Чому один орендар EVPN може показувати кілька route distinguisher
Два RD в одного орендаря — не конфлікт. Пройдіть від виводу CLI до MAC-VRF або IP-VRF, що створив маршрут, потім перевірте імпорт RT і VNI.
Ви фільтруєте таблицю EVPN для одного орендаря, і маршрути несуть два різні route distinguisher. Перша реакція — конфлікт конфігурації, і ця реакція зазвичай хибна. Ім'я орендаря — це бізнес-мітка, а не єдиний об'єкт площини керування, тому контекст мосту та контекст маршрутизації всередині нього можуть законно анонсуватися під окремими ідентифікаторами. Пройдіть по одному маршруту за раз від виводу назад до локального об'єкта сервісу, який його створив, і другий RD перестане виглядати помилкою.
Почніть із виводу, який вас заплутав
Виберіть один маршрут, а не всю таблицю. Запишіть тип маршруту, RD, експортовані route target і наступний хоп. Цих чотирьох полів достатньо, щоб визначити, який локальний об'єкт його анонсував і яка віддалена політика має його імпортувати.
На пристрої в стилі NX-OS докладний вигляд відкривається командою show bgp l2vpn evpn route-type 2 detail або show bgp l2vpn evpn route-type 5 detail. На Junos та сама інформація міститься в show route table bgp.evpn.0 detail. Інший синтаксис, ті самі поля.
Не починайте з того, щоб зробити всі показані числа однаковими. Вирівнювання RD — це зміна, яка ламає політику імпорту на робочому fabric.
Дайте кожному ідентифікатору його завдання
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
MAC-VRF зберігає інформацію пересилання MAC для сервісу мосту. IP-VRF надає контекст маршрутизації IP для маршрутизованого сервісу. Орендар може містити обидва, тому один орендар може створити більше одного RD без жодної помилки конфігурації.
RFC 7432 призначає RD анонсуючого MAC-VRF його EVPN NLRI і вимагає різних RD між MAC-VRF на одному PE. Процедури route-target окремі: вони дозволяють один або кілька атрибутів RT і покладаються на політику імпорту для членства. Рівність RD — не те, що створює спільне членство, і таке ставлення до неї є коренем цієї плутанини.
Пройдіть один маршрут від анонсу до імпорту
Стежте за маршрутом в одному напрямку. Підтвердьте тип маршруту, сервіс, що його створив, RD, експортовані RT, а потім політику імпорту на приймальному PE. Кожен крок відповідає на інше питання, і збій на будь-якому кроці виглядає як той самий відсутній префікс на іншому боці.
Коли маршрут присутній, огляньте встановлений контекст пересилання та зіставлення VNI. Збіг VNI на обох кінцях показує, що площина даних згодна; він не показує, що площина керування імпортувала маршрут через передбачену політику.
Якщо маршрут з'являється на віддаленому PE, але трафік не йде, проблема вийшла за межі EVPN. Перевірте прив'язку VNI до VLAN або VNI до VRF і шлях underlay, перш ніж знову редагувати route target. Почніть із зіставлення, потім underlay і лише потім площина керування. Відкат зміни route-target у гонитві за несправністю площини даних — надійний спосіб зламати робочий імпорт.
Префікси рівня 3 і далі є маршрутами EVPN
Префікс IP у таблиці EVPN — не звичайний IPv4-unicast BGP. маршрут EVPN IP Prefix — це окремий тип маршруту, а анонси MAC/IP і префіксів IP подорожують у родині адрес EVPN, яку RFC 7432 визначає як AFI 25 і SAFI 70.
Ця відмінність важлива, коли ви порівнюєте маршрут у таблиці EVPN із маршрутом у таблиці unicast. Вони можуть описувати той самий пункт призначення і все ж створюватися, фільтруватися та імпортуватися різною політикою. Читання одного як доказу про інший — це те, через що правильний fabric виглядає зламаним під час міграції.
Перевірте виведення постачальника, перш ніж порівнювати числа
RFC 9136 розширює EVPN маршрутами IP Prefix і зазначає, чи походить застосовний RD з контексту MAC-VRF чи IP-VRF. Тому мітку сервісу L2 і мітку маршрутизованого сервісу в одному виводі слід читати щодо об'єктів, яким вони належать, а не зводити до одного RD на орендаря.
Автоматичне виведення RD і RT залежить від постачальника. Прочитайте довідку розгорнутого постачальника щодо використовуваної формули; автоматично згенероване значення, побачене на одному комутаторі, не є універсальним кодуванням, і порівняння чисел двох постачальників рідко щось доводить.
Завершіть письмовим слідом для маршруту, з якого почали: тип, об'єкт-джерело, RD, експортований RT, політика імпорту, встановлений VNI. Шість полів пояснюють анонс кожному, хто читатиме заявку наступним, і жодне з них не вимагає, щоб числа орендаря збігалися.