Два PE, один префикс: почему RD определяет видимость
Два граничных маршрутизатора, объявляющих один и тот же префикс, делят одно назначение, если их route distinguisher не различаются. Назначайте осознанно, затем проверьте VRF.
Два граничных маршрутизатора, объявляющих один и тот же префикс клиента, описывают одно назначение VPNv4, пока что-то их не разделит, и разделителем является route distinguisher. Он квалифицирует префикс; он не решает, кто импортирует результат, это задача route target. Назначайте RD из множества маршрутов, которые должны оставаться различимыми в каждом домене, где эти объявления могут встретиться, а не из раскладки файлов на одном устройстве. Выбранный номер — это идентичность, от которой будут зависеть последующие проверки, поэтому ему место в описи до того, как он попадёт в конфигурацию.
RD вместе с префиксом — одно назначение
RD вместе с префиксом IPv4 образует назначение VPNv4, которое сравнивает плоскость управления. Дайте двум PE один и тот же префикс для разных клиентов, и без разных RD они объявляют маршруты к одному назначению. Ничто на экране не говорит, что такое группирование неверно, потому что платформа делает именно то, что говорит идентичность. Смените RD на одном из них, и старое объявление отзывается, а под другой идентичностью появляется новое. Всё ниже по потоку, что опиралось на старую идентичность, от выбора маршрута до сохранённого фильтра оператора, теперь ссылается на то, чего больше нет.
Несколько маршрутов на одно назначение — обычное поведение BGP, а не симптом. Спикер может держать несколько полученных маршрутов, выбирая один лучший для пересылки, и разрыв между полученным и выбранным — это место, где живут вопросы видимости. Когда маршрут кажется исчезнувшим, сначала подтвердите, существует ли ещё идентичность, к которой он относился, и только потом смотрите на сессию.
Тот же RD и то же назначение, разные маршруты
Отправьте один RD и один префикс с двух маршрутизаторов от имени одной услуги, и оба предлагают маршруты к одному назначению, обычно с разными следующими хопами. Какой из них передаст отражатель маршрутов — решение об отражателе: его выбор маршрута, способность объявлять и любая политика поверх этого. Ни один из граничных маршрутизаторов не управляет этим выбором. Дайте двум объявлениям разные RD, и каждое станет своим назначением, так что оба смогут пережить плоскость управления, которая иначе несёт только выбранный маршрут для одной идентичности.
Видимость и многопутевость встречаются в принимающем VRF, но это не одно и то же решение, и отражатель, несущий две идентичности, не настроил второй установленный маршрут. VRF устанавливает то, что допускает его политика импорта, и то, что позволяет его собственная настройка максимального числа маршрутов. Проверьте эту настройку отдельно, если хотите, чтобы второй маршрут использовался, а не просто был виден.
Локальное правило уникальности — не политика
Давать каждому PE и каждому экземпляру маршрутизации собственный RD — здравая практика: он называет источник, не даёт несвязанным услугам сталкиваться на одной идентичности и даёт описи стабильный ключ. Некоторые платформы требуют уникальности только внутри устройства и явно разрешают маршрутизаторам делить RD для одного экземпляра VPN. Это разрешение — ограничение реализации, а не межсетевое правило, которое можно делегировать поставщику. Если домен охватывает несколько команд, напишите политику распределения сами.
Принадлежность никогда не следует из цифр. Шаблон вроде 65000:12 для одного PE и 65000:13 для другого — привычка, тогда как совпадающие цели экспорта и импорта вроде 65000:112 — это то, что помещает маршрут в VRF. Относитесь к RD как к идентичности маршрута, а к route target — как к разрешению, которое несёт его в VRF.
Докажите изменение на VRF, а не на экране
Прежде чем трогать RD, запишите четыре вещи: что PE объявляет сегодня, что отражает отражатель, что импортирует принимающий VRF и какой маршрут он выбирает. Новый RD отзывает одно объявление и вводит другое, поэтому изменение видно с обеих сторон сессии, и его легко прочитать неверно, если следить только за объявляющей стороной. Приёмка должна опираться на нужную вам доступность, а не на лишнюю строку в списке префиксов. Таблица ниже не даёт трём идентификаторам слиться во время этой проверки.
| Identifier | Question it answers | What breaks when it is confused with another |
|---|---|---|
| Route distinguisher | Which route identity is this? | Two services collapse into one destination, so one advertisement withdraws the other |
| Route target | Who is allowed to import it? | Routes arrive in a VRF that should not have them, or never arrive at all |
| VRF import policy | What does this instance accept and install? | The route is visible on the PE but never selected in the VRF |
Начните с объявляющего PE и сравните обе идентичности для одного префикса, прежде чем что-либо удалять. Команды IOS ниже по порядку отвечают на три вопроса: на месте ли старое объявление, видна ли новая идентичность отражателю и выбирает ли VRF этот префикс.
show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24 show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24 show ip route vrf CUSTOMER-A 203.0.113.0/24
Другие платформы печатают ту же информацию в другом синтаксисе, и вопросы переживают это изменение. Если новая идентичность отсутствует у отражателя, а PE перечисляет её как объявленную, первый подозреваемый — политика или способность отражателя объявлять, а не нумерация.
Запишите PE, экземпляр, RD, цели экспорта и импорта и владельца префикса в одном месте, потому что следующее назначение становится поиском, а не догадкой только тогда, когда эта запись существует. Держите старый RD, пока новая идентичность не станет видимой в принимающем VRF, затем отзовите его вторым шагом, чтобы каждый этап оставался обратимым.