Solución de problemas de PIM que Reconoce HSRP

Opciones de descarga

PDF (298.3 KB)
Visualice con Adobe Reader en una variedad de dispositivos
ePub (288.0 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (173.7 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

Introducción

Explicación

Conclusión

Eliminación de claves

Información Relacionada

Introducción

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

Explicación

En entornos que requieren redundancia para usted, HSRP se ejecuta normalmente. HSRP es un protocolo probado y funciona, pero ¿cómo se gestiona cuando tiene clientes que necesitan multicast? ¿Qué hace que la multidifusión converja 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 tener en cuenta aquí es que R3 es el PIM Designated Router (DR) aunque R2 sea el HSRP AR. La red se ha configurado con Open Shortest Path First (OSPF), PIM y R1 son el Punto de Encuentro (RP) con una dirección IP 10.1.1.1. Tanto R2 como R3 reciben informes de protocolo de administración de grupos de Internet (IGMP), pero sólo R3 envía la unión PIM, ya que es el DR PIM. 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

Luego, hace ping 239.0.0.1 desde el origen multicast para generar el 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

La S,G ha sido construida:

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 topología de unidifusión y multidifusión no es congruente actualmente. Esto puede o no 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 detecte que R3 se ha ido y se haga cargo del rol DR. Esto 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

El PIM que reconoce HSRP es una función que hace que el HSRP AR sea el PIM DR. También envía los mensajes PIM desde la IP virtual, lo que resulta ú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:

HSRP Aware PIM permite que el tráfico multicast se reenvíe a través del HSRP AR, permite que PIM aproveche la redundancia HSRP, evita el tráfico duplicado potencial y habilita la conmutación por fallas, que depende de los estados 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 dirige a los clientes, por lo que aunque esta función suene perfecta, 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 era anteriormente 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 de R2s se desactiva? ¿Puede R3 convertirse en el DR? ¿Y a qué velocidad converge?

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 haya caducado (tres 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

Perderá 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 sabe que PIM realmente no ayudó aquí. Es útil si utiliza la Topología 2 en su lugar:

Topology 2

Topología 2

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

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 con reconocimiento de HSRP, la verificación Reverse Path Forwarding (RPF) falla porque PIM se peers 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 multicast en el momento de las condiciones normales ya que es el PIM DR 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

Intente 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....................................................................
......................................................................
............................................................

El tiempo de espera de los pings se agota porque cuando entra la Unión PIM de R5, R3 no se da cuenta de que debe procesar la Unión.

*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

Resulta que el comando de redundancia PIM también se debe configurar en el router secundario para que procese las uniones PIM al VIP.

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

Después de que se haya configurado, se procesará la incorporación entrante. R3 activa R5 para enviar una nueva incorporación porque GenID se establece 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, el rol PIM DR converge tan rápido como HSRP lo permite. En esta situación se utiliza la detección de reenvío bidireccional (BFD).

Conclusión

El concepto clave para comprender 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 debe configurarse también 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 PIM hayan agotado el tiempo de espera. El router secundario procesa las uniones, por lo que la multidifusión converge.