[Cisco, Сетевые технологии] Внедрение Multicast VPN на Cisco IOS (часть 5 — знакомство с Data/Partitioned MDT)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В предыдущих выпусках:
Profile 0
Profile 1
Profile 3
Profile 11
Как мы узнали из прошлых записей, в опорной сети при реализации mVPN всегда присутствует конструкция Default MDT, к которой подключены все РЕ маршрутизаторы. В рамках данного MDT передаются служебные сообщения PIM (например Bootstrap, Auto-RP), а также пользовательский многоадресный трафик. В результате получается, что какие-то РЕ устройства получают даже тот трафик, на который они не подписывались.
Если хотите узнать как с этим бороться — добро пожаловать под кат!
Для того чтобы повысить эффективность передачи данных используется дополнительная конструкция, которая именуется как «Data MDT». Идея, которая лежит в её основе, заключается в следующем:
- В рамках дерева распространяется только C-(S, G) трафик
- Участниками дерева становятся только те Egress PE, у которых есть заинтересованные получатели
- Корневым устройством Data MDT является Ingress PE (маршрутизатор, за которым находится источник)
Визуально это выглядит следующим образом:
Если представить ситуацию, в которой источник начинает вещать на вторую многоадресную группу (230.1.1.2), получатели для которой находятся только за РЕ2 и РЕ3, то создаётся дополнительное Data MDT и общая картинка приобретает вид (Default MDT опущено):
Сигнализация по переключению трафика от Default MDT к Data MDT осуществляется исключительно по-требованию при превышении заданного порога со стороны Ingress PE либо средствами PIM, либо средствами BGP.
Data MDT с помощью PIM
Если для сигнализации используется PIM, то ingress PE генерирует специальное сообщение PIM Data-MDT TLV и отправляет его в рамках Default MDT чтобы быть уверенным в том, что все РЕ смогут получить данное сообщение. Одновременно с отправкой Data MDT TLV, Ingress PE запускает таймер, равный трём секундам. По истечении таймера, все пакеты будут передаваться в рамках Data MDT.
Также необходимо отметить тот факт, что информация, содержащаяся в Data-MDT TLV кешируется на всех РЕ. Причина тому довольно банальна — даже если в текущий момент на конкретном РЕ нет заинтересованных получателей трафика, они могут появиться там спустя некоторое время. Соответственно, при получении PIM Join (внутри C-VRF) PE может моментально подключиться к уже существующему на сети Data MDT.
Прим. Data-MDT TLV передаются раз в минуту.
Каждое Data MDT устанавливается для отдельного (S, G) маршрута в рамках VPN/VRF. Администратору необходимо явно указать максимальное количество Data MDT, которое может быть создано на устройстве. Если в какой-то момент количество вновь устанавливаемых деревьев достигает заданного предела, то следующие деревья будут переиспользовать уже установленные.
Прим. На момент написания статьи, Cisco IOS не поддерживает PIM сигнализацию поверх Data MDT. Все профили с данной сигнализацией доступны только на операционной системе IOS XR.
Data MDT с помощью BGP
При использовании BGP в наложенной сети для сигнализации Data MDT, основные принципы остаются неизменными (по сравнению с PIM):
- ingress PE сигнализирует всем РЕ о том, что трафик для C-(S,G) будет передаваться в рамках Data MDT
- egress PE при получении BGP апдейта присоединяется к указанному дереву
- для сигнализации используется адресное семейство mVPN (sAFI 129).
Получается, что Ingress PE должен сформировать специальное BGP Update сообщение и отправить его всем РЕ в рамках mVPN. Для этого используется маршрут третьего типа.
Profile 14
Рассмотрим описанный переход на примере нашей лаборатории. В частности, применим конфигурацию, известную как «Profile 14». Данный профиль характеризуется использованием BGP mVPN A-D для построения P2MP MLDP LSP.
На РЕ будем использовать следующий шаблон конфигурации:
ip vrf C-ONE
mdt auto-discovery mldp
mdt partitioned mldp p2mp
mdt overlay use-bgp
mdt strict-rpf interface
!
router bgp 1
address-family ipv4 mvpn
neighbor 8.8.8.8 activate
neighbor 8.8.8.8 send-community extended
exit-address-family
Прим. о предназначении команды mdt strict-rpf interface поговорим в следующем выпуске.
Auto-Discovery
Посмотрим, что происходит на РЕ1:
На каждом РЕ создаётся интерфейс Lspvif0, на котором активируется C-PIM.
*Dec 3 10:04:54.450: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up
Никаких соседей на данный момент нет:
PE1#show ip pim vrf C-ONE int
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 Lspvif0 v2/S 0 30 1 1.1.1.1
Посмотрим BGP таблицу:
PE1#show bgp ipv4 mvpn all
BGP table version is 39, 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 ?
Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)
*> [3][1.1.1.1:1][*][*][1.1.1.1]/14
0.0.0.0 32768 ?
*>i [3][1.1.1.1:1][*][*][2.2.2.2]/14
2.2.2.2 0 100 0 ?
*>i [3][1.1.1.1:1][*][*][3.3.3.3]/14
3.3.3.3 0 100 0 ?
*>i [3][1.1.1.1:1][*][*][4.4.4.4]/14
4.4.4.4 0 100 0 ?
*> [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18
0.0.0.0 32768 ?
Route Distinguisher: 2.2.2.2:1
*>i [3][2.2.2.2:1][*][*][2.2.2.2]/14
2.2.2.2 0 100 0 ?
Route Distinguisher: 3.3.3.3:1
*>i [3][3.3.3.3:1][*][*][3.3.3.3]/14
3.3.3.3 0 100 0 ?
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 4.4.4.4:1
*>i [3][4.4.4.4:1][*][*][4.4.4.4]/14
4.4.4.4 0 100 0 ?
Как видно, в дополнение к уже рассмотренным ранее маршрутам первого типа, добавляются маршруты третьего типа S-PMSI A-D, которые используются для объявления РЕ в качестве Ingress маршрутизатора для конкретной C-(S,G) группы. На текущий момент группа равна (*, *). Это говорит о желании РЕ участвовать в построении Partitioned MDT.
Очевидно, чтобы заработала передача данных, в рамках VRF должна быть известна информация о точке рандеву. В нашем случае в качестве RP и BSR выступает CE15.
C-RP#sh run | i pim
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0
Поскольку у C-RP построено PIM соседство с PE1, то на этом РЕ1 информация об RP также известна:
PE1#show ip pim vrf C-ONE rp mapping
Auto-RP is not enabled
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 15.15.15.15 (?), v2
Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150
Uptime: 01:25:50, expires: 00:01:26
Необходимо доставить эту информацию до всех остальных PE/CE. Как это сделать? Чтобы лучше понять принцип, предлагаю пойти от обратного и начать просмотра уже известной информации на СЕ2:
CE2#show ip pim rp mapping
Auto-RP is not enabled
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 15.15.15.15 (?), v2
Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150
Uptime: 01:27:54, expires: 00:02:26
Как видим, сообщения PIM BSR распространилось по mVPN инфраструктуре. Посмотрим дамп трафика на РЕ1:
Как видим PE1 инкапсулирует сообщение PIM BSR внутрь MPLS и помечает его меткой 28. Откуда она берётся? Можем предположить, что поскольку этот пакет достиг СЕ2 (а значит и РЕ2), то есть некий LSP до РЕ2.
PE2#show mpls mldp database
* For interface indicates MLDP recursive forwarding is enabled
* For RPF-ID indicates wildcard value
> Indicates it is a Primary MLDP MDT Branch
LSM ID : 1 Type: P2MP Uptime : 04:17:40
FEC Root : 2.2.2.2 (we are the root)
Opaque decoded : [gid 65536 (0x00010000)]
Opaque length : 4 bytes
Opaque value : 01 0004 00010000
Upstream client(s) :
None
Expires : N/A Path Set ID : 1
Replication client(s):
> MDT (VRF C-ONE)
Uptime : 04:17:40 Path Set ID : None
Interface : Lspvif0 RPF-ID : *
LSM ID : 3 Type: P2MP Uptime : 01:30:06
FEC Root : 1.1.1.1
Opaque decoded : [gid 131071 (0x0001FFFF)]
Opaque length : 4 bytes
Opaque value : 01 0004 0001FFFF
Upstream client(s) :
6.6.6.6:0 [Active]
Expires : Never Path Set ID : 3
Out Label (U) : None Interface : GigabitEthernet2.26*
Local Label (D): 34 Next Hop : 10.2.6.6
Replication client(s):
MDT (VRF C-ONE)
Uptime : 01:30:06 Path Set ID : None
Interface : Lspvif0 RPF-ID : *
Из анализа базы mLDP видно, что на РЕ2 есть некое дерево (LSM ID: 3), корнем которого является PE1 (IP = 1.1.1.1), Opaque = 01 0004 0001FFFF и для этого дерева сгенерирована локальная метка 34, которая отправлена соседу R6 (P2).
Откуда РЕ2 узнал о дереве, корнем которого является PE1 да ещё и получил Opaque для него? Ответ прост — с помощью BGP маршрута третьего типа.
Когда РЕ1 получил PIM BSR, то сгенерировал дополнительный BGP маршрут, который описывает группу (*, 224.0.0.13) (напоминаю, что это зарезервированный адрес для рассылки всех служебных PIM сообщений). Этот маршрут служит для объявления нового многоадресного mLDP дерева. Внутри РТА указано Opaque значение, которое необходимо использовать для сигнализации посредством mLDP.
PE1#show bgp ipv4 mvpn all route-type 3 * 224.0.0.13 1.1.1.1
BGP routing table entry for [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18, version 116
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
Advertised to update-groups:
1
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
Community: no-export
Extended Community: RT:65001:1
PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 17, label: exp-null, tunnel parameters: 0600 0104 0101 0101 0007 0100 0400 01FF FF
rx pathid: 0, tx pathid: 0x0
Таким образом, РЕ2 импортируя этот маршрут, может начать mLDP сигнализацию в сторону РЕ1 для дерева (*, 224.0.0.13). Для полученной от РЕ2 метки, Р2 (R6) генерирует свой собственную локальную (29) и отправляет её в сторону P1 (R5):
P2#show mpls mldp database
* For interface indicates MLDP recursive forwarding is enabled
* For RPF-ID indicates wildcard value
> Indicates it is a Primary MLDP MDT Branch
LSM ID : 2 Type: P2MP Uptime : 01:40:24
FEC Root : 1.1.1.1
Opaque decoded : [gid 131071 (0x0001FFFF)]
Opaque length : 4 bytes
Opaque value : 01 0004 0001FFFF
Upstream client(s) :
5.5.5.5:0 [Active]
Expires : Never Path Set ID : 2
Out Label (U) : None Interface : GigabitEthernet2.56*
Local Label (D): 29 Next Hop : 10.5.6.5
Replication client(s):
2.2.2.2:0
Uptime : 01:40:24 Path Set ID : None
Out label (D) : 34 Interface : GigabitEthernet2.26*
Local label (U): None Next Hop : 10.2.6.2
Аналогичным образом поступает и Р1 (R5), генерируя свою локальную метку для дерева и отправляя её к РЕ1:
P1#show mpls mldp database
* For interface indicates MLDP recursive forwarding is enabled
* For RPF-ID indicates wildcard value
> Indicates it is a Primary MLDP MDT Branch
LSM ID : 2 Type: P2MP Uptime : 01:41:24
FEC Root : 1.1.1.1
Opaque decoded : [gid 131071 (0x0001FFFF)]
Opaque length : 4 bytes
Opaque value : 01 0004 0001FFFF
Upstream client(s) :
1.1.1.1:0 [Active]
Expires : Never Path Set ID : 2
Out Label (U) : None Interface : GigabitEthernet2.15*
Local Label (D): 28 Next Hop : 10.1.5.1
Replication client(s):
4.4.4.4:0
Uptime : 01:41:24 Path Set ID : None
Out label (D) : 34 Interface : GigabitEthernet2.45*
Local label (U): None Next Hop : 10.4.5.4
7.7.7.7:0
Uptime : 01:41:24 Path Set ID : None
Out label (D) : 30 Interface : GigabitEthernet2.57*
Local label (U): None Next Hop : 10.5.7.7
6.6.6.6:0
Uptime : 01:41:24 Path Set ID : None
Out label (D) : 29 Interface : GigabitEthernet2.56*
Local label (U): None Next Hop : 10.5.6.6
Визуально весь процесс представлен на рисунке ниже:
Присоединение к Shared Tree и построение корневого P2MP дерева (ROOT = RP-PE)
Шаг 2. В сети появляется получатель трафика. После того как Egress PE (РЕ2) получает PIM Join от CE для C-(*, G), PE2 производит RPF проверку чтобы найти BGP Next-Hop в сторону C-RP. Найденный Next-Hop (1.1.1.1) будет использоваться как Partitioned MDT ROOT для mLDP.
Дополнительно РЕ2 создаёт интерфейс Lspvif внутри C-VRF:
PE2#
*Dec 3 14:46:21.606: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to up
PE2#
*Dec 3 14:46:22.310: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1
Шаг 3. Egress PE (PE2) генерирует сообщение mLDP mapping в сторону RP-PE (ROOT P2MP MDT) используя Opaque значение из BGP апдейта.
PE2#show mpls mldp database summary
LSM ID Type Root Decoded Opaque Value Client Cnt.
4 P2MP 1.1.1.1 [gid 65536 (0x00010000)] 1
1 P2MP 2.2.2.2 [gid 65536 (0x00010000)] 1
3 P2MP 1.1.1.1 [gid 131071 (0x0001FFFF)] 1
PE2#
PE2#show mvpn ipv4 vrf C-ONE auto-discovery s-pmsi * * detail
I-PMSI - Intra-AS Inclusive-PMSI, S-PMSI - Selective-PMSI
* - Indicates Wildcard source or group address
[S-PMSI][1.1.1.1:1][*][*][1.1.1.1], Joined
Orig: Remote Uptime: 04:44:27 Type: MLDP P2MP
Root: 1.1.1.1 Fec-Opq: 1 Global-Id: 65536 (0x10000)
[S-PMSI][3.3.3.3:1][*][*][3.3.3.3],
Orig: Remote Uptime: 04:44:22 Type: MLDP P2MP
Root: 3.3.3.3 Fec-Opq: 1 Global-Id: 65536 (0x10000)
[S-PMSI][4.4.4.4:1][*][*][4.4.4.4],
Orig: Remote Uptime: 04:44:20 Type: MLDP P2MP
Root: 4.4.4.4 Fec-Opq: 1 Global-Id: 65536 (0x10000)
[S-PMSI][2.2.2.2:1][*][*][2.2.2.2], Joined
Orig: Local Uptime: 04:44:24 Type: MLDP P2MP
Root: 2.2.2.2 Fec-Opq: 1 Global-Id: 65536 (0x10000)
PE2#show mpls mldp database opaque_type gid 65536
LSM ID : 4 Type: P2MP Uptime : 00:03:43
FEC Root : 1.1.1.1
Opaque decoded : [gid 65536 (0x00010000)]
Opaque length : 4 bytes
Opaque value : 01 0004 00010000
Upstream client(s) :
6.6.6.6:0 [Active]
Expires : Never Path Set ID : 4
Out Label (U) : None Interface : GigabitEthernet2.26*
Local Label (D): 35 Next Hop : 10.2.6.6
Replication client(s):
MDT (VRF C-ONE)
Uptime : 00:03:43 Path Set ID : None
Interface : Lspvif1 RPF-ID : 0x1
Шаг 4. Egress PE генерирует BGP маршрут шестого типа (присоединение к Shared Tree в сторону RP-PE). Данный маршрут импортируется только на RP-PE.
PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 230.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][230.1.1.1/32]/22, version 130
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
1
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
Extended Community: RT:1.1.1.1:1
rx pathid: 1, tx pathid: 0x0
Шаг 5. RP-PE транслирует полученный BGP маршрут шестого типа в PIM Join в сторону RP. На этот момент RP готово к отправке многоадресного трафика в сторону Egress PE. Необходимо доставить трафик от источника до RP.
PE1#show ip mroute vrf C-ONE | b \(
(*, 230.1.1.1), 00:07:08/stopped, RP 15.15.15.15, flags: SG
Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.15
Outgoing interface list:
Lspvif0, Forward/Sparse, 00:07:08/stopped
Шаг 6. Когда S-PE (PE4) получает первый многоадресный пакет от источника (CE4), трафик инкапсулируется внутрь сообщения PIM Register и отправляется как одноадресный пакет в сторону C-RP (используя обычные правила MPLS L3 VPN).
Шаг 7. После получения PIM Register, C-RP начинает процесс построения дерева С-(14.14.14.14, 230.1.1.1). RP-PE получает PIM Join для C-(14.14.14.14, 230.1.1.1) от C-RP. Данное сообщение транслируется в BGP маршрут седьмого типа. Однако, перед отправкой в сторону источника, необходимо построить новое дерево Partitioned MDT с РЕ в качестве ROOT.
Шаг 8. RP-PE производит RPF проверку чтобы найти BGP Next-Hop в сторону источника. Данный адрес будет использоваться как Partitioned MDT ROOT для mLDP.
Шаг 9. Используя полученный BGP Next-Hop и BGP маршрут третьего типа от Ingress PE, RP-PR генерирует сообщение mLDP mapping в сторону IP адреса Ingress PE, тем самым строя корневое P2MP дерево до Ingress PE.
Шаг 10. RP-PE отправляет BGP маршрут седьмого типа (Join от RP) в сторону Ingress PE.
Шаг 11. Ingress PE преобразует полученный BGP маршрут седьмого типа в PIM Join и отправляет его в сторону источника трафика.
Присоединение к Source Tree и построение P2MP (ROOT = S-PE)
Шаг 12. Ingress PE также отправляет BGP маршрут пятого типа ко всем mVPN PE, тем самым информируя их о наличии активного источника в сети. Данный маршрут является триггером для переключения к SPT дереву.
Шаг 13. Egress PE использует полученный BGP маршрут пятого типа для генерации сообщения mLDP mapping в сторону Ingress PE (информация о MDT берётся из BGP маршрута третьего типа).
Таким образом теперь трафик может быть перенаправлен оптимальным путём от источника к получателю, используя mpls (mLDP) метки.
===========
Источник:
habr.com
===========
Похожие новости:
- [Python, Сетевые технологии, Беспроводные технологии] Небольшой рассказ, как мы модернизировали и расширяли сеть Wi-Fi до 14 000 точек доступа
- [Сетевые технологии] Как находить проблемы с интернетом и кто виноват ч.2 — домашняя работа
- [Сетевые технологии, Дизайн] Новый интерфейс Веб-клиента Zimbra от Zextras
- [Настройка Linux, Сетевые технологии, Программирование микроконтроллеров] Делаем из ENC28J60 внешнюю USB сетевую карту
- [Сетевые технологии, Сетевое оборудование, Транспорт] В НАСА разрабатывают аналог кабеля Ethernet для сверхзвуковых самолетов
- [Сетевые технологии, Беспроводные технологии, Разработка систем связи, Научно-популярное, Космонавтика] Всё о проекте «Спутниковый интернет Starlink». Часть 20. Внутреннее устройство терминала SL
- [Сетевые технологии] Как находить проблемы с интернетом и кто виноват ч.1
- [Сетевые технологии, IT-стандарты, Стандарты связи, Разработка для интернета вещей] Эффективное применение DLMS/COSEM в больших системах с ограниченными ресурсами (перевод)
- [Cisco, Сетевые технологии] Внедрение Multicast VPN на Cisco IOS (часть 4 — BGP сигнализация)
- [Системное администрирование, Сетевые технологии, Резервное копирование, Облачные сервисы] Off-site резервирование Zimbra OSE с помощью Zextras Backup
Теги для поиска: #_cisco, #_setevye_tehnologii (Сетевые технологии), #_cisco, #_pim, #_multicast, #_mldp, #_mvpn, #_cisco, #_setevye_tehnologii (
Сетевые технологии
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:03
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
В предыдущих выпусках: Profile 0 Profile 1 Profile 3 Profile 11 Как мы узнали из прошлых записей, в опорной сети при реализации mVPN всегда присутствует конструкция Default MDT, к которой подключены все РЕ маршрутизаторы. В рамках данного MDT передаются служебные сообщения PIM (например Bootstrap, Auto-RP), а также пользовательский многоадресный трафик. В результате получается, что какие-то РЕ устройства получают даже тот трафик, на который они не подписывались. Если хотите узнать как с этим бороться — добро пожаловать под кат!  Для того чтобы повысить эффективность передачи данных используется дополнительная конструкция, которая именуется как «Data MDT». Идея, которая лежит в её основе, заключается в следующем:
Визуально это выглядит следующим образом:  Если представить ситуацию, в которой источник начинает вещать на вторую многоадресную группу (230.1.1.2), получатели для которой находятся только за РЕ2 и РЕ3, то создаётся дополнительное Data MDT и общая картинка приобретает вид (Default MDT опущено):  Сигнализация по переключению трафика от Default MDT к Data MDT осуществляется исключительно по-требованию при превышении заданного порога со стороны Ingress PE либо средствами PIM, либо средствами BGP.  Data MDT с помощью PIM Если для сигнализации используется PIM, то ingress PE генерирует специальное сообщение PIM Data-MDT TLV и отправляет его в рамках Default MDT чтобы быть уверенным в том, что все РЕ смогут получить данное сообщение. Одновременно с отправкой Data MDT TLV, Ingress PE запускает таймер, равный трём секундам. По истечении таймера, все пакеты будут передаваться в рамках Data MDT. Также необходимо отметить тот факт, что информация, содержащаяся в Data-MDT TLV кешируется на всех РЕ. Причина тому довольно банальна — даже если в текущий момент на конкретном РЕ нет заинтересованных получателей трафика, они могут появиться там спустя некоторое время. Соответственно, при получении PIM Join (внутри C-VRF) PE может моментально подключиться к уже существующему на сети Data MDT. Прим. Data-MDT TLV передаются раз в минуту. Каждое Data MDT устанавливается для отдельного (S, G) маршрута в рамках VPN/VRF. Администратору необходимо явно указать максимальное количество Data MDT, которое может быть создано на устройстве. Если в какой-то момент количество вновь устанавливаемых деревьев достигает заданного предела, то следующие деревья будут переиспользовать уже установленные. Прим. На момент написания статьи, Cisco IOS не поддерживает PIM сигнализацию поверх Data MDT. Все профили с данной сигнализацией доступны только на операционной системе IOS XR. Data MDT с помощью BGP При использовании BGP в наложенной сети для сигнализации Data MDT, основные принципы остаются неизменными (по сравнению с PIM):
Получается, что Ingress PE должен сформировать специальное BGP Update сообщение и отправить его всем РЕ в рамках mVPN. Для этого используется маршрут третьего типа. Profile 14 Рассмотрим описанный переход на примере нашей лаборатории. В частности, применим конфигурацию, известную как «Profile 14». Данный профиль характеризуется использованием BGP mVPN A-D для построения P2MP MLDP LSP. На РЕ будем использовать следующий шаблон конфигурации: ip vrf C-ONE
mdt auto-discovery mldp mdt partitioned mldp p2mp mdt overlay use-bgp mdt strict-rpf interface ! router bgp 1 address-family ipv4 mvpn neighbor 8.8.8.8 activate neighbor 8.8.8.8 send-community extended exit-address-family Прим. о предназначении команды mdt strict-rpf interface поговорим в следующем выпуске. Auto-Discovery Посмотрим, что происходит на РЕ1: На каждом РЕ создаётся интерфейс Lspvif0, на котором активируется C-PIM. *Dec 3 10:04:54.450: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up
Никаких соседей на данный момент нет: PE1#show ip pim vrf C-ONE int
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 Lspvif0 v2/S 0 30 1 1.1.1.1 Посмотрим BGP таблицу: PE1#show bgp ipv4 mvpn all
BGP table version is 39, 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 ? Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE) *> [3][1.1.1.1:1][*][*][1.1.1.1]/14 0.0.0.0 32768 ? *>i [3][1.1.1.1:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? *>i [3][1.1.1.1:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? *>i [3][1.1.1.1:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ? *> [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18 0.0.0.0 32768 ? Route Distinguisher: 2.2.2.2:1 *>i [3][2.2.2.2:1][*][*][2.2.2.2]/14 2.2.2.2 0 100 0 ? Route Distinguisher: 3.3.3.3:1 *>i [3][3.3.3.3:1][*][*][3.3.3.3]/14 3.3.3.3 0 100 0 ? Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 4.4.4.4:1 *>i [3][4.4.4.4:1][*][*][4.4.4.4]/14 4.4.4.4 0 100 0 ? Как видно, в дополнение к уже рассмотренным ранее маршрутам первого типа, добавляются маршруты третьего типа S-PMSI A-D, которые используются для объявления РЕ в качестве Ingress маршрутизатора для конкретной C-(S,G) группы. На текущий момент группа равна (*, *). Это говорит о желании РЕ участвовать в построении Partitioned MDT. Очевидно, чтобы заработала передача данных, в рамках VRF должна быть известна информация о точке рандеву. В нашем случае в качестве RP и BSR выступает CE15. C-RP#sh run | i pim
ip pim bsr-candidate Loopback0 0 ip pim rp-candidate Loopback0 Поскольку у C-RP построено PIM соседство с PE1, то на этом РЕ1 информация об RP также известна: PE1#show ip pim vrf C-ONE rp mapping
Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:25:50, expires: 00:01:26 Необходимо доставить эту информацию до всех остальных PE/CE. Как это сделать? Чтобы лучше понять принцип, предлагаю пойти от обратного и начать просмотра уже известной информации на СЕ2: CE2#show ip pim rp mapping
Auto-RP is not enabled PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 15.15.15.15 (?), v2 Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150 Uptime: 01:27:54, expires: 00:02:26 Как видим, сообщения PIM BSR распространилось по mVPN инфраструктуре. Посмотрим дамп трафика на РЕ1:  Как видим PE1 инкапсулирует сообщение PIM BSR внутрь MPLS и помечает его меткой 28. Откуда она берётся? Можем предположить, что поскольку этот пакет достиг СЕ2 (а значит и РЕ2), то есть некий LSP до РЕ2. PE2#show mpls mldp database
* For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 1 Type: P2MP Uptime : 04:17:40 FEC Root : 2.2.2.2 (we are the root) Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : None Expires : N/A Path Set ID : 1 Replication client(s): > MDT (VRF C-ONE) Uptime : 04:17:40 Path Set ID : None Interface : Lspvif0 RPF-ID : * LSM ID : 3 Type: P2MP Uptime : 01:30:06 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 3 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 34 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 01:30:06 Path Set ID : None Interface : Lspvif0 RPF-ID : * Из анализа базы mLDP видно, что на РЕ2 есть некое дерево (LSM ID: 3), корнем которого является PE1 (IP = 1.1.1.1), Opaque = 01 0004 0001FFFF и для этого дерева сгенерирована локальная метка 34, которая отправлена соседу R6 (P2). Откуда РЕ2 узнал о дереве, корнем которого является PE1 да ещё и получил Opaque для него? Ответ прост — с помощью BGP маршрута третьего типа. Когда РЕ1 получил PIM BSR, то сгенерировал дополнительный BGP маршрут, который описывает группу (*, 224.0.0.13) (напоминаю, что это зарезервированный адрес для рассылки всех служебных PIM сообщений). Этот маршрут служит для объявления нового многоадресного mLDP дерева. Внутри РТА указано Opaque значение, которое необходимо использовать для сигнализации посредством mLDP. PE1#show bgp ipv4 mvpn all route-type 3 * 224.0.0.13 1.1.1.1
BGP routing table entry for [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18, version 116 Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer) Advertised to update-groups: 1 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 Community: no-export Extended Community: RT:65001:1 PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 17, label: exp-null, tunnel parameters: 0600 0104 0101 0101 0007 0100 0400 01FF FF rx pathid: 0, tx pathid: 0x0 Таким образом, РЕ2 импортируя этот маршрут, может начать mLDP сигнализацию в сторону РЕ1 для дерева (*, 224.0.0.13). Для полученной от РЕ2 метки, Р2 (R6) генерирует свой собственную локальную (29) и отправляет её в сторону P1 (R5): P2#show mpls mldp database
* For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 2 Type: P2MP Uptime : 01:40:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 5.5.5.5:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.56* Local Label (D): 29 Next Hop : 10.5.6.5 Replication client(s): 2.2.2.2:0 Uptime : 01:40:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.26* Local label (U): None Next Hop : 10.2.6.2 Аналогичным образом поступает и Р1 (R5), генерируя свою локальную метку для дерева и отправляя её к РЕ1: P1#show mpls mldp database
* For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 2 Type: P2MP Uptime : 01:41:24 FEC Root : 1.1.1.1 Opaque decoded : [gid 131071 (0x0001FFFF)] Opaque length : 4 bytes Opaque value : 01 0004 0001FFFF Upstream client(s) : 1.1.1.1:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : GigabitEthernet2.15* Local Label (D): 28 Next Hop : 10.1.5.1 Replication client(s): 4.4.4.4:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 34 Interface : GigabitEthernet2.45* Local label (U): None Next Hop : 10.4.5.4 7.7.7.7:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 30 Interface : GigabitEthernet2.57* Local label (U): None Next Hop : 10.5.7.7 6.6.6.6:0 Uptime : 01:41:24 Path Set ID : None Out label (D) : 29 Interface : GigabitEthernet2.56* Local label (U): None Next Hop : 10.5.6.6 Визуально весь процесс представлен на рисунке ниже:  Присоединение к Shared Tree и построение корневого P2MP дерева (ROOT = RP-PE) Шаг 2. В сети появляется получатель трафика. После того как Egress PE (РЕ2) получает PIM Join от CE для C-(*, G), PE2 производит RPF проверку чтобы найти BGP Next-Hop в сторону C-RP. Найденный Next-Hop (1.1.1.1) будет использоваться как Partitioned MDT ROOT для mLDP. Дополнительно РЕ2 создаёт интерфейс Lspvif внутри C-VRF: PE2#
*Dec 3 14:46:21.606: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to up PE2# *Dec 3 14:46:22.310: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1 Шаг 3. Egress PE (PE2) генерирует сообщение mLDP mapping в сторону RP-PE (ROOT P2MP MDT) используя Opaque значение из BGP апдейта. PE2#show mpls mldp database summary
LSM ID Type Root Decoded Opaque Value Client Cnt. 4 P2MP 1.1.1.1 [gid 65536 (0x00010000)] 1 1 P2MP 2.2.2.2 [gid 65536 (0x00010000)] 1 3 P2MP 1.1.1.1 [gid 131071 (0x0001FFFF)] 1 PE2# PE2#show mvpn ipv4 vrf C-ONE auto-discovery s-pmsi * * detail I-PMSI - Intra-AS Inclusive-PMSI, S-PMSI - Selective-PMSI * - Indicates Wildcard source or group address [S-PMSI][1.1.1.1:1][*][*][1.1.1.1], Joined Orig: Remote Uptime: 04:44:27 Type: MLDP P2MP Root: 1.1.1.1 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][3.3.3.3:1][*][*][3.3.3.3], Orig: Remote Uptime: 04:44:22 Type: MLDP P2MP Root: 3.3.3.3 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][4.4.4.4:1][*][*][4.4.4.4], Orig: Remote Uptime: 04:44:20 Type: MLDP P2MP Root: 4.4.4.4 Fec-Opq: 1 Global-Id: 65536 (0x10000) [S-PMSI][2.2.2.2:1][*][*][2.2.2.2], Joined Orig: Local Uptime: 04:44:24 Type: MLDP P2MP Root: 2.2.2.2 Fec-Opq: 1 Global-Id: 65536 (0x10000) PE2#show mpls mldp database opaque_type gid 65536 LSM ID : 4 Type: P2MP Uptime : 00:03:43 FEC Root : 1.1.1.1 Opaque decoded : [gid 65536 (0x00010000)] Opaque length : 4 bytes Opaque value : 01 0004 00010000 Upstream client(s) : 6.6.6.6:0 [Active] Expires : Never Path Set ID : 4 Out Label (U) : None Interface : GigabitEthernet2.26* Local Label (D): 35 Next Hop : 10.2.6.6 Replication client(s): MDT (VRF C-ONE) Uptime : 00:03:43 Path Set ID : None Interface : Lspvif1 RPF-ID : 0x1 Шаг 4. Egress PE генерирует BGP маршрут шестого типа (присоединение к Shared Tree в сторону RP-PE). Данный маршрут импортируется только на RP-PE. PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 230.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][230.1.1.1/32]/22, version 130 Paths: (1 available, best #1, table MVPNv4-BGP-Table) Advertised to update-groups: 1 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 Extended Community: RT:1.1.1.1:1 rx pathid: 1, tx pathid: 0x0 Шаг 5. RP-PE транслирует полученный BGP маршрут шестого типа в PIM Join в сторону RP. На этот момент RP готово к отправке многоадресного трафика в сторону Egress PE. Необходимо доставить трафик от источника до RP. PE1#show ip mroute vrf C-ONE | b \(
(*, 230.1.1.1), 00:07:08/stopped, RP 15.15.15.15, flags: SG Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.15 Outgoing interface list: Lspvif0, Forward/Sparse, 00:07:08/stopped  Шаг 6. Когда S-PE (PE4) получает первый многоадресный пакет от источника (CE4), трафик инкапсулируется внутрь сообщения PIM Register и отправляется как одноадресный пакет в сторону C-RP (используя обычные правила MPLS L3 VPN). Шаг 7. После получения PIM Register, C-RP начинает процесс построения дерева С-(14.14.14.14, 230.1.1.1). RP-PE получает PIM Join для C-(14.14.14.14, 230.1.1.1) от C-RP. Данное сообщение транслируется в BGP маршрут седьмого типа. Однако, перед отправкой в сторону источника, необходимо построить новое дерево Partitioned MDT с РЕ в качестве ROOT.  Шаг 8. RP-PE производит RPF проверку чтобы найти BGP Next-Hop в сторону источника. Данный адрес будет использоваться как Partitioned MDT ROOT для mLDP. Шаг 9. Используя полученный BGP Next-Hop и BGP маршрут третьего типа от Ingress PE, RP-PR генерирует сообщение mLDP mapping в сторону IP адреса Ingress PE, тем самым строя корневое P2MP дерево до Ingress PE. Шаг 10. RP-PE отправляет BGP маршрут седьмого типа (Join от RP) в сторону Ingress PE. Шаг 11. Ingress PE преобразует полученный BGP маршрут седьмого типа в PIM Join и отправляет его в сторону источника трафика.  Присоединение к Source Tree и построение P2MP (ROOT = S-PE) Шаг 12. Ingress PE также отправляет BGP маршрут пятого типа ко всем mVPN PE, тем самым информируя их о наличии активного источника в сети. Данный маршрут является триггером для переключения к SPT дереву. Шаг 13. Egress PE использует полученный BGP маршрут пятого типа для генерации сообщения mLDP mapping в сторону Ingress PE (информация о MDT берётся из BGP маршрута третьего типа).  Таким образом теперь трафик может быть перенаправлен оптимальным путём от источника к получателю, используя mpls (mLDP) метки.  =========== Источник: habr.com =========== Похожие новости:
Сетевые технологии ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:03
Часовой пояс: UTC + 5