Contenu

Introduction

Explication

Conclusion

Reprise clé

Informations connexes

Introduction

Ce document décrit comment dépanner la fonctionnalité de multidiffusion indépendante du protocole (PIM) 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 s'exécute normalement. HSRP est un protocole éprouvé qui fonctionne, mais comment gérer quand vous avez des clients qui ont besoin de multidiffusion ? Qu’est-ce qui déclenche la convergence de la multidiffusion 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é (DR) PIM 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 tous deux des rapports IGMP (Internet Group Management Protocol), mais seul R3 envoie le PIM Join 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:20

Vous envoyez ensuite une requête ping à 239.0.0.1 à partir de la source de multidiffusion pour générer 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 ms

Le 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:50

La topologie de monodiffusion et de multidiffusion n'est pas compatible actuellement. Cela peut ou ne peut pas être important. Que se passe-t-il en cas de défaillance de R3 ?

R3(config)#int e0/2

R3(config-if)#sh

R3(config-if)#

Aucune réponse aux requêtes ping n'est reçue tant que PIM sur R2 ne détecte pas que R3 est parti et ne prend pas en charge le rôle DR. Cela prend entre 60 et 90 secondes avec les temporisateurs par défaut 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 ms

Vous pouvez augmenter la priorité du routeur désigné sur R2 pour en faire le routeur désigné.

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

PIM compatible HSRP est une fonctionnalité qui fait de HSRP AR le DR PIM. Il envoie également les messages PIM 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 HSRP Aware PIM permet le transfert du trafic de multidiffusion via le HSRP AR, permet au protocole PIM d'exploiter la redondance HSRP, évite les trafics en double potentiels et permet le basculement, qui dépend des états HSRP du périphérique. Le PIM-DR fonctionne sur la même passerelle que le HSRP AR et gère les états de 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 dans la convergence de 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/2

R2 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 G

R2 a maintenant le S, G et vous pouvez voir que c'était le gagnant du Assert parce que 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, A

Que se passe-t-il lorsque l’interface LAN de R2 est désactivée ? R3 peut-il devenir le routeur désigné ? Et à quelle vitesse peut-il converger ?

R2(config)#int e0/2

R2(config-if)#sh

HSRP devient actif sur R3 mais le rôle DR PIM ne converge pas tant que l'intervalle de requête PIM n'a pas expiré (3 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 DR

Vous perdez beaucoup de paquets lorsque 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 ms

HSRP est conscient que PIM n'a pas vraiment aidé ici. Il est utile si vous utilisez plutôt la topologie 2 :

Topologie 2

Le routeur R5 a été ajouté et le récepteur se trouve 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.1

Sans PIM compatible HSRP, le contrôle RPF (Reverse Path Forwarding) échoue car PIM homologue avec l'adresse physique, mais R5 voit trois voisins sur le segment, où 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 G

R2 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:39

Essayez 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 ms

La requête ping fonctionne et R2 a le 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

Que se passe-t-il en cas de défaillance de R2 ?

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 le PIM Join de R5 arrive, R3 ne se rend pas compte qu'il doit traiter le Join.

*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

Il s'avère que 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 10

Une fois configuré, la jointure entrante est traitée. R3 déclenche R5 pour envoyer une nouvelle jointure, car l'ID de génération est défini dans le Hello PIM sur une nouvelle valeur.

*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

Aprè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 protocole PIM compatible HSRP est le suivant :

- Initialement, la configuration de 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 paquets Hello PIM n'ont pas expiré. Le routeur secondaire traite les jointures, de sorte que la multidiffusion converge.

Reprise clé

Cette fonctionnalité ne fonctionne pas lorsque vous avez un récepteur sur un réseau local HSRP, car le rôle DR n'est pas déplacé jusqu'à l'expiration de la contiguïté PIM.

Informations connexes

- 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

- Support et documentation techniques - Cisco Systems