Dépanner le PIM compatible HSRP
Introduction
Ce document décrit comment dépanner la fonctionnalité PIM (Protocol Independent Multicast) compatible HSRP (Hot Standby Router Protocol) et les scénarios dans lesquels elle peut être utilisée.
Explication
Dans les environnements qui nécessitent une redondance pour vous, HSRP fonctionne normalement. HSRP est un protocole éprouvé et il fonctionne, mais comment gérez-vous lorsque vous avez des clients qui ont besoin de multidiffusion ? Qu'est-ce qui déclenche la multidiffusion pour converger lorsque le routeur actif (AR) tombe en panne ? Dans ce cas, la topologie 1 est utilisée :
Topologie 1
Une chose à noter ici est que R3 est le routeur désigné PIM (DR) même si R2 est le routeur désigné HSRP. Le réseau a été configuré avec OSPF (Open Shortest Path First), PIM et R1 sont le point de rendez-vous (RP) avec une adresse IP 10.1.1.1. R2 et R3 reçoivent des rapports IGMP (Internet Group Management Protocol), mais seul R3 envoie la jointure PIM, car il s’agit du DR PIM. R3 construit le '*, G' vers le 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:20Vous envoyez ensuite une requête ping à 239.0.0.1 à partir de la source de multidiffusion pour générer le S, G:
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 msLe S, G a été construit :
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:50La topologie de monodiffusion et de multidiffusion n'est pas actuellement congruente. Cela peut ou non être important. Que se passe-t-il lorsque R3 tombe en panne ?
R3(config)#int e0/2
R3(config-if)#sh
R3(config-if)#Aucune réponse aux requêtes ping n'arrive tant que le protocole PIM sur R2 ne détecte pas que R3 n'est plus présent et ne prend pas le rôle de routeur désigné. Cette opération prend entre 60 et 90 secondes lorsque les minuteurs par défaut sont utilisés.
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 msVous pouvez augmenter la priorité du DR sur R2 pour le faire devenir DR.
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/2Le PIM compatible HSRP est une fonctionnalité qui fait du HSRP AR le DR PIM. Il envoie également les messages PIM à partir de l'adresse IP virtuelle, ce qui est utile dans les situations où vous avez un routeur avec une route statique vers une adresse IP virtuelle (VIP). Voici comment Cisco décrit cette fonctionnalité :
Le protocole PIM compatible HSRP permet au trafic de multidiffusion d'être transféré via le routeur AR HSRP, permet au protocole PIM d'exploiter la redondance HSRP, évite le trafic potentiellement dupliqué et permet le basculement, qui dépend des états HSRP dans le périphérique. Le DR PIM s'exécute sur la même passerelle que l'AR HSRP et conserve les états mroute.
Dans la topologie 1, le protocole HSRP s'exécute vers les clients, donc même si cette fonctionnalité semble parfaitement adaptée, elle ne peut pas aider à la convergence multidiffusion. Configurez cette fonctionnalité sur 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/2R2 est maintenant le DR PIM et R3 voit maintenant deux voisins PIM sur l'interface 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 GR2 possède désormais S, G et vous pouvez voir qu'il était le gagnant d'Assert, car R3 était auparavant le redirecteur de multidiffusion vers le segment LAN.
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, AQue se passe-t-il lorsque l’interface LAN de R2 tombe en panne ? R3 peut-il devenir le routeur désigné ? Et à quelle vitesse peut-il converger ?
R2(config)#int e0/2
R2(config-if)#shHSRP passe à actif sur R3 mais le rôle DR PIM ne converge pas jusqu'à ce que l'intervalle de requête PIM ait expiré (3x HELLO).
*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 DRVous perdez beaucoup de paquets pendant que la convergence PIM se produit :
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 msHSRP est conscient que PIM n'a pas vraiment aidé ici. Il est utile si vous utilisez la topologie 2 à la place :
Topologie 2
Le routeur R5 a été ajouté et le récepteur est placé derrière R5. R5 n'exécute pas le routage avec R2 et R3, uniquement avec des points de route statiques au niveau du RP et de la source de multidiffusion :
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.1Sans PIM compatible HSRP, le contrôle RPF (Reverse Path Forwarding) échoue parce que PIM est homologue avec l'adresse physique, mais R5 voit trois voisins sur le segment, dont l'un est le VIP :
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 GR2 est celui qui transfère la multidiffusion au moment des conditions normales puisqu'il s'agit du DR PIM via l'état HSRP du routeur actif :
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:39Essayez une requête ping à partir de la source :
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 msLa requête ping fonctionne et R2 a la valeur 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:29Que se passe-t-il lorsque R2 tombe en panne ?
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....................................................................
......................................................................
............................................................
Les requêtes ping expirent, car lorsque la jointure PIM de R5 arrive, R3 ne se rend pas compte qu'il doit traiter la jointure.
*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.2Comme il s'avère, la commande de redondance PIM doit également être configurée sur le routeur secondaire, pour qu'il traite les jointures PIM au VIP.
R3(config-if)#ip pim redundancy HSRP1 hsrp dr-priority 10Une fois cette configuration effectuée, la jointure entrante est traitée. R3 déclenche l'envoi d'une nouvelle jointure par R5, car l'ID de génération est défini sur une nouvelle valeur dans le Hello PIM.
*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.1Après cette configuration, le rôle DR PIM converge aussi vite que HSRP le permet. La détection de transfert bidirectionnel (BFD) est utilisée dans ce scénario.
Conclusion
Le concept clé pour comprendre le PIM compatible HSRP est le suivant :
- Initialement, la configuration de la redondance PIM sur l'AR en fait le DR.
- La redondance PIM doit également être configurée sur le routeur secondaire, sinon, il ne peut pas traiter les jointures PIM au VIP.
- Le rôle DR PIM ne converge pas tant que les HELLO PIM n'ont pas expiré. Le routeur secondaire traite les jointures, de sorte que la multidiffusion converge.
Enlèvement de clé
Cette fonctionnalité ne fonctionne pas lorsque vous avez un récepteur sur un LAN HSRP, parce que le rôle DR n'est pas déplacé jusqu'à ce que la contiguïté PIM expire.
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
02-Jun-2022 |
Première publication |
Commentaires