Сигнализация PIM
Введение
У крупных корпоративных клиентов периодически появляется желание передавать групповой трафик (multicast) не только внутри своих сетей в крупных офисах и дата-центрах, но также и между ними. Операторам связи приходится решать поставленные перед ними задачи по обеспечению доставки таких пакетов между точками присутствия клиентов.
Среди наиболее распространённых способов передачи группового трафика в MPLS-сетях можно отметить несколько: Rosen и mLDP, RSVP и head-end replication, например, в EVPN; в данной статье мы сосредоточимся на одном из них – Rosen (по фамилии одного из авторов RFC).
При передаче multicast-трафика в Rosen режиме между двумя PE маршрутизаторами (Provider Edge) устанавливается специальный GRE-туннель, по которому и передаются групповые пакеты. Стоит отметить, что underlay сеть может быть как с настоящей поддержкой multicast, так и с его эмуляцией (например, в сетях DMVPN, то есть при использовании 2547oDMVPN).
Сигнализация при этом может быть на основе различных протоколов: PIM, mLDP, BGP. Разберёмся, что происходит в сети, когда для сигнализации используется протокол PIM SM (Profile 0 Default MDT - GRE - PIM C-mcast Signaling).
Топология
Чтобы упростить себе задачу, рассмотрим underlay сеть безо всяких дополнительных туннельных протоколов, например, DMVPN.
В MPLS-сеть провайдера входят следующие устройства: PE1, P1, P2 и PE2. Назначение маршрутизатора понятно из его названия. В качестве платформы для эмуляции операторского оборудования был выбран виртуальный маршрутизатор Cisco CSR1000v, на который установлена последняя версия программного обеспечения (IOS-XE линейки 17.3). Клиентское оборудование представлено маршрутизаторами Cisco серии 7200 (IOS версии 15.2). Единственное, что стоит упомянуть отдельно – устройства Sender и Receiver. В данной статье в качестве отправителя и получателя группового трафика мы использовали маршрутизаторы, естественно, что в реальной сети для этих целей будут применяться настоящие рабочие станции, серверы, медиа-плееры.
Underlay
Под underlay сетью в данном случае мы будем понимать инфраструктуру провайдера. В сети оператора мы использовали следующие протоколы: OSPF и LDP.
PE1#sho run | s r o
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
mpls ldp autoconfig
PE1#sho mpls ldp neighbor
Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 3.3.3.3:0
TCP connection: 1.1.1.1.646 - 3.3.3.3.35398
State: Oper; Msgs sent/rcvd: 70/72; Downstream
Up time: 00:53:14
LDP discovery sources:
GigabitEthernet2, Src IP addr: 172.16.0.2
Addresses bound to peer LDP Ident:
172.16.1.1 172.16.0.2 1.1.1.1
PE1#sho mpl fo
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 1.1.1.1/32 0 Gi2 172.16.0.2
17 16 2.2.2.2/32 0 Gi2 172.16.0.2
18 Pop Label 172.16.1.0/24 0 Gi2 172.16.0.2
19 17 172.16.2.0/24 0 Gi2 172.16.0.2
20 19 4.4.4.4/32 0 Gi2 172.16.0.2
Также в underlay сети присутствует поддержка multicast-трафика. Для сигнализации используется PIM sparse-mode. На ряде линеек устройств компании Cisco маршрутизация multicast-трафика по умолчанию отключена, поэтому кроме включения протокола PIM на всех нужных интерфейсах необходимо также включить маршрутизацию multicast-пакетов. В качестве Rendezvous Point (RP) был выбран маршрутизатор PE1, информация о котором по сети распространяется с помощью стандартного протокола автоматического выбора RP - BootStrap Router (BSR).
PE1(config)#ip multicast-routing distributed
PE1(config)#^Z
PE1#sho ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
3.3.3.3 Loopback0 v2/S 0 30 1 3.3.3.3
172.16.0.1 GigabitEthernet2 v2/S 1 30 1 172.16.0.2
PE1#sho run | i candi
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0
Убедимся, что на маршрутизаторе PE2 присутствует вся необходимая информация для работы с multicast в сети провайдера: обнаружены PIM-соседи, получена информация об адресе RP.
PE2#sho ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
172.16.2.1 GigabitEthernet2 00:06:04/00:01:36 v2 1 / S P G
PE2#sho ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 3.3.3.3 (?), v2
Info source: 3.3.3.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:45:18, expires: 00:01:36
Мы решили снять дамп на линке P1-P2 и найти в нём сообщение, с помощью которого маршрутизатор PE1 анонсирует себя в качестве кандидата на роли BSR и RP.
Unicast overlay
Для обработки пользовательского трафика был создан VRF A. За передачу маршрутной информации между PE1 и PE2 отвечает протокол MP-BGP. Обмен маршрутами с пользовательскими маршрутизаторами CE1 и CE2 производится с помощью протокола OSPF.
PE1#sho run | s r b
router bgp 1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 4.4.4.4 remote-as 1
neighbor 4.4.4.4 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 send-community extended
exit-address-family
!
address-family ipv4 vrf A
redistribute ospf 2 match internal external 2
exit-address-family
PE1#sho run | s r ospf 2
router ospf 2 vrf A
capability vrf-lite
redistribute bgp 1
network 0.0.0.0 255.255.255.255 area 0
Распространение сервисных MPLS-меток производится с помощью протокола MP-BGP (address-family vpnv4).
PE1#sho bgp vpnv4 unicast vrf A labels
Network Next Hop In label/Out label
Route Distinguisher: 1:1 (A)
5.5.5.5/32 192.168.0.2 22/nolabel
6.6.6.6/32 4.4.4.4 nolabel/22
10.0.0.0/24 192.168.0.2 23/nolabel
10.0.1.0/24 4.4.4.4 nolabel/23
192.168.0.0 0.0.0.0 21/nolabel(A)
192.168.1.0 4.4.4.4 nolabel/21
Несложно убедиться в том, что пользовательские маршрутизаторы обладают всеми необходимыми префиксами.
CE1#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
5.0.0.0/32 is subnetted, 1 subnets
C 5.5.5.5 is directly connected, Loopback0
6.0.0.0/32 is subnetted, 1 subnets
O E2 6.6.6.6 [110/1] via 192.168.0.1, 00:43:33, GigabitEthernet0/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.0.0.0/24 is directly connected, GigabitEthernet1/0
L 10.0.0.1/32 is directly connected, GigabitEthernet1/0
O E2 10.0.1.0/24 [110/1] via 192.168.0.1, 00:43:33, GigabitEthernet0/0
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, GigabitEthernet0/0
L 192.168.0.2/32 is directly connected, GigabitEthernet0/0
O E2 192.168.1.0/24 [110/1] via 192.168.0.1, 00:43:33, GigabitEthernet0/0
Так как устройства Sender и Receiver имитируют хосты, то никакой динамической маршрутизации на них не используется.
Receiver#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 10.0.1.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.0.1.1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.1.0/24 is directly connected, GigabitEthernet1/0
L 10.0.1.2/32 is directly connected, GigabitEthernet1/0
Узлы Sender и Receiver успешно обмениваются данными.
Receiver#ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/32/44 ms
Мы перехватили одно из указанных ICMP-сообщений на линке P1-P2.
Обратите внимание на наличие обеих MPLS-меток у пакета: сервисной и транспортной.
Multicast overlay
Функции Rendezvous Point для VRF A мы решили возложить на клиентское оборудование, то есть маршрутизатор CE1 будет объявлять себя как C-RP и C-BSR.
CE1#sho run | i candi
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0
CE1#sho ip pim rp map
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
This system is the Bootstrap Router (v2)
Group(s) 224.0.0.0/4
RP 5.5.5.5 (?), v2
Info source: 5.5.5.5 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:55:21, expires: 00:02:06
В сети провайдера нужно обязательно включить поддержку multicast-маршрутизации не только глобально, но ещё и для VRF A.
PE1(config)#ip multicast-routing vrf A distributed
Но и это ещё не всё. Каждый vrf должен быть настроен на использование уникальных multicast-групп для передачи пользовательского трафика с помощью команд mdt default и mdt data. Последняя команда опциональна.
PE1#sho run vrf | s def
vrf definition a
rd 1:1
route-target export 1:1
route-target import 1:1
!
address-family ipv4
mdt default 239.1.1.1
mdt data 239.1.2.0 0.0.0.255 threshold 1
mdt data threshold 1
exit-address-family
По умолчанию весь трафик передаётся с помощью группы, указанной в команде mdt default, однако если скорость передачи трафика превышает некоторый предел, заданный с помощью опции threshold, то данный поток пользовательского трафика переводится в одну из data-групп.
После того, как мы осуществили привязку default-группы к VRF, все PE-маршрутизаторы автоматически подписываются на эту группу и пытаются обнаружить PIM-соседей в overlay-сети.
Это очень интересный и показательный пакет, который мы перехватили в сети провайдера. Он отправляется маршрутизатором PE2 в сторону устройства, выполняющего функции RP в underlay-сети. Это unicast-пакет, поэтому к нему стандартным образом добавляется транспортная MPLS-метка. Внутри этого IPv4-пакета расположено сообщение Register протокола PIM. То есть маршрутизатор PE2 пытается переслать некоторый multicast-пакет в сторону RP пока ещё нет никакой подписки со стороны RP. Всё как и в случае обычной групповой рассылки. Но что это за IP-пакет, который PE2 хочет доставить до PE1? А это ни много ни мало рассылка для группы 239.1.1.1, которая у нас была объявлена как mdt default для VRF A. Производим декапсуляцию дальше: GRE заголовок и потом снова IPv4. Это уже попытка роутера PE2 внутри VRF A обнаружить PIM-соседей (судя по адресу получателя 224.0.0.13) при помощи сообщения PIM Hello.
В результате мы видим, что все PIM-маршрутизаторы внутри VRF A обнаружены, и соседство с ними установлено.
PE2#sho ip pim vrf a neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
3.3.3.3 Tunnel1 00:06:31/00:01:38 v2 1 / S P G
192.168.1.2 GigabitEthernet1 00:03:28/00:01:43 v2 1 / DR S P G
На какие же группы и каких отправителей теперь подписан маршрутизатор PE2? То есть маршрутизатор PE2 заинтересован в получении трафика группы 239.1.1.1, настроенной как mdt default.
PE2#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group, c - PFP-SA cache created entry,
* - determined by Assert, # - iif-starg configured on rpf intf,
e - encap-helper tunnel flag
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 01:09:41/stopped, RP 3.3.3.3, flags: SJCFZ
Incoming interface: GigabitEthernet2, RPF nbr 172.16.2.1
Outgoing interface list:
MVRF a, Forward/Sparse, 01:09:41/00:02:18
(3.3.3.3, 239.1.1.1), 01:09:41/00:01:13, flags: JTZ
Incoming interface: GigabitEthernet2, RPF nbr 172.16.2.1
Outgoing interface list:
MVRF a, Forward/Sparse, 01:09:41/00:02:18
(4.4.4.4, 239.1.1.1), 01:09:41/00:03:13, flags: FT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2, Forward/Sparse, 01:09:41/00:02:38
(*, 224.0.1.40), 01:26:41/00:02:22, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 01:26:39/00:02:22
На данный момент сеть готова к передаче пользовательского multicast-трафика.
С помощью протокола IGMP подпишемся на группу 239.7.7.7 с устройства Receiver.
Receiver#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Receiver(config)#int gi1/0
Receiver(config-if)#ip igmp jo 239.7.7.7
На изображении ниже видно соответствующее сообщение протокола IGMP (Membership Report), которое отправлено с маршрутизатора Receiver. Конечные узлы ничего не знают о том, как реализована поддержка multicast в сети оператора, и используют стандартные IGMP сообщения Membership Report.
Убедимся в успешности подписки конечного узла на маршрутизаторе CE2.
CE2#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.7.7.7 GigabitEthernet1/0 00:03:49 00:02:37 10.0.1.2
224.0.1.40 GigabitEthernet0/0 01:43:29 00:02:55 192.168.1.1
224.0.1.40 Loopback0 01:43:36 00:02:27 6.6.6.6
Убедимся, что все пользовательские подписки были продублированы маршрутизатором CE2 в сторону оборудования провайдера по протоколу PIM.
PE2#sho ip mroute vrf a
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group, c - PFP-SA cache created entry,
* - determined by Assert, # - iif-starg configured on rpf intf,
e - encap-helper tunnel flag
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.7.7.7), 00:05:12/00:03:12, RP 5.5.5.5, flags: S
Incoming interface: Tunnel1, RPF nbr 3.3.3.3
Outgoing interface list:
GigabitEthernet1, Forward/Sparse, 00:05:12/00:03:12
(*, 224.0.1.40), 01:45:32/00:02:31, RP 0.0.0.0, flags: DPL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
Несмотря на то, что канал CE2-PE2 – линк в сторону провайдера, никакие операторские технологии здесь не используются, только стандартный PIM.
Убедимся, что маршрутизатор CE1, выполняющий функции Rendezvous Point для клиентской сети, также получил информацию о группах, на которые выполнена подписка.
CE1#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.7.7.7), 00:10:46/00:02:32, RP 5.5.5.5, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0, Forward/Sparse, 00:02:21/00:02:32
(*, 224.0.1.40), 01:50:51/00:02:48, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0, Forward/Sparse, 01:50:49/00:02:48
Вновь заглянем в дамп на канале между P1 и P2, где найдём сообщение, с помощью которого и производится подписка.
Итак, перед нами стандартное PIM-сообщение Join/Prune, отправляемое маршрутизатором PE2 в IP-пакете с адресом отправителя 4.4.4.4 и групповым адресом получателя 224.0.0.13. Однако это сообщение в overlay-сети, поэтому оно инкапсулируется внутрь GRE, после чего инкапсулируется внутрь пакета IPv4, передаваемого по underlay сети. Адрес получателя во внешнем IP-пакете равен 239.1.1.1, что соответствует группе mdt default для VRF A. Именно по этому адресу получателя опорная сеть отличает групповые потоки разных VRF.
Внутри самого PIM-сообщения мы также видим два IP-адреса: 3.3.3.3 и 5.5.5.5. Адрес 3.3.3.3 идентифицирует маршрутизатор PE1 – PIM-соседа для PE2. Адрес 5.5.5.5 указывает на «конечную точку», то есть адрес RP. Подписка на группы по протоколу PIM происходит последовательно по направлению от получателя в сторону Rendezvous Point (при отсутствии узла, отправляющего трафик для этой группы): CE2 подписывается на PE2, PE2 подписывается на PE1, PE1 – на CE1. Это означает, например, что на линке CE2-PE2 в качестве Upstream-neighbor будет указан адрес 4.4.4.4, при этом адрес RP (5.5.5.5) меняться не будет.
Data plane
Единственное, что осталось сделать, - убедиться в успешности передачи группового трафика между Sender и Receiver.
Sender#ping 239.7.7.7 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.7.7.7, timeout is 2 seconds:
Reply to request 0 from 10.0.1.2, 164 ms
Reply to request 1 from 10.0.1.2, 52 ms
Reply to request 2 from 10.0.1.2, 44 ms
Reply to request 3 from 10.0.1.2, 56 ms
Reply to request 4 from 10.0.1.2, 48 ms
Внутри сети оператора ICMP сообщения Echo Request, отправляемые на групповой адрес, выглядят так, как представлены ниже.
Сообщения ICMP Echo Reply отправляются в виде unicast, поэтому для этих пакетов применяются все стандартные правила передачи данных внутри VRF.
Если скорость потока multicast превышает заданную величину, то на underlay сети происходит переключение с группы mdt default на одну из групп mdt data. В этот момент по underlay-сети передаётся сообщение PIM Join –подписка на mdt data группу от устройства PE2 в сторону PE1.
Заключение
Групповое вещание может успешно передаваться по сети MPLS-оператора внутри VRF. Сигнализация может выполняться при помощи разных протоколов: в данном материале мы ограничились рассмотрением сигнализации PIM, однако в ближайшее время мы планируем описать сигнализацию с помощью протокола BGP.
Решение на базе Rosen GRE является весьма популярным, не в последнюю очередь благодаря практически повсеместной поддержке со стороны сетевого оборудования.
Конфигурация всех маршрутизаторов приведена в архиве.
