Почему один арендатор 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. Шесть полей объясняют анонс каждому, кто прочитает заявку следующим, и ни одно из них не требует, чтобы числа арендатора совпадали.