Мережі для найбільш досвідчених. Микровыпуск №7. EVPN



Як ви пам'ятаєте з минулого випуску провайдер linkmeup став на щабель Tier 2. Але просто надавати послуги доступу в Інтернет або L2/3VPN-и (по суті трубою для трафіку) Linkmeup не влаштовує. Зараз великим попитом користуються послуги хмарного зберігання даних, тому linkmeup обзавівся кількома власними датацентрами, розташовані з економічних міркувань в Рязані. У зв'язку з цим перед нами постало нове завдання — як зв'язати датацентри між собою і надати клієнтам доступ до корпоративних СГД, розташовані в наших автозалах? Зважаючи на те, що в core-network вже запущений MPLS, то наш вибір припав на EVPN/MPLS. Його і розглянемо.

Дана технологія вирішує проблеми існуючих на сьогоднішній день методів об'єднання датацентрів через віртуальну L2 мережу. Звичайно, ця технологія не єдина у своєму роді, але інші ми поки що не будемо розглядати в силу їх проприетарности. Завжди треба дивитися в майбутнє і хоча сьогодні ми будемо будувати мережу виключно на Juniper MX, ми, як провайдер, не можемо бути впевнені в тому, що завтра у нас не з'являться парочка ASR9K. Можливо, деякі з рішень, застосованих в EVPN, вам здадуться занадто складними і незрозумілими. Але при цьому не варто забувати навіщо ця технологія була придумана, які проблеми вона вирішує та чи можливо було реалізувати це по-іншому. Хоча в назві присутнє слово микровыпуск, не варто думати, що дана стаття буде маленькою і простий. Навпаки, обсяг статті більше 115 000 знаків (близько 60 сторінок А4, написаних 11-м шрифтом) і багато чого з описаного не зовсім очевидно і зрозуміло з першого разу.

Відразу хочу загострити увагу читача на те, що в даній статті ми будемо розгортати і розглядати на практиці EVPN поверх MPLS, а не VXLAN. Але, як ви розумієте, EVPN це control plane, тому принцип роботи що поверх MPLS, що поверх VXLAN буде приблизно однаковий, але є й істотні відмінності. Тому, якщо ви хочете ближче дізнатися EVPN/VXLAN, то можете почитати документацію, наприклад, Brocade — у них ця тема добре розкрита, або документацію на комутатори Cisco серії Nexus. Ну а ми приступимо до вивчення EVPN/MPLS.

Зміст статті:1.0. Згадуємо VPLS
2.0. Базова частина технології EVPN
3.0. Лабораторія для тестів і конфігурації
4.0. Маршрут типу 3
5.0. Маршрут типу 2
5.1. Вивчення MAC-адрес
6.0. Маршрут типу 1
6.1. Автоматичний пошук multihomed PE і ESI label
6.2. MAC Mass Withdrawal
6.3. Aliasing label
7.0 Маршрут типу 4
7.1 Механізм вибору DF
8.0. L3-функціонал в EVPN
8.1. IRB synchronisation
8.2. Маршрутизація між bridge-доменами
8.3. Вихід в інші VRF і зовнішні мережі
9.0. Навіщо це все-таки потрібно?
10.0. Висновок

Згадуємо VPLS
Думаю, що всі вже прочитали про випуск L2VPN і уявляють собі, що таке VPLS і з чим його їдять. Трохи освіжити в пам'яті які види VPLS існують на сьогоднішній день і чим же вони істотно відрізняються:
  • VPLS LDP-signaling (Martini)
  • VPLS LDP-signaling with BGP-Autodiscovery
  • VPLS BGP-signaling (Kompella)
VPLS LDP-signaling (Martini) — найбільш проста технологія, що реалізує функціонал VPLS, і в плані конфігурації і в плані траблшутинга, але складна в адмініструванні, так як дана не наділена функцією автоматичного пошуку РЕ-маршрутизаторів, що входять в один VPLS домен. Тому, всі РЕ-маршрутизатори, які беруть участь в одному VPLS домені, явно прописуються на кожному РЕ-маршрутизаторі вручну. У підсумку, додавання нового сайту в існуючий VPLS домен передбачає зміну конфігурації на всіх РЕ-маршрутизаторах даного VPLS домену, що, на мій погляд, не дуже зручно, особливо якщо у клієнта 5-6 сайтів і більше. До плюсів даної технології можна віднести її простоту і відсутність необхідності в додаванні нового сімейства адрес в протокол BGP (для частини старого обладнання в той момент, коли народилася технологія, знадобилося б оновити софт). Так як вся сигналізація працює виключно за LDP, то робота даної технології була зрозуміла інженерами без необхідності щось заново вивчати (все-таки ми, люди, в основній своїй масі ліниві істоти). Але в сучасних реаліях, думаю, що зручніше один раз додати нове сімейство адрес в BGP (нехай навіть доведеться оновитися софт на парі залозок), а не бігати постійно по всіх PE-кам при додаванні нейбора в VPLS-домен.

VPLS LDP-signaling with BGP-Autodiscovery. У кінцевому рахунку розробники технології VPLS LDP-signaling все ж зрозуміли свою помилку — відсутність автоматичного пошуку інших РЕ-шек сильно обмежувало масштабованість даного рішення в порівнянні з VPLS BGP-signaling, тому було вирішено додати в дану технологію автоматичний пошук РЕ-маршрутизаторів. Природно, засобами LDP це реалізувати у них не вийшло, тому був використаний великий і могутній BGP, в який було додано ще одне сімейство адрес (причому відмінне від родини адрес, що використовуються в VPLS Kompella), зарезервовано нове розширене ком'юніті l2vpn-id і доданий новий FEC — FEC129 (в VPLS LDP використовується FEC128). У результаті, при використанні даної технології, пошук PE маршрутизаторів здійснюється по протоколу BGP, а L2 канали вже сигналізуються за LDP. На мій погляд, даними діями розробники перекреслили все, чим вони пишалися до цього і, якщо ваше обладнання підтримує і Martini+BGP AD і Kompella, то особисто я б вибрав друге.

VPLS BGP-signaling (Kompella). Дана технологія сильно відрізняється від двох попередніх — загальна у них тільки мета — організація віртуальної мережі L2 поверх мережі провайдера. Даний вид VPLS використовує для сигналізації протокол BGP, який забезпечує автоматичний пошук сусідів і сигналізація віртуальних L2 каналів. У результаті ми маємо добре масштабоване рішення, а менша поширеність VPLS BGP-signaling в мережах провайдерів обумовлена швидше за все тим, що дана розробка просувалася Juniper і до певного часу просто не підтримувалася іншими вендорами, а також удавана на перший погляд складність самої технології — чого варта одна модель розподілу міток.

Всі перераховані технології забезпечують один і той же результат — організацію віртуальної мережі L2 поверх мережі провайдера, різняться лише засоби реалізації і можливості даних технологій, про яких ви можете почитати в попередньому випуску СДСМ. Але у даних технологій є кілька загальних проблем, які накладають певні незручності при експлуатації і не дають спокою розробникам. Таких проблем як мінімум три:

1. Немає можливості для multihomed сайтів (сайтів, підключених до 2-м і більш PE маршрутизаторам одночасно) використовувати всі лінки для передачі трафіку (працювати в Active-Active mode);

2. Ці технології не надають розширених функцій L3, за винятком банального додавання BVI/IRB інтерфейсу в VPLS домен для виходу у зовнішню мережу;

3. MAC-адреси вивчаються виключно на рівні data plane, що призводить до збільшення флуду BUM трафіку в мережі провайдера.

Боротися з цими недоліками в VPLS вже марно — це сильно ускладнить і так не прості технології (приміром є технологія NG-VPLS, яка використовується P2MP LSP, але про її реальному використанні я не чув). Тому була винайдена нова технологія, в якій дані недоліки були усунуті. Сьогодні ми поговоримо про Ethernet VPN (EVPN). Існує думка, що дана технологія є розвитком VPLS BGP-signaling, думаю, що для простоти сприйняття, не буде зайвим в даній статті порівнювати EVPN c VPLS BGP-signaling (далі буду писати просто VPLS, що передбачає саме VPLS BGP-signaling).

Особисто моя думка, що ця технологія є гібридом L3VPN і VPLS BGP-signaling. А чому, думаю, ви зрозумієте, дочитавши статтю до кінця. Отже, поїхали…

Базова частина технології EVPN
Як і VPLS, EVPN використовує для сигналізації виключно протокол BGP, але використовує вже нові NLRI: AFI 25 SAFI 70 (деякі версії Wireshark ще не знають дане AFI/SAFI і при знятті дампа пишуть unknown SAFI for AFI 25). Використання нового сімейства адрес обумовлено тим, що EVPN використовує для вивчення MAC-адрес не тільки data-plane, як в стандартному VPLS або комутаторі, але і control-plane:

Маленький ліричний відступ: можливо ілюстрації в стилі Brocade комусь не сподобаються, але використання даних ілюстрацій обумовлено тим, що якщо використовувати позначення маршрутизаторів і комутаторів в стилі Juniper або Cisco, то ми на деяких малюнках отримаємо не читається місиво, а нам цього не хочеться. Ну і особисто мені такі малюнки як то більше подобаються (але це, як мовиться, на смак і колір...). Нижче представлений список всіх позначень на схемах:

Давайте розглянемо, як же відбувається вивчення MAC-адрес в EVPN. Використовувати будемо ось таку банальну мережа:

Уявімо, що CE1 хоче відправити пакет ICMP на CE2:

1. Так як у CE1 немає MAC-адреси CE2, то CE1 робить широкомовний ARP запит на резолв адреси CE2.

2. PE1, отримавши від CE1 широкомовний пакет, аналізує його заголовок і розуміє, що цей пакет треба переслати всім іншим PE маршрутизаторам в даному широкомовному домені. Крім цього, PE1 записує source MAC MAC-таблицю відповідного bridge-домену.

Якщо б у нас був VPLS, то більше ніяких операцій PE1 не став би робити. Але у нас EVPN, тому PE1 генерує BGP Update, в якому вказує MAC-адресу CE1 і мітку VPN, і відправляє його на всі інші PE маршрутизатори (природно, через роутрефлектор).

3. PE2 і PE3 отримують цей широкомовний пакет і відправляють його всім підключеним CE-маршрутизаторам. Як і в VPLS, в EVPN є функція split horizon — пакет, отриманий від PE маршрутизатора, не буде відправлений на інші PE маршрутизатори.

У VPLS PE2 і PE3, при отриманні пакету від PE1, повинні були б записати MAC-адресу CE1 MAC-таблиці та асоціювати його з PW в бік PE1. Але в EVPN вивчати MAC-адреси по source адрес пакетів, що прийшли від інших PE маршрутизаторів, немає необхідності, адже PE1 вже зробив анонс MAC+label, а значить PE1 і PE2 запис в таблиці MAC-адрес зроблять з цього анонсу (так, як в L3VPN з IPv4 префіксами).

4. PE2 отримує від CE2 відповідь на даний ARP запит. Так як MAC-адресу CE1 і мітка до нього вже відомі з отриманого від PE1 BGP анонсу, то пакет відправляється юникастом прямо на PE1. Крім цього PE2 записують MAC-адресу CE2 MAC-таблицю і генерує BGP Update, в якому вказує MAC-адресу CE2 і мітку, і відправляє його на інші PE маршрутизатори.

5. PE1 отримує вже юникастовый пакет і по MAC-таблиці відправляє його у відповідний інтерфейс.

Як ви вже зрозуміли, EVPN використовує MAC-адреси, як роутинговые адреси. Це можна порівняти з розподілом маршрутів всередині L3VPN.

Думаю всі прочитали статтю про L2VPN пам'ятають, що в VPLS розподіл міток з допомогою BGP проводиться блоками, так як одержувачу пакета (в сенсі PE маршрутизатора) необхідно знати, з якого PE-маршрутизатора прилетів даний пакет, і асоціювати MAC-адресу з PW до цього PE маршрутизатора. У EVPN такої потреби вже немає. Це відбувається через те, що EVPN обробляє MAC-адреси, так само, як L3VPN IPv4 префікси — PE маршрутизатор, вивчивши новий MAC-адресу через data plane від підключеного CE маршрутизатора, відразу анонсує даний MAC BGP. В BGP анонсі вказується MPLS мітка і protocol next-hop (як правило, це лупбек PE маршрутизатора). У підсумку всі інші PE маршрутизатори знають куди відправляти пакет і з якою міткою.

Цікавий факт: в VPLS (будь-якому його вигляді), описаного вище сценарію, PE3 дізналася б тільки MAC-адресу CE1, так як від CE2 до CE1 пакет передається вже юникастом і не потрапить на PE3. А при використанні EVPN PE3 вивчає обидва MAC-адреси і CE1 і CE2, перший дізнається з анонсу від PE1, другий з анонсу від PE2.


Сподіваюся, принцип роботи технології зрозумілий, і тепер ми можемо перейти від теорії до практики і подивитися на роботу EVPN на прикладі.

Лабораторія для тестів і конфігурації
Для тестів я використовував Unetlab, в якій зібрав стенд з чотирьох vMX і трьох Cisco IOL (L3). Як ви розумієте vMX-си використовується для емуляції мережі провайдера, а Cisco — як клієнтські CE маршрутизатори. Якщо кому цікаво, то дана лаба була запущена на самому звичайному ноутбуку з i5 і 12 Гб ОПЕРАТИВНОЇ пам'яті (з яких лише 6 було зайнято, а завантаження CPU не перевищувала 30 відсотків) — так що можете запустити у себе і помацати EVPN.

Наша схема виглядає наступним чином:

Як ви зрозуміли, у нас три PE маршрутизатора, один P-маршрутизатор, він же і роутрефлектор, і три CE маршрутизатора. Вся адресація для зручності наведена на схемі.

Juniper дозволяє нам сконфігурувати routing-instance для EVPN двома способами — це перший instance з типом EVPN — самий простий, і другий, instance з типом virtual-switch. Особисто мені більше подобається другий варіант, так як він більш гнучкий, але для наочності в нашій лабі ми будемо використовувати обидва способи. Однак відмінності цих двох способів не тільки в конфігурації.

VLAN Based Service — даний тип використання EVPN хороший тим, що bridge-домени повністю ізольовані один від одного. Але на кожен влан доведеться робити нову routing instance. У такому сценарії трафік між PE маршрутизаторами може йти як з влан тегом так і не тегированным. JunOS за замовчуванням відправляє тегированный трафік з оригінальним тегом (якщо, звичайно, не налаштовані правила перезапису тега на інтерфейсі).
Конфігурація routing instance з типом EVPN виглядає ось так:
bormoglotx@RZN-PE-3> show configuration routing-instances RZN-VPN-1
instance-type evpn;
vlan id 777;
interface ge-0/0/2.200;
interface ge-0/0/2.777;
routing-interface irb.777;
route-distinguisher 62.0.0.3:1;
vrf-import VPN-1-IMPORT;
vrf-export VPN-1-EXPORT;
protocols {
evpn {
interface ge-0/0/2.777;
}
}
bormoglotx@RZN-PE-3> show configuration interfaces ge-0/0/2
description "link to RZN-CE3-SW1";
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
mac 50:01:00:03:00:04;
unit 777 {
encapsulation vlan-bridge;
vlan id 777;
family bridge;
}

У конфігурації инстанса з типом EVPN варто звернути увагу на таку строчку:
bormoglotx@RZN-PE-3> show configuration routing-instances RZN-VPN-1 | match vlan
vlan id 777;

Це значення визначає, який тег використовується для нормалізації. Тобто якщо до цього EVPN инстансу буде підключений крім влана 777 ще й влан 200 (як у наведеному вище конфіги), то при отриманні пакету з тегом 200, PE маршрутизатор буде знімати цей тег (тег 200) і навішувати новий — 777. На прийом PE-ка буде діяти в зворотній послідовності — зніматися тег 777 навішувати тег 200 при відправці в інтерфейс в бік CE-маршрутизатора, в нашому випадку інтерфейс ge-0/0/2.200 (см конфігурацію вище, на схемах даний CE маршрутизатор не показаний).

Це мінімальна конфігурація, яка дозволить EVPN працювати (не забуваємо про базове налаштування мережі — IGP, MPLS і т. д., яка тут не представлена). Як бачите, ми вказуємо RD і RT, так як для сигналізації використовується BGP. Все як завжди — RD робить наш маршрут унікальним, а RT використовуються для фільтрації маршрутів. Політики імпорту і експорту на всіх PE-маршрутизаторах однакові, але для тих, кому цікава їх конфігурація, наведу її під спойлером:
Конфігурація політик
bormoglotx@RZN-PE-3> show configuration policy-options policy-statement VPN-1-IMPORT
term DEFAULT-IMPORT {
from {
протоколу bgp;
community VPN-1;
}
then accept;
}
term REJECT {
then reject;
}

bormoglotx@RZN-PE-3> show configuration policy-options policy-statement VPN-1-EXPORT
term DEFAULT {
then {
community + VPN-1;
accept;
}
}
term REJECT {
then reject;
}

bormoglotx@RZN-PE-3> show configuration policy-options community VPN-1
members target:6262:777;


VLAN Service Aware — в цьому випадку ми робимо тільки одну routing instance з типом virtual switch і додаємо в неї bridge-домени. Якщо у клієнта буде 30 вланов, нам не треба городити конфіг на сотні рядків, роблячи instance на кожен влан — досить створений для клієнта instance додати 30 bridge-доменів. У цьому випадку наявність vlan тега, згідно RFC, обов'язково.
Конфігурація instance з типом virtual-switch має приблизно такий вигляд:
bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-1
instance-type virtual-switch;
interface ge-0/0/2.0;
route-distinguisher 62.0.0.1:1;
vrf-import VPN-1-IMPORT;
vrf-export VPN-1-EXPORT;
protocols {
evpn {
extended-vlan-list 777;
}
}
bridge-domains {
VLAN-777 {
vlan id 777;
}
}

bormoglotx@RZN-PE-1> show configuration interfaces ge-0/0/2
description "link to RZN-CE1-SW1";
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
mac 50:01:00:01:00:04;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 777;
}
}

Ніяких проблем при використанні з одного боку EVPN, з іншого virtual switch бути не повинно (якщо ви все робите як належить), так як JunOS з инстанса EVPN відправляє тегированный трафік з оригінальним тегом. У всякому разі в ході тестування я проблем не виявив. Але є один нюанс. Варто враховувати, що нормалізація може зіграти з вами злий жарт, якщо ви почнете в одному і тому ж EVPN домені використовувати різні типи инстансов не розділяючи вланы по bridge-доменам. Наприклад на одному PE-маршрутизаторі в інстанси з типом EVPN ви додаєте два влана: 777 1777, а для нормалізації використовуєте влан 777. З іншого кінця у вас буде virtual switch з двома bridge доменами — vlan 777 і vlan 1777. В результаті отримуємо: пакет прилітає від CE під влане 1777, відбувається нормалізація влана на 777 і в інстанси virtual switch пакет прилітає у влан 777. А хост призначення під влане 1777, тобто в іншому bridge домені. У підсумку — у вас немає зв'язності між хостами в одному влане. Або інший варіант розвитку подій — в одному і тому ж bridge домені ви вас є відповідні різні теги, призначені для нормалізації. У такому випадку у вас теж не буде зв'язності (взагалі не буде), так як з PE1 пакет буде відлітати наприклад з нормальним тегом 777, а на PE2 нормальний тег — 1777. У підсумку PE2 буде просто відкидати пакети з відповідним номером влана.

Маршрут типу 3
В даний момент часу ще обміну пакетами між CE маршрутизаторами не проводилося (природно, CDP, LLDP та інші радості відключені, щоб мережа не відлітало що то зайве), тому ні один з PE маршрутизаторів не вивчив жодного MAC-адреси. Це можна перевірити:
bormoglotx@RZN-PE-1> show evpn instance RZN-VPN-1 brief
Intfs IRB intfs MH MAC addresses
Instance Total Up Total Up Nbrs ESIs Local Remote
RZN-VPN-1 1 1 0 0 2 0 0 0

З цього висновку ми можемо дізнатися, що в цій routing-instance 1 інтерфейс і він в активному стані, IRB інтерфейсів у нас немає (про них пізніше). Ми бачимо двох сусідів ( за нашою схемою це PE2 і PE3), а також що нами ще не вивчений жоден MAC-адресу ( local — це MAC-адреси, локальні для даного PE маршрутизатора, а remote — це MAC-адреси, отримані від сусідніх PE маршрутизаторів).

Тепер подивимося, які маршрути у нас є в таблиці маршрутизації даної routing-instance:
bormoglotx@RZN-PE-1> show route table RZN-VPN-1.evpn.0

RZN-VPN-1.evpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3:62.0.0.1:1::777::62.0.0.1/304
*[EVPN/170] 01:33:42
Indirect
3:62.0.0.2:1::777::62.0.0.2/304
*[BGP/170] 01:10:22, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.1 via ge-0/0/0.0, Push 299808
3:62.0.0.3:1::777::62.0.0.3/304
*[BGP/170] 01:10:01, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.1 via ge-0/0/0.0, Push 299776

У нас всього три маршрути, причому перший локальний для PE1. Що ж це за маршрути і навіщо вони потрібні? Давайте розбиратися. У EVPN існує всього 5 типів маршрутів:
  • 1 — Ethernet Auto-Discovery (A-D) route
  • 2 — MAC/IP Advertisement route
  • 3 — Inclusive Multicast Ethernet Tag route
  • 4 — Ethernet Segment route
  • 5 — IP Prefix Route*
Примітка: маршрут 5-го типу в даний час ще не затверджений в статуті RFC, і поки що описаний тільки в драфті, тому в даній статті ми його розглядати не будемо.
У представленому вище висновку ми бачимо, що першою цифрою в маршруті є 3, а значить це Inclusive Multicast Ethernet Tag route. Даний маршрут генерується кожним PE маршрутизатором і використовується для прийому і відправки BUM трафіку. Складається маршрут з наступних полів:

RD — думаю всім зрозуміло, що це таке, в показаному нижче анонсі це :62.0.0.3:1:
Ethernet ID Tag — це номер влана, в нашому випадку :777:
IP Address Length — довжина IP-адреси, зазначеної в наступному полі (на обладнання Juniper дане значення не показується)
Originating Router's IP Address — IP-адреса оригінатора маршруту, як правило лупбек PE маршрутизатора. У нашому випадку це :62.0.0.3.

Примітка: /304 — довжина префікса, Juniper автоматично додає її до всіх EVPN маршрутами, смислового навантаження по суті не несе. Як написано на сайті Juniper, дане значення означає максимальну довжину маршруту і дозволяє використовувати цю особливість при пошуку маршрутів з допомогою регулярних виразів. Ну що ж, врахуємо на майбутнє.
3:62.0.0.3:1::777::62.0.0.3/304 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 62.0.0.3:1
PMSI: Flags 0x0: Label 299904: Type INGRESS-REPLICATION 62.0.0.3
Next hop type: Indirect
Address: 0x95ca3d4
Next-hop reference count: 2
Source: 62.0.0.255
Protocol next hop: 62.0.0.3
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: <Secondary Active Int Ext>
Local AS: 6262 Peer AS: 6262
Age: 1:16:02 Metric2: 1
Validation State: unverified
Task: BGP_6262.62.0.0.255+179
Announcement bits (1): 0-RZN-VPN-1-evpn
AS path: I (Originator)
Cluster list: 62.0.0.255
Originator ID: 62.0.0.3
Communities: target:6262:777
Import Accepted
Localpref: 100
Router ID: 62.0.0.255
Primary Routing Table bgp.evpn.0

Якщо подивитися на маршрут уважніше, то ми бачимо наступну рядок:
PMSI: Flags 0x0: Label 299904: Type INGRESS-REPLICATION 62.0.0.3

PMSI розшифровується як Provider Multicast Service Interface, і це не що інше, як Point-to-Multipoint LSPs. У даній статті ми не будемо розглядати як працює P2MP LSP, так як це дуже велика і складна тема, але, як бачите, в EVPN використовується функціонал p2mp LSP для пересилання BUM трафіку. PE3 згенерував мітку 299904, яку можуть використовувати інші PE маршрутизатори, щоб відправити BUM трафік на PE3.

Маршрут типу 3 генерується на кожен влан окремо, про що говорять у його назві слова Ethernet Tag. Якщо у вас буде два bridge-домену (наприклад влан 777 і влан 1777), то PE маршрутизатор згенерує два маршрути типу 3 — по одному на кожен влан (bridge-домен).

Ми з'ясували, що в початковий момент часу в таблиці маршрутизації EVPN є тільки маршрути типу 3, щоб PE маршрутизатори знали з якою міткою їм відправляти широкомовні пакети на віддалені PE маршрутизатори.

Маршрут типу 2
Тепер запустимо пінг між CE1 і CE2:
RZN-CE1-SW1#ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 7/8/11 ms

Одні пакет загубився, так як CE1 зробив ARP запит на резолв адреси 10.0.0.2. Тепер подивимося, з'явилися адреси MAC-таблиці:
bormoglotx@RZN-PE-1> show evpn instance RZN-VPN-1 brief
Intfs IRB intfs MH MAC addresses
Instance Total Up Total Up Nbrs ESIs Local Remote
RZN-VPN-1 1 1 0 0 2 0 1 1

З'явилися відразу два MAC-адреси: один локальний для PE1 (адреса CE1) і один MAC, отриманий від PE2 (адреса CE2):
bormoglotx@RZN-PE-1> show route table RZN-VPN-1.evpn.0

RZN-VPN-1.evpn.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2:62.0.0.1:1::777::aa:bb:cc:00:06:00/304
*[EVPN/170] 00:05:23
Indirect
2:62.0.0.2:1::777::aa:bb:cc:00:07:00/304
*[BGP/170] 00:05:23, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.1 via ge-0/0/0.0, Push 299808

Тепер у нас в таблиці два нових маршруту (всього у таблиці 5 маршрутів, маршрути типу 3 не показані для скорочення виводу). Маршрути мають тип 2 — MAC/IP Advertisement route. Даний маршрут має наступний вигляд:

RD — Route Distinguisher, куди ж без нього, в нашому випадку дорівнює :62.0.0.2:1;
Ethernet Segment Identifier — ідентифікатор ESI, про нього поговоримо пізніше. JunOS показує це значення тільки при detail або extensive висновках, у нас в маршруті він дорівнює нулю: ESI: 00:00:00:00:00:00:00:00:00:00;
Ethernet ID Tag — номер влана :777;
MAC Address Length — довжина MAC-адреси, по суті завжди 48 біт, і JunOS дане значення не виводить;
MAC Address — сам MAC-адресу: aa:bb:cc:00:07:00;
IP Address Length — довжина IP-адреси, для IPv4 дорівнює 32 бітам, і для IPv6 — 128. Дане поле опціонально і може не містити ніяких значень (всі нулі). JunOS дане значення не виводить.
IP Address — сам адресу, у висновку нижче він не представлений. Поле заповнюється опціонально.
MPLS Label1|2 — безпосередньо сама мітка, JunOS її показує тільки при detail або extensive виведення.
2:62.0.0.2:1::777::aa:bb:cc:00:07:00/304 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 62.0.0.2:1
Next hop type: Indirect
Address: 0x95c9f90
Next-hop reference count: 4
Source: 62.0.0.255
Protocol next hop: 62.0.0.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: <Secondary Active Int Ext>
Local AS: 6262 Peer AS: 6262
Вік: 26 Metric2: 1
Validation State: unverified
Task: BGP_6262.62.0.0.255+179
Announcement bits (1): 0-RZN-VPN-1-evpn
AS path: I (Originator)
Cluster list: 62.0.0.255
Originator ID: 62.0.0.2
Communities: target:6262:777
Import Accepted
Route Label: 300272
ESI: 00:00:00:00:00:00:00:00:00:00
Localpref: 100
Router ID: 62.0.0.255
Primary Routing Table bgp.evpn.0

Як я і писав раніше, EVPN використовує MAC-адреси як роутинговые адреси. З анонсу від PE2, PE1 тепер знає, що, щоб дістатися до MAC-адреси aa:bb:cc:00:07:00 у влане 777 (звертаю увагу, що саме в 777 влане, так як один і той же MAC-адресу може бути в різних вланах, і це будуть різні маршрути), необхідно навісити на пакет дві мітки: 300272 (VPN) і транспортну мітку до 62.0.0.2.

Примітка: крім усім відомих полів Route Distinguisher, Protocol next hop і т д ми бачимо поле ESI, яке в даному анонсі виставлено в нулі. Це поле дуже важливо при використанні multihomed сайтів, і до нього ми повернемося трохи пізніше, в цьому випадку воно не грає ролі.
Як і L3VPN, EVPN вміє генерувати мітки per-mac, per-next-hop і per-instance:

per-mac — на кожен мак адресу генерується окрема мітка. Як ви розумієте цей вид розподілу міток занадто марнотратний;

per-next-hop — мабуть, точніше буде сказати per-CE або per-AC, тобто одна і та ж мітка генерується тільки для MAC-адрес, що перебувають за одним і тим же Attachment Circuit (тобто якщо до одного PE маршрутизатора в одному routing-instance підключено два CE маршрутизатора, то для MAC-адрес, вивчених від CE1, PE маршрутизатор буде генерувати одну мітку, а для MAC-адрес, вивчених від CE2 — іншу)

per-instance — одна мітка генерується на весь routing-instance, тобто у всіх маршрутів буде одна і та ж мітка. В JunOS ви можете побачити цю мітку при перегляді EVPN instance в режимі extensive.

Вивчення MAC-адрес
Тепер подивимося на MAC-таблицю на PE1:
bormoglotx@RZN-PE-1> show bridge mac-table

MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)

Routing instance : RZN-VPN-1
Bridging domain : VLAN-777, VLAN : 777
MAC MAC Logical NH RTR
address flags interface Index ID
aa:bb:cc:00:06:00 D ge-0/0/2.0
aa:bb:cc:00:07:00 DC 1048575 1048575

Колонка flag говорить нам про те, як був вивчений даний адреса: MAC-адресу aa:bb:cc:00:06:00 має тільки прапор D, що означає, що цей мак вивчений динамічно (стандартним способом через data plane) і, так як більше ніяких прапорів ми не бачимо, то можемо з упевненістю сказати, що даний MAC вивчений від локально підключеного CE маршрутизатора. А ось MAC-адресу aa:bb:cc:00:07:00 має два прапори — DC. Що означає " перший прапор, ми вже знаємо, а от прапор Із говорить про те, що даний адреса вивчений через control plane.

Якщо ми подивимося на таблицю MAC-адрес на PE3, то побачимо, що всі адреси вивчені даними PE маршрутизатором через control plane, і немає жодного локального MAC-адреси:
bormoglotx@RZN-PE-3> show evpn mac-table

MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)

Routing instance : RZN-VPN-1
Bridging domain : __RZN-VPN-1__, VLAN : 777
MAC MAC Logical NH RTR
address flags interface Index ID
aa:bb:cc:00:06:00 DC 1048574 1048574
aa:bb:cc:00:07:00 DC 1048575 1048575

Примітка: якщо ви помітили, в одному випадку я використав команду show bridge mac-table, а в другому show evpn mac-table. Це обумовлено тим, що на різних PE маршрутизаторах routing instance налаштовані по-різному — в першому випадку virtual-swicth, у другому EVPN.


На PE3 немає жодного вивченого локально MAC-адреси, так як ще не було трафіку від CE3. Давайте виправимо цю ситуацію, запустивши пінг до CE3, і ще раз подивимося дану таблицю:
RZN-CE1-SW1#ping 10.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 7/10/13 ms

bormoglotx@RZN-PE-3> show evpn mac-table

MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)

Routing instance : RZN-VPN-1
Bridging domain : __RZN-VPN-1__, VLAN : 777
MAC MAC Logical NH RTR
address flags interface Index ID
aa:bb:cc:00:05:00 D ge-0/0/2.777
aa:bb:cc:00:06:00 DC 1048574 1048574
aa:bb:cc:00:07:00 DC 1048575 1048575

Як бачите, на PE3 тепер з'явився MAC-адресу CE3, вивчений через data plane.

Як і у звичайного свіча, адреси MAC-таблиці EVPN мають певний «термін придатності», цей термін дорівнює 300-м секунд. Якщо протягом даного часу цей MAC був неактивний і не оновлювався, то маршрут видаляється з таблиці. Начебто, все просто — таймер відпрацював — MAC видалили. Але все не так просто, як здається. Давайте розглянемо, як це відбувається.

Отже, PE3 вивчив MAC-адресу CE3 і відправив його в BGP анонсі іншим PE маршрутизаторам. Припустимо, що протягом 300 секунд запис не оновлювалася. Тоді PE3 повинен видалити даний MAC-адресу з таблиці, що він і робить. Але ми пам'ятаємо, що PE3 відправив всім своїм сусідам інформацію про те, що даний MAC-адресу знаходиться за ним. А раптом цей хост переїхав або взагалі вже вимкнений? Що тоді? Інші PE маршрутизатори так і будуть слати пакети для CE3 на PE3, як у чорну діру? Звичайно, немає. Справа в тому, що якщо PE маршрутизатор видаляє з таблиці локальний MAC-адресу, то він відправляє BGP Withdrawn повідомлення, яке змушує інші PE маршрутизатори видалити цей маршрут, а отже і MAC-адресу, з своїх таблиць. Давайте це перевіримо.

На першому скріні представлений BGP UPDATE Message, який оголошує MAC-адресу aa:bb:cc:00:07:00 (картинки клікабельні):

Через 300 секунд, ми бачимо ще одне BGP UPDATE Message, яке є Withdrawn повідомленням, скасовує маршрут до зазначеного раніше MAC-адреси:

Крім MAC aging time, у EVPN є механізм сигналізації про зміну MAC-адреси. Коли від CE маршрутизатора PE-ка отримує Gratuitous ARP, то генерується BGP Update, в якому міститься withdrawn повідомлення із зазначенням старого MAC-адреси і анонс нового MAC-адреси.

Але крім MAC-адреси маршрут MAC/IP Advertisement route опціонально може містити в собі і IP-адреса хоста. Додамо в наш EVPN роутинговый-інтерфейс IRB і подивимося який маршрут з'явився:
bormoglotx@RZN-PE-1> show configuration interfaces irb.777
family inet {
address 10.0.0.254/24;
}
mac 02:00:00:00:00:02;

bormoglotx@RZN-PE-1> *2:62.0.0.1:1::777::02*
show route table RZN-VPN-1.evpn.0 match-prefix
RZN-VPN-1.evpn.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2:62.0.0.1:1::777::02:00:00:00:00:02/304
*[EVPN/170] 14:17:31
Indirect
2:62.0.0.1:1::777::02:00:00:00:00:02::10.0.0.254/304
*[EVPN/170] 14:17:31
Indirect

З'явилися два нових маршруту, причому перший це MAC-адресу irb.777, а ось другий MAC+IP. Mac+IP анонс має вигляд ARP запису, все PE маршрутизатори, які беруть участь в одному EVPN-домені, синхронізують свої ARP-запису, що дозволяє зменшити кількість флуду широкомовні ARP запитів по мережі провайдера.

Тепер подивимося на маршрут уважніше:
bormoglotx@RZN-PE-1> show route table RZN-VPN-1.evpn.0 match-prefix *2:62.0.0.1:1::777::02* detail

RZN-VPN-1.evpn.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
2:62.0.0.1:1::777::02:00:00:00:00:02/304 (1 entry, 1 announced)
*EVPN Preference: 170
Next hop type: Indirect
Address: 0x940d804
Next-hop reference count: 7
Protocol next hop: 62.0.0.1
Indirect next hop: 0x0 - INH Session ID: 0x0
State: <Ad Int Ext>
Age: 14:21:34
Validation State: unverified
Task: RZN-VPN-1-evpn
Announcement bits (1): 1-BGP_RT_Background
AS path: I
Communities: evpn-default gateway
Route Label: 300144
ESI: 00:00:00:00:00:00:00:00:00:00

У даному маршруті з'явилося нове розширене ком'юніті evpn-default gateway. Саме так позначаються маршрути, які є основним шлюзом для routing-instance. Даний маршрут буде генеруватися для кожного влана окремо.

Чому генеруються два маршрути? Справа в тому, що перший маршрут, в якому вказано MAC-адреса, що використовується виключно для свитчинга в bringe-домені, а ось маршрут MAC+IP вже використовується для маршрутизації і є по своїй суті arp записом. Забіжу трохи наперед і напишу, що точно так само будуть генеруватися маршрути до хостів при русі трафіку в інші вланы або в зовнішню мережу (це ми розглянемо далі при додаванні в схему ще одного влана).

Маршрут типу 1
Поки що у нас без уваги залишилися маршрути типу 1 і типу 4. Ці маршрути використовуються для multihomed сайтів.

Примітка: через занадто великого обсягу статті глибоко занурюватися в роботу EVPN з multihomed сайтами ми не будемо. Якщо комусь буде цікаво — пишіть в коментарі — напишу по цій темі окрему статтю.


Маршрут типу 1 має наступний вигляд:

1:62.0.0.2:0::112233445566778899aa::0/304
*[BGP/170] 00:00:56, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.1 via ge-0/0/0.0, Push 299792

Даний маршрут не несе інформації про MAC-адресах, але має дуже широке застосування, таке як:
  • Автоматичний пошук PE маршрутизаторів, до яких підключений один і той же CE-маршрутизатор
  • Анонс ESI мітки
  • Анонс масової скасування вивчених MAC-адрес
  • Анонс Aliasing мітки
Маршрут 1 типу може анонсуватися per-EVI або per-ESI. Перший анонс використовується при анонсуванні Aliasing мітки, другий — для можливості масової скасування анонсованих MAC-адрес якого-небудь сегмента ethernet.

Давайте зупинимося на вищеописаних функція даного маршруту докладніше.

Автоматичний пошук multihomed PE ESI label
На відміну від VPLS, в EVPN включена функція автоматичного виявлення РЕ-маршрутизаторів, підключених до одного і того ж СЕ-маршрутизатора (multihomed сайти). У термінах EVPN стик PE<->CE називається Ethernet Segment. Кожному сегменту призначається ESI (Ethernet Segment Identifier, число розміром 80 біт записане в 10 групах по 8 біт в групі). Для single-homed сайтів даний код не грає ролі і тому призначається автоматично і дорівнює 0. Але от для multihomed сайтів даний ідентифікатор дуже важливий і повинен бути унікальним для всього EVPN-домену (благо кількість можливих комбінацій ESI дуже велике і дорівнює 2^80). ES, підключені до одного і того ж CE-маршрутизатора, повинні мати один і той же ESI. Два значення з усього діапазону зарезервовані, і їх не можна задати адміністративно — це всі нулі (використовується як ідентифікатор для не multihoming сегментів) і все F.

У представленому вище виведення магічний набір букв і цифр :112233445566778899aa: є не що інше, як ESI, сконфігурований адміністратором мережі на фізичному інтерфейсі:
bormoglotx@RZN-PE-2> show configuration interfaces ge-0/0/4
description "link to RZN-MULTI-SW-1";
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
esi {
11:22:33:44:55:66:77:88:99:aa;
single-active;
}
mac 50:01:00:02:00:06;
unit 111 {
encapsulation vlan-bridge;
vlan id 111;
family bridge;
}

Даний маршрут, крім ESI несе в собі дуже важливе значення, яке представлене у вигляді розширеного ком'юніті: esi-label. Виглядає вона наступним чином:
bormoglotx@RZN-PE-2> show route table RZN-VPN-3.evpn.0 match-prefix *1:62* detail RZN-VPN-3.evpn.0: 6 destinations, 6 routes (active 6, 0 holddown, 0 hidden)

1:62.0.0.1:0::112233445566778899aa::0/304 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 62.0.0.1:0
Next hop type: Indirect
Address: 0x95c0f28
Next-hop reference count: 20
Source: 62.0.0.255
Protocol next hop: 62.0.0.1
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: <Secondary Active Int Ext>
Local AS: 6262 Peer AS: 6262
Age: 2:50 Metric2: 1
Validation State: unverified
Task: BGP_6262.62.0.0.255+179
Announcement bits (1): 0-RZN-VPN-3-evpn
AS path: I (Originator)
Cluster list: 62.0.0.255
Originator ID: 62.0.0.1
Communities: target:6262:111 esi-label:00049660(label 300640) <<<<<<community
Import Accepted
Localpref: 100
Router ID: 62.0.0.255
Primary Routing Table bgp.evpn.0

Так як даний маршрут має в своєму складі нативне розширене ком'юніті, характерне для даного EVPN-домену, то все PE маршрутизатори в evpn-домені імпортують даний маршрут в таблицю маршрутизації відповідної EVPN instance:
bormoglotx@RZN-PE-3> show route table RZN-VPN-3.evpn.0 match-prefix *1:62* detail | match esi
Communities: target:6262:111 esi-label:00049660(label 300640)
Communities: target:6262:111 esi-label:00049680(label 300672)

Навіщо воно потрібно? Розглянемо таку схему:

У даному сценарії ми маємо потенційну L2 петлю, так як якщо BUM трафік від CE1 потрапить на PE2, то буде відправлений всім іншим PE маршрутизаторам, включаючи і PE1. PE1 теж має лінк у бік CE1, від якого було отримано BUM трафік. І якщо PE1 відправить пакет на CE1, то ми отримуємо петлю на 2 рівні, а як ви знаєте, L2 заголовку немає поля ttl. Ситуація, м'яко кажучи, неприємна. Як з цим боротися? У EVPN для цієї мети використовується автоматично вибір Designated Forwarder-а (DF). Як він вибирається ми розглянемо пізніше, а поки поговоримо про його призначення.

DF має виключне право відправляти широкомовні кадри в бік CE маршрутизатора, що знаходиться в ethernet сегменті, для якого даний PE маршрутизатор є DF. Всі інші non-DF маршрутизатори BUM трафік в бік CE маршрутизатора не відправляють.

У нас може бути два сценарії: коли використовується режим Single-Active і коли використовується режим Active-Active (All-Active).

Як неважко здогадатися, в Single-Active режимі у нас працює тільки одне плече, друга знаходиться в резерві. У разі падіння основного плеча, трафік переходить на резервне. Можливо використовувати одне плече для передачі трафіку в одному влане, а друге в другому, але відразу по обох плечах в одному влане трафік йти не може (точніше не має — якщо не так, то пишіть в підтримку, мабуть ви знайшли баг, або, що більш імовірно, у інженера, який збирав схему, криві руки).

У Active-Active або All Active режимі працюють всі лінки від CE до PE, для чого збирається MC-LAG. Принцип роботи технології MC-LAG в даній статті розглядатися не буде: мається на увазі, що читач вже вивчив дану тему.

У першому випадку все просто — вибирається DF, і весь трафік, включаючи і BUM трафік, форвардит тільки він. При цьому ESI label в анонсі відсутня (у всякому разі на обладнанні Juniper її немає), хоча згідно RFC навіть при Single-Active режимі рекомендується використовувати цю мітку, щоб у разі помилки в роботі механізму вибору DF (коли обидва PE маршрутизатора раптом будуть вважати себе DF) не утворилася петля.

При нормальній роботі механізму вибору DF одне плече просто блокується, а значить PE маршрутизатор не вивчає за заблокованого лінком MAC-адреси, отже і не анонсує нічого на інші PE маршрутизатори. Але, навіть якщо якимось хитромудрим шляхом на даний маршрутизатор прилетить BUM трафік, то він буде просто відкинутий.

У другому випадку трохи складніше. Тут так само вибирається DF, який має право відправляти BUM трафік в бік CE маршрутизатора — то є проблеми з трафіком, що йдуть до CE маршрутизатора, немає. Проблеми можуть з'явитися при передачі BUM трафіку від CE маршрутизатора. Так як CE маршрутизатора абсолютно без різниці хто з PE маршрутизаторів DF (точніше сказати CE маршрутизатор думає, що просто підключений до іншого комутатора агрегованим інтерфейсом), то можлива наступна ситуація. Припустимо, що широкомовний пакет від CE1 прилетів на PE1, який не є DF. PE1 отримує пакет та надсилає його всім іншим PE маршрутизаторам, включаючи і PE2. PE2, будучи DF маршрутизатором для даного сегмента, форвардит BUM трафік назад на CE маршрутизатор. Так, отримали петлю. Ось тут-то нам і стане в нагоді ESI-label. Справа в тому, що при відправленні пакета на PE2, PE1 навішує дві мітки: ESI-label (дно міток) і Inclusive Multicast label. PE2 отримує пакет, знімає верхню позначку і виявляє ESI-label, це говорить маршрутизатора про те, що флудити пакет в бік CE1 не треба, так як трафік з цього сегменту і прилетів. Але навіщо ж тоді цей пакет взагалі відправляти на PE2? Справа в тому, що до PE2, крім CE1, від якої було отримано цей трафік, можуть бути підключені інші CE маршрутизатори, які можуть бути зацікавлені в даному трафіку.

Скорочення на схемі:
IM — Inclusive Multicast label
ESI — ESI label
TL — Transport MPLS label


Примітка: PE1 і PE2 безпосередньо з'єднані, тому транспортна мітка при відправці трафіку від PE1 на PE2 не навішується. Якби між ними було б більше одного хопу, то ми б отримали стек з трьох міток.


MAC Mass Withdrawal

Ця функція призначена для тих випадків, коли у нас відвалиться один з лінків, якими підключений multihomed CE-маршрутизатор. Так як у випадку з Active-Active режимом трафік від CE маршрутизатора балансується, то і MAC-адреси будуть вивчені іт обох PE маршрутизаторів. Якщо у нас впав один з лінків, то PE маршрутизатор повинен скасувати всі маршрути даного сегмента, які їм були відправлені. Уявіть, що їх 1000 або більше, тоді ми отримаємо високу утилізацію процесора різким сплеском BGP повідомлень, що може погано позначитися на всьому control-plane. Та й по часу обробити велику кількість Withdrawn повідомлень не так-то просто. Тому PE маршрутизатор отруює Withdrawn повідомлення про скасування раніше відправленого маршруту типу 1, згенерований per-ESI (про це трохи пізніше). Отримавши це повідомлення, інші PE маршрутизатори можуть або очистити все відповідності MAC-label, асоційовані з даним сегментом (ES), або, якщо в даному сегменті є інший маршрутизатор, який здатний форвардить трафік, то використовувати маршрути, отримані від нього (тобто, по суті змінити protocol next-hop). Якщо «помер» останній маршрутизатор в даному сегменті, то очистити таблиці MAC-адрес, пов'язану з даним сегментом.

Як ви розумієте, це необхідно для швидкого перемикання з резерву на бекап.

Aliasing label

І знову ця функція стосується multihoming CE. Трафік від CE маршрутизатора в All-Active режимі повинен балансуватися між усіма лінками. Так як балансування проводиться з якогось алгоритму, відомому тільки самому CE маршрутизатора та його розробнику, то можлива ситуація, коли multihoming CE маршрутизатор буде відправляти весь вихідний трафік тільки через один інтерфейс. В результаті, маршрути типу 2 будуть відправлятися тільки з одного PE маршрутизатора, припустимо що тільки з PE1:

Так як інші маршрутизатори не будуть знати, як дістатися до зазначеного сегмента через PE2, то через нього трафік не піде, що викличе простий одного з плечей між PE і CE маршрутизаторами. Для цього кожен PE маршрутизатор анонсує анонсує Aliasing мітку для свого сегмента ethernet. Так як інші PE маршрутизатори отримують маршрути типу 1, то вони бачать, що PE1 і PE2 мають лінки в одному і тому ж ES і працюють в All-Active режимі. Використовуючи отриману Aliasing мітку, інші PE маршрутизатори можу відправляти пакети на CE маршрутизатор і через PE1 і через PE2, навещивая на пакет, який піде через PE2 замість VPN мітки — Aliasing-мітку, отриману від PE2 в маршруті типу 1, згенерованого per-EVI.

Скорочення на схемі:
AL — Aliasing label
EVPN — EVPN label
TL — Transport MPLS label


На маршрутах типу 1 є прапор, який відповідає за інформування інших PE маршрутизаторів про те, в якому режимі працює даний PE маршрутизатор в даному ethernet сегменті — Single-або All Active-Active. Даний прапор розташована в складі розширеного ком'юніті, який додається до анонсу маршруту типу 1. Якщо прапор піднятий, то маршрутизатор працює в режимі Single-Active (прапор так і називається Single-Active flag), якщо прапор не піднято — то маршрутизатор працює в All-Active режимі. Нижче приклад маршруту, в якому піднято прапор і відсутня позначка:
bormoglotx@RZN-PE-1> show route advertising-протоколу bgp 62.0.0.255 table __default_evpn__.evpn.0 detail match-prefix *112233445566778899aa::*

__default_evpn__.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
* 1:62.0.0.1:0::112233445566778899aa::0/304 (1 entry, 1 announced)
BGP group RR-NODES type Internal
Route Distinguisher: 62.0.0.1:0
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [6262] I
Communities: target:6262:111 esi-label:100000(label 0)

А ось маршрут вже з міткою і не піднятим Single-Active прапором:
bormoglotx@RZN-PE-1> show route advertising-протоколу bgp 62.0.0.255 table __default_evpn__.evpn.0 detail match-prefix *62000000000000000001::*

__default_evpn__.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
* 1:62.0.0.1:0::62000000000000000001::0/304 (1 entry, 1 announced)
BGP group RR-NODES type Internal
Route Distinguisher: 62.0.0.1:0
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [6262] I
Communities: target:100:100 esi-label:000493a0(label 299936)


Маршрут типу 4
Тепер розберемо маршрут типу 4. Цей маршрут потрібен для вибору DF, про призначення якого я писав раніше. Даний маршрут виглядає наступним чином:

bormoglotx@RZN-PE-2> show route table bgp.evpn.0 match-prefix *4:6*

bgp.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

4:62.0.0.1:0::112233445566778899aa:62.0.0.1/304
*[BGP/170] 01:07:57, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.3 via ge-0/0/0.0, Push 299808

Примітно, що даний маршрут не несе ком'юніті, яке сконфигурено на експорт з routing-instance:
bormoglotx@RZN-PE-2> show route table bgp.evpn.0 match-prefix *4:6* detail

bgp.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
4:62.0.0.1:0::112233445566778899aa:62.0.0.1/304 (1 entry, 0 announced)
*BGP Preference: 170/-101
Route Distinguisher: 62.0.0.1:0
Next hop type: Indirect
Address: 0x95c1954
Next-hop reference count: 14
Source: 62.0.0.255
Protocol next hop: 62.0.0.1
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: <Ad Int Ext>
Local AS: 6262 Peer AS: 6262
Age: 1:07:59 Metric2: 1
Validation State: unverified
Task: BGP_6262.62.0.0.255+51796
AS path: I (Originator)
Cluster list: 62.0.0.255
Originator ID: 62.0.0.1
Communities: es-import-target:33-44-55-66-77-88
Import Accepted
Localpref: 100
Router ID: 62.0.0.255
Secondary Tables: __default_evpn__.evpn.0

Дані маршрути використовують нове ком'юніті: es-import-target:XX-XX-XX-XX-XX-XX. Саме ком'юніті генерується з ESI. Для цього з ідентифікатора беруться 48 біт, як це показано нижче:

ESI:
11:22:33:44:55:66:77:88:99:aa

Згенероване ком'юніті:
Communities: es-import-target:33-44-55-66-77-88

Тільки PE маршрутизатори, що мають однакові ESI (точніше однакові біти з 16 по 64 в ідентифікаторі), імпортують даний маршрут. Як бачите, в анонсі немає RT, зазначеного на імпорт або експорт в routing instance. Тобто маршрути типу 4 не видно в таблиці маршрутизації самої EVPN. Їх можна побачити тільки в таблицях bgp.evpn.0 і __default_evpn__.evpn.0.

Якщо у іншого PE маршрутизатора буде ESI, наприклад aaaa334455667788aaaa, то, як не важко здогадатися, їх ком'юніті буде однаково, а значить маршрут теж буде імпортовано. Але не варто панікувати, все вже вкрадено до нас у тілі самого маршруту зазначений повний ідентифікатор ESI і цей маршрут буде імпортований, але проігнорований. Як і RT, es-import-target призначений тільки для фільтрації маршрутів. Нижче представлений сам маршрут типу 4 і його ком'юніті:
bormoglotx@RZN-PE-1> show route table bgp.evpn.0 match-prefix *4:62* detail | match "comm|\/304"
4:62.0.0.2:0::112233445566778899aa:62.0.0.2/304 (1 entry, 0 announced)
Communities: es-import-target:33-44-55-66-77-88

Цікавим випадком є ось такий конфіг:
bormoglotx@RZN-PE-1> show configuration interfaces ae1 | match esi | display set
set interfaces ae1 esi 62:00:00:00:00:00:00:00:00:01
set interfaces ae1 esi all-active

Думаю, ви вже здогадалися, що ми отримуємо в анонсі розширене ком'юніті, що складається з нулів:
bormoglotx@RZN-PE-1> show route advertising-протоколу bgp 62.0.0.255 table __default_evpn__.evpn.0 detail match-prefix *62000000000000000001:6*

__default_evpn__.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
* 4:62.0.0.1:0::62000000000000000001:62.0.0.1/304 (1 entry, 1 announced)
BGP group RR-NODES type Internal
Route Distinguisher: 62.0.0.1:0
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [6262] I
Communities: es-import-target:0-0-0-0-0-0

Не варто думати, що це все зламається. Навіть з таким ком'юніті все буде працювати, але якщо у вас в мережі будуть, наприклад, ESI в діапазоні хх: хх:00:00:00:00:00:00:00:01-хх: хх:00:00:00:00:00:00:99:99, то у всіх маршрутів типу 4 будуть однакові ком'юніті, а значить PE маршрутизатори будуть приймати і встановлювати в таблиці маршрутизації всі маршрути типу 4, навіть якщо вони їм не потрібні. Але думаю, що про це не варто паритися, плюс/мінус 100 маршрутів погоди не зроблять (чому не зроблять — зрозумієте, коли дочитаєте цю статтю до кінця).

Не знаю, чи помітив читач, але в маршрутах типу 1 і 4 RD виглядає дещо дивно. Наприклад, маршрут типу 2 від PE2:
2:62.0.0.2:1::777::aa:bb:cc:00:07:00/304
*[BGP/170] 00:00:18, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.1 via ge-0/0/0.0, Push 299792

А ось маршрут типу 1 з того ж PE2:
1:62.0.0.2:0::112233445566778899aa::0/304
*[BGP/170] 00:00:56, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.1 via ge-0/0/0.0, Push 299792

Від PE2 маршурт типу 1 має RD 62.0.0.2:0, хоча від цього ж PE2 маршрути типу 2 або 3 прилітають з RD 62.0.0.2:1, який і сконфигурен в routing instance. Що відбувається з RD? Для перевірки даного явища створимо два routing instance з типом EVPN і призначимо їм абсолютно різні RD:
bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-3 | match route
route-distinguisher 62.0.0.1:3;

bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-4 | match route
route-distinguisher 9999:99;

Тепер подивимося, з яким RD буде анонсуватися маршрут типу 1:
bormoglotx@RZN-PE-1> show route advertising-протоколу bgp 62.0.0.255 | match "1:6"
1:62.0.0.1:0::112233445566778899aa::0/304
1:62.0.0.1:0::aaaa334455667788aaaa::0/304

RD у маршруті не відповідає сконфигуренному ні на RZN-VPN-3, ні на RZN-VPN-4. Звідки ж це RD береться? JunOS генерує його автоматично з router-id або loopback адреси. Причому перше значення має пріоритет. Наприклад, зараз маємо router-id:
bormoglotx@RZN-PE-1> show configuration routing-options router-id
router-id 62.0.0.1;

І це значення береться як перша частина RD, а друга виставляється в нашому випадку в нуль. Давайте пом'янемо router id:
bormoglotx@RZN-PE-1> show configuration routing-options router-id
router-id 62.62.62.62;

Дивимося, які тепер віддаються маршрути:
bormoglotx@RZN-PE-1> show route advertising-протоколу bgp 62.0.0.255 | match "1:6"
1:62.62.62.62:0::112233445566778899aa::0/304
1:62.62.62.62:0::aaaa334455667788aaaa::0/304

Як бачите JunOS сам згенерував RD. Що буде якщо ми не вкажемо router-id? Давайте перевіримо. Але ускладнимо завдання, навісивши на лупбек ще пару адрес:
bormoglotx@RZN-PE-1> show configuration interfaces lo0
description "BGP & MPLS router-id";
unit 0 {
family inet {
address 10.1.1.1/32;
address 62.0.0.1/32;
address 62.62.62.62/32;
}
family iso {
address 49.0000.0620.0000.0001.00;

Дивимося тепер:
bormoglotx@RZN-PE-1> show route advertising-протоколу bgp 62.0.0.255 | match " 1:(1/6)"
1:10.1.1.1:0::112233445566778899aa::0/304
1:10.1.1.1:0::aaaa334455667788aaaa::0/304

JunOS вибрав найменший IP-адреса лупбека і використовував його як router-id. Це відбувається тому, що даний маршрут типу 1 сгенеирирован per-ESI. Якщо маршрут буде генеруватися per-EVI, то у нього буде нативний RD инстанса, з якого даний маршрут анонсується. А ось маршрут типу 4 завжди буде мати RD, унікальний на маршрутизатор, так як він завжди генерується per-ESI.

Генерація маршруту per-ESI має деяку особливість. Так як ідентифікатор ESI конфігурується на фізичному інтерфейсі, то якщо у нас буде наприклад 10 логічних юнітів (можна сказати вланов) на даному інтерфейсі і всі в різних EVPN-інстансах, то ми отримаємо, що в різних інстансах буде згенерований один і той же маршрут типу 1. Навіщо генерувати 10 однакових маршрутів (різниця в них буде тільки в RT), якщо можна згенерувати тільки один і навісити на нього RT-ки всіх зацікавлених у даному маршруті инстансов?

Давайте подивимося, як це працює на прикладі. Ось конфігурація ESI на фізичному інтерфейсу:
bormoglotx@RZN-PE-1> show configuration interfaces ge-0/0/2 | match esi | display set
set interfaces ge-0/0/2 esi 00:00:00:00:00:00:00:00:00:07
set interfaces ge-0/0/2 esi single-active

Цей інтерфейс використовується двома инстансами з типом evpn:
bormoglotx@RZN-PE-1> show configuration routing-instances | display set | match ge-0/0/2.
set routing-instances RZN-VPN-1 interface ge-0/0/2.0
set routing-instances eVPN-test interface ge-0/0/2.200

Подивимося, які RT відповідають даним инстансам (я видалив політики і прописав RT з допомогою vrf-target для наочності):
bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-1 | match target
vrf-target target:62:1;

bormoglotx@RZN-PE-1> show configuration routing-instances eVPN-test | match target
vrf-target target:62:2;

А тепер подивимося маршрут типу 1, анонсований на рефлектор:
bormoglotx@RZN-PE-1> show route advertising-протоколу bgp 62.0.0.255 table __default_evpn__.evpn.0 match-prefix *1:6*:07:* detail

__default_evpn__.evpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
* 1:62.0.0.1:0::07::0/304 (1 entry, 1 announced)
BGP group RR-NODES type Internal
Route Distinguisher: 62.0.0.1:0
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [6262] I
Communities: target:62:1 target:62:2 esi-label:100000(label 0)

Як бачите, у маршруту дві RT-ки: target:62:1, яка відповідає RZN-VPN-1 і target:62:2, відповідна eVPN-test. Ця функція зменшує час збіжності. Якщо даний лінк відвалиться, то він відвалиться у всіх инстансов, до яких він прикріплений. У нашому випадку замість 2-x BGP Withdrawn повідомлень, відлетить тільки одне, але з двома RT.

Примітка: маршрути типу 1 і 4, якщо буде бажання у читача будемо розглядати окремо, в окремій статті, присвяченій EVPN multihoming.


Механізм вибору DF
Механізм вибору DF дозволяє вибрати різний DF для різних вланов, тим самим можна, наприклад, домогтися балансування трафіку між різними bridge-доменами — трафік різних вланов буде йти з різних лінками в бік CE маршрутизатора всередині одного EVPN-instance.

Маршрутизатор відправляє анонс маршруту типу 4 з зазначенням ESI і відповідним ком'юніті і запускає таймер вибору DF. За замовчуванням цей таймер встановлений в 3 секунди. Його можна змінити, але він повинен бути однаковий на всіх PE маршрутизаторах сегмента — інакше алгоритм може відпрацювати некоректно.

По закінченню таймера всі PE маршрутизатори, які беруть участь у виборі DF, складають повний список всіх PE маршрутизаторів сегмента починаючи з самого маленького адреси. Кожному з PE маршрутизаторів в списку присвоюється номер (i), починаючи з нуля.

Після цього вираховується номер DF за формулою V mod N = i, де V — номер влана, а N кількість PE маршрутизаторів в сегменті. Той PE маршрутизатор, номер якого буде результатом обчислення і стає DF даного сегменту в даному влане.

Спробуємо вирахувати DF для влана 777 якщо у нас буде тільки 2 PE маршрутизтора з адресами 62.0.0.1 і 62.0.0.2.

Обидва PE маршрутизатора складуть такий список
62.0.0.1 i=0
62.0.0.2 i=1

Так як влан у нас 777, то V=777, а N=2 (так як у нас всього два маршрутизатора в сегменті). Тепер вважаємо 777 mod 2 = 1. Значить DF у нас 62.0.0.2.

Тепер збільшимо число PE маршрутизаторів в сегменті до 3 і ще раз порахуємо.
62.0.0.1 i=0
62.0.0.2 i=1
62.0.0.3 i=2

777 mod 3 = 0, значить DF 62.0.0.1.

Як неважко здогадатися, якщо у нас в сегменті буде два влана наприклад 777 778 і два PE маршрутизатора, то в 777 влане DF стане PE1, а в 778 PE2.

Для прикладу подивимося, хто в вказаною вище схемою буде DF при vlan id 777:
bormoglotx@RZN-PE-2# run show evpn instance RZN-VPN-3 extensive | match "vlan|forward"
VLAN ID: 777
Designated forwarder: 62.0.0.2
Backup forwarder: 62.0.0.1

Тепер поміняємо номер влана на 778 та подивимося, що зміниться DF:
bormoglotx@RZN-PE-2# run show evpn instance RZN-VPN-3 extensive | match "vlan|forward"
VLAN ID: 778
Designated forwarder: 62.0.0.1
Backup forwarder: 62.0.0.2

Як бачите механізм працює.

L3-функціонал в evpn
В даний момент ми розібралися, які існують маршрути в EVPN і як буде передаватися трафік усередині одного bridge-домену. Це звичайно добре, але адже ця технологія призначена для з'єднання датацентрів, а в них, як правило, не один влан, як у звичайного клієнта, і логічно, що між ними (вланами) повинен ходити трафік. Та й зв'язок датацентру з зовнішнім світом теж необхідна. Зараз ми будемо розбирати, як же працює маршрутизація пакетів між різними вланами (bridge-доменами).

IRB synchronization
Але перед тим, як пірнути з головою в дивний, але цікавий світ інтегрованої в EVPN маршрутизації, висвітлимо дуже важливий пункт — синхронізація дефолтних шлюзів. Адже ми досі не знаємо, навіщо ж до анонсів IRB-інтерфейсів додається default gateway community. Не для краси же. Думаю, що виходячи з назви даного пункту, ви вже здогадалися що це необхідно для синхронізації дефолтних шлюзів. Що таке синхронізація, як вона відбувається і навіщо потрібна? Давайте розбиратися.

Для початку подивимося всі MAC-адреси на PE1,2 і 3, які навішені на їх IRB-інтерфейси. По порядку, PE1:
bormoglotx@RZN-PE-1> show interfaces irb.777 | match mac
MAC: 02:00:00:00:07:77

bormoglotx@RZN-PE-1> show interfaces irb.1777 | match mac
MAC: 02:00:00:00:17:77

На PE1 mac адреси irb интрефейсов сконфігуровані вручну. Тепер перейдемо до PE2:
bormoglotx@RZN-PE-2> show interfaces irb.777 | match mac
MAC: 02:00:00:02:07:77

bormoglotx@RZN-PE-2> show interfaces irb.1777 | match mac
MAC: 02:00:00:02:17:77

І тут я дозволив собі самостійно призначити адреси на IRB-інтерфейси.
Ну і подивимося на PE3:
bormoglotx@RZN-PE-3> show interfaces irb | match curr
Current address: 00:05:86:71:96:f0, Hardware address: 00:05:86:71:96:f0

Тут MAC страшніше, так як я його залишив таким, яким він зашитий в обладнання.

Всі PE маршрутизатори анонсують MAC+IP маршрут до свого або своїх дефолтних шлюзів (irb.777 і irb.1777). Коли PE маршрутизатор отримує маршрут MAC+IP, позначений default gateway community, то він починає сприймати отриманий MAC-адресу віддаленого IRB-інтерфейсу, як свій власний адресу. Адже якщо є інтерфейси, на яких кілька IP-адрес і один MAC, то чому не може бути зворотного — один IP і кілька MAC-адрес? Синхронізація дефолтних шлюзів буває двох видів: автоматичне і ручне. Автоматичну синхронізацію ми зараз розглянемо, до ручної повернемося трохи пізніше.

Подивитися які адреси використовуються PE маршрутизатором можна такою командою (перевіримо на PE1):
bormoglotx@RZN-PE-1> show bridge evpn peer-gateway-macs

Routing instance : RZN-VPN-1
Bridging domain : VLAN-1777, VLAN : 1777
Installed GW MAC addresses:
02:00:00:02:17:77
Bridging domain : VLAN-777, VLAN : 777
Installed GW MAC addresses:
00:05:86:71:96:f0
02:00:00:02:07:77

На PE1 два bridge-домену, для кожного кожного з яких синхронізація дефолтних шлюзів здійснюється індивідуально. На відміну від PE1, на PE3 тільки один bridge-домен і один IRB-інтерфейс. Відповідно синхронізація проводиться тільки для bridge-домену VLAN-777:
bormoglotx@RZN-PE-3> show evpn peer-gateway-macs

Routing instance : RZN-VPN-1
Bridging domain : __RZN-VPN-1__, VLAN : 777
Installed GW MAC addresses:
02:00:00:00:07:77
02:00:00:02:07:77

У підсумку виходить наступна картина — irb.777 на PE1 повинен відгукуватися на три MAC-адреси:
  • 00:05:86:71:96:f0 (PE3)
  • 02:00:00:02:07:77 (PE2)
  • 02:00:00:00:07:77 (native PE1)
І, природно, ми зараз перевіримо, що IRB-інтерфейс буде відповідати на пакети, адресовані не на його власний MAC. Зробимо це по-селянськи — просто пропишемо статичну arp запис на CE маршрутизаторі на потрібний нам MAC-адресу. Так як CE1-1 підключений до PE1 в bridge-домен VLAN-777, то при резолве MAC-адреси irb.777 він отримує нативний MAC-адресу irb.777- 02:00:00:00:07:77. Ми створимо на CE1-1 статичну arp запис, яка буде вказувати, що MAC-адресу irb.777 на PE1 не 02:00:00:00:07:77, а 02:00:00:02:07:77 (який насправді належить irb.777 на PE2):
RZN-CE1-SW1#sh start | i arp
arp 10.0.0.254 0200.0002.0777 ARPA

RZN-CE1-SW1#show arp | i 10.0.0.254
Internet 10.0.0.254 - 0200.0002.0777 ARPA

Логічно припустити, що трафік піде на PE2, так як зазначений на CE1-1 MAC-адреса відповідає irb.777 на PE2. Для того, щоб перевірити куди ж піде трафік, навесим на IRB-інтерфейси PE-шек такі фільтри:
[edit]
bormoglotx@RZN-PE-2# show | compare
[edit interfaces irb unit 777 family inet]
+ filter {
+ input irb777-counter;
+ }
[edit interfaces IRB unit 1777 family inet]
+ filter {
+ input irb1777-counter;
+ }
[edit]
+ firewall {
+ family inet {
+ filter irb777-counter {
+ term 1 {
+ then {
+ count irb777;
+ accept;
+ }
+ }
+ }
+ filter irb1777-counter {
+ term 1 {
+ then {
+ count irb1777;
+ accept;
+ }
+ }
+ }
+ }
+ }

Як ви можете помітити, фільтри просто вважають, що потрапило на IRB-інтерфейс і пропускають весь трафік. В даний момент часу і на PE1 і на PE2 лічильники по нулях.

На PE1:
bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777

Filter: irb777-counter
Counters:
Name Bytes Packets
irb777 0 0


На PE2:
bormoglotx@RZN-PE-2> show firewall filter irb777-counter counter irb777

Filter: irb777-counter
Counters:
Name Bytes Packets
irb777 0 0

Отже, запустимо 33 icmp запиту до 10.0.0.254 з CE1-1 (чому 33? Щоб ніхто не здогадався!):
RZN-CE1-SW1#ping 10.0.0.254 repeat 33
Type escape sequence to abort.
Sending 33, 100-byte ICMP Echos to 10.0.0.254, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (33/33), round-trip min/avg/max = 1/2/6 ms

Як ви пам'ятаєте, CE1-1 вважає, що MAC-адресу шлюзу за замовчуванням не локальний мак irb.777 PE1, а MAC irb.777 PE2, це дуже важливо.

Дивимося що у нас з лічильником на PE1:
bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777

Filter: irb777-counter
Counters:
Name Bytes Packets
irb777 3300 33

Опа, всі 33 пакету були прийняті локальним IRB-інтерфейсом. Давайте подивимося, що у нас коїться з лічильником на PE2:
bormoglotx@RZN-PE-2> show firewall filter irb777-counter counter irb777

Filter: irb777-counter
Counters:
Name Bytes Packets
irb777 0 0

Все по нулях. Трафік туди просто не відправлявся і оброблявся локальним IRB-інтерфейсом PE1.

Наведу пару скрінів з Wireshark-а.
Ось пакет від CE1-1 до PE1:

Як destination не вказано MAC локального інтерфейсу irb.777 на PE1, а MAC-адресу irb.777 PE2. Але ось що примітно: подивимося, з якого адреси прилітає відповідь від PE1 на CE1-1:

Відповідь все-таки PE1 шле з нативного MAC-адреси irb.777. Тобто, як ви розумієте, irb.777 приймає тільки пакети, адресовані на MAC-адреси інтерфейсів irb.777 (PE2 і PE3), але як сорс адресу при відправленні будь-якого пакету чужі MAC-адреси PE1 не використовує. Це дуже важливо, так як, наприклад, при резолве адреси дефолтного шлюзу, IRB-інтерфейс буде відповідати і вказувати тільки свій нативний MAC-адресу.

Для чистоти експерименту вкажемо CE1-1, що тепер MAC-адресу irb.777 дорівнює MAC-адресу інтерфейсу irb.777 на PE3:
RZN-CE1-SW1#sh start | i arp
arp 10.0.0.254 0005.8671.96f0 ARPA

RZN-CE1-SW1#show arp | i 10.0.0.254
Internet 10.0.0.254 - 0005.8671.96f0 ARPA

Природно, на irb.777 PE3 я також навісив даний фільтр. Запускаємо пінг і перевіряємо:
RZN-CE1-SW1#ping 10.0.0.254 repeat 27
Type escape sequence to abort.
Sending 27, 100-byte ICMP Echos to 10.0.0.254, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (27/27), round-trip min/avg/max = 1/2/5 ms

Заглянемо в WIreshark, щоб упевнитися, що пакет з CE був відправлений з необхідним нам destination MAC-адресою:

Дивимося лічильник на PE1:
bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777

Filter: irb777-counter
Counters:
Name Bytes Packets
irb777 6000 60

irb.777 на PE1 обробив ще 27 пакетів, в той час, як на PE3 лічильник так і стоїть на нулі:
bormoglotx@RZN-PE-3> show firewall filter irb777-couter counter irb777

Filter: irb777-couter
Counters:
Name Bytes Packets
irb777 0 0

Це ми розглянули механізм автоматичної синхронізації. Тепер перейдемо до ручної синхронізації.

Взагалі ручна синхронізація — це просто відключення автоматичної синхронізації, внаслідок того, що вона просто не потрібна. Чому? Ми зараз конфигурили на всіх PE-ках однакові IP-адреси на IRB-інтерфейси, але різні MAC-в. Другий спосіб налаштування IRB-інтерфейсів в EVPN (він же і рекомендований) — однакові IP і MAC-адреси на всіх IRB-інтерфейсах одного і того ж bridge-домену. При такому розкладі IRB-інтерфейси вже синхронізовані, так як скрізь однакові MAC. Тому можна дати команду default gateway do-not-advertise і тим самим заборонити генерацію маршрутів MAC+IP для IRB-інтерфейсів.

Великим плюсом синхронізації дефолтних шлюзів є те, що це дозволяє нам переміщати віртуальні машини між датацентрами без перерви сервісу (при виконанні певних умов, таких як, затримка менш 100мс між точками А (звідки переміщається машина) і Z (куди переміщується машина) і т д). Після переміщення віртуальної машини вона може продовжувати відправляти пакети в зовнішню мережу на адресу дефолтного шлюзу, що знаходиться в її arp — тобто навіть очищати кеш arp нам не доведеться. Природно, буде створений новий BGP Update про те, що тепер цей MAC в іншому місці. Взагалі по темі VM Mobility в EVPN необхідно писати окрему чималеньку статтю і, тому, висвітлювати її зараз ми не будемо.

Сподіваюся, що все вищесказане відклалося в пам'яті, так як без цього не буде зрозумілий механізм роботи L3 інтерфейсів в EVPN. Тепер перейдемо безпосередньо до передачі пакетів між bridge-доменами.

Маршрутизація пакетів між bridge-доменами
Беремо за основу те, що всередині одного bridge-домену пакети комутуються, а між різними bridge-доменами (або при виході в зовнішню мережу) маршрутизуються. Щоб трафік міг маршрутизироваться, нам треба додати в наші instance роутинговые інтерфейси. В JunOS роутинговым інтерфейсом є IRB (Integrated Routing and Bridging). Даний інтерфейс не є тегированным, і з попадає на нього трафіку знімається vlan тег. Як і звичайний інтерфейс на JunOS, IRB має юніти. Номер юніта в IRB-інтерфейсі (як, власне, і номери юнітів на фізичних інтерфейсах) не означає, що цей інтерфейс відноситься до якогось певного влану. Наприклад, інтерфейс irb.777 не обов'язково повинен ставитися до влану 777. Але все ж зручніше читати конфігураційні файли, коли номер влана і номер IRB юніта в одному bridge-домені однакові.

Для тестування будемо використовувати ту ж лабу, що і до цього, але додамо в неї роутинговые інтерфейси і пару CE маршрутизаторів, як це зазначено на схемі:

Для простоти у статті я не буду вказувати хостнеймы, як вони зазначені на схемі, а буду використовувати скорочення:
RZN-CE1-SW1 ⇒ CE1-1
RZN-CE1-SW2 ⇒ CE1-2
RZN-CE2-SW1 ⇒ CE2-1
RZN-CE2-SW2 ⇒ CE2-2
RZN-CE2-SW1 ⇒ CE3


Схема на перший погляд має, м'яко кажучи, дивний вигляд — на всіх PE маршрутизаторах однакові IRB-інтерфейси. Думаю, що у вас повинні виникнути як мінімум два питання — як це працює і навіщо це потрібно. Давайте спробуємо відповісти на ці питання.

Отже, поїхали. Для початку згадаємо, як працює основний (або дефолтний, кому як подобається) шлюз у вже нами вивчений VPLS. У нас є якийсь PE маршрутизатор, на якому ми створюємо IRB-інтерфейс. Цей же IRB-інтерфейс ми додаємо в який-небудь VRF або випускаємо GRT, якщо є така необхідність. Можливо, що у нас таких маршрутизаторів більше одного, і ми використовуємо vrrp для резервування основного шлюзу, але майстром все одно буде хтось один. Тобто в VPLS у нас є тільки один вихід в зовнішню мережу, розташований на якомусь PE маршрутизаторі, що входить в VPLS-домен. Весь трафік, спрямований назовні, з усіх інших PE маршрутизаторів буде йти через дану PE-ку, так як вона є єдиним виходом у зовнішню мережу (це, якщо не застосовувати милиці у вигляді навмисно зламаного vrrp). Мінуси даної схеми очевидні — PE-ке, на якій буде знаходиться дефолтний шлюз, доведеться перетравлювати весь вихідний трафік VPLS-домену, спрямований у зовнішню мережу і весь вхідний в VPLS домен трафік із зовнішнього світу. А вже, якщо ця PE-ка відмовить, і у нас не зібраний VRRP, то ми взагалі будемо відрізані від інших мереж зовнішнього світу. Як не дивно, але у даної схеми є і плюси — це простота. Будь-якому інженеру описане вище рішення буде зрозуміло і в плані конфігурації і в плані траблшутинга, чого я не можу сказати про рішення, що використовується в EVPN.

Крім описаних вище недоліків, є ще один важливий нюанс — в описаній вище схемі ми ніяк не можемо оптимізувати L3 трафік, що йде всередину VPLS-домену або виходить з нього.

EVPN пропонує нам зовсім іншу схему використання L3 інтерфейсів. Якщо CE маршрутизатор хоче мати вихід в зовнішню мережу, інші вланы чи інтернет, то на PE-ке, до якої підключено даний CE маршрутизатор повинен бути налаштований дефолтний шлюз у вигляді L3 інтерфейсу. Природно, на кожен влан повинен бути свій шлюз.

Примітно те, що в RFC явно не написано, що кожен PE маршрутизатор повинен мати IRB-інтерфейс для можливості виходу в зовнішню мережу. А ось у документації Juniper по налаштуванню EVPN є ось такі рядки:

Initially when EVPN and Layer 3 gateway functionality were conceived, some basic assumptions were made, and RFC вимога were to be followed.

These were:

1. All PE's for an EVPN instance must have an IRB configured.

2. All PE's should have the same IP address for the GW. From the RFC, if there is a discrepancy between the GW IP addresses, an error is logged. Though it must be noted that different addresses can still be configured as both MAC/IP for advertisement to remote provider edge (PE) devices and are installed on all participating PE devices.


У підсумку, якщо ви використовуєте EVPN/MPLS, то конфігурувати L3 інтерфейс на кожному PE маршрутизаторі обов'язково, інакше цей сайт просто не вийде з влана. А ось для EVPN/VXLAN цієї вимоги немає (це, до речі, є істотною відмінністю EVPN/VXLAN від EVPN/MPLS)

Повернемося до нашої схеми. У нас два bridge-домену — це домен VLAN-777 і VLAN-1777. У влане 1777 у нас два CE маршрутизатора — це CE1-2 і CE2-2, у влане 777 три маршрутизатора: CE1-1, CE2-1 і CE3. Природно, я хочу мати зв'язність між усіма CE маршрутизаторами, зазначеними на схемі.

Але щоб зв'язати кілька bridge-доменів між собою додавання одного L3 інтерфейсу в routing-instance EVPN недостатньо. Необхідно ще створити на кожному PE маршрутизаторі routing-instance з типом VRF (яка використовується для L3VPN), в яку необхідно помістити наші L3 інтерфейси. Таким чином ми з'єднаємо два инстанса: VRF і EVPN (або virtual-switch):

Примітка: можна випустити наш EVPN і в GRT, але, мені здається, що це не дуже гарна ідея. У всякому випадку це підтримується, а реалізовувати цей функціонал чи ні — вирішує кожен сам.


Як було сказано вище, нам необхідно сконфігурувати routing instance з типом VRF і пов'язати її з EVPN. Нижче представлена конфігурація з PE2 — virtual switch і пов'язаний з ним VRF:
bormoglotx@RZN-PE-2> show configuration routing-instances RZN-VPN-1
instance-type virtual-switch;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
route-distinguisher 62.0.0.2:1;
vrf-import VPN-1-IMPORT;
vrf-export VPN-1-EXPORT;
protocols {
evpn {
extended-vlan-list [ 777 1777 ];
}
}
bridge-domains {
VLAN-1777 {
vlan id 1777;
routing-interface irb.1777;
}
VLAN-777 {
vlan id 777;
routing-interface irb.777;
}
}

bormoglotx@RZN-PE-2> show configuration routing-instances VRF-VPN-1
instance-type vrf;
interface irb.777;
interface irb.1777;
route-distinguisher 62.0.0.2:10002;
vrf-target {
import target:6262:10001;
export target:6262:10001;
}
vrf-table-label;

Такі ж VRF піднімаються на інших PE маршрутизаторах, за винятком того, що в VRF на PE3 немає інтерфейсу irb.1777.

Ми вже знаємо, що маршрут типу 2 опціонально може містити IP-адреса хоста. Сам маршрут MAC+IP ми вже бачили: якщо пам'ятаєте, то при додаванні в EVPN IRB-інтерфейсу у нас генерувалися два маршрути: просто MAC-адресу IRB-інтерфейсу, щоб можна було до нього дістатися всередині bridge-домену не вдаючись до маршрутизації і MAC+IP, до якого прикріплялося ком'юніті default gateway. Другий маршрут був необхідний для роутінга і є arp записом. Але MAC+IP маршрут генерується не тільки для дефолтного шлюзу. Такий маршрут до будь-якого хоста буде з'являтися у тому випадку, якщо це хост спробує вийти в зовнішню мережу або інший влан.

Що треба хосту, щоб вийти з влана? Вірно — необхідно відправити пакет на шлюз за замовчуванням. У нашому випадку роль шлюзу для bridge-домену грає IRB-інтерфейс PE маршрутизатора. А щоб послати пакет на IRB-інтерфейс, хосту треба знати MAC-адресу цього IRB-інтерфейсу. Тому, для початку хост посилає arp запит на резолв MAC-адреси IRB-інтерфейсу. В той момент, коли IRB-інтерфейс отримує arp запит від хоста (в нашому випадку CE маршрутизатора), який до цього PE маршрутизатора безпосередньо підключений*, він і генерує два маршрути типу 2: MAC-адресу та MAC+IP — і розсилає їх по BGP у вигляді EVPN маршрутів. Крім цього, так як цей маршрут у вигляді звичайного IPv4 префікса з маскою /32 з'явиться ще і в зв'язаному з EVPN VRF-е як локальний маршрут, то за BGP відправляється ще й vpnv4 маршрут до даного хоста (навіщо потрібна друга — зрозумієте пізніше). Власне, вищеописане — це головний принцип роботи EVPN при маршрутизації між вланами, який і дозволяє оптимізувати проходження трафіка між різними bridge-доменами або між EVPN і зовнішніми мережами.

Саму таблицю arp записів можна подивитися на кожному PE маршрутизаторі. Для прикладу на PE2:
bormoglotx@RZN-PE-2> show bridge evpn arp-table
INET MAC Logical Routing Bridging
address address interface instance domain
10.0.1.2 aa:bb:cc:00:0a:00 irb.1777 RZN-VPN-1 VLAN-1777
10.0.1.22 aa:bb:cc:00:0a:00 irb.1777 RZN-VPN-1 VLAN-1777
10.0.1.222 aa:bb:cc:00:0a:00 irb.1777 RZN-VPN-1 VLAN-1777
10.0.0.2 aa:bb:cc:00:07:00 irb.777 RZN-VPN-1 VLAN-777

*10.0.1.22 і 10.0.1.222 — це secondary адреси CE2-2, накладених в ході тестування для зняття дампів.

У висновку вказується, з якого інтерфейсу був зроблений arp запит, в якому bridge-домені і routing instance. Ця інформація буде корисна, так як один і той же MAC-адресу може бути в різних вланах або, як у наведеному вище висновку — на одному фізичному інтерфейсі може бути кілька адрес, і, природно, у них буде один MAC-адресу. До всіх цих хостів ви обов'язково знайдете маршрут в VRF:
bormoglotx@RZN-PE-2> show route table VRF-VPN-1.inet.0 active-path | match "(10.0.0.2\/)|(10.0.1.2{1,3}\/)"
10.0.0.2/32 *[EVPN/7] 00:09:38
10.0.1.2/32 *[EVPN/7] 09:11:03
10.0.1.22/32 *[EVPN/7] 02:02:40
10.0.1.222/32 *[EVPN/7] 01:54:26

Тепер перейдемо від теорії до практики: розберемо, як трафік буде йти від CE3 до CE1-2. Перший знаходиться у влане 777 і має адресу 10.0.0.3, другий у влане 1777 і має адресу 10.0.1.1. Нагадую, що на PE3 немає локального інтерфейсу irb.1777.

Отже, CE3 хоче відправити пакет на CE1-2, який знаходиться в іншій мережі. CE3 не знає мак адресу основного шлюзу, тому робить arp запит на резолв адреси 10.0.0.254, який для даного CE маршрутизатора є основним шлюзом в інші мережі. Природно, на CE3 (та й на всіх інших CE-маршрутизаторах прописаний дефолтний маршрут у бік IRB-інтерфейсу). Так як PE3 отримує arp запит від CE3, адресований його локального IRB-інтерфейсу, то PE3 генерує MAC+IP маршрут і відправляє його на інші PE-ки. Крім цього, так як маршрут 10.0.0.3/32 з'явився в VRF у вигляді локального маршруту, то PE3 анонсує ще й BGP vpnv4 маршрут:
bormoglotx@RZN-PE-3> show route advertising-протоколу bgp 62.0.0.255 | match 10.0.0.3
* 10.0.0.3/32 Self 100 I
2:62.0.0.3:1::777::aa:bb:cc:00:05:00::10.0.0.3/304

Примітка: як правило, маршрут типу 2, що містить MAC-адресу, буває вже згенерований раніше. В такому випадку даний маршрут повторно не генерується, щоб уникнути флапов. PE маршрутизатор просто генерує тільки MAC+IP анонс. Це не складно побачити на практиці, подивившись час життя цих маршрутів — воно, як правило, буде різним.
Рухаємося далі. CE3 тепер знає MAC-адресу дефолтного шлюзу, а значить знає, куди треба слати пакет, адресований CE1-1 (мається на увазі MAC-адресу L2 заголовка). CE3 формує пакет і L3 заголовку адресою призначення вказує адресу CE1-1 (10.0.1.1), що походить адресою вказує власний адресу CE3 (10.0.0.3). В L2 заголовку адресою призначення вказує мак адресу irb.777, а виходить адресою — власний MAC-адресу (адресу інтерфейсу в бік PE маршрутизатора).

Пакет прилітає на PE3. Так як MAC-адресу призначення — локальний інтерфейс irb.777, то PE3 знімає L2 заголовок і робить IP lookup в таблиці маршрутизації VRF, яка пов'язана з нашою EVPN-instance. В даний момент в даної таблиці чотири активних маршруту:
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 active-path

VRF-VPN-1.inet.0: 4 destinations, 9 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/24 *[Direct/0] 00:20:05
> via irb.777
10.0.0.3/32 *[EVPN/7] 00:00:06
> via irb.777
10.0.0.254/32 *[Local/0] 04:04:34
Local via irb.777
10.0.1.0/24 *[BGP/170] 02:19:20, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)

10.0.0.0/24 і 10.0.0.3/32 локальні для PE3 (другий якраз був згенерований при arp-запит на irb.777), а ось маршрут до мережі 10.0.1.0/24 ми отримуємо за BGP від PE1 і PE2.

Так як на PE1 і PE2 створений такий же VRF, як і на PE3 (з однаковими RT), то PE3 приймає всі анонси від PE1 і PE2. На них (PE1 і PE2), в свою чергу в даний VRF додано інтерфейс irb.1777, а значить вони будуть анонсувати маршут до мережі 10.0.1.0/24 по BGP у вигляді звичайного vpnv4 маршруту, який і буде імпортовано в таблицю маршрутизації VRF на PE3. У висновку вище показані тільки активні маршрути, тому ми бачимо тільки один анонс, всього їх, природно, два — один отриманий від PE1, другий — від PE2. Кращим обраний маршрут від PE1, так як він має менший router-id, а всі інші параметри маршрутів, отриманих від обох PE-шек повністю ідентичні. Який маршрут буде обраний кращим — від PE1 або PE2 — абсолютно неважливо (наприклад якщо у нас буде 10 сайтів, то ми будемо отримувати 9 маршрутів до однієї мережі, але вибереться все одно тільки один), так як все одно при отриманні BUM трафіку bridge-домену VLAN-777, PE1 буде флудити його у всі інтерфейси bridge-домену VLAN-1777. Чому — з'ясуємо далі.

В ході IP lookup-а, PE3 поимает, що префікс 10.0.1.0/24 перебуває на PE1, тому PE3 відправляє пакет через L3VPN на PE1:
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.0/24 active-path

VRF-VPN-1.inet.0: 4 destinations, 9 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/24 *[BGP/170] 02:23:12, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)

Можливий варіант, коли на PE3 буде включена балансування трафіку по еквівалентним шляхах (ECMP) і в FIB буде встановлено два маршрути, а значить трафік може піти і на PE2, але це, як я написав вище, не важливо — головне щоб пакет потрапив на PE маршрутизатор, на якому є локальний bridge-домен VLAN-1777 (по-іншому бути і не може, якщо, звичайно, у вас не налаштований якийсь жорсткий лікінг між VRF-ми). Якщо такого bridge-домену на PE-ке не буде, то не буде і від неї анонсу до мережі 10.0.1.0/24.

PE1 приймає пакет від PE3 в VRF, робить IP lookup і розуміє, що пакет призначений bridge-домену VLAN-1777:
bormoglotx@RZN-PE-1> show route table mpls.0 label 16

mpls.0: 22 destinations, 23 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

16 *[VPN/0] 02:25:02
to table VRF-VPN-1.inet.0, Pop

Так як PE1 не знає MAC-адреси хоста 10.0.1.1, то проводиться флуд arp запит у всі інтерфейси bridge-домену VLAN-1777 на резолв цієї адреси. Якщо бути точніше, одна копія пакету відправляється на CE1-2, а друга, з inclusive multicast міткою на PE2. А як же функція split horizon? Адже пакет, отриманий від PE маршрутизатора, не повинен відправлятися на інші PE маршрутизатори. А тут за фактом ми його порушуємо без докорів совісті. Справа в тому, що даний пакет прийшов, L3VPN (тобто по суті з якоїсь зовнішньої мережі по відношенню до EVPN на PE1), тому правило split-horizon тут не працює. Але ми то знаємо що пакет прилетів з EVPN — чи не виникне широкомовного шторму? Пакет хоч і прилетів з evpn, але з іншого широкомовного домену (CE3 знаходиться під влане 777, а CE1-2 під влане 1777). Так як це різні bridge-домени, то і широкомовного шторму між ними виникнути не може — пакети між bridge-доменами маршрутизуються.

Так як CE1-2 хост призначення і підключений до PE1, то він відповідає на даний arp запит. Як ми пам'ятаємо, після отримання arp-а, адресованого IRB-інтерфейсу від будь-якого хоста, PE маршрутизатор повинен згенерувати маршрут типу 2 MAC+IP. У зв'язку з цим, PE1 генерує MAC+IP і vpnv4 маршрут:
bormoglotx@RZN-PE-3> show route table RZN-VPN-1.evpn.0 match-prefix *10.0.1.1*

RZN-VPN-1.evpn.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2:62.0.0.1:1::1777::aa:bb:cc:00:09:00::10.0.1.1/304
*[BGP/170] 00:02:46, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 299792

bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.1/32

VRF-VPN-1.inet.0: 5 destinations, 10 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.1/32 *[BGP/170] 00:02:48, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299792(top)

Тепер у PE1 є маршрут MAC+IP до хоста 10.0.0.3 в таблиці маршрутизації EVPN і 10.0.0.3/32 в таблиці маршрутизації VRF. Аналогічно і з боку PE3: маршрут до хоста 10.0.1.1/32 є в таблиці маршрутизації epn і VRF. Виходить, що тепер обміну пакетами між CE3 і CE1-2 нічого не перешкоджає. Але є один нюанс. Давайте подивимося таблицю маршрутизації в VRF на PE1:
bormoglotx@RZN-PE-1> show route table VRF-VPN-1.inet.0 10.0.0.3/32

VRF-VPN-1.inet.0: 7 destinations, 15 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.3/32 *[EVPN/7] 00:24:37, metric2 1
> to 10.62.0.1 via ge-0/0/0.0, Push 300352, Push 299792(top)
[BGP/170] 00:24:37, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.1 via ge-0/0/0.0, Push 16, Push 299792(top)

На PE1 два маршрути до хоста 10.0.0.3/32, в той час як на PE3 є тільки один маршрут до 10.0.1.1/32:
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.1/32

VRF-VPN-1.inet.0: 6 destinations, 11 routes (active 6, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.1/32 *[BGP/170] 02:25:44, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)

У VRF з'явився якийсь дивний маршрут з поки що нам невідомих протоколом EVPN, та ще й преференсом 7, що його робить кращим BGP ( а також бажано маршрутів ISIS, OSPF і т д). Як то дивно, чи не правда. Що це за маршрут? Навіщо він нам потрібен, адже і без нього все буде працювати. Справа в тому, що даний маршрут необхідний для прямого обміну трафіком між EVPN, минаючи L3VPN. Давайте його розглянемо уважно:
bormoglotx@RZN-PE-1> show route table VRF-VPN-1.inet.0 10.0.0.3/32 protocol evpn detail

VRF-VPN-1.inet.0: 7 destinations, 15 routes (7 active, 0 holddown, 0 hidden)
10.0.0.3/32 (2 entries, 1 announced)
*EVPN Preference: 7
Next hop type: Indirect
Address: 0x97f5f90
Next-hop reference count: 2
Next hop type: Router, Next hop index: 615
Next hop: 10.62.0.1 via ge-0/0/0.0, selected
Label operation: Push 300352, Push 299792(top)
Label TTL action: no-prop-ttl, no-prop-ttl(top)
Load balance label: Label 300352: None; Label 299792: None;
Session Id: 0x1
Protocol next hop: 62.0.0.3
Label operation: Push 300352
Label TTL action: no-prop-ttl
Load balance label: Label 300352: None;
Composite next hop: 0x95117b8 670 INH Session ID: 0x2
Ethernet header rewrite:
SMAC: 02:00:00:00:07:77, DMAC: aa:bb:cc:00:05:00
TPID: 0x8100, TCI: 0x0309, VLAN ID: 777, Ethertype: 0x0800
Indirect next hop: 0x9860990 1048583 INH Session ID: 0x2
State: <Active NoReadvrt Int Ext>
Age: 1:09 Metric2: 1
Validation State: unverified
Task: RZN-VPN-1-evpn
Announcement bits (1): 0-KRT
AS path: I

Нам цікаві такі рядки цього висновку:
Ethernet header rewrite:
SMAC: 02:00:00:00:07:77, DMAC: aa:bb:cc:00:05:00
TPID: 0x8100, TCI: 0x0309, VLAN ID: 777, Ethertype: 0x0800

Це не що інше, як наказ, який треба додати L2 заголовок, щоб відправити пакет на CE3! Подивимося, що за MAC-адресу вказано джерело: SMAC: 00:05:86:71:1a:f0. Логічно, що якщо це джерело пакета, то він повинен бути на PE1. Давайте прикинемо, з якого MAC-адреси можуть йти пакети під влан 777? Логічно припустити, що це буде інтерфейс irb.777, а значить в L2 заголовку має бути саме його MAC. Подивимося, якою насправді MAC-адресу у irb.777:
bormoglotx@RZN-PE-1> show interfaces irb.777 | match mac
MAC: 02:00:00:00:07:77

Все вірно, у заголовку вказано MAC-адресу локального інтерфейсу irb.777 на PE1, а значить наші міркування були правильними. Давайте тепер визначаємо, кому ж належить MAC-адресу призначення: DMAC: aa:bb:cc:00:05:00? Думаю, гадати не варто — це повинен бути MAC CE3. Давайте перевіряти:
bormoglotx@RZN-PE-1> show route table RZN-VPN-1.evpn.0 match-prefix *10.0.0.3*

RZN-VPN-1.evpn.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2:62.0.0.3:1::777::aa:bb:cc:00:05:00::10.0.0.3/304
*[BGP/170] 00:05:18, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.1 via ge-0/0/0.0, Push 299792

Даний MAC належить хосту 10.0.0.3, куди і вказує маршрут. Для достовірності підемо на CE3 і подивимося, як MAC на її інтерфейсі у бік PE:
RZN-CE3-SW1#sh ip int br | i 10.0.0.3
Ethernet0/0.777 10.0.0.3 YES NVRAM up up

RZN-CE3-SW1#sh interfaces eth0/0.777 | i Hard
Hardware is AmdP2, address is aabb.cc00.0500 (bia aabb.cc00.0500)

Приналежність адрес ми встановили. Тепер подивимось на другий рядок нас цікавить частині висновку:
TPID: 0x8100, TCI: 0x0309, VLAN ID: 777, Ethertype: 0x0800

А це значення, якими необхідно заповнити решту поля кадру ethernet при відправці на CE3.

Тобто цей маршрут нам явно вказує, що якщо треба відправити ethernet кадр з irb.777 на хост CE3, то треба додати зазначені значення L2 заголовок, навісити дві позначки: Push 300352, Push 299792(top) і відправити пакет в інтерфейс ge-0/0/0.0. Все просто.

Примітка: дане дію з пакетом передбачає використання composite next hop. Саме тому включення функціоналу прикутий-composite-next-hop обов'язково на Juniper, при налаштуванні EVPN.


bormoglotx@RZN-PE-1> show configuration routing-options forwarding table
прикутий-composite-next-hop {
ingress {
evpn;
}
}

Звідки ж береться цей маршрут? Може бути нам його надіслала PE3? Давайте перевіримо що анонсує PE3 на рефлектор:
bormoglotx@RZN-PE-3> show route advertising-протоколу bgp 62.0.0.255 | match 10.0.0.3
* 10.0.0.3/32 Self 100 I
2:62.0.0.3:1::777::aa:bb:cc:00:05:00::10.0.0.3/304

Нічого кримінального, тільки два маршрути мають у своєму складі адреса 10.0.0.3. Перший — vpnv4 маршрут, другий — EVPN тип 2.

Значить цей маршрут локальний для PE-маршрутизатора. Все вірно. Даний маршрут генерується локальним PE маршрутизатором на основі EVPN MAC+IP маршруту. Але тоді чому його немає на PE3? Скориставшись методом банальної ерудиції, можна прийти до висновку, що на PE3 немає bridge-домену влан 1777 з інтерфейсом irb.1777 (адже з нього повинен йти пакет на CE1-2) і інтерфейсу irb.1777 немає у зв'язаному VRF. А так як немає локального інтерфейсу, то який MAC-адресу вказати як source? Не поставиш же адресу іншого інтерфейсу. Ось тому цей маршрут і відсутній на PE3. Давайте перевіримо цю теорію — деактивуємо на PE1 в VRF інтерфейс irb.777, з якого повинен буде відлітати пакет на PE3.

Отже, маршрут на PE1 зараз є:
[edit]
bormoglotx@RZN-PE-1# run show route table VRF-VPN-1.inet.0 10.0.0.3/32

VRF-VPN-1.inet.0: 8 destinations, 18 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.3/32 *[EVPN/7] 00:01:22, metric2 1
> to 10.62.0.1 via ge-0/0/0.0, Push 300352, Push 299792(top)
[BGP/170] 00:04:41, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.1 via ge-0/0/0.0, Push 16, Push 299792(top)


Деактивуємо інтерфейс IRB в VRF на PE1:
[edit]
bormoglotx@RZN-PE-1# show | compare
[edit routing-instances VRF-VPN-1]
! inactive: interface irb.777 { ... }

І перевіряємо, що у нас з маршрутом до 10.0.0.3/32:
[edit]
bormoglotx@RZN-PE-1# run show route table VRF-VPN-1.inet.0 10.0.0.3/32

VRF-VPN-1.inet.0: 7 destinations, 13 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.3/32 *[BGP/170] 00:05:47, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.1 via ge-0/0/0.0, Push 16, Push 299792(top)

Ну і перевіримо, а пройде пінг?
RZN-CE1-SW2#ping 10.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/14/21 ms

Природно, пінг пройшов, але тепер трафік йде через L3VPN в обидві сторони. Але хочеться сказати, що навіть у такому сценарії маршрут трафіку оптимізовано. Теж саме відбудеться, якщо вивести bridge-домен VLAN-777 з конфігурації (в цьому випадку irb.777 ще буде в VRF, але в стані down, так як для того, щоб IRB-інтерфейс був up, необхідний хоча б один фізичний інтерфейс в стані up в bridge-домені, в якому знаходиться IRB-інтерфейс).

Але ми зупинилися на тому, що пакет від CE3 дійшов до CE1-2.Тепер CE1-2 хоче відповісти на цей пакет. Тут ми вже обійдемося без висновків з CLI.

Отже, CE1-2 надсилає пакет на адресу основного шлюзу, адреса якого він вже знає. PE1 приймає пакет bridge-домені VLAN-1777. Так як в пакеті L2 заголовку адресою призначення вказано irb.1777, то PE1 знімає L2 заголовок і робить IP lookup в таблиці маршрутизації VRF. В таблиці маршрутизації є маршрут до хоста 10.0.0.3/32, причому, як показано вище, маршрутів два і кращий EVPN. PE1 просто змінює L2 заголовок, навішує ярлики та надсилає пакет на PE3.

PE3 отримує пакет, бачить позначку, яка вказує на те, що необхідно зробити L2 lookup MAC-таблиці bridge-домену VLAN-777, і, згідно з інформацією в ній, переслати пакет на CE3.

Власне, ось ми і розглянули весь процес, що відбувається з пакетом, при його русі від CE3 до CE1-2 і назад. Але ми розглянули процес в момент, коли ще не було трафіку між цими вузлами і PE маршрутизатори не знали MAC-адрес CE1-2 і CE3. Після того, як адреси стали відомі і маршрути розлетілися по всьому PE-кам, трафік піде трохи інакше. Давайте коротко розглянемо, як кінцевому підсумку буде йти трафік:

Від CE3 до CE1-2:
  1. Пакет від CE3 потрапляє в bridge-домен влан 777 на PE3.
  2. PE3 робить IP lookup в звязанном VRF і бачить специфічний маршрут до хоста 10.0.1.1/32. Так як на PE3 немає локального bridge-домену влан 1777, то немає і EVPN маршруту. Значить трафік йде через L3VPN на PE1.
  3. PE1 приймає пакет в VRF, знімає з нього мітку і бачить, що він призначений bridge-домену влан 1777.
  4. PE1 надсилає пакет на CE2-1 згідно MAC-таблиці bridge-домену влан 1777.

Тепер пакет у зворотному напрямку Від CE1-2 до CE3:
  1. CE1-2 надсилає пакет на PE1.
  2. PE1 робить IP lookup в VRF і бачить маршрут до хоста 10.0.0.3/32, причому кращий маршрут — це маршрут EVPN.
  3. PE1 навішує новий L2 заголовок і додає стек з двох міток, згідно інформації, що міститься в EVPN в маршруті у зв'язаному VRF.
  4. PE3 приймає пакет від PE1, знімає позначку і бачить, що необхідно зробити L2 lookup MAC-таблиці bridge-домену VLAN-777.
  5. Далі PE3 пересилає пакет на CE3.

Як бачите, у зворотний бік пакет летить трохи інакше — це називається асиметричним перенаправленням. Виникає резонне питання — чому асиметричним? Справа в тому, що ingress PE робить IP lookup в VRF і надсилає пакет на підставі наявного у VRF EVPN маршруту, а ось egress PE вже приймає пакет не в VRF, а в EVPN-інстанси. Якщо порівняти дві останні схеми, то буде добре видно симетричність і асиметричність трафіку. Думаю, що всі зрозуміли як це працює.

Схема, яку ми розібрали, називається схемою з симетричним використанням IRB-інтерфейсів (різні вендори можуть по різному називати дану схему, зазначений термін взятий з мануалів по налаштуванню EVPN на Brocade). Асиметричної схемою буде схема, коли на всіх PE маршрутизаторах будуть однакові IRB-інтерфейси, навіть за умови того що зазначеного влана на даному PE маршрутизаторі немає. Плюсом асиметричної схеми буде те, що у всіх VRF будуть маршрути протоколу EVPN ([EVPN/7]) і ваш трафік не буде проходити в одну сторону через L3VPN, а назад безпосередньо в EVPN. В нашому випадку, якщо ми додамо в схему irb.1777 на PE3, то ми отримаємо асиметричну схему.

Але є ще одне але, яке треба висвітлити.

Як ви знаєте, ARP запит відправляється на бродкастный адресу, а відповідь на нього форвардится тому за вказаною в заголовку MAC-адресою відправника.

У розглянутому вище випадку CE1-2 був безпосередньо підключений до PE1 і все працювало штатно: PE1 відправляв arp запит, і CE1-2 йому відповідав — власне, ніяких проблем. Але, якщо б CE3 відправляв пакет на CE2-2, то події розвивалися дещо інакше. Спочатку все так само, як і описано раніше:

  1. PE3 дивиться в таблицю маршрутизації VRF і бачить маршрут до мережі 10.0.1.0/24, отриманий від PE1.
  2. PE3 немає інших варіантів, окрім як відправити пакет через L3VPN на PE1.
  3. PE1 приймає пакет, робить L3 lookup і переправляє його в bridge-домен VLAN-1777. Так як irb.1777 ще не знає MAC-адресу CE2-2, він ініціює arp запит на резолв адреси CE2-2 (10.0.1.2), відправляючи пакет на CE1-2 і PE2.
  4. CE1-2 дропает пакет, так як адреса 10.0.1.2 йому не належить. PE2 пересилає отриманий запит на CE2-2.
  5. CE2-2 приймає arp запит і відповідає на нього юникастом на MAC-адресу, що належить irb.1777 на PE1.


Але чи отримає irb.1777 на PE1 відповідь від CE2-2? Згадуємо про синхронізацію MAC-адрес між дефолтними шлюзами. Згадали? Значить розумієте, що irb.1777 на PE2 прийме пакет, спрямований на MAC-адресу irb.1777 PE1. У підсумку PE1 не отримає відповіді на свій запит, скільки б він їх не відправляв, а значить не разрезолвит IP-адресу призначення і не зможе відправити пакет на CE2-2. Все було б так, якщо б це був би не EVPN.

Так як irb.1777 на PE2 прийняв arp від CE2-2, то він генерує маршрут типу 2 (MAC і MAC+IP), а також vpnv4 префікс. Як розумієте PE1 вже не потрібен відповідь на його arp запит, так як тепер він отримав MAC-адресу CE2-2 по BGP і може переслати йому пакет, який перебував у буфері. Виходить, що трафік на CE2-2, який живе на PE2 йде з PE3 петлею через PE1? Не зовсім так. Петлею прилетів тільки пакет (пакети), який PE3 вже встиг відправити і які перебували в черзі на відправлення на PE1. Але так як і на PE3 з'явився в VRF більш специфичый маршрут до CE2-2, то в подальшому трафік вже піде не через PE1 за маршрутом 10.0.1.0/24, а безпосередньо на PE2 (за маршрутом 10.0.1.2/32, який з'явиться в таблиці маршрутизації VRF).

У розглянутому нами випадку у всіх IRB-інтерфейсів були різні MAC-адреси, що передбачало необхідність синхронізації дефолтних шлюзів. Рекомендований варіант використання IRB-інтерфейсів — використовувати однакові MAC і IP-адреси на всіх PE маршрутизаторах одного bridge-домену. Як ви розумієте, коли скрізь MAC-адреси будуть однакові і все буде працювати так, як я описав вище, тільки синхронізації дефолтних шлюзів, по суті, не треба.

У кінцевому рахунку, при будь-якому розкладі, як би ви ні використовували IRB-інтерфейси:
з однаковими IP, але різними MAC-адресами;
з однаковими IP і MAC-адресами,
все одно всі PE маршрутизатори в EVPN-домені отримають маршрут MAC+IP і BGP vpnv4 префікс, а значить при відправленні пакета з іншого CE маршрутизатора не потрібно знову відправляти arp запит на резолв цієї адреси. Це дозволяє істотно скоротити arp флудинг по мережі провайдера.

Вихід в інші VRF і зовнішні мережі
Вище ми розібрали, як трафік буде йти між вланами. Але як бути з доступом з інших VRF, ніяк не пов'язаних evpn?

Давайте спробуємо достукатися до наприклад хоста 10.0.1.1/32 з VRF, який не пов'язаний ні з однією EVPN. Робити новий VRF мені не хочеться, тому я зроблю простіше: на PE3 деактивуємо instance evpn, а в VRF деактивуємо irb.777 і додамо новий інтерфейс irb.0 (20.0.0.1/24):

[edit]
bormoglotx@RZN-PE-3# show routing-instances RZN-VPN-1
##
## inactive: routing-instances RZN-VPN-1
##
instance-type evpn;
vlan id 777;
interface ge-0/0/2.777;
routing-interface irb.777;
route-distinguisher 62.0.0.3:1;
vrf-import VPN-1-IMPORT;
vrf-export VPN-1-EXPORT;
protocols {
evpn {
interface ge-0/0/2.777;
}
}


[edit]
bormoglotx@RZN-PE-3# show routing-instances VRF-VPN-1
instance-type vrf;
interface irb.0;
inactive: interface irb.777;
route-distinguisher 62.0.0.3:10003;
vrf-target {
import target:6262:10001;
export target:6262:10001;
}
vrf-table-label;


[edit]
bormoglotx@RZN-PE-3# show interfaces irb.0
family inet {
address 20.0.0.1/24;

Дивимося, що у нас в таблиці маршрутизації:
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 active-path

VRF-VPN-1.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/24 *[BGP/170] 00:00:03, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)
10.0.1.0/24 *[BGP/170] 00:00:03, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)
10.0.1.1/32 *[BGP/170] 00:00:03, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)
10.0.1.2/32 *[BGP/170] 00:00:03, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299792(top)
10.0.1.22/32 *[BGP/170] 00:00:03, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299792(top)
20.0.0.0/24 *[Direct/0] 00:00:03
> via irb.0
20.0.0.1/32 *[Local/0] 00:00:03
Local via irb.0

Я спеціально деактивував даний VRF, щоб показати, що маршрути /32 відразу прилетять у вигляді vpnv4 префіксів і встануть в таблицю маршрутизації (як бачите час життя маршруту в таблиці у всіх префіксів однаково і дорівнює трьом секундах).

Тепер запустимо пінг з нашого IRB-інтерфейсу (20.0.0.1) на CE1-2 (10.0.1.1), який живе за PE1:
bormoglotx@RZN-PE-3> ping rapid routing-instance VRF-VPN-1 source 20.0.0.1 10.0.1.1
PING 10.0.1.1 (10.0.1.1): 56 data bytes
!!!!!
--- 10.0.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.828/7.872/10.368/1.655 ms


А тепер до хоста CE2-2 10.0.1.2, який живе на PE2:
bormoglotx@RZN-PE-3> ping rapid routing-instance VRF-VPN-1 source 20.0.0.1 10.0.1.2
PING 10.0.1.2 (10.0.1.2): 56 data bytes
!!!!!
--- 10.0.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.443/6.713/7.342/0.656 ms

Тепер знову повернемося до маршрутами і подивимося, чи різними шляхами йдуть пакети:
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.1/32

VRF-VPN-1.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.1/32 *[BGP/170] 00:03:50, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)

bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.2/32

VRF-VPN-1.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.2/32 *[BGP/170] 00:03:52, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299792(top)

Отже, до 10.0.1.1 транспортна мітка 299776, а до 10.0.1.2 — 299792. Дивимося, що це за LSP:
Мітка 299776 — транспортна мітка до 62.0.0.1 (PE1):
bormoglotx@RZN-PE-3> show route 62.0.0.1/32 table inet.3

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

62.0.0.1/32 *[LDP/9] 03:36:41, 1 metric
> to 10.62.0.5 via ge-0/0/0.0, Push 299776

Мітка 299776 — транспортна мітка до 62.0.0.2 (PE2):
bormoglotx@RZN-PE-3> show route 62.0.0.2/32 table inet.3

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

62.0.0.2/32 *[LDP/9] 03:36:45, 1 metric
> to 10.62.0.5 via ge-0/0/0.0, Push 299792

Як бачите, навіть з VRF, абсолютно нічого не знає про EVPN, трафік йде оптимальним шляхом. Зворотний трафік з EVPN в VRF до мережі 20.0.0.0/24 йде за маршрутом, отриманого за BGP:
bormoglotx@RZN-PE-2> show route table VRF-VPN-1.inet.0 20.0.0.0/24 active-path

VRF-VPN-1.inet.0: 10 destinations, 16 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

20.0.0.0/24 *[BGP/170] 00:06:44, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.3 via ge-0/0/0.0, Push 16, Push 299808(top)

Шлях пакета з VRF (irb.0 20.0.0.1) в EVPN (CE1-2 10.0.1.1):

Маршрут проходження зворотного трафіку:

Але представлений випадок простий — маршрути до хостів 10.0.1.1 і 10.0.1.2 вже були в таблиці маршрутизації. Як бути, якщо маршруту до вузла немає? Тут все працює так само, як і в першому випадку (коли на PE маршрутизаторі немає bridge-домену, в якому живе хост призначення). Давайте достукаємося наприклад до 10.0.0.2, специфічного маршруту до якого у нас в даний момент немає:
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.0.2/32

bormoglotx@RZN-PE-3>

Маршруту і справді немає, але зате у нас є маршрут до 10.0.0.0/24:
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.0.0/24 | match \/24
10.0.0.0/24 *[BGP/170] 00:13:14, localpref 100, from 62.0.0.255

Логічно, що трафік піде за цим маршрутом. Запустимо пінг і перевіримо, що все працює:
bormoglotx@RZN-PE-3> ping rapid routing-instance VRF-VPN-1 source source 20.0.0.1 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
!!!!!
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 6.135/7.206/7.806/0.663 ms

Пінг успішно пройшов, а в VRF у нас з'явився маршрут до хоста 10.0.0.2/32:
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.0.2/32

VRF-VPN-1.inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.2/32 *[BGP/170] 00:00:06, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299792(top)

Сподіваюся, ви зрозуміли як це працює.

Навіщо це все-таки потрібно?
Один з моїх знайомих охрестив цю технологію — наркоманією. Можливо, що алгоритм використання IRB-інтерфейсу занадто заплутаний і складний для розуміння і не тільки в плані роботи, але і в плані того, навіщо воно взагалі потрібне. Але згадайте, коли ви вперше почули про MPLS — хіба ця технологія вам була повністю зрозуміла? Думаю, що навряд чи.

Але чому не можна було зробити так само як і в VPLS — один вихід із всього домену? Давайте подумаємо, яку проблему вирішує описане вище використання L3 інтерфейсів. EVPN по своїй суті призначалася для з'єднання датацентрів. З датацентру йде дуже пристойну кількість трафіку, на відміну від простого клієнтського VPLS. Тому розглянемо ось такий випадок:

У нас одна точка виходу з VPLS, розташована на PE2, і припустимо, що CE1 підключений до L3VPN, а CE2 до VPLS домену. Важливим тут є те, що обидві ці сітки будуть жити в одному і тому ж датацентрі, а от ходити трафік між ними буде такий петлі:

Спочатку трафік від Server 2 йде до виходу з VPLS домену, який знаходиться на PE2, і з PE2, через L3VPN повертається назад на PE1. Можливо, що навіть ці два сервери будуть включені в одні і той же комутатор та/або стоять в одному і тому ж стативе в датацентрі. Так, якщо це якийсь малий обсяг трафіку, то нехай він так і йде — швидше за все, тут гра не варта свічок. Але, якщо це потокове відео, завантаження будь-якого контенту з FTP-server-а і т д? Тоді весь цей обсяг трафіку двічі пройде по ядру мережі, просто забиваючи смугу пропускання по суті «паразитним» трафіком. Саме це завдання вирішує L3 функціонал EVPN. Генеруючи /32 маршрут до хосту і передаючи його в VRF, EVPN оптимізує проходження трафіка між різними мережами. Якщо в представленій вище схемою використовувати EVPN, то PE1 згенерував б /32 маршрут до server1, і трафік пішов би локально через PE1, а не петлею через всі ядро:

І це тільки один приклад…

Висновок
Як бачите, EVPN є не просто технологією 2-го рівня. В дану технологію глибоко інтегрований і роутинг і світчинг. Причому використовувати вищеописану схему з інтеграцією в VRF не обов'язково, якщо ви прокидываете просто клієнтський L2 сервіс.

Але за все в цьому світі треба платити і EVPN не виняток. То що технологія складна і заплутана — це не проблема, треба просто в ній розібратися (адже колись і VPLS здавався темним лісом — а зараз здається, що начебто все логічно і зрозуміло (у всякому випадком мені)). Однією з проблем може стати велика кількість /32 і велика кількість маршрутів типу 2, розібратися в яких часом буде нереально. Давайте прикинемо, що у нас наприклад 4 мережі, розміром /24 — грубо кажучи, це мережі на 250 хостів. Якщо ми хочемо, щоб всі хости спілкувалися один з одним, то ми отримаємо 1000 маршрутів /32 (по 250 маршрутів /32 і типу 2 на кожну мережу /24). А якщо таких доменів буде 10? Тоді вже 10 000 маршрутів з маскою /32 будуть літати по нашій мережі, навантажуючи control plane. Причому ці цифри в сучасних реаліях датацентрів з їх системами віртуалізації будуть на 2-3 порядки вище описаних у статті. Ми знаємо, що роутрефлектор надсилає своїм нейборам всі маршрути, дозволені групової експортною політикою. Якщо, для прикладу, в нашу топологію додати маршрутизатор PE4, який буде мати vpnv4 сесію з рефлектором, то він буде отримувати від рефлектора всі наші 10 000 маршрутів, які йому особливо не потрібні. Природно, PE4 буде дивитися на RT і відкидати анонс, але ця робота теж буде навантажувати процесор RE. В RFC немає ніяких рекомендацій з цього приводу. Juniper ж рекомендує використовувати сімейство адрес route-target, щоб отримувати тільки потрібні анонси. Але у своїй практиці від даного сімейства адрес я отримував поки що тільки проблеми.

До всього іншого відповімо на просте питання: чому MAC-адреси не використовуються для роутінга? Адже на відміну від IPv4 адрес, MAC-адрес більше, вони глобально унікальними, є як бродкастные, так і мультикастные адреси, є навіть приватні (точніше призначені вручну адміністраторами незалежно від виробника обладнання) MAC-адреси. Використовуй — не хочу! Але чомусь використовується IP з усіма його милицями типу NAT і т д. Однією з найважливіших причин є те, що MAC-адреси, на відміну від IP-адрес, не агрегуються в підмережі, так як перша їх частина не відповідає за географічне розташування адреси або організацію, якою цей блок адрес виданий, а за приналежність обладнання до тому чи іншому виробникові. У підсумку виходить, що теоретично MAC-адреси піддаються агрегації, але практично на живий мережі це зробити нереально, так як наприклад MAC-адресу 04:01:00:00:01:01 належить залізниці, розташованої де-небудь на узбережжі Флориди, а залізка з MAC-адресою 04:01:00:00:01:02 наприклад, вже в Рязані.

Сьогодні FV налічує понад 600 000 агрегованих маршрутів. Уявіть розмір таблиці маршрутизації, якщо б для роутінга використовувалися виключно /32 адреси. Навіщо я про це пишу? Справа в тому, що якщо у вас з'єднані 5-6 датацентрів, в яких близько 100к MAC-адрес, то уявіть яке навантаження ляже на control plane за розподілом тільки EVPN маршрутів (про практично такій же кількості /32 я мовчу). У цієї проблеми є рішення, наприклад, використання PBB, але, як мовиться, це вже зовсім інша історія…

Якщо комусь цікавіше покопатися глибше, то ось деякі посилання на інформацію по даній тематиці:
Безпосередньо сам RFC 7432 з усією історією змін;
Juniper EVPN;
Juniper EVPN IRB;
Cisco EVPN PBB;
Cisco EVPN VXLAN;
Brocade EVPN.

Посилання на всі попередні випуски СДСМ:12. Мережі для найбільш досвідчених. Мережі для найбільш досвідчених. Частина дванадцята. MPLS L2VPN
11.1. Мережі для самих маленьких. Микровыпуск №6. MPLS L3VPN і доступ в Інтернет
11. Мережі для самих маленьких. Частина Одинадцята. MPLS L3VPN
10. Мережі для самих маленьких. Частина десята. Базовий MPLS
9. Мережі для самих маленьких. Частина дев'ята. Мультикаст
8.1 Мережі для Самих Маленьких. Микровыпуск №3. IBGP
8. Мережі для самих маленьких. Частина восьма. BGP і IP SLA
7. Мережі для самих маленьких. Частина сьома. VPN
6. Мережі для самих маленьких. Частина шоста. Динамічна маршрутизація
5. Мережі для самих маленьких: Частина п'ята. NAT і ACL
4. Мережі для самих маленьких: Частина четверта. STP
3. Мережі для самих маленьких: Частина третя. Статична маршрутизація
2. Мережі для самих маленьких. Частина друга. Комутація
1. Мережі для самих маленьких. Частина перша. Підключення до обладнання cisco
0. Мережі для самих маленьких. Частина нульова. Планування

Від автора

На написання статті, тестування різних функцій, читання RFC та іншої доступної літератури різних вендорів (не обмежуючись тільки Cisco та Juniper) пішло більше 2-х місяців. Як бачите, тести проводилися виключно на Juniper, і в інших вендорів реалізація певного функціоналу може дещо відрізнятися від описаного вище. Сподіваюся викладене в статті буде зрозумілим і корисним читачам. Якщо знайшли в статті помилки або якісь косяки — пишіть в лічку. Ну, і дякую за увагу...
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.