Fehlerbehebung: IP Multicast-Leitfaden

Geben Sie einige weitere Debug-Befehle ein:

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface

Die Pakete werden auf E3/1 empfangen, was richtig ist. Sie werden jedoch verworfen, da dies nicht die Schnittstelle ist, die die Unicast-Routing-Tabelle für die RPF-Prüfung verwendet.

Hinweis: Das Debuggen von Paketen ist gefährlich. Das Paket-Debugging löst ein CPU-intensives Prozess-Switching der Multicast-Pakete aus. Außerdem kann das Paket-Debugging zu einer riesigen Ausgabe führen, bei der der Router aufgrund der langsamen Ausgabe an den Konsolen-Port vollständig hängen bleibt. Bevor Sie Pakete debuggen, müssen Sie besonders vorsichtig sein, um die Protokollausgabe an der Konsole zu deaktivieren und die Protokollierung im Speicherpuffer zu aktivieren. Um dies zu erreichen, konfigurieren Sie keine Protokollierungskonsole und Protokollieren gepuffertes Debuggen. Die Ergebnisse der Fehlersuche können mit dem Befehl show logging angezeigt werden.

Mögliche Fehlerbehebung

Sie können entweder die Unicast-Routing-Tabelle ändern, um diese Anforderung zu erfüllen, oder Sie können eine statische Route hinzufügen, um Multicast aus einer bestimmten Schnittstelle in die RPF zu zwingen, unabhängig davon, welchen Status die Unicast-Routing-Tabelle hat. Statische Route hinzufügen:

ip22-72a(config)#ip mroute 10.1.1.1 255.255.255.255 10.2.1.1

Diese statische Route gibt an, dass Sie zum Abrufen der Adresse 10.1.1.1 für RPF 10.2.1.1 als nächsten Hop verwenden, der über die Schnittstelle E3/1 hinausgeht.

ip22-72a#show ip rpf 10.1.1.1 
RPF information for ? (10.1.1.1) 
  RPF interface: Ethernet3/1 
  RPF neighbor: ? (10.2.1.1) 
  RPF route/mask: 10.1.1.1/32 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

Die Ausgabe von show ip mroute und debug ip mpacket sieht gut aus, die Anzahl der gesendeten Pakete in steigt, und HostA empfängt Pakete in demshow ip mroute count Netzwerk.

ip22-72a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 (10.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA Incoming interface: Ethernet3/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 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: 1019, Packets received: 1019 Source: 10.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 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: 1026, Packets received: 1026 Source: 10.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0 ip22-72a# ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward

Router leitet Multicast-Pakete aufgrund der TTL-Einstellung der Quelle nicht an Host weiter

Dieser Abschnitt bietet eine Lösung für das häufige Problem von IP-Multicast-Paketen, die nicht weitergeleitet werden, da der TTL-Wert (Time To Live) auf Null herabgesetzt wird. Dies ist ein häufiges Problem, da es viele Multicast-Anwendungen gibt. Diese Multicast-Anwendungen sind primär für die LAN-Nutzung konzipiert und stellen somit die TTL auf einen niedrigen Wert oder sogar 1 ein. Verwenden Sie dieses Netzwerkdiagramm als Beispiel. 

Multicast-Anwendungen, die primär für das Beispiel zur LAN-Nutzung konzipiert wurden

Diagnose des Problems

In der vorherigen Abbildung leitet Router A keine Pakete von der Quelle(n) an Router B weiter, der direkt mit dem Receiver verbunden ist. Schauen Sie sich die Ausgabe des Befehls auf   show ip mroute  Router A an, um den Multicast-Routing-Status anzuzeigen:

ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00 (*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00 

Sie können 224.0.1.40 in der Ausgabe ignorieren, da alle Router dieser Auto-RP Discovery-Gruppe beitreten. Es ist jedoch keine Quelle für 224.1.1.1 aufgelistet. Neben "*, 224.1.1.1" wird "10.1.1.1, 224.1.1.1" nicht angezeigt.

Geben Sie den Befehl show ip rpf ein, um festzustellen, ob es sich um ein RPF-Problem handelt:

ROUTERA#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 10.1.1.1/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables 

Bei der Ausgabe handelt es sich nicht um ein RPF-Problem. Die RPF-Prüfung weist auf E0/0 hin, um die Quell-IP-Adresse zu erhalten.

Überprüfen Sie mit dem folgenden Befehl, ob PIM auf den Schnittstellen konfiguriertshow ip pim interface ist:

ROUTERA#show ip pim interface Address Interface Version/Mode Nbr Query DR Count Intvl 10.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 10.1.1.2 10.2.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 10.2.1.2 

Die Ausgabe sieht gut aus, das ist also nicht das Problem. Überprüfen Sie mit dem folgenden Befehl, ob der Router aktiven Datenverkehr erkenntshow ip mroute active:

ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps 

Auf Basis der Ausgabe erkennt der Router keinen aktiven Datenverkehr.

ROUTERA#debug ip mpacket IP multicast packets debugging is on 

Möglicherweise sendet der Receiver keine IGMP-Berichte (Internet Group Management Protocol) (Joins) für die Gruppe 224.1.1.1. Sie können dies mit dem folgenden show ip igmp group  Befehl überprüfen:

ROUTERB#show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet1/1 00:34:34 never 10.2.1.2 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2 

224.1.1.1 wurde an E1/2 angeschlossen, was in Ordnung ist.

Der PIM Dense Mode ist ein Flood-and-Prune-Protokoll, es gibt also keine Joins, aber es gibt Transplantate. Da Router B keine Flut von Router A erhalten hat, weiß er nicht, wohin er ein Transplantat senden soll.

Sie können überprüfen, ob es sich um ein TTL-Problem mit der Sniffer-Erfassung und auch mit dem show ip traffic  Befehl gesehen:

ROUTERA#show ip traffic IP statistics: Rcvd: 248756 total, 1185 local destination 0 format errors, 0 checksum errors, 63744 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 0 with options 

Die Ausgabe zeigt 63744 fehlerhafte Hop-Zählungen an. Bei jeder Eingabe dieses Befehls erhöht sich die Anzahl fehlerhafter Hops. Dies ist ein starkes Indiz dafür, dass der Sender Pakete mit einem TTL=1 sendet, wobei Router A auf Null abfällt. Dies führt zu einer Erhöhung des Felds für die Anzahl fehlerhafter Hops.

Mögliche Fehlerbehebung

Um das Problem zu lösen, müssen Sie die TTL erhöhen. Dies erfolgt auf Anwendungsebene des Absenders. Weitere Informationen finden Sie in der Bedienungsanleitung Ihrer Multicast-Anwendung.

Danach sieht Router A wie folgt aus:

ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00 (*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00 (10.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00 

Das ist die Art von Ausgabe, die Sie sehen wollen.

Router B:

ROUTERB#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00 (*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00 (10.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1 Outgoing interface list: Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00

Router leitet Multicast-Pakete aufgrund des TTL-Schwellenwerts des Routers nicht weiter

Dieser Abschnitt bietet eine Lösung für das häufige Problem, dass der TTL-Grenzwert zu niedrig angesetzt ist, sodass der IP-Multicast-Verkehr den Empfänger nicht erreicht. Dieses Netzwerkdiagramm wird als Beispiel verwendet.

Der TTL-Grenzwert ist zu niedrig, damit der IP-Multicast-Datenverkehr den Empfänger nicht erreicht.

Diagnose des Problems

In der vorherigen Abbildung empfängt der Empfänger keine Multicast-Pakete von der Quelle. Zwischen der Quelle und dem Router 75a können mehrere Router vorhanden sein. Sehen Sie sich zunächst den Router 75a an, da dieser direkt mit dem Receiver verbunden ist.

ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00 (10.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00 

Die Ausgabe zeigt, dass der Router 75a Pakete über Ethernet0/1 weiterleitet. Um sicher zu gehen, dass Router 75a die Pakete weiterleitet, aktivieren Sie diese Option debug nur für diese Quell- und Multicast-Gruppe:

ip22-75a#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 10.1.1.1 host 224.1.1.1 ip22-75a(config)#end ip22-75a#debug ip mpacket 101 IP multicast packets debugging is on for access list 101 ip22-75a# *Jan 17 09:04:08.714: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

Die debug Meldungen weisen darauf hin, dass der Router 75a die Multicast-Pakete nicht weiterleitet, da der TTL-Grenzwert erreicht wurde. Sehen Sie sich die Router-Konfiguration an, um herauszufinden, ob Sie den Grund dafür finden. Diese Ausgabe zeigt den Schuldigen:

interface Ethernet0/1 ip address 10.2.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15 

Der TTL-Schwellenwert des Routers ist 15. Dies bedeutet jedoch nicht, dass ein Wert größer als ein TTL-Wert von 15 nicht gesendet wird. Tatsächlich ist das Gegenteil der Fall. Die Anwendung wird mit einem TTL von 15 gesendet. Bis Router 75a erreicht ist, haben die Multicast-Pakete eine TTL von weniger als 15.

Der ip multicast ttl-threshold <value> Befehl bedeutet, dass Pakete, deren TTL unter dem festgelegten Schwellenwert, in diesem Fall 15, liegt, nicht weitergeleitet werden. Dieser Befehl wird normalerweise verwendet, um eine Grenze bereitzustellen, damit interner Multicast-Datenverkehr nicht aus dem Intranet fließt.

Mögliche Fehlerbehebung

Entfernen Sie entweder den ip multicast ttl-threshold <value> Befehl ohne Form dieses Befehls, der auf den TTL-Standardschwellenwert 0 zurückgesetzt wird, oder senken Sie den TTL-Schwellenwert ab, sodass der Datenverkehr weitergeleitet werden kann.

Mehrere Pfade zu gleichen Kosten führen zu unerwünschtem RPF-Verhalten

In diesem Abschnitt wird gezeigt, wie preisgleiche Pfade zu einer Multicast-Quelle unerwünschtes RPF-Verhalten verursachen können. Außerdem wird beschrieben, wie IP-Multicast konfiguriert wird, um dieses Verhalten zu vermeiden. Dieses Netzwerkdiagramm wird als Beispiel verwendet.

Gleiche Kostenpfade zu einer Multicast-Quelle verursachen unerwünschtes RPF-Verhalten.

Diagnose des Problems

In der Abbildung hat Router 75b drei Pfade zu gleichen Kosten zurück zur Quelle (10.1.1.1), und er wählt eine Verbindung aus, die nicht seine erste Wahl als RPF-Verbindung sein soll.

Wenn mehrere Pfade zu gleichen Kosten zu einer Quelle vorhanden sind, wählt IP-Multicast die Schnittstelle aus, die einen Protocol Independent Multicast (PIM)-Nachbarn mit der höchsten IP-Adresse als eingehende Schnittstelle hat, und sendet dann Prunes an PIM-Nachbarn auf den anderen Verbindungen.

Mögliche Fehlerbehebung

Um die Schnittstelle, die IP-Multicast als eingehende Schnittstelle auswählt, zu ändern, können Sie einen der folgenden Schritte ausführen:

• Konfigurieren Sie PIM nur auf den Schnittstellen, die von Multicast durchlaufen werden sollen, d. h. Sie verlieren die Multicast-Redundanz.

• Ändern Sie die Subnetze so, dass die höchste IP-Adresse auf der Verbindung ist, die Sie als primäre Multicast-Verbindung verwenden möchten.

• Erstellen Sie eine statische Multicast-Route (mroute), die auf die bevorzugte Multicast-Schnittstelle hinweist, was bedeutet, dass Sie die Multicast-Redundanz verlieren.

Als Beispiel wird eine statische Route erstellt.

Bevor Sie eine statische Route installieren, sehen Sie in dieser Ausgabe, dass die Routing-Tabelle drei Routen gleicher Kosten für die Quelladresse 10.1.1.1 enthält. Aus den RPF-Informationen geht hervor, dass es sich bei der RPF-Schnittstelle um E1/3 handelt:

ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/3 RPF neighbor: ? (10.4.1.1) RPF route/mask: 10.1.1.1/24 RPF type: unicast (ospf 1) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00 (10.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT Incoming interface: Ethernet1/3, RPF nbr 10.4.1.1 Outgoing interface list: Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32 Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42 

Nachdem Sie die statische Route konfiguriert haben, sehen Sie in dieser Ausgabe, dass die RPF-Schnittstelle zu E1/1 geändert wurde:

ip22-75b#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 10.2.1.1 ip22-75b(config)#end ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/1 RPF neighbor: ? (10.2.1.1) RPF route/mask: 10.1.1.1/0 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00 (10.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47 Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28

Warum findet IP-Multicast keinen Lastenausgleich über alle verfügbaren Equal Cost-Pfade hinweg?

Dieser Abschnitt bietet eine Lösung für das häufige Problem der Konfiguration von IP-Multicast, um einen Lastausgleich über alle verfügbaren Pfade zu gleichen Kosten zu erreichen. Dieses Netzwerkdiagramm wird als Beispiel verwendet.

Hinweis: Bevor Sie IP-Multicast-Datenverkehr über Tunnel auf kostengünstigere Pfade aufteilen, müssen Sie den CEF-Lastenausgleich für einzelne Pakete konfigurieren. Andernfalls kann der Lastenausgleich für die GRE-Pakete nicht pro Paket erfolgen. Weitere Methoden zur Lastverteilung in Multicast-Umgebungen finden Sie unter Lastverteilung von IP-Multicast-Datenverkehr über ECMP.

Konfigurieren von IP-Multicast zum Lastenausgleich über alle verfügbaren kostengleichen Pfade hinweg

In der Abbildung verfügt Router 75b über drei Pfade mit gleichen Kosten zurück zur Quelle (10.1.1.1). Sie möchten den Lastenausgleich für den Multicast-Verkehr über alle drei Verbindungen durchführen.

Mögliche Fehlerbehebung

Wie Sie im Abschnitt Multiple Equal Cost Paths Result in Unwanted RPF Behaviour (Unerwünschtes RPF-Verhalten) gesehen haben, wählt Protocol Independent Multicast (PIM) nur eine Schnittstelle für die RPF-Prüfung aus und entfernt die anderen. Dies bedeutet, dass kein Lastenausgleich stattfindet. Um die Last auszugleichen, müssen Sie PIM aus den redundanten Verbindungen entfernen und einen Tunnel zwischen Router 75a und Router 75b erstellen. Anschließend kann die Last auf Verbindungsebene ausgeglichen werden, und die IP-Adresse läuft über den Tunnel.

Dies sind die Konfigurationen für den Tunnel.

interface Tunnel0 
 ip address 10.6.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet0/0 
 tunnel destination 10.5.1.1 
! 
interface Ethernet0/0 
 ip address 10.1.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
! 
interface Ethernet0/1 
 ip address 10.2.1.1 255.255.255.0 
! 
interface Ethernet0/2 
 ip address 10.3.1.1 255.255.255.0 
! 
interface Ethernet0/3 
 ip address 10.4.1.1 255.255.255.0

interface Tunnel0 
 ip address 10.6.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet1/4 
 tunnel destination 10.1.1.2 
! 
interface Ethernet1/1 
 ip address 10.2.1.2 255.255.255.0 
! 
interface Ethernet1/2 
 ip address 10.3.1.2 255.255.255.0 
! 
interface Ethernet1/3 
 ip address 10.4.1.2 255.255.255.0 
! 
interface Ethernet1/4 
 ip address 10.5.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
! 
ip mroute 0.0.0.0 0.0.0.0 Tunnel0

Geben Sie nach der Konfiguration des Tunnels den show ip mroute Befehl ein, um die Multicast-Route (mroute) für die Gruppe anzuzeigen:

ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 (10.1.1.1, 224.1.1.1), 02:40:32/00:03:29, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00 Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00 (10.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT Incoming interface: Tunnel0, RPF nbr 10.6.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00 

Um sicherzustellen, dass die Multicast-Daten gleichmäßig auf die drei Verbindungen verteilt sind, sehen Sie sich die Schnittstellendaten des Routers 75a an.

Die eingehende Schnittstelle beträgt 9.000 Bit/s:

ip22-75a#show interface e0/0 . . 5 minute input rate 9000 bits/sec, 20 packets/sec 

Die drei ausgehenden Schnittstellen zeigen jeweils 3000 Bit/s:

ip22-75a#show interface e0/1 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/2 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/3 . . 5 minute output rate 3000 bits/sec, 7 packets/sec

Wenn Sie die IP-Multicast-Fehlermeldungen "INVALID_RP_JOIN" auf dem Router erhalten

Dieser Abschnitt enthält Lösungen für das häufige Problem der IP-Multicast-Fehlermeldung "INVALID_RP_JOIN".

Diagnose des Problems - Teil 1

Diese Fehlermeldung wird am Rendezvous Point (RP) empfangen:

00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 

Im Dokument "Cisco IOS Software System Error Messages" (Systemfehlermeldungen der Cisco IOS-Software) wird erläutert, was diesen Fehler verursacht: Ein Downstream-PIM-Router hat eine Join-Nachricht für den Shared Tree gesendet, die dieser Router nicht akzeptieren möchte. Dieses Verhalten zeigt an, dass dieser Router nur Downstream-Router zulässt, die einem bestimmten RP beitreten.

Es wird vermutet, dass es filtert. Sehen Sie sich hierzu die Konfiguration des Routers an:

interface Ethernet0/0 ip address 10.1.5.4 255.255.255.0 ip pim sparse-dense-mode ! ip pim accept-rp 10.2.2.2 8 ip pim send-rp-announce Ethernet0/0 scope 15 ip pim send-rp-discovery scope 15 ! access-list 8 permit 224.0.0.0 0.255.255.255 

Welche accept-rp  Aussage soll durch die Konfiguration erreicht werden? In IP Multicast Routing Commands heißt es: "Um einen Router so zu konfigurieren, dass er Joins oder Prunes akzeptiert, die für einen bestimmten RP und für eine bestimmte Gruppenliste bestimmt sind, verwenden Sie den ip pim accept-rp globalen Konfigurationsbefehl. Um diese Prüfung zu entfernen, verwenden Sie die Form no dieses Befehls."

Wenn Sie den ip pim accept-rp Befehl entfernen, verschwinden die Meldungen. Der Befehl, der das Problem verursacht, wurde gefunden, aber was ist, wenn Sie diesen Befehl in der Konfiguration beibehalten möchten? Sie können die falsche RP-Adresse zulassen. Geben Sie den show ip pim rp mapping  Befehl ein, um die richtige RP-Adresse anzuzeigen:

ip22-75a#show ip pim rp mapping PIM Group-to-RP Mappings This system is an RP (Auto-RP) This system is an RP-mapping agent Group(s) 224.0.0.0/4 RP 10.1.5.4 (?), v2v1 Info source: 10.1.5.4 (?), via Auto-RP Uptime: 01:00:48, expires: 00:02:07

Basierend auf der Ausgabe wird nur der RP 10.1.5.4 über Auto-RP oder auf andere Weise erfasst. Dieser Router ist jedoch nur der RP für die Gruppen 224.0.0.0/4. Die pim accept-rp Aussage in der Konfiguration ist also falsch.

Mögliche Fehlerbehebung

Die Lösung besteht darin, die IP-Adresse in der ip pim accept-rp Anweisung wie folgt zu korrigieren:

Diese Anweisung ändern:

ip pim accept-rp 10.2.2.2 8

Dazu:

ip pim accept-rp 10.1.5.4 8

Sie können die Anweisung auch ändern, um den Inhalt des auto-rp-Cache zu akzeptieren, und sicherstellen, dass die Zugriffsliste (in diesem Beispiel 8) den erforderlichen Multicast-Gruppenbereich zulässt. Hier ein Beispiel:

ip pim accept-rp auto-rp access-list 8 permit 224.0.0.0 0.255.255.255

Diagnose des Problems - Teil 2

Diese Fehlermeldung wird auf Router2 angezeigt.

router2# *Aug 12 15:18:17.891: %PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40) Join from 0.0.0.0 for invalid RP 10.2.1.1

Überprüfen Sie, ob router2 der RP für Gruppe 224.1.1.1 ist:

router2#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:21:26, expires: 00:02:24 router2#

Der RP für 224.1.1.1 lautet 10.1.1.1.

Überprüfen Sie, ob dies eine der Schnittstellen von Router2 ist:

router2#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.1.1.2 YES NVRAM up up Ethernet1/0 10.2.1.1 YES NVRAM up up Ethernet2/0 unassigned YES NVRAM administratively down down router2#

Da es sich bei Router2 nicht um einen RP handelt, darf der Router dieses RP-Join-Paket nicht empfangen haben. Prüfen Sie, warum der Downstream-Router Join an router2 gesendet hat, dies jedoch nicht tun darf:

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:24:30, expires: 00:02:16 Group(s): 224.0.0.0/4, Static-Override RP: 10.2.1.1 (?) router3#

Wie Sie sehen, hat Router3 die RP-Informationen statisch konfiguriert und verweist auf Router2, was falsch ist. Dies erklärt, warum Router3 RP-Join an Router2 sendet.

Mögliche Fehlerbehebung

Machen Sie router2 zum RP für die Gruppe 224.1.1.1, oder ändern Sie die Konfiguration auf router3, sodass sie sich auf die richtige RP-Adresse bezieht.

router3#show run | i rp ip pim rp-address 10.2.1.1 override router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router3(config)#no ip pim rp-address 10.2.1.1 override router3(config)#exit router3#

Nachdem die Konfiguration auf Router3 korrigiert wurde, verweist Router3 auf die richtige RP-Adresse, und die Fehlermeldung wird beendet.

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:30:45, expires: 00:02:02 router3#

Duplizierte Multicast-Paketströme werden empfangen

Ursache 1

Wenn zwei Router im Dense-Modus konfiguriert werden, werden doppelte Multicast-Pakete empfangen. Im dichten Modus flutet die Vorrichtung den Strom periodisch. Nach der Überschwemmung schneidet er die Grenzflächen ab, wo der Dampf nicht erwünscht ist. Die beiden Router durchlaufen ebenfalls den Assertionsprozess und entscheiden, wer der Forwarder ist. Jedes Mal, wenn die Timer ausgeschaltet werden, und bis dieser Prozess abgeschlossen ist, leiten beide Router den Stream weiter. Dadurch erhält die Anwendung doppelte Multicast-Streams.

Mögliche Fehlerbehebung 1

Dieses Problem kann behoben werden, wenn einer der Router für Multicast-Routing konfiguriert ist und der andere Router als RP im Upstream-Bereich konfiguriert ist. Konfigurieren Sie den Stream, um ihn in den Sparse-Modus zu konvertieren, bevor er in den Router gelangt. Dadurch kann verhindert werden, dass doppelte Pakete die Anwendung erreichen. Es gehört nicht zur Verantwortung des Netzwerks, sicherzustellen, dass keine duplizierten Pakete jemals einen End-Host erreichen. Es gehört zur Verantwortung der Anwendung, doppelte Pakete zu verarbeiten und nicht benötigte Daten zu ignorieren.

Ursache 2

Dieses Problem kann bei Cisco Catalyst Switches der Serie 6500 auftreten, die für den Multicast-Ausgangs-Replikationsmodus konfiguriert sind und durch Entfernen und Wiedereinsetzen von Line Cards (OIR) ausgelöst werden können. Nach OIR kann der Fabric Port Of Exit (FPOE) falsch programmiert werden, was dazu führen kann, dass Pakete an den falschen Fabric-Ausgangskanal geleitet und an die falschen Linecards gesendet werden. Das Ergebnis ist, dass sie in Loops zum Fabric zurückgeleitet und mehrmals repliziert werden, wenn sie die richtige Linecard nutzen.

C6509#show mls ip multicast capability Current mode of replication is Egress Auto replication mode detection is ON Slot Multicast replication capability 1 Egress 2 Egress 3 Egress 4 Egress 5 Egress 6 Egress 7 Egress

Mögliche Fehlerbehebung 2

Ändern Sie zur Problemumgehung in den Eingangs-Replikationsmodus. Bei einem Wechsel vom Egress- zum Ingress-Replikationsmodus kann es zu Datenverkehrsunterbrechungen kommen, da die Verknüpfungen gelöscht und neu installiert werden.

mls ip multicast replication-mode ingress 

Aktualisieren Sie die Cisco IOS-Software auf eine Version, die nicht von der Cisco Bug-ID CSCeg28814 betroffen ist, um das Problem dauerhaft zu beheben.

Hinweis: Nur registrierte Cisco Benutzer haben Zugriff auf interne Cisco Tools und Fehlerinformationen.

Ursache 3

Dieses Problem kann auch auftreten, wenn die RSS-Einstellung (Receive Side Scaling) auf den End-Hosts oder Servern deaktiviert ist.

Mögliche Fehlerbehebung 3

Die RSS-Einstellung ermöglicht eine schnellere Übertragung von Daten über mehrere CPUs. Aktivieren Sie die RSS-Einstellung auf dem End-Host oder Server.

Warum werden Multicast-Pakete verworfen?

Ursache 1

Bei Multicast-Datenverkehr kann es vorkommen, dass an den Schnittstellen zu viele Datenpakete verloren gehen. Sie können die Leerungen mit dem show interface Befehl überprüfen.

Switch#show interface gigabitethernet 1/0 !--- Output suppressed MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX input flow-control is off, output flow-control is on Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 2/75/0/13370328 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 195000 bits/sec, 85 packets/sec 30 second output rate 1000 bits/sec, 1 packets/sec L2 Switched: ucast: 53056 pkt, 4728434 bytes - mcast: 235759386 pkt, 66914376970 bytes L3 in Switched: ucast: 8714263 pkt, 1815426423 bytes - mcast: 1081138213 pkt,
 438000092206 bytes mcast L3 out Switched: ucast: 4939256 pkt, 790351689 bytes mcast: 0 pkt, 0 bytes 1326976857 packets input, 506833655045 bytes, 0 no buffer Received 1318209538 broadcasts, 0 runts, 0 giants, 1 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 31643944 packets output, 3124494549 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out

Mögliche Fehlerbehebung 1

Sie können den SPT-Wert als unendlich für die Schnittstelle festlegen, in der übermäßige Entleerungen zu sehen sind.

Konfigurieren Sie Folgendes:

Switch(config-if)#ip pim spt-threshold infinity 

Ursache 2

Wenn Sie den ip igmp join-group <group-name> Befehl auf einer oder mehreren Schnittstellen verwenden, wird das Switching verarbeitet. Wenn Multicast-Pakete auf einer oder mehreren Schnittstellen verarbeitet werden, wird eine höhere CPU-Belastung durch das Prozess-Switching aller Pakete an diese Gruppe verursacht. Sie können den show buffers input-interface Befehl ausführen und die ungewöhnliche Größe überprüfen.

Switch#show buffers input-interface gigabitethernet 1/0 Header DataArea Pool Rcnt Size Link Enc Flags Input Output 437C6EAC 8096AE4 Middl 1 434 7 1 280 Gi1/1 None 437C74B4 8097864 Middl 1 298 7 1 280 Gi1/1 None 437C98E4 809C964 Middl 1 434 7 1 280 Gi1/1 None 437CAAFC 809F1E4 Middl 1 349 7 1 280 Gi1/1 None 437CAE00 809F8A4 Middl 1 519 7 1 280 Gi1/1 None !--- Output suppressed 

Mögliche Fehlerbehebung 2

Sie können den ip igmp static-group <group-name> Befehl anstelle des ip igmp join-group <group-name> Befehls verwenden.

Hinweis: Aufgrund früherer Probleme ist es möglich, dass Sie eine hohe CPU-Auslastung von ca. 90 Prozent feststellen. Die CPU normalisiert sich, wenn Sie sie mit diesen möglichen Korrekturen beheben.

Zugehörige Informationen

• Fehlerbehebung bei Multicast-Netzwerken mit CLI-Tools
• Schnellstart-Konfigurationsanleitung für Multicast

• Aktivieren von ECMP Multicast Load Splitting 

• Unterstützung der IP-Multicast-Technologie
• Unterstützung von IP-Routing-Protokollen
• Technischer Support und Downloads von Cisco