La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo documento descrive i problemi più comuni e le soluzioni per il multicast IP.
Nessun requisito specifico previsto per questo documento.
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Quando si risolvono i problemi relativi al routing multicast, il problema principale è l'indirizzo di origine. Il multicast prevede il controllo RPF (Reverse Path Forwarding). Quando un pacchetto multicast arriva a un'interfaccia, il processo RPF controlla che l'interfaccia in entrata sia quella in uscita usata dal routing unicast per raggiungere l'origine del pacchetto multicast. Questo processo di controllo RPF impedisce i loop. Il routing multicast inoltra un pacchetto solo se l'origine del pacchetto supera un controllo RPF. Una volta che un pacchetto ha superato il controllo RPF, il routing multicast inoltra il pacchetto solo in base all'indirizzo di destinazione.
Come il routing unicast, il routing multicast ha diversi protocolli disponibili, come la modalità IPM-DM (Protocol Independent Multicast Dense Mode), la modalità PIM sparse (PIM-SM), il protocollo DVMRP (Distance Vector Multicast Routing Protocol), il protocollo MBGP (Multicast Border Gateway Protocol) e l'MSDP (Multicast Source Discovery Protocol). I case study riportati in questo documento guidano l'utente attraverso il processo di risoluzione di vari problemi. È possibile visualizzare i comandi utilizzati per individuare rapidamente il problema e imparare a risolverlo. I casi di studio elencati di seguito sono generici nei vari protocolli, tranne dove indicato.
In questa sezione viene fornita una soluzione al problema comune relativo a un errore IP multicast di RPF. Questo diagramma di rete è utilizzato come esempio.
Esempio di errore di RPF multicast nel diagramma reticolare
In questa figura, i pacchetti multicast vengono inseriti nella E0/0 del router 75a da un server il cui indirizzo IP è 10.1.1.1 e vengono inviati al gruppo 224.1.1.1. Questo processo è noto come (S,G) o (10.1.1.1, 224.1.1.1).
Gli host connessi direttamente al router 75a ricevono il feed multicast, a differenza degli host connessi direttamente al router 72a. Immettere prima il comando show ip route per controllare l'attività sul router 75a. Questo comando esamina la route multicast (mroute) per l'indirizzo di gruppo 24.1.1.1:
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:01:23/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:01:23/00:00:00 (10.1.1.1, 224.1.1.1), 00:01:23/00:03:00, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
Poiché il router esegue la modalità PIM dense (si sa che è la modalità dense a causa del flag D), ignorare la voce *,G e attivare la voce S,G. Questa voce indica che i pacchetti multicast provengono da un server il cui indirizzo è 10.1.1.1, che invia a un gruppo multicast 24.1.1.1. I pacchetti entrano nell'interfaccia Ethernet0/0 e vengono inoltrati all'interfaccia Ethernet0/1. Questo è uno scenario perfetto.
Immettere show ip pim neighbor il comando per verificare se il router 72a visualizza il router upstream (75a) come router adiacente PIM:
ip22-72a#show ip pim neighbor
PIM Neighbor Table
Neighbor Address Interface Uptime Expires Ver Mode
10.2.1.1 Ethernet3/1 2d00h 00:01:15 v2
Dall'output del
show ip pim neighbor comando, il vicinato di PIM è buono.
Immettere il
show ip mroute comando per verificare se il router 72a dispone di un percorso valido:
ip22-72a#show ip mroute 224.1.1.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, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Dense, 00:10:42/00:00:00 Ethernet3/2, Forward/Dense, 00:10:42/00:00:00 (10.1.1.1, 224.1.1.1), 00:01:10/00:02:48, flags: Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Dense, 00:01:10/00:00:00 Ethernet3/2, Forward/Dense, 00:00:16/00:00:00 ip22-72a#
Il
show ip mroute 224.1.1.1 comando mostra che l'interfaccia in ingresso è Ethernet2/0, mentre è prevista Ethernet3/1.
Immettere il
show ip mroute 224.1.1.1 countcomando per verificare se il traffico multicast per questo gruppo arriva al router 72a e cosa succede dopo:
ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2032 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: 0, Packets received: 471 Source: 10.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0 ip22-72a#
Dagli Altri conteggi si evince che il traffico viene interrotto a causa di un errore RPF: 471 cadute totali, a causa di un errore RPF - 471...
Immettere il comando
show ip rpf <source> per verificare la presenza di un errore RPF:
ip22-72a#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet2/0 RPF neighbor: ? (0.0.0.0) RPF route/mask: 10.1.1.1/32 RPF type: unicast (static) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-72a#
Cisco IOS® calcola l'interfaccia RPF in questo modo. Le possibili origini delle informazioni RPF sono la tabella di routing Unicast, la tabella di routing MBGP, la tabella di routing DVMRP e la tabella di routing statica. Quando si calcola l'interfaccia RPF, viene utilizzata principalmente la distanza amministrativa per determinare esattamente su quale fonte di informazioni si basa il calcolo RPF. Le norme specifiche sono le seguenti:
-
Viene cercata una corrispondenza nell'indirizzo IP di origine per tutte le origini dati RPF precedenti. Quando si utilizzano strutture condivise, al posto dell'indirizzo di origine viene utilizzato l'indirizzo RP.
-
Se vengono individuate più route corrispondenti, viene utilizzata la route con la distanza amministrativa più bassa.
-
Se le distanze amministrative sono uguali, viene utilizzato l'ordine di preferenza seguente:
-
Route statiche
-
Route DVMRP
-
route MBGP
-
Route unicast
-
Se nella stessa tabella di route sono presenti più voci per una route, viene utilizzata la route con corrispondenza più lunga.
L'output del
show ip mroute 224.1.1.1 comando mostra che l'interfaccia RPF è E2/0, ma l'interfaccia in ingresso deve essere E3/1.
Immettere il
show ip mroute 224.1.1.1 comando per verificare perché l'interfaccia RPF è diversa da quella prevista.
ip22-72a#show ip route 10.1.1.1 Routing entry for 10.1.1.1/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Ethernet2/0 Route metric is 0, traffic share count is 1
Da questo output del comando show ip route 10.1.1.1 risulta una route statica /32 che rende l'interfaccia sbagliata da scegliere come interfaccia RPF.
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.
Router 75a
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
Router 75b
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
Revisione | Data di pubblicazione | Commenti |
---|---|---|
3.0 |
22-May-2024 |
Correzione dell'indirizzamento IP |
2.0 |
26-May-2023 |
Certificazione |
1.0 |
02-Dec-2013 |
Versione iniziale |