Для того, чтобы прокинуть L3VPN между разными автономными системами, необходимо использовать опции протокола BGP — A, B или C. Если кто не знает, как работают эти опции, то прошу сюда. У каждой из данных опций есть как плюсы, так и минусы. Остановимся на каждой поподробнее:

Option A.
Смысл данной опции заключается в том, что на ASBR-рах поднимаются отдельные vrf для каждого клиентского vpn и создается сабинтерфейс, через который происходит обмен чистыми ip маршрутами и, через эти же сабинтерфейсы, происходит форвардинг клиентского трафика. Никакого mpls между ASBR нет. Взаимодействие между ASBR происходит, как между PE и CE маршрутизаторами.
Недостатки данной опции более чем очевидны:

— необходимо помимо создания vrf на PE маршрутизаторах, создавать vrf на ASBR-ах;

— для обмена маршрутами между ASBR необходимо в каждой vrf поднимать протокол маршрутизации, естественно большое количество, к примеру, bgp-сессий не благоприятно сказывается на производительности маршрутизатора;

Но, как не удивительно, у данной схемы есть и плюсы:

+ так как между ASBR идет чистый ip трафик, без mpls, то можно реализовать qos и фильтрацию на основе ip заголовка;

+ трафик клиентов четко разделен;

+ данная опция является самой защищенной из всех (к примеру, если вы можете поднять данную опцию между разными провайдерами если не хотите инжектировать чужие маршруты в свою автономную систему).

Но все все таки, минусы в данном случае перевешивают плюсы (представьте, что вам надо прокинуть 50-60 vpn-ов – желание использовать опцию А сразу же отпадает). Поэтому, находясь в своем уме, вряд ли какой то инженер захочет в нынешних условиях поднимать опцию А.

Option B.
Смысл данной опции заключается в том, что ASBR обмениваются vpnv4 маршрутами. Получив vpnv4 маршрут из соседней AS, ASBR генерирует новую метку, ставит next-hop-ом себя (option B-a) или не меняя next-hop (option B-b) передает маршруты на рефлектор (или PE маршрутизаторы сразу, в зависимости от вашей топологии), после чего у всех PE маршрутизаторов есть необходимые vpnv4 маршруты.

Плюсы данного подхода:

+ необходима всего одна BGP vpnv4 сессия для передачи маршрутов между автономными системами, ASBR не нагружен протоколами маршрутизации в vrf;

+ так как все префиксы передается в рамках одной сессии, то данный подход имеет хорошую масштабируемость (в сравнении с опцией А);

+ при включении нового клиента нет необходимости менять конфигурацию на ASBR (кроме фильтров естественно);

Минусы:

— трафик клиентов передается в общем потоке с mpls меткой и применить qos или фильтрацию на основе ip заголовка не представляется возможным;

— ASBR нагружен помимо форвардинга трафика, еще и перевариванием большого количества vpnv4 маршрутов;

Option C.
Смысл данной опции заключается в том, что обмен vpnv4 маршрутами происходит между роутрефлекторами разных автономных систем по ebgp-multihop сессии. ASBR-ры, в свою очередь, передают в соседние автономные системы маршруты с метками (bgp labeled-unicast) до лупбеков роутрефлекторов и PE маршрутизаторов. В итоге с помощью меток, полученных от ASBR, PE маршрутизаторы могут построить end-to-end lsp между собой, а метки vrf между всеми PE маршрутизаторами распределены с помощью роутрефлекторов.

Плюсы данной опции:

+ очень высокую масштабируемость

+ не нагружает ASBR лишней работой (в сравнении с другими опциями)

Но есть и минусы:

— как и в опции В, клиентский трафик между ASBR идет в общем потоке, правда уже с двумя mpls метками, что не дает применить qos и фильтрацию трафика между ASBR на основе ip заголовка.

Как совместить в одном подходе и возможность применения фильтров/qos и в то же время не нагрузить ASBR лишней работой по поддержанию большого количества bgp (ospf, isis, rip)-соседств, а инженеров избавить от сложных конфигураций на ASBR?

Итак, сегодня речь пойдет об inter-AS Option AB (D).

Данная опция, как и опция А, подразумевает создание на ASBR-рах отдельного vrf на каждый vpn, а так же создание отдельного сабинтерфейса в каждом vrf, который будет использоваться для передачи клиентского трафика. Пока что все так же как и в стандартной опции А. Существенное различие в том, что никакой протокол маршрутизации в vrf (на ASBR) не запускается, а созданные сабинтерфейсы используются только для форвардинга трафика. Как же будет производиться обмен маршрутами? Для этой цели, как в опции В, создается единственная vpnv4 сессия между ASBR-ми, по которой и производится передача vpnv4 маршрутов. Собственно, можно сказать, что мы одновременно понимаем и опцию А и опцию В между двумя ASBR. Давайте теперь перейдем к детальному описанию control plane, что бы все встало на свои места:

1. PE2 генерирует vpnv4 маршрут и передает его на роутрефлектор RR2.

2. Роутрефлектор производит валидацию полученного маршрута, и передает его своим клиентам. В нашем случае на ASBR2.

3. ASBR2 получает vpnv4 маршрут и инсталирует его в таблицу маршрутизации соответственного vrf, в нашем случае vrf VPN1-ASBR2, согласно сконфигурированному route-target import.

4. ASBR2 генерирует новый vpnv4 маршрут, навешивает на него excommunity (route-target), которое указано на экспорт в vrf VPN1-ASBR2 и передает маршрут на ASBR1. Next-hop-ом, как и при обычной опции В устанавливается адрес маршрутизатора ASBR2 (адрес интерфейса, который является сорсом для данной vpnv4 сессии).

5. ASBR1, принимает данный маршрут и согласно route-target import, устанавливает данный маршрут в таблицу маршрутизации соответствующего vrf, в нашем случае vrf VPN1-ASBR1, производя замену next-hop, согласно указанному в vrf VPN1-ASBR1 (inter-as hybrid next-hop). Замена производится на адрес ASBR2 (стык ASBR2(vrf VPN1-ASBR2)==> ASBR1 (vrf VPN1-ASBR1)).

6. ASBR1 генерирует новый vpnv4 маршрут, навешивает на него excommunity (route-target), которое указано на экспорт в vrf VPN1-ASBR1 и отправляет маршрут на роутрефлектор RR1 (next-hop — лупбек ASBR1)

7. RR1 анонсирует маршрут на PE1.

8. PE1, получив маршрут от RR1, инсталирует его в таблицу маршрутизации соответствующего vrf.

Основным в данной опции является то, что vpnv4 маршруты на ASBR сначала попадает в vrf и уже из данной vrf анонсируется дальше, причем анонсируется с тем excommunity, которое указанно в vrf на экспорт, и оно может отличаться от того excommunity, c которым данный маршрут изначально анонсировался). Схематично это выглядит вот так:

То есть передача vpnv4 маршрута из одной AS в другую происходит в такой последовательности: PE2==>RR2==>ASBR2==>ASBR2 (vrf VPN1-ASBR2)==>ASBR1==>ASBR1 (vrf VPN1-ASBR1)==>RR1==>PE1.

Итак, рассмотрим все вышесказанное на примере.
На PE2 созданы два vrf:

ip vrf VPN1-CE2
 rd 2:1
 route-target export 2:100
 route-target import 1:100
 route-target import 2:100
!
ip vrf VPN2-CE2
 rd 2:2
 route-target export 2:200
 route-target import 1:200
 route-target import 2:200

Мы будем рассматривать сигнализацию маршрута 10.0.1.0/24 из vrf VPN1-CE2.

Ниже представлен vpnv4, маршрут сгенерированный PE2:

PE2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24
BGP routing table entry for 2:1:10.0.1.0/24, version 2
Paths: (1 available, best #1, table VPN1-CE2)
  Advertised to update-groups:
     3
  Local
    0.0.0.0 from 0.0.0.0 (10.1.10.1)
      Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:2:100 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0
      mpls labels in/out IPv4 VRF Aggr:22/nolabel(VPN1-CE2)

Мы видим, что для PE2 маршрут является локальным и для данного префикса сгенерированна метка 22.

Теперь PE2 должен отправить данный маршрут на роутрефлектор. Проверим:

PE2#show ip bgp vpnv4 rd 2:1 neighbors 10.1.10.10 advertised-routes
BGP table version is 13, local router ID is 10.1.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 2:1 (default for vrf VPN1-CE2)
*> 10.0.1.0/24      0.0.0.0                  0         32768 ?
*> 10.1.1.2/32      10.0.1.2                 2         32768 ?

Total number of prefixes 2

Мы анонсируем два маршрута (10.1.1.2 — это лупбек маршрутизатора VPN1-CE2, который получен через ospf). Дальше маршрут передается на ASBR2:

RR2#sh ip bgp vpnv4 rd 2:1 neighbors 10.1.10.3 advertised-routes | i 10.
BGP table version is 37, local router ID is 10.1.10.10
*>i10.0.1.0/24      10.1.10.1                0    100      0 ?
*>i10.1.1.2/32      10.1.10.1                2    100      0 ?

ASBR2#sh ip bgp vpnv4 rd 2:1 10.0.1.0/24
BGP routing table entry for 2:1:10.0.1.0/24, version 100
Paths: (1 available, best #1, no table)
  Not advertised to any peer
  Local
    10.1.10.1 (metric 3) from 10.1.10.10 (10.1.10.10)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:2:100 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0
      Originator: 10.1.10.1, Cluster list: 10.1.10.10
      mpls labels in/out nolabel/22

У нас не включена опция no bgp default route-target filter, но на ASBR2 созданы vrf:

ip vrf VPN1-ASBR2
 rd 2:10001
 route-target export 2:100
 route-target import 1:100
 route-target import 2:100
 inter-as-hybrid next-hop 10.1.0.1
!
ip vrf VPN2-ASBR2
 rd 2:10002
 route-target export 2:200
 route-target import 1:200
 route-target import 2:200
 inter-as-hybrid next-hop 20.1.0.1

Согласно route-target import 2:100 маршруты попадают в vrf VPN1-ASBR2.

Примечание: в конфигурации vrf появилась новая команда: inter-as-hybrid next-hop. Ее назначение будет рассмотрено далее.

Проверим, установлен ли наш маршрут к сети 10.0.1.0/24 в таблицу маршрутизации vrf VPN1-ASBR2:

ASBR2#sh ip route vrf VPN1-ASBR2 10.0.1.0

Routing Table: VPN1-ASBR2
Routing entry for 10.0.1.0/24
  Known via "bgp 2", distance 200, metric 0, type internal
  Last update from 10.1.10.1 00:50:46 ago
  Routing Descriptor Blocks:
  * 10.1.10.1 (default), from 10.1.10.10, 00:50:46 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0
      MPLS label: 22
      MPLS Flags: MPLS Required

Отлично, маршрут есть. Пока что все как в опции А. Но в опции А дальше мы должны анонсировать чистые ip маршруты из одного vrf в другой с использованием специально запущенного в vrf протокола маршрутизации. Но в опции АВ маршруты между ASBR передаются по bgp vpnv4 сессии между ASBR-ми. Посмотрим, что мы анонсируем на ASBR1 по bgp сессии между ASBR-ми:

ASBR2#sh ip bgp vpnv4 all neighbors 10.2.0.1 advertised-routes
BGP table version is 109, local router ID is 10.1.10.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 2:10001 (default for vrf VPN1-ASBR2)
*>i10.0.1.0/24      10.1.10.1                0    100      0 ?
*>i10.1.1.2/32      10.1.10.1                2    100      0 ?
Route Distinguisher: 2:10002 (default for vrf VPN2-ASBR2)
*>i20.0.1.0/24      10.1.10.1                0    100      0 ?
*>i20.1.1.2/32      10.1.10.1                2    100      0 ?

Total number of prefixes 4

Мы анонсируем 4 маршрута, но у них уже не оригинальный rd. Анонс с PE1 был с rd 2:1, а теперь мы анонсируем маршруты с rd 2:10001. То есть маршрут был заново сгенерирован на ASBR2. Что бы это работало, необходимо в настройках bgp сессии между ASBR дать команду: inter-as-hybrid. Данная команда указывает на то, что данная сессия предназначена для передачи vpnv4 маршрутов для опции AB ( в терминах Сиско — созданный на ASBR vrf называется option AB vrf).

ASBR2#sh configuration | b  address-family vpnv4
 address-family vpnv4
  neighbor 10.1.10.10 activate
  neighbor 10.1.10.10 send-community extended
  neighbor 10.2.0.1 activate
  neighbor 10.2.0.1 send-community extended
  neighbor 10.2.0.1 inter-as-hybrid
 exit-address-family

Продолжим. Проверим маршруты до сети 10.0.1.0/24 на ASBR1:

ASBR1#sh ip bgp vpnv4 all 10.0.1.0/24
BGP routing table entry for 1:10001:10.0.1.0/24, version 98
Paths: (1 available, best #1, table VPN1-ASBR1)
  Advertised to update-groups:
     1
  2, imported path from 2:10001:10.0.1.0/24
    10.1.0.2 (via VPN1-ASBR1) from 10.2.0.2 (10.1.10.3)
      Origin incomplete, localpref 100, valid, external, best
      Extended Community: RT:2:100 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0
      mpls labels in/out 31/19
BGP routing table entry for 2:10001:10.0.1.0/24, version 94
юPaths: (1 available, best #1, no table)
  Not advertised to any peer
  2
    10.2.0.2 from 10.2.0.2 (10.1.10.3)
      Origin incomplete, localpref 100, valid, external, best
      Extended Community: RT:2:100 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0
      mpls labels in/out nolabel/19

В выводе у нас два маршрута, один с next-hop 10.2.0.2 — это оригинальный vpnv4 маршрут, полученный от ASBR2; второй с next-hop 10.1.0.2 (via VPN1-ASBR1) — уже измененный маршрут, который будет использоваться для передачи трафика и инсталироваться в таблицу маршрутизации VPN1-ASBR1.

Прошу обратить внимание на то, что ASBR2 как и положено ASBR-ру в опции В сгенерировал метку: в маршруте на ASBR1 есть метка на out: “mpls labels in/out 31/19”. Но данная метка не будет использована для передачи трафика. Это видно из маршрута, который импортируется в таблицу маршрутизации vrf VPN1-ASBR1: в маршруте mpls метки нет: “MPLS label: none” (см вывод ниже):

ASBR1#sh ip rou vrf VPN1-ASBR1 10.0.1.0

Routing Table: VPN1-ASBR1
Routing entry for 10.0.1.0/24
  Known via "bgp 1", distance 20, metric 0
  Tag 2, type external
  Last update from 10.1.0.2 on GigabitEthernet3/0.10, 01:14:18 ago
  Routing Descriptor Blocks:
  * 10.1.0.2, from 10.2.0.2, 01:14:18 ago, via GigabitEthernet3/0.10
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 2
      MPLS label: none

Замена next-hop была произведена благодаря команде inter-as-hybrid next-hop на ASBR1:

ip vrf VPN1-ASBR1
 rd 1:10001
 route-target export 1:100
 route-target import 1:100
 route-target import 2:100
 inter-as-hybrid next-hop 10.1.0.2

Если данную команду не указать, то в vrf будут импортироваться маршрут с оригинальным next-hop-ом из полученного vpnv4 маршрута от ASBR2 (то есть next-hop-ом будет адрес ASBR2, который используется как сорс для eBGP сессии, как в обычной опции В). В нашем случае на ASBR1 мы имеем вот такие интерфейсы:

ASBR1#sh int description | i Gi3
Gi3/0                          up             up       "to ASBR2 | AS2"
Gi3/0.2                        up             up       "to ASBR2 | vpnv4 routes only"
Gi3/0.10                       up             up       "for VPN1 only"
Gi3/0.20                       up             up       "for VPN2 only"

ASBR1#sh ip int brief | i 3/0
GigabitEthernet3/0         unassigned      YES NVRAM  up                    up
GigabitEthernet3/0.2       10.2.0.1        YES NVRAM  up                    up
GigabitEthernet3/0.10      10.1.0.1        YES NVRAM  up                    up
GigabitEthernet3/0.20      20.1.0.1        YES NVRAM  up                    up

Нам надо что бы трафик vpn1 форвардился через интерфейс GigabitEthernet3/0.10 (соответственно vpn2 — через GigabitEthernet3/0.20). Поэтому в настройках vrf next-hop-ом указан адрес 10.1.0.2 — интерфейс GigabitEthernet3/0.10 на ASBR2, который находится в vrf VPN1-ASBR2:

ASBR2#sh run int gigabitEthernet 3/0.10
Building configuration...

Current configuration : 165 bytes
!
interface GigabitEthernet3/0.10
 description "for VPN1 forwarding"
 encapsulation dot1Q 10
 ip vrf forwarding VPN1-ASBR2
 ip address 10.1.0.2 255.255.255.252
end

Двигаемся дальше. Из vrf VPN1-ASBR1 данный маршрут должен быть анонсирован на роутрефлектор:

ASBR1#sh ip bgp vpnv4 all neighbors 10.0.10.10 advertised-routes
BGP table version is 101, local router ID is 10.0.10.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:10001 (default for vrf VPN1-ASBR1)
*> 10.0.1.0/24      10.1.0.2                               0 2 ?
*> 10.1.1.2/32      10.1.0.2                               0 2 ?
Route Distinguisher: 1:10002 (default for vrf VPN2-ASBR1)
*> 20.0.1.0/24      20.1.0.2                               0 2 ?
*> 20.1.1.2/32      20.1.0.2                               0 2 ?

Total number of prefixes 4

Думаю вы уже заметили, что это новый маршрут, сгенерированный ASBR1, так как вот маршруты, которые ASBR1 получил (обратите внимание на rd):

Route Distinguisher: 2:10001 (default for vrf VPN1-ASBR2)
*>i10.0.1.0/24      10.1.10.1                0    100      0 ?
*>i10.1.1.2/32      10.1.10.1                2    100      0 ?

А вот маршруты, который анонсированы с ASBR1:

Route Distinguisher: 1:10001 (default for vrf VPN1-ASBR1)
*> 10.0.1.0/24      10.1.0.2                               0 2 ?
*> 10.1.1.2/32      10.1.0.2                               0 2 ?

Обратите внимание на rd: был 2:10001, теперь 1:10001. Посмотрим, какие vrf настроены на ASBR1:

ip vrf VPN1-ASBR1
 rd 1:10001
 route-target export 1:100
 route-target import 1:100
 route-target import 2:100
 inter-as-hybrid next-hop 10.1.0.2
!
ip vrf VPN2-ASBR1
 rd 1:10002
 route-target export 1:200
 route-target import 1:200
 route-target import 2:200
 inter-as-hybrid next-hop 20.1.0.2

Думаю теперь понятно, что маршрут был сгенерирован ASBR1.
ASBR1 сгенерировал метку 31 для данного префикса:

RR1#sh ip bgp vpnv4 all 10.0.1.0/24
BGP routing table entry for 1:10001:10.0.1.0/24, version 38
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     1
  2, (Received from a RR-client)
    10.0.10.3 (metric 20) from 10.0.10.3 (10.0.10.3)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:1:100 OSPF DOMAIN ID:0x0005:0x000000020200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.1.1:0
      mpls labels in/out nolabel/31

Далее все стандартно. Маршрут передается c RR1 на PE1:

RR1#sh ip bgp vpnv4 rd 1:10001 neighbors 10.0.10.1 advertised-routes
BGP table version is 41, local router ID is 10.0.10.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:10001
*>i10.0.1.0/24      10.0.10.3                0    100      0 2 ?
*>i10.1.1.2/32      10.0.10.3                0    100      0 2 ?

Total number of prefixes 2

А PE1 инсталирует его таблицу маршрутизации соответствующего vrf:

PE1#sh ip route vrf VPN1-CE1 10.0.1.0

Routing Table: VPN1-CE1
Routing entry for 10.0.1.0/24
  Known via "bgp 1", distance 200, metric 0
  Tag 2, type internal
  Redistributing via ospf 1
  Advertised by ospf 1 subnets
  Last update from 10.0.10.3 01:45:25 ago
  Routing Descriptor Blocks:
  * 10.0.10.3 (default), from 10.0.10.10, 01:45:25 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 2
      MPLS label: 31
      MPLS Flags: MPLS Required

На картинке ниже изображен процесс сигнализирования метки vpn.

Теперь перейдем к data plane. Сделаем трассировку между CE маршрутизаторами:

CE1-VPN1#ping 10.0.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/101/144 ms

CE1-VPN1#traceroute 10.0.1.2

Type escape sequence to abort.
Tracing the route to 10.0.1.2

  1 10.0.0.1 32 msec 12 msec 8 msec
  2 10.0.2.2 [MPLS: Labels 17/31 Exp 0] 48 msec 44 msec 48 msec
  3 10.1.0.1 [MPLS: Label 31 Exp 0] 44 msec 40 msec 12 msec
  4 10.1.0.2 60 msec 48 msec 44 msec
  5 10.1.0.2 [MPLS: Labels 17/22 Exp 0] 72 msec 88 msec 68 msec
  6 10.0.1.1 80 msec 40 msec 56 msec
  7 10.0.1.2 100 msec 84 msec 80 msec

И тоже самое для vpn2:

VPN2-CE1#ping 20.0.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 92/120/144 ms
VPN2-CE1#traceroute 20.0.1.2

Type escape sequence to abort.
Tracing the route to 20.0.1.2

  1 20.0.0.1 64 msec 16 msec 16 msec
  2 10.0.0.2 [MPLS: Labels 16/32 Exp 0] 44 msec 40 msec 40 msec
  3 20.1.0.1 [MPLS: Label 32 Exp 0] 12 msec 28 msec 24 msec
  4 20.1.0.2 52 msec 44 msec 40 msec
  5 10.1.0.2 [MPLS: Labels 17/23 Exp 0] 40 msec 48 msec 64 msec
  6 20.0.1.1 60 msec 48 msec 84 msec
  7 20.0.1.2 76 msec 72 msec 76 msec

PE1 получает IP пакет от клиентского маршрутизатора и согласно своей таблицы маршрутизации производит навешивание двух меток — 31 (метка vrf) и 17 или 16 (транспортная метка до ASBR1 в зависимости от того, как PE1 балансирует трафик):

PE1#sh ip route vrf VPN1-CE1 10.0.1.0

Routing Table: VPN1-CE1
Routing entry for 10.0.1.0/24
  Known via "bgp 1", distance 200, metric 0
  Tag 2, type internal
  Redistributing via ospf 1
  Advertised by ospf 1 subnets
  Last update from 10.0.10.3 01:45:25 ago
  Routing Descriptor Blocks:
  * 10.0.10.3 (default), from 10.0.10.10, 01:45:25 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 2
      MPLS label: 31
      MPLS Flags: MPLS Required

PE1#sh mpls forwarding-table 10.0.10.3
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
18         16         10.0.10.3/32     0             Gi1/0      10.0.0.2
           17         10.0.10.3/32     0             Gi2/0      10.0.2.2

Судя по трассировке выше, PE1 выбирает маршрут через P1.
P1, получив пакет с меткой 17, производит снятие данной (верхней) метки и отправку пакета в интерфейс Gi1/0 (линк в сторону ASBR1):

P1#sh mpls forwarding-table labels 17
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
17         Pop Label  10.0.10.3/32     11590         Gi1/0      10.0.3.1

ASBR1 обрабатывает пакет как обычный PE маршрутизатор — снимает метку и отправляет в интерфейс Gi3/0.10 чистый IP пакет:

ASBR1#sh mpls forwarding-table labels 31
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
31         No Label   10.0.1.0/24[V]   1712          Gi3/0.10   10.1.0.2

Получив данный пакет, ASBR2, работает как PE маршрутизатор, получивший пакет от клиентского CE маршрутизатора — навешивает метку vrf (22) и транспортную метку (17 или 19 — опять эквивалентные пути и судя по трассировке пакет идет на RR2):

ASBR2#  sh ip route vrf VPN1-ASBR2 10.0.1.0

Routing Table: VPN1-ASBR2
Routing entry for 10.0.1.0/24
  Known via "bgp 2", distance 200, metric 0, type internal
  Last update from 10.1.10.1 01:51:32 ago
  Routing Descriptor Blocks:
  * 10.1.10.1 (default), from 10.1.10.10, 01:51:32 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0
      MPLS label: 22
      MPLS Flags: MPLS Required

ASBR2#sh mpls forwarding-table 10.1.10.1
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
23         17         10.1.10.1/32     0             Gi1/0      10.1.0.2
           19         10.1.10.1/32     0             Gi2/0      10.1.2.2

RR2, как и положено транзитному mpls маршрутизатору на предпоследнем хопе, снимает верхнюю метку и отправляет пакет на PE2:

RR2#sh mpls forwarding-table labels 17
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
17         Pop Label  10.1.10.1/32     7242          Gi2/0      10.1.1.1

Ну а PE2 знает, что метка 22 указывает на то, что надо сделать ip lookup в vrf VPN1-CE2:

PE2#show mpls forwarding-table labels 22
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
22         Pop Label  IPv4 VRF[V]      8150          aggregate/VPN1-CE2

Далее пакет улетает на клиентский CE маршрутизатор. Все метки и операции с ними представлены на рисунке ниже.

В итоге мы получили гибрид опции А и В, в которой мы можем использовать qos и фильтрацию клиентского трафика между ASBR-рами как в опции А, но в тоже время хоть нам и придется сконфигурировать vrf для каждого vpn на ASBR и сделать отдельный стык, но нет необходимости в отдельном процессе протокола маршрутизации в каждом vrf, что естественно снижает нагрузку на ASBR, который, как в опции В, должен поддерживать всего одну vpnv4 сессию с соседним ASBR-ом.

Ну и в конце хотелось бы акцентировать внимание на двух важных командах:

inter-as-hybrid next-hop в иерархии ip vrf — данная команда необходима для подмены next-hop, если ее не указать, то в vrf будет импортироваться маршрут с next-hop в стык, на котором запущена опция В.

neighbor 10.2.0.1 inter-as-hybrid — данная команда указывает на то, что между пирами установлена bgp сессия для обмена vpnv4 маршрутами для Inter-AS Option AB. Данная команда дает возможность сначала импортировать маршруты в vrf, а потом экспортировать маршруты из этого vrf дальше (меняя rd и при необходимости community).

Важно, что обе эти опции должны быть включены, иначе у вас или ничего не заработает или заработает, но не так как должно работать.

В настоящее время есть только драфт RFC, посвященный опции AB. В данной статье мы познакомились с опцией АВ на примере реализации ее компанией Cisco. Пишите в личку если найдете какие либо недостатки или считаете, что что то надо дополнить/описать получше.

Всем спасибо за внимание!