В предыдущих выпусках:
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.
Для более простого понимания BGP сигнализации для построения многоадресных деревьев, начнём наш разговор с более простого PIM SSM.
Прежде всего, уберём текущие настройки точки рандеву и отключим получателей трафика:
На всех РЕ укажем, что для сигнализации вместо PIM будет работать BGP. Это делается следующей командой:
Отправной точкой наблюдений будет ситуация без наличия источников и получателей многоадресного трафика. В BGP таблице должны присутствовать только type-1 маршруты:
Подключим получателя:
На ближайшем РЕ создаётся BGP маршрут 7-го типа — это эквивалент сообщения PIM (S, G) Join:
По логике вещей, данный маршрут должен присутствовать только на РЕ4 и на РЕ1 (т.к именно через них должен проходить трафик) и отсутствовать на РЕ2 и РЕ3. Проверим:
Как так получается, что маршрут, изначальной порождённый на РЕ4, импортируется только на РЕ1?
Посмотрим на запись в BGP-таблице чуть детальнее:
В записи префикса присутствует расширенное коммьюнити Route-target = 1.1.1.1:1, которое было добавлено в vpnv4 префикс маршрутизатором, который с точки РЕ4 является RPF соседом:
Проверим связность:
В случае работы C-PIM в режиме SSM всё довольно просто. Для корректной работы mVPN достаточно создания двух дополнительных (типов) BGP маршрутов.
А как обстоят дела, если внутри C-VRF используется более комплексный ASM PIM?
Прежде всего мы видим, что на всех СЕ известна информация о точке рандеву:
Как? Если мы посмотрим BGP таблицу, то не найдём там никакого намёка на эту точку:
Не надо забывать о том, что у нас есть PMSTI, на котором активирован PIM:
Отсюда можно сделать важный вывод — некоторые сообщения PIM (даже при BGP сигнализации) передаются поверх опорной сети в рамках Default MDT.
Представим, что в сети появился источник (за маршрутизатором СЕ2). Поскольку на СЕ2 на данный момент нет записей в mRIB, то PIM Designated Router (в нашем случае это сам СЕ2) отправляет сообщение Register на точку рандеву, тем самым сигнализируя о наличии активного источника в сети.
На точке рандеву создаётся дерево (12.12.12.12, 231.1.1.1):
И, поскольку, в сети нет активных получателей трафика (отсутствует дерево (*, 231.1.1.1)), то со стороны CE5 создаётся сообщение Register-Stop
В ответ на получение Register-Stop, CE2 приостанавливает передачу данных (нет интерфейсов в OIL):
Теперь представим, что в сети появился получатель, заинтересованный в трафике для группы 231.1.1.1. На РЕ4 появляется маршрут внутри C-VRF:
И создаётся BGP маршрут 6-го типа, который является эквивалентом PIM Join (*, 231.1.1.1):
В приведённом выше выводе необходимо обратить внимание на расширенное коммьюнити Route-target = 1.1.1.1:1. Что это и откуда взялось?
Проверим наличие данного префикса на других РЕ:
Т.е. префикс существует только на РЕ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 для адреса точки рандеву:
В качестве RPF соседа виден РЕ1. Значит, РЕ4 должен поместить внутрь маршрута 6-го типа такой Route-target, который будет импортирован только РЕ1. Чтобы ответить на вопрос «откуда РЕ4 его знает?» — посмотрим, для начала, на vpn маршрут:
Обратите внимание на дополнительное коммьюнити MVPN VRF:1.1.1.1:1. Это ничто иное, как коммьюнити Route Import, сгенерированное РЕ1. Именно это значение копируется как Route-target внутрь многоадресного маршрута, что позволяет РЕ1 импортировать полученный апдейт от РЕ4.
Результатом обработки BGP маршрут 6-го типа на РЕ4 является создание записи в многоадресной таблице маршрутизации:
Прим — обратите внимание, что входным интерфейсом указан Tunnel0 (PMSTI).
На точке рандеву завершается создание общего дерева:
Теперь, если в сети опять появится активный источник трафика, точка рандеву будет знать как «совместить» (*, 231.1.1.1) и (12.12.12.12, 231.1.1.1) деревья.
Точка рандеву создаёт PIM Join (12.12.12.12, 231.1.1.1), отправляя его в сторону CE2. PE1 получает указанный PIM Join и создаёт BGP маршрут 7-го типа:
Обратите внимание, что в качестве Remote VPN RD выставляется значение 2.2.2.2:1, т.к. именно через РЕ2 завершается RPF проверка маршрута:
И RT 2.2.2.2:1 был добавлен в VPNv4 префикс со стороны РЕ2:
На этом шаге, по сути, завершается построение дерева (12.12.12.12, 231.1.1.1) на участке между источником и точкой рандеву:
После получения маршрута 7-го типа, РЕ2 генерирует маршрут 5-го типа, сигнализируя о наличии активного источника трафика в сети. Маршрут импортируется всеми РЕ устройствами.
При получении маршрута 5-го типа, на РЕ4 (где находится получатель) завершается создание многоадресного дерева:
Прим — обратите внимание на флаг Q, который говорит о том, что запись была создана благодаря сообщению BGP Source-Active
Рассмотренный вариант организации mVPN носит кодовое имя «Profile 11». Его основные характеристики:
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
