Multicast-Dienstspiegelung mit PIM-SM auf IOS-XE: Multicast an Unicast
Inhalt
Einleitung
Dieser Artikel vermittelt Ihnen in Form eines Leitfadens für ein Konfigurationslabor ein Verständnis der grundlegenden Funktionsweise von MSR (Multicast Service Replication) unter Verwendung von IOS-XE-Plattformen.
Voraussetzungen
Anforderungen
Grundlegendes Verständnis von PIM-SM
Verwendete Komponenten
ASR1000 (R2&R4), ISR4300 (R3), ISR2900 (R1&R5)
Konfigurieren
Nachfolgend sind End-to-End-Konfigurationen dargestellt, die auf dem unten stehenden schematischen Szenario für die Multicast-Übersetzung basieren.
Netzwerkdiagramm
Konfigurationen
Im obigen Diagramm wirkt der Knoten R1 als Empfänger, der nur Unicast-Multicast-Datenfeeds von der Multicast-Quelle erhalten soll.
Der Knoten R5 fungiert als Multicast-Quelle, die Multicast-ICMP-Datenverkehr aus seiner Loopback-0-Schnittstelle generiert.
Der Knoten R2 befindet sich unter der Multicast-Core-Domäne des Content Providers und führt PIM-SM mit Underlay von OSPF aus.
Der Knoten R3 fungiert als der Router, der die Multicast Service Replication Application ausführt und in diesem Fall der Multicast Border Router ist, von dem aus der Multicast-Datenverkehr in ein Unicast-Datenpaket zum Empfänger umgewandelt werden soll. Er verwendet OSPF und EIGRP für den Content Provider bzw. ISP und beherbergt den RP (Rendezvouz Point) auf seiner Loopback-Schnittstelle in der Multicast-Core-Domäne.
Der Knoten R4 befindet sich unter der Kontrolle des ISP-Core und ist nicht für Multicast aktiviert. Er versteht nur, wie der Knoten R3 mithilfe des zugrunde liegenden EIGRP-Routings erreicht wird.
Nachfolgend finden Sie die relevanten Konfigurationen, die auf den im obigen Topologiediagramm vorhandenen Knoten vorhanden sind:
R1:
!
no ip domain lookup
ip cef
no ipv6 cef
!
interface GigabitEthernet0/2
ip address 10.10.20.1 255.255.255.0
duplex auto
speed auto
end
!
router eigrp 100
network 10.10.20.0 0.0.0.255
!R2:
!
interface GigabitEthernet0/0/0
ip address 10.10.20.2 255.255.255.0
negotiation auto
!
interface GigabitEthernet0/0/2
ip address 10.10.10.1 255.255.255.0
negotiation auto
!
router eigrp 100
network 10.10.10.0 0.0.0.255
network 10.10.20.0 0.0.0.255
!R3:
!
ip multicast-routing distributed
!
interface Loopback0
ip address 192.168.2.1 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!
interface GigabitEthernet0/0/0
ip address 192.168.30.1 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet0/0/1
ip address 10.10.10.2 255.255.255.0
negotiation auto
!
interface Vif1
ip address 192.169.169.1 255.255.255.0
ip pim sparse-mode
ip service reflect GigabitEthernet0/0/0 destination 224.1.1.0 to 10.10.20.0 mask-len 24 source 192.169.169.169 <<<<
ip igmp static-group 224.1.1.1
ip ospf 1 area 0
!
router eigrp 100
network 10.10.10.0 0.0.0.255
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!R4:
!
ip multicast-routing distributed
!
interface GigabitEthernet0/0/0
ip address 192.168.30.2 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet0/0/2
ip address 192.168.20.1 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
negotiation auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!R5:
!
ip multicast-routing
ip cef
no ipv6 cef
!
interface Loopback0
ip address 192.168.168.168 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!
interface GigabitEthernet0/2
ip address 192.168.20.2 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
duplex auto
speed auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!Überprüfung
Wir können die Konfigurationen validieren, indem wir einen Test-Ping zur Simulation des Multicast-Datenverkehrs vom R5-Router mit einer Quelle seiner Loopback-0-Schnittstelle [192.168.168.168] durchführen, die an die Multicast-Adresse 224.1.1.1 gerichtet ist. Überprüfen Sie dann die Routeneinträge auf dem Knoten, auf dem die MSR-Anwendung ausgeführt wird, d. h. R3 :
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
.............................R3#sh ip mroute 224.1.1.1
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
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:47:41/stopped, RP 192.168.2.1, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vif1, Forward/Sparse, 00:46:36/00:01:23 <<<<
(192.168.168.168, 224.1.1.1), 00:00:20/00:02:43, flags: T
Incoming interface: GigabitEthernet0/0/0, RPF nbr 192.168.30.2
Outgoing interface list:
Vif1, Forward/Sparse, 00:00:20/00:02:39 <<<<R3#sh ip mroute 224.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.
IP Multicast Statistics
3 routes using 2938 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.1.1.1, Source count: 1, Packets forwarded: 1455, Packets received: 1458 <<<<
RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
Source: 192.168.168.168/32, Forwarding: 1454/1/113/0, Other: 1457/3/0
R3#sh ip mroute 224.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.
IP Multicast Statistics
3 routes using 2938 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.1.1.1, Source count: 1, Packets forwarded: 1465, Packets received: 1468 <<<<
RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
Source: 192.168.168.168/32, Forwarding: 1464/1/113/0, Other: 1467/3/0Sie können auch Aufnahmen machen, um zu überprüfen, ob die Pakete tatsächlich in die beabsichtigte Unicast-Zieladresse auf dem R2-Knoten übersetzt werden. Hierzu verwenden Sie die EPC-Funktion (Embedded Packet Capture) auf dem IOS-XE-Router:
R2#mon cap TAC int gi 0/0/2 both match any
R2#mon cap TAC buff siz 50 circular
R2#mon cap TAC start
Started capture point : TAC
R2#
*Aug 12 06:50:40.195: %BUFCAP-6-ENABLE: Capture Point TAC enabled.
R2#sh mon cap TAC buff br | i ICMP
6 114 10.684022 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
7 114 10.684022 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
8 114 12.683015 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<
9 114 12.683015 192.169.169.169 -> 10.10.20.1 0 BE ICMP <<<<Der wichtige Punkt hierbei ist, dass Sie regelmäßig, wenn Sie Multicast-ICMP-Pings in "Laborumgebungen" durchführen, erwarten würden, dass Sie die ICMP-Echo-Antwortpakete von der Empfängerseite zur Quelle zurückerhalten, vorausgesetzt, es besteht vollständige Erreichbarkeit zwischen den beiden (Quelle und Empfänger). In diesem Szenario ist es jedoch wichtig zu beachten, dass selbst wenn wir versuchen, die NATted-Quelladresse für die Multicast-ICMP-Pakete, d. h. 192.169.169.169, bis zum Empfänger, d. h. R1 bis EIGRP, anzukündigen, die Unicast-ICMP-Echoantworten den R3-Router nicht durchlaufen, da die umgekehrte NAT nicht auf dem MSR-Anwendungsknoten konfiguriert. Dies kann getestet werden, indem die EIGRP-Routenankündigung der Vif 1-Schnittstelle auf R3 in EIGRP (ISP-Core-Routing) ausgeführt wird:
ISR4351(config)#router eigrp 100
ISR4351(config-router)#network 192.169.169.0 0.0.0.255 <<<<Jetzt können wir die Aufnahmen des R2-Knotens in den ICMP-Echo-Antworten einchecken, die an R3 gesendet werden:
R2#sh mon cap TAC buff br | i ICMP
249 114 317.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
250 114 317.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
251 114 317.847948 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
252 114 317.847948 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
253 114 319.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
254 114 319.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP
255 114 319.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
256 114 319.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
259 114 321.848955 192.169.169.169 -> 10.10.20.1 0 BE ICMP
260 114 321.848955 192.169.169.169 -> 10.10.20.1 0 BE ICMP
261 114 321.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<<
262 114 321.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<< Aber die Pings würden immer noch versagen, wie an der Quelle R5 zu sehen:
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................
......................................................................
Um nun die Antworten bis zur Quelle zu erhalten, können wir die NAT-Port-Weiterleitung auf dem MSR-Anwendungsknoten R3 so konfigurieren, dass der Zieldatenverkehr in Richtung 192.169.169.169 bis 192.168.168.168 übersetzt wird. Dazu konfigurieren wir erweiterbares NAT:
R3(config)#int gi 0/0/1
R3(config-if)#ip nat out
R3(config-if)#int gi 0/0/0
R3(config-if)#ip nat ins
R3(config-if)#exit
R3(config)#ip nat inside source static 192.168.168.168 192.169.169.169 extendable <<<<Wenn wir nun den Quell-R5-Knoten überprüfen, sehen wir, wie die Antwort zurückkommt:
R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................
Reply to request 716 from 10.10.20.1, 1 ms
Reply to request 716 from 10.10.20.1, 1 ms
Reply to request 717 from 10.10.20.1, 1 ms
Reply to request 717 from 10.10.20.1, 1 ms
Reply to request 718 from 10.10.20.1, 1 ms
Reply to request 718 from 10.10.20.1, 1 ms Der oben beschriebene Vorgang wurde lediglich durchgeführt, um den Paketfluss zu erläutern und zu verstehen, wie der umgekehrte Unicast-Pfad bzw. -Fluss für den Datenverkehr und den Downstream-Multicast-Verkehr eingerichtet wird. Da in den normalen Produktionsszenarien normalerweise keine Fälle/Instanzen auftreten, in denen die Multicast-Anwendungen, die auf der Server-/Quellseite ausgeführt werden, eine Rückwärtsbestätigung der Pakete von den Empfängern in Unicast-Form erfordern.
Durch die oben genannten Tests und Validierungen hätte ein kurzer Überblick darüber gegeben werden müssen, wie eine Multicast-Dienstreplikationsanwendung auf einem der Multicast Border Nodes ausgeführt wird und wie diese bereitgestellt werden können, wenn die oben gezeigten Anwendungen auf eine umfangreiche Bereitstellung erweitert werden.
Feedback