Troubleshooting de HSRP Aware PIM

Opciones de descarga

PDF (473.0 KB)
Visualice con Adobe Reader en una variedad de dispositivos
ePub (295.6 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (184.8 KB)
Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos

Actualizado:2 de junio de 2022

ID del documento:217904

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Contenido

Información Relacionada

Introducción

Este documento describe cómo resolver problemas de la función de multidifusión independiente del protocolo de router con espera en caliente (HSRP) y escenarios en los que se puede utilizar.

Explicación

En entornos que requieren redundancia, HSRP se ejecuta normalmente. HSRP es un protocolo de eficacia probada y funciona, pero ¿cómo se gestiona cuando hay clientes que necesitan multidifusión? ¿Qué activa la convergencia de multidifusión cuando el router activo (AR) deja de funcionar? En este caso, se utiliza la Topología 1:

Topology 1

Topología 1

Una cosa a notar aquí es que R3 es el router designado PIM (DR) aunque R2 sea el AR HSRP. La red se ha configurado con OSPF (ruta de acceso más corta primero), PIM y R1 son el punto de encuentro (RP) con una dirección IP 10.1.1.1. Tanto R2 como R3 reciben informes del protocolo de administración de grupos de Internet (IGMP), pero sólo R3 envía la conexión PIM, ya que es PIM DR. R3 construye el '*,G' hacia el 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

A continuación, se hace ping a 239.0.0.1 desde el origen de multidifusión para generar 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

El S,G ha sido construido:

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

Actualmente, la topología de unidifusión y multidifusión no es coherente. Esto puede o no puede ser importante. ¿Qué sucede cuando falla R3?

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

No se reciben respuestas a los pings hasta que PIM en R2 detecta que R3 se ha ido y asume el rol DR. Este proceso tarda entre 60 y 90 segundos con los temporizadores predeterminados en uso.

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

Puede aumentar la prioridad DR en R2 para convertirla en 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/2

PIM que reconoce HSRP es una función que hace que HSRP AR sea PIM DR. También envía los mensajes PIM desde la IP virtual, lo cual es útil en situaciones en las que tiene un router con una ruta estática hacia una IP virtual (VIP). Así es como Cisco describe la función:

PIM con reconocimiento de HSRP permite reenviar el tráfico multicast a través de HSRP AR, permite que PIM aproveche la redundancia de HSRP, evita el posible tráfico duplicado y habilita la conmutación por fallas, que depende de los estados de HSRP en el dispositivo. El PIM-DR se ejecuta en el mismo gateway que el HSRP AR y mantiene los estados de ruta multicast.

En la Topología 1, HSRP se ejecuta hacia los clientes, por lo que aunque esta función suena como un ajuste perfecto, no puede ayudar en la convergencia de multidifusión. Configure esta función en 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 es ahora el PIM DR, y R3 ahora ve dos vecinos PIM en la interfaz 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 ahora tiene el S,G y puede ver que fue el ganador de Assert porque R3 fue previamente el reenviador multicast al segmento 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

¿Qué sucede cuando la interfaz LAN R2s deja de funcionar? ¿Puede R3 convertirse en el DR? ¿Y a qué velocidad puede converger?

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

HSRP cambia a activo en R3, pero la función PIM DR no converge hasta que el intervalo de consulta PIM ha caducado (3 saludos).

*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

Se pierden muchos paquetes mientras se produce la convergencia PIM:

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 es consciente de que PIM no ayudó realmente en esto. Es útil si utiliza la Topología 2 en su lugar:

Topology 2

Topología 2

El router R5 ha sido agregado y el receptor se encuentra detrás del R5 en su lugar. R5 no ejecuta ruteo con R2 y R3, solamente con puntos de ruta estáticos en el RP y el origen de multidifusión:

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

Sin PIM que reconozca HSRP, la verificación de Reverse Path Forwarding (RPF) falla porque PIM se compara con la dirección física, pero R5 ve tres vecinos en el segmento, donde uno es el 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 es el que reenvía la multidifusión en el momento de condiciones normales, ya que es el DR PIM a través del estado HSRP del router activo:

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

Pruebe un ping desde el origen:

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

El ping funciona y R2 tiene el 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

¿Qué sucede cuando falla 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....................................................................
......................................................................
............................................................

Los pings agotan el tiempo de espera porque cuando entra PIM Join desde R5, R3 no se da cuenta de que debe procesar 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

Como se ve, el comando de redundancia PIM debe configurarse también en el router secundario, para que procese las Uniones PIM al VIP.

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

Una vez configurado, se procesa la conexión entrante. R3 activa R5 para enviar un nuevo Join porque el GenID está configurado en el saludo PIM a un nuevo valor.

*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

Después de esta configuración, la función PIM DR converge tan rápido como HSRP lo permite. En este escenario se utiliza la detección de reenvío bidireccional (BFD).

Conclusión

El concepto clave para entender el PIM que reconoce HSRP aquí es que:

Inicialmente, la configuración de redundancia PIM en el AR lo convierte en el DR.
La redundancia PIM también se debe configurar en el router secundario; de lo contrario, no puede procesar las uniones PIM al VIP.
La función PIM DR no converge hasta que los saludos de PIM hayan agotado el tiempo de espera. El router secundario procesa las uniones, por lo que la multidifusión converge.