Внедрение 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 поговорим в следующий раз.