Risoluzione dei problemi della guida al multicast IP
Sommario
Introduzione
Questo documento descrive i problemi più comuni e le soluzioni per il multicast IP.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
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.
Premesse
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.
Il router non inoltra i pacchetti multicast all'host a causa di un errore RPF
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 inviati nella modalità E0/0 del router 75a da un server il cui indirizzo IP è 10.1.1.1 e vengono inviati al gruppo 10.224.1.1. Questo processo è noto come (S,G) o (10.1.1.1, 10.224.1.1).
Diagnosticare il problema
Gli host connessi direttamente al router 75a ricevono il feed multicast, a differenza degli host connessi direttamente al router 72a. Immettere innanzitutto il show ip mroute 224.1.1.1 per controllare l'attività sul router 75a. Questo comando esamina la route multicast (mroute) per l'indirizzo di gruppo 10.224.1.1:
75a#show ip mroute 10.224.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
(*, 10.224.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, 10.224.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 10.224.1.1. I pacchetti entrano nell'interfaccia Ethernet0/0 e vengono inoltrati all'interfaccia Ethernet0/1. Questo è uno scenario perfetto.
Immettere il show ip pim neighbor per verificare se il router 72a visualizza il router a monte (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
Dal show ip pim neighbor dell'output del comando, il vicinato di PIM è buono.
Immettere il show ip mroute per verificare se il router 72a dispone di un buon percorso:
ip22-72a#show ip mroute 10.224.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
(*, 10.224.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, 10.224.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#
È possibile visualizzare le immagini dalla show ip mroute 10.224.1.1 che l'interfaccia in ingresso è Ethernet2/0, mentre è previsto Ethernet3/1.
Immettere il show ip mroute 10.224.1.1 count per verificare se il traffico multicast di questo gruppo arriva al router 72a e cosa succede dopo:
ip22-72a#show ip mroute 10.224.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: 10.224.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 show ip rpf 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.
OSPF (Open Shortest Path First) show ip mroute 224.1.1.1 L'output del 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 per capire perché l'interfaccia RPF è diversa da quanto previsto.
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 10.224.1.1 *Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.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.
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 show ip mroute e debug ip mpacket sembra corretto, il numero di pacchetti inviati nel show ip mroute count e l'host A riceve i pacchetti.
ip22-72a#show ip mroute 10.224.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
(*, 10.224.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, 10.224.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 10.224.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: 10.224.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 10.224.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: 10.224.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 10.224.1.1
*Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.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. Osservare l'output del show ip mroute 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
(*, 10.224.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 10.224.0.40 nell'output poiché tutti i router si uniscono a questo gruppo di individuazione Auto-RP. Tuttavia, non sono elencate fonti per 10.224.1.1. Oltre a "*, 10.224.1.1" è possibile visualizzare "10.1.1.1, 10.224.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 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 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 10.224.1.1. È possibile controllare la versione con il comando 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 10.224.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2
La versione 10.224.1.1 è stata aggiunta alla versione E1/2, il che non è un problema.
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 si tratta di un problema di TTL con la cattura dello sniffer e se viene visualizzato anche con 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
(*, 10.224.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, 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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 assolutamente certi che il router 75a inoltri i pacchetti, attivare debug solo per questo gruppo di origine e 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 10.224.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=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied
OSPF (Open Shortest Path First) debug indica 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.
OSPF (Open Shortest Path First) ip multicast ttl-threshold
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 ip multicast ttl-threshold
utilizzando la forma no di questo comando, che ripristina il valore predefinito della soglia TTL, ossia 0, o diminuire la 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 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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.
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 comando show ip mroute per visualizzare la route multicast (mroute) per il gruppo:
ip22-75a#show ip mroute 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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 (*, 10.224.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.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
Cos'è accept-rp nella configurazione da eseguire? Nei comandi IP Multicast Routing, si legge che "per configurare un router in modo che accetti i join o le eliminazioni destinati a un determinato RP e a un elenco specifico di gruppi, utilizzare il comando ip pim accept-rp comando di configurazione globale. Per rimuovere il controllo, utilizzare la forma no di questo comando."
Quando si rimuove il ip pim accept-rp 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 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. Quindi, la pim accept-rp nella configurazione è errata.
Correzioni possibili
La soluzione è correggere l'indirizzo IP nel ip pim accept-rp così formulata:
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 10.224.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 10.224.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 10.224.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#
Il protocollo CGMP non impedisce l'aumento incontrollato dei pacchetti multicast
In questa sezione viene spiegato come evitare che i pacchetti multicast vengano trasmessi quando il protocollo CGMP (Cisco Group Management Protocol) non è abilitato su tutti i router di una subnet specifica. Questo diagramma di rete è utilizzato come esempio.
Protocollo CGMP (Cisco Group Management Protocol) non abilitato
Diagnosticare il problema
Nella figura, la tabella relativa alla CAM statica nello switch Catalyst 5000 A non mostra nessuna delle porte corrette popolate. Il router configurato con CGMP non invia pacchetti CGMP.
CGMP è configurato correttamente con set cgmp enable sullo switch A e sul ip cgmp sull'interfaccia E0/2 del router 75a. Tuttavia, sullo switch A non vengono visualizzati gruppi multicast quando show multicast group è stato emesso:
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- Total Number of Entries = 0
L'output di questo comando deve visualizzare ciascuna porta su cui è presente un router configurato con CGMP (porta 2/3) e ciascuna porta su cui è presente un ricevitore interessato (porta 2/6). Poiché nell'elenco è presente 0, è possibile presupporre che tutte le porte siano inutilmente inondate da traffico multicast, indipendentemente dal fatto che lo desiderino o meno.
Osservazioni
Verificare se esistono router 75a adiacenti PIM (Protocol Independent Multicast):
ip22-75a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 10.2.1.1 Ethernet0/2 00:07:41 00:01:34 v2
L'output mostrato come il router 75a sia in grado di vedere il router 75b come router adiacente PIM valido tramite lo switch A.
A questo punto, verificare di ricevere le informazioni corrette sulla route multicast (mroute) sui router:
ip22-75a#show ip mroute 10.224.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
(*, 10.224.1.1), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00
(10.1.1.1, 10.224.1.1), 00:14:56/00:02:59, flags: CTA
Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00
Il risultato mostra che il router 75a inoltra i pacchetti multicast in uscita E0/2 verso lo switch A. In questo output il router 75b ottiene i pacchetti multicast e li inoltra correttamente:
ip22-75b#show ip mroute 10.224.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
(*, 10.224.1.1), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00
Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00
(10.1.1.1, 10.224.1.1), 00:00:35/00:02:59, flags: CTA
Incoming interface: Ethernet1/3, RPF nbr 10.2.1.2
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00
Dal punto di vista dello switch A, il router 75a si trova fuori dalla porta 2/3.
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 Total Number of Entries = 1
Tutto quello che si è visto finora sembra andare bene. Immetti alcuni debug dei comandi sul router 75a per verificare cosa è possibile scoprire:
ip22-75a#debug ip cgmp CGMP debugging is on *Feb 8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:45:22.206: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:46:22.234: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:47:22.262: GDA 0000.0000.0000, USA 00d0.ff2f.a002
Nell'output, 0000.0000.0000 è l'indirizzo di tutti i gruppi e viene usato quando i router inviano messaggi di join/uscita CGMP in modo che gli switch possano popolare le porte del router. GDA è l'acronimo di Group Destination Address in Media Access Control (MAC) level format e USA è l'acronimo di Unicast Source Address. Questo è l'indirizzo dell'host che ha originato il report IGMP per il quale viene generato questo messaggio CGMP. In questo caso, è l'indirizzo MAC dell'interfaccia E0/2 del router 75a. L'indirizzo MAC per E0/2 del router 75a può essere visualizzato con il show interface comando come mostrato di seguito:
ip22-75a#show interface e0/2 Ethernet0/2 is up, line protocol is up Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)
È inoltre possibile visualizzare periodicamente questo messaggio quando debug ip igmp è attivato:
*Feb 8 12:51:41.854: IGMP: Received v2 Report from 10.2.1.3 (Ethernet0/2) for 10.224.1.1
Tuttavia, non sarà possibile visualizzare un pacchetto CGMP corrispondente proveniente dal router 75a. Ciò significa che il router 75a riceve i report IGMP, ma non genera i pacchetti CGMP necessari per aiutare lo switch A a conoscere le porte da bloccare. Si tratta di un comportamento previsto per il router 75a se si tratta del querier IGMP. Questo output del router 75a indica il motivo per cui il comportamento previsto non si verifica:
ip22-75a#show ip igmp interface e0/2 Ethernet0/2 is up, line protocol is up Internet address is 10.2.1.2/24 IGMP is enabled on interface Current IGMP version is 2 CGMP is enabled IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 3 joins, 1 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 10.2.1.2 (this system) IGMP querying router is 10.2.1.1 No multicast groups joined
Se si hanno due router sulla stessa subnet e si configurano entrambi per CGMP, solo uno può inviare pacchetti CGMP. Il router che invia i pacchetti CGMP è il protocollo IGMP che interroga il router. Questo messaggio indica il router con l'indirizzo IP unicast più basso dei router abilitati per IGMP.
In questo caso, entrambi i router 75a e 75b hanno il protocollo IGMP abilitato (il router 75b è diventato il router interrogante per IGMP), ma solo il router 75a ha il protocollo CGMP abilitato. Poiché il router 75a non è il router interrogante IGMP, non vengono inviati pacchetti CGMP.
Correzioni possibili
Per risolvere il problema, è necessario configurare il protocollo CGMP sul router di query IGMP. In questo caso, il router 75b. Prima di tutto, accendi debug comandi sul router 75b:
ip22-75b#conf t Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#int e 1/3 ip22-75b(config-if)#ip cgmp ip22-75b(config-if)#end ip22-75b#debug ip cgmp ip22-75b#debug ip igmp *Feb 8 12:58:42.422: IGMP: Received v2 Report from 10.2.1.3 (Ethernet1/3) for 10.224.1.1 *Feb 8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 *Feb 8 12:58:42.422: from 10.2.1.3 for 10.224.1.1 *Feb 8 12:58:42.422: CGMP: Sending Join on Ethernet1/3 *Feb 8 12:58:42.422: GDA 0100.5e01.0101, USA 0030.b655.a859
Il router 75b riceve un report IGMP dalla versione 10.2.1.3 per il gruppo 10.224.1.1. Successivamente, invia un join CGMP allo switch A per l'equivalente MAC di 10.224.1.1 con l'indirizzo MAC (Stati Uniti) dell'host 10.2.1.3 interessato. Lo switch A riconosce la porta su cui si trova l'host, quindi la contrassegna come aperta e blocca le altre.
A questo punto, è necessario utilizzare lo switch A:
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4,2/6 Total Number of Entries = 2
Questo è molto meglio. I pacchetti 10.224.1.1 (01-00-5e-01-01-01) vengono inviati solo alle porte 2/3, 2/4 e 2/6 sullo switch A, come previsto. Inondazione su tutte le altre porte interrotta. Il numero totale di voci è ora indicato correttamente come 2. L'indirizzo MAC 01-00-5e-00-01-28 è mappato dall'indirizzo multicast 224.0.1.40, che viene usato per i self join CGMP.
Il protocollo CGMP non impedisce il flooding di pacchetti multicast, a causa del posizionamento dell'origine/del ricevitore
In questa sezione viene fornita una soluzione al problema comune di uno switch Catalyst che trasferisce il traffico a tutte le porte, anziché solo all'host corretto. Questo diagramma di rete è utilizzato come esempio.
Switch Catalyst che trasferisce il traffico a tutte le porte
Diagnosticare il problema
Nella figura, i router 75a e 75b e Catalyst 5000 (switch A) sono configurati correttamente per multicast e CGMP (Cisco Group Management Protocol). L'host ottiene il traffico multicast. Tuttavia, lo stesso vale per tutti gli altri host dello switch A. Lo switch A inonda il traffico in tutte le porte, il che significa che il protocollo CGMP non funziona.
L'output del show multicast group Il comando sullo switch A ha il seguente aspetto:
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 Total Number of Entries = 1
Dall'output si può vedere che l'unico gruppo è 224.0.1.40, che viene utilizzato dal router quando invia i self-join CGMP per il gruppo auto-RP. Com'è possibile che non ci siano altri gruppi?
Correzioni possibili
Per comprendere la soluzione, è necessario capire come si comporta il protocollo CGMP in determinate condizioni. Un router abilitato per CGMP invia join CGMP a uno switch per informare lo switch degli host interessati a un particolare gruppo multicast. Lo switch cerca gli indirizzi MAC di questi host nella relativa tabella CAM, quindi inoltra i pacchetti multicast alle porte interessate e impedisce a tutte le altre porte di inoltrare i pacchetti multicast.
Un router invia i self-join CGMP all'interfaccia abilitata per CGMP se riceve pacchetti multicast da un'origine che si trova sulla stessa interfaccia su cui (il router) ha abilitato CGMP.
Ad esempio, se l'origine si trova sulla stessa subnet (VLAN), 10.2.1.0/24, dei router 75a e 75b, il protocollo CGMP funzionerà perfettamente. Quando il router identifica i pacchetti provenienti dall'origine, invia un self-join CGMP allo switch, che a sua volta scopre dinamicamente su quali porte si trova il router e blocca l'inoltro dei pacchetti multicast a tutte le altre porte.
Un router invia i join CGMP a un'interfaccia abilitata per CGMP se riceve i report IGMP da un host sulla stessa interfaccia su cui (il router) ha abilitato CGMP.
Un altro esempio si può verificare se un host interessato si trova sulla stessa VLAN. In questo caso, quando un router abilitato per CGMP riceve un report IGMP (Internet Group Management Protocol) da un host interessato a un particolare gruppo multicast, invia un join CGMP. Il join indica l'indirizzo MAC (Media Access Control) dell'host che si desidera unire e il gruppo a cui si desidera unire. Catalyst 5000 controlla quindi la tabella CAM per individuare l'indirizzo MAC dell'host, inserisce la porta associata nell'elenco dei gruppi multicast e blocca tutte le altre porte non interessate.
Lo stesso non si verifica quando gli host di origine e di interesse si trovano su una subnet diversa da quella abilitata per CGMP (VLAN). I pacchetti multicast, provenienti dall'origine, non fanno in modo che il router invii i self-join CGMP allo switch. Pertanto, i pacchetti colpiscono lo switch e vengono trasmessi ovunque all'interno della VLAN. Questo scenario continua finché un host nella VLAN, che esce da una porta sullo switch, non invia un join IGMP. Solo dopo aver ricevuto un report IGMP, il router invia un pacchetto CGMP, che a sua volta determina l'aggiunta da parte dello switch della porta host appropriata come porta di inoltro e il blocco di tutte le altre porte (escluse le porte del router).
Affinché CGMP funzioni nella topologia del tipo di transito, è possibile aggiungere un host alla stessa VLAN dei router 75a e 75b, come mostrato nel diagramma di rete.
Aggiunta di un host alla stessa VLAN dei router 75a e 75b
Oppure spostare l'origine sulla stessa subnet dei router 75a e 75b, come nell'esempio.
Spostare l'origine nella stessa subnet dei router 75a e 75b
Spostare l'origine nella stessa subnet e quindi controllare l'output dello switch A:
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 2/4 6 Total Number of Entries = 2 '*' - Configured Console> (enable) Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4 Total Number of Entries = 2
Il protocollo CGMP non impedisce il flooding di pacchetti multicast per alcuni indirizzi di gruppo
In questa sezione viene illustrato il motivo per cui alcuni indirizzi IP multicast causano l'inondazione del traffico multicast su tutte le porte di una rete LAN (Local Area Network) da parte del protocollo Cisco Group Management Protocol (CGMP). Quando si utilizza l'indirizzo del gruppo multicast 10.225.0.1, CGMP non funziona. Inonda il flusso multicast su tutte le porte dello switch e spreca la larghezza di banda. Tuttavia, se si modifica l'indirizzo in 10.225.1.1 CGMP funziona correttamente. È possibile utilizzare 10.225.0.1 perché non è un indirizzo registrato per un protocollo di routing?
Correzioni possibili
Innanzitutto, è importante comprendere come gli indirizzi multicast di livello 3 vengono mappati agli indirizzi multicast di livello 2. Tutti i frame IP multicast utilizzano indirizzi MAC IEEE che iniziano con il prefisso a 24 bit 0x0100.5e. Quando si esegue il mapping degli indirizzi dal layer 3 al layer 2, i 23 bit meno significativi dell'indirizzo multicast di layer 3 vengono mappati nei 23 bit meno significativi dell'indirizzo MAC IEEE.
Un altro fatto importante da comprendere è che esistono 28 bit di spazio di indirizzi univoco per un indirizzo IP multicast (32 bit meno i primi 4 bit che contengono il prefisso 1110 di classe D). Poiché ci sono solo 23 bit collegati all'indirizzo MAC IEEE, rimangono 5 bit di sovrapposizione. Ciò significa che più indirizzi multicast di livello 3 possono essere mappati allo stesso indirizzo multicast di livello 2.
Ad esempio:
10.244.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001 10.244.128.0 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001
Si noti che nell'esempio sia 10.244.0.1 che 10.244.128.0 sono mappati allo stesso indirizzo multicast di layer 2.
Ora che si conosce la modalità di mapping degli indirizzi multicast dal layer 3 al layer 2, passare alla soluzione specifica per il problema.
Lo switch A invia i pacchetti multicast a 224.0.0.x perché questi indirizzi sono locali del collegamento e si desidera essere certi che gli indirizzi locali del collegamento raggiungano tutti i dispositivi della rete locale (LAN). Gli switch Catalyst inoltrano inoltre i pacchetti multicast ad altri indirizzi multicast il cui livello MAC è ambiguo con 224.0.0.x (ad esempio, 10.244.0.1 e 10.225.0.1 mappano entrambi a 0100.5e00.0001). Lo switch invia i pacchetti multicast destinati a questi indirizzi locali del collegamento, anche se CGMP non è abilitato.
Pertanto, l'applicazione multicast deve evitare l'utilizzo di indirizzi di classe D mappati a un indirizzo multicast di layer 2 di 0100.5e00.00xx, dove xx può essere da 00 a FF in esadecimale. Si tratta dei seguenti indirizzi di classe D:
224.0.0.x (x = 0 to 255) 225.0.0.x . 239.0.0.x 224.128.0.x (x = 0 to 255) 225.128.0.x . 239.128.0.x
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 show interface
Switch#show interface gi 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
Quando si utilizza il ip igmp join-group
su qualsiasi interfaccia, elabora la 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 show buffers input-interface e controllare le dimensioni anomale.
Switch#show buffers input-interface gi 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 ip igmp static-group
al posto del comando ip igmp join-group
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
26-May-2023 |
Certificazione |
1.0 |
02-Dec-2013 |
Versione iniziale |
Feedback