Теоретические основы и архитектура
Межоператорское взаимодействие Inter-AS Option A (Back-to-Back VRF, RFC 4364) соединяет пограничные маршрутизаторы двух независимых автономных систем (ASBR) через набор выделенных логических сабинтерфейсов или физических каналов, по одному на каждый клиентский VRF. Между ASBR не используется MPLS: стык выглядит как обычное классическое IP-соединение, на котором запускается локальный протокол маршрутизации (обычно eBGP или статическая маршрутизация в рамках каждого VRF). Плюсы Option A: максимальная простота конфигурации, независимость адресных пространств операторов, отсутствие необходимости согласовывать LDP или MP-BGP между операторами и строгая безопасность. Минусы: плохая масштабируемость — для добавления каждого нового VPN требуется проброс отдельного VLAN между ASBR и создание отдельной сессии маршрутизации, что перегружает ресурсы памяти и процессора пограничных узлов при сотнях клиентов.
Идея Option A: два PE, склеенные кабелем
Inter-AS Option A (RFC 4364, раздел 10, вариант "a") не вводит новых протоколов. ASBR1 в AS 65000 и ASBR2 в AS 65001 - обычные PE, у каждого свои VRF клиента; между собой они соединены интерфейсами, и для ASBR1 соседний ASBR2 выглядит как CE, и наоборот. Поэтому схему называют back-to-back VRF: каждому VPN выделяется отдельный (под)интерфейс и отдельный сеанс маршрутизации (eBGP, OSPF или статика) внутри VRF. Операторам не нужно согласовывать ни RD, ни RT, ни MPLS на стыке: у AS 65000 клиент A живёт с RD/RT 65000:100, у AS 65001 - с 65001:100, и эти значения друг с другом никак не связаны.
Плоскость управления
Маршрут клиента A 192.168.20.0/24 проходит такой путь:
- CE2 -> PE3 (AS 65001): обычный PE-CE протокол.
- PE3 -> ASBR2: MP-iBGP VPNv4 (RD 65001:100, RT 65001:100, метка VPN).
- ASBR2 импортирует маршрут в VRF CUST-A по RT, затем анонсирует его соседу 10.1.100.1 как обычный IPv4 префикс (eBGP внутри VRF, AS_PATH 65001 ...).
- ASBR1 принимает префикс в VRF CUST-A, добавляет RD 65000:100 и экспортирует его в VPNv4 с RT 65000:100 к RR 10.255.0.100.
- PE1 импортирует его в свою VRF и отдаёт CE1.
На шагах 3-4 информация о RD/RT/VPN-метках чужой AS теряется: ASBR - это граница ответственности, здесь VPN-информация "отрезается".
Плоскость данных
Пакет 192.168.10.5 -> 192.168.20.7 летит по AS 65000 со стеком [транспортная LDP | VPN-метка ASBR1]. На ASBR1 транспортная метка уже снята (PHP на предпоследнем узле), по VPN-метке выбирается VRF CUST-A, и пакет уходит в VLAN 100 без единой метки: Outgoing label = No Label. ASBR2 принимает чистый IPv4, делает IP lookup в своей VRF CUST-A и навешивает стек AS 65001. Следствия: на стыке работает любой L3-коммутатор или firewall, QoS-политика строится по DSCP (EXP/TC не пересекают границу) и MTU стыка равен обычному IP MTU плюс 4 байта VLAN-тега, но не плюс метки.
Что реально масштабируется плохо
| Ресурс | Расход на 1 VPN | Что происходит при 500 VPN |
|---|---|---|
| Сабинтерфейс / VLAN | 1 | 802.1Q даёт 4094 VLAN на порт, дальше нужен QinQ или новый порт |
| BGP-сеанс | 1 | 500 сеансов keepalive 60 c / hold 180 c на каждом ASBR |
| VRF и таблицы | 1 | память под полную копию префиксов каждого клиента |
| Провижининг | 2 ASBR x (VRF + sub-if + BGP) | рост ошибок конфигурации, нужна автоматизация |
Отдельный минус - отказ физического линка роняет сразу все VPN; его компенсируют LAG или двумя независимыми линками и BFD на сеансах.
eBGP в VRF и петли AS_PATH
Если у клиента один и тот же номер AS на обоих сайтах (например, AS 65100), маршрут от CE2 попадает к CE1 с AS_PATH 65000 65001 65100, и CE1 отбрасывает его по loop prevention. Решения: neighbor ... as-override на PE1/PE3 (Cisco; Huawei - peer ... substitute-as, Junos - as-override в группе) либо allowas-in на CE. Это не специфика Option A, но на стыке AS проблема заметнее: цепочка AS_PATH длиннее. Для статики и IGP эта проблема отсутствует, но тогда ASBR должен перераспределять маршруты в BGP VRF.
Метки на ASBR: per-prefix и per-VRF
Cisco по умолчанию выделяет VPN-метку на каждый префикс (per-prefix). Для префикса, полученного по eBGP от ASBR2, метка указывает прямо на next-hop 10.1.100.2 - без второго lookup. Режим per-VRF (mpls label mode vrf CUST-A protocol bgp-vpnv4 per-vrf) экономит метки, но требует IP lookup в VRF при приёме. Junos аналогично: по умолчанию метка на next-hop, vrf-table-label включает lookup в VRF (нужен, например, если на egress нужна фильтрация по VRF).
Безопасность стыка
В Option A ASBR видит только IPv4 префиксы клиента и не доверяет соседнему оператору: на каждом сеансе ставят maximum-prefix (Huawei - route-limit, Junos - prefix-limit), фильтры по ожидаемым префиксам клиента и защиту сеанса (MD5/TCP-AO, GTSM ttl-security). Нет RT и меток на стыке - значит, оператор не может "залить" чужие VPN-маршруты в вашу VRF через подмену RT. Это главное достоинство Option A и причина, по которой её выбирают между недоверяющими друг другу операторами.
Option AB (гибрид)
Для случаев, когда масштаб Option A мал, а изоляция Option B недостаточна, существует гибрид (у Cisco - Inter-AS Option AB, в части документов - "Option D"): control plane устроен как Option B (единый сеанс VPNv4 между ASBR), а data plane - как Option A (отдельный интерфейс на VRF, IP lookup в VRF). Реализация и название зависят от платформы; в этом курсе он только упоминается, проверяйте поддержку на своём оборудовании.
