Пропавший маршрут в VRF: локальный, VPNv4 или таблица пересылки?

Клиент говорит, что после изменения цели маршрута пропал префикс, и первый присланный скриншот обычно показывает не ту таблицу. Три разные таблицы отвечают на три разных вопроса: есть ли префикс внутри VRF, был ли он объявлен и импортирован как маршрут VPNv4 и была ли действительно установлена запись пересылки. Чтение их не по порядку даёт уверенные и неверные выводы. Этот регламент проводит один локальный и один удалённый префикс через все три таблицы по порядку и заканчивается планом отката для изменения RT, с которого всё началось.

Назовите префикс и таблицу, к которой он относится

Запишите два префикса, прежде чем что-либо вводить. Один локальный на площадке клиента, выученный с подключённого интерфейса или из объявления CE. Другой удалённый, и ожидается, что он придёт через магистраль провайдера. Они идут разными путями в одну и ту же VRF, и неисправность в одном ничего не говорит о другом.

Держите различие между двумя идентификаторами ясным, потому что большая часть путаницы в этих заявках идёт именно оттуда. Различитель маршрута входит в NLRI VPNv4 и существует, чтобы иначе одинаковые префиксы клиентов были уникальными во всей магистрали. Цель маршрута — расширенное сообщество, переносимое как атрибут, и именно с ним сопоставляется политика импорта и экспорта. Это не второе имя различителя, и она не переносится в пакетах клиента.

Шаг 1: докажите, что префикс есть в VRF

Начните с локального вида, затем с RT, которые управляют импортом. Если локального префикса здесь нет, ничто выше не может быть виновато:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Префикс, который отображается как подключённый или статический, выучен локально, и его наличие ничего не говорит о том, был ли он экспортирован. Это самое частое ошибочное чтение в этой работе: здоровая таблица VRF — доказательство только о локальном обучении. Сторона экспорта — отдельный вопрос, на который отвечают вид соседа и привязанная цель экспорта.

Проверьте списки RT на VRF, пока вы здесь. Если нужной цели импорта нет в списке, всё ниже не имеет значения. Если она есть, но отличается от того, что экспортирует удалённый PE, вы нашли неисправность, не открыв ни одного перехвата пакетов.

Шаг 2: прочитайте таблицу VPNv4 и её цели

Таблица VPNv4 показывает, что плоскость управления действительно обменяла. Ищите удалённый префикс под правильным различителем, затем посмотрите на сообщества, привязанные к нему:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

Запись с правильной целью маршрута, но без локальной установки, указывает на политику импорта или на выбор маршрута, а не на доступность. Запись, которая вообще не появляется в таблице VPNv4, указывает вверх: возможно, исходный PE её не экспортировал или сессия не несёт семейство адресов.

Есть и третий случай, который сбивает людей с толку при изменениях. Некоторые платформы ограничивают, какие VPN-маршруты они запрашивают или удерживают, используя сведения о членстве в целях маршрутов, поэтому отсутствие удалённого NLRI в одном отфильтрованном виде не доказывает, что объявления нет нигде. Проверьте нефильтрованную таблицу и объявленные маршруты соседа, прежде чем заключать, что маршрут отозван глобально.

Шаг 3: подтвердите, что что-то установлено и помечено

Запись BGP — это решение, а не путь. Таблицы пересылки говорят, есть ли пакетам куда идти:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

Запись CEF с разрешённой смежностью и исходящей меткой означает, что трафик плоскости данных должен работать, а любой оставшийся симптом относится к приложению или к фильтрации внутри VRF. Запись CEF с неразрешённым следующим переходом означает, что путь метки неполон, хотя BGP выглядит здоровым, и именно в этом случае скриншот таблицы BGP ввёл в заблуждение проверку изменения.

Сравните метку, которую навязывает локальный PE, с той, которую удалённый PE ожидает получить. Расхождение между двумя видами — это проблема распределения меток или сессии, и его не исправит правка целей маршрутов, сколько бы раз вы это ни делали.

Откатите изменение RT с объявленным охватом

Если неисправность началась с правки цели маршрута, отмените её как один осознанный шаг и скажите, какой охват вы меняете. Удаление цели импорта отзывает право внутри этой VRF. Оно не удаляет объявление VPNv4 из магистрали, и на некоторых платформах маршрут остаётся удержанным в таблице. Это разные исходы, и видимый пользователю эффект зависит от того, какой из них вы имеете в виду.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Мягкая входящая реконфигурация достаточна, когда сессия уже хранит префиксы; жёсткий сброс сессии, обращённой к провайдеру, в рабочее время — решение, которое должен принять кто-то другой. На Junos соответствующие проверки читают таблицу по каждой VRF и таблицу VPN напрямую, а откат — это возврат при commit, а не отмена по каждой команде, поэтому зафиксируйте разницу конфигурации до начала работы.

Закончите теми же тремя командами, с которых начали, в том же порядке, и запишите их вывод с отметкой времени. Заявка, которая говорит, что RT был неверным и теперь верен, не годится для повторного использования; та, что показывает префикс в VRF, в VPNv4 и установленный в CEF, — это доказательство, с которым следующий человек может сравнить. Если изменились только первые две, изменение не завершено.