EVPN тип 2 проти типу 5: чому одна IP-адреса означає два маршрути

Два маршрути на одному пристрої можуть указувати на 198.51.100.77 і все ж відповідати на різні питання. Один описує, де доступна MAC-адреса і, необов'язково, який IP прив'язаний до неї. Інший описує префікс, що розв'язується через наступний хоп, навіть коли цей префікс — єдиний хост. Їхнє плутання породжує тікет, який виглядає як помилка маршрутизації, але насправді є неправильно прочитаним типом маршруту.

Найшвидший спосіб їх розрізнити — прочитати ключ, навколо якого побудовано NLRI, а не маску в його кінці.

Ключ маршруту каже, що саме стверджує маршрут

Тип 2 — це маршрут оголошення MAC/IP з RFC 7432, і його ключем є 48-бітна MAC-адреса всередині NLRI. За цим ключем стоїть поле IP-адреси, поле довжини якого може бути 0, 32 або 128 біт, тож оголошення лише з MAC — це повний маршрут, а не запис хоста з відсутніми частинами. Стек міток, що йде далі, вказує на контекст мосту, де живе ця MAC.

Заповнене поле IP чи ні змінює те, що маршрут стверджує, а не тип маршруту. За довжини 32 або 128 біт відправник також стверджує, що ця IP належить тій MAC у межах одного екземпляра EVPN. За нульової довжини відправник взагалі не робить жодного твердження про IP. Жоден із варіантів не каже, що префікс доступний через маршрутизатор.

Тип 5 — це маршрут префікса IP з RFC 9136, і його ключем є префікс, записаний як довжина плюс стільки біт. Довжина сягає від 0 до 32 для IPv4 і від 0 до 128 для IPv6.

Обидва кінці цього діапазону допустимі, і жоден не передбачає MAC. Префікс нульової довжини стверджує доступність, не називаючи хост, тоді як /32 називає рівно одну адресу. NLRI також несе IP-адресу шлюзу, яку вихідна сторона використовує для побудови індексу overlay, плюс мітку для контексту пересилання. Поля MAC, за яким можна було б комутувати, немає, тому отримувач розглядає тип 5 як маршрутизований пункт призначення.

Маршрут префікса /32 — це не перейменований тип 2

Префікси розміром із хост — звичайні маршрути типу 5. Маршрут префікса /32 і тип 2 для тієї ж адреси можуть існувати разом в одному екземплярі EVPN, і вони несуть різну інформацію про пересилання.

Візьміть 198.51.100.77 в екземплярі EVPN з VNI 10100. Тип 2 може зіставити його з MAC 02:00:00:00:00:77 і міткою, що визначає домен мосту, де цю MAC було вивчено. Тип 5 може оголосити 198.51.100.0/24 для всієї підмережі або 198.51.100.77/32 лише для цієї адреси, з адресою шлюзу, що вказує на вихідний VTEP. Адреси перекриваються навмисно, бо маршрути відповідають на різні питання.

Один маршрут каже, що прив'язка кінцевої точки існує і доступна через певний міст. Інший каже, що префікс доступний через певний маршрутизатор, незалежно від того, чи вивчалася коли-небудь якась кінцева точка всередині нього.

Ця різниця визначає, куди дивитися насамперед, коли трафік не проходить. Якщо окремий хост недоступний, а маршрут його підмережі виглядає нормально, тип 5 ніколи не мав нести цей хост; шукайте відсутній тип 2. Якщо маршрут хоста є, але вся підмережа недоступна, перевірте, чи тип 5 узагалі створено. Читання полів по порядку краще за здогадки з довжини маски.

Читання обох маршрутів без здогадок

На NX-OS show bgp l2vpn evpn route type 2 і show bgp l2vpn evpn route type 5 ділять таблицю точно по цій лінії, а show l2route evpn mac ip показує локальні прив'язки MAC до IP за маршрутами типу 2. На Junos show evpn database перелічує вивчені прив'язки MAC і IP, тоді як show route table bgp.evpn.0 показує, що було оголошено й отримано.

Фільтруйте за route distinguisher і міткою Ethernet, перш ніж робити висновки. Та сама MAC або префікс може з'явитися в кількох екземплярах EVPN, і маршрут, що виглядає неправильним в одному екземплярі, може бути правильним в іншому.

Далі читайте NLRI по порядку: тип маршруту, ключ, поля шлюзу або мітки, потім route target у атрибутах. Тип 2 з ненульовим ESI повідомляє, що MAC є multi-homed, і саме це значення пов'язує оголошення від різних PE-маршрутизаторів. Тип 5 з адресою шлюзу повідомляє, який вихідний VTEP має приймати трафік.

Якщо маршрут відсутній, перевірте його виникнення перед кодуванням. Переконайтеся, що джерело має прив'язку або префікс локально, а потім переконайтеся, що пов'язаний з ним route target імпортується на цьому пристрої. Більшість повідомлень про зламаний тип 5 закінчуються на політиці імпорту, а не на форматі NLRI.

Записуйте контекст, а не лише тип маршруту

Запишіть разом тип маршруту, екземпляр EVPN, route distinguisher, імпортовані та експортовані route target і розв'язаний наступний хоп. Тип 2 без свого екземпляра неоднозначний, а наступний хоп без родини маршрутів запрошує до хибного висновку.

Обидва є маршрутами EVPN, навіть коли корисне навантаження — це адреса IPv4. Родина адрес усередині NLRI і родина адрес самого маршруту — окремі властивості, і тип 5 не стає маршрутом IPv4-unicast або VPN-IPv4 лише тому, що несе префікс IPv4.

Ця різниця проявляється на межі між площиною керування EVPN і IP-VRF. Route target визначає, який VRF імпортує префікс, а адреса шлюзу та мітка визначають, як пакет інкапсулюється в бік виходу. Читайте це разом, і рішення про пересилання перестає виглядати довільним.

Наступного разу, коли в таблиці EVPN з'явиться /32, перевірте ключ раніше за маску. Ключ MAC з необов'язковим IP — це прив'язка типу 2; ключ-префікс — це маршрут типу 5, якою б не була його довжина. Запишіть поруч route target і наступний хоп, і наступному інженеру не доведеться заново виводити всю історію.