В предыдущих выпусках:
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 Loopback0CE4(config-if)#no ip igmp join-group 231.1.1.2CE4(config-if)#CE15(config)#no ip pim bsr-candidate Loopback0 0CE15(config)#no ip pim rp-candidate Loopback0 group-list 1
На всех РЕ укажем, что для сигнализации вместо PIM будет работать
BGP. Это делается следующей командой:
ip vrf C-ONEmdt overlay use-bgp
Отправной точкой наблюдений будет ситуация без наличия источников и
получателей многоадресного трафика. В BGP таблице должны
присутствовать только type-1 маршруты:
PE1#show bgp ipv4 mvpn allBGP table version is 406, local router ID is 1.1.1.1Status 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, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork Next Hop Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*> [1][1.1.1.1:1][1.1.1.1]/120.0.0.0 32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2 0 100 0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3 0 100 0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4 0 100 0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2 0 100 0 ?Route Distinguisher: 3.3.3.3:1Network Next Hop Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3 0 100 0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.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 allRoute Distinguisher: 1.1.1.1:1*> [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/220.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]/224.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.1BGP routing table entry for [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22, version 533Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:7Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (4.4.4.4)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx 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/32BGP routing table entry for 1.1.1.1:1:11.11.11.11/32, version 670Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1 17Refresh Epoch 465011172.1.11.11 (via vrf C-ONE) from 172.1.11.11 (11.11.11.11)Origin IGP, metric 0, localpref 100, valid, external, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1mpls labels in/out 10018/nolabelrx pathid: 0, tx pathid: 0x0PE1#PE2#show bgp vpnv4 unicast rd 2.2.2.2:1 11.11.11.11/32BGP routing table entry for 2.2.2.2:1:11.11.11.11/32, version 762Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 15265011, 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, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1Originator: 1.1.1.1, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 1.1.1.1:1:1.1.1.1mpls labels in/out nolabel/10018rx pathid: 0, tx pathid: 0x0
Проверим связность:
CE1#ping 230.1.1.1 so 11.11.11.11 rep 3Type 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.11Reply to request 0 from 14.14.14.14, 7 msReply to request 0 from 14.14.14.14, 8 msReply to request 1 from 14.14.14.14, 7 msReply to request 1 from 14.14.14.14, 9 msReply to request 2 from 14.14.14.14, 7 msReply 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 mappCE2#show ip pim rp mappingAuto-RP is not enabledPIM Group-to-RP MappingsGroup(s) 231.1.1.0/24RP 15.15.15.15 (?), v2Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150Uptime: 1d04h, expires: 00:02:09CE2#
Как? Если мы посмотрим BGP таблицу, то не найдём там никакого
намёка на эту точку:
PE1#show bgp ipv4 mvpn allBGP table version is 682, local router ID is 1.1.1.1Status 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, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork Next Hop Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*> [1][1.1.1.1:1][1.1.1.1]/120.0.0.0 32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2 0 100 0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3 0 100 0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4 0 100 0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2 0 100 0 ?Route Distinguisher: 3.3.3.3:1Network Next Hop Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3 0 100 0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4 0 100 0 ?
Не надо забывать о том, что у нас есть PMSTI, на котором
активирован PIM:
PE1#show ip pim vrf C-ONE interfaceAddress Interface Ver/ Nbr Query DR DRMode Count Intvl Prior172.1.11.1 GigabitEthernet2.111 v2/S 1 30 1 172.1.11.11172.1.15.1 GigabitEthernet2.115 v2/S 1 30 1 172.1.15.151.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: SPIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list: Null(12.12.12.12, 231.1.1.1), 00:00:19/00:02:40, flags: PIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1Outgoing 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: PFTIncoming interface: Loopback0, RPF nbr 0.0.0.0Outgoing 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: SgIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing 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 allRoute Distinguisher: 1.1.1.1:1*> [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/220.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.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 808Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (4.4.4.4)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx 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 tablePE3#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 tablePE1#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 698Paths: (1 available, best #1, table MVPNv4-BGP-Table)Not advertised to any peerRefresh Epoch 2Local4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:1.1.1.1:1Originator: 4.4.4.4, Cluster list: 8.8.8.8rx 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.15RPF information for ? (15.15.15.15)RPF interface: Tunnel0RPF neighbor: ? (1.1.1.1)RPF route/mask: 15.15.15.15/32RPF type: unicast (bgp 65001)Doing distance-preferred lookups across tablesBGP originator: 1.1.1.1RPF 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/32BGP routing table entry for 4.4.4.4:1:15.15.15.15/32, version 859Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 165015, 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, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1Originator: 1.1.1.1, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 1.1.1.1:1:1.1.1.1mpls labels in/out nolabel/10013rx 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: SgIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing 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: SIncoming interface: Null, RPF nbr 0.0.0.0Outgoing 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: SIncoming interface: Null, RPF nbr 0.0.0.0Outgoing 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: PTIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1Outgoing interface list: Null
Точка рандеву создаёт PIM Join (12.12.12.12, 231.1.1.1), отправляя
его в сторону CE2. PE1 получает указанный PIM Join и создаёт BGP
маршрут 7-го типа:
PE1#show bgp ipv4 mvpn allRoute Distinguisher: 2.2.2.2:1*> [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/220.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.1BGP routing table entry for [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22, version 726Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (1.1.1.1)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:2.2.2.2:1rx 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.12RPF information for ? (12.12.12.12)RPF interface: Tunnel2RPF neighbor: ? (2.2.2.2)RPF route/mask: 12.12.12.12/32RPF type: unicast (bgp 65001)Doing distance-preferred lookups across tablesBGP originator: 2.2.2.2RPF 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.12BGP routing table entry for 1.1.1.1:1:12.12.12.12/32, version 706Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 265012, 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, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:2.2.2.2:1Originator: 2.2.2.2, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 2.2.2.2:1:2.2.2.2mpls labels in/out nolabel/31rx pathid: 0, tx pathid: 0x0
На этом шаге, по сути, завершается построение дерева (12.12.12.12,
231.1.1.1) на участке между источником и точкой рандеву:
После получения маршрута 7-го типа, РЕ2 генерирует маршрут 5-го
типа, сигнализируя о наличии активного источника трафика в сети.
Маршрут импортируется всеми РЕ устройствами.
PE2#show bgp ipv4 mvpn allRoute 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]/180.0.0.0 32768 ?PE2#show bgp ipv4 mvpn all route-type 5 12.12.12.12 231.1.1.1BGP routing table entry for [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18, version 838Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (2.2.2.2)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestCommunity: no-exportExtended Community: RT:65001:1rx 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: TnQIncoming interface: Tunnel0, RPF nbr 2.2.2.2Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:22:24/00:03:19
Прим обратите внимание на флаг Q,
который говорит о том, что запись была создана благодаря сообщению
BGP Source-Active
Рассмотренный вариант организации mVPN носит кодовое имя Profile
11. Его основные характеристики:
- для передачи многоадресного трафика наложенной сети
используется Default MDT
- в качестве метода организации транспорта выступает протокол
mGRE
- для сигнализации многоадресного дерева в рамках наложенной сети
используется протокол BGP