O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como o Cisco Catalyst 6500 com Supervisor Sup2T programa as entradas CEF (Cisco Express Forwarding) configuradas no software Cisco IOS no hardware de placas de linha usado para alcançar o encaminhamento de pacotes.
A Cisco recomenda que você tenha conhecimento destes tópicos:
Cisco Catalyst 6500 Series Switches
As informações neste documento são baseadas nas seguintes versões de hardware e software:
Placa de linha Cisco Catalyst 6500 WS-X6848-GE-TX (com DFC4).
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
O CEF como um mecanismo de comutação de Camada 3 é usado pela maioria dos switches multicamada da Cisco.É essencial que os engenheiros de rede entendam como o CEF funciona para solucionar problemas de interrupções de rede, perda de pacotes ou cenários de atraso de pacotes diariamente.
O supervisor Sup2T em modo autônomo ou como VSS é atualmente implantado por muitas redes corporativas como um switch central, agrega praticamente todos os outros dispositivos de roteamento ou comutação. Isso também significa que o encaminha a maior parte do tráfego intra e inter domínios para entregar com êxito os pacotes aos seus destinos. Para que isso seja alcançado, o Sup2T deve ter informações de roteamento apropriadas aprendidas estática ou dinamicamente através de protocolos de roteamento.
Em um chassi modular, podem existir vários mecanismos de encaminhamento além do supervisor. Determinadas placas de linha (especialmente as de nova geração, como C6800-32P10G) já incluem seu próprio mecanismo de encaminhamento para aprimorar o desempenho de comutação de pacotes, a pesquisa de entradas CEF é executada localmente e faz com que os recursos sejam melhor distribuídos para o tráfego que entra em diferentes placas de linha. Essas placas são conhecidas como placas de encaminhamento distribuído (DFCs).
Essas entradas de CEF compartilhadas em todos os mecanismos de encaminhamento podem falhar ao serem alocadas no HW por várias razões, desde uma condição de defeito de software, esgotamento de recursos até condições de alta CPU e impede que o switch tenha tempo suficiente para atualizar todas as entradas, o que pode causar uma série de eventos indesejáveis.
Rede:
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
No diagrama, um switch 6506 autônomo tem um Supervisor 2T instalado, bem como uma placa de linha WS-6848-GE-TX com uma DFC no slot 3. O host 3750X que está conectado à placa de linha através da porta G3/1 envia tráfego para o endereço Loopback 0 1.1.1.1 do 3850.
Para isso, o 3750X tem uma rota estática para o endereço IP 1.1.1.1 até o próximo salto 10.1.1.10, que é o SVI da VLAN 1 no switch Sup2T. O switch Sup2T precisa rotear esse tráfego para o switch 3850 com base em uma entrada de rota estática para IP 1.1.1.1/32 através do próximo salto 10.1.2.1, que é a interface 3850 conectada ao Sup2T na 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
Lembre-se de que, por uma questão de simplicidade, os switches 3750X e 3850 são conectados ao 6500 através da mesma placa de linha. Isso significa que o tráfego também é pesquisado localmente e encaminhado localmente.
Um pacote entra no switch Sup2T através da Gi3/1, eventualmente, alcança o mecanismo de encaminhamento (já que isso é uma DFC). O mecanismo de encaminhamento analisa o campo de endereço IP de destino nesse pacote e consulta as entradas CEF programadas para obter a melhor correspondência (Máscara mais longa).
Como essa é uma placa DFC, significa que ela tem suas próprias entradas de CEF e para verificá-las, é necessário que nós conectemos à placa de linha com o comando attach [dec] ou attach switch [1-2] mod [dec] para VSS.
Agora, você deve estar no prompt da DFC, o comando show platform hardware cef ou show platform hardware cef vpn 0 retornará todas as entradas CEF programadas para a tabela de roteamento geral (VPN 0/ Sem VRF).
Como o objetivo é o prefixo 1.1.1.1/32, você usa o comando show platform hardware cef vpn 0 lookup 1.1.1.1. O comando retorna a melhor correspondência para o prefixo 1.1.1.1 e aquele que ele usa para realmente encaminhar o tráfego:
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
A entrada CEF está lá, ela foi programada como resultado de nossa entrada estática programada no software IOS através do comando ip route 1.1.1.1 255.255.255.255 10.1.2.1.
Você também pode verificar se essa entrada recebe acertos e se o tráfego é encaminhado com essa entrada através dos comandos show platform hardware cef 1.1.1.1 detail que retorna uma entrada de adjacência:
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)
Finalmente, a entrada de adjacência mostra como o pacote é regravado e se o tráfego é regravado por esta entrada de adjacência:
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 <<<<
Os valores dest_mac e src_mac são os que têm interesse principal, indicando os novos cabeçalhos L2 que são escritos para esse pacote. O endereço MAC destino 0c11.678b.f6f7 é 10.1.2.1, que é o 3850 (próximo salto para acessar 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
Além disso, o campo Statistics mostra que o tráfego está realmente atingindo essa entrada de adjacência e os cabeçalhos L2 são reescritos de acordo.
Excluir entradas CEF pode nos ajudar a excluir qualquer entrada que possa estar programada incorretamente (para uma entrada de adjacência errada, por exemplo) ou até mesmo para fins de treinamento. Ele também fornece uma maneira de modificar um caminho de roteamento.
Para excluir uma entrada CEF, você precisa entender que as entradas CEF são programadas sequencialmente e têm um Índice de hardware atribuído, por exemplo:
MXC.CALO.Sup2T-dfc3#show platform hardware cef vpn 0
Códigos: decap - Desencapsulamento, + - Rótulo de envio
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.
...
Este índice de hardware é o elemento mais importante para excluir uma entrada de CEF, pois é usado como referência. No entanto, para fazer qualquer alteração nele, ele deve ser convertido em um identificador de software. Você pode conseguir isso com o 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
Agora que você conhece o identificador de software, pode continuar com a exclusão de entrada CEF com o 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.
Note: O valor do comprimento da máscara é 32, pois essa é uma rota específica de host (1.1.1.1/32)
Agora, nossa entrada CEF é excluída:
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
Observe que o comando test platform hardware cef vpn 0 foi executado no prompt da DFC. Dessa forma, a entrada CEF foi removida da tabela CEF da DFC e NÃO do supervisor. Você deve ter muito cuidado com o mecanismo de encaminhamento do qual as entradas são removidas.
Uma alteração no tráfego tem o risco de não ter visibilidade (no caso de um teste de laboratório), isso pode ser devido ao acerto de outra entrada CEF. Considere sempre corresponder a máscara mais exata (máscara mais longa). Neste laboratório, ele atinge:
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
Então, o que essa entrada realmente faz com o pacote?:
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
Agora, todo o tráfego com destino 1.1.1.1 que entra pela placa de linha 3 é recirculado com o cabeçalho de calço e lançado para a CPU. Às vezes, em vez dessa entrada CEF, outra adjacência 0.0.0.0/0 com drop é vista e faz exatamente a mesma coisa.
Note: Avalie quais entradas CEF foram removidas. Um alto nível de utilização da CPU pode ser causado por isso. Geralmente, uma rota padrão 0.0.0.0/0 é configurada e o tráfego é encaminhado com base nela (e causa perda de pacotes).
Quando uma entrada CEF é adicionada, na maioria dos casos resolve qualquer problema de programação incorreta que causa perda de pacotes, atraso de pacotes ou alta utilização da CPU. O conhecimento de como instalar as entradas CEF no hardware não só fornece a capacidade de corrigir uma entrada mal programada, mas também de manipular qualquer encaminhamento de pacote por meio da recirculação do pacote, apontá-lo para uma interface completamente diferente ou para o próximo salto, regravar um pacote roteado conforme desejado e/ou descartá-lo, etc. Tudo isso, sem recarregar a caixa, remova e defina a configuração ou qualquer alteração aparente. A adição de entrada CEF pode ser feita sem entrar no modo de configuração também. (Como você também fez com o procedimento de remoção de entrada CEF explicado na seção anterior).
Basicamente, há duas situações aqui, quando você tem uma entrada ARP válida para o próximo salto, nesse caso 10.1.2.1 e quando não tem (por qualquer razão). A segunda situação força você a criar realmente uma entrada ARP válida (via ARP estático):
Etapa 1. Há uma entrada ARP no switch para 10.1.2.1, que é o próximo salto para 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
Uma entrada ARP é programada como uma rota de host ( /32 ) na tabela 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)
Qualquer pacote com qualquer endereço IP destino que tenha o mesmo salto seguinte de enlace de dados deve ser encaminhado através da mesma interface e regravado com os mesmos cabeçalhos L2.
Embora isso possa parecer bastante óbvio a princípio, na verdade é o elemento mais importante para adicionar uma entrada de CEF, você precisa dizer a ele como um pacote deve ser regravado com uma entrada de adjacência de CEF específica.
Etapa 2. Agora, suponha que não haja nenhuma entrada ARP criada automaticamente para isso, portanto, você precisa criar uma entrada ARP estática.
Para fazer isso, você precisa saber o endereço MAC do dispositivo que é usado como o próximo salto para o prefixo 10.1.2.1, para que ele seja enviado para 0c11.678b.f6f7. Se já houver uma entrada de endereço MAC na saída do comando show mac address-table address 0c11.678b.f6f7 que é boa, se não, então você precisa criar uma entrada MAC estática:
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
Etapa 3. Finalmente, uma entrada ARP estática precisa ser criada para que uma entrada CEF seja programada:
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...
Agora que você entendeu o que essas entradas de adjacência fazem, pode finalmente continuar adicionando uma entrada de CEF. Na última seção, a entrada CEF para o prefixo 1.1.1.1/32 foi excluída por meio do comando test platform hardware cef v4-delete. Agora, adicione-o novamente através do comando test platform hardware cef v4-insert [prefix] [mask length] vpn [vpn number] adjacency [adjacency index]
Para verificar isso, use o comando test platform hardware cef v4-insert 1.1.1.1 32 vpn 0 adjacency 114689. A entrada foi adicionada de volta na tabela CEF da DFC:
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
Durante toda a configuração feita a partir de todas as etapas anteriores, a sequência de caracteres vpn 0 nos comandos show platform hardware cef foi aplicada. Mesmo que pareça completamente desnecessário, já que o comando por padrão retorna as entradas para a tabela de roteamento geral ou vpn 0, isso foi feito de propósito para sempre ter em mente que as entradas são adicionadas ou excluídas de instâncias específicas da tabela de roteamento (VRFs), através do documento que você adicionou e excluiu a entrada de CEF 1.1.1.1/32. No entanto, é muito provável que certos prefixos existam em VRFs diferentes (i. e. 10.x.x.x) e excluir, adicionar ou modificar uma entrada CEF para um VRF incorreto pode causar um impacto negativo.
Exclua uma entrada CEF com o prefixo 1.1.1.1/32 para VRF TEST_VRF. Para obter uma descrição detalhada da adição de entradas de CEF, consulte a seção Adicionar uma Entrada de CEF deste documento.
Para adicionar o VRF, altere os SVIs no switch 6500 para o VRF proposto com o comando ip vrf forwarding [VRF-NAME] e, finalmente, adicione a mesma rota estática em nossa tabela 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
Os VRFs também são programados sequencialmente. Este foi o primeiro VRF no switch (nenhum outro VRF foi configurado anteriormente), portanto, o número de vpn para esta instância de VRF deve ser 1. Execute o comando show platform hardware cef vpn 1 para verificar se isso é verdade:
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 saber o número de VPN real e o índice de software para esta entrada para que você possa continuar a excluí-lo ou adicioná-lo de/para esta instância de 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
Considere que, em uma rede de produção, ocorre perda de pacotes e áudio cortado ou vídeo ruim devido à condição dessas entradas de CEF. Portanto, é recomendável executar esses testes em uma janela de manutenção.
Feedback