Fehlerbehebung: IP Multicast-Leitfaden

Einleitung

In diesem Dokument werden gängige Probleme bei IP-Multicast und die entsprechenden Lösungen beschrieben.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt. 

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Bei der Fehlerbehebung beim Multicast-Routing geht es in erster Linie um die Quelladresse. Für Multicast gilt das Konzept der RPF-Prüfung (Reverse Path Forwarding). Wenn ein Multicast-Paket an einer Schnittstelle eingeht, prüft der RPF-Prozess, ob diese eingehende Schnittstelle die vom Unicast-Routing verwendete Ausgangsschnittstelle ist, um die Quelle des Multicast-Pakets zu erreichen. Diese RPF-Prüfung verhindert Schleifen. Beim Multicast-Routing wird ein Paket nur weitergeleitet, wenn die Quelle des Pakets eine RPF-Prüfung besteht. Wenn ein Paket diese RPF-Prüfung besteht, leitet das Multicast-Routing das Paket nur auf Basis der Zieladresse weiter.

Wie beim Unicast-Routing stehen für das Multicast-Routing mehrere Protokolle zur Verfügung, z. B. Protocol Independent Multicast Dense Mode (PIM-DM), PIM Sparse Mode (PIM-SM), Distance Vector Multicast Routing Protocol (DVMRP), Multicast Border Gateway Protocol (MBGP) und Multicast Source Discovery Protocol (MSDP). Die Fallstudien in diesem Dokument führen Sie durch den Prozess zur Fehlerbehebung bei verschiedenen Problemen. Sie können sehen, welche Befehle verwendet werden, um das Problem schnell zu lokalisieren und zu lernen, wie es zu lösen ist. Die hier aufgeführten Fallstudien sind protokollübergreifend, sofern nicht anders angegeben.

Router leitet Multicast-Pakete aufgrund eines RPF-Fehlers nicht an Host weiter

Dieser Abschnitt bietet eine Lösung für das häufige Problem eines IP-Multicast-RPF-Fehlers. Dieses Netzwerkdiagramm wird als Beispiel verwendet.

Netzwerkdiagramm - Beispiel eines Multicast-RPF-Ausfalls

In dieser Abbildung gelangen Multicast-Pakete von einem Server mit der IP-Adresse 10.1.1.1 in E0/0 des Routers 75a und werden an die Gruppe 10.224.1.1 gesendet. Dies wird als (S,G) oder (10.1.1.1, 10.224.1.1) bezeichnet.

Diagnose des Problems

Hosts, die direkt mit Router 75a verbunden sind, erhalten den Multicast-Feed, Hosts, die direkt mit Router 72a verbunden sind, jedoch nicht. Geben Sie zunächst den show ip mroute 224.1.1.1  , um die Aktivität auf dem Router 75a zu überprüfen. Dieser Befehl untersucht die Multicast-Route (mroute) für die Gruppenadresse 10.224.1.1:

75a#show ip mroute 10.224.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 

(*, 10.224.1.1), 00:01:23/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:01:23/00:00:00 

(10.1.1.1, 10.224.1.1), 00:01:23/00:03:00, flags: TA 
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 

Da der Router den PIM-Dense-Modus ausführt (Sie wissen, dass er aufgrund des D-Flags im Dense-Modus arbeitet), ignorieren Sie den *,G-Eintrag, und konzentrieren Sie sich auf den S,G-Eintrag. Dieser Eintrag teilt Ihnen mit, dass die Multicast-Pakete von einem Server mit der Adresse 10.1.1.1 stammen, der sie an eine Multicast-Gruppe mit der Nummer 10.224.1.1 sendet. Die Pakete gelangen an die Ethernet0/0-Schnittstelle und werden von der Ethernet0/1-Schnittstelle weitergeleitet. Das ist ein perfektes Szenario.

Geben Sie show ip pim neighbor , um festzustellen, ob Router 72a den Upstream-Router (75a) als PIM-Nachbarn anzeigt:

ip22-72a#show ip pim neighbor
PIM Neighbor Table 
Neighbor Address  Interface          Uptime    Expires   Ver  Mode 
10.2.1.1           Ethernet3/1        2d00h     00:01:15  v2 

Über die show ip pim neighbor -Befehls ausgegeben wird, sieht die PIM-Nachbarschaft gut aus.

Geben Sie show ip mroute  um festzustellen, ob Router 72a über eine gute mroute verfügt:

ip22-72a#show ip mroute 10.224.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,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
 
(*, 10.224.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet3/1, Forward/Dense, 00:10:42/00:00:00
    Ethernet3/2, Forward/Dense, 00:10:42/00:00:00
 
(10.1.1.1, 10.224.1.1), 00:01:10/00:02:48, flags: 
  Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet3/1, Forward/Dense, 00:01:10/00:00:00
    Ethernet3/2, Forward/Dense, 00:00:16/00:00:00
 
ip22-72a#

Wie Sie sehen können,  show ip mroute 10.224.1.1  dass die eingehende Schnittstelle Ethernet2/0 ist, während Ethernet3/1 erwartet wird.

Geben Sie  show ip mroute 10.224.1.1 count  um zu überprüfen, ob Multicast-Datenverkehr für diese Gruppe beim Router 72a eingeht und was als Nächstes geschieht:

ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 routes using 2032 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: 10.224.1.1, Source count: 1, Packets forwarded:      0, Packets received: 471
  Source:      10.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#

Aus den anderen Zählern wird ersichtlich, dass Datenverkehr aufgrund eines RPF-Fehlers verworfen wird: insgesamt 471 Verwerfungen, aufgrund eines RPF-Fehlers - 471...

Geben Sie show ip rpf   um zu überprüfen, ob ein RPF-Fehler vorliegt:

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

Cisco IOS® berechnet die RPF-Schnittstelle auf diese Weise. Mögliche Quellen für RPF-Informationen sind die Unicast-Routing-Tabelle, die MBGP-Routing-Tabelle, die DVMRP-Routing-Tabelle und die statische Routing-Tabelle. Bei der Berechnung der RPF-Schnittstelle wird in erster Linie die administrative Distanz verwendet, um genau zu bestimmen, auf welcher Informationsquelle die RPF-Berechnung basiert. Die spezifischen Vorschriften sind:

• Alle vorherigen Quellen von RPF-Daten werden nach einer Übereinstimmung mit der Quell-IP-Adresse durchsucht. Wenn Sie Shared Trees verwenden, wird die RP-Adresse anstelle der Quelladresse verwendet.

• Wenn mehr als eine übereinstimmende Route gefunden wird, wird die Route mit der geringsten administrativen Distanz verwendet.

• Wenn die administrativen Abstände gleich sind, wird die folgende Rangfolge verwendet:

  1. Statische Routen

  2. DVMRP-Routen

  3. MBGP-Routen

  4. Unicast-Routen

• Wenn mehrere Einträge für eine Route innerhalb derselben Routing-Tabelle auftreten, wird die Route mit der längsten Übereinstimmung verwendet.

Die Fehlermeldung  show ip mroute 224.1.1.1 zeigt an, dass die RPF-Schnittstelle E2/0 ist, die Eingangsschnittstelle jedoch E3/1 sein muss.

Geben Sie  show ip mroute 224.1.1.1 , um zu erfahren, warum die RPF-Schnittstelle von den Erwartungen abweicht.

ip22-72a#show ip route 10.1.1.1
  Routing entry for 10.1.1.1/32
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet2/0
   Route metric is 0, traffic share count is 1

Wie Sie der Befehlsausgabe show ip route 10.1.1.1 entnehmen können, gibt es eine statische /32-Route, wodurch die falsche Schnittstelle als RPF-Schnittstelle ausgewählt wird.

Geben Sie einige weitere Debug-Befehle ein:

ip22-72a#debug ip mpacket 10.224.1.1 
*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.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  gut aus, die Anzahl der gesendeten Pakete im  show ip mroute count erhöht, und HostA empfängt Pakete.

ip22-72a#show ip mroute 10.224.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 

(*, 10.224.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, 10.224.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 10.224.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: 10.224.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 10.224.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: 10.224.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 10.224.1.1 
*Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) 
d=10.224.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  show ip mroute  auf Router A, 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 

(*, 10.224.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 10.224.0.40 in der Ausgabe ignorieren, da alle Router dieser Auto-RP Discovery-Gruppe beitreten. Es ist jedoch keine Quelle für 10.224.1.1 aufgelistet. Zusätzlich zu "*, 10.224.1.1" können Sie "10.1.1.1, 10.224.1.1" sehen.

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.

Prüfen Sie, ob PIM auf den Schnittstellen mit dem  show ip pim interface command:

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, ob der Router aktiven Datenverkehr mit dem show ip mroute active  command:

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 10.224.1.1. Sie können es mit dem  show ip igmp group  command:

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 
10.224.1.1        Ethernet1/2          00:30:02  00:02:45  10.3.1.2 

10.224.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 handelt. Dies wird auch mit show ip traffic  command:

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 

(*, 10.224.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, 10.224.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 

(*, 10.224.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, 10.224.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 10.224.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 

(*, 10.224.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, 10.224.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 absolut sicher zu sein, dass der Router 75a die Pakete weiterleitet, aktivieren Sie  debug nur für diese Quelle 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 10.224.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=10.224.1.1 len 60, threshold denied 
*Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied 
*Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied

Die Fehlermeldung  debug zeigen an, dass 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.

Die Fehlermeldung  ip multicast ttl-threshold  -Befehl bedeutet, dass Pakete mit einer TTL, die 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  ip multicast ttl-threshold  -Befehls keine Form dieses Befehls hat, der auf den TTL-Standardschwellenwert 0 zurückgesetzt wird, oder den TTL-Schwellenwert herabsetzt, 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 10.224.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 

(*, 10.224.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, 10.224.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 10.224.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 

(*, 10.224.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, 10.224.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

Nachdem Sie den Tunnel konfiguriert haben, geben Sie show ip mroute  um die Multicast-Route (mroute) für die Gruppe anzuzeigen:

ip22-75a#show ip mroute 10.224.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 

(*, 10.224.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, 10.224.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 10.224.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 

(*, 10.224.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, 10.224.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 (*, 10.224.1.1) 
Join from 10.1.6.2 for invalid RP 10.1.5.4 
00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.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 

Was ist die accept-rp  -Anweisung in der zu erreichenden Konfiguration? 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 Liste von Gruppen bestimmt sind, verwenden Sie die ip pim accept-rp globaler Konfigurationsbefehl. Um diese Prüfung zu entfernen, verwenden Sie die Form no dieses Befehls."

Wenn Sie die ip pim accept-rp  -Befehl werden die Meldungen ausgeblendet. 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 show ip pim rp mapping  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 -Anweisung in der Konfiguration ist falsch.

Mögliche Fehlerbehebung

Die Lösung besteht darin, die IP-Adresse im  ip pim accept-rp   Anweisung wie folgt:

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 10.224.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 10.224.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 10.224.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#

Der CGMP verhindert keine Flut von Multicast-Paketen.

In diesem Abschnitt wird erläutert, wie unerwünschte Überflutungen von Multicast-Paketen auftreten können, wenn das Cisco Group Management Protocol (CGMP) nicht auf allen Routern in einem bestimmten Subnetz aktiviert ist, und wie dieses Problem vermieden werden kann. Dieses Netzwerkdiagramm wird als Beispiel verwendet.

Cisco Group Management Protocol (CGMP) ist nicht aktiviert.

Diagnose des Problems

In der Abbildung zeigt die statische CAM-Tabelle des Catalyst 5000 Switch A keinen der richtigen eingefüllten Ports. Der CGMP-konfigurierte Router sendet keine CGMP-Pakete.

Der CGMP wurde ordnungsgemäß mit dem set cgmp enable  Befehl auf Switch A und ip cgmp  auf der E0/2-Schnittstelle des Routers 75a. Auf Switch A werden jedoch keine Multicast-Gruppen erkannt, wenn die  show multicast group  wird ausgegeben:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 

Total Number of Entries = 0

Die Ausgabe dieses Befehls muss jeden Port anzeigen, auf dem ein CGMP-konfigurierter Router installiert ist (Port 2/3), sowie jeden Port, auf dem ein entsprechender Receiver installiert ist (Port 2/6). Da 0 aufgelistet ist, können Sie davon ausgehen, dass alle Ports unnötigerweise mit Multicast-Datenverkehr überflutet werden, ob sie diesen wollen oder nicht.

Beobachtungen

Überprüfen Sie, ob der Router 75a Protocol Independent Multicast (PIM)-Nachbarn aufweist:

ip22-75a#show ip pim neighbor 
PIM Neighbor Table 
Neighbor Address  Interface          Uptime    Expires   Ver  Mode 
10.2.1.1           Ethernet0/2        00:07:41  00:01:34  v2 

Die Ausgabe zeigt, dass Router 75a Router 75b über Switch A als gültigen PIM-Nachbarn sehen kann.

Überprüfen Sie nun, ob Sie die richtigen Informationen zur Multicast-Route (mroute) auf den Routern erhalten:

ip22-75a#show ip mroute 10.224.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 

(*, 10.224.1.1), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00 

(10.1.1.1, 10.224.1.1), 00:14:56/00:02:59, flags: CTA 
  Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00 

Die Ausgabe zeigt, dass der Router 75a die Multicast-Pakete von E0/2 an Switch A weiterleitet. Diese Ausgabe zeigt, dass Router 75b die Multicast-Pakete empfängt und korrekt weiterleitet:

ip22-75b#show ip mroute 10.224.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 

(*, 10.224.1.1), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC 
  Incoming interface: Null, RPF nbr 0.0.0.0 
  Outgoing interface list: 
    Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00 
    Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00 

(10.1.1.1, 10.224.1.1), 00:00:35/00:02:59, flags: CTA 
  Incoming interface: Ethernet1/3, RPF nbr 10.2.1.2 
  Outgoing interface list: 
    Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00 

Aus der Sicht von Switch A wird Router 75a außerhalb von Port 2/3 erkannt.

Console> (enable) show multicast router 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 

Port       Vlan 
---------  ---------------- 
 2/3       6 

Total Number of Entries = 1 

Alles bisher Gesehene scheint in Ordnung zu sein. Geben Sie einige  debug auf dem Router 75a, um herauszufinden, was Sie herausfinden können:

ip22-75a#debug ip cgmp 
CGMP debugging is on 
*Feb  8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:45:22.206:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 
*Feb  8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:46:22.234:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 
*Feb  8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2 
*Feb  8 12:47:22.262:       GDA 0000.0000.0000, USA 00d0.ff2f.a002 

In der Ausgabe ist 0000.0000.0000 die Adresse für alle Gruppen und wird verwendet, wenn Router CGMP-Join/Leave-Nachrichten senden, damit Switches Router-Ports füllen können. GDA steht für Group Destination Address im Media Access Control (MAC)-Level-Format und USA für Unicast Source Address. Dies ist die Adresse des Hosts, der den IGMP-Bericht erstellt hat, für den diese CGMP-Meldung generiert wird. In diesem Fall ist dies die MAC-Adresse für die Router 75a-Schnittstelle E0/2. Die MAC-Adresse für E0/2 des Routers 75a ist wie folgt zu sehen:  show interface  wie hier gezeigt:

ip22-75a#show interface e0/2 
Ethernet0/2 is up, line protocol is up 
  Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)

Darüber hinaus können Sie dies in regelmäßigen Abständen sehen, wenn das  debug ip igmp  -Befehl ist aktiviert:

*Feb  8 12:51:41.854: IGMP: Received v2 Report from 10.2.1.3 (Ethernet0/2) for 10.224.1.1

Anschließend wird jedoch kein entsprechendes CGMP-Paket von Router 75a angezeigt. Das bedeutet, dass Router 75a IGMP-Berichte empfängt, jedoch nicht die erforderlichen CGMP-Pakete generiert, damit Switch A wissen kann, welche Ports blockiert werden müssen. Dies wird vom Router 75a erwartet, wenn es sich um den IGMP Querier handelt. Diese Ausgabe von Router 75a zeigt an, warum das erwartete Verhalten nicht auftritt:

ip22-75a#show ip igmp interface e0/2 
Ethernet0/2 is up, line protocol is up 
  Internet address is 10.2.1.2/24 
  IGMP is enabled on interface 
  Current IGMP version is 2 
  CGMP is enabled 
  IGMP query interval is 60 seconds 
  IGMP querier timeout is 120 seconds 
  IGMP max query response time is 10 seconds 
  Last member query response interval is 1000 ms 
  Inbound IGMP access group is not set 
  IGMP activity: 3 joins, 1 leaves 
  Multicast routing is enabled on interface 
  Multicast TTL threshold is 0 
  Multicast designated router (DR) is 10.2.1.2 (this system) 
  IGMP querying router is 10.2.1.1 
  No multicast groups joined 

Wenn sich zwei Router im gleichen Subnetz befinden und Sie beide für den CGMP konfigurieren, kann nur einer CGMP-Pakete senden. Der Router, der die CGMP-Pakete sendet, ist das IGMP, das den Router abfragt. Dies bezeichnet den Router mit der niedrigsten Unicast-IP-Adresse der IGMP-fähigen Router.

In diesem Fall ist IGMP auf beiden Routern 75a und 75b aktiviert (Router 75b wurde zum IGMP-abfragenden Router), aber nur auf Router 75a ist CGMP aktiviert. Da der Router 75a nicht der IGMP-anfragende Router ist, werden keine CGMP-Pakete gesendet.

Mögliche Fehlerbehebung

Um das Problem zu beheben, müssen Sie CGMP auf dem IGMP-anfragenden Router konfigurieren. In diesem Fall Router 75b. Zuerst einschalten debug Befehle auf Router 75b:

ip22-75b#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
ip22-75b(config)#int e 1/3 
ip22-75b(config-if)#ip cgmp 
ip22-75b(config-if)#end 
ip22-75b#debug ip cgmp 
ip22-75b#debug ip igmp 
*Feb  8 12:58:42.422: IGMP: Received v2 Report from 10.2.1.3 (Ethernet1/3) for 10.224.1.1 
*Feb  8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 
*Feb  8 12:58:42.422:       from 10.2.1.3 for 10.224.1.1 
*Feb  8 12:58:42.422: CGMP: Sending Join on Ethernet1/3 
*Feb  8 12:58:42.422:       GDA 0100.5e01.0101, USA 0030.b655.a859 

Router 75b empfängt einen IGMP-Bericht von 10.2.1.3 für Gruppe 10.224.1.1. Anschließend sendet er eine CGMP-Join-Nachricht an Switch A für das MAC-Äquivalent 10.224.1.1 mit der MAC-Adresse (USA) des interessierten Hosts 10.2.1.3. Switch A weiß, an welchem Port sich der Host befindet, markiert ihn also als offen und blockiert die anderen.

Switch A muss nun funktionsfähig sein:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 
6     01-00-5e-01-01-01             2/3-4,2/6 

Total Number of Entries = 2 

Das ist viel besser. Die 10.224.1.1 (01-00-5e-01-01-01) Pakete werden nur wie gewünscht an die Ports 2/3, 2/4 und 2/6 an Switch A gesendet. Die Überflutung aller anderen Ports wurde beendet. Die Gesamtanzahl der Einträge wird nun korrekt als 2 angezeigt. Die MAC-Adresse 01-00-5e-00-01-28 wird aus der Multicast-Adresse 224.0.1.40 abgeleitet, die für CGMP-Self-Joins verwendet wird.

Der CGMP verhindert nicht das Flooding von Multicast-Paketen aufgrund der Quell-/Empfängerplatzierung.

Dieser Abschnitt bietet eine Lösung für das häufige Problem eines Catalyst Switches, bei dem der Datenverkehr nicht nur an den richtigen Host, sondern an alle Ports geleitet wird. Dieses Netzwerkdiagramm wird als Beispiel verwendet.

Catalyst Switch überflutet Datenverkehr an jeden Port

Diagnose des Problems

In der Abbildung sind die Router 75a und 75b sowie der Catalyst 5000 (Switch A) ordnungsgemäß für Multicast und Cisco Group Management Protocol (CGMP) konfiguriert. Der Host erhält den Multicast-Datenverkehr. Gleiches gilt für alle anderen Hosts von Switch A. Switch A flutet den Datenverkehr über alle Ports, was bedeutet, dass CGMP nicht funktioniert.

Die Ausgabe des  show multicast group auf Switch A sieht wie folgt aus:

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 

Total Number of Entries = 1 

Aus der Ausgabe geht hervor, dass die einzige Gruppe 224.0.1.40 ist. Diese wird vom Router verwendet, wenn er CGMP-Self-Joins für die Auto-RP-Gruppe sendet. Wie kommt es, dass es keine anderen Gruppen gibt?

Mögliche Fehlerbehebung

Um die Lösung zu verstehen, müssen Sie wissen, wie sich CGMP unter bestimmten Bedingungen verhält. Ein CGMP-fähiger Router sendet CGMP-Joins an einen Switch, um den Switch über Hosts zu informieren, die an einer bestimmten Multicast-Gruppe interessiert sind. Der Switch sucht in seiner CAM-Tabelle nach den MAC-Adressen für diese Hosts und leitet dann Multicast-Pakete an die Ports mit interessierten Hosts weiter. Außerdem blockiert er die Weiterleitung von Multicast-Paketen durch alle anderen Ports.

Ein Router sendet CGMP-Self-Joins von einer CGMP-fähigen Schnittstelle, wenn er Multicast-Pakete von einer Quelle empfängt, die sich auf derselben Schnittstelle befindet, auf der (dem Router) CGMP aktiviert ist.

Wenn sich die Quelle beispielsweise im selben Subnetz (VLAN), 10.2.1.0/24, wie die Router 75a und 75b befindet, funktioniert CGMP einwandfrei. Wenn der Router Pakete von der Quelle identifiziert, sendet er einen CGMP-Self-Join an den Switch, der dann dynamisch lernt, an welchen Ports sich der Router befindet, und alle anderen Ports daran hindert, Multicast-Pakete weiterzuleiten.

Ein Router sendet CGMP-Joins von einer CGMP-fähigen Schnittstelle, wenn er IGMP-Berichte von einem Host auf derselben Schnittstelle empfängt, auf der auch CGMP aktiviert ist (der Router).

Ein weiteres Beispiel wäre, wenn sich ein interessierter Host auf demselben VLAN befände. Wenn ein CGMP-fähiger Router einen IGMP-Bericht (Internet Group Management Protocol) von einem Host erhält, der an einer bestimmten Multicast-Gruppe interessiert ist, sendet der Router eine CGMP-Anmeldung. Der Join gibt die MAC-Adresse (Media Access Control) des Hosts an, der der Konferenz beitreten möchte, sowie die Gruppe, der sie beitreten möchte. Der Catalyst 5000 würde dann seine CAM-Tabelle nach der Host-MAC-Adresse durchsuchen, den zugehörigen Port in die Multicast-Gruppenliste aufnehmen und alle anderen Ports blockieren, die nicht von Interesse sind.

Dasselbe gilt nicht, wenn sich die Quelle und die interessierten Hosts in einem anderen Subnetz als dem CGMP-fähigen Subnetz (VLAN) befinden. Multicast-Pakete, die von der Quelle stammen, lösen den Router nicht aus, CGMP-Self-Joins an den Switch zu senden. Daher werden die Pakete auf den Switch übertragen und im gesamten VLAN verteilt. Dieses Szenario wird so lange fortgesetzt, bis ein Host im VLAN, der einen Port am Switch verlässt, einen IGMP-Join sendet. Erst nach Eingang eines IGMP-Berichts sendet der Router ein CGMP-Paket, das den Switch veranlasst, den geeigneten Host-Port als Weiterleitung hinzuzufügen, und alle anderen Ports werden blockiert (mit Ausnahme der Router-Ports).

Damit CGMP in dieser Transit-Topologie funktioniert, können Sie entweder einen Host zum gleichen VLAN wie die Router 75a und 75b hinzufügen, wie in diesem Netzwerkdiagramm dargestellt.

Hinzufügen eines Hosts zu demselben VLAN wie die Router 75a und 75b

Oder verschieben Sie die Quelle, wie in diesem Beispiel gezeigt, in dasselbe Subnetz wie die Router 75a und 75b.

Verschieben der Quelle in dasselbe Subnetz wie die Router 75a und 75b

Verschieben Sie die Quelle in dasselbe Subnetz, und überprüfen Sie dann die Ausgabe von Switch A:

Console> (enable) show multicast router 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 

Port       Vlan 
---------  ---------------- 
 2/3       6 
 2/4       6 

Total Number of Entries = 2 
'*' - Configured 
Console> (enable) 

Console> (enable) show multicast group 
CGMP enabled 
IGMP disabled 
IGMP fastleave disabled 
GMRP disabled 

VLAN  Dest MAC/Route Des    [CoS]  Destination Ports or VCs / [Protocol Type] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 
6     01-00-5e-01-01-01             2/3-4 

Total Number of Entries = 2 

Der CGMP verhindert kein Flooding von Multicast-Paketen für bestimmte Gruppenadressen.

In diesem Abschnitt wird erläutert, warum einige Multicast-IP-Adressen dazu führen, dass das Cisco Group Management Protocol (CGMP) den Multicast-Datenverkehr über alle Ports in einem LAN (Local Area Network) verteilt. Wenn Sie die Multicast-Gruppenadresse 10.225.0.1 verwenden, funktioniert CGMP nicht. Er flutet den Multicast-Stream über alle Switch-Ports und verschwendet Bandbreite. Wenn Sie die Adresse jedoch in 10.225.1.1 ändern, funktioniert CGMP einwandfrei. Können Sie 10.225.0.1 verwenden, da es sich nicht um eine registrierte Adresse für ein Routing-Protokoll handelt?

Mögliche Fehlerbehebung

Zunächst ist es wichtig zu verstehen, wie Layer-3-Multicast-Adressen Layer-2-Multicast-Adressen zugeordnet werden. Alle IP-Multicast-Frames verwenden IEEE-MAC-Layer-Adressen, die mit dem 24-Bit-Präfix 0x0100.5e beginnen. Wenn Sie Layer 3- und Layer 2-Adressen zuordnen, werden die niedrigen 23 Bit der Layer 3-Multicast-Adresse den niedrigen 23 Bit der IEEE-MAC-Adresse zugeordnet.

Ein weiterer wichtiger Aspekt ist, dass 28 Bit eindeutiger Adressraum für eine IP-Multicast-Adresse vorhanden sind (32 Bit minus den ersten 4 Bit, die das Präfix der Klasse D 1110 enthalten). Da nur 23 Bit an die IEEE-MAC-Adresse angeschlossen sind, bleiben 5 Bit der Überlappung erhalten. Das bedeutet, dass mehrere Layer-3-Multicast-Adressen derselben Layer-2-Multicast-Adresse zugeordnet werden können.

Beispiele:

10.244.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary
low order 23 bits =    000 0000.0000 0000.0000 0001
hex equivalent    =     0    0    0    0    0    1
result of mapping = 0x0100.5e00.0001


10.244.128.0 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary
low order 23 bits =      000 0000.0000 0000.0000 0001
hex equivalent    =       0    0    0     0    0    1
result of mapping = 0x0100.5e00.0001

Im Beispiel werden 10.244.0.1 und 10.244.128.0 derselben Layer-2-Multicast-Adresse zugeordnet.

Nachdem Sie jetzt wissen, wie Multicast-Adressen von Layer 3 auf Layer 2 zugeordnet werden, fahren Sie mit der spezifischen Lösung für dieses Problem fort.

Switch A flutet Multicast-Pakete mit 224.0.0.x, da diese Adressen Link-Local sind, und Sie sicherstellen möchten, dass Link-Local-Adressen zu allen Geräten im LAN (Local Area Network) gelangen. Catalyst Switches übertragen Multicast-Pakete auch an andere Multicast-Adressen, die auf der MAC-Ebene nicht eindeutig mit 224.0.0.x sind (beispielsweise 10.244.0.1 und 10.225.0.1, die beide 0100.5e00.0001 zugeordnet sind). Der Switch flutet die Multicast-Pakete, die für diese lokalen Verbindungsadressen bestimmt sind, unabhängig davon, ob CGMP aktiviert ist oder nicht.

Daher muss die Multicast-Anwendung die Verwendung von Adressen der Klasse D vermeiden, die einer Layer-2-Multicast-Adresse von 0100.5e00.00xx zugeordnet sind, wobei xx im Hexadezimalformat 00 bis FF sein kann. Diese besteht aus den folgenden Klassen-D-Adressen:

224.0.0.x (x = 0 to 255)
225.0.0.x 
.
239.0.0.x


224.128.0.x (x = 0 to 255)
225.128.0.x
.
239.128.0.x

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 Spülungen mit dem  show interface  aus.

Switch#show interface gi 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 die  ip igmp join-group   -Befehls auf einer oder mehreren Schnittstellen ausgeführt wird, verarbeitet er das Switching. 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 die show buffers input-interface und überprüfen Sie die ungewöhnliche Größe.

Switch#show buffers input-interface gi 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 die   ip igmp static-group   anstelle des Befehls  ip igmp join-group   aus.

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