Questo documento deve essere utilizzato come guida per la risoluzione dei problemi di routing IP unicast sugli switch Catalyst 6500/6000 con Supervisor Engine 2, Policy Feature Card 2 (PFC2), Multilayer Switch Feature Card 2 (MSFC2). Il routing unicast su Supervisor Engine 2 viene eseguito utilizzando Cisco Express Forwarding (CEF). Questo documento riguarda solo il routing IP sugli switch Catalyst serie 6500/6000 dotati di Supervisor Engine 2, PFC2, MSFC2. Il presente documento non è valido per uno switch Catalyst 6500/6000 con Supervisor Engine 1 (o 1A) o per il modulo Multilayer Switch (MSM). Questo documento è valido solo per gli switch con software di sistema Catalyst OS (CatOS) sul Supervisor Engine e non per il software di sistema Cisco IOS®.
Nessun requisito specifico previsto per questo documento.
Il documento può essere consultato per tutte le versioni software o hardware.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
CEF era originariamente una tecnica di commutazione software di Cisco IOS progettata per indirizzare i pacchetti più rapidamente. Il CEF è molto più scalabile della commutazione veloce. (non è necessario inviare il primo pacchetto per la commutazione di contesto.) Catalyst 6500 con Supervisor Engine 2 utilizza un meccanismo di inoltro CEF basato su hardware implementato sul PFC2. CEF utilizza principalmente due tabelle per memorizzare le informazioni necessarie per il routing: la base di informazioni per l'inoltro (FIB) e la tabella adiacente.
Il CEF utilizza un FIB per prendere decisioni di switching basate sul prefisso della destinazione IP (prima la corrispondenza più lunga). Il FIB è concettualmente simile a una tabella di routing o a una base di informazioni. e conserva un'immagine speculare delle informazioni di inoltro contenute nella tabella di routing IP. Quando si verificano modifiche di routing o topologia nella rete, la tabella di routing IP viene aggiornata e le modifiche vengono riflesse nel file FIB. Il FIB gestisce le informazioni sull'indirizzo dell'hop successivo in base alle informazioni contenute nella tabella di routing IP. A causa di una correlazione uno-a-uno tra le voci FIB e le voci della tabella di routing, FIB contiene tutti i percorsi noti ed elimina la necessità di manutenzione della cache dei percorsi associata ai percorsi di switching, come ad esempio la commutazione rapida e la commutazione ottimale. Nel file FIB è sempre presente una corrispondenza, sia predefinita che con caratteri jolly.
I nodi della rete si definiscono adiacenti se possono raggiungere l'un l'altro con un solo hop attraverso un livello di collegamento. Oltre alla FIB, la CEF utilizza tabelle adiacenti per anteporre le informazioni di indirizzamento Layer 2 (L2). La tabella adiacente mantiene gli indirizzi hop successivo L2 per tutte le voci FIB. Ciò significa che una voce FIB completa contiene un puntatore a una posizione nella tabella adiacente che contiene le informazioni di riscrittura L2 per l'hop successivo fino alla destinazione IP finale. Affinché il CEF hardware funzioni sul sistema Catalyst 6500/Supervisor Engine 2, è necessario eseguire IP CEF sull'MSFC2.
La tabella FIB di PFC2 deve essere esattamente la stessa della tabella FIB dell'MSFC2. Sul PFC2, tutti i prefissi IP nel FIB vengono memorizzati in una TCAM (Content Addressable Memory) ternaria e ordinati in base alla lunghezza della maschera, a partire dalla maschera più lunga. Ciò significa che è necessario trovare prima tutte le voci con una maschera di 32 (voce host); quindi, si trovano tutte le voci con una lunghezza di maschera pari a 31 e così via, finché non si raggiunge una voce con una lunghezza di maschera pari a 0. Questa è la voce predefinita. La FIB viene letta in sequenza e la prima hit viene utilizzata come corrispondenza. Si consideri la seguente tabella FIB di esempio su PFC2:
Cat6k> (enable) show mls entry cef Mod FIB-Type Destination-IP Destination-Mask NextHop-IP Weight --- --------- --------------- ---------------- --------------- ------ 15 receive 0.0.0.0 255.255.255.255 !--- This is the first entry with mask length 32. 15 receive 255.255.255.255 255.255.255.255 15 receive 192.168.254.254 255.255.255.255 15 receive 10.48.72.237 255.255.255.255 15 receive 10.48.72.0 255.255.255.255 15 receive 10.48.72.255 255.255.255.255 15 receive 192.168.222.7 255.255.255.255 15 receive 192.168.100.254 255.255.255.255 15 receive 192.168.10.254 255.255.255.255 15 resolved 192.168.199.3 255.255.255.255 192.168.199.3 1 15 resolved 192.168.222.2 255.255.255.255 192.168.222.2 1 15 resolved 192.168.199.2 255.255.255.255 192.168.199.2 1 15 resolved 192.168.254.252 255.255.255.255 192.168.199.3 1 !--- This is the last entry with mask length 32. 15 connected 192.168.222.0 255.255.255.252 !--- This is the only entry with mask length 30. 15 receive 224.0.0.0 255.255.255.0 !--- This is the first entry with mask length 24. 15 connected 10.48.72.0 255.255.255.0 15 connected 192.168.10.0 255.255.255.0 15 connected 192.168.11.0 255.255.255.0 15 connected 192.168.100.0 255.255.255.0 15 connected 192.168.101.0 255.255.255.0 15 connected 192.168.199.0 255.255.255.0 !--- This is the last entry with mask length 24. 15 connected 127.0.0.0 255.0.0. 0 !--- This is the entry with mask length 8. 15 wildcard 0.0.0.0 0.0.0. 0 !--- This is the entry with mask length 0.
Ogni voce è costituita dai campi riportati di seguito.
Mod: l'MSFC2 che installa la voce è 15 o 16, a seconda del quale è l'MSFC2 designato.
Tipo FIB (FIB-Type) - Tipo associato a questa voce specifica. I possibili tipi FIB sono:
receive: il prefisso associato alle interfacce MSFC. Questo contiene un prefisso con una maschera di 32 corrispondente all'indirizzo IP delle interfacce MSFC e un indirizzo IP della subnet di broadcast.
resolve: prefisso associato a un indirizzo hop successivo valido. Contiene un prefisso con adiacenza risolta per l'hop successivo.
connected - Prefisso associato a una rete connessa.
wildcard: corrisponde a tutte le voci (drop o reindirizzamento MSFC). Questa voce è presente solo se non esiste una voce predefinita ed è presente con una lunghezza di maschera pari a 0.
default - La route di default. Come voce con caratteri jolly, essa corrisponde a tutte le subnet ed è presente con una lunghezza di maschera di 0. Punta all'hop successivo. Questa voce CEF predefinita è presente solo se è presente una route predefinita nella tabella di routing.
drop: tutti i pacchetti che corrispondono a una voce con un drop vengono scartati.
Destination-IP: indirizzo IP o subnet IP di destinazione interessata.
Maschera di destinazione (Destination-Mask) - Maschera associata alla voce. Come si può vedere nell'esempio, il valore FIB viene classificato a partire dalla maschera più lunga (255.255.255.255), fino alla maschera più corta possibile (0.0.0).
Next-Hop IP: visualizza l'IP dell'hop successivo, se esistente.
È possibile visualizzare la tabella adiacente completa immettendo questo comando:
Cat6k> (enable) show mls entry cef adjacency Mod:15 Destination-IP : 192.168.98.2 Destination-Mask : 255.255.255.255 FIB-Type :resolved AdjType NextHop-IP NextHop-Mac VLAN Encp Tx-Packets Tx-Octets -------- --------------- ----------------- ---- ---- ------------ ---------- connect 192.168.98.2 00-90-21-41-c5-57 98 ARPA 0 0
Nota: questo output contiene una voce simile a quella trovata nella tabella FIB di esempio, sopra, per ciascuna delle voci CEF risolte (o predefinite) nella FIB.
Prima di fornire alcuni esempi e dettagli sulla risoluzione dei problemi, questa sezione riepiloga i metodi seguiti per risolvere i problemi di connettività o raggiungibilità a un indirizzo IP specifico. Tenere presente che la tabella CEF sul PFC2 rispecchia la tabella CEF sull'MSFC2. Pertanto, PFC2 contiene solo le informazioni corrette per raggiungere un indirizzo IP se anche le informazioni note dall'MSFC2 sono corrette. È sempre necessario verificare le informazioni seguenti.
Attenersi alla seguente procedura:
Verificare che le informazioni contenute nel routing IP sulla tabella MSFC2 siano corrette usando il comando show ip route (o il comando show ip route x.x.x.x per evitare di cercare la tabella di routing completa), quindi verificare che l'output contenga l'hop successivo previsto.
In caso contrario, è necessario controllare il protocollo di routing, la configurazione, il protocollo di routing adiacente e qualsiasi altra risoluzione dei problemi relativa al protocollo di routing in esecuzione.
Verificare che l'hop successivo (o la destinazione finale di una rete connessa) abbia una voce ARP (Address Resolution Protocol) corretta sull'MSFC2 usando il comando show ip arp next_hop_ip_address, quindi verificando che l'ARP sia stato risolto e contenga l'indirizzo MAC corretto.
Se l'indirizzo MAC non è corretto, è necessario verificare se un altro dispositivo è proprietario di tale indirizzo IP. Infine, è necessario tenere traccia del livello dello switch sulla porta che connette il dispositivo proprietario dell'indirizzo MAC. Se la voce ARP è incompleta, significa che non è stata ricevuta alcuna risposta da tale host. È necessario verificare che l'host sia operativo. È possibile utilizzare uno sniffer sull'host per verificare se riceve la risposta ARP e se risponde correttamente.
Verificare che la tabella CEF sull'MSFC2 contenga le informazioni corrette e che l'adiacenza venga risolta eseguendo la procedura seguente:
Eseguire il comando show ip cef rete_destinazione per verificare che l'hop successivo nella tabella CEF corrisponda all'hop successivo nella tabella di routing IP (dal passaggio 1 di cui sopra).
Verificare che l'adiacenza sia corretta eseguendo il comando show adiacency detail | iniziare il comando next_hop_ip_address.
Deve contenere lo stesso indirizzo MAC dell'ARP indicato nel passaggio 2 di cui sopra.
Se i passaggi 1 e 2 forniscono i risultati corretti, ma i passaggi 3a o 3b hanno esito negativo, si verifica un problema di CEF del software Cisco IOS che probabilmente non è correlato a Catalyst 6500/6000. È necessario provare a cancellare la tabella ARP e la tabella di routing IP.
Attenersi alla seguente procedura:
Verificare che le informazioni FIB memorizzate sul PFC2 siano corrette e corrispondano alle informazioni memorizzate nella tabella CEF sull'MSFC2 (come mostrato nel passaggio 3, sopra) usando il comando show mls entry cef ip destination_ip_network/destination_subnet_mask e verificando che l'indirizzo IP dell'hop successivo sia quello previsto.
Se le informazioni non corrispondono ai risultati del passaggio 3, si verificherà un problema di comunicazione tra l'MSFC2 e il PFC2 (interno di Catalyst 6500/6000). Verificare che non vi sia un bug noto per il CatOS del PFC2 o per il software Cisco IOS dell'MSFC2 in esecuzione. Per ripristinare la voce corretta, usare il comando clear ip route sull'MSFC2.
Verificare la tabella delle adiacenze sul PFC2 usando il comando show mls entry cef ip next_hop_ip_address/32 adiacency, quindi verificare che contenga lo stesso indirizzo MAC di quello mostrato ai punti 2 e 3b della sezione From the MSFC2, sopra.
Se l'adiacenza nel PFC2 non corrisponde a quella dell'hop successivo nel passaggio 3b, è probabile che si verifichi un problema di comunicazione interna tra MSFC2 e PFC2. È possibile provare a eliminare l'adiacenza per ripristinare le informazioni corrette.
Questo semplice caso offre uno studio della connettività tra:
host 1 nella VLAN 10 con indirizzo IP 192.168.10.10
host 2 nella VLAN 199 con indirizzo IP 192.168.199.3
Di seguito è riportato un esempio dell'output della configurazione MSFC2:
interface VLAN 10 description Server VLAN ip address 192.168.10.1 255.255.255.0 no ip redirects ! interface VLAN 199 ip address 192.168.199.1 255.255.255.0
Nota: è importante notare che Catalyst 6500/6000 con Supervisor Engine 2 e MSFC2 sta eseguendo il routing tramite CEF nell'hardware. Nessun elemento da configurare. Impossibile disabilitare CEF sull'MSFC2.
Seguire le procedure evidenziate nella sezione Metodo di risoluzione dei problemi in questo documento per verificare il percorso per raggiungere l'indirizzo IP 192.168.199.3.
Verificare la tabella di routing IP usando uno dei seguenti comandi:
Cat6k-MSFC2# show ip route 192.168.199.3 Routing entry for 192.168.199.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via VLAN 199 Route metric is 0, traffic share count is 1
o
Cat6k-MSFC2# show ip route | include 192.168.199.0 C 192.168.199.0/24 is directly connected, VLAN 199
In entrambi gli output del comando è possibile verificare che la destinazione si trova in una subnet connessa direttamente. Di conseguenza, non c'è un hop successivo verso la destinazione.
Verificare la voce ARP sull'MSFC2.
In questo caso, verificare che esista una voce ARP per l'indirizzo IP di destinazione usando questo comando:
Cat6k-MSFC2# show ip arp 192.168.199.3 Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.199.3 176 0030.7150.6800 ARPA VLAN 199
Verificare il CEF e la tabella adiacente sull'MSFC2.
Verificare la tabella CEF usando questo comando:
Cat6k-MSFC2# show ip cef 192.168.199.3 192.168.199.3/32, version 281, connected, cached adjacency 192.168.199.3 0 packets, 0 bytes via 192.168.199.3, VLAN 199, 0 dependencies next-hop 192.168.199.3, VLAN 199 valid cached adjacency
È possibile notare che esiste una voce CEF valida con una lunghezza della maschera di 32 e che esiste un'adiacenza della cache valida.
Verificare la tabella adiacente usando questo comando:
Cat6k-MSFC2# show adjacency detail | begin 192.168.199.3 IP VLAN 199192.168.199.3(7) 0 packets, 0 bytes 003071506800 !--- This is the destination MAC address. 00D0003F8BFC0800 ARP00:58:35
Come si può vedere dall'output di cui sopra, c'è un'adiacenza. L'indirizzo MAC di destinazione dell'adiacenza mostra le stesse informazioni dell'indirizzo MAC nella tabella ARP del punto 2, sopra.
Si noti che i contatori al Passaggio 3b sono quasi sempre 0, in quanto i pacchetti sono commutati al Layer 3 (L3) nell'hardware. Pertanto, non raggiungono mai l'MSFC2 e non vengono conteggiati nei contatori dell'MSFC2 CEF. L'unico modo per vedere le statistiche sui pacchetti inoltrati a una determinata destinazione è quello di guardare le statistiche dell'adiacenza rilevata sul PFC2 durante il Passaggio 5.
Verificare dal punto di vista di Supervisor Engine che la voce CEF/FIB sia corretta.
Ci sono due voci interessanti in FIB, come segue:
Una voce per l'indirizzo IP di destinazione, come mostrato di seguito:
Cat6k> (enable) show mls entry cef ip 192.168.199.3/32 Mod FIB-Type Destination-IP Destination-Mask NextHop-IP Weight --- --------- --------------- ---------------- --------------- ------ 15 resolved 192.168.199.3 255.255.255.255 192.168.199.3 1
Questa voce è una voce host con un hop successivo già noto (che, in questo caso, è la destinazione stessa).
Una voce corrispondente alla rete di destinazione, come mostrato di seguito:
Cat6k> (enable) show mls entry cef ip 192.168.199.0/24 Mod FIB-Type Destination-IP Destination-Mask NextHop-IP Weight --- --------- --------------- ---------------- --------------- ------ 15 connected 192.168.199.0 255.255.255.0
Questa voce è una voce FIB connessa, il che significa che qualsiasi pacchetto che tocca questa voce viene reindirizzato all'MSFC2 per un'ulteriore elaborazione (principalmente invio di ARP e attesa della risoluzione ARP).
Tenere presente che la FIB viene visualizzata in sequenza, a partire dalla lunghezza della maschera più lunga. Pertanto, se sono presenti entrambe le voci elencate al punto 4, si preme il primo con la maschera 32 (voce host) e non si scende più in basso nella tabella FIB. Nel caso in cui la voce /32 non sia presente, è necessario selezionare la seconda voce, ovvero la voce relativa alla rete; trattandosi di una voce connessa, il pacchetto viene reindirizzato all'MSFC2 per un'ulteriore elaborazione. L'MSFC2 può inviare una richiesta ARP per la maschera di destinazione. Dopo aver ricevuto la risposta ARP, la tabella ARP e la tabella adiacente vengono completate per l'host sull'MSFC2.
Dopo aver ottenuto la voce FIB corretta con lunghezza maschera 32, verificare che l'adiacenza sia correttamente popolata per l'host usando questo comando:
Cat6k> (enable) show mls entry cef ip 192.168.199.3/32 adjacency Mod:15 Destination-IP : 192.168.199.3 Destination-Mask : 255.255.255.255 FIB-Type : resolved AdjType NextHop-IP NextHop-Mac VLAN Encp TX-Packets TX-Octets -------- --------------- ----------------- ---- ---- ------------ ------------- connect 192.168.199.3 00-30-71-50-68-00 199 ARPA 0 0
Nota: l'adiacenza viene popolata e il campo NextHop-Mac contiene l'indirizzo MAC valido dell'host 2 (come mostrato nei passaggi 2 e 3b).
A questo punto, tutto l'output è corretto, anche se il numero di pacchetti trasmessi per questa adiacenza è ancora 0. Nell'esempio successivo, si inviano dieci ping di 100 byte dall'host 1 all'host 2 e si controlla di nuovo l'adiacenza.
Cat6k> (enable) show mls entry cef ip 192.168.199.3/32 adjacency Mod:15 Destination-IP : 192.168.199.3 Destination-Mask : 255.255.255.255 FIB-Type : resolved AdjType NextHop-IP NextHop-Mac VLAN Encp TX-Packets TX-Octets -------- --------------- ----------------- ---- ---- ------------ ------------- connect 192.168.199.3 00-30-71-50-68-00 199 ARPA 10 1000
È possibile ora vedere che il numero di pacchetti TX è 10, il che è coerente con il traffico che è stato inviato.
Come indicato al punto 4 della procedura di risoluzione dei problemi, sopra, si dispone di due voci FIB che possono essere utili, come spiegato di seguito:
la voce network (in questo caso, 192.168.199.0/24): questa voce è sempre presente e proviene direttamente dalla tabella di routing e CEF dell'MSFC. Questa rete è sempre connessa direttamente nella tabella di routing.
la voce dell'host di destinazione (in questo caso, 192.168.199.3/32): questa voce non è necessariamente presente. In caso contrario, si preme la voce network e si verificano le seguenti condizioni:
Il pacchetto viene inoltrato all'MSFC2.
La voce host con lunghezza maschera 32 viene quindi creata nella tabella FIB della PFC. Tuttavia, poiché non avete ancora un'adiacenza completa, l'adiacenza viene creata con il tipo frc drop (che significa force drop).
Il pacchetto successivo per quella destinazione colpisce la voce /32 frc drop, e il pacchetto viene scartato.
Allo stesso tempo, il pacchetto originale inviato all'MSFC2 attiva l'MSFC2 per inviare una richiesta ARP.
Una volta risolto l'ARP, la voce ARP viene completata. L'adiacenza viene completata sull'MSFC2 e un aggiornamento dell'adiacenza viene inviato al Supervisor Engine per completare l'adiacenza di rilascio frc esistente.
Il Supervisor Engine cambia l'adiacenza dell'host in modo da riflettere l'indirizzo MAC di riscrittura e il tipo di adiacenza viene modificato in connessione.
Questo meccanismo di installazione di una frc drop adiacente mentre si attende la risoluzione dell'ARP è chiamato acceleratore ARP. La limitazione ARP è utile per evitare che tutti i pacchetti vengano inoltrati all'MSFC2 e vengano generate più richieste ARP. Solo i primi pacchetti vengono inviati all'MSFC2, gli altri vengono scartati al PFC2 fino al completamento dell'adiacenza.
Ciò consente anche di indirizzare il traffico diretto a un host inesistente o che non risponde in una rete direttamente connessa.
Quando si risolvono i problemi di connessione tra due utenti di due VLAN diverse, è importante tenere sempre presente che occorre esaminare:
il traffico tra l'host 1 e l'host 2 utilizzando il metodo di risoluzione dei problemi illustrato sopra, per creare l'indirizzo IP di destinazione host 2
il traffico tra l'host 2 e l'host 1 utilizzando lo stesso metodo, ma questa volta con la destinazione come host 1
È inoltre importante ricordare che l'output deve essere eseguito sul gateway predefinito dell'origine, che non è necessariamente lo stesso traffico tra l'host 1 e l'host 2 e lo stesso traffico tra l'host 2 e l'host 1.
Nota: i contatori nel passo 3b della procedura di risoluzione dei problemi, sopra, sono quasi sempre 0 in quanto i pacchetti sono commutati L3 nell'hardware. Pertanto, non raggiungono mai l'MSFC2 e non vengono conteggiati nei contatori dell'MSFC2 CEF. L'unico modo per visualizzare le statistiche sui pacchetti inoltrati a una determinata destinazione è quello di esaminare le statistiche delle adiacenze trovate sul PFC2 durante il passaggio 5 della procedura di risoluzione dei problemi, sopra riportata.
Si consideri il diagramma seguente, in cui l'host 1 con indirizzo IP 192.168.10.10 esegue il ping tra l'host 2 e l'indirizzo IP 192.168.150.3. Tuttavia, questa volta l'host 2 è posizionato a due hop indirizzati anziché essere connesso direttamente a Catalyst 6500/6000-MSFC2. Lo stesso metodo viene utilizzato per seguire il percorso indirizzato CEF su Catalyst 6500/6000-MSFC2.
Attenersi alla seguente procedura:
Controllare la tabella di routing sull'MSFC2 usando questo comando:
Cat6k-MSFC2# show ip route 192.168.150.3 Routing entry for 192.168.150.0/24 Known via "ospf 222", distance 110, metric 2, type intra area Last update from 192.168.199.3 on VLAN 199, 00:12:43 ago Routing Descriptor Blocks: * 192.168.199.3, from 192.168.254.252, 00:12:43 ago, via VLAN 199 Route metric is 2, traffic share count is 1 Cat6k-MSFC2#sh ip route | include 192.168.150.0 O 192.168.150.0/24 [110/2] via 192.168.199.3, 00:13:00, VLAN 199
Come si evince dall'output precedente, per raggiungere l'host 2 con l'indirizzo IP 192.168.150.3 è disponibile una route OSPF (Open Shortest Path First). È necessario raggiungere l'indirizzo IP 192.168.199.3 nella VLAN 199 come hop successivo.
Controllare la tabella ARP sull'MSFC2 usando il comando seguente.
Nota: controllare la voce ARP per l'hop successivo e non per la destinazione finale.
Cat6k-MSFC2# show ip arp 192.168.199.3 Protocol Address Age (min) Hardware Addr Type Interface Internet 192.168.199.3 217 0030.7150.6800 ARPA VLAN 199
Controllare la tabella CEF e la tabella adiacente sull'MSFC2 usando questo comando:
Cat6k-MSFC2# show ip cef 192.168.150.0 192.168.150.0/24, version 298, cached adjacency 192.168.199.3 0 packets, 0 bytes via 192.168.199.3, VLAN 199, 0 dependencies next-hop 192.168.199.3, VLAN 199 valid cached adjacency
Si osserverà che esiste una voce CEF per la rete di destinazione e che i risultati dell'hop successivo corrispondono a quelli mostrati nel passo 1 della tabella di routing.
Controllare la tabella adiacente per l'hop successivo usando questo comando:
Cat6k-MSFC2# show adjacency detail | begin 192.168.199.3 IP VLAN 199 192.168.199.3(9) 0 packets, 0 bytes 003071506800 00D0003F8BFC0800 ARP 00:17:48
Esiste una adiacenza valida per l'hop successivo e l'indirizzo MAC di destinazione corrisponde alla voce ARP trovata nel passaggio 2 di cui sopra.
Controllare la tabella FIB sul Supervisor Engine (PFC2) eseguendo questo comando:
Cat6k> (enable) show mls entry cef ip 192.168.150.0/24 Mod FIB-Type Destination-IP Destination-Mask NextHop-IP Weight --- --------- --------------- ---------------- --------------- ------ 15 resolved 192.168.150.0 255.255.255.0 192.168.199.3 1
Il file FIB riflette le stesse informazioni trovate nel passaggio 3 e si dispone dello stesso hop successivo.
Controllare le adiacenze del Supervisor Engine (PFC2) usando questo comando:
Cat6k> (enable) show mls entry cef ip 192.168.150.0/24 adjacency Mod:15 Destination-IP : 192.168.150.0 Destination-Mask : 255.255.255.0 FIB-Type : resolved AdjType NextHop-IP NextHop-Mac VLAN Encp TX-Packets TX-Octets -------- --------------- ----------------- ---- ---- ------------ ------------ connect 192.168.199.3 00-30-71-50-68-00 199 ARPA 0 0
È inoltre possibile verificare di disporre di un'adiacenza di connessione che rifletta lo stesso indirizzo MAC individuato nei passaggi 2 e 4.
Nota: è possibile controllare l'adiacenza per la destinazione finale quando si controlla l'adiacenza sul PFC2. Ciò non è possibile con il software Cisco IOS sull'MSFC2, con cui è necessario controllare l'adiacenza per l'hop successivo. La tabella adiacente sul PFC2 per la destinazione finale mostra sia l'hop successivo che l'adiacenza per l'hop successivo (se risolto), il tutto in un unico output di comando. Sull'MSFC2, è necessario controllare separatamente la voce CEF per trovare l'hop successivo e quindi cercare l'adiacenza dell'hop successivo.
Nell'esempio viene mostrato come le operazioni di risoluzione dei problemi utilizzate per verificare la connettività su uno switch Catalyst 6500/6000-MSFC2 per raggiungere una rete remota siano simili all'esempio precedente illustrato nella sezione Case Study 1: Connettività a un host in una rete a connessione diretta. Esistono tuttavia alcune differenze:
È possibile controllare la destinazione finale nella tabella di routing IP, nella tabella CEF e in FIB (passaggi 1, 3 e 5).
È possibile controllare le informazioni dell'hop successivo nella tabella ARP e nella tabella adiacente (punti 2 e 4).
Nel passo 6, è possibile controllare direttamente l'adiacenza per la destinazione finale. I risultati visualizzano sia l'hop successivo dal FIB che le informazioni di riscrittura adiacenti dalla tabella adiacente.
In questo caso, non vi è alcuna voce nel FIB per la destinazione finale, come indicato di seguito. (È presente solo la voce di rete con una lunghezza della maschera di 24.)
Cat6k> (enable) show mls entry cef ip 192.168.150.3/32 adjacency Cat6k> (enable)
In questo caso di studio viene descritto cosa succede nel caso in cui siano disponibili diversi hop successivi e percorsi diversi per raggiungere la stessa rete di destinazione.
In una sezione di esempio della tabella di routing sottostante, notare che ci sono tre percorsi diversi e tre hop successivi disponibili per raggiungere lo stesso indirizzo IP di destinazione di 192.168.254.253.
O 192.168.254.253 [110/2] via 192.168.222.6, 00:42:45, POS8/2 [110/2] via 192.168.222.2, 00:42:45, VLAN 222 [110/2] via 192.168.199.2, 00:42:45, VLAN 199
Controllare la voce ARP per ciascuno dei tre hop successivi, attenendosi alla seguente procedura:
Controllare la tabella CEF per la destinazione.
Si noti che nella destinazione vengono visualizzate anche tre voci diverse nella tabella CEF dell'MSFC2. Il software CEF di Cisco IOS consente di condividere il carico tra route diverse.
cat6k-MSFC2# show ip cef 192.168.254.253 192.168.254.253/32, version 64, per-destination sharing 0 packets, 0 bytes via 192.168.222.6, POS8/2, 0 dependencies traffic share 1 next-hop 192.168.222.6, POS8/2 valid adjacency via 192.168.222.2, VLAN 222, 0 dependencies traffic share 1 next-hop 192.168.222.2, VLAN 222 valid adjacency via 192.168.199.2, VLAN 199, 0 dependencies traffic share 1 next-hop 192.168.199.2, VLAN 199 valid adjacency 0 packets, 0 bytes switched through the prefix
Controllare le tre adiacenze nella tabella adiacenze MSFC2.
Devono corrispondere alla voce ARP nel passaggio 2 di cui sopra.
Si noti che per la stessa destinazione sono installate tre voci FIB diverse.
Il CEF hardware sul PFC2 è in grado di caricare fino a sei percorsi diversi per la stessa destinazione. È possibile visualizzare il peso utilizzato per ogni hop successivo nel campo del peso. La condivisione del carico utilizzata dal PFC2 è solo una condivisione del carico per flusso. Non consente la condivisione del carico per pacchetto.
Cat6k> (enable) show mls entry cef ip 192.168.254.253/32 Mod FIB-Type Destination-IP Destination-Mask NextHop-IP Weight --- --------- --------------- ---------------- --------------- ------ 15 resolved 192.168.254.253 255.255.255.255 point2point 1 192.168.222.2 1 192.168.199.2 1
Verificare le adiacenze della voce di destinazione utilizzando questo comando:
cat6k> (enable) show mls entry cef ip 192.168.254.253/32 adjacency Mod : 15 Destination-IP : 192.168.254.253 Destination-Mask : 255.255.255.255 FIB-Type : resolved AdjType NextHop-IP NextHop-Mac VLAN Encp TX-Packets TX-Octets -------- --------------- ----------------- ---- ---- ------------ ------------ connect point2point 00-00-08-00-04-00 1025 ARPA 0 0 connect 192.168.222.2 00-90-21-41-c4-07 222 ARPA 0 0 connect 192.168.199.2 00-90-21-41-c4-17 199 ARPA 0 0
A prescindere dall'aspetto della tabella di routing, esiste sempre una voce FIB nel Supervisor Engine 2 per inoltrare pacchetti che non corrispondono a nessuna voce precedente. Per visualizzare la voce, usare questo comando:
Cat6k> (enable) show mls entry cef ip 0.0.0.0/0 Mod FIB-Type Destination-IP Destination-Mask NextHop-IP Weight --- --------- --------------- ---------------- --------------- ------ 15 default 0.0.0.0 0.0.0.0 192.168.98.2 1
Come si può vedere, questa è l'unica voce con una lunghezza di maschera di 0. L'impostazione predefinita può essere di due tipi, come spiegato di seguito nelle sezioni Route predefinita esistente nella tabella di routing MSFC2 e Nessuna route predefinita nella tabella di routing.
Determinare innanzitutto come verificare se è presente una route predefinita nella tabella di routing MSFC2. È possibile cercare una route con destinazione 0.0.0.0 oppure cercare nella tabella di routing. Il percorso predefinito è contrassegnato da un asterisco (*). (Qui, viene visualizzato anche in grassetto.)
Cat6k-MSFC2# show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "rip", distance 120, metric 1, candidate default path Redistributing via rip Last update from 192.168.98.2 on VLAN 98, 00:00:14 ago Routing Descriptor Blocks: * 192.168.98.2, from 192.168.98.2, 00:00:14 ago, via VLAN 98 Route metric is 1, traffic share count is 1 Cat6k-MSFC2#sh ip ro | include 0.0.0.0 R* 0.0.0.0/0 [120/1] via 192.168.98.2, 00:00:22, VLAN 98
In questo caso, il percorso predefinito è presente nella tabella di routing MSFC2 e viene appreso tramite il protocollo RIP (Routing Information Protocol). Si noti tuttavia che il comportamento CEF è lo stesso indipendentemente da come viene appresa la route predefinita (static, OSPF, RIP e così via).
In questo caso, se si dispone di un percorso predefinito, è sempre disponibile una voce CEF con una lunghezza della maschera pari a 0 e un tipo FIB di valore predefinito che viene utilizzato per inoltrare tutto il traffico che non corrisponde ad alcun altro prefisso.
Cat6k> (enable) show mls entry cef ip 0.0.0.0/0 Mod FIB-Type Destination-IP Destination-Mask NextHop-IP Weight --- --------- --------------- ---------------- --------------- ------ 15 default 0.0.0.0 0.0.0.0 192.168.98.2 1 Cat6k< (enable) show mls entry cef ip 0.0.0.0/0 adjacency Mod : 15 Destination-IP : 0.0.0.0 Destination-Mask : 0.0.0.0 FIB-Type : default AdjType NextHop-IP NextHop-Mac VLAN Encp TX-Packets TX-Octets -------- --------------- ----------------- ---- ---- ------------ ------------- connect 192.168.98.2 00-90-21-41-c5-57 98 ARPA 10433743 3052325803
Poiché la FIB viene cercata in sequenza per ciascun pacchetto, iniziando prima dalla corrispondenza più lunga, questa FIB predefinita viene utilizzata solo per i pacchetti per cui non è stata trovata alcuna altra corrispondenza.
Cat6k-MSFC2# show ip route 0.0.0.0 % Network not in table
Se nella tabella di routing non sono presenti route predefinite, è ancora presente una voce FIB con lunghezza di maschera 0 nel Supervisor Engine 2. Tuttavia, questa voce ha ora un tipo FIB di carattere jolly. Questo FIB con caratteri jolly scarta tutti i pacchetti che lo colpiscono e corrisponde a qualsiasi pacchetto che non corrisponde ad altre voci nel FIB. È utile eliminare questi pacchetti, in quanto non si dispone di route predefinite. Non è necessario inoltrare questi pacchetti all'MSFC2, che li rifiuta comunque. L'uso di questo carattere jolly FIB assicura la consegna di questi pacchetti inutili nell'hardware.
Cat6k> (enable) show mls entry cef ip 0.0.0.0/0 Mod FIB-Type Destination-IP Destination-Mask NextHop-IP Weight --- --------- --------------- ---------------- --------------- ------ 15 wildcard 0.0.0.0 0.0.0.0
Nota: nel raro caso in cui la tabella FIB sia piena, la voce con caratteri jolly è ancora presente ma, invece di eliminare i pacchetti corrispondenti, vengono inoltrati all'MSFC2. Questo si verifica solo se si dispone di un prefisso superiore a 256K nel FIB e se non è possibile memorizzare la tabella di routing completa e la adiacenza ARP nel FIB. A questo punto, è necessario inviare il meccanismo predefinito all'MSFC2, in quanto quest'ultimo può avere una voce di routing non presente nel file FIB.
Quando il Supervisor Engine 2 riceve un pacchetto, lo considera un potenziale pacchetto L3 solo se l'indirizzo MAC di destinazione del pacchetto è lo stesso di uno degli indirizzi MAC dell'MSFC2. È possibile verificare che questi indirizzi siano dal punto di vista del Supervisor Engine 2 usando questo comando:
Cat6k> (enable) show mls cef mac Module 15 : Physical MAC-Address 00-d0-00-3f-8b-fc VLAN Virtual MAC-Address(es) ---- ----------------------- 10 00-00-0c-07-ac-0a 100 00-00-0c-07-ac-64 Module 15 is the designated MSFC for installing CEF entries
È possibile visualizzare l'indirizzo MAC fisico dell'MSFC2. Ricordare che tutte le interfacce dell'MSFC2 utilizzano lo stesso indirizzo MAC; non è possibile configurare indirizzi MAC diversi su due interfacce diverse.) Questo indirizzo MAC deve essere lo stesso di quello dell'MSFC2.
Cat6k-MSFC2# show interface VLAN1 is up, line protocol is up Hardware is Cat6k RP Virtual Ethernet, address is 00d0.003f.8bfc (bia 00d0.003f.8bfc) ?..
Il comando show mls cef mac visualizza anche tutti gli indirizzi MAC collegati ai gruppi HSRP (Hot Standby Router Protocol), dove l'MSFC è attivo. L'output del comando show mls cef mac di cui sopra indica che l'MSFC è attivo per HSRP sulla VLAN 10 e sulla VLAN 100. Per verificare la correttezza del risultato, usare questo comando sull'MSFC2:
Cat6k-MSFC2# show standby brief P indicates configured to preempt. | Interface Grp Prio P State Active addr Standby addr Group addr Vl10 10 200 P Active local 192.168.10.2 192.168.10.254 Vl11 11 100 P Standby 192.168.11.1 local 192.168.11.254 Vl98 98 200 Standby 192.168.98.2 local 192.168.98.5 Vl99 99 200 Standby 192.168.99.2 local 192.168.99.5 Vl100 100 200 P Active local 192.168.100.2 192.168.100.254 Vl101 101 100 P Standby 192.168.101.2 local 192.168.101.254
Come si può vedere, lo stato è Attivo solo per la VLAN 10 e la VLAN 100. Lo stato è Standby per tutti gli altri gruppi HSRP configurati. Se, per un motivo qualsiasi, lo stato Active inizia per un'altra VLAN, l'output del comando show mls cef mac deve restituire che la VLAN aggiuntiva non è attiva.
In caso di incongruenze tra l'output del comando show mls cef mac e il risultato desiderato, è possibile usare questo comando per ottenere ulteriori informazioni sugli indirizzi MAC aggiunti e rimossi dall'elenco dei comandi show mls cef mac:
Cat6k-MSFC2#Cat6k> (enable) show mls rlog l2 SWLOG at 82a7f410: magic 1008, size 51200, cur 82a81ca4, end 82a8bc20 Current time is: 12/28/01,17:09:15 1781 12/28/01,11:40:05:(RouterConfig)Router_cfg: router_add_mac_to_earl 00-d0-00-3f-8b- fcadded for mod 15/1 VLAN 99 Earl AL =0 1780 12/28/01,11:40:05:(RouterConfig)Router_Cfg: process add(3) router intf for mNo 15/1 VLAN 99 1779 12/28/01,11:40:05:(RouterConfig)Router_cfg: router_add_mac_to_earl 00-d0-00-3f-8b- fcadded for mod 15/1 VLAN 99 Earl AL =0 1778 12/28/01,11:40:05:(RouterConfig)Router_Cfg: process add(3) router intf for mNo 15/1 VLAN 99 1777 12/28/01,11:40:05:(RouterConfig)Router_cfg: router_add_mac_to_earl 00-d0-00-3f-8b- fcadded for mod 15/1 VLAN 99 Earl AL =0 1776 12/28/01,11:40:05:(RouterConfig)Router_Cfg: Process add mls entry for mod 15/1 VLAN 99 i/f 1, proto 3, LC 0 1775 12/28/01,11:40:05:(RouterConfig)Router_cfg: router_add_mac_to_earl 00-d0-00-3f-8b- fcadded for mod 15/1 VLAN 99 Earl AL =0 1774 12/28/01,11:40:05:(RouterConfig)Router_Cfg: Process add mls entry for mod 15/1 VLAN 99 i/f 1, proto 2, LC 0
Questo comando restituisce un messaggio ogni volta che si aggiunge o si rimuove un indirizzo MAC nella tabella dei comandi show mls cef mac.
In questo documento viene descritto come controllare la tabella dei comandi show mls entry cef sul Supervisor Engine 2. Questo comando non rappresenta in modo accurato la reale programmazione ASIC (Application-Specific Integrated Circuit) del PFC2. Rappresenta solo una copia shadow di questa impostazione ASIC. Ci sono stati alcuni problemi noti in cui le reali impostazioni hardware non erano in accordo con quanto visualizzato nel TCAM ombra, che ha causato l'inoltro di alcuni pacchetti all'hop successivo sbagliato. Questi problemi sono documentati nell'ID bug Cisco CSCdv49956 (solo utenti registrati) e CSCdu85211 (solo utenti registrati), entrambi risolti nel software CatOS versione 6.3(3), 7.1(1) e successive.
Nelle prime versioni del codice è stato rilevato un bug in cui l'inoltro alla route predefinita non funziona con il protocollo EIGRP (Enhanced Interior Gateway Routing Protocol) o con OSPF. Questo problema è documentato nell'ID bug Cisco CSCdt54036 (solo utenti registrati) e viene risolto nel software CatOS versione 6.1(3) e successive per l'immagine Supervisor Engine e nel software Cisco IOS versione 12.1(6)E1 per l'immagine MSFC2.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
05-Jun-2008 |
Versione iniziale |