Теоретические основы и архитектура

На крупной сети Route Reflector по умолчанию рассылает каждому PE все VPNv4-маршруты всех клиентов, а PE сам отбрасывает те, чей Route Target не импортирован ни в одном локальном VRF. Тысячи PE и миллионы VPN-префиксов превращают это в лишнюю нагрузку на RR, каналы и процессор PE. RT-Constrain (RFC 4684) решает проблему на стороне отправителя: PE объявляет в отдельном адресном семействе (AFI 1, SAFI 132), какие Route Target ему нужны, и RR отправляет только подходящие маршруты. Урок разбирает формат RTC-маршрута, префиксное соответствие, default RT-constraint route, иерархию RR и подводные камни начального обмена. Вторая часть - VRF-Lite: несколько VRF на одном маршрутизаторе без MPLS и MP-BGP, подинтерфейсы 802.1Q и отдельный IGP на каждый VRF. Третья - доступ клиента VPN в Internet: статика с ключом global, отдельный Internet VRF, обратный маршрут и заметки о NAT. Предполагается, что вы знаете VRF, RD/RT и протоколы PE-CE из предыдущих уроков модуля.

Зачем нужен RT-Constrain

Без дополнительных мер Route Reflector отправляет каждому клиенту все VPNv4-маршруты, которые получил. PE применяет к ним неявный фильтр по Route Target: маршрут, чей RT не импортирован ни одним локальным VRF, отбрасывается (на Cisco это поведение отключается командой no bgp default route-target filter). Лишняя работа уже сделана: RR сформировал обновление, канал его перенёс, PE разобрал атрибуты. Если PE обслуживает 5 VRF из нескольких тысяч, до 99 процентов полученных VPN-маршрутов выбрасывается. Это создаёт пик нагрузки при холодном старте RR (все клиенты поднимаются одновременно) и при перезапуске сессии, а также задерживает сходимость нужных маршрутов в общей очереди обновлений.

Механизм RFC 4684

RT-Constrain добавляет адресное семейство AFI 1, SAFI 132 (Route Target Constraint, RTC). Его NLRI состоит из 4-байтового origin AS и 8-байтового Route Target (расширенное community): всего до 12 байт, то есть до 96 бит префикса. PE создаёт RTC-маршрут для каждого import RT каждого VRF, обычно с origin AS, равным локальной AS, и отправляет его соседу. Сосед (RR) использует полученные RTC-маршруты как исходящий фильтр для этого пира: VPN-маршрут (SAFI 128 или VPNv6) отправляется, если хотя бы один его RT совпал с одним из RTC-префиксов пира. Если пир не согласовал семейство RTC, фильтрация для него не применяется, и поведение остаётся прежним, поэтому внедрение можно вести поэтапно.

Совпадение префиксное. Полный RTC-маршрут (96 бит) выбирает один конкретный RT. Короче префикс - шире охват: 32 бита покрывают все RT с данным origin AS, а длина 0 - это default RT-constraint route, означающий "отправь мне всё". Его используют узлы без собственной фильтрации (например, система мониторинга или RR верхнего уровня, которому нужны все клиентские маршруты) и сам RR, когда нужно отключить ограничение для клиента. Cisco выдаёт его командой default-originate в семействе rtfilter, Junos - advertise-default (точный синтаксис проверяйте на своей версии).

Динамика: что происходит при изменении RT

Добавили import RT в VRF - PE отправляет новый RTC-маршрут, RR в ответ высылает накопленные VPN-маршруты с этим RT без route refresh. Убрали RT - RTC-маршрут отзывается, и отправитель, как правило, отзывает уже отправленные маршруты, которые больше не нужны. Поэтому массовая правка RT в VRF создаёт всплеск обновлений на RR: в окно изменений стоит вносить пакетами. Многие реализации откладывают первую отправку VPN-маршрутов, пока не получат RTC End-of-RIB или не истечёт таймер, чтобы не отправить лишнее: если RTC на клиенте включён, но не активирован, VPN-маршруты могут прийти с задержкой - это нормально, это стоит проверить в первую очередь при жалобе "VRF поднялся, маршрутов нет".

Масштабирование RR и иерархия

RTC не уменьшает память RR: он хранит все VPN-маршруты в Adj-RIB-In, фильтруется только исходящая рассылка. Выигрыш - в обновлениях, полосе, CPU клиентов и времени сходимости. Для экономии памяти RR разделяют по наборам клиентов (RR1 обслуживает часть VPN, RR2 - остальные) и совмещают разделение с RTC. В иерархии клиент - RR - RR верхнего уровня нижний RR агрегирует RTC-маршруты клиентов и объявляет вверх объединённый набор; одинаковые RTC от разных PE превращаются в один путь по выбору лучшего, и это нужно учитывать при ECMP и add-path: проверяйте, что upstream получает достаточно RTC-путей, иначе на нём окажется один источник вместо двух. Между автономными системами RTC работает по eBGP: ASBR объявляет RTC-маршруты с origin AS своей AS, а в Option B/C RTC уменьшает объём обмена между ASBR (подробности в RFC 4684).

VRF-Lite

VRF-Lite - это только локальная часть VPN: несколько независимых RIB и FIB на одном маршрутизаторе без меток и без MP-BGP. Разделение достигается привязкой интерфейсов к VRF; между маршрутизаторами каждый VRF требует своего канала (физический порт или подинтерфейс 802.1Q с отдельным VLAN) и своего процесса маршрутизации либо отдельного address-family в BGP. RD на Cisco в таком VRF не обязателен, RT не используется, потому что обмена маршрутами между VRF через BGP нет. Типовые применения: Multi-VRF CE (клиентский маршрутизатор делит локальные сети), сегментация кампуса, дата-центр, а также стык PE-PE по схеме Inter-AS Option A (back-to-back VRF).

Ограничения: на каждый VRF приходится по подинтерфейсу, по сессии IGP/BGP и по набору конфигурации, поэтому сотни VRF вручную не масштабируются, и для этого есть L3VPN. На Cisco каждый VRF с OSPF - отдельный процесс (router ospf 30 vrf GUEST), число процессов ограничено платформой. Лимиты на размеры таблиц общие: VRF делят TCAM и FIB устройства.