Внедрение Multicast VPN на Cisco IOS (часть 3 — BGP Auto-Discovery)

В прошлых выпусках мы с Вами познакомились с понятиями Default MDT, типами корневых деревьев и разобрали два варианта реализации mVPN на основе mGRE и mLDP:
Profile 0
Profile 1

На сегодняшний день адресное семейство BGP MDT (которое уже рассматривали) является устаревшим. Ему на замену пришло новое — SAFI = multicast VPN (mVPN). Что нового приносит данное адресное семейство? Какие случаи использования могут быть? Попробуем разобраться.

Заинтересованным — добро пожаловать под кат.

Авторы идеи предложили разделить сообщение BGP update на две составляющие:

• Непосредственно mvpn NLRI. Внутри передаётся следующая информация:
  
  • Типа маршрута (значение от 1 до 7). У каждого маршрута — своя функция.
• Аттрибуты туннеля PMSI (PMSI Tunnel Attribute, PTA). Отвечают за передачу информации о типе корневого дерева.

Типы BGP mVPN маршрутов

PTA

Тип туннеля определяет используемое корневое дерево и может принимать одно из следующих значений:

0 — информация не представлена
1 — RSVP-TE P2MP LSP
2 — mLDP P2MP LSP
3 — PIM-SSM
4 — PIM-SM
5 — BIDIR-PIM
6 — Ingress Replication
7 — mLDP MP2MP LSP

Дополнительные community

В зависимости от того, используется ли BGP для сигнализации многоадресного трафика в рамках VRF, у маршрутов могут появляться дополнительные коммьюнити.

VRF Route Import (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение:
Импортирование многоадресных маршрутов (подобную функцию в vpnv4 выполняет аттрибут Route-Target)

Route Target Constraint (RTC)
Предназначение:
В случае наличия RTC, Route-Reflector (или любой другой РЕ) отправляет только «желаемый» vpnv4/vpnv6 префикс к РЕ. «Желаемый» обозначает, что на принимаемом РЕ есть один или более VRF, в который указанный префикс может быть импортирован.

Прим. Более подробно про RTC написано в RFC4684

Source-AS Extended Community (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение:
Передача AS информации для организации Inter-AS mVPN сценариев

PE Distinguisher Label
Предназначение:
Построение PPMP дерева для участия в Partitioned MDT (на текущий момент я не планирую рассматривать данное дерево в рамках цикла статей).

Поскольку с появлением SAFI mVPN функционал BGP очень расширился, то и применять данное SAFI можно для разных сценариев, в частности:

• проведение Auto-Discovery
• замена PIM сигнализации на BGP

Стоит отметить, что два вышеуказанных сценария могут быть задействованы как одновременно, так и по-отдельности.

Сначала рассмотрим случай когда в наложенной сети сохраняется PIM, но поиск заинтересованных РЕ происходит посредством BGP. Передача данных между РЕ осуществляется посредством GRE. Данная реализация известна под кодовым именем «Profile 3».

Как и раньше, будем использовать следующую лабораторную топологию:

Начальные условия:

• В рамках опорной сети:
  
  • настроен OSPF
  • настроен P-PIM в режиме SSM
    

    access-list 99 permit 239.1.1.0 0.0.0.255
    ip pim ssm range 99

• В рамках VRF:
  
  • настроен C-PIM
  • нет активных источников или получателей трафика
• VRF приведена к виду
  

  ip vrf C-ONE
   rd 1.1.1.1:1
   route-target export 65001:1
   route-target import 65001:1

В первую очередь рассмотрим ситуацию, когда в рамках vrf C-ONE работает C-PIM SSM.

На всех РЕ:

ip vrf C-ONE
 mdt auto-discovery pim
 mdt default 239.1.1.1

На РЕ устройствах поднимается новый PMSTI:

*Nov 24 20:44:40.941: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

*Nov 24 20:44:42.872: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel2

PE1#show int tu2
Tunnel2 is up, line protocol is up 
  Interface is unnumbered. Using address of Loopback0 (1.1.1.1)
  Tunnel source 1.1.1.1 (Loopback0)
  Tunnel protocol/transport multi-GRE/IP

Пока что нет PIM соседства (т.к. РЕ не знают друг о друге):

*Nov 24 20:44:42.872: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel2

Активируем адресное семейство ipv4 mvpn:

router bgp 65001
 !
 address-family ipv4 mvpn
  neighbor MPLS_PE send-community extended
  neighbor MPLS_PE route-reflector-client
  neighbor 1.1.1.1 activate
  neighbor 2.2.2.2 activate
  neighbor 3.3.3.3 activate
  neighbor 4.4.4.4 activate
 exit-address-family

На РЕ моментально появляются соседи в рамках C-VRF:

PE1#show ip pim vrf C-ONE neighbor 
172.1.11.11       GigabitEthernet2.111     2w3d/00:01:19     v2    1 / DR S P G
172.1.15.15       GigabitEthernet2.115     2w3d/00:01:35     v2    1 / DR S P G
4.4.4.4           Tunnel2                  00:00:17/00:01:27 v2    1 / DR S P G
3.3.3.3           Tunnel2                  00:00:17/00:01:27 v2    1 / S P G
2.2.2.2           Tunnel2                  00:00:47/00:01:27 v2    1 / S P G

И соответствующие (S, G) деревья:

PE1#show ip mroute 239.1.1.1

(1.1.1.1, 239.1.1.1), 00:00:45/00:02:44, flags: sT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet2.15, Forward/Sparse, 00:00:45/00:02:44

(4.4.4.4, 239.1.1.1), 00:00:49/00:02:10, flags: sTIZ
  Incoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5
  Outgoing interface list:
    MVRF C-ONE, Forward/Sparse, 00:00:49/00:02:10

(3.3.3.3, 239.1.1.1), 00:00:53/00:02:06, flags: sTIZ
  Incoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5
  Outgoing interface list:
    MVRF C-ONE, Forward/Sparse, 00:00:53/00:02:06

(2.2.2.2, 239.1.1.1), 00:01:19/00:01:40, flags: sTIZ
  Incoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5
  Outgoing interface list:
    MVRF C-ONE, Forward/Sparse, 00:01:19/00:01:40

Как РЕ смогли «увидеть» друг друга? Ответ на этот вопрос нам даст анализ BGP таблицы:

PE1#show bgp ipv4 mvpn all 
BGP table version is 258, 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 ?

Как видим, каждый РЕ маршрутизатор создал BGP IPv4 mvpn маршрут первого типа, в котором описал себя

PE1#show bgp ipv4 mvpn all  route-type 1 4.4.4.4 
BGP routing table entry for [1][1.1.1.1:1][4.4.4.4]/12, version 262
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
  Not advertised to any peer
  Refresh Epoch 1
  Local, imported path from [1][4.4.4.4:1][4.4.4.4]/12 (global)
    4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: no-export
      Extended Community: RT:65001:1
      Originator: 4.4.4.4, Cluster list: 8.8.8.8
      PMSI Attribute: Flags: 0x0, Tunnel type: 3, length 8, label: exp-null, tunnel parameters: 0404 0404 EF01 0101 
      rx pathid: 0, tx pathid: 0x0
BGP routing table entry for [1][4.4.4.4:1][4.4.4.4]/12, version 265
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
  Not advertised to any peer
  Refresh Epoch 1
  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
      Community: no-export
      Extended Community: RT:65001:1
      Originator: 4.4.4.4, Cluster list: 8.8.8.8
      PMSI Attribute: Flags: 0x0, Tunnel type: 3, length 8, label: exp-null, tunnel parameters: 0404 0404 EF01 0101 
      rx pathid: 0, tx pathid: 0x0

Обратите внимание на PTA:

• Tunnel type: 3 говорит нам о том, что в рамках vrf использует SSM PIM
• tunnel parameters сообщает нам об адресе РЕ и группе многоадресной рассылки (EF01 0101 = 239.1.1.1)

Подключим клиента:

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

На РЕ этого сайта появляется многоадресный маршрут:

PE4#show ip mroute vrf C-ONE
(11.11.11.11, 230.1.1.1), 00:00:11/00:03:18, flags: sT
  Incoming interface: Tunnel0, RPF nbr 1.1.1.1
  Outgoing interface list:
    GigabitEthernet2.414, Forward/Sparse, 00:00:11/00:03:18

В качестве RPF nbr указан адрес 1.1.1.1 — как PE4 вычисляет его? На самом деле очень просто. Это адрес BGP next-hop для источника = 11.11.11.11

PE4#show ip route vrf C-ONE 11.11.11.11

Routing Table: C-ONE
Routing entry for 11.11.11.11/32
  Known via "bgp 65001", distance 200, metric 0
  Tag 65011, type internal
  Last update from 1.1.1.1 01:02:10 ago
  Routing Descriptor Blocks:
  * 1.1.1.1 (default), from 8.8.8.8, 01:02:10 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65011
      MPLS label: 10018
      MPLS Flags: MPLS Required

Соответственно, РЕ4 генерирует PIM Join и отправляет его в рамках Default MDT:

Данный PIM Join будет получен всеми РЕ, но обработан только на РЕ1 (т.к. только на нём Join пройдет RPF проверку)

PE1#show ip mroute vrf C-ONE | b \(
(11.11.11.11, 230.1.1.1), 00:01:16/00:03:11, flags: sT
  Incoming interface: GigabitEthernet2.111, RPF nbr 172.1.11.11
  Outgoing interface list:
    Tunnel2, Forward/Sparse, 00:01:16/00:03:11

PE2#show ip mroute vrf C-ONE | b \(
PE2#

Проверим работоспособность сервиса:

CE1#ping
Target IP address: 230.1.1.1
Repeat count [1]: 5
Extended commands [n]: y
Interface [All]: GigabitEthernet2.111
Source address or interface: 11.11.11.11

Sending 5, 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 1 from 14.14.14.14, 7 ms
Reply to request 2 from 14.14.14.14, 8 ms
Reply to request 3 from 14.14.14.14, 8 ms
Reply to request 4 from 14.14.14.14, 7 ms

Как видно, многоадресные пакеты корректно передаются через опорную сеть. При этом стоит отметить, что способ передачи пакетов ничем не отличается от того, что мы с Вами наблюдали в рамках Profile0. Т.е. пакеты долетают до всех РЕ в рамках Default MDT и уже там отбрасываются в случае отсутствия активных подписчиков.

В этом можно убедиться, сняв дамп трафика на сети как это показано на рисунке ниже (vlan id = 37 характеризует интерфейс между R3 и R7):

Выше мы рассмотрели случай использования PIM SSM внутри C-VRF. Изменится ли что-либо, если будет работать PIM ASM?

CE4(config-if)#interface Lo0
CE4(config-if)#ip igmp version 2
CE4(config-if)#no ip igmp join-group 230.1.1.1 source 11.11.11.11
CE4(config-if)#ip igmp join-group 231.1.1.1
!
CE15(config)#no ip pim bsr-candidate Loopback0 0
CE15(config)#no ip pim rp-candidate Loopback0
!
CE15(config)#access-list 1 permit 231.1.1.0 0.0.0.255
CE15(config)#ip pim bsr-candidate Lo0
CE15(config)#ip pim rp-candidate Lo0 group-list 1

На РЕ сайта появляется дополнительный туннельный интерфейс для PIM encap:

PE1# 
*Nov 24 21:39:32.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

Все маршрутизаторы внутри C-VRF корректно узнают о появившихся RP и BSR устройствах в сети:

CE1#show ip pim bsr-router 
PIMv2 Bootstrap information
  BSR address: 15.15.15.15 (?)
  Uptime:      00:01:54, BSR Priority: 0, Hash mask length: 0
  Expires:     00:01:16

До тех пор, пока нет активного источника трафика, внутри C-VRF будут наблюдаться только (*, G) маршруты согласно обычной логике работы PIM ASM:

PE4#show ip mroute vrf C-ONE
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 231.1.1.2), 00:00:46/00:02:43, RP 15.15.15.15, flags: S
  Incoming interface: Tunnel0, RPF nbr 1.1.1.1
  Outgoing interface list:
    GigabitEthernet2.414, Forward/Sparse, 00:00:46/00:02:43

При этом внутри BGP домена не появляется никаких дополнительных mvpn префиксов:

PE4#show bgp ipv4 mvpn all 
Route Distinguisher: 1.1.1.1:1
 *>i  [1][1.1.1.1:1][1.1.1.1]/12
                       1.1.1.1                  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
 *>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 (default for vrf C-ONE)
 *>i  [1][4.4.4.4:1][1.1.1.1]/12
                       1.1.1.1                  0    100      0 ?
 *>i  [1][4.4.4.4:1][2.2.2.2]/12
     Network          Next Hop            Metric LocPrf Weight Path
                       2.2.2.2                  0    100      0 ?
 *>i  [1][4.4.4.4:1][3.3.3.3]/12
                       3.3.3.3                  0    100      0 ?
 *>   [1][4.4.4.4:1][4.4.4.4]/12

«Почему?» — спросите Вы? Потому что для сигнализации многоадресного трафика C-VRF используется протокол PIM.

О возможной замене сигнализации на BGP поговорим в следующий раз.