Теоретические основы и архитектура
Inter-AS Option B и Option C позволяют масштабно связать VPN двух операторов. В Option B ASBR поднимают между собой eBGP-сессию с семейством vpnv4. VRF на ASBR нет: они принимают VPNv4-префиксы, ставят next-hop-self, выделяют новые локальные VPN-метки и передают помеченные пакеты по одному линку. Option B убирает рост подинтерфейсов, но ASBR хранят всё межоператорское VPN-состояние. В Option C ASBR вообще не знают VPN-маршрутов: они обмениваются только loopback-ами PE/RR с метками через BGP Labeled Unicast (BGP-LU, RFC 8277, ранее RFC 3107), а VPNv4 идёт напрямую между RR (или PE) двух AS по multihop eBGP с сохранением next hop. Пакет несёт до трёх меток: транспортную внутри AS, метку BGP-LU и внутреннюю VPN-метку. Option C масштабируется лучше всех, но раскрывает loopback-и ядра и требует высокого доверия между операторами.
Option B: ASBR как транзитный узел VPNv4
Inter-AS Option B (RFC 4364, раздел 10, вариант "b") заменяет множество стыков Option A одним сеансом eBGP VPNv4 между ASBR1 (10.1.0.1, AS 65000) и ASBR2 (10.1.0.2, AS 65001). VRF на ASBR не создаются: он хранит VPNv4-маршруты в таблице BGP и просто передаёт их дальше. Внутри своей AS ASBR1 ведёт обычный iBGP VPNv4 с RR 10.255.0.100. По умолчанию ASBR без VRF отбрасывает маршруты, RT которых не импортируется ни одной VRF; чтобы он их удержал, нужна явная команда: IOS-XE - no bgp default route-target filter, IOS-XR - retain route-target all, VRP - undo policy vpn-target в ipv4-family vpnv4, Junos - keep all на группе (проверьте на своём релизе).
Метки: swap на каждом ASBR
Когда ASBR1 передаёт маршрут PE1 соседу, он ставит себя next-hop (для eBGP это поведение по умолчанию) и выделяет новую VPN-метку. Цепочка для 192.168.10.0/24 (RD 65000:100):
- PE1 анонсирует маршрут с next-hop 10.255.0.1 и VPN-меткой 22.
- ASBR1 получает его от RR, выделяет метку 25 и записывает в LFIB:
25 -> swap 22, push транспортная метка LDP к PE1. - ASBR1 анонсирует маршрут ASBR2 с next-hop 10.1.0.1 и меткой 25.
- ASBR2 выделяет свою метку (например, 31):
31 -> swap 25, отправить на 10.1.0.1, и передаёт маршрут в AS 65001 с next-hop-self и меткой 31.
Обратный путь устроен зеркально. Пакет между ASBR несёт ровно одну метку (VPN-метку, выданную принимающим ASBR); транспортной метки нет, потому что next-hop - непосредственный сосед на линке. Для eBGP-сеанса на подключённом линке интерфейс включается в MPLS командой mpls bgp forwarding (IOS-XE; включается автоматически для eBGP VPNv4-сеанса), mpls на интерфейсе VRP, family mpls на интерфейсе Junos.
Цена Option B
| Параметр | Option B | Следствие |
|---|---|---|
| Состояние на ASBR | все VPNv4-маршруты обеих AS (то, что ASBR решил удержать) | таблица и LFIB растут с числом клиентов |
| Метки на стыке | одна VPN-метка | любой L3/MPLS транспорт, QoS по EXP/TC |
| Согласование | RT клиента должен совпадать или переписываться на ASBR | нужна договорённость о RT между операторами |
| Доверие | сосед может прислать любой RT | обязателен фильтр RT на стыке |
Без фильтра соседний оператор способен прислать маршрут с вашим RT 65000:100 и попасть в чужой VPN. Поэтому на стыке ставят route-map/policy: принимать только согласованные RT и не принимать маршруты с RT, которые используются только внутри AS. Если RT у операторов разные, их переписывают на ASBR (Cisco set extcommunity rt ... additive и delete, Junos community delete/add).
Option C: ASBR без VPN-маршрутов
В Option C (RFC 4364, 10c) ASBR вообще не знают о клиентах. Они обмениваются по eBGP только маршрутами с метками (BGP-LU, AFI 1 / SAFI 4, RFC 8277, ранее 3107) до loopback-адресов PE и RR: 10.255.0.1/32, 10.255.0.100/32 из AS 65000 и 10.254.0.2/32, 10.254.0.100/32 из AS 65001. VPNv4-маршруты обмениваются напрямую между RR (или PE) двух AS multihop eBGP-сеансом loopback-loopback, и RR обязаны сохранять next-hop (next-hop-unchanged у Cisco, multihop no-nexthop-change на Junos, next-hop-invariable на VRP). Тогда next-hop VPN-маршрута - loopback удалённого PE, и этот адрес должен резолвиться в LSP, созданный через BGP-LU.
Стек из трёх меток
Пакет PE1 -> PE3 в Option C: [транспортная метка до ASBR1 | метка BGP-LU к 10.254.0.2/32 | VPN-метка PE3]. Верхняя метка выдаётся LDP/SR внутри AS 65000 и снимается на предпоследнем узле; средняя метка - от ASBR1 (iBGP-LU с next-hop-self, на ASBR1 swap на метку ASBR2); нижняя - VPN-метка PE3. Если ASBR перераспределяет /32 в IGP, а транспортные метки выдаёт LDP, на PE видно только две метки. ASBR1 коммутирует по средней метке и не заглядывает ни в VRF, ни в VPN. Это даёт максимальный масштаб: на ASBR десятки /32, а не миллионы VPN-маршрутов.
Сравнение Option A, B и C
| A | B | C | |
|---|---|---|---|
| Сеансы на стыке | N (по VPN) | 1 eBGP VPNv4 | 1 eBGP LU (+ multihop VPNv4 между RR) |
| Метки на стыке | нет | 1 (VPN) | 1 (LU) + вложенные |
| Состояние ASBR | VRF на клиента | все VPNv4-маршруты | только /32 PE и RR |
| Доверие между операторами | минимальное | среднее (RT-фильтры) | высокое (раскрытие loopback, общий RT) |
| Отладка | простая | средняя | сложная (3 метки, 2 плоскости) |
Отказы и ловушки
- ASBR принимает сеанс, но таблица VPNv4 пуста: нет
no bgp default route-target filter/keep all; маршруты отброшены по RT. - PE1 видит маршрут, но next-hop недостижим: ASBR не поставил next-hop-self в сторону RR, и PE1 получил адрес 10.1.0.2 вне своей IGP.
- Option C: RR получил маршруты, трафик не идёт: потерян
next-hop-unchanged, next-hop стал loopback RR, метки не совпали. - Option C: multihop-сеанс не поднимается: нет маршрута до 10.254.0.100 (BGP-LU не дошёл до RR), TTL 1 вместо
ebgp-multihop. - MTU: Option C добавляет 12 байт (три метки), Option B - 4-8; проверяйте большими пингами с DF.
- Конвергенция: eBGP по умолчанию рассылает обновления с MRAI 30 с (Cisco
advertisement-interval), добавьте BFD на стык.
Схема архитектуры и топология
Option B (eBGP VPNv4 between ASBRs)
+------+ +----------+ eBGP VPNv4 +----------+ +------+
| PE1 |==>| ASBR1 |---------------->| ASBR2 |==>| PE3 |
|AS 1 | | AS 65000 | 1 label (swap) | AS 65001 | | AS 2 |
+------+ +----------+ +----------+ +------+