VPNv4 между AS: чего требует договор о пересылке меток

Чтение метки VPNv4 на пограничном маршрутизаторе AS мало что даст, пока не известно, какая модель между AS реализует передачу. Метка сама по себе не свойство маршрута; она фиксирует соглашение об инкапсуляции и доставке между двумя маршрутизаторами. Определите модель, прежде чем читать вывод. Иначе вы отлаживаете соглашение, которое никто не записал.

Какую модель реализует граница

Схема VRF-в-VRF соединяет совпадающие VRF через маршрутизируемые подключения. Каждая сторона видит другую как соседа customer-edge, и они обмениваются обычными маршрутами IPv4, поэтому на этой границе ничего не требует MPLS.

Вторая схема меняет маршруты VPNv4 с метками между самими пограничными маршрутизаторами. Это работает только при согласованном пути с коммутацией меток через interconnect и при распространении route-target плюс модели доверия, которую принимают обе стороны. Если не хватает любой из двух частей, модель не используется, что бы ни подразумевала конфигурация.

Третья распространяет достижимость PE с метками, пока маршруты VPN идут между оконечными точками или отражателями маршрутов через AS. Каждая из трёх оставляет на границе свою работу, и смешение плоскости управления одной с предположениями об интерфейсе другой — классический отказ. Это несоответствие обычно проявляется как метка, которая на одной стороне выглядит правильной, а на другой исчезает.

Проследите один префикс от начала до конца

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

Номер локален. Он значит что-то в отношении маршрутизатора, который его выделил, и пути, который несёт пакеты туда, поэтому одно и то же значение может появиться дважды и значить две разные вещи. Сравните его с тем, что, по словам принимающей стороны, она получила.

Метка локальна, и обещание тоже

Возможность проверяется на обоих концах interconnect, а не на одном. Команда на вашем интерфейсе ничего не делает с интерфейсом соседнего провайдера, а маршрут, принятый BGP, сам по себе не обязывает соседа передавать пакет с меткой.

RFC 4364 ограничивает пиринг VPNv4 с метками доверенными схемами и предупреждает против приёма меток, которые никогда не анонсировались этому пиру. Это утверждение о безопасности в той же мере, что и о протоколе. Держите отношения маршрутизации публичного интернета в стороне от обмена частными маршрутами VPN. Если interconnect — это простой IP, не ждите, что какая-либо метка его переживёт. А там, где канал с метками, подтвердите, что внешняя транспортная метка корректно меняется на каждом переходе.

Метка, которая на одной стороне выглядит правильной, а на другой исчезает, — обычно именно это несоответствие, а не ошибка маршрутизации.

Что записать при приёмке

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

Эта запись позволяет следующему оператору правильно прочитать тот же вывод меток. Без неё модель выводится из конфигурации, а выведенные предположения — это способ, которым одна и та же ошибка повторяется. Раздел о взаимодействии между AS в RFC 4364 — это место, где решается, какая модель задумывалась.