Два маршрута на одном устройстве могут указывать на 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 targets в атрибутах. Тип 2 с ненулевым ESI сообщает, что MAC является multi-homed, и именно это значение связывает объявления от разных PE-маршрутизаторов. Тип 5 с адресом шлюза сообщает, какой выходной VTEP должен принимать трафик.

Если маршрут отсутствует, проверьте его возникновение перед кодированием. Убедитесь, что источник имеет привязку или префикс локально, затем убедитесь, что связанный с ним route target импортируется на этом устройстве. Большинство сообщений о сломанном типе 5 заканчиваются на политике импорта, а не на формате NLRI.

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

Запишите вместе тип маршрута, экземпляр EVPN, route distinguisher, импортированные и экспортированные route targets и разрешённый следующий хоп. Тип 2 без своего экземпляра неоднозначен, а следующий хоп без семейства маршрутов приглашает к неверному выводу.

Оба являются маршрутами EVPN, даже когда полезная нагрузка — это адрес IPv4. Семейство адресов внутри NLRI и семейство адресов самого маршрута — отдельные свойства, и тип 5 не становится маршрутом IPv4-unicast или VPN-IPv4 только потому, что несёт префикс IPv4.

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

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

Похожие статьи