Perché la modalità sparse PIM non funziona con un percorso statico a un indirizzo HSRP?

Introduzione

Questo documento spiega perché i pacchetti multicast non vengono inoltrati quando si configura una route statica all'indirizzo HSRP (Hot Standby Router Protocol) di un router adiacente in modalità sparse PIM (Protocol Independent Multicast).

Prerequisiti

Requisiti

Questo documento è utile per conoscere i seguenti argomenti:

• HSRP

• PIM modalità sparse

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Esempio di rete

Nella figura precedente, i router 2 e 3 comunicano con l'HSRP sulla subnet 10.1.3.0 e il router 2 è il router attivo. I router 1, 2 e 3 comunicano tra loro con il protocollo EIGRP (Enhanced Interior Gateway Routing Protocol) e il router 4 dispone di un percorso statico predefinito all'indirizzo virtuale dell'HSRP.

Configurazioni

Current configuration:

! 
ip multicast-routing 
! 
! 
interface Loopback0 
ip address 10.10.10.10 255.255.255.255 
no ip directed-broadcast 
! 
interface Ethernet0 
no ip address 
no ip directed-broadcast 
shutdown 
! 
interface Ethernet1 
ip address 10.1.1.1 255.255.255.0 
no ip directed-broadcast 
ip pim sparse-mode 
! 
interface Serial1 
no ip address 
no ip directed-broadcast 
encapsulation frame-relay 
! 
interface Serial1.1 point-to-point 
ip address 10.1.2.1 255.255.255.252 
no ip directed-broadcast 
ip pim sparse-mode 
frame-relay interface-dlci 612 
! 
! 
interface Serial1.2 point-to-point 
ip address 10.1.2.5 255.255.255.252 
no ip directed-broadcast 
ip pim sparse-mode 
frame-relay interface-dlci 613 
! 
router eigrp 1 
network 10.0.0.0 
no auto-summary 
! 
ip classless 
no ip http server 
ip pim rp-address 10.10.10.10 
! 

end

Current configuration:

! 
ip multicast-routing 
ip dvmrp route-limit 20000 
! 
! 
interface Ethernet1 
ip address 10.1.3.1 255.255.255.0 
no ip redirects 
ip pim sparse-mode 
standby 1 priority 110 preempt 
standby 1 ip 10.1.3.3 
! 
interface Serial1 
no ip address 
encapsulation frame-relay 
! 
interface Serial1.1 point-to-point 
ip address 10.1.2.2 255.255.255.252 
ip pim sparse-mode 
frame-relay interface-dlci 621 
! 
router eigrp 1 
network 10.0.0.0 
no auto-summary 
! 
ip classless 
ip pim rp-address 10.10.10.10 
!

end

Current configuration:

! 
ip multicast-routing 
ip dvmrp route-limit 20000 
! 
interface Ethernet1 
ip address 10.1.3.2 255.255.255.0 
no ip redirects 
ip pim sparse-mode 
standby 1 priority 100 preempt 
standby 1 ip 10.1.3.3 
! 
interface Serial1 
no ip address 
encapsulation frame-relay 
! 
interface Serial1.2 point-to-point 
ip address 10.1.2.6 255.255.255.252 
ip pim sparse-mode 
frame-relay interface-dlci 631 
! 
router eigrp 1 
network 10.0.0.0 
no auto-summary 
eigrp log-neighbor-changes 
! 
ip classless 
no ip http server 
ip pim rp-address 10.10.10.10 
!

end

Current configuration:

ip multicast-routing 
ip dvmrp route-limit 20000 
! 
! 
! 
interface Ethernet0 
ip address 10.1.4.1 255.255.255.0 
no ip directed-broadcast 
ip igmp join-group 239.1.2.3 
! 
interface Ethernet1 
ip address 10.1.3.4 255.255.255.0 
no ip directed-broadcast 
ip pim sparse-mode 
! 
no ip http server 
ip classless 
ip route 0.0.0.0 0.0.0.0 10.1.3.3 
ip pim rp-address 10.10.10.10 
!

end

Per simulare un host sull'interfaccia Ethernet 0, il comando ip igmp join-group è stato configurato su questa interfaccia sul router 4:

router4# ip igmp join-group 

IGMP Connected Group Membership 
Group Address Interface Uptime Expires Last Reporter 
224.0.1.40 Ethernet1 4d23h never 10.1.3.1 
239.1.2.3 Ethernet0 4d23h never 10.1.4.1 

Il router 4 può anche eseguire il ping dell'indirizzo del punto di rendering (RP):

Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/61/68 ms

Osservare la tabella delle route multicast (mroute):

Router4# show ip mroute 239.1.2.3 

IP Multicast Routing Table 

Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned 
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT 
X - Proxy Join Timer Running 

Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode 
(*, 239.1.2.3), 00:04:28/00:00:00, RP 10.10.10.10, flags: SJCL 
Incoming interface: Ethernet1, RPF nbr 10.1.3.3 
Outgoing interface list: 
Ethernet0, Forward/Sparse, 00:02:12/00:02:53 

Poiché esiste un ricevitore per questo gruppo (a causa del comando ip igmp join-group usato nel router 4), creare una voce (*,G) nella tabella mroute. Si noti che la voce RPF (Reverse Path Forwarding) adiacente per la voce (*,G) è 10.1.3.3, che è l'indirizzo di standby HSRP. Tuttavia, non è presente una voce (S,G), il che significa che il traffico non viene ricevuto dalla sorgente.

Poiché il router 4 ha un ricevitore interessato per il gruppo, ora deve inviare un messaggio di aggiunta/eliminazione PIM ai relativi vicini PIM. Utilizzare il comando show ip pim neighbors per visualizzare i router adiacenti PIM del router 4, come mostrato di seguito:

Router4# show ip pim neighbor 

PIM Neighbor Table 
Neighbor Address Interface Uptime Expires Ver Mode 
10.1.3.1 Ethernet1 4d23h 00:01:41 v2 
10.1.3.2 Ethernet1 4d23h 00:01:36 v2

Se il comando debug ip pim 239.1.2.3 è abilitato, il router 4 sta creando il messaggio di unione/eliminazione PIM, ma non lo invia:

*6 mar 18:32:48: PIM: Ricevuto RP-Raggiungibile su Ethernet1 da 10.10.10.10 *6 mar 18:32:48: per il gruppo 239.1.2.3 *Mar 6 18:33:14: PIM: Creazione del messaggio di unione/eliminazione per 239.1.2.3 *Mar 6 18:34:13: PIM: Creazione del messaggio di unione/eliminazione per 239.1.2.3

Perché il router non invia il messaggio di aggiunta/eliminazione? La RFC 2362 afferma che "un router invia un messaggio di join/eliminazione periodico a ogni singolo router adiacente RPF associato a ciascuna voce (S,G), (*,G) e (*,*,RP). I messaggi di unione/eliminazione vengono inviati solo se il router adiacente RPF è un router adiacente PIM."

Nell'esempio, il router adiacente RPF è 10.1.3.3, che è l'indirizzo di standby HSRP utilizzato dalla route statica predefinita. Tuttavia, questo indirizzo non è elencato come vicino PIM. Il motivo per cui l'indirizzo di standby dell'HSRP non è elencato come router adiacente PIM è che i due router che eseguono HSRP (router 2 e 3) non origineranno i messaggi dei router adiacenti PIM dall'indirizzo di standby dell'HSRP.

Per risolvere il problema, modificare la configurazione del router 4 in modo che anche il router adiacente RPF sia un router adiacente PIM. A tal fine, includere il router 4 nel processo EIGRP in modo che apprenda l'indirizzo RP tramite EIGRP.

Nota: poiché il router 4 è in grado di eseguire un protocollo di routing, non deve fare affidamento su un indirizzo in standby HSRP per la connettività. Lo sviluppo dell'HSRP è stato concepito per offrire agli host un modo per ottenere una ridondanza o un failover rapido ed efficiente.

Di seguito è riportata la nuova configurazione del router 4 con EIGRP abilitato.

ip multicast-routing 
ip dvmrp route-limit 20000 
! 
! 
! 
interface Ethernet0 
ip address 10.1.4.1 255.255.255.0 
no ip directed-broadcast 
ip igmp join-group 239.1.2.3 
! 
interface Ethernet1 
ip address 10.1.3.4 255.255.255.0 
no ip directed-broadcast 
ip pim sparse-mode 
!
router eigrp 1
network 10.0.0.0
no auto-summary
! 
no ip http server 
ip classless 
ip route 0.0.0.0 0.0.0.0 10.1.3.3 
ip pim rp-address 10.10.10.10 
!
end 

Nota: anziché includere il router 4 nel processo EIGRP (il metodo preferito), aggiungere le route statiche al router 4 per renderlo RPF agli indirizzi IP dei router veri e propri, in quanto le route sono preferite alla tabella di routing unicast nei controlli RPF. Ad esempio, aggiungere ip route 0.0.0.0 0.0.0 10.1.3.2.

Informazioni correlate

• Pagina di supporto per HSRP
• Pagina di supporto per i protocolli di routing IP
• Supporto tecnico – Cisco Systems