В этой части статьи мы рассмотрим с Вами вариант замены сигнализации в рамках наложенной сети с протокола 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
ссылка на оригинал статьи https://habr.com/ru/post/530150/
Добавить комментарий