От маршрута RIP на CE до удалённого VRF: где происходит экспорт
Префикс RIPv2 с CE попадает в удалённый VRF только после трёх отдельных решений: изучения, выбора в VRF и экспорта по подходящей политике.
Обновление RIPv2 приходит на provider edge, попадает в таблицу маршрутизации VRF и остаётся там, если что-то явно его не экспортирует. Три решения происходят последовательно, и каждое может отклонить префикс по своей причине. Именно восприятие их как одного события заставляет искать неисправность не в том устройстве, когда удалённый сайт не достаёт сеть, которую CE явно анонсирует. Проследите маршрут через PE, и последовательность станет очевидной.
Что PE делает с обновлением RIP
PE получает обновление на интерфейсе VRF, проверяет, что источник является разрешённым соседом, и устанавливает префикс в таблицу маршрутизации VRF с числом хопов, производным от анонса. Эта таблица — обычная таблица маршрутизации со своими административными дистанциями и собственным выбором лучшего пути. Если CE анонсирует один и тот же префикс дважды с разными метриками, в таблицу попадает только лучший. Ничто на этом шаге не затрагивает магистраль провайдера.
Теперь префикс существует внутри контекста маршрутизации одного клиента, что далеко от доступности где-либо ещё.
Экспорт — это акт политики, а не следствие протокола
Чтобы покинуть VRF, маршрут должен быть перераспределён в процесс MP-BGP, который переносит VPN-маршруты, и ему нужен extended community route target, определяющий, какие удалённые VRF могут его импортировать. Архитектура из RFC 4364 сохраняет эти обмены отдельно от протокола CE-PE именно по этой причине. Использование RIP на границе ничего не говорит о том, что должно пересекать сеть провайдера.
Запишите контракт экспорта до того, как что-либо настраивать: префиксы клиента, которые должны быть доступны удалённо, маршруты, которые должны остаться локальными, а также любые маршруты по умолчанию, более специфичные маршруты или исключения для общих сервисов. Сверяйте этот контракт с фактическим VRF, а не с похожим по имени VRF другого клиента.
Сторона импорта — это вторая политика со своими route targets, и совпадающий экспорт при несовпадающем импорте даёт префикс, который существует в магистрали и не появляется ни в одной удалённой таблице.
Перераспределение и явное порождение ведут себя по-разному
Перераспределение берёт маршруты, уже существующие в таблице VRF, и копирует их в BGP с фильтрацией по route map. Map решает, какие префиксы подходят и какие атрибуты они несут, а метрику нужно задать явно, потому что число хопов RIP не имеет смысла как метрика BGP. Всё, что вы оставите незаданным, наследуется так, что это обычно удивляет человека, читающего конфигурацию полгода спустя.
Взаимное перераспределение — это место, где происходит тихий ущерб. Префикс, экспортированный в BGP, может вернуться через вторую точку перераспределения, и без тегов или фильтров маршрут колеблется, пока обе таблицы в любой момент выглядят правдоподобно. Фильтруйте по тегам, применяемым на границе, вместо того чтобы полагаться на топологию в предотвращении обратного пути.
Явное порождение выглядит аккуратнее и не является безусловным. Оператор network обычно требует совпадающего маршрута в таблице маршрутизации до того, как префикс будет порождён, поэтому анонс исчезает в момент, когда CE перестаёт его анонсировать. Часто это и есть желаемое поведение, и оно не то же самое, что статический маршрут, остающийся настроенным навсегда. Проверяйте фактическое правило платформы, а не предполагайте одно из поведений.
В любом случае вопрос по каждому префиксу — какой активный источник делает его допустимым и что произойдёт, когда этот источник исчезнет.
Проверьте цепочку в четырёх местах
Посмотрите на анонс CE, таблицу маршрутизации VRF, таблицу VPN-маршрутов с её route target и импорт в удалённом VRF — именно в этом порядке. В IOS это означает вывод соседей CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, и та же команда на дальнем PE. В IOS-XR эквивалентный вывод находится под show bgp vrf CUSTOMER ipv4 unicast. Имена команд различаются, четыре контрольные точки — нет.
Проверяйте префикс, который должен быть отклонён, так же тщательно, как тот, который должен пройти, потому что политика, разрешающая всё, выглядит идентично правильной до первого исключения. Затем посмотрите на отзыв: отключите интерфейс CE и убедитесь, что удалённая запись исчезает в пределах ожидаемого таймера, а не остаётся.
Зафиксируйте, кто владеет каждой политикой. Когда провайдер эксплуатирует CE, поставляемое поведение относится к договору на обслуживание, и другой протокол или политика отзыва на управляемом устройстве — это прежде всего проблема документации, а уже потом маршрутизации.