Contents

Introduction

Explicação

Conclusão

Conclusão chave

Informações Relacionadas

Introduction

Este documento descreve como solucionar problemas do recurso PIM (Hot Standby Router Protocol) e dos cenários em que ele pode ser usado.

Explicação

Em ambientes que exigem redundância para você, o HSRP é executado normalmente. O HSRP é um protocolo comprovado e funciona, mas como você lida quando tem clientes que precisam de multicast? O que aciona o multicast para convergir quando o roteador ativo (AR) é desativado? Nesse caso, a topologia 1 é usada:

Topologia 1

Uma coisa a ser observada aqui é que R3 é o PIM Designated Router (DR), mesmo que R2 seja o HSRP AR. A rede foi configurada com OSPF (Open Shortest Path First), PIM e R1 são o RP (Rendezvous Point) com um endereço IP 10.1.1.1. R2 e R3 recebem relatórios do Internet Group Management Protocol (IGMP), mas apenas R3 envia o PIM Join, pois é o PIM DR. R3 cria '*,G' em direção ao 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

Em seguida, faça ping em 239.0.0.1 a partir da origem multicast para criar o 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

O S,G foi construído:

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

A topologia unicast e multicast não é congruente no momento. Isso pode ou não pode ser importante. O que acontece quando R3 falha?

R3(config)#int e0/2

R3(config-if)#sh

R3(config-if)#

Nenhuma resposta aos pings entra até que o PIM em R2 detecte que R3 foi removido e assume a função de DR. Isso leva entre 60 e 90 segundos com os temporizadores padrão em 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

Você pode aumentar a prioridade do DR em R2 para torná-lo o 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

O PIM com reconhecimento de HSRP é um recurso que faz do HSRP AR o PIM DR. Ele também envia mensagens PIM do IP virtual, que é útil em situações em que você tem um roteador com uma rota estática para um IP virtual (VIP). É assim que a Cisco descreve o recurso:

O HSRP Aware PIM permite que o tráfego multicast seja encaminhado através do HSRP AR, permite que o PIM aproveite a redundância do HSRP, evite o tráfego duplicado potencial e habilite o failover, que depende dos estados do HSRP no dispositivo. O PIM-DR é executado no mesmo gateway que o HSRP AR e mantém estados de rota.

Na Topologia 1, o HSRP é executado em direção aos clientes, portanto, mesmo que esse recurso pareça um ajuste perfeito, ele não pode ajudar na convergência de multicast. Configure esse recurso em 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 agora é o PIM DR e R3 agora vê dois vizinhos PIM na 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 agora tem o S,G e você pode ver que ele foi o vencedor do Assert porque R3 era anteriormente o encaminhador multicast para o segmento de 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

O que acontece quando a interface de LAN do R2s é desativada? R3 pode se tornar o DR? E quão rápido pode convergir?

R2(config)#int e0/2

R2(config-if)#sh

O HSRP é alterado para ativo em R3, mas a função PIM DR não é convergida até que o intervalo de consulta PIM tenha expirado (3x saudações).

*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

Você perde muitos pacotes enquanto a convergência de PIM acontece:

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

O HSRP sabe que o PIM não ajudou muito aqui. É útil se você usar a topologia 2 em vez disso:

Topologia 2

O roteador R5 foi adicionado e o receptor fica atrás de R5. R5 não executa o roteamento com R2 e R3, somente com pontos de rota estática no RP e na origem de 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

Sem o PIM sensível ao HSRP, a verificação de RPF (Reverse Path Forwarding) falha porque os pares PIM com o endereço físico, mas R5 vê três vizinhos no segmento, onde um é o 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 é o que encaminha multicast no momento das condições normais, pois é o PIM DR através do estado HSRP do roteador ativo:

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

Tente um ping da origem:

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

O ping funciona e R2 tem o 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

O que acontece quando R2 falha?

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

......................................................................

............................................................

O tempo limite dos pings é porque quando o PIM Join de R5 entra, R3 não percebe que deve processar o 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 resultado, o comando PIM redundancy também deve ser configurado no roteador secundário para que ele processe PIM Joins para o VIP.

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

Depois que isso for configurado, a União de entrada será processada. R3 aciona R5 para enviar um novo Join porque o GenID está definido no PIM hello como um novo 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

Após essa configuração, a função PIM DR converge tão rápido quanto o HSRP permite. A detecção de encaminhamento bidirecional (BFD) é usada nesse cenário.

Conclusão

O conceito principal para entender o PIM sensível ao HSRP aqui é que:

- Inicialmente, a configuração de redundância de PIM no AR o torna o DR.

- A redundância de PIM também deve ser configurada no roteador secundário, caso contrário, não poderá processar PIM Joins para o VIP.

- A função PIM DR não é convergida até que os hellos do PIM tenham atingido o tempo limite. O roteador secundário processa as junções, de modo que o multicast converge.

Conclusão chave

Este recurso não funciona quando você tem um receptor em uma LAN HSRP, porque a função DR não é movida até que a adjacência de PIM expire.

Informações Relacionadas

- 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

- Suporte Técnico e Documentação - Cisco Systems