Risoluzione dei problemi della guida al multicast IP

Immettere altri comandi di debug:

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface

I pacchetti arrivano su E3/1, il che è corretto. Tuttavia, vengono eliminate perché non è l'interfaccia utilizzata dalla tabella di routing unicast per il controllo RPF.

Nota: il debug dei pacchetti è pericoloso. Il debug dei pacchetti attiva la commutazione di processo dei pacchetti multicast, che richiede un utilizzo intensivo della CPU. Inoltre, il debug dei pacchetti può produrre un output enorme che può bloccare completamente il router a causa dell'output lento sulla porta della console. Prima di eseguire il debug dei pacchetti, occorre procedere con molta cautela per disabilitare l'output di registrazione sulla console e abilitare la registrazione sul buffer di memoria. A tale scopo, configurare nessuna console di registrazione e debug con buffer di registrazione. I risultati del debug possono essere visualizzati con il comando show logging.

Correzioni possibili

È possibile modificare la tabella di routing unicast per soddisfare questo requisito oppure aggiungere una route statica per forzare il multicast a utilizzare una determinata interfaccia, indipendentemente dallo stato della tabella di routing unicast. Aggiungere una route statica:

ip22-72a(config)#ip mroute 10.1.1.1 255.255.255.255 10.2.1.1

Questo percorso statico indica che per raggiungere l'indirizzo 10.1.1.1 per RPF, usare 10.2.1.1 come hop successivo nell'interfaccia E3/1.

ip22-72a#show ip rpf 10.1.1.1 
RPF information for ? (10.1.1.1) 
  RPF interface: Ethernet3/1 
  RPF neighbor: ? (10.2.1.1) 
  RPF route/mask: 10.1.1.1/32 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

L'output di eshow ip mroute debug ip mpacket ha un buon aspetto, il numero di pacchetti inviati nelshow ip mroute count pacchetto aumenta e l'host A riceve i pacchetti.

ip22-72a#show ip mroute 224.1.1.1 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 M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 (10.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA Incoming interface: Ethernet3/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019 Source: 10.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026 Source: 10.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0 ip22-72a# ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward

Il router non inoltra i pacchetti multicast all'host a causa dell'impostazione TTL dell'origine

In questa sezione viene fornita una soluzione al problema comune dei pacchetti IP multicast che non vengono inoltrati perché il valore TTL (Time To Live) viene ridotto a zero. Si tratta di un problema comune, in quanto esistono molte applicazioni multicast. Queste applicazioni multicast sono progettate principalmente per l'uso LAN, quindi impostare il valore TTL su un valore basso o anche su 1. Utilizzare questo diagramma di rete come esempio. 

Applicazioni multicast progettate principalmente per l'utilizzo LAN

Diagnosticare il problema

Nella figura precedente, il router A non inoltra i pacchetti dalle origini al router B collegato direttamente al ricevitore. Controllare l'output del comando   show ip mroute  sul router A per verificare lo stato del routing multicast:

ROUTERA#show ip mroute 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 M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00 (*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00 

È possibile ignorare la versione 24.0.1.40 nell'output poiché tutti i router si uniscono a questo gruppo di rilevamento Auto-RP. Ma non esiste nessuna fonte elencata per 24.1.1.1. Oltre a "*, 224.1.1.1" non è possibile visualizzare "10.1.1.1, 224.1.1.1".

Immettere il comando show ip rpf per verificare se è un problema di RPF:

ROUTERA#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 10.1.1.1/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables 

Dall'output, non si tratta di un problema RPF. Il controllo RPF indica correttamente E0/0 per raggiungere l'indirizzo IP di origine.

Controllare se PIM è configurato sulle interfacce con il show ip pim interface comando:

ROUTERA#show ip pim interface Address Interface Version/Mode Nbr Query DR Count Intvl 10.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 10.1.1.2 10.2.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 10.2.1.2 

L'output è buono, quindi non è questo il problema. Verificare se il router riconosce il traffico attivo con il show ip mroute active comando:

ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps 

In base all'output, il router non riconosce alcun traffico attivo.

ROUTERA#debug ip mpacket IP multicast packets debugging is on 

È possibile che il ricevitore non invii alcun rapporto IGMP (Internet Group Management Protocol) (join) per il gruppo 24.1.1.1. Per verificarlo, usare il show ip igmp group  comando:

ROUTERB#show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet1/1 00:34:34 never 10.2.1.2 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2 

224.1.1.1 è stato aggiunto a E1/2, il che va bene.

La modalità PIM dense è un protocollo flood and prune, quindi non ci sono join, ma ci sono innesti. Poiché il router B non ha ricevuto un'inondazione dal router A, non sa dove inviare un trapianto.

È possibile verificare se è un problema di TTL con lo sniffer capture e se viene visualizzato anche con il show ip traffic  comando:

ROUTERA#show ip traffic IP statistics: Rcvd: 248756 total, 1185 local destination 0 format errors, 0 checksum errors, 63744 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 0 with options 

L'output mostra 63744 conteggi di hop errati. Ogni volta che si digita questo comando, il numero di hop errati aumenta. Ciò è una forte indicazione che il mittente invia pacchetti con un TTL=1, che il router A riduce a zero. Il risultato è un aumento del campo del numero di hop errati.

Correzioni possibili

Per risolvere il problema, è necessario aumentare il valore TTL. Questa operazione viene eseguita a livello di applicazione nel mittente. Per ulteriori informazioni, consultare il manuale di istruzioni dell'applicazione multicast.

Al termine, il router A avrà il seguente aspetto:

ROUTERA#show ip mroute 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 M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00 (*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00 (10.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00 

Questo è il tipo di output che si desidera visualizzare.

Sul router B viene visualizzato:

ROUTERB#show ip mroute 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 M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00 (*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00 (10.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1 Outgoing interface list: Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00

Il router non inoltra i pacchetti multicast a causa della soglia TTL del router

In questa sezione viene fornita una soluzione al problema comune quando la soglia TTL è impostata su un valore troppo basso, in modo che il traffico multicast IP non raggiunga il destinatario. Questo diagramma di rete è utilizzato come esempio.

La soglia TTL è troppo bassa, il traffico multicast IP non raggiunge il ricevitore

Diagnosticare il problema

Nella figura precedente, il ricevitore non riceve pacchetti multicast dall'origine. Tra l'origine e il router 75a possono essere presenti diversi router. Esaminare anzitutto il router 75a, poiché è collegato direttamente al ricevitore.

ip22-75a#show ip mroute 224.1.1.1 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 M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00 (10.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00 

L'output mostrato come il router 75a inoltra i pacchetti Ethernet 0/1. Per essere certi che il router 75a inoltri i pacchetti, accenderlo debug solo per questa origine e gruppo multicast:

ip22-75a#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 10.1.1.1 host 224.1.1.1 ip22-75a(config)#end ip22-75a#debug ip mpacket 101 IP multicast packets debugging is on for access list 101 ip22-75a# *Jan 17 09:04:08.714: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

I debug messaggi indicano che il router 75a non inoltra i pacchetti multicast perché è stata raggiunta la soglia TTL. Esaminare la configurazione del router per individuare la causa. Questo output mostra i colpevoli:

interface Ethernet0/1 ip address 10.2.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15 

Il router ha una soglia TTL di 15, ma ciò non significa che non venga inviato alcun messaggio superiore a un TTL di 15. In realtà, è vero il contrario. L'applicazione viene inviata con un valore TTL di 15. Quando si raggiunge il router 75a, i pacchetti multicast hanno un valore TTL inferiore a 15.

Il comandoip multicast ttl-threshold <value> indica che i pacchetti con un valore TTL inferiore alla soglia specificata, in questo caso 15, non vengono inoltrati. Questo comando è in genere utilizzato per creare un bordo che impedisca al traffico multicast interno di uscire dalla rete Intranet.

Correzioni possibili

Rimuovere il comandoip multicast ttl-threshold <value> con la forma no di questo comando, che ripristina il valore predefinito del valore di soglia TTL, 0, o abbassare il valore di soglia TTL in modo che il traffico possa passare.

Più percorsi costo uguali determinano un comportamento RPF indesiderato

Questa sezione illustra come i percorsi di costo uguali a un'origine multicast possono causare un comportamento RPF indesiderato. Descrive anche come configurare il multicast IP per evitare questo comportamento. Questo diagramma di rete è utilizzato come esempio.

L'uguaglianza dei percorsi di costo per un'origine multicast provoca un comportamento RPF indesiderato

Diagnosticare il problema

Nella figura, il router 75b ha tre percorsi di costo uguali per tornare all'origine (10.1.1.1) e sceglie un collegamento che non si desidera diventi la sua prima scelta come collegamento RPF.

Quando si trovano di fronte a più percorsi di costo uguali verso un'origine, il multicast IP sceglie come interfaccia in ingresso l'interfaccia che ha un router adiacente Protocol Independent Multicast (PIM) con l'indirizzo IP più alto e quindi invia le prugne ai vicini PIM sugli altri collegamenti.

Correzioni possibili

Per modificare l'interfaccia scelta dal multicast IP come interfaccia in ingresso, è possibile effettuare una delle seguenti operazioni:

• Configurare PIM solo sulle interfacce che si desidera attraversare tramite multicast, perdendo così la ridondanza multicast.

• Modificare le subnet in modo che l'indirizzo IP più alto si trovi sul collegamento che si desidera diventi il collegamento multicast primario.

• Creare una route multicast statica (mroute) che indichi l'interfaccia multicast preferita, perdendo la ridondanza multicast.

Ad esempio, viene creata una route statica.

Prima di installare una route statica, si noterà in questo output che la tabella di routing dispone di tre route con costo uguale per l'indirizzo di origine 10.1.1.1. Le informazioni RPF indicano che l'interfaccia RPF è E1/3:

ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/3 RPF neighbor: ? (10.4.1.1) RPF route/mask: 10.1.1.1/24 RPF type: unicast (ospf 1) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip mroute 224.1.1.1 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 M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00 (10.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT Incoming interface: Ethernet1/3, RPF nbr 10.4.1.1 Outgoing interface list: Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32 Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42 

Dopo aver configurato la route statica, in questo output l'interfaccia RPF è stata modificata in E1/1:

ip22-75b#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 10.2.1.1 ip22-75b(config)#end ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/1 RPF neighbor: ? (10.2.1.1) RPF route/mask: 10.1.1.1/0 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip mroute 224.1.1.1 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 M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00 (10.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47 Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28

Perché IP Multicast Non Bilancia Il Carico Su Tutti I Percorsi Uguali Disponibili?

In questa sezione viene fornita una soluzione al problema comune di come configurare il multicast IP per bilanciare il carico su tutti i percorsi disponibili con pari costo. Questo diagramma di rete è utilizzato come esempio.

Nota: prima di caricare il traffico multicast IP suddiviso su percorsi a costo uguale su un tunnel, configurare il bilanciamento del carico CEF per pacchetto altrimenti i pacchetti GRE non potranno essere bilanciati dal carico per pacchetto. Per altri metodi di caricamento della condivisione in ambienti multicast, vedere Caricamento del traffico multicast IP su ECMP.

Configurazione del multicast IP per il bilanciamento del carico su tutti i percorsi pari costo disponibili

Nella figura, il router 75b ha tre percorsi uguali all'origine (10.1.1.1). Si desidera bilanciare il carico del traffico multicast su tutti e tre i collegamenti.

Correzioni possibili

Come illustrato nella sezione Più percorsi costo uguali per il comportamento di RPF indesiderato, la funzionalità PIM (Protocol Independent Multicast) sceglie solo un'interfaccia per il controllo di RPF e elimina le altre. Ciò significa che non viene eseguito il bilanciamento del carico. Per bilanciare il carico, è necessario rimuovere il PIM dai collegamenti ridondanti e creare un tunnel tra il router 75a e il router 75b. È quindi possibile bilanciare il carico a livello di collegamento e l'indirizzo IP viene eseguito sul tunnel.

Ecco le configurazioni del tunnel.

interface Tunnel0 
 ip address 10.6.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet0/0 
 tunnel destination 10.5.1.1 
! 
interface Ethernet0/0 
 ip address 10.1.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
! 
interface Ethernet0/1 
 ip address 10.2.1.1 255.255.255.0 
! 
interface Ethernet0/2 
 ip address 10.3.1.1 255.255.255.0 
! 
interface Ethernet0/3 
 ip address 10.4.1.1 255.255.255.0

interface Tunnel0 
 ip address 10.6.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet1/4 
 tunnel destination 10.1.1.2 
! 
interface Ethernet1/1 
 ip address 10.2.1.2 255.255.255.0 
! 
interface Ethernet1/2 
 ip address 10.3.1.2 255.255.255.0 
! 
interface Ethernet1/3 
 ip address 10.4.1.2 255.255.255.0 
! 
interface Ethernet1/4 
 ip address 10.5.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
! 
ip mroute 0.0.0.0 0.0.0.0 Tunnel0

Dopo aver configurato il tunnel, immettere il comandoshow ip mroute per visualizzare il percorso multicast (mroute) del gruppo:

ip22-75a#show ip mroute 224.1.1.1 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 M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 (10.1.1.1, 224.1.1.1), 02:40:32/00:03:29, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 ip22-75b#show ip mroute 224.1.1.1 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 M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00 Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00 (10.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT Incoming interface: Tunnel0, RPF nbr 10.6.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00 

Per verificare che il bilanciamento del carico dei dati multicast sia uniforme tra i tre collegamenti, esaminare i dati dell'interfaccia del router 75a.

L'interfaccia in ingresso è 9000 bit/sec:

ip22-75a#show interface e0/0 . . 5 minute input rate 9000 bits/sec, 20 packets/sec 

Le tre interfacce in uscita mostrano ciascuna 3000 bit/sec:

ip22-75a#show interface e0/1 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/2 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/3 . . 5 minute output rate 3000 bits/sec, 7 packets/sec

Quando si ricevono i messaggi di errore IP Multicast "INVALID_RP_JOIN" sul router

In questa sezione vengono fornite le soluzioni al problema comune del messaggio di errore IP multicast "INVALID_RP_JOIN".

Diagnosticare il problema - Parte 1

Questo messaggio di errore viene ricevuto sul punto di rendering (RP):

00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 

Il documento Messaggi di errore di sistema del software Cisco IOS spiega la causa di questo errore: un router PIM downstream ha inviato un messaggio di join per la struttura condivisa che questo router non desidera accettare. Questo comportamento indica che questo router consente solo l'aggiunta di router a valle a un RP specifico.

Si sospetta che stia filtrando. Esaminare la configurazione del router:

interface Ethernet0/0 ip address 10.1.5.4 255.255.255.0 ip pim sparse-dense-mode ! ip pim accept-rp 10.2.2.2 8 ip pim send-rp-announce Ethernet0/0 scope 15 ip pim send-rp-discovery scope 15 ! access-list 8 permit 224.0.0.0 0.255.255.255 

Qual è l' accept-rp  istruzione da eseguire nella configurazione? Nei comandi di routing multicast IP, si afferma che "per configurare un router in modo che accetti join o eliminazioni destinati a un determinato RP e a un elenco specifico di gruppi, utilizzare il comando di configurazione globaleip pim accept-rp. Per rimuovere il controllo, utilizzare la forma no di questo comando."

Quando si rimuove il ip pim accept-rp comando, i messaggi scompaiono. È stato trovato il comando che ha causato il problema, ma se si desidera mantenere tale comando nella configurazione? È possibile autorizzare l'indirizzo RP errato. Immettere il show ip pim rp mapping  comando per visualizzare l'indirizzo RP corretto:

ip22-75a#show ip pim rp mapping PIM Group-to-RP Mappings This system is an RP (Auto-RP) This system is an RP-mapping agent Group(s) 224.0.0.0/4 RP 10.1.5.4 (?), v2v1 Info source: 10.1.5.4 (?), via Auto-RP Uptime: 01:00:48, expires: 00:02:07

In base all'output, 10.1.5.4 è l'unico RP appreso tramite Auto-RP o altrimenti. Tuttavia, questo router è solo l'RP per i gruppi 224.0.0.0/4. L'istruzione nella pim accept-rp configurazione è errata.

Correzioni possibili

La soluzione consiste nel correggere l'indirizzo IP nel ip pim accept-rp seguente modo:

Modificare l'istruzione:

ip pim accept-rp 10.2.2.2 8

A questo:

ip pim accept-rp 10.1.5.4 8

È inoltre possibile modificare l'istruzione in modo da accettare il contenuto della cache rp automatica e assicurarsi che l'elenco degli accessi (8 in questo esempio) consenta l'intervallo di gruppi multicast necessario. Ecco un esempio:

ip pim accept-rp auto-rp access-list 8 permit 224.0.0.0 0.255.255.255

Diagnosticare il problema - Parte 2

Questo messaggio di errore viene visualizzato sul router2.

router2# *Aug 12 15:18:17.891: %PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40) Join from 0.0.0.0 for invalid RP 10.2.1.1

Verificare se router2 è l'RP per il gruppo 24.1.1.1:

router2#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:21:26, expires: 00:02:24 router2#

L'RP per 24.1.1.1 è 10.1.1.1.

Verificare se si tratta di una delle interfacce del router2:

router2#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.1.1.2 YES NVRAM up up Ethernet1/0 10.2.1.1 YES NVRAM up up Ethernet2/0 unassigned YES NVRAM administratively down down router2#

Poiché il router2 non è un RP, non deve aver ricevuto questo pacchetto RP-Join. Verificare il motivo per cui il router downstream ha inviato il join al router2, mentre non deve:

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:24:30, expires: 00:02:16 Group(s): 224.0.0.0/4, Static-Override RP: 10.2.1.1 (?) router3#

Come si può vedere, il router3 ha configurato staticamente le informazioni RP e punta al router2, il che non è corretto. Questo spiega perché il router3 invia l'RP-Join al router2.

Correzioni possibili

Rendere il router2 l'RP per il gruppo 24.1.1.1 o modificare la configurazione sul router3 in modo che faccia riferimento all'indirizzo RP corretto.

router3#show run | i rp ip pim rp-address 10.2.1.1 override router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router3(config)#no ip pim rp-address 10.2.1.1 override router3(config)#exit router3#

Dopo aver corretto la configurazione sul router3, il router3 fa riferimento all'indirizzo RP corretto e il messaggio di errore si arresta.

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:30:45, expires: 00:02:02 router3#

Ricevuti flussi di pacchetti multicast duplicati

Causa 1

I pacchetti multicast duplicati vengono ricevuti quando due router sono configurati in modalità densa. In modalità densa, il dispositivo inonda periodicamente il flusso. Dopo l'allagamento, potatura le interfacce dove il vapore non è desiderato. Anche i due router seguono il processo di asserzione e decidono chi è il server d'inoltro. Ogni volta che i timer scendono, si verifica un errore e finché il processo non è completato, entrambi i router inoltrano lo streaming. In questo modo l'applicazione riceve flussi multicast duplicati.

Possibile soluzione 1

Per risolvere il problema, è possibile usare uno dei router configurati per il routing multicast e configurare l'altro router come router upstream. Configurare il flusso in modo da convertire il flusso in modalità sparse prima che entri nel router. In questo modo è possibile evitare che i pacchetti duplicati raggiungano l'applicazione. Accertarsi che nessun pacchetto duplicato raggiunga mai l'host finale non fa parte della responsabilità della rete. La gestione dei pacchetti duplicati e l'ignoramento dei dati non necessari sono responsabilità dell'applicazione.

Causa 2

Questo problema può verificarsi sugli switch Cisco Catalyst 6500, configurati per la modalità di replica multicast in uscita, e può essere attivato dalla rimozione e dal reinserimento di qualsiasi scheda di linea [OIR]. Dopo la trasmissione a infrarossi, la porta di uscita del fabric [FPOE] può essere programmata in modo errato, il che può causare il reindirizzamento dei pacchetti al canale di uscita del fabric errato e l'invio alle schede di linea errate. Il risultato è che vengono rimandati indietro al fabric e replicati più volte quando vengono rilasciati sulla scheda di linea corretta.

C6509#show mls ip multicast capability Current mode of replication is Egress Auto replication mode detection is ON Slot Multicast replication capability 1 Egress 2 Egress 3 Egress 4 Egress 5 Egress 6 Egress 7 Egress

Possibile soluzione 2

Per ovviare al problema, passare alla modalità di replica in ingresso. Durante il passaggio dalla modalità di replica in uscita a quella in entrata, possono verificarsi interruzioni del traffico in quanto i collegamenti vengono eliminati e reinstallati.

mls ip multicast replication-mode ingress 

Per risolvere definitivamente il problema, aggiornare il software Cisco IOS a una versione non interessata dall'ID bug Cisco CSCeg28814.

Nota: solo gli utenti Cisco registrati possono accedere agli strumenti Cisco interni e alle informazioni sui bug.

Causa 3

Questo problema può verificarsi anche se l'impostazione RSS (Receive Side Scaling) sugli host finali o sui server è disabilitata.

Possibile soluzione 3

L'impostazione RSS semplifica la trasmissione più rapida dei dati su più CPU. Abilitare l'impostazione RSS sull'host finale o sul server.

Perché i pacchetti multicast vengono scartati?

Causa 1

È possibile che si verifichino scaricamenti eccessivi e le perdite di pacchetti di input sulle interfacce quando il traffico multicast scorre. È possibile controllare gli svuotamenti con il show interface comando.

Switch#show interface gigabitethernet 1/0 !--- Output suppressed MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX input flow-control is off, output flow-control is on Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 2/75/0/13370328 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 195000 bits/sec, 85 packets/sec 30 second output rate 1000 bits/sec, 1 packets/sec L2 Switched: ucast: 53056 pkt, 4728434 bytes - mcast: 235759386 pkt, 66914376970 bytes L3 in Switched: ucast: 8714263 pkt, 1815426423 bytes - mcast: 1081138213 pkt,
 438000092206 bytes mcast L3 out Switched: ucast: 4939256 pkt, 790351689 bytes mcast: 0 pkt, 0 bytes 1326976857 packets input, 506833655045 bytes, 0 no buffer Received 1318209538 broadcasts, 0 runts, 0 giants, 1 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 31643944 packets output, 3124494549 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out

Possibile soluzione 1

È possibile impostare il valore SPT su infinito per l'interfaccia in cui vengono rilevati gli scarichi eccessivi.

Configurare:

Switch(config-if)#ip pim spt-threshold infinity 

Causa 2

Il comandoip igmp join-group <group-name> utilizzato su una o più interfacce non comporta il processo di commutazione. Se i pacchetti multicast vengono elaborati su una o più interfacce, consuma più CPU in quanto impone la commutazione di tutti i pacchetti a quel gruppo. È possibile eseguire il show buffers input-interface comando e verificare le dimensioni anomale.

Switch#show buffers input-interface gigabitethernet 1/0 Header DataArea Pool Rcnt Size Link Enc Flags Input Output 437C6EAC 8096AE4 Middl 1 434 7 1 280 Gi1/1 None 437C74B4 8097864 Middl 1 298 7 1 280 Gi1/1 None 437C98E4 809C964 Middl 1 434 7 1 280 Gi1/1 None 437CAAFC 809F1E4 Middl 1 349 7 1 280 Gi1/1 None 437CAE00 809F8A4 Middl 1 519 7 1 280 Gi1/1 None !--- Output suppressed 

Possibile soluzione 2

È possibile utilizzare il comandoip igmp static-group <group-name> anziché il ip igmp join-group <group-name> comando.

Nota: a causa di problemi precedenti, è possibile che l'utilizzo elevato della CPU si aggiri intorno al 90%. La CPU diventa normale quando viene risolta con queste possibili correzioni.

Informazioni correlate

• Risoluzione dei problemi relativi alle reti multicast con gli strumenti CLI
• Guida rapida alla configurazione del multicast

• Abilitazione della divisione del carico multicast ECMP 

• Supporto della tecnologia IP Multicast
• Supporto protocolli di routing IP
• Supporto tecnico e download Cisco