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

Технология VRF (Virtual Routing and Forwarding) позволяет разделить один физический маршрутизатор на множество независимых виртуальных маршрутизаторов. Каждый VRF имеет собственную независимую таблицу маршрутизации (RIB), таблицу пересылки (FIB) и привязанные интерфейсы. Это фундаментальное свойство решает главную проблему оператора: поддержку клиентов с одинаковыми (перекрывающимися) диапазонами приватных IP-адресов (RFC 1918). Например, если Клиент А и Клиент Б одновременно используют подсеть 192.168.1.0/24 для своих офисов, на пограничном PE-маршрутизаторе интерфейс Клиента А помещается в VRF A, а интерфейс Клиента Б — в VRF B. При поступлении пакета из сети клиента маршрутизатор определяет VRF по входящему физическому или сабинтерфейсу (пакеты из MPLS-ядра попадают в VRF по VPN-метке), поэтому поиск в FIB выполняется в таблице этого VRF. Маршруты разных VRF не смешиваются между собой и с глобальной таблицей ядра, пока обмен не разрешён явной политикой (RT, route leaking). Это логическая изоляция маршрутизации, а не межсетевой экран и не шифрование.

Что такое VRF на самом деле

VRF - это не отдельный процесс и не виртуальная машина, а набор из четырёх объектов внутри одного маршрутизатора: собственная таблица маршрутов (RIB), собственная таблица пересылки (FIB/CEF), список интерфейсов-членов и, при необходимости, свои экземпляры протоколов PE-CE (BGP address-family, OSPF-процесс, статические маршруты). Контекст пересылки выбирается только по входному интерфейсу (или субинтерфейсу/VLAN): пакет, пришедший на Gi2, ищется в FIB того VRF, которому принадлежит Gi2, и больше нигде. Глобальная таблица ядра (IGP + LDP) остаётся отдельным контекстом: интерфейс, помещённый в VRF, перестаёт быть членом глобальной таблицы, поэтому ping 172.16.1.2 без указания VRF не работает.

Перекрывающиеся адреса: где именно они "живут"

Клиенты A и B могут использовать один и тот же стык 172.16.1.0/30 и одну и ту же LAN 192.168.10.0/24. На PE это безопасно, потому что два маршрута с одинаковым префиксом лежат в разных RIB. Проблема возникает только при выходе в ядро: MP-BGP переносит маршруты в одной общей таблице, где два одинаковых IPv4-префикса были бы одним и тем же NLRI, и лучший путь затёр бы второй. Решение - Route Distinguisher: к IPv4-префиксу добавляется 8 байт RD, получается 12-байтовый адрес VPN-IPv4 (VPNv4 NLRI; префикс-длина считается как 64 + длина IPv4-префикса). RD 65000:1 + 192.168.10.0/24 и RD 65000:3 + 192.168.10.0/24 - два разных NLRI, оба переживают в BGP RR и не конкурируют в выборе лучшего пути.

RD бывает трёх типов: тип 0 (2-байтовый ASN : 4-байтовый номер), тип 1 (IPv4-адрес : 2-байтовый номер), тип 2 (4-байтовый ASN : 2-байтовый номер). RD не определяет политику импорта/экспорта - это делает Route Target (следующий урок). Практическое правило: RD уникален на (VRF, PE), тогда RR видит маршрут одного клиента из двух PE как два разных NLRI и может отдавать их обоим для multipath и быстрой сходимости.

Метки: что именно прячет VRF в плоскости данных

Для каждого экспортируемого маршрута PE выделяет VPN-метку (20 бит) и вкладывает её в MP_REACH_NLRI вместе с VPNv4 NLRI. Есть три режима выделения:

  • per-prefix (per-route): метка на каждый префикс. Выходной PE по метке сразу знает next-hop и интерфейс, дополнительный IP-lookup не нужен. Минус - расход меток на больших таблицах (на Cisco это режим по умолчанию, на Huawei - per-route по умолчанию).
  • per-VRF: одна метка на весь VRF. Метки экономятся, но egress PE после снятия метки обязан выполнить IP-lookup в FIB этого VRF (Cisco: mpls label mode vrf A protocol bgp-vpnv4 per-vrf, Huawei: apply-label per-instance, Junos: vrf-table-label).
  • per-next-hop (per-CE): метка на пару (VRF, CE next-hop); так работает Junos по умолчанию без vrf-table-label. Нужен компромисс между числом меток и скоростью.

Побочный эффект per-VRF: на egress PE выполняется lookup по IP назначения, что даёт возможность применять фильтры VRF и uRPF, но на старых платформах требует recirculation (Junos: туннельный интерфейс vt- или виртуальный loopback).

Путь пакета A1 -> A2 через два перекрывающихся VRF

  1. Пакет от CE-A1 приходит на Gi2; интерфейс принадлежит VRF A, поэтому lookup идёт в FIB A.
  2. Найден BGP-маршрут от PE2 (RD 65000:2, VPN-метка 24 + next-hop 10.255.0.2). Транспортная метка к 10.255.0.2 берётся из глобальной LFIB (LDP).
  3. Ingress PE вставляет стек [LDP-метка, VPN-метка], P1 делает swap/PHP по внешней метке, не заглядывая в клиентский IP.
  4. Egress PE по VPN-метке определяет VRF A (или конкретный next-hop) и отдаёт пакет CE-A2. У B тот же IP-пакет придёт с другой VPN-меткой и попадёт в другой VRF.