В предыдущих выпусках:

Profile 0
Profile 1
Profile 3

В этой части статьи мы рассмотрим с Вами вариант замены сигнализации в рамках наложенной сети с протокола PIM на BGP.

Как рассматривалось ранее (см статью про BGP Auto-Discovery), для того чтобы передавать аналоги PIM сообщений, в BGP было придумано несколько типов маршрутов, каждый из которых несёт в себе определённый функционал. При этом типов маршрутов больше, чем есть типов сообщений у PIM.



«Зачем натягивать сову на глобус?» — можете спросить Вы, ведь всё прекрасно работает и с PIM. И, в общем-то, будете правы. Основной причиной эдакого ходя конём является масштабируемость. PIM, являясь по сути своей Soft Driven протоколом, требует для своей работы постоянной рассылки служебных сообщений, что при определённом размере внедрения (если количество узлов начинает переваливать за пару сотен или тысяч) привносит ограничения в связи с неизбежной загрузкой CPU. BGP же является Hard Driven протоколом — т.е. если что-то было сказано однажды, то не повторяется; любые BGP обновления вызваны исключительно изменениями в сети.

Сегодня мы с Вами рассмотрим два сценария: использование PIM SSM и PIM ASM в рамках C-VRF.

C-PIM SSM

Для более простого понимания BGP сигнализации для построения многоадресных деревьев, начнём наш разговор с более простого PIM SSM.

Прежде всего, уберём текущие настройки точки рандеву и отключим получателей трафика:

CE4(config)#interface Loopback0
CE4(config-if)#no ip igmp join-group 231.1.1.2
CE4(config-if)#

CE15(config)#no ip pim bsr-candidate Loopback0 0
CE15(config)#no ip pim rp-candidate Loopback0 group-list 1

На всех РЕ укажем, что для сигнализации вместо PIM будет работать BGP. Это делается следующей командой:

ip vrf C-ONE
 mdt overlay use-bgp

Отправной точкой наблюдений будет ситуация без наличия источников и получателей многоадресного трафика. В BGP таблице должны присутствовать только type-1 маршруты:

PE1#show bgp ipv4 mvpn all 
BGP table version is 406, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)
 *>   [1][1.1.1.1:1][1.1.1.1]/12
                       0.0.0.0                            32768 ?
 *>i  [1][1.1.1.1:1][2.2.2.2]/12
                       2.2.2.2                  0    100      0 ?
 *>i  [1][1.1.1.1:1][3.3.3.3]/12
                       3.3.3.3                  0    100      0 ?
 *>i  [1][1.1.1.1:1][4.4.4.4]/12
                       4.4.4.4                  0    100      0 ?
Route Distinguisher: 2.2.2.2:1
 *>i  [1][2.2.2.2:1][2.2.2.2]/12
                       2.2.2.2                  0    100      0 ?
Route Distinguisher: 3.3.3.3:1
     Network          Next Hop            Metric LocPrf Weight Path
 *>i  [1][3.3.3.3:1][3.3.3.3]/12
                       3.3.3.3                  0    100      0 ?
Route Distinguisher: 4.4.4.4:1
 *>i  [1][4.4.4.4:1][4.4.4.4]/12
                       4.4.4.4                  0    100      0 ?

Подключим получателя:

CE4(config-if)#ip igmp join 230.1.1.1 source 11.11.11.11

На ближайшем РЕ создаётся BGP маршрут 7-го типа — это эквивалент сообщения PIM (S, G) Join:

PE4#show bgp ipv4 mvpn all 
Route Distinguisher: 1.1.1.1:1
 *>   [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22
                       0.0.0.0                            32768 ?

По логике вещей, данный маршрут должен присутствовать только на РЕ4 и на РЕ1 (т.к именно через них должен проходить трафик) и отсутствовать на РЕ2 и РЕ3. Проверим:

PE1#show bgp ipv4 mvpn all | b \[7\]
 *>i  [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22
                       4.4.4.4                  0    100      0 ?

PE2#show bgp ipv4 mvpn all | b \[7\]
PE2#

PE3#show bgp ipv4 mvpn all | b \[7\]
PE3#

Как так получается, что маршрут, изначальной порождённый на РЕ4, импортируется только на РЕ1?

Посмотрим на запись в BGP-таблице чуть детальнее:

PE4#show bgp ipv4 mvpn all route-type 7 1.1.1.1:1 65001 11.11.11.11 230.1.1.1 
BGP routing table entry for [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22, version 533
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
  Advertised to update-groups:
     7         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (4.4.4.4)
      Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
      Extended Community: RT:1.1.1.1:1
      rx pathid: 1, tx pathid: 0x0

В записи префикса присутствует расширенное коммьюнити Route-target = 1.1.1.1:1, которое было добавлено в vpnv4 префикс маршрутизатором, который с точки РЕ4 является RPF соседом:

PE1#show bgp vpnv4 unicast rd 1.1.1.1:1 11.11.11.11/32
BGP routing table entry for 1.1.1.1:1:11.11.11.11/32, version 670
Paths: (1 available, best #1, table C-ONE)
  Advertised to update-groups:
     1          17        
  Refresh Epoch 4
  65011
    172.1.11.11 (via vrf C-ONE) from 172.1.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
      mpls labels in/out 10018/nolabel
      rx pathid: 0, tx pathid: 0x0
PE1#

PE2#show bgp vpnv4 unicast rd 2.2.2.2:1 11.11.11.11/32
BGP routing table entry for 2.2.2.2:1:11.11.11.11/32, version 762
Paths: (1 available, best #1, table C-ONE)
  Advertised to update-groups:
     1         
  Refresh Epoch 152
  65011, imported path from 1.1.1.1:1:11.11.11.11/32 (global)
    1.1.1.1 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
      Originator: 1.1.1.1, Cluster list: 8.8.8.8
      Connector Attribute: count=1
       type 1 len 12 value 1.1.1.1:1:1.1.1.1
      mpls labels in/out nolabel/10018
      rx pathid: 0, tx pathid: 0x0

Проверим связность:

CE1#ping 230.1.1.1 so 11.11.11.11 rep 3   
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11 
 
Reply to request 0 from 14.14.14.14, 7 ms
Reply to request 0 from 14.14.14.14, 8 ms
Reply to request 1 from 14.14.14.14, 7 ms
Reply to request 1 from 14.14.14.14, 9 ms
Reply to request 2 from 14.14.14.14, 7 ms
Reply to request 2 from 14.14.14.14, 7 ms

C-PIM ASM

В случае работы C-PIM в режиме SSM всё довольно просто. Для корректной работы mVPN достаточно создания двух дополнительных (типов) BGP маршрутов.

А как обстоят дела, если внутри C-VRF используется более комплексный ASM PIM? 

Прежде всего мы видим, что на всех СЕ известна информация о точке рандеву:

CE2#show ip pim rp mapp
CE2#show ip pim rp mapping 
Auto-RP is not enabled
PIM Group-to-RP Mappings
 
Group(s) 231.1.1.0/24
  RP 15.15.15.15 (?), v2
    Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 1d04h, expires: 00:02:09
CE2#

Как? Если мы посмотрим BGP таблицу, то не найдём там никакого намёка на эту точку:

PE1#show bgp ipv4 mvpn all 
BGP table version is 682, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
 
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)
 *>   [1][1.1.1.1:1][1.1.1.1]/12
                       0.0.0.0                            32768 ?
 *>i  [1][1.1.1.1:1][2.2.2.2]/12
                       2.2.2.2                  0    100      0 ?
 *>i  [1][1.1.1.1:1][3.3.3.3]/12
                       3.3.3.3                  0    100      0 ?
 *>i  [1][1.1.1.1:1][4.4.4.4]/12
                       4.4.4.4                  0    100      0 ?
Route Distinguisher: 2.2.2.2:1
 *>i  [1][2.2.2.2:1][2.2.2.2]/12
                       2.2.2.2                  0    100      0 ?
Route Distinguisher: 3.3.3.3:1
     Network          Next Hop            Metric LocPrf Weight Path
 *>i  [1][3.3.3.3:1][3.3.3.3]/12
                       3.3.3.3                  0    100      0 ?
Route Distinguisher: 4.4.4.4:1
 *>i  [1][4.4.4.4:1][4.4.4.4]/12
                       4.4.4.4                  0    100      0 ?

Не надо забывать о том, что у нас есть PMSTI, на котором активирован PIM:

PE1#show ip pim vrf C-ONE interface 
 
Address          Interface                Ver/   Nbr    Query  DR         DR
                                          Mode   Count  Intvl  Prior
172.1.11.1       GigabitEthernet2.111     v2/S   1      30     1          172.1.11.11
172.1.15.1       GigabitEthernet2.115     v2/S   1      30     1          172.1.15.15
1.1.1.1          Tunnel2                  v2/S   0      30     1          1.1.1.1

Отсюда можно сделать важный вывод — некоторые сообщения PIM (даже при BGP сигнализации) передаются поверх опорной сети в рамках Default MDT.


Представим, что в сети появился источник (за маршрутизатором СЕ2). Поскольку на СЕ2 на данный момент нет записей в mRIB, то PIM Designated Router (в нашем случае это сам СЕ2) отправляет сообщение Register на точку рандеву, тем самым сигнализируя о наличии активного источника в сети.


На точке рандеву создаётся дерево (12.12.12.12, 231.1.1.1):

CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:00:19/stopped, RP 15.15.15.15, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null
 
(12.12.12.12, 231.1.1.1), 00:00:19/00:02:40, flags: P
  Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1
  Outgoing interface list: Null

И, поскольку, в сети нет активных получателей трафика (отсутствует дерево (*, 231.1.1.1)), то со стороны CE5 создаётся сообщение Register-Stop



В ответ на получение Register-Stop, CE2 приостанавливает передачу данных (нет интерфейсов в OIL):

CE2#show ip mroute 231.1.1.1               
 
(12.12.12.12, 231.1.1.1), 00:00:07/00:02:54, flags: PFT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list: Null

Теперь представим, что в сети появился получатель, заинтересованный в трафике для группы 231.1.1.1. На РЕ4 появляется маршрут внутри C-VRF:

PE4#show ip mroute vrf C-ONE 231.1.1.1 | b \(
(*, 231.1.1.1), 00:00:44/00:02:45, RP 15.15.15.15, flags: Sg
  Incoming interface: Tunnel0, RPF nbr 1.1.1.1
  Outgoing interface list:
    GigabitEthernet2.414, Forward/Sparse, 00:00:44/00:02:45

И создаётся BGP маршрут 6-го типа, который является эквивалентом PIM Join (*, 231.1.1.1):

PE4#show bgp ipv4 mvpn all
Route Distinguisher: 1.1.1.1:1
 *>   [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22
                       0.0.0.0                            32768 ?
 
PE4#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 808
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
  Advertised to update-groups:
     8         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (4.4.4.4)
      Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
      Extended Community: RT:1.1.1.1:1
      rx pathid: 1, tx pathid: 0x0

В приведённом выше выводе необходимо обратить внимание на расширенное коммьюнити Route-target = 1.1.1.1:1. Что это и откуда взялось?

Проверим наличие данного префикса на других РЕ:

PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
% Network not in table
 
PE3#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
% Network not in table

PE1#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 698
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
  Not advertised to any peer
  Refresh Epoch 2
  Local
    4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:1.1.1.1:1
      Originator: 4.4.4.4, Cluster list: 8.8.8.8
      rx pathid: 0, tx pathid: 0x0

Т.е. префикс существует только на РЕ1. Что интересно, так это тот факт, что точка рандеву (15.15.15.15) находится именно на сайте за РЕ1.

Зная назначение Route-target (импорт маршрутов внутрь определённой VRF) напрашивается вывод — RT = 1.1.1.1:1 известен РЕ1 и неизвестен РЕ2/PE3. Т.е очевиден факт, что РЕ4 сгенерировал BGP маршрут, описывающий PIM Shared Tree Join таким образом, чтобы он был обработан только на том РЕ, за которым в действительности находится точка рандеву (по факту, это аналог передачи PIM Join через RPF интерфейс). Но каким образом РЕ1 и РЕ4 согласуют между собой значения Route-target?

PE4 проводит RPF для адреса точки рандеву:

PE4#show ip rpf vrf C-ONE 15.15.15.15
RPF information for ? (15.15.15.15)
  RPF interface: Tunnel0
  RPF neighbor: ? (1.1.1.1)
  RPF route/mask: 15.15.15.15/32
  RPF type: unicast (bgp 65001)
  Doing distance-preferred lookups across tables
  BGP originator: 1.1.1.1
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

В качестве RPF соседа виден РЕ1. Значит, РЕ4 должен поместить внутрь маршрута 6-го типа такой Route-target, который будет импортирован только РЕ1. Чтобы ответить на вопрос «откуда РЕ4 его знает?» — посмотрим, для начала, на vpn маршрут:

PE4#show bgp vpnv4 unicast vrf C-ONE 15.15.15.15/32
BGP routing table entry for 4.4.4.4:1:15.15.15.15/32, version 859
Paths: (1 available, best #1, table C-ONE)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  65015, imported path from 1.1.1.1:1:15.15.15.15/32 (global)
    1.1.1.1 (metric 3) (via default) from 8.8.8.8 (8.8.8.8)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
      Originator: 1.1.1.1, Cluster list: 8.8.8.8
      Connector Attribute: count=1
       type 1 len 12 value 1.1.1.1:1:1.1.1.1
      mpls labels in/out nolabel/10013
      rx pathid: 0, tx pathid: 0x0

Обратите внимание на дополнительное коммьюнити MVPN VRF:1.1.1.1:1. Это ничто иное, как коммьюнити Route Import, сгенерированное РЕ1. Именно это значение копируется как Route-target внутрь многоадресного маршрута, что позволяет РЕ1 импортировать полученный апдейт от РЕ4.

Результатом обработки BGP маршрут 6-го типа на РЕ4 является создание записи в многоадресной таблице маршрутизации:

PE4#show ip mroute vrf C-ONE
 
(*, 231.1.1.1), 00:23:31/00:02:33, RP 15.15.15.15, flags: Sg
  Incoming interface: Tunnel0, RPF nbr 1.1.1.1
  Outgoing interface list:
    GigabitEthernet2.414, Forward/Sparse, 00:23:31/00:02:33

Прим — обратите внимание, что входным интерфейсом указан Tunnel0 (PMSTI).

На точке рандеву завершается создание общего дерева:

CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:25:42/00:03:22, RP 15.15.15.15, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2.115, Forward/Sparse, 00:25:42/00:03:22

Теперь, если в сети опять появится активный источник трафика, точка рандеву будет знать как «совместить» (*, 231.1.1.1) и (12.12.12.12, 231.1.1.1) деревья.

CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:47:12/stopped, RP 15.15.15.15, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2.115, Forward/Sparse, 00:47:12/00:02:31
 
(12.12.12.12, 231.1.1.1), 00:00:23/00:02:43, flags: PT
  Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1
  Outgoing interface list: Null

Точка рандеву создаёт PIM Join (12.12.12.12, 231.1.1.1), отправляя его в сторону CE2. PE1 получает указанный PIM Join и создаёт BGP маршрут 7-го типа:

PE1#show bgp ipv4 mvpn all 
Route Distinguisher: 2.2.2.2:1
 *>   [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22
                       0.0.0.0                            32768 ?
 
PE1#show bgp ipv4 mvpn all route-type 7 2.2.2.2:1 65001 12.12.12.12 231.1.1.1
BGP routing table entry for [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22, version 726
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
  Advertised to update-groups:
     8         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (1.1.1.1)
      Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
      Extended Community: RT:2.2.2.2:1
      rx pathid: 1, tx pathid: 0x0

Обратите внимание, что в качестве Remote VPN RD выставляется значение 2.2.2.2:1, т.к. именно через РЕ2 завершается RPF проверка маршрута:

PE1#show ip rpf vrf C-ONE 12.12.12.12
RPF information for ? (12.12.12.12)
  RPF interface: Tunnel2
  RPF neighbor: ? (2.2.2.2)
  RPF route/mask: 12.12.12.12/32
  RPF type: unicast (bgp 65001)
  Doing distance-preferred lookups across tables
  BGP originator: 2.2.2.2
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

И RT 2.2.2.2:1 был добавлен в VPNv4 префикс со стороны РЕ2:

PE1#show bgp vpnv4 unicast vrf C-ONE 12.12.12.12
BGP routing table entry for 1.1.1.1:1:12.12.12.12/32, version 706
Paths: (1 available, best #1, table C-ONE)
  Advertised to update-groups:
     1         
  Refresh Epoch 2
  65012, imported path from 2.2.2.2:1:12.12.12.12/32 (global)
    2.2.2.2 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:2.2.2.2:1
      Originator: 2.2.2.2, Cluster list: 8.8.8.8
      Connector Attribute: count=1
       type 1 len 12 value 2.2.2.2:1:2.2.2.2
      mpls labels in/out nolabel/31
      rx pathid: 0, tx pathid: 0x0

На этом шаге, по сути, завершается построение дерева (12.12.12.12, 231.1.1.1) на участке между источником и точкой рандеву:


После получения маршрута 7-го типа, РЕ2 генерирует маршрут 5-го типа, сигнализируя о наличии активного источника трафика в сети. Маршрут импортируется всеми РЕ устройствами.

PE2#show bgp ipv4 mvpn all
 
Route Distinguisher: 2.2.2.2:1 (default for vrf C-ONE)
 *>   [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18
                       0.0.0.0                            32768 ?
 
 PE2#show bgp ipv4 mvpn all route-type 5 12.12.12.12 231.1.1.1
BGP routing table entry for [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18, version 838
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
  Advertised to update-groups:
     8         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
      Community: no-export
      Extended Community: RT:65001:1
      rx pathid: 0, tx pathid: 0x0

При получении маршрута 5-го типа, на РЕ4 (где находится получатель) завершается создание многоадресного дерева:

PE4#show ip mroute vrf C-ONE
 
(12.12.12.12, 231.1.1.1), 00:22:24/00:02:51, flags: TnQ
  Incoming interface: Tunnel0, RPF nbr 2.2.2.2
  Outgoing interface list:
    GigabitEthernet2.414, Forward/Sparse, 00:22:24/00:03:19

Прим — обратите внимание на флаг Q, который говорит о том, что запись была создана благодаря сообщению BGP Source-Active 


Рассмотренный вариант организации mVPN носит кодовое имя «Profile 11». Его основные характеристики:

• для передачи многоадресного трафика наложенной сети используется Default MDT
• в качестве метода организации транспорта выступает протокол mGRE
• для сигнализации многоадресного дерева в рамках наложенной сети используется протокол BGP