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

Архитектура BGP/MPLS L3VPN (RFC 4364) базируется на двух ключевых концепциях: Route Distinguisher (RD) и Route Target (RT). 1. Route Distinguisher (RD) — это 64-битный префикс, который добавляется к 32-битному IPv4-адресу клиента на ingress PE, формируя глобально уникальный 96-битный адрес VPNv4 (например, RD 65000:1 + 192.168.1.0/24 = 65000:1:192.168.1.0/24). Назначение RD — исключительно предотвратить коллизию одинаковых IP-префиксов в плоскости управления BGP на Route Reflector. 2. Route Target (RT) — это расширенное комьюнити BGP (Extended Community), определяющее топологию и правила распространения сервиса. Экспортируемый RT (export RT) прикрепляется к VPNv4-маршруту при отправке в MP-BGP. Принимающий egress PE проверяет импортируемый RT (import RT) своих локальных VRF: если RT совпадает, маршрут импортируется в VRF клиента. Для IPv6 применяется аналогичная архитектура VPNv6 (RFC 4659), где 64-битный RD добавляется к 128-битному префиксу IPv6, формируя 192-битный адрес VPNv6.

RD и RT решают разные задачи

Route Distinguisher (RD) делает префикс уникальным в общей таблице MP-BGP: 8 байт RD + IPv4-префикс = VPNv4 NLRI (AFI 1, SAFI 128), 8 байт RD + IPv6-префикс = VPNv6 NLRI (AFI 2, SAFI 128). RD ничего не говорит о том, кому маршрут можно показывать. Route Target (RT) - это политика: расширенное BGP-community (8 байт: тип/подтип + глобальный администратор + локальное значение), которое экспортирующая VRF добавляет к маршруту, а импортирующая VRF использует как фильтр. Один и тот же маршрут может нести несколько RT, а одна VRF - импортировать и экспортировать несколько RT. Именно комбинации RT создают топологии full mesh, hub-and-spoke и extranet.

Форматы и числа

  • RD/RT тип 0: 2-байтовый ASN + 4-байтовое число (65000:100); тип 1: IPv4-адрес + 2 байта (10.255.0.1:100); тип 2: 4-байтовый ASN + 2 байта (для 4-байтовых AS).
  • Номер метки VPN - 20 бит, передаётся внутри NLRI (MP_REACH_NLRI); next-hop - loopback PE (10.255.0.2), недостижимый без транспортного LSP.
  • Для VPNv6 (6VPE, RFC 4659) next-hop - IPv4-mapped IPv6 адрес (::ffff:10.255.0.2), транспорт остаётся IPv4 LDP: ядро не обязано поддерживать IPv6.
  • RT передаётся в атрибуте Extended Communities, поэтому BGP-сессия обязана его пересылать: на Cisco нужно явное send-community extended в vpnv4/vpnv6, на Junos расширенные community отправляются по умолчанию.

Что происходит с маршрутом от CE до CE

  1. CE-A2 анонсирует 192.168.20.0/24 на PE2 (static/eBGP/OSPF).
  2. PE2 помещает маршрут в VRF A, ставит RD 65000:2, назначает VPN-метку, добавляет RT экспорта 65000:100 и анонсирует VPNv4 NLRI в сторону RR (next-hop 10.255.0.2).
  3. RR отражает маршрут всем клиентам, не проверяя RT: на Cisco для этого на RR отключают bgp default route-target filter, на Junos сохраняют все маршруты (keep all или отсутствие локальных VRF).
  4. PE1 принимает VPNv4 NLRI и проверяет RT: если ни одна локальная VRF не импортирует 65000:100, путь отбрасывается (Cisco: фильтр RT включён по умолчанию, Junos: bgp.l3vpn.0 без keep all). Это защищает память PE, но создаёт ловушку при добавлении нового клиента.
  5. Если RT совпал, маршрут попадает в VRF A.inet.0 как BGP-маршрут с next-hop 10.255.0.2, меткой VPN и транспортной меткой LDP.

RD: уникальный на PE или общий на клиента

  • Общий RD на VPN (65000:1 на всех PE): RR видит один NLRI от двух PE и отражает только один лучший путь, поэтому балансировка и мгновенное резервирование недоступны (нужен add-path).
  • Уникальный RD на (VRF, PE) (65000:1 на PE1, 65000:2 на PE2): два NLRI живут параллельно, RR отдаёт оба, PE получает ECMP/backup. Это рекомендуемая практика для мультихоминга.
  • RD не должен совпадать у разных клиентов: в противном случае перекрывающиеся префиксы затрут друг друга (см. предыдущий урок).

Схема назначения RT

Типичный стандарт: ASN:100 - клиент A, ASN:200 - клиент B, ASN:1xx - hub-and-spoke, ASN:9xx - общие сервисы. Заводите реестр RT и RD, ведите его как данные (не в голове инженера): ошибка в одной цифре даёт утечку между клиентами. Несколько RT на одну VRF допустимы (extranet), но каждое дополнительное значение расширяет зону видимости.

VPNv6

IPv6 в VRF настраивается отдельным address-family ipv6 (Cisco: в vrf definition, Huawei: ipv6-family в ip vpn-instance, Junos: тот же инстанс, таблица A.inet6.0). RD/RT можно задать одинаковые для v4 и v6 (так проще), но допустимы и разные. Сессия к RR должна активировать vpnv6 отдельно от vpnv4: недостающая активация - частая причина "IPv4 работает, IPv6 нет". Метка VPNv6 выделяется по тем же режимам per-prefix/per-VRF, что и для VPNv4.

Диагностика по слоям

  1. Есть ли сессия Established с RR и согласован ли AFI/SAFI (show bgp vpnv4 unicast all summary).
  2. Есть ли маршрут в таблице VPNv4 и какие RT на нём.
  3. Совпадает ли RT с импортом VRF.
  4. Достижим ли next-hop по LSP (транспортная метка).
  5. Видна ли метка VPN в выводе CEF/forwarding.

Если на шаге 2 маршрута нет - проблема в экспорте/сессии; если на шаге 3 - в RT; если на шаге 4 - в IGP/LDP.

Схема архитектуры и топология