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 pesquisar defeitos caídas de entrada na relação no Roteadores XR.
Não existem requisitos específicos para este documento.
Este artigo cobre 9000 Series Router ASR, Series Router CR e Series Router GSR12000.
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.
As caídas de entrada em IO XR têm um significado completamente diferente do que aquele das caídas de entrada nos IO. Pode confundi-lo quando migra IO a IO XR e os começa ver seus contadores da caída de entrada na relação da mostra.
Nos IO, uma caída de entrada era devido à fila de entrada de interface que obtém completamente. Isto significa que pacotes demais punted ao CPU para o processo que comuta e não podia os segurar rapidamente bastante. A fila de entrada está acumulada até que obtenha completamente e houver algumas gotas.
Em IO XR, não há nenhuma definição restrita de uma caída de entrada. Assim é basicamente até os colaboradores de um componente para decidir se querem incrementar o contador da caída de entrada quando decidem deixar cair um pacote. A coisa chave aqui é aquela a dada altura do código, o roteador decide deixar cair o pacote de modo que signifique que é provável que o roteador não esteve suposto enviar que o pacote e o roteador decidem conscientemente o deixar cair. Consequentemente, isto não é relacionado à congestão como em IO. Contudo, é um pouco um pacote que sejam recebidos pelo roteador e que não fosse suposto ser enviado assim que o roteador decidiu deixá-lo cair e é muito provável não uma razão ser alarmado. Embora, você não possa dizer se é algo se preocupar aproximadamente ou não até que você compreendeu completamente o tipo dos pacotes que estão incrementando o contador da caída de entrada e que não é aquele simples, infelizmente.
Exemplos:
Quando as caídas de entrada são relatadas, o problema é figurar para fora se estas são gotas legítimas como no exemplo 1 ou a consequência de um problema como no exemplo 2.
Este documento recruta as razões para que as caídas de entrada que está incrementado e como verifique se é essa razão:
Runts, sequência de verificação de frame (FCS), abortos, excessos da saída da primeira entrada primeiros (FIFO), pacote dos gigantes sobre gotas SDH/SONET (POS).
RP/0/RP0/CPU0:equinox#show controllers poS 0/2/0/0 framer statistics POS Driver Internal Cooked Stats Values for port 0 =================================================== Rx Statistics Tx Statistics ------------- ------------- Total Bytes: 71346296 Total Bytes: 67718333 Good Bytes: 71346296 Good Bytes: 67718333 Good Packets: 105385 Good Packets: 67281 Aborts: 0 Aborts: 0 FCS Errors: 0 Min-len errors: 0 Runts: 0 Max-len errors: 0 FIFO Overflows: 0 FIFO Underruns: 0 Giants: 0 Drops: 0 RP/0/RP0/CPU0:equinox#
Para um Ethernet (gige, tengige…) relação, verificação algo como:
mostre a controladores o gigabitethernet 0/0/0/18 de stats
Veja se há um contador no stats do controlador que incrementa na mesma taxa que o contador da caída de entrada na relação da mostra. Alguns destes contadores de erros devem igualmente estar na relação da mostra.
Pacotes com um endereço MAC de destino não essa da relação ou com uma rede de área local virtual (VLAN) não combinada por uma subinterface. Estes podem acontecer quando há alguma inundação em um domínio L2 de endereços do unicast desconhecido MAC assim que o roteador XR conectado a esse domínio L2 recebe quadros com um endereço MAC de destino que não seja um de seus controladores. É igualmente possível quando um IOS Router está enviando o Keepalives dos Ethernet em sua relação do gige assim que este Keepalives está incrementando as caídas de entrada no roteador XR porque não tem o endereço MAC de destino do roteador XR. Ou quando a relação for conectada a um outro dispositivo que tenha mais vlans/subinterfaces do dot1q configurados como no roteador XR de modo que o roteador XR receba quadros com uma etiqueta desconhecida do dot1q.
No CR os módulos de interface da camada física fixados (PLIM), você poderia encontrar tais gotas em:
RP/0/RP0/CPU0:pixies-uk#sh contr plim asic statistics interface tenGigE 0/1/0/3 location 0/1/CPU0 Wed Aug 22 16:07:47.854 CEST Node: 0/1/CPU0 TenGigE0/1/0/3 Drop ------------------------------------------------------------------------------- RxFiFO Drop : 0 PAR Tail Drop : 0 PAR Err Drop : 0 Invalid MAC Drop : 86 TxFIFO Drop : 0 Invalid VLAN Drop : 11
Ou no stats do controlador do tengige ou do gige:
RP/0/RP0/CPU0:pixies-uk#sh contr ten 0/1/0/3 stats Wed Aug 22 16:22:42.059 CEST Statistics for interface TenGigE0/1/0/3 (cached values): Ingress: Input drop overrun = 0 Input drop abort = 0 Input drop invalid VLAN = 11 Input drop invalid DMAC = 0 Input drop invalid encap = 0 Input drop other = 86
Nota: O erro CSCub74803 existe, caída de entrada que outro é incrementado em vez da caída de entrada DMAC inválido pelo menos no 8-port PLIM fixado tengige dos CR.
Para adaptadores de porta compartilhados (termas) (CR, XR 12000), os pacotes com MAC inválido seriam deixados cair pelos TERMAS l2-tcam assim que você pode encontrar estas gotas em controladores TenGigE a/b/c/d todo da mostra:
Input drop other = 107 l2-tcam Invalid DA Drops: 107
Em um ASR 9000, na caída de entrada DMAC inválido e na caída de entrada que outros contadores no stats do controlador não são incrementados. Assim a maneira de reconhecer estas gotas no ASR 9000 é encontrar o NP segurar a relação com as caídas de entrada:
RP/0/RSP0/CPU0:obama#sh int gig 0/0/0/30 | i "input drops" Wed Aug 22 16:55:52.374 CEST 1155 packets input, 156256 bytes, 1000 total input drops RP/0/RSP0/CPU0:obama#sh contr np ports all location 0/0/CPU0 Wed Aug 22 16:56:01.385 CEST Node: 0/0/CPU0: ---------------------------------------------------------------- NP Bridge Fia Ports -- ------ --- --------------------------------------------------- 0 0 0 GigabitEthernet0/0/0/30 - GigabitEthernet0/0/0/39 1 0 0 GigabitEthernet0/0/0/20 - GigabitEthernet0/0/0/29 2 1 0 GigabitEthernet0/0/0/10 - GigabitEthernet0/0/0/19 3 1 0 GigabitEthernet0/0/0/0 - GigabitEthernet0/0/0/9 RP/0/RSP0/CPU0:obama#
Assim você pode ver que a atuação 0/0/0/30 da relação está segurada pelo NP 0 em 0/0/CPU0.
Deixe-nos verificar os contadores NP de NP0 em 0/0/CPU0:
RP/0/RSP0/CPU0:obama#sh contr np counters np0 location 0/0/CPU0 Wed Aug 22 16:56:19.883 CEST Node: 0/0/CPU0: ---------------------------------------------------------------- Show global stats counters for NP0, revision v3 Read 26 non-zero NP counters: Offset Counter FrameValue Rate (pps) ------------------------------------------------------------------------------- 22 PARSE_ENET_RECEIVE_CNT 1465 0 23 PARSE_FABRIC_RECEIVE_CNT 2793 0 24 PARSE_LOOPBACK_RECEIVE_CNT 2800 0 28 MODIFY_FABRIC_TRANSMIT_CNT 80 0 29 MODIFY_ENET_TRANSMIT_CNT 1792 0 32 RESOLVE_INGRESS_DROP_CNT 1000 0 35 MODIFY_EGRESS_DROP_CNT 1400 0 36 MODIFY_MCAST_FLD_LOOPBACK_CNT 1400 0 38 PARSE_INGRESS_PUNT_CNT 465 0 39 PARSE_EGRESS_PUNT_CNT 155 0 45 MODIFY_RPF_FAIL_DROP_CNT 1400 0 53 PARSE_LC_INJECT_TO_FAB_CNT 80 0 54 PARSE_LC_INJECT_TO_PORT_CNT 864 0 57 PARSE_FAB_INJECT_UNKN_CNT 155 0 67 RESOLVE_INGRESS_L3_PUNT_CNT 465 0 69 RESOLVE_INGRESS_L2_PUNT_CNT 464 0 70 RESOLVE_EGRESS_L3_PUNT_CNT 1400 0 93 CDP 464 0 95 ARP 1 0 109 DIAGS 154 0 221 PUNT_STATISTICS 9142 1 223 PUNT_DIAGS_RSP_ACT 155 0 225 PUNT_DIAGS_RSP_STBY 155 0 227 NETIO_RP_TO_LC_CPU_PUNT 155 0 373 L3_NOT_MYMAC 1000 0 565 INJECT_EGR_PARSE_PRRT_PIT 928 0 RP/0/RSP0/CPU0:obama#
Assim L3_NOT_MYMAC no contador NP significa que o roteador recebeu um quadro em uma relação da camada 3 com um endereço MAC de destino que não seja uma das relações. E o roteador deixa-o cair como esperado e este é relatado como caídas de entrada na relação da mostra.
No ASR 9000 para os pacotes recebidos com um dot1q VLAN não configurado em uma subinterface do ASR 9000, o contador desconhecido do 802.1Q da caída de entrada não é incrementado no gigabitethernet dos controladores da mostra 0/0/0/30 de stats. O procedimento é o mesmo que acima para o DMAC desconhecido: identifique que NP segura as relações e verifique então contadores este NP. Você vê que o contador UIDB_TCAM_MISS_AGG_DROP NP que incrementa nesse caso.
Que um é direto detectar porque há um contador para estas gotas uma linha abaixo das caídas de entrada na relação da mostra:
RP/0/RSP0/CPU0:obama#sh int gig 0/0/0/18 Wed Aug 22 17:14:35.232 CEST GigabitEthernet0/0/0/18 is up, line protocol is up 5 minute input rate 4000 bits/sec, 0 packets/sec 5 minute output rate 5000 bits/sec, 0 packets/sec 7375 packets input, 6565506 bytes, 1481 total input drops 1481 drops for unrecognized upper-level protocol
Você pode ver aqui que todas as caídas de entrada eram devido a protocolo não reconhecido do nível superior.
Isso significa que esse os pacotes estiveram recebidos com um protocolo de Ethernet que o roteador não está interessado dentro. De modo que signifique que uma característica está configurada no vizinho (ou em um host conectado ao domínio da camada 2 conectado a essa relação) de modo que nos envie quadros com um protocolo não configurado no roteador XR.
Exemplos: BPDU, Intermediate System to Intermediate System (ISIS), conexão menos protocolo de rede (CLNP), IPv6, UDLD, Cisco Discovery Protocol (CDP), protocolo VLAN trunking (VTP), Dynamic Trunking Protocol (DTP), protocolo de descoberta da camada de enlace (LLDP) etc.….
Quando estas características não são configuradas na relação XR, então a caixa XR deixa-as cair como esperado. Para encontrar que tipo dos quadros está incrementando este contador, você terá que comparar que características são permitidas no roteador XR com as características permitidas no vizinho (pode ser um roteador ou um interruptor), ou as características permitidas em todos os dispositivos conectados aos domínios da camada 2 conectados a essa relação (muito menos fácil). Se o roteador XR é conectado a um interruptor, você pode tentar um período nesse interruptor dos pacotes que envia ao roteador XR na relação com caídas de entrada. Veja:
ASR9000/XR: Gotas para erro de protocolo não reconhecido do nível superior
Os contadores das gotas no processo da rede (NP) do ASR 9000 estão relatados como caídas de entrada quando se aplicam a um pacote recebido em uma relação e deixado cair. Isto não acontece para gotas do motor de switch de pacotes (PSE) nos CR e no XR 12000: não são contados como caídas de entrada.
Assim se você tem caídas de entrada em um ASR 9000 e não o combinam uma destas razões, a seguir faria controladores que de uma mostra o NP move todo o lugar 0/<x>/CPU0 para encontrar o NP segurar a relação com caídas de entrada e para verificar então seus contadores NP com o lugar 0/<x>/CPU0 do np<y> dos contadores NP do contr da mostra.
Você pode conduzir a saída para manter somente contadores de queda com um comando como o lugar sh 0/<x>/CPU0 do np<y> dos contadores NP do contr | eu DEIXO CAIR mas este pode ser perigoso porque às vezes um contador de queda não tem a GOTA em seu nome. Você viu um bom exemplo com L3_NOT_MYMAC. Tão talvez tubulação para a GOTA|DISCARD|NÃO|EXCD.
Você pode cancelar os contadores de interface e os contadores NP com lugar claro 0/<x>/CPU0 do np<y> dos contadores NP do controlador aproximadamente no mesmo momento de encontrar que incrementos contrários NP na mesma taxa que as caídas de entrada.
Por exemplo, você obtém IPV4_PLU_DROP_PKT nos contadores NP que significa que a entrada CEF/PLU está dizendo que o pacote tem que ser deixado cair. Você não tem uma rota padrão e tem os pacotes assim desabilitados inalcançáveis que não combinam uma rota mais específica onde batendo o alimentador do padrão CEF que é uma entrada da gota.
Se você encontra um contador de queda no NP que pode explicar as caídas de entrada como incrementam na mesma taxa mas no contador de queda NP não é muito evidente, você pode navegar esta página para tentar compreender o que o contador significa:
ASR9000/XR: Pesquise defeitos quedas de pacote de informação e contadores de queda compreensivos NP
Nota: A página de Xander em fóruns do apoio contém as razões da gota para a primeira geração de placas de linha (Trident) e há uns nomes contrários novos para as placas de linha da nova geração (tufão)… mas baseado no nome, você deve poder encontrar um nome contrário similar como em Trident.
Você pode recolher um <int> BID do netio da mostra e este dá-lhe a entrada de interface gota e os contadores de queda do nó do netio:
RP/0/RP0/CPU0:ipc-lsp690-r-ca-01#show netio idb gigabitEthernet 0/2/0/1
GigabitEthernet0/2/0/1 (handle: 0x01280040, nodeid:0x21) netio idb:
---------------------------------
name: GigabitEthernet0_2_0_1
interface handle: 0x01280040
interface global index: 3
physical media type: 30
dchain ptr: <0x482e0700>
echain ptr: <0x482e1024>
fchain ptr: <0x482e13ec>
driver cookie: <0x4829fc6c>
driver func: <0x4829f040>
number of subinterfaces: 4096
subblock array size: 7
DSNCNF: 0x00000000
interface stats info:
IN unknown proto pkts: 0
IN unknown proto bytes: 0
IN multicast pkts: 0
OUT multicast pkts: 0
IN broadcast pkts: 0
OUT broadcast pkts: 0
IN drop pkts: 0 <=========== cleared when added to input drop counter !!!
OUT drop pkts: 0
IN errors pkts: 0
OUT errors pkts: 0
Chains
--------------------
Base decap chain:
ether <30> <0xfd018cd8, 0x482c736c> < 0, 0>
Protocol chains:
---------------
<Protocol number> (name) Stats
Type Chain_node <caps num> <function, context> <drop pkts, drop bytes>
<snip>
<13> (mpls) Stats IN: 204 pkts, 23256 bytes; OUT: 0 pkts, 0 bytes
Encap:
mpls <25> <0xfcc7ddbc, 0x00000000> < 0, 0>
ether <30> <0xfd0189b4, 0x482c736c> < 0, 0>
l2_adj_rewrite <86> <0xfcaa997c, 0x4831a2e8> < 0, 0>
pcn_output <54> <0xfd0561f0, 0x48319f04> < 0, 0>
q_fq <43> <0xfd05f4b8, 0x48320fec> < 0, 0>
txm_nopull <60> <0xfcadba38, 0x4824c0fc> < 0, 0>
Decap:
pcn_input <55> <0xfd0561f0, 0x4830ba8c> < 0, 0>
q_fq_input <96> <0xfd05f330, 0x48312c7c> < 0, 0>
mpls <25> <0xfcc7b2b8, 0x00000000> < 152, 17328>
Fixup:
l2_adj_rewrite <86> <0xfcaa945c, 0x00000000> < 0, 0>
pcn_output <54> <0xfd0561f0, 0x48319f04> < 0, 0>
q_fq <43> <0xfd05f4b8, 0x48320fec> < 0, 0>
txm_nopull <60> <0xfcadba38, 0x4824c0fc> < 0, 0>
As gotas no nó (MPLS) Multiprotocol Label Switching aqui poderiam ser devido ao Time to Live MPLS (TTL) expirado (em caso de um laço ou quando o cliente fizer um traceroute) ou a fragmentação exigiu e não fragmenta o jogo do bit (DF) por exemplo. Você pode ser executado debuga a queda de pacote de informação dos mpls e debuga o erro dos mpls com o lugar da relação para tentar figurar para fora que tipo do pacote está incrementando este contador.
Pacotes de transmissão múltipla Punted. Quando você não vê o netio em pacotes da gota mas o nenhum nó do netio abaixo com algumas gotas que poderiam explicar em pacotes da gota, a seguir este pôde ser pacotes punted mcast e você pode permitir a gota do netio do mfib deb de figurar para fora que tipo dos pacotes