Warum funktioniert der PIM Sparse Mode nicht mit einer statischen Route zu einer HSRP-Adresse?

Download-Optionen

  • PDF     (133.2 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (100.8 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (100.4 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:10. August 2005
Dokument-ID:13783

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einführung

In diesem Dokument wird erläutert, warum Multicast-Pakete nicht weitergeleitet werden, wenn Sie eine statische Route zur Hot Standby Router Protocol (HSRP)-Adresse eines PIM-Sparse-Mode-Nachbarn konfigurieren.

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten folgende Themen kennen:

  • HSRP

  • PIM Sparse Mode

Verwendete Komponenten

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

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions.

Netzwerkdiagramm

hsrpmcasta.gif

In der obigen Abbildung sprechen die Router 2 und 3 für HSRP im Subnetz 10.1.3.0, und Router 2 ist der aktive Router. Die Router 1, 2 und 3 sprechen für das Enhanced Interior Gateway Routing Protocol (EIGRP), und Router 4 weist eine statische Standardroute zur virtuellen HSRP-Adresse auf.

Konfigurationen

Router 1 Router 2 
Current configuration:

! 
ip multicast-routing 
! 
! 
interface Loopback0 
ip address 10.10.10.10 255.255.255.255 
no ip directed-broadcast 
! 
interface Ethernet0 
no ip address 
no ip directed-broadcast 
shutdown 
! 
interface Ethernet1 
ip address 10.1.1.1 255.255.255.0 
no ip directed-broadcast 
ip pim sparse-mode 
! 
interface Serial1 
no ip address 
no ip directed-broadcast 
encapsulation frame-relay 
! 
interface Serial1.1 point-to-point 
ip address 10.1.2.1 255.255.255.252 
no ip directed-broadcast 
ip pim sparse-mode 
frame-relay interface-dlci 612 
! 
! 
interface Serial1.2 point-to-point 
ip address 10.1.2.5 255.255.255.252 
no ip directed-broadcast 
ip pim sparse-mode 
frame-relay interface-dlci 613 
! 
router eigrp 1 
network 10.0.0.0 
no auto-summary 
! 
ip classless 
no ip http server 
ip pim rp-address 10.10.10.10 
! 

end
 
Current configuration:

! 
ip multicast-routing 
ip dvmrp route-limit 20000 
! 
! 
interface Ethernet1 
ip address 10.1.3.1 255.255.255.0 
no ip redirects 
ip pim sparse-mode 
standby 1 priority 110 preempt 
standby 1 ip 10.1.3.3 
! 
interface Serial1 
no ip address 
encapsulation frame-relay 
! 
interface Serial1.1 point-to-point 
ip address 10.1.2.2 255.255.255.252 
ip pim sparse-mode 
frame-relay interface-dlci 621 
! 
router eigrp 1 
network 10.0.0.0 
no auto-summary 
! 
ip classless 
ip pim rp-address 10.10.10.10 
!

end
Router 3 Router 4 
Current configuration:

! 
ip multicast-routing 
ip dvmrp route-limit 20000 
! 
interface Ethernet1 
ip address 10.1.3.2 255.255.255.0 
no ip redirects 
ip pim sparse-mode 
standby 1 priority 100 preempt 
standby 1 ip 10.1.3.3 
! 
interface Serial1 
no ip address 
encapsulation frame-relay 
! 
interface Serial1.2 point-to-point 
ip address 10.1.2.6 255.255.255.252 
ip pim sparse-mode 
frame-relay interface-dlci 631 
! 
router eigrp 1 
network 10.0.0.0 
no auto-summary 
eigrp log-neighbor-changes 
! 
ip classless 
no ip http server 
ip pim rp-address 10.10.10.10 
!

end
 
Current configuration:

ip multicast-routing 
ip dvmrp route-limit 20000 
! 
! 
! 
interface Ethernet0 
ip address 10.1.4.1 255.255.255.0 
no ip directed-broadcast 
ip igmp join-group 239.1.2.3 
! 
interface Ethernet1 
ip address 10.1.3.4 255.255.255.0 
no ip directed-broadcast 
ip pim sparse-mode 
! 
no ip http server 
ip classless 
ip route 0.0.0.0 0.0.0.0 10.1.3.3 
ip pim rp-address 10.10.10.10 
!

end

Zur Simulation eines Hosts auf Ethernet 0 wurde der Befehl ip igmp join-group auf dieser Schnittstelle auf Router 4 konfiguriert:

router4# ip igmp join-group 

IGMP Connected Group Membership 
Group Address Interface Uptime Expires Last Reporter 
224.0.1.40 Ethernet1 4d23h never 10.1.3.1 
239.1.2.3 Ethernet0 4d23h never 10.1.4.1

Router 4 kann auch einen Ping an die Rendezvous Point (RP)-Adresse senden:

Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/61/68 ms

Sehen Sie sich die Multicast-Route-Tabelle (mroute) an:

Router4# show ip mroute 239.1.2.3 

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 
X - Proxy Join Timer Running 

Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 
(*, 239.1.2.3), 00:04:28/00:00:00, RP 10.10.10.10, flags: SJCL 
Incoming interface: Ethernet1, RPF nbr 10.1.3.3 
Outgoing interface list: 
Ethernet0, Forward/Sparse, 00:02:12/00:02:53

Da für diese Gruppe ein Empfänger vorhanden ist (aufgrund des Befehls ip igmp join-group, der in Router 4 verwendet wird), erstellen Sie einen (*,G)-Eintrag in der mroute-Tabelle. Beachten Sie, dass der Reverse Path Forwarding (RPF)-Nachbar für den (*,G)-Eintrag 10.1.3.3 ist. Dies ist die HSRP-Standby-Adresse. Es gibt jedoch keinen (S,G)-Eintrag, d. h. der Datenverkehr wird nicht von der Quelle empfangen.

Da Router 4 über einen interessierten Empfänger für die Gruppe verfügt, sollte er jetzt eine PIM Join/Prune-Nachricht an seine PIM-Nachbarn senden. Verwenden Sie den Befehl show ip pim neighbor, um die PIM-Nachbarn von Router 4 anzuzeigen, wie unten gezeigt:

Router4# show ip pim neighbor 

PIM Neighbor Table 
Neighbor Address Interface Uptime Expires Ver Mode 
10.1.3.1 Ethernet1 4d23h 00:01:41 v2 
10.1.3.2 Ethernet1 4d23h 00:01:36 v2

Wenn der Befehl debug ip pim 239.1.2.3 aktiviert ist, erstellt Router 4 diese PIM-Join/Prune-Nachricht, sendet sie aber nicht:

* 6. März 18:32:48: PIM: RP-Erreichbar über Ethernet1 ab 10.10.10.10 *März 6 18:32:48: für die Gruppe 239.1.2.3 *Mär 6 18:33:14: PIM: Building Join/Prune-Nachricht für 239.1.2.3 *06. März 18:34:13: PIM: Erstellen von Join/Prune-Nachrichten für 239.1.2.3

Warum sendet der Router die Meldung Join/Prune nicht? RFC 2362 leavingcisco.com besagt: "Ein Router sendet eine periodische Join/Prune-Nachricht an jeden eindeutigen RPF-Nachbarn, der jedem (S,G), (*,G) und (*,*,RP)-Eintrag zugeordnet ist. Join/Prune-Nachrichten werden nur gesendet, wenn der RPF-Nachbar ein PIM-Nachbar ist."

Im Beispiel ist der RPF-Nachbar 10.1.3.3, d. h. die HSRP-Standby-Adresse, die von der statischen Standardroute verwendet wird. Diese Adresse ist jedoch nicht als PIM-Nachbar aufgeführt. Die HSRP-Standby-Adresse ist nicht als PIM-Nachbarn aufgeführt, da die beiden Router mit HSRP (Router 2 und 3) die PIM-Nachbarnachrichten nicht von der HSRP-Standby-Adresse beziehen.

Um das Problem zu beheben, ändern Sie die Konfiguration von Router 4 so, dass der RPF-Nachbar auch ein PIM-Nachbar ist. Fügen Sie hierzu Router 4 in den EIGRP-Prozess ein, sodass die RP-Adresse jetzt über EIGRP abgerufen wird.

Hinweis: Da Router 4 ein Routing-Protokoll ausführen kann, sollte es nicht erforderlich sein, sich für die Verbindung auf eine HSRP-Standby-Adresse zu verlassen. Die Entwicklung von HSRP sollte Hosts die Möglichkeit bieten, schnell und effizient Redundanz oder Failover zu erzielen.

Nachfolgend finden Sie die neue Konfiguration von Router 4 mit aktiviertem EIGRP.

ip multicast-routing 
ip dvmrp route-limit 20000 
! 
! 
! 
interface Ethernet0 
ip address 10.1.4.1 255.255.255.0 
no ip directed-broadcast 
ip igmp join-group 239.1.2.3 
! 
interface Ethernet1 
ip address 10.1.3.4 255.255.255.0 
no ip directed-broadcast 
ip pim sparse-mode 
!
router eigrp 1
network 10.0.0.0
no auto-summary
! 
no ip http server 
ip classless 
ip route 0.0.0.0 0.0.0.0 10.1.3.3 
ip pim rp-address 10.10.10.10 
!
end

Hinweis: Statt Router 4 in den EIGRP-Prozess (die bevorzugte Methode) einzubinden, fügen Sie Router 4 statische Routen hinzu, um ihn den IP-Adressen der echten Router per RPF zuzuweisen, da bei RPF-Prüfungen Routen gegenüber der Unicast-Routing-Tabelle bevorzugt werden. Fügen Sie z. B. ip mroute 0.0.0.0 0.0.0 10.1.3.2 hinzu.

Zugehörige Informationen

Revisionsverlauf

Überarbeitung Veröffentlichungsdatum Kommentare
1.0
10-Aug-2005
Erstveröffentlichung

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren