La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritto come Cisco Catalyst 6500 con Supervisor Sup2T programma le voci CEF (Cisco Express Forwarding) configurate sul software Cisco IOS nelle schede di linea e nell'hardware usato per ottenere l'inoltro dei pacchetti.
Cisco raccomanda la conoscenza dei seguenti argomenti:
Switch Cisco Catalyst serie 6500
Le informazioni di questo documento si basano sulle seguenti versioni hardware e software:
Cisco Catalyst 6500 WS-X6848-GE-TX (con DFC4) scheda di linea.
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.
Il CEF è un meccanismo di switching di layer 3 utilizzato dalla maggior parte degli switch multilivello Cisco. È essenziale che i tecnici di rete comprendano il funzionamento del CEF per risolvere giornalmente problemi di interruzione della rete, perdita o ritardo dei pacchetti.
Sup2T supervisor in modalità standalone o VSS è attualmente implementato da molte reti aziendali come switch principale, aggrega praticamente tutti gli altri dispositivi di routing o switching. Ciò significa anche che inoltra la maggior parte del traffico all'interno e tra domini per consegnare correttamente i pacchetti alle sue destinazioni. Per ottenere questo risultato, Sup2T deve avere informazioni di routing appropriate apprese in modo statico o dinamico tramite i protocolli di routing.
In uno chassis modulare, oltre a quello del supervisore possono esistere più motori di inoltro. Alcune schede di linea (in particolare quelle di nuova generazione come la C6800-32P10G) includono già un proprio motore di inoltro per migliorare le prestazioni di switching dei pacchetti. La ricerca delle voci CEF viene eseguita localmente e consente una migliore distribuzione delle risorse per il traffico in entrata su schede di linea diverse. Queste schede sono note come DFC (Distributed Forwarding Card).
Le voci CEF condivise tra tutti i motori di inoltro potrebbero non essere allocate nei dispositivi hardware per più motivi, da una condizione di errore software, esaurimento delle risorse a condizioni di CPU elevate e impedisce allo switch di avere tempo sufficiente per aggiornare tutte le voci, causando una serie di eventi indesiderati.
Rete:
Switch#show module 3
---------------------- ----------------------------- Mod Ports Card Type Model Serial No. --- ----- -------------------------------------- ------------------ ----------- 3 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6848-GE-TX SAL2003X5AH ---- --------------------------- ------------------ ----------- ------- ------- 3 Distributed Forwarding Card WS-F6K-DFC4-A SAL2003X5AH 1.4 Ok
Nel diagramma, uno switch 6506 standalone ha un Supervisor 2T installato e una scheda di linea WS-6848-GE-TX con un DFC nello slot 3. L'host 3750X collegato alla scheda di linea tramite la porta G3/1 invia il traffico all'indirizzo di loopback 0 dell'host 3850 1.1.1.
Per questo motivo, lo switch 3750X ha un percorso statico all'indirizzo IP da 1.1.1.1 a 10.1.1.10 dell'hop successivo, ossia la SVI della VLAN 1 nello switch Sup2T. Lo switch Sup2T deve indirizzare questo traffico allo switch 3850 in base a una voce di percorso statico per IP 1.1.1.1/32 tramite l'hop successivo 10.1.2.1, ossia l'interfaccia 3850 collegata alla Sup2T nella VLAN 2.
MXC.CALO.3750X#show ip route | inc 1.1.1.1 S 1.1.1.1 [1/0] via 10.1.1.10 MXC.CALO.Sup2T#show ip route | inc 1.1.1.1 S 1.1.1.1 [1/0] via 10.1.2.1 CALO.MXC.3850#show ip route | inc 1.1.1.1 C 1.1.1.1 is directly connected, Loopback1
Per semplicità, gli switch 3750X e 3850 sono collegati allo switch 6500 tramite la stessa scheda di linea. Ciò significa che il traffico viene cercato localmente e inoltrato localmente.
Un pacchetto entra nello switch Sup2T via Gi3/1 e raggiunge il motore di inoltro (poiché si tratta di una DFC). Il motore di inoltro analizza il campo dell'indirizzo IP di destinazione in questo pacchetto e cerca la corrispondenza migliore (maschera più lunga) tra le voci CEF programmate.
Poiché si tratta di una scheda DFC, significa che dispone di proprie voci CEF e per verificarle, è necessario per noi collegare alla scheda di linea con il comando attach [dec] o attach switch [1-2] mod [dec] per VSS.
A questo punto, il prompt DFC, comando show platform hardware cef o show platform hardware cef vpn 0, restituisce tutte le voci CEF programmate per la tabella di routing generale (VPN 0/ No VRF).
Poiché l'obiettivo è il prefisso 1.1.1.1/32, si utilizza il comando show platform hardware cef vpn 0 lookup 1.1.1.1. Il comando restituisce la corrispondenza migliore per il prefisso 1.1.1.1 e quella usata per inoltrare effettivamente il traffico:
MXC.CALO.Sup2T#attach 3 Trying Switch ... Entering CONSOLE for Switch Type "^C^C^C" to end this session MXC.CALO.Sup2T-dfc3#show platform hardware cef vpn 0 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 32 0.0.0.0/32 receive 33 255.255.255.255/32 receive 34 10.1.85.254/32 glean 35 10.1.85.5/32 receive 36 10.1.86.5/32 receive [snip...] MXC.CALO.Sup2T-dfc3#show platform hardware cef vpn 0 lookup 1.1.1.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 262 1.1.1.1/32 Vl2 ,0c11.678b.f6f7
La voce CEF è lì, è stata programmata come risultato della nostra voce statica programmata nel software IOS tramite il comando ip route 1.1.1.255.255.255.255 10.1.2.1.
È inoltre possibile verificare che questa voce riceva risultati e che il traffico venga inoltrato con questa voce tramite i comandi show platform hardware cef 1.1.1 detail che restituisce una voce adiacente:
MXC.CALO.Sup2T-dfc3#show platform hardware cef 1.1.1.1 detail Codes: M - mask entry, V - value entry, A - adjacency index, NR- no_route bit LS - load sharing count, RI - router_ip bit, DF: default bit CP - copy_to_cpu bit, AS: dest_AS_number, DGTv - dgt_valid bit DGT: dgt/others value Format:IPV4 (valid class vpn prefix) M(262 ): 1 F 2FFF 255.255.255.255 V(262 ): 1 0 0 1.1.1.1 (A:114689, LS:0, NR:0, RI:0, DF:0 CP:0 DGTv:1, DGT:0)
Infine, la voce adiacente mostra come il pacchetto viene riscritto e se il traffico viene riscritto da questa voce adiacente:
MXC.CALO.Sup2T-dfc3#show platform hardware cef adjacencies entry 114689 detail RIT fields: The entry has a Layer2 Format _________________________________________________________ |decr_ttl = YES | pipe_ttl = 0 | utos = 0 |_________________|__________________|____________________ |l2_fwd = 0 | rmac = 0 | ccc = L3_REWRITE |_________________|__________________|____________________ |rm_null_lbl = YES| rm_last_lbl = YES| pv = 0 |_________________|__________________|____________________ |add_shim_hdr= NO | rec_findex = N/A | rec_shim_op = N/A |_________________|__________________|____________________ |rec_dti_type = N/A | rec_data = N/A |____________________________________|____________________ |modify_smac = YES| modify_dmac = YES| egress_mcast = NO |____________________________________|____________________ |ip_to_mac = NO |_________________________________________________________ |dest_mac = 0c11.678b.f6f7 | src_mac = d8b1.902c.9680 |___________________________|_____________________________ | Statistics: Packets = 642 Bytes = 75756 <<<<
dest_mac e src_mac sono i valori di interesse principale, che indicano le nuove intestazioni L2 scritte per questo pacchetto. L'indirizzo MAC di destinazione 0c11.678b.f6f7 è 10.1.2.1, ossia 3850 (hop successivo per raggiungere la versione 1.1.1.1):
MXC.CALO.Sup2T#show ip arp 10.1.2.1 Protocol Address Age (min) Hardware Addr Type Interface Internet 10.1.2.1 30 0c11.678b.f6f7 ARPA Vlan2
Inoltre, il campo Statistics mostra che il traffico raggiunge effettivamente questa voce adiacente e le intestazioni L2 vengono riscritte di conseguenza.
L'eliminazione di voci CEF può essere utile per eliminare qualsiasi voce programmata in modo errato (ad esempio in una voce adiacente errata) o anche a scopo di training. Consente inoltre di modificare un percorso di routing.
Per eliminare una voce CEF, è necessario comprendere che le voci CEF sono programmate in sequenza e a esse è assegnato un indice hardware, ad esempio:
MXC.CALO.Sup2T-dfc3#show platform cef vpn 0
Codici: decap - Decapsulamento, + - Etichetta Push
MXC.CALO.Sup2T-dfc3#show platform hardware cef vpn 0
...
Index Prefix Adjacency 259 10.1.2.255/32 receive 260 10.1.1.1/32 Vl1 ,a0ec.f930.3f40 261 10.1.2.1/32 Vl2 ,0c11.678b.f6f7 262 1.1.1.1/32 Vl2 ,0c11.678b.f6f7 <<<< Our CEF entry of interest has a HW index of 262.
...
Questo indice hardware è l'elemento più importante per eliminare una voce CEF poiché viene utilizzato come riferimento. Tuttavia, per apportare modifiche, è necessario convertirla in un handle di software. Per ottenere questo risultato, usare il comando test platform hardware cef index-conv hw_to_sw [hw index]
MXC.CALO.Sup2T-dfc3#test platform hardware cef index-conv hw_to_sw 262 hw index: 262 ----> sw handle: 101
Ora che si conosce l'handle del software, è possibile procedere con l'eliminazione della voce CEF con il comando test platform hardware cef v4-delete [sw handle] mask [mask length] vpn [dec]
MXC.CALO.s2TVSS-sw2-dfc3#test platform hardware cef v4-delete 101 mask 32 vpn 0 test_ipv4_delete: done.
Nota: Il valore della lunghezza della maschera è 32 perché si tratta di una route specifica dell'host (1.1.1.1/32)
A questo punto, la voce CEF viene eliminata:
MXC.CALO.Sup2T-dfc3#show platform hard cef vpn 0 1.1.1.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency MXC.CALO.Sup2T-dfc3#show platform hard cef vpn 0 [snip...] 259 10.1.2.255/32 receive 260 10.1.1.1/32 Vl1 ,a0ec.f930.3f40 261 10.1.2.1/32 Vl2 ,0c11.678b.f6f7 288 224.0.0.0/24 receive <<<<<<< Index 262 no longer exists in the CEF entries. 289 10.1.85.0/24 glean
Si noti che il comando test platform hardware cef vpn 0 è stato eseguito al prompt DFC. In questo modo, la voce CEF è stata rimossa dalla tabella CEF di DFC e NON dal supervisore, è necessario prestare attenzione a quale motore di inoltro le voci vengono rimosse.
Una variazione del traffico potrebbe non avere visibilità (nel caso di un test di laboratorio), a causa dell'impatto di un'altra voce CEF. Considerare sempre la corrispondenza con quella più esatta (maschera più lunga). In questo laboratorio, colpisce:
MXC.CALO.Sup2T-dfc3#show plat hard cef vpn 0 lookup 1.1.1.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 262048 0.0.0.0/0 glean
Qual è la funzione effettiva di questa voce sul pacchetto?
MXC.CALO.Sup2T-dfc3#show platform hardware cef adjacencies entry 262048
RIT fields: The entry has a Recirc. Format _________________________________________________________ |decr_ttl=NO | l2_fwd=NO | ccc = 6 | add_shim_hdr = YES |_____________|____________|_________|____________________ |rc_fidx=0 | rc_shimop=1 | rc_dti_type=4 | rc_data = 0x10B |____________|_____________|_______________|______________ Statistics: Packets = 2163 Bytes = 255234
Taken from a CPU packet capture using Catlayst 6500 NETDR tool. For NETDR capture tool details refer to: Catalyst 6500 Series Switches Netdr Tool for CPU-Bound Packet Captures ------- dump of incoming inband packet ------- l2idb Po1, l3idb Vl1, routine inband_process_rx_packet, timestamp 01:00:17.841 dbus info: src_vlan 0x1(1), src_indx 0xB40(2880), len 0x82(130) bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x5FA4(24484), CoS 0 cap1 0, cap2 0 78020800 00018400 0B400100 82000000 1E000464 2E000004 00000010 5FA45BDD destmac D8.B1.90.2C.96.80, srcmac A0.EC.F9.30.3F.40, shim ethertype CCF0 earl 8 shim header IS present: version 0, control 64(0x40), lif 1(0x1), mark_enable 1, feature_index 0, group_id 0(0x0), acos 0(0x0), ttl 14, dti 4, dti_value 267(0x10B) 10000028 00038080 010B ethertype 0800 protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 100, identifier 51573 df 0, mf 0, fo 0, ttl 255, src 10.1.1.1, dst 1.1.1.1 icmp type 8, code 0 ------- dump of outgoing inband packet ------- l2idb NULL, l3idb Vl2, routine etsec_tx_pak, timestamp 01:03:56.989 dbus info: src_vlan 0x2(2), src_indx 0x380(896), len 0x82(130) bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x0(0), CoS 0 cap1 0, cap2 0 00020000 0002A800 03800000 82000000 00000000 00000000 00000000 00000000 destmac 0C.11.67.8B.F6.F7, srcmac D8.B1.90.2C.96.80, shim ethertype CCF0 earl 8 shim header IS present: version 0, control 0(0x0), lif 16391(0x4007), mark_enable 0, feature_index 0, group_id 0(0x0), acos 0(0x0), ttl 15, dti 0, dti_value 540674(0x84002) 000800E0 0003C008 4002 ethertype 0800 protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 100, identifier 50407 df 0, mf 0, fo 0, ttl 254, src 10.1.1.1, dst 1.1.1.1 icmp type 8, code 0
Ora, tutto il traffico la cui destinazione è 1.1.1.1 e che entra attraverso la scheda di linea 3 viene ricircolato con intestazione shim e puntato alla CPU. A volte, invece di questa voce CEF, si vede un altro 0.0.0.0/0 con drop adiacente e fa la stessa cosa.
Nota: Valuta quali voci CEF vengono rimosse. Ciò può causare un utilizzo elevato della CPU. In genere, viene configurato un percorso predefinito 0.0.0.0/0 e il traffico viene inoltrato in base a esso (causando la perdita di pacchetti).
Quando si aggiunge una voce CEF, nella maggior parte dei casi risolve qualsiasi problema di programmazione errata che causa la perdita, il ritardo o l'utilizzo elevato della CPU. La conoscenza di come installare le voci CEF nell'hardware permette non solo di correggere una voce mal programmata, ma anche di manipolare l'inoltro dei pacchetti il ricircolo del pacchetto, lo indirizzano a un'interfaccia completamente diversa o all'hop successivo, riscrivono il pacchetto come desiderato e/o lo scartano, ecc. Tutto questo, senza dover ricaricare la scatola, rimuovere e impostare la configurazione o qualsiasi apparente modifica. La voce CEF l'aggiunta può essere effettuata senza accedere anche alla modalità di configurazione. (come è stato fatto anche con la procedura di rimozione dell'ingresso CEF descritta nella sezione precedente).
Fondamentalmente, ci sono due situazioni qui, quando si ha una voce ARP valida per l'hop successivo, in questo caso 10.1.2.1 e quando non lo si ha (per qualsiasi motivo). La seconda situazione forza la creazione effettiva di una voce ARP valida (tramite ARP statico):
Passaggio 1. Nello switch è presente una voce ARP per 10.1.2.1, ossia l'hop successivo per 1.1.1.1.
MXC.CALO.Sup2T#show ip arp 10.1.2.1 Protocol Address Age (min) Hardware Addr Type Interface Internet 10.1.2.1 2 0c11.678b.f6f7 ARPA Vlan2 MXC.CALO.Sup2T#show ip route | inc 1.1.1.1 S 1.1.1.1 [1/0] via 10.1.2.1
Una voce ARP viene programmata come percorso host ( /32 ) nella tabella CEF:
MXC.CALO.Sup2T-dfc3#show plat hard cef vpn 0 look 10.1.2.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 53 10.1.2.1/32 Vl2 ,0c11.678b.f6f7 And of course, there is an index for this which again will tell us how a packet should be rewritten to reach 10.1.2.1: MXC.CALO.Sup2T-sw2-dfc3#show plat hard cef vpn 0 10.1.2.1 detail [snip...] Format:IPV4 (valid class vpn prefix) M(53 ): 1 F 2FFF 255.255.255.255 V(53 ): 1 0 0 10.1.2.1 (A:114689, LS:0, NR:0, RI:0, DF:0 CP:0 DGTv:1, DGT:0) Wait, wasn't 114689 adj entry the same used for 1.1.1.1?: MXC.CALO.Sup2T-sw2-dfc3#show plat hard cef 1.1.1.1 de [snip...] Format:IPV4 (valid class vpn prefix) M(54 ): 1 F 2FFF 255.255.255.255 V(54 ): 1 0 0 1.1.1.1 (A:114689, LS:0, NR:0, RI:0, DF:0 CP:0 DGTv:1, DGT:0)
Tutti i pacchetti con indirizzi IP di destinazione con lo stesso data link nell'hop successivo devono essere inoltrati tramite la stessa interfaccia e riscritti con le stesse intestazioni L2.
Anche se può sembrare piuttosto ovvio in un primo momento, in realtà è l'elemento più importante per aggiungere una voce CEF, è necessario dirgli come un pacchetto deve essere riscritto con una voce CEF adiacente specifica.
Passaggio 2. Si supponga ora che non vi sia alcuna voce ARP creata automaticamente per questa operazione, quindi è necessario creare una voce ARP statica.
A tale scopo, è necessario conoscere l'indirizzo MAC del dispositivo utilizzato come hop successivo per il prefisso 10.1.2.1, quindi viene inviato a 0c11.678b.f6f7. Se esiste già una voce Indirizzo MAC nell'output del comando show mac address-table address 0c11.678b.f6f7 corretta, in caso contrario è necessario creare una voce MAC statica:
MXC.CALO.Sup2T(config)#mac address-table static 0c11.678b.f6f7 vlan 2 int Gi3/21 Displaying entries from DFC switch [2] linecard [3]: vlan mac address type learn age ports ----+----+---------------+-------+-----+----------+----------------------------- 2 0c11.678b.f6f7 static No - Gi3/21
Passaggio 3. Infine, per programmare una voce CEF, è necessario creare una voce ARP statica:
MXC.CALO.Sup2T(config)#arp 10.1.2.1 0c11.678b.f6f7 arpa <<< Static ARP configuration MXC.CALO.Sup2T#show ip arp 10.1.2.1 Protocol Address Age (min) Hardware Addr Type Interface Internet 10.1.2.1 - 0c11.678b.f6f7 ARPA <<< Now the static ARP entry is complete
// Attaching to DFC3...
MXC.CALO.Sup2T-sw2-dfc3#show plat hard cef 10.1.2.1 detail [snip...] Format:IPV4 (valid class vpn prefix) M(53 ): 1 F 2FFF 255.255.255.255 V(53 ): 1 0 0 10.1.2.1 (A:114689, LS:0, NR:0, RI:0, DF:0 CP:0 DGTv:1, DGT:0)
The ARP entry exist in CEF table for DFC3. Same Adjacency Index result as before...
Una volta comprese le funzioni di queste voci adiacenti, è possibile aggiungere una voce CEF. Nell'ultima sezione, la voce CEF per il prefisso 1.1.1.1/32 è stata eliminata tramite il comando cef v4-delete della piattaforma di test. A questo punto, aggiungerlo nuovamente tramite il comando test platform hardware cef v4-insert [prefix] [lunghezza maschera] vpn [numero vpn] adiacenza [indice adiacenza]
Per verificare questa condizione, utilizzare il comando test platform hardware cef v4-insert 1.1.1.1 32 vpn 0 adiacency 114689. La voce è stata aggiunta nuovamente nella tabella DFC CEF:
MXC.CALO.Sup2T-sw2-dfc3#test platform hardware cef v4-insert 1.1.1.1 32 vpn 0 adjacency 114689 test_ipv4_insert: done: sw_index = 42 MXC.CALO.Sup2T-sw2-dfc3#show plat hard cef vpn 0 1.1.1.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 54 1.1.1.1/32 Vl2 ,0c11.678b.f6f7 Ping from the 3750X to Loopback 0 is successful and HW forwarded by 6500 DFC. MXC.CALO.Sup2T-sw2-dfc3#show platform hard cef adj entry 114689 Index: 114689 -- Valid entry (valid = 1) -- RIT fields: The entry has a Layer2 Format _________________________________________________________ |decr_ttl=YES | l2_fwd=NO | ccc = 4 | add_shim_hdr = NO |_____________|____________|_________|____________________ Statistics: Packets = 684 Bytes = 80712
// Logs in 3850
CALO.MXC.385024XU#show logging [snip...] *Jan 23 05:59:56.911: ICMP: echo reply sent, src 1.1.1.1, dst 10.1.1.1, topology BASE, dscp 0 topoid 0 *Jan 23 05:59:57.378: ICMP: echo reply sent, src 1.1.1.1, dst 10.1.1.1, topology BASE, dscp 0 topoid 0 *Jan 23 05:59:57.390: ICMP: echo reply sent, src 1.1.1.1, dst 10.1.1.1, topology BASE, dscp 0 topoid 0
Per tutta la configurazione effettuata da tutti i passaggi precedenti, è stata applicata la stringa vpn 0 nei comandi show platform hardware cef. Anche se sembra completamente superfluo poiché il comando restituisce per impostazione predefinita le voci per la tabella di routing generale o per la vpn 0, l'operazione è stata effettuata apposta per: tenere sempre presente che le voci vengono aggiunte o eliminate da istanze specifiche della tabella di routing (VRF), tramite il documento aggiunto ed eliminato alla voce CEF 1.1.1.1/32. Tuttavia, è molto probabile che alcuni prefissi esistano in VRF diverse (i. e. 10 x x x x) ed eliminare, aggiungere o modificare una voce CEF per un VRF errato può causare un impatto negativo.
Eliminare una voce CEF con prefisso 1.1.1.1/32 per VRF TEST_VRF. Per una descrizione dettagliata dell'aggiunta di voci CEF, fare riferimento alla sezione Aggiunta di una voce CEF in questo documento.
Per aggiungere il VRF, modificare le SVI dello switch 6500 sul VRF proposto con il comando ip vrf forwarding [VRF-NAME] e infine aggiungere la stessa route statica nella tabella TEST_VRF:
MXC.CALO.Sup2T(config)#ip vrf TEST_VRF MXC.CALO.Sup2T(config-vrf)#int vlan 1 MXC.CALO.Sup2T(config-if)#ip vrf forwarding TEST_VRF % Interface Vlan1 IPv4 disabled and address(es) removed due to enabling VRF TEST_VRF MXC.CALO.Sup2T(config-if)#ip add 10.1.1.10 255.255.255.0 MXC.CALO.Sup2T(config-if)#int vlan 2 MXC.CALO.Sup2T(config-if)#ip vrf forwarding TEST_VRF % Interface Vlan2 IPv4 disabled and address(es) removed due to enabling VRF TEST_VRF MXC.CALO.Sup2T(config-if)#ip add 10.1.2.10 255.255.255.0 MXC.CALO.Sup2T(config)#ip route vrf TEST_VRF 1.1.1.1 255.255.255.255 10.1.2.1
MXC.CALO.Sup2T#show ip vrf
Name Default RD Interfaces
TEST_VRF <not set> Vl1
Vl2
Anche i VRF vengono programmati in sequenza. Questo è il primo VRF nello switch (nessun altro VRF era stato configurato in precedenza), quindi il numero vpn per questa istanza VRF dovrebbe essere 1. Eseguire il comando show platform hardware cef vpn 1 per verificare che questa condizione sia vera:
MXC.CALO.Sup2T-sw2-dfc3#show plat hard cef vpn 1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 34 10.1.1.10/32 receive 35 10.1.1.0/32 receive 36 10.1.1.255/32 receive 38 10.1.2.10/32 receive 43 10.1.2.0/32 receive 44 10.1.2.255/32 receive 53 10.1.2.1/32 Vl2 ,0c11.678b.f6f7 54 1.1.1.1/32 Vl2 ,0c11.678b.f6f7 [snip...] However, usually, switches have hundred or thousands of VRFs and just count them in the 'show ip vrf' command output would be quite difficult. In order to know which VPN number is assigned to a VRF we will run the command "show platform hardware cef vrf [VRF name] [prefix] detail", it will return the actual vpn number for that VRF: Format:IPV4 (valid class vpn prefix) M(54 ): 1 F 2FFF 255.255.255.255 V(54 ): 1 0 1 1.1.1.1 <<<<<<<<<<< The number in red determines the VPN this prefix belongs to. (A:114689, LS:0, NR:0, RI:0, DF:0 CP:0 DGTv:1, DGT:0)
È importante conoscere il numero VPN effettivo e l'indice software per questa voce in modo da poter procedere all'eliminazione o all'aggiunta da/a questa istanza VRF:
MXC.CALO.Sup2T-sw2-dfc3#test platform hardware cef index-conv hw_to_sw 54 hw index: 54 ----> sw handle: 42 MXC.CALO.Sup2T-sw2-dfc3#test platform hardware cef v4-delete 42 mask 32 vpn 1 test_ipv4_delete: done. Result: MXC.CALO.Sup2T-sw2-dfc3#show platform hardware cef vpn 1 lookup 1.1.1.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 262049 0.0.0.0/0 drop Traffic is now getting punted, and the effects are seen in the 3750X pings to 1.1.1.1: MXC.CALO.3750X#ping 1.1.1.1 repe 5000000 Sending 5000000, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!! [snip...]
// Packet loss
Si supponga che, in una rete di produzione, si verifichino perdite di pacchetti e audio instabile o video errato a causa delle seguenti condizioni della CEF. Si consiglia pertanto di eseguire questi test in una finestra di manutenzione.