Pull to refresh

BGP Inter-AS

Reading time 28 min
Views 65K
Сегодня речь пойдет о «межоператорском» взаимодействии — BGP Inter-AS. Эти опции используют при необходимости прокинуть L3vpn между PE маршрутизаторами, находящимися в разных автономных системах. Стоит уточнить, что данные опции используются по большей части внутри компаний при поглощении/слиянии сетей, для взаимодействия между филиалами одной компании если они имеют свои автономные системы и свои mpls домены.
В статье рассмотрим следующие темы:
— BGP Inter-AS Option A
— BGP Inter-AS Option B
— BGP Inter-AS Option C
— Особенности настройки данных опций на JunOS
В данной статье будет много выводов из CLI Cisco и Juniper. Если вы не знаете основ mpls, разницы между bgp labeled-unicast и vpnv4 unicast, то читать данную статью вам нет смысла. Если же эти понятия вам знакомы, то прошу под кат.

Примечание: в приведенных схемах левая часть состоит из маршрутизаторов под управлением JunOS (кроме CE), в правой части Cisco IOS15.

Ну и начнем с самого банального — Option A.
Смысл данной опции заключается в том, что на ASBR-рах создаются VRF на каждый VPN и поднимаются отдельные сабинтерфейсы с соседней AS. Таким образом ASBR-ры взаимодействуют как CE-PE маршрутизаторы, обмениваясь чистыми IP маршрутами. В данной опции между ASBR-ми нет MPLS — только чистый IP трафик:

Разберем поподробнее как работает control plane:

1. PE1 генерирует vpnv4 маршрут и отдает его по MP-BGP на роутрефлектор (RR1).

2. Роутрефлектор имеет vpnv4 сессию с ASBR1, в рамках которой отдает ему полученный от PE1 vpnv4 маршрут.

3. Так как на ASBR1 тоже создан VRF (в нашей топологии на ASBR1 CE1 и CE3, а на ASBR2 — CE2 и CE4), то он принимает маршрут и инсталирует его в таблицу маршрутизации соответствующей vrf.

4. ASBR1 передает на ASBR2 уже чистый IP марушрут (протокол маршрутизации может быть любым, от RIP до BGP). Тут работает взаимодействие по типу от CE к PE, где ASBR1 будет выполнять роль CE маршрутизатора, отдавая IP префикс, а ASBR2 — PE маршрутизатора, получая префикс и генерируя vpnv4 префикс для своей AS. (маршруты передаются с обоих сторон, поэтому оба ASBR выполняют роль и CE и PE маршрутизатора).

5. ASBR2, получив IP префикс, генерирует vpnv4 префикс и отдает его на свой роутрефлектор (RR2).

6. PE2 получает от роутрефлектора по vpnv4 сессии данный префикс и инсталирует его в таблицу маршрутизации соответствующего vrf, предварительно проверив достижимость next-hop и соответствие rt в маршруте сконфигурированному на маршрутизаторе vrf-import.

Теперь перейдем к data plane:

1. PE1 получает пакет от CE1, навешивает на него метку (метку vrf), полученную от ASBR1, транспортную метку до ASBR1 (полученную по ldp) и отправляет в соответствующий интерфейс.

2. P1 получив пакет от PE1 со стеком из 2-x меток производит снятие верхней транспортной метки (php) и отправку пакета на ASBR1.

3. ASBR1 получает пакет с одной меткой (меткой vrf), и действует как обычный PE маршрутизатор, терминирующий клиентский CE маршрутизатор — снимает метку и отправляет пакет в соответствующий интерфейс, но так как роль CE маршрутизатора в данном сценарии выполняет ASBR2, то чистый IP пакет отправляется в стык c ASBR2.

4. ASBR2 получает данный пакет и работает как обычный PE маршрутизатор – добавляет метку vrf (полученную от PE2), транспортную метку до PE2 (полученную по ldp) и отправляет в соответствующий интерфейс.

5. P2 производит снятие транспортной метки (php).

6. PE2 получает пакет с одной меткой (меткой vrf, которую сам и сгенерировал), снимает ее, делает ip lookup и отправляет пакет согласно таблицы маршрутизации соответствующего vrf.

Теперь посмотрим на практике, какие операции с метками будут производиться.
Ниже представлены конфигурации BGP на ASBR-рах:
bormoglotx@ASBR1> show configuration routing-instances CE1
instance-type vrf;
interface ge-0/0/3.0;
route-distinguisher 1:2;
vrf-target {
    import target:1:100;
    export target:1:100;
}
vrf-table-label;
protocols {
    bgp {
        group AS64999 {
            type external;
            local-address 10.2.0.1;
            peer-as 64999;
            local-as 65000;
            neighbor 10.2.0.2;
        }
    }
}

ASBR2#sh configuration | b ip vrf
ip vrf CE2
 rd 2:2
 route-target export 2:100
 route-target import 2:100

ASBR2#sh configuration | b address-family ipv4
 address-family ipv4 vrf CE2
  no synchronization
  neighbor 10.2.0.1 remote-as 65000
  neighbor 10.2.0.1 local-as 64999
  neighbor 10.2.0.1 activate
 exit-address-family

Все, как видите, как у обычного PE маршрутизатора, ничего криминального.

Примечание: есть несколько нюансов касаемо протоколов маршрутизации. Если вы используете BGP, то, возможно, вам придется воспользоваться командой loops 2, если вы будете связывать два сайта клиента с одинаковыми номерами автономных систем, а если у вас везде будет, к примеру, OSPF, то не стоит забывать про DN-бит. Каждый отдельный случай необходимо рассматривать отдельно.

Итак, мы создали vrf CE1 на PE1 и ASBR1, и vrf CE2 на PE2 и ASBR2, как показано на схеме. Экспорт и импорт vpnv4 маршрутов возможен только между данными vrf-ми внутри автономной системы. Между автономными системами маршрутами обмениваются только ASBR-ры (и то ipv4 unicast). Проверим связность между клиентскими маршрутизаторами CE1 и CE2:
R5#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 = 60/70/84 ms

Все отлично, связность есть. Теперь рассмотрим, какие будут происходить операции с метками по ходу продвижения пакета.
Итак, сморим маршрут на PE1:
bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/24

CE1.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/24        *[BGP/170] 00:03:29, localpref 100, from 10.0.10.10
                      AS path: 65000 64999 2 ?
                    > to 10.0.2.2 via ge-0/0/0.0, Push 16, Push 299824(top)

PE1 навешивает две метки:

16 — метка vrf, полученную через RR1 от ASBR1
299824 — транспортная метка, полученная по протоколу ldp

и отправляет пакет в интерфейс ge-0/0/0.0 в сторону P1.
P1 согласно таблице mpls.0 (так как он транзитный маршрутизатор) производит снятие верхней метки (отрабатывает механизм php) и отправляет данный пакет на ASBR1:
bormoglotx@P1> show route table mpls.0 label 299824

mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299824             *[LDP/9] 00:41:16, metric 1
                    > to 10.0.3.1 via ge-0/0/1.0, Pop
299824(S=0)        *[LDP/9] 00:41:16, metric 1
                    > to 10.0.3.1 via ge-0/0/1.0, Pop

ASBR1 снимает метку vrf и делает ip lookup в таблице CE1.inet.0 (не забываем давать команду vrf-table-label на JunOS):
bormoglotx@ASBR1> show route table mpls.0 label 16

mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

16                 *[VPN/0] 00:35:23
                      to table CE1.inet.0, Pop

bormoglotx@ASBR1> show route table CE1.inet.0 10.0.1.0/24

CE1.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/24        *[BGP/170] 00:05:41, localpref 100
                      AS path: 64999 2 ?
                    > to 10.2.0.2 via ge-0/0/3.0

Пакет от ASBR1 передается через интерфейс ge-0/0/3 на ASBR2 без mpls заголовка — только чистый ip трафик (обычно тегированный, в нашем случае всего одни vrf, поэтому я не стал делать сабинтерфейсы, когда у вас будет несколько vrf, вам придется делать отдельный сабинтерфейс на каждый vpn и указывать его в настройках vrf).
ASBR2, получив IP пакет, ищет маршрут в таблице маршрутизации vrf CE2:
ASBR2#show ip route vrf CE2 10.0.1.0
Routing Table: CE2
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:20:49 ago
  Routing Descriptor Blocks:
  * 10.1.10.1 (default), from 10.1.10.10, 00:20:49 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
21         18         10.1.10.1/32     0             Gi1/0      10.1.0.2
           17         10.1.10.1/32     0             Gi2/0      10.1.2.2

Согласно маршрута, ASBR2 навешивает метку vrf (22), полученную по bgp vpnv4 от PE2 и отправляет в lsp на PE2 (10.1.10.1). Next-hop-ом в маршруте указан P2 или RR2 (в нашем случае рефлектор работает как P-маршрутизатор). Мы предположим, что трафик пойдет через P2 и будем смотреть операции с метками на нем. P2 получает пакет с двумя метками 22 и 17, смотрит в mpls forwarding-table:
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.1.10.1/32     18542         Gi1/0      10.1.3.1

Согласно mpls forwarding-table, P2 снимает верхнюю метку (опять php) и отправляет пакет на PE2.

PE2 видит, что эта метка указывает на vrf CE2, производит ip lookup в таблице vrf CE2 и отправляет чистый ip пакет клиенту:
PE2#sh mpls forwarding-table labels 22
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
22         No Label   10.0.1.0/24[V]   14450         aggregate/CE2

PE2#sh ip rou vrf CE2 10.0.1.0

Routing Table: CE2
Routing entry for 10.0.1.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via bgp 2
  Advertised by bgp 2
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet3/0.10
      Route metric is 0, traffic share count is 1

Понятно, что данное решение масштабируется довольно-таки сложно. Если вы подключаете нового клиента, то вам надо будет создать vrf не только на PE маршрутизаторе, на котором данный клиент будет терминироваться, а еще и на ASBR (причем с ответной стороны должны будут сделать то же самое). Естественно, это решение не удовлетворяет сегодняшние запросы операторов связи, поэтому мы перейдем к рассмотрению более интересных решений — опции В и С.

Option B.

Между ASBR поднимается vpnv4 сессия, в рамках которой производится обмен vpnv4 маршрутами (естественно необходимо настраивать фильтрацию на ASBR отдаваемых и получаемых префиксов, что бы не отдать или не получить что-то лишнее). Но мы знаем, что маршрутизатор отбрасывает vpnv4 маршруты (исключение маршрутизаторы Juniper), если у него нет VRF, которому (-ым) эти маршруты предназначены (если указанного в NLRI route-target нет ни в одном из vrf на import). Чтобы изменить это дефолтное поведение на ASBR необходимо разрешить прием всех vpnv4 маршрутов ( keep all — Juniper, no bgp default route-target filter — IOS, retain route-target all — IOS XR, undo policy vpn-target — Huawei).

Примечание: на маршрутизаторах Juniper нет необходимости в команде keep all, так как при конфигурировании eBGP vpnv4 сессии, маршрутизатор автоматически считает себя ASBR-ром для опции В, поэтому принимает и инсталирует все полученные от пиров vpnv4 маршруты в таблицу bgp.l3vpn.0 и передает данные маршруты своим пирам.

Итак, начнем с control plane:

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

2. Роутрефлектор RR2 пересылает данный маршрут всем своим клиентам.

3. ASBR2, являясь клиентом роутрефлектора, получает сгенерированный PE2 vpnv4 маршрут. Так как на нем включена опция no bgp default route-target filter, ASBR2 инсталирует полученный маршрут в таблицу маршрутизации.

4. ASBR2 меняет в полученном от роутрефлектора маршруте next-hop на себя, генерирует новую метку (причем значение метки может и не поменяться) и отправляет этот маршрут на ASBR1 по ebgp vpnv4 сессии.

5. ASBR1 принимает vpnv4 маршрут от ASBR2 и инсталирует его в табилицу маршрутизации bgp.l3vpn.0.

6. ASBR1 меняет в полученном от ASBR2 маршруте next-hop на себя, генерирует новую mpls метку и отправляет данный маршрут на RR1.

7. RR1, получив данный маршрут проверяет доступность next-hop, as-path (стандартный механизм выбора лучшего маршрута bgp) и инсталирует данный маршрут в свою таблицу маршрутизации.

8. RR1 передает полученный от ASBR1 маршрут на PE1.

9. PE1, получив от роутрефлектора vpnv4 маршрут, проверяет доступность next-hop, проверяет соответствует ли extcommunity (rt) в полученном маршруте сконфигрурированному на маршрутизаторе vrf-import и инсталирует его в таблицу маршрутизации соответствующего vrf.

Транспортные метки до ASBR внутри AS распределеяются стандартным способом — LDP или RSVP-TE.

Теперь рассмотрим все вышесказанное на примере:

Рассмотрим как будет происходить сигнализация метки для клиентского префикса 10.0.1.0/24, который терминируется на PE2 vrf CE2:
PE2#sh ip route vrf CE2 10.0.1.0
Routing Table: CE2
Routing entry for 10.0.1.0/24
 Known via "connected", distance 0, metric 0 (connected, via interface)
 Redistributing via bgp 2
 Advertised by bgp 2
 Routing Descriptor Blocks:
 * directly connected, via GigabitEthernet3/0.10
     Route metric is 0, traffic share count is 1

PE2 генерирует vpnv4 маршрут и отдает его по iBGP на роутрефлектор RR2:
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 CE2)
 Advertised to update-groups:
    1
 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: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 17/nolabel(CE2)

Согласно выводу выше, для данного префикса сгенерирована метка 17: mpls labels in/out 17/nolabel(CE2)
Далее PE2 отдает vpnv4 маршруты на роутрефлектор. Маршрутов два, так как один это сеть между PE2 и CE2, а второй – лупбек клиентского маршрутизатора CE2.
PE2#sh ip bgp vpnv4 all neighbors 10.1.10.10 advertised-routes
BGP table version is 39, 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 CE1)
*> 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

Роутрефлектор RR2 передает полученный от PE2 vpnv4 маршрут своим клиентам, включая ASBR2:
RR2#sh ip bgp vpnv4 rd 2:1 neighbors 10.1.10.3 advertised-routes
BGP table version is 21, local router ID is 10.1.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: 2:1
*>i10.0.1.0/24      10.1.10.1                0    100      0 ?
*>i10.1.1.2/32      10.1.10.1                2    100      0 ?
 
Total number of prefixes 2

ASBR2 принимает данный маршрут и инсталирует его в таблицу маршрутизации:
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 4
Paths: (1 available, best #1, no table)
 Advertised to update-groups:
    1
 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:1: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 26/17

Обращаем внимание на строку «mpls labels in/out 26/17». ASBR2 генерирует новую метку на in – 26 и отправляет все имеющиеся у него vpnv4 маршруты (или не все если настроена фильтрация на out) в соседнюю AS на ASBR1:
ASBR2#sh ip bgp vpnv4 rd 2:1 neighbors 10.2.0.1 advertised-routes
BGP table version is 13, 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:1
*>i10.0.1.0/24      10.1.10.1                0    100      0 ?
*>i10.1.1.2/32      10.1.10.1                2    100      0 ?
 
Total number of prefixes 2

ASBR1 принимает эти маршруты и инсталирует в таблицу маршрутизации:
bormoglotx@ASBR1> show route receive-protocol bgp 10.2.0.2 10.0.1.0/24 10.0.1.0/24 detail
 
inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
 
bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 2:1:10.0.1.0/24 (1 entry, 1 announced)
    Accepted
    Route Distinguisher: 2:1
    VPN Label: 26
    Nexthop: 10.2.0.2
    AS path: 2 ?
    Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0

Помимо того, что ASBR2 сгенерировал новую метку, он так же и изменил next-hop на себя (Nexthop: 10.2.0.2).
ASBR1 генерирует новую метку (VPN Label: 299888) до префикса 10.0.1.0/24, меняет next-hop на себя (Nexthop: Self) и отдает маршрут на роутрефлектор RR1
bormoglotx@ASBR1> show route advertising-protocol bgp 10.0.10.10 10.0.1.0/24 detail
 
bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 2:1:10.0.1.0/24 (1 entry, 1 announced)
BGP group RR type Internal
    Route Distinguisher: 2:1
    VPN Label: 299888
    Nexthop: Self
    Flags: Nexthop Change
    Localpref: 100
    AS path: [1] 2 ?
    Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0

Роутрефлектор RR1 отдает маршрут своим клиентам, включая и PE1:
bormoglotx@PE1> show route receive-protocol bgp 10.0.10.10 10.0.1.0/24 detail
 
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
 
CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
* 10.0.1.0/24 (1 entry, 1 announced)
    Import Accepted
    Route Distinguisher: 2:1
    VPN Label: 299888
    Nexthop: 10.0.10.3
    Localpref: 100
    AS path: 2 ? (Originator) Cluster list:  10.0.10.10
    AS path:  Originator ID: 10.0.10.3
    Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
 
* 2:1:10.0.1.0/24 (1 entry, 0 announced)
    Import Accepted
    Route Distinguisher: 2:1
    VPN Label: 299888
    Nexthop: 10.0.10.3
    Localpref: 100
    AS path: 2 ? (Originator) Cluster list:  10.0.10.10
    AS path:  Originator ID: 10.0.10.3
    Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0

Маршрут мы видим в двух таблицах: в таблице vrf CE1.inet.0 и в таблице bgp vpnv4 маршрутов bgp.l3vpn.0.
Получая vpnv4 маршруты, JunOS проверяет их на пригодность (AS-PATH, доступность next-hop), есть ли указанные в vpnv4 маршруте excommunity в конфиграциях routing instance на import, и если маршрут проходит данные проверки и выбирается лучшим согласно штатному алгоритму выбора bgp best path, он инсталируется на таблицу bgp.l3vpn.0. И уже из этой таблицы ip префикс переносится в таблицу vrf (CE1.inet.0 в нашем случае).

Data-plane:

С сигнализацией меток мы разобрались. Теперь рассмотрим data plane, то есть как будет пересылаться пакет от CE1 (с 10.0.0.2) к CE2 (10.0.1.2) через “mpls облако”.
Для начала запустим пинг между CE маршрутизаторами и убедимся, что связность между хостами есть:
CE1#ping 10.0.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/91/132 ms

Теперь сделаем трассировку:
R5#traceroute 10.0.1.2 numeric timeout 1
 
Type escape sequence to abort.
Tracing the route to 10.0.1.2
 
 1 10.0.0.1 32 msec 4 msec 12 msec
 2 10.0.2.2 [MPLS: Labels 299792/299888 Exp 0] 48 msec 68 msec 52 msec
 3 10.0.3.1 [MPLS: Label 299888 Exp 0] 48 msec 60 msec 52 msec
 4 10.2.0.2 [MPLS: Label 26 Exp 0] 64 msec 52 msec 52 msec
 5 10.1.0.2 [MPLS: Labels 19/17 Exp 0] 48 msec 60 msec 52 msec
 6 10.0.1.1 52 msec 52 msec 56 msec
 7 10.0.1.2 48 msec 64 msec 108 msec

Видно, что максимальное количество меток — 2.

Примечание: их может быть и больше, если вы используете traffic-engineereng. В нашем случае метки распределяет только ldp.

Теперь разберемся с операциями над метками при движении пакета по сети.
На PE1 с клиентского маршрутизатора CE1 прилетает чистый IP пакет (в нашем случае с vlan тегом 10, но это не имеет значения, так как это l3vpn и тег снимается). Маршрут на PE1 говорит о том, что пакет необходимо отправить в mpls тоннель. PE1 навешивает две метки: метку vrf — 299888 (которую мы получили от ASBR1) и транспортную метку до ASBR1 – 299792 (полученную по протоколу ldp):
bormoglotx@PE1> show route table CE1.inet.0 10.0.1.2
 
CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
10.0.1.0/24        *[BGP/170] 00:15:32, localpref 100, from 10.0.10.10
                     AS path: 2 ?
                     to 10.0.2.2 via ge-0/0/0.0, Push 299888, Push 299792(top)
                   > to 10.0.0.2 via ge-0/0/1.0, Push 299888, Push 299792(top)

bormoglotx@PE1> show interfaces descriptions
Interface       Admin Link Description
ge-0/0/0        up    up   to P1
ge-0/0/1        up    up   to RR1
ge-0/0/3        up    up   to SW1
lo0             up    up   router-id

PE1 отправляет данный пакет в интерфейс ge-0/0/1 в сторону RR1 (в нашем случае роутрефлектор выполняет функцию и P-маршрутизатора).
RR1 получает пакет со стеком меток и анализирует верхнюю метку 299792:
bormoglotx@RR1> show route table mpls.0 label 299792
 
mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
299792             *[LDP/9] 01:19:34, metric 1
                   > to 10.0.1.1 via ge-0/0/0.0, Pop
299792(S=0)        *[LDP/9] 01:19:34, metric 1
                   > to 10.0.1.1 via ge-0/0/0.0, Pop

Согласно таблице mpls.0, RR1 производит снятие метки (php) и отправку пакета в интерфейс ge-0/0/0.0 в сторону ASBR2.
ASBR2 получает паект только с одной меткой 299888. Смотрим, что он должен сделать:
bormoglotx@ASBR1> show route table mpls.0 label 299888
 
mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
299888             *[VPN/170] 00:17:02
                   > to 10.2.0.2 via ge-0/0/3.0, Swap 26

ASBR1 делает своп метки 299888 на метку 26 и отправляет пакет через стык с AS2 на ASBR2.

Далее ASBR2 тоже производит своп метки 26 на метку 17 (он ее получил от PE2)
ASBR2#show ip bgp vpnv4 rd 2:1 10.0.1.0/24
BGP routing table entry for 2:1:10.0.1.0/24, version 4
Paths: (1 available, best #1, no table)
 Advertised to update-groups:
    1
 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:1: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 26/17

Итак как в маршруте next-hop-ом является 10.1.10.1, то ASBR2 должен добавить еще и транспортную метку (19) до PE2:
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         19         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 или P2, так как пути равнозначны… Посмотрим, что будет делать с данным пакетом P2:
P1#sh mpls forwarding-table labels  19
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
19         Pop Label  10.1.10.1/32     1180          Gi1/0      10.1.3.1

P2 производит снятие метки и отправляет пакет с одной меткой на PE2.

PE2 получает пакет с единственной меткой 17, которая и является меткой vrf. В данном случае используется распределение меток на префикс (одна метка – одни префикс клиента), что в реальной жизни естественно слишком расточительно, поэтому режим распределения меток необходимо переключить – per-vrf (одна метка на vrf). В отличии же от Cisco, в JunOS дефолтный механизм распределения меток – per-next-hop. Если у клиента Ethernet линк, что естественно будет в подавляющем большинстве случаев, то необходимо включить генерацию меток per-vrf командой vrf-table-label. Принцип обработки пакета в данном случае меняется, и достоин отдельной статьи.
PE2#show mpls forwarding-table labels 17
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
17         No Label   10.0.1.0/24[V]   0             aggregate/CE1

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 CE1)
 Advertised to update-groups:
    1
 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: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 17/nolabel(CE1)

Согласно представленной выше информации, PE2 снимает метку 17, делает ip lookup в таблице vrf CE1 и отправляет пакет клиенту.

Конфигурации ASBR:
bormoglotx@ASBR1# show
keep all;
group RR {
    type internal;
    local-address 10.0.10.3;
    family inet-vpn {
        unicast;
    }
    export NHS;
    neighbor 10.0.10.10;
}
group ASBR-AS2 {
    type external;
    local-address 10.2.0.1;
    family inet-vpn {
        unicast;
    }
    peer-as 2;
    neighbor 10.2.0.2;
}


ASBR2#sh configuration | b router bgp
router bgp 2
 no synchronization
 no bgp default route-target filter
 bgp log-neighbor-changes
 neighbor 10.1.10.10 remote-as 2
 neighbor 10.1.10.10 description RR2
 neighbor 10.1.10.10 update-source Loopback0
 neighbor 10.2.0.1 remote-as 1
 neighbor 10.2.0.1 description ASBR1 | AS2
 neighbor 10.2.0.1 update-source GigabitEthernet3/0
 no auto-summary
 !
 address-family vpnv4
  neighbor 10.1.10.10 activate
  neighbor 10.1.10.10 send-community extended
  neighbor 10.1.10.10 next-hop-self
  neighbor 10.2.0.1 activate
  neighbor 10.2.0.1 send-community extended
 exit-address-family

ASBR2#sh run int gi3/0
Building configuration...

Current configuration : 143 bytes
!
interface GigabitEthernet3/0
 description to ASBR1 | AS1
 ip address 10.2.0.2 255.255.255.252
 negotiation auto
 mpls bgp forwarding
 !
end

Хотелось бы добавить, что бывает два вида Option B. Мы рассмотрели первый способ — самый распространенный — ASBR производит подмену next-hop при передаче маршрута внутрь автономной системы (при передаче маршрута на рефлектор). Второй способ заключается в том, что ASBR, как положено для ibgp сессии, при анонсировании маршрута на рефлектор не производил подмену next-hop на свой адрес. Но тогда сеть между ASBR должна быть анонсирована в IGP (можно линк между ASBR сделать passive интерфейсом или прописать на ASBR статику и сделать ее редистрибуцию в IGP). Это необходимо для того, что бы PE маршрутизаторы могли установить BGP маршрут в свои таблицы (проверка доступности next-hop) а ldp сгенерировал метку до данного префикса.

С Option B думаю разобрались. Перейдем к Option С.

Option C

Обмен vpnv4 маршрутами производится между роутрефлекторами разных AS напрямую по ebgp-multihop сессии, а на ASBR-ры ложится задача по распределению маршрутов с mpls метками до лупбеков роутрефлекторов и PE маршрутизаторов соседней автономной системы.

Рассмотрим как работает control plane:

Распределение транспортных меток:

1. ASBR2 по протоколу ldp получает от своих соседей метку до PE2.

2. ASBR2 согласно настроенной политике генерирует маршруты с метками до лубеков своей автономной системы и по bgp labeled-unicast передает данные маршруты на ASBR1, указывая в маршруте next-hop-ом себя.

3. ASBR1 принимает labeled-unicast маршрут от ASBR2 и инсталирует их в mpls forwarding table.

4. ASBR1 генерирует метки для полученных от ASBR2 маршрутов, указывает next-hop-ом себя и отдает маршруты на RR1.

5. RR1, получив данные маршруты проверяет маршрут на валидность, инсталирует в свою таблицу маршрутизации и отправляет всем остальным своим клиентам.

6. PE1 получив от роутрефлектора labeled-unicast маршрут, производит его валидацию и инсталирует маршрут в таблицу маршрутизации.

Распределение меток vrf:

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

2. Роутрефлектор RR2 пересылает данный маршрут всем своим клиентам и RR1 по eBGP multihop сессии, не меняя next-hop и значения меток.

3. RR1 передает полученный от RR2 маршрут всем своим клиентам, включая и PE1.

4. PE1 проверят маршрут на пригодность и устанавливает в таблицу маршрутизации соответствующего vrf.

Метки vrf и транспортные метки распределены.

Теперь посмотрим как это все работает на практике. Сначала нам необходимо распределить маршруты лупбеков между автономными системами, так как наша vpnv4 сессия между роутрефлекторами не поднимется ввиду отсутствия маршрута до удаленного роутрефлектора. Мы будем распределять между автономными системами сразу маршруты с метками, поэтому между ASBR-ми будет только labeled-unicast сессия (ipv4 префиксы без меток нам не нужны). Но если вам нужны оба семейства адресов, то необходимо будет указать, что маршруты labeled-unicast необходимо инсталировать в inet.3(иначе на JunOS вы два семейства адресов ipv4 и ipv4 labeled-unicast в одной сессии не поднимите).

Конфигурация bgp на ASBR1 (сессия с ASBR2):
bormoglotx@ASBR1> show configuration protocols bgp group ASBR-AS2
type external;
local-address 10.2.0.1;
family inet {
    labeled-unicast;
}
export Lo-export;
peer-as 2;
neighbor 10.2.0.2;

bormoglotx@ASBR1> show configuration policy-options policy-statement Lo-export
term 1 {
    from {
        protocol isis;
        route-filter 10.0.10.0/24 prefix-length-range /32-/32;
    }
    then accept;
}
term 2 {
    then reject;

Посмотрим как отработает сигнализация метки до лупбека PE2.

Итак, внутри автономной системы у нас запущен ldp и метки до лупбеков автоматически разлетаются по всей AS. Естественно у ASBR2 есть метки до лупбеков всех маршрутизаторов AS2. Теперь ASBR2 должен сгенерировать маршруты с метками до лупбеков своей AS и передать их на ASBR1. Посмотрим:
ASBR2#sh ip bgp 10.1.10.1/32
BGP routing table entry for 10.1.10.1/32, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1          2
  Local
    10.1.0.2 from 0.0.0.0 (10.1.10.3)
      Origin incomplete, metric 3, localpref 100, weight 32768, valid, sourced, best
      mpls labels in/out 22/nolabel

Как видно из вывода, ASBR2 сгенерировал метку до префикса 10.1.10.1 на in, равную 22.

Посмотрим данный маршрут на ASBR1:
bormoglotx@ASBR1> show route receive-protocol bgp 10.2.0.2 10.1.10.1/32 detail

inet.0: 17 destinations, 20 routes (17 active, 0 holddown, 0 hidden)
* 10.1.10.1/32 (1 entry, 1 announced)
     Accepted
     Route Label: 22
     Nexthop: 10.2.0.2
     MED: 3
     AS path: 2 ?

Нас интересует в выводе метка: 22 и next-hop: 10.2.0.2 (адрес интерфейса ASBR2). Теперь ASBR1 знает как добраться до PE2.

Далее этот маршрут по labeled -unicast сессии передается на рефлектор и с него распределяется внутри автономной системы между PE маршрутизаторами. Но тут есть одно но: если ASBR1 передаст маршрут в том же виде, что и получил от ASBR2, то ничего не заработает, так как маршрута до сети 10.2.0.0/30 (сеть между ASBR-ми) внутри автономной системы нет. Поэтому ASBR1 меняет next-hop на себя и генерирует новую метку:
bormoglotx@ASBR1> show route advertising-protocol bgp 10.0.10.10 10.1.10.1/32 detail

inet.0: 17 destinations, 20 routes (17 active, 0 holddown, 0 hidden)
* 10.1.10.1/32 (1 entry, 1 announced)
 BGP group RR type Internal
     Route Label: 299920
     Nexthop: Self
     Flags: Nexthop Change
     MED: 3
     Localpref: 100
     AS path: [1] 2 ?

Посмотрим теперь данный маршрут на PE1:
bormoglotx@PE1> show route protocol bgp 10.1.10.1/32

inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.10.1/32       *[BGP/170] 00:26:35, MED 3, localpref 100, from 10.0.10.10
                      AS path: 2 ?
                    > to 10.0.2.2 via ge-0/0/0.0, Push 299920, Push 299776(top)
                      to 10.0.0.2 via ge-0/0/1.0, Push 299920, Push 299776(top)

inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.10.1/32       *[BGP/170] 00:26:35, MED 3, localpref 100, from 10.0.10.10
                      AS path: 2 ?
                    > to 10.0.2.2 via ge-0/0/0.0, Push 299920, Push 299776(top)
                      to 10.0.0.2 via ge-0/0/1.0, Push 299920, Push 299776(top)

Все верно, метка 299920 используется чтобы добраться до PE2. В выводе мы также видим еще одну метку 299776, то есть у нас получился стек меток. О назначении второй (299776) будет написано чуть ниже).

Отлично, теперь у нас есть end-to-end lsp между PE1 и PE2. Собственно говоря между рефлекторами тоже теперь есть lsp, так как маршруты до RR1 и RR2 тоже отдаются с метками. После того, как мы распределили маршруты лупбеков между автономными системами, между роутрефлекторами поднимается соседство:
bormoglotx@RR1> show bgp neighbor 10.1.10.10
Peer: 10.1.10.10+34875 AS 2    Local: 10.0.10.10+179 AS 1
  Type: External    State: Established    Flags: <Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: <Multihop NoNextHopChange Preference LocalAddress Ttl AddressFamily PeerAS Rib-group Refresh>
  Address families configured: inet-vpn-unicast
  Local Address: 10.0.10.10 Holdtime: 90 Preference: 170
  Number of flaps: 0
  Peer ID: 10.1.10.10      Local ID: 10.0.10.10        Active Holdtime: 90
  Keepalive Interval: 30         Peer index: 0
  BFD: disabled, down
  NLRI for restart configured on peer: inet-vpn-unicast
  NLRI advertised by peer: inet-unicast inet-vpn-unicast
  NLRI for this session: inet-vpn-unicast
  Peer supports Refresh capability (2)
  Stale routes from peer are kept for: 300
  Peer does not support Restarter functionality
  Peer does not support Receiver functionality
  Peer supports 4 byte AS extension (peer-as 2)
  Peer does not support Addpath
  Table bgp.l3vpn.0 Bit: 20001
    RIB State: BGP restart is complete
    RIB State: VPN restart is complete
    Send state: in sync
    Active prefixes:              2
    Received prefixes:            2
    Accepted prefixes:            2
    Suppressed due to damping:    0
    Advertised prefixes:          2
  Last traffic (seconds): Received 20   Sent 13   Checked 68
  Input messages:  Total 210    Updates 3       Refreshes 0     Octets 4222
  Output messages: Total 212    Updates 2       Refreshes 0     Octets 4205
  Output Queue[1]: 0

Между рефлекторами распределяются vpnv4 маршруты: NLRI for this session: inet-vpn-unicast.
Мы принимаем 2 префикса от соседа: Accepted prefixes: 2
И столько же отдаем: Advertised prefixes: 2
Думаю, это понятно.

Настройки рефлекторов:
bormoglotx@RR1# show protocols bgp group RR-AS2
type external;
multihop {
    ttl 5;
    no-nexthop-change;
}
local-address 10.0.10.10;
family inet-vpn {
    unicast;
}
peer-as 2;
neighbor 10.1.10.10;


RR2#sh configuration | b router bgp
router bgp 2
 bgp log-neighbor-changes
 neighbor 10.0.10.10 remote-as 1
 neighbor 10.0.10.10 ebgp-multihop 5
 neighbor 10.0.10.10 update-source Loopback0
  !
  address-family vpnv4
  neighbor 10.0.10.10 activate
  neighbor 10.0.10.10 send-community extended
  neighbor 10.0.10.10 next-hop-unchanged
  exit-address-family

Примечание: в конфигурации RR2 (Cisco IOS15) часть строк, не относящихся к 10.0.10.10 удалена, что бы сократить размер вывода.

Теперь мы можем посмотреть, как работает распределение меток vrf:

PE2 генерирует маршрут до сети 10.0.1.0/24, которая терминируется в vrf CE1
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 CE1)
  Advertised to update-groups:
     1
  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: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 22/nolabel(CE1)

Как видим, была сгенерирована метка 22.

Далее маршрут отдается на RR2:
PE2#sh ip bgp vpnv4 all neighbors 10.1.10.10 advertised-routes
BGP table version is 7, 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 CE1)
*> 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

Роутрефлектор отдает этот маршрут всем своим клиентам, а так же на RR1:
RR2#sh ip bgp vpnv4 rd 2:1 neighbors 10.0.10.10 advertised-routes
BGP table version is 5, local router ID is 10.1.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: 2:1
*>i10.0.1.0/24      10.1.10.1                0    100      0 ?
*>i10.1.1.2/32      10.1.10.1                2    100      0 ?

Total number of prefixes 2

Посмотрим полученный маршрут на RR1:
bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24

bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden)

Маршрут попал в hidden и никуда больше не распространяется. Возникает вопрос — почему? (Причем у Cisco нет такой беды)
bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24 hidden

bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

2:1:10.0.1.0/24
                    [BGP/170] 00:29:12, localpref 100, from 10.1.10.10
                      AS path: 2 ?
                      Unusable

Посмотрим причину:
bormoglotx@RR1> show route table bgp.l3vpn.0 10.0.1.0/24 hidden detail

bgp.l3vpn.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden)
2:1:10.0.1.0/24 (1 entry, 0 announced)
         BGP    Preference: 170/-101
                Route Distinguisher: 2:1
                Next hop type: Unusable
                Address: 0x8f3c5a4
                Next-hop reference count: 2
                State: <Hidden Ext>
                Local AS:     1 Peer AS:     2
                Age: 31:00
                Task: BGP_2.10.1.10.10+34875
                AS path: 2 ?
                Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0
                Accepted
                VPN Label: 22
                Localpref: 100
                Router ID: 10.1.10.10

В выводе напротив Next hop type стоит Unusable. Роутрефлектор проверил маршрут на доступность next-hop, но не нашел в таблице маршрутизации маршрут до указанного next-hop.

Посмотрим в таблицу маршрутизации:
bormoglotx@RR1> show route 10.1.10.1/32

inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.10.1/32       *[BGP/170] 00:33:04, MED 3, localpref 100, from 10.0.10.3
                      AS path: 2 ?
                    > to 10.0.1.1 via ge-0/0/0.0, Push 299920

Маршрут есть и даже с меткой (логично, мы же его распространили с ASBR1 по labeled-unicast). Дело в том, что в JunOS (в отличии от других вендоров) есть несколько таблиц маршрутизации. Сейчас нас интересует таблицы inet.0 и inet.3.

inet.0 — таблица маршрутизации, в которой хранятся ipv4 unicast маршруты.

inet.3 — таблица маршрутизации, в которой хранятся ipv4 mpls маршруты. Этой таблицей пользуется маршрутизатор, если он является ingress LSR.

BGP, получая vpnv4 маршруты, пытается разрезольвить next-hop именно в таблице inet.3. По умолчанию, bgp labeled unicast маршруты инсталируются в таблицу inet.0 и они не попадают в inet.3. То есть — роутрефлектор получил vpnv4 маршрут и пытается разрезольвить next-hop, но не находит маршрут до него в таблице inet.3 и помечает vpnv4 маршрут как hidden в связи с unusable next-hop.

Необходимо изменить это поведение. Для его есть несколько рычагов:

resolve-vpn — эта команда меняет стандартное поведение JunOS касательно установки labeled-unicast маршрутов в таблицу маршрутизации. Теперь JunOS будет устанавливать полученные по bgp labeled-unicast маршруты и в таблицу inet.0 и в таблицу inet.3.

rib-groups — очень гибкий механизм, можно с помощью политики перетащить определенные маршруты (в плоть до префикса /32) из одной таблицы маршрутизации в другую (в нашем случае из inet.0 в inet.3) Но с rib-groups нужно быть внимательным, так как можно наломать дров, не четко понимая, что делаешь (возможности rib-groups очень велики).

resolution rib bgp.l3vpn.0 resolution-ribs inet.0 — эта команда позволяет никуда ничего не переносить, а лишь заставляет маршрутизатор резольвить vpnv4 маршруты в таблице inet.0.

На роутрефлеторе дадим команду resolution rib, а на PE маршрутизаторе resolve-vpn:
bormoglotx@RR1# show routing-options
router-id 10.0.10.10;
autonomous-system 1;
resolution {
    rib bgp.l3vpn.0 {
        resolution-ribs inet.0;
    }
}

Теперь маршруты на рефлекторе появились и могу быть распространены внутри автономной системы:
bormoglotx@RR1> show route receive-protocol bgp 10.1.10.10

inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  2:1:10.0.1.0/24
*                         10.1.10.1                               2 ?
  2:1:10.1.1.2/32
*                         10.1.10.1                               2 ?

Посмотрим сам маршрут с деталями:
bormoglotx@RR1> show route protocol bgp rd-prefix 2:1:10.0.1.0/24 detail

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
2:1:10.0.1.0/24 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 2:1
                Next hop type: Indirect
                Address: 0x934d6d8
                Next-hop reference count: 1
                Source: 10.1.10.10
                Protocol next hop: 10.1.10.1
                Push 22
                Indirect next hop: 2 no-forward
                State: <Active Ext>
                Local AS:     1 Peer AS:     2
                Age: 11:55      Metric2: 1
                Task: BGP_2.10.1.10.10+34875
                Announcement bits (1): 0-BGP_RT_Background
                AS path: 2 ?
                Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0
                Accepted
                VPN Label: 22
                Localpref: 100
                Router ID: 10.1.10.10

В выводе видно, что next-hop остался неизменным при переходе через границу автономной системы, что не характерно для ebgp. Дело в том, что в конфигурации (показана выше) есть команда no-nexthop-change — JunOS, next-hop-unchanged — Cisco, которая меняет стандартное поведение ebgp и не дает менять next-hop при переходе границы автономной системы. Для чего это нужно. Если не дать данную команду, то во всех vpnv4 маршрутах роутрефлектор будет ставить себя next-hop-ом, то есть весь vpn трафик полезет через роутрефлектор, которому и так не сладко в жизни. Теперь, помимо переваривания кучи маршрутов (особенно если на нем FV), ему придется и обрабатывать огромное количество трафика. Собственно конец всегда будет один — данная схема потерпит фиаско, а если быть точнее — падение роутрефлектора со всеми вытекающими. Причем даже наличие двух резервирующих рефлекторов вам не поможет. Но вернемся к нашей топологии и посмотрим vpnv4 маршрут на PE1 (не забываем, что мы уже дали команду resolve-vpn, иначе маршруты попадут в hidden):
bormoglotx@PE1> show configuration protocols bgp group RR
type internal;
local-address 10.0.10.1;
family inet {
    labeled-unicast {
        resolve-vpn;
    }
}
family inet-vpn {
    unicast;
}
neighbor 10.0.10.10;


bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/24 detail

CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
10.0.1.0/24 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 2:1
                Next hop type: Indirect
                Address: 0x934d2e8
                Next-hop reference count: 3
                Source: 10.0.10.10
                Next hop type: Router, Next hop index: 608
                Next hop: 10.0.2.2 via ge-0/0/0.0, selected
                Label operation: Push 22, Push 299920, Push 299776(top)
                Label TTL action: prop-ttl, prop-ttl, prop-ttl(top)
                Protocol next hop: 10.1.10.1
                Push 22
                Indirect next hop: 94a0658 262151
                State: <Secondary Active Int Ext>
                Local AS:     1 Peer AS:     1
                Age: 39:28      Metric2: 1
                Task: BGP_1.10.0.10.10+179
                Announcement bits (2): 0-CE1-OSPF 1-KRT
                AS path: 2 ?
                Communities: target:1:100 domain-id:0:131584 route-type-vendor:0.0.0.0:2:0 router-id-vendor:10.0.1.1:0
                Import Accepted
                VPN Label: 22
                Localpref: 100
                Router ID: 10.0.10.10
                Primary Routing Table bgp.l3vpn.0


Нам интересны строки:
Protocol next hop: 10.1.10.1
Push 22
VPN Label: 22

Сигнализация отработала, теперь у нас есть lsp между PE маршрутизаторами и метки vrf.

Data-plane:

Теперь посмотрим как будет передаваться трафик по просигнализированному пути.
Для начала проверим связность между CE:
CE1#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 = 48/57/68 ms

Отлично. Теперь можно сделать трассировку:
R5#traceroute 10.0.1.2

Type escape sequence to abort.
Tracing the route to 10.0.1.2

  1 10.0.0.1 4 msec 4 msec 8 msec
  2 10.0.2.2 [MPLS: Labels 299776/299920/22 Exp 0] 48 msec 48 msec 12 msec
  3 10.0.3.1 [MPLS: Labels 299920/22 Exp 0] 76 msec 56 msec 36 msec
  4 10.2.0.2 [MPLS: Labels 22/22 Exp 0] 48 msec 12 msec 76 msec
  5 10.1.2.2 [MPLS: Labels 17/22 Exp 0] 40 msec 52 msec 44 msec
  6 10.0.1.1 44 msec 60 msec 48 msec
  7 10.0.1.2 44 msec 56 msec 56 msec

Виден стек из трех меток.

И так, сморим маршрут на PE1 до клиентского префикса 10.0.1.0/24:
bormoglotx@PE1> show route table CE1.inet.0 10.0.1.0/24

CE1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/24        *[BGP/170] 00:39:25, localpref 100, from 10.0.10.10
                      AS path: 2 ?
                    > to 10.0.2.2 via ge-0/0/0.0, Push 22, Push 299920, Push 299776(top)

PE1 навешивает три метки:

22- метка vrf, полученна через рефлекторы от PE2
299920 — метка до лупбека PE2, полученная через роутрефлектор от ASBR1
299776 — метка до ASBR1, полученная по протоколу LDP

и отправляет данный пакет в сторону P1: Next hop: 10.0.2.2 via ge-0/0/0.0
bormoglotx@PE1> show interfaces descriptions
Interface       Admin Link Description
ge-0/0/0        up    up   to P1
ge-0/0/1        up    up   to RR1
ge-0/0/3        up    up   to SW1
lo0             up    up   router-id

Примечание: так как мы распределили метку до PE2 по labeled-unicast, то у P1 нет метки до лубека PE2. Если мы пошлем пакет с двумя метками, то P1 не будет знать что делать с данной меткой. Поэтому нам нужно добавить еще одну метку до ASBR1, тогда P1 будет обрабатывать данный трафик не подозревая что это трафик в соседнюю AS (работает то она только с верхней меткой). Другими словами мы в lsp до ASBR1 туннелируем lsp о PE2.

Посмотрим, что сделает P1 с полученным пакетом:
bormoglotx@P1> show route table mpls.0 label 299776

mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299776             *[LDP/9] 01:13:09, metric 1
                    > to 10.0.3.1 via ge-0/0/1.0, Pop
299776(S=0)        *[LDP/9] 01:13:09, metric 1
                    > to 10.0.3.1 via ge-0/0/1.0, Pop

Все логично, P1 снимает верхнюю метку (механизм php) и отправляет пакет уже со стеком их двух меток на ASBR1.

ASBR1 производит своп верхней метки (метки до PE2), на метку, которую ему сообщил ASBR2:
bormoglotx@ASBR1> show route table mpls.0 label 299920

mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

299920             *[VPN/170] 01:13:51
                    > to 10.2.0.2 via ge-0/0/3.0, Swap 22

Примечание: получился очень наглядно — метка 22 была сгенерирована ASBR2 для достижения PE2, в то же время как метка 22 была сгенерирована и PE2 как vrf метка. Поэтому у нас пакет между ASBR1 и ASBR2 будет идти со стеком из двух одинаковых меток 22/22. Реально же это две разные метки (по назначению) и то, что они в данном случае одинаковые — случайность.

Далее пакет попадает на ASBR2.
ASBR2#sh mpls forwarding-table labels 22
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
22         18         10.1.10.1/32     0             Gi1/0      10.1.0.2
           17         10.1.10.1/32     13378         Gi2/0      10.1.2.2

ASBR2 производит своп верхней метки в стеке на метку 18 или 17 (у нас эквивалентные пути). Эти метки он получил из протокола ldp:
ASBR2#show mpls ldp bindings 10.1.10.1 32
  lib entry: 10.1.10.1/32, rev 18
        local binding:  label: 22
        remote binding: lsr: 10.1.10.2:0, label: 17
        remote binding: lsr: 10.1.10.10:0, label: 18

Предположим что пакет уходит на P2, значит ASBR2 производит своп верхней метки на метку 17.
Смотрим что будет делать P2:
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.1.10.1/32     12936         Gi1/0      10.1.3.1

P2 снимает метку и отправляет пакет уже с одной меткой (меткой vrf) на PE2.
Осталось только проверить, что будет делать PE2 с пакетом с меткой 22.
PE1 смотрит в mpls forwarding-table, снимает метку, делает ip lookup в таблице CE1 и отправляет пакет в интерфейс GigabitEthernet3/0.10, который смотрит в SW2, к которому подключен клиентский маршрутизатор CE2:
PE2#sh mpls forwarding-table labels 22
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
22         No Label   10.0.1.0/24[V]   3296          aggregate/CE1

PE2#sh ip route vrf CE1 10.0.1.0

Routing Table: CE1
Routing entry for 10.0.1.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via bgp 2
  Advertised by bgp 2
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet3/0.10
      Route metric is 0, traffic share count is 1

В данном примере я использовал схему со стеком из трех меток. Есть вариант с использованием стека из 2-х меток. Отличие в том, что маршруты, получаемые ASBR-ми, должны быть перераспределены в протокол IGP. Тогда ldp начнет распределять метки и до лупбеков соседней автономной системы, но лично мне данный вариант не нравится, как минимум потому что мы засовываем bgp маршруты в igp, что не очень хорошо. В остальном все аналогично описанному выше.

Надеюсь, я донес до читателя принцип работы данных опций и вам пригодится эта статья при диагностике неисправностей на l3vpn. Статья получилась очень большая и писалась не один день, если кто то хочет что то добавить или заметил какой то недостаток (все таки я человек), прошу писать в личку — поправим и добавим. Если есть вопросы — пишите в комментарии, по возможности отвечу. Спасибо за внимание!

Спасибо за помощь в написании статьи пользователю AllTheThingsUndone.

Tags:
Hubs:
+14
Comments 17
Comments Comments 17

Articles