Sommario

Introduzione

Spiegazione

Conclusioni

Eliminazione dei tasti

Informazioni correlate

Introduzione

In questo documento viene descritto come risolvere i problemi relativi alla funzionalità PIM (Protocol Independent Multicast) con supporto per HSRP (Hot Standby Router Protocol) e gli scenari in cui può essere utilizzata.

Spiegazione

Negli ambienti che richiedono ridondanza, HSRP funziona normalmente. HSRP è un protocollo collaudato che funziona, ma come si gestisce quando si dispone di client che richiedono il multicast? Che cosa attiva la convergenza del multicast quando il router attivo (AR) non è attivo? In questo caso, viene utilizzata la topologia 1:

Topologia 1

Una cosa da notare è che R3 è il PIM Designated Router (DR), anche se R2 è il HSRP AR. La rete è stata configurata con Open Shortest Path First (OSPF), PIM e R1 sono il Rendezvous Point (RP) con un indirizzo IP 10.1.1.1. Sia R2 che R3 ricevono rapporti IGMP (Internet Group Management Protocol), ma solo R3 invia l'aggiunta PIM in quanto si tratta di PIM DR. R3 genera '*,G' per 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

Eseguire quindi il ping 239.0.0.1 dall'origine multicast per compilare 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

S,G è stato costruito:

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 topologia unicast e multicast non è attualmente congruente. Questo può essere importante o meno. Cosa succede quando R3 fallisce?

R3(config)#int e0/2

R3(config-if)#sh

R3(config-if)#

Nessuna risposta ai ping arriva fino a quando PIM su R2 non rileva che R3 è andato e assume il ruolo di DR. Questa operazione richiede tra 60 e 90 secondi con i timer predefiniti in 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

È possibile aumentare la priorità di ripristino di emergenza in R2 in modo che diventi tale.

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 con riconoscimento HSRP è una funzionalità che rende HSRP AR il PIM DR. Inoltre, invia messaggi PIM dall'IP virtuale, il che è utile nelle situazioni in cui si dispone di un router con un percorso statico verso un IP virtuale (VIP). In questo modo Cisco descrive la funzione:

PIM compatibile con HSRP consente l'inoltro del traffico multicast tramite HSRP AR, consente a PIM di sfruttare la ridondanza HSRP, evita potenziali traffico duplicato e abilita il failover, che dipende dagli stati HSRP nel dispositivo. Il PIM-DR viene eseguito sullo stesso gateway dell'HSRP AR e mantiene gli stati del percorso.

Nella Topologia 1, HSRP viene eseguito verso i client, quindi anche se questa funzione sembra una perfetta integrazione, non può aiutare nella convergenza multicast. Configurare questa funzionalità in 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 è ora il PIM DR e R3 vede due PIM adiacenti sull'interfaccia 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 ora ha S,G e si può vedere che è stato il vincitore di Assert perché R3 era precedentemente il server di inoltro 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

Cosa succede quando l'interfaccia LAN di R2s non funziona? R3 può diventare il DR? E quanto velocemente può convergere?

R2(config)#int e0/2

R2(config-if)#sh

HSRP diventa attivo su R3, ma il ruolo DR PIM non converge fino alla scadenza dell'intervallo di query PIM (3x hellos).

*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

Durante la convergenza PIM si perdono molti pacchetti:

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 è consapevole che PIM non ha realmente aiutato qui. È utile se si utilizza invece la Topologia 2:

Topologia 2

È stato aggiunto il router R5 e il ricevitore si trova dietro R5. R5 non esegue il routing con R2 e R3, ma solo con i punti di routing statici all'RP e l'origine 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

Senza PIM compatibile con HSRP, il controllo RPF (Reverse Path Forwarding) non riesce perché i peer PIM con indirizzo fisico sono collegati, ma R5 rileva tre router adiacenti sul segmento, dove uno è il 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 inoltra il multicast al momento delle condizioni normali, in quanto è lo stato PIM DR via HSRP del router attivo:

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

Provare a eseguire il ping dall'origine:

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

Il ping funziona e R2 ha i caratteri 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

Cosa succede quando R2 non funziona?

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

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

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

Il ping scade perché quando arriva la giunzione PIM da R5, R3 non si rende conto che deve elaborare la giunzione.

*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

A quanto pare, il comando di ridondanza PIM deve essere configurato anche sul router secondario, per poter elaborare i join PIM al VIP.

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

Dopo la configurazione, il join in ingresso viene elaborato. R3 attiva R5 per l'invio di un nuovo join perché l'ID di generazione è impostato in PIM hello su un nuovo valore.

*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

Dopo questa configurazione, il ruolo DR PIM converge alla massima velocità consentita da HSRP. In questo scenario viene utilizzato il rilevamento dell'inoltro bidirezionale (BFD).

Conclusioni

Il concetto chiave per comprendere il PIM in grado di riconoscere HSRP è il seguente:

- Inizialmente, la configurazione di ridondanza PIM sul server AR lo rende il DR.

- La ridondanza PIM deve essere configurata anche sul router secondario, altrimenti non può elaborare i join PIM al VIP.

- Il ruolo DR PIM non converge fino al timeout degli hellos PIM. Il router secondario elabora i join in modo che il multicast converga.

Eliminazione dei tasti

Questa funzione non funziona se si dispone di un ricevitore su una LAN HSRP, in quanto il ruolo DR non viene spostato fino alla scadenza dell'adiacenza PIM.

Informazioni correlate

- 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

- Documentazione e supporto tecnico – Cisco Systems