Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konfigurieren

Netzwerkdiagramm

Konfigurationen

Überprüfung

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/0

Sie 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.