Передача L3VPN: частные маршруты, маршрут по умолчанию или полная таблица?

Ваш канал поднят, VRF настроена, и провайдер задаёт короткий вопрос, который определяет остаток проекта: что должен получить клиентский край? Три ответа распространены, и ни один не следует из того, что существует стек меток. Это сервисные решения о том, откуда трафик покидает филиал.

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

Начните с трафика, который никто не планировал

Задайте один вопрос до появления любого списка префиксов: когда пакет не совпадает ни с одним частным маршрутом, куда он должен идти? Филиал с собственным интернет-каналом обычно держит локальный маршрут по умолчанию, поэтому обычный веб-трафик уходит через локальный межсетевой экран и никогда не касается провайдера. В таком проекте VPN несёт только удалённые частные площадки, а выбор делают более конкретные префиксы.

Филиал, которому положено использовать центральный выход, — обратный случай. Там маршрут по умолчанию указывает внутрь сервиса, а провайдер или центральная площадка владеет пересылкой, обратной маршрутизацией и любым преобразованием. Сказать "по умолчанию в VPN" без этого владельца означает филиал, который разрешает имена и никуда не попадает.

Два проекта различаются тем, как выглядит отказ маршрутизации, и поэтому угадывание дорого. С локальным маршрутом по умолчанию потерянный частный маршрут отправляет этот трафик в интернет, где его отбрасывает межсетевой экран или, что хуже, отвечает нечто, чего вы не задумывали. С центральным маршрутом по умолчанию та же потеря полностью лишает доступа в интернет, и заявка приходит как "весь филиал лежит". Ни один отказ сам по себе не является ошибкой, но только один соответствует проданному сервису, и одна лишь конфигурация BGP не скажет, какой вы построили.

Запишите частные префиксы вместе со сценарием отказа

Перечислите префиксы, до которых филиал должен дотянуться, и отметьте, какие из них агрегированы. Агрегат на один бит шире нужного втягивает неизвестные адресаты в VPN, и это допустимо только если дальняя сторона действительно ими владеет и их пересылает.

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

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

Проверьте, что CE действительно установил

Замысел конфигурации и состояние пересылки расходятся достаточно часто, поэтому проверка относится к передаче, а не к разбору инцидента. На клиентском крае IOS-XE три команды ниже отвечают на три разных вопроса: что было предложено, что было принято и что действительно используется.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Выполните все три в день передачи, а не месяц спустя, пока кто-то ещё помнит, о чём договорились. Первый вывод зависит от soft-reconfiguration inbound или сохранённого обновления маршрутов; без одного или другого CE не сможет показать, что он отклонил. Второй показывает принятые и лучшие маршруты после политики. Третий говорит, куда маршрут по умолчанию идёт на самом деле, и это самая полезная строка во всей передаче.

Выполните те же проверки на втором CE, если площадка подключена двумя линиями. Асимметричное принятие между двумя краями — частая причина "работает с одного сервера и не работает с другого", и она незаметна в различии конфигурации, которое выглядит симметричным.

Оцените больший поток, а не предполагайте его

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

Доводы о ёмкости ошибаются в обе стороны. Полная таблица внутри VRF не запрещена и не бесплатна. Точно так же нельзя вывести сегодняшнюю стоимость из старого числа маршрутов, и меньшее распределение меток не убирает стоимость хранения маршрутов.

Спецификация BGP/MPLS IP VPN обсуждает несколько схем доступа в интернет рядом с самим сервисом VPN и не объявляет полную таблицу или маршрут по умолчанию обязательными для каждого клиента, и именно этот раздел стоит указывать, когда появляется утверждение о "стандартной практике": RFC 4364.

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