Fehlerbehebung für HSRP-fähiges PIM

Einleitung

In diesem Dokument wird die Fehlerbehebung für die Funktion Hot Standby Router Protocol (HSRP)-fähige Protocol Independent Multicast (PIM) und die Szenarien beschrieben, in denen diese verwendet werden kann.

Erläuterung

In Umgebungen, die für Sie Redundanz erfordern, wird HSRP normal ausgeführt. HSRP ist ein bewährtes Protokoll und funktioniert, aber wie gehen Sie vor, wenn Sie Clients haben, die Multicast benötigen? Was löst die Multicast-Konvergenz aus, wenn der Active Router (AR) ausfällt? In diesem Fall wird Topologie 1 verwendet:

Topologie 1

Hierbei ist zu beachten, dass R3 der PIM Designated Router (DR) ist, obwohl R2 der HSRP AR ist. Das Netzwerk wurde mit Open Shortest Path First (OSPF) eingerichtet, PIM und R1 sind der Rendezvous Point (RP) mit einer 10.1.1.1 IP-Adresse. Sowohl R2 als auch R3 empfangen Internet Group Management Protocol (IGMP)-Berichte, aber nur R3 sendet die PIM-Join-Nachricht, da es sich um den PIM DR handelt. R3 erstellt '*,G' zum RP:

R3#sh ip mroute 239.0.0.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.0.0.1), 02:54:15/00:02:20, RP 10.1.1.1, flags: SJC
  Incoming interface: Ethernet0/0, RPF nbr 172.16.1.1
  Outgoing interface list:
    Ethernet0/2, Forward/Sparse, 00:25:59/00:02:20

Anschließend wird ein Ping an 239.0.0.1 von der Multicast-Quelle gesendet, um S,G zu erstellen:

Sender#ping 239.0.0.1 re 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Reply to request 0 from 10.0.0.10, 35 ms
Reply to request 1 from 10.0.0.10, 1 ms
Reply to request 2 from 10.0.0.10, 2 ms

Das S,G wurde gebaut:

R3#sh ip mroute 239.0.0.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.0.0.1), 02:57:14/stopped, RP 10.1.1.1, flags: SJC
  Incoming interface: Ethernet0/0, RPF nbr 172.16.1.1
  Outgoing interface list:
    Ethernet0/2, Forward/Sparse, 00:28:58/00:02:50

(192.168.1.10, 239.0.0.1), 00:02:03/00:00:56, flags: JT
  Incoming interface: Ethernet0/0, RPF nbr 172.16.1.1
  Outgoing interface list:
    Ethernet0/2, Forward/Sparse, 00:02:03/00:02:50

Die Unicast- und Multicast-Topologie ist derzeit nicht deckungsgleich. Das kann wichtig sein oder auch nicht. Was passiert, wenn R3 ausfällt?

R3(config)#int e0/2
R3(config-if)#sh
R3(config-if)#

Es werden keine Antworten auf die Pings empfangen, bis PIM auf R2 erkennt, dass R3 nicht mehr verfügbar ist und die DR-Rolle übernimmt. Bei Verwendung der Standard-Timer dauert dies zwischen 60 und 90 Sekunden.

Sender#ping 239.0.0.1 re 100 ti 1
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 239.0.0.1, timeout is 1 seconds:

Reply to request 0 from 10.0.0.10, 18 ms
Reply to request 1 from 10.0.0.10, 2 ms....................................................................
.......
Reply to request 77 from 10.0.0.10, 10 ms
Reply to request 78 from 10.0.0.10, 1 ms
Reply to request 79 from 10.0.0.10, 1 ms
Reply to request 80 from 10.0.0.10, 1 ms

Sie können die DR-Priorität auf R2 erhöhen, um daraus den DR zu machen.

R2(config-if)#ip pim dr-priority 50  
*May 30 12:42:45.900: %PIM-5-DRCHG: DR change from neighbor 10.0.0.3 to 10.0.0.2 on interface Ethernet0/2

HSRP-fähiges PIM ist eine Funktion, die HSRP AR zum PIM DR macht. Es sendet auch die PIM-Nachrichten von der virtuellen IP, was in Situationen nützlich ist, in denen Sie einen Router mit einer statischen Route zu einer virtuellen IP (VIP) haben. Cisco beschreibt die Funktion wie folgt:

HSRP-fähiges PIM ermöglicht die Weiterleitung von Multicast-Datenverkehr über die HSRP-AR, ermöglicht PIM die Nutzung der HSRP-Redundanz, vermeidet potenziell doppelten Datenverkehr und ermöglicht ein Failover, das von den HSRP-Zuständen im Gerät abhängt. Der PIM-DR wird auf demselben Gateway wie der HSRP AR ausgeführt und behält den Routenstatus bei.

In Topologie 1 wird HSRP zu den Clients hin ausgeführt. Diese Funktion mag zwar perfekt passen, kann jedoch bei der Multicast-Konvergenz nicht helfen. Konfigurieren Sie diese Funktion auf R2:

R2(config-if)#ip pim redundancy HSRP1 hsrp dr-priority 100
R2(config-if)#
*May 30 12:48:20.024: %PIM-5-DRCHG: DR change from neighbor 10.0.0.3 to 10.0.0.2 on interface Ethernet0/2

R2 ist jetzt der PIM DR, und R3 erkennt jetzt zwei PIM-Nachbarn an der Schnittstelle E0/2:

R3#sh ip pim nei e0/2
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
10.0.0.1          Ethernet0/2              00:00:51/00:01:23 v2    0 / S P G
10.0.0.2          Ethernet0/2              00:07:24/00:01:23 v2    100/ DR S P G

R2 verfügt jetzt über das S,G, und wie Sie sehen, war R3 der Gewinner der Assert-Bewertung, da R3 zuvor der Multicast-Forwarder für das LAN-Segment war.

R2#sh ip mroute 239.0.0.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.0.0.1), 00:20:31/stopped, RP 10.1.1.1, flags: SJC
  Incoming interface: Ethernet0/0, RPF nbr 192.0.2.1
  Outgoing interface list:
    Ethernet0/2, Forward/Sparse, 00:16:21/00:02:35

(192.168.1.10, 239.0.0.1), 00:00:19/00:02:40, flags: JT
  Incoming interface: Ethernet0/0, RPF nbr 192.0.2.1
  Outgoing interface list:
    Ethernet0/2, Forward/Sparse, 00:00:19/00:02:40, A

Was passiert, wenn die R2s LAN-Schnittstelle ausfällt? Kann R3 zum DR werden? Und wie schnell kann sie konvergieren?

R2(config)#int e0/2
R2(config-if)#sh

HSRP wird auf R3 aktiviert, die PIM DR-Rolle wird jedoch erst nach Ablauf des PIM-Abfrasintervalls konvergiert (3 Hellos).

*May 30 12:51:44.204: HSRP: Et0/2 Grp 1 Redundancy "hsrp-Et0/2-1" state Standby -> Active
R3#sh ip pim nei e0/2
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
10.0.0.1          Ethernet0/2              00:04:05/00:00:36 v2    0 / S P G
10.0.0.2          Ethernet0/2              00:10:39/00:00:36 v2    100/ DR S P G
R3#
*May 30 12:53:02.013: %PIM-5-NBRCHG: neighbor 10.0.0.2 DOWN on interface Ethernet0/2 DR
*May 30 12:53:02.013: %PIM-5-DRCHG: DR change from neighbor 10.0.0.2 to 10.0.0.3 on interface Ethernet0/2
*May 30 12:53:02.013: %PIM-5-NBRCHG: neighbor 10.0.0.1 DOWN on interface Ethernet0/2 non DR

Während der PIM-Konvergenz gehen viele Pakete verloren:

Sender#ping 239.0.0.1 re 100 time 1
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 239.0.0.1, timeout is 1 seconds:

Reply to request 0 from 10.0.0.10, 5 ms
Reply to request 0 from 10.0.0.10, 14 ms...................................................................
Reply to request 68 from 10.0.0.10, 10 ms
Reply to request 69 from 10.0.0.10, 2 ms

Reply to request 70 from 10.0.0.10, 1 ms

HSRP ist sich bewusst, dass PIM hier nicht wirklich hilfreich war. Es ist hilfreich, wenn Sie stattdessen Topologie 2 verwenden:

Topologie 2

Der Router R5 wurde hinzugefügt, und der Empfänger befindet sich stattdessen hinter R5. R5 führt kein Routing mit R2 und R3 aus, sondern nur mit statischen Routing-Punkten am RP und der Multicast-Quelle:

R5(config)#ip route 10.1.1.1 255.255.255.255 10.0.0.1
R5(config)#ip route 192.168.1.0 255.255.255.0 10.0.0.1

Ohne HSRP-fähiges PIM schlägt die RPF-Prüfung (Reverse Path Forwarding) fehl, da PIM mit der physischen Adresse gleicht, R5 jedoch drei Nachbarn auf dem Segment erkennt, von denen einer der VIP ist:

R5#sh ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
10.0.0.2          Ethernet0/0              00:03:00/00:01:41 v2    100/ DR S P G
10.0.0.1          Ethernet0/0              00:03:00/00:01:41 v2    0 / S P G
10.0.0.3          Ethernet0/0              00:03:00/00:01:41 v2    1 / S P G

R2 ist der Router, der Multicast unter normalen Bedingungen weiterleitet, da es sich um den PIM DR über den HSRP-Status des aktiven Routers handelt:

R2#sh ip mroute 239.0.0.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.0.0.1), 00:02:12/00:02:39, RP 10.1.1.1, flags: S
  Incoming interface: Ethernet0/0, RPF nbr 192.0.2.1
  Outgoing interface list:
    Ethernet0/2, Forward/Sparse, 00:02:12/00:02:39

Versuchen Sie einen Ping von der Quelle:

Sender#ping 239.0.0.1 re 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Reply to request 0 from 198.51.100.10, 1 ms
Reply to request 1 from 198.51.100.10, 2 ms
Reply to request 2 from 198.51.100.10, 2 ms

Der Ping funktioniert, und R2 hat die S,G:

R2#sh ip mroute 239.0.0.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.0.0.1), 00:04:18/00:03:29, RP 10.1.1.1, flags: S
  Incoming interface: Ethernet0/0, RPF nbr 192.0.2.1
  Outgoing interface list:
    Ethernet0/2, Forward/Sparse, 00:04:18/00:03:29

(192.168.1.10, 239.0.0.1), 00:01:35/00:01:24, flags: T
  Incoming interface: Ethernet0/0, RPF nbr 192.0.2.1
  Outgoing interface list:
    Ethernet0/2, Forward/Sparse, 00:01:35/00:03:29

Was passiert, wenn R2 ausfällt?

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int e0/2
R2(config-if)#sh
R2(config-if)#

Sender#ping 239.0.0.1 re 200 ti 1
Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 239.0.0.1, timeout is 1 seconds:

Reply to request 0 from 198.51.100.10, 9 ms
Reply to request 1 from 198.51.100.10, 2 ms
Reply to request 1 from 198.51.100.10, 11 ms....................................................................
......................................................................
............................................................

Bei den Pings wird die Zeit überschritten, da R3 nicht erkennt, dass die PIM-Join-Nachricht von R5 verarbeitet werden muss.

*May 30 13:20:13.236: PIM(0): Received v2 Join/Prune on Ethernet0/2 from 10.0.0.5, not to us
*May 30 13:20:32.183: PIM(0): Generation ID changed from neighbor 10.0.0.2

Wie sich herausstellt, muss der PIM-Redundanzbefehl auch auf dem sekundären Router konfiguriert werden, damit PIM Joins to the VIP verarbeitet werden können.

R3(config-if)#ip pim redundancy HSRP1 hsrp dr-priority 10

Nachdem dies konfiguriert wurde, wird der eingehende Join verarbeitet. R3 löst R5 aus, eine neue Join-Nachricht zu senden, da die GenID im PIM-Hello auf einen neuen Wert festgelegt ist.

*May 30 13:59:19.333: PIM(0): Matched redundancy group VIP 10.0.0.1 on Ethernet0/2 Active, processing the Join/Prune, to us
*May 30 13:40:34.043: PIM(0): Generation ID changed from neighbor 10.0.0.1

Nach dieser Konfiguration wird die PIM DR-Rolle so schnell konvergiert, wie es das HSRP zulässt. In diesem Szenario wird die bidirektionale Weiterleitungserkennung (BFD) verwendet.

Schlussfolgerung

Das zentrale Konzept für ein HSRP-fähiges PIM ist in diesem Zusammenhang folgende:

• Zunächst wird der DR durch die PIM-Redundanzkonfiguration auf dem AR festgelegt.
• Die PIM-Redundanz muss auch auf dem sekundären Router konfiguriert werden. Andernfalls können PIM-Joins zum VIP nicht verarbeitet werden.
• Die PIM DR-Rolle konvergiert erst, wenn die PIM-Hellos abgelaufen sind. Der sekundäre Router verarbeitet die Joins, sodass Multicast konvergiert.

Wichtige Merkmale

Diese Funktion funktioniert nicht, wenn sich ein Empfänger in einem HSRP-LAN befindet, da die DR-Rolle erst nach Ablauf der PIM-Adjacency verschoben wird.

Zugehörige Informationen

• https://www.cisco.com/en/US/docs/ios-xml/ios/ipmulti_pim/configuration/15-2s/imc_hsrp_aware.html#GUID-1294B212-466A-4D8D-AB20-D8DE0B3645CD

• Technischer Support und Dokumentation für Cisco Systeme