Identificar e Solucionar Problemas de Quedas de Entrada no IOS XR
Opções de download
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Sobre esta tradução
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.
Contents
Introduction
Este documento descreve como solucionar problemas de quedas de entrada na interface em roteadores XR.
Prerequisites
Requirements
Não existem requisitos específicos para este documento.
Componentes Utilizados
Este artigo abrange os roteadores ASR 9000 Series, os roteadores CRS Series e os roteadores GSR 12000 Series.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
As quedas de entrada no IOS XR têm um significado completamente diferente do das quedas de entrada no IOS. Ele pode confundi-lo quando migra o IOS para o IOS XR e começa a ver seus contadores de queda de entrada no show interface.
No IOS, uma queda de entrada foi devido à fila de entrada da interface que fica cheia. Isso significa que muitos pacotes foram direcionados para a CPU para switching de processo e que ela não conseguiu lidar com eles com rapidez suficiente. A fila de entrada é construída até ficar cheia e há algumas quedas.
No IOS XR, não há uma definição estrita de queda de entrada. Então, basicamente, cabe aos desenvolvedores de um componente decidir se eles querem aumentar o contador de queda de entrada quando decidem descartar um pacote. O importante aqui é que em algum ponto do código, o roteador decide descartar o pacote, de modo que seja provável que o roteador não tenha que encaminhar o pacote e o roteador decidam conscientemente descartá-lo. Portanto, isso não está relacionado ao congestionamento como no IOS. No entanto, é um pacote que foi recebido pelo roteador e que não deveria ser encaminhado, então o roteador decidiu descartá-lo e provavelmente não é motivo para alarmar. Embora, você não possa dizer se é algo com que se preocupar ou não até que você entenda completamente o tipo de pacotes que estão incrementando o contador de queda de entrada e isso não é tão simples, infelizmente.
Examples:
- Um roteador XR é conectado a um switch que envia alguns pacotes de unidade de dados de protocolo de bridge (BPDUs) e UDLD. O roteador XR não tem spanning-tree nem UDLD configurado em suas interfaces de camada 3, portanto, ele simplesmente descarta esses quadros e incrementa o contador de quedas de entrada em show interface. Nesse caso, não há nada com que se preocupar, pois é a coisa certa a fazer para descartar esses quadros, já que os recursos não estão configurados.
- Um ASR 9000 tem uma entrada Cisco Express Forwarding (CEF) mal programada devido a um bug para que ele não aponte para uma adjacência válida. Nesse caso, o processador de rede da placa de linha (LC) ASR 9000 percebe que o roteador não tem uma informação de carga e incrementa um contador de descarte NP (Network Processor) que é carregado no contador de queda de entrada da interface.
Quando as quedas de entrada são relatadas, o problema é descobrir se são quedas legítimas, como no exemplo 1, ou a consequência de um problema como no exemplo 2.
Problema: Incremento na queda de entrada
Este documento contém os motivos para as quedas de entrada que são incrementadas e como verificar se é esse o motivo:
Quedas do controlador
Runts, Frame Check Sequence (FCS), abortos, sobrecargas First Input First Output (FIFO), quedas de Pacotes sobre SDH/SONET (POS) gigantes.
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 uma interface Ethernet (gige, tengige...), verifique algo como:
show controllers gigabitEthernet 0/0/0/18 stats
Veja se há um contador nas estatísticas do controlador que incrementa na mesma taxa do contador de queda de entrada em show interface. Alguns desses contadores de erro também devem estar em show interface.
Destino desconhecido Endereço de Controle de Acesso Médio (DMAC - Medium Access Control Address) ou VLAN dot1q
Pacotes com um endereço MAC de destino não é o da interface ou com uma rede local virtual (VLAN) não correspondida por uma subinterface. Isso pode acontecer quando há alguma inundação em um domínio L2 de endereços MAC unicast desconhecidos, de modo que o roteador XR conectado a esse domínio L2 receba quadros com um endereço MAC de destino que não seja um de seus controladores. Também é possível quando um roteador IOS está enviando keepalives ethernet em sua interface gige, portanto, esses keepalives estão incrementando as quedas de entrada no roteador XR, pois eles não têm o endereço mac de destino do roteador XR. Ou quando a interface está conectada a outro dispositivo que tem mais vlans/subinterfaces dot1q configuradas como no roteador XR para que o roteador XR receba quadros com uma marca dot1q desconhecida.
Em um PLIM (Physical Layer Interface Modules, Módulos de Interface de Camada Física) fixo do CRS, você pode encontrar tais quedas 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 nas estatísticas do controlador tengige ou 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
Note: O bug CSCub74803 existe, Input drop other é incrementado em vez de Input drop inválido DMAC pelo menos no tengige fixed PLIM de 8 portas do CRS.
Para Adaptadores de Porta Compartilhada (SPAs - Shared Port Adapters) (CRS, XR 12000), os pacotes com MAC inválido seriam descartados pela câmera SPA l2 para que você possa encontrar essas quedas em show controllers TenGigE a/b/c/d all:
Input drop other = 107 l2-tcam Invalid DA Drops: 107
Em um ASR 9000, o DMAC inválido de entrada e o descarte de entrada de outros contadores nas estatísticas do controlador não são incrementados. Assim, a maneira de reconhecer essas quedas no ASR 9000 é encontrar o NP que manipula a interface com as quedas 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 interface gig 0/0/0/30 é tratada pelo NP 0 em 0/0/CPU0.
Vamos 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#
Então L3_NOT_MYMAC no contador NP significa que o roteador recebeu um quadro em uma interface da Camada 3 com um endereço MAC de destino que não é uma das interfaces. E o roteador o descarta conforme esperado e isso é relatado como descarte de entrada em show interface.
No ASR 9000 para pacotes recebidos com uma VLAN dot1q não configurada em uma subinterface do ASR 9000, o contador Input drop desconhecido 802.1Q não é incrementado em show controllers gigabitEthernet 0/0/0/30 stats. O procedimento é o mesmo acima para o DMAC desconhecido: identifique qual NP manipula as interfaces e verifique esses contadores NP. Você vê que o contador NP UIDB_TCAM_MISS_AGG_DROP incrementando nesse caso.
Pacotes descartados devido ao protocolo de nível superior não reconhecido
Essa é simples de detectar, pois há um contador para essas quedas uma linha abaixo das quedas de entrada em show interface:
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 quedas de entrada foram devidas a um protocolo de nível superior não reconhecido.
Isso significa que os pacotes foram recebidos com um protocolo Ethernet no qual o roteador não está interessado. Isso significa que um recurso é configurado no vizinho (ou em um host conectado ao domínio da camada 2 conectado a essa interface) para que ele nos envie quadros com um protocolo não configurado no roteador XR.
Examples: BPDUs, Intermediate System to Intermediate System (ISIS), Connection Less Network Protocol (CLNP), IPv6, UDLD, Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP), Dynamic Trunking Protocol (DTP), Link Layer Discovery Protocol (LLDP) etc....
Quando esses recursos não estão configurados na interface XR, a caixa XR os descarta conforme esperado. Para descobrir que tipos de quadros estão incrementando esse contador, você terá que comparar quais recursos estão ativados no roteador XR com os recursos ativados no vizinho (ele pode ser um roteador ou um switch), ou os recursos ativados em todos os dispositivos conectados aos domínios da camada 2 conectados a essa interface (muito menos fácil). Se o roteador XR estiver conectado a um switch, você poderá tentar um span nesse switch dos pacotes que ele envia ao roteador XR na interface com descartes de entrada. Consulte:
ASR9000/XR: Quedas por erro de protocolo de nível superior não reconhecido
Quedas NP no ASR 9000
Os contadores de quedas no processo de rede (NP) do ASR 9000 são relatados como quedas de entrada quando se aplicam a um pacote recebido em uma interface e descartado. Isso não acontece para quedas do Packet Switch Engine (PSE) no CRS e no XR 12000: eles não são contados como quedas de entrada.
Portanto, se você tiver quedas de entrada em um ASR 9000 e elas não corresponderem a um desses motivos, você deverá fazer um show controllers np ports all location 0/<x>/CPU0 para encontrar o NP manipulando a interface com quedas de entrada e, em seguida, verificar seus contadores NP com show contr counters np<y> location 0/<x>/CPU0.
Você pode canalizar a saída apenas para manter contadores DROP com um comando como sh contr np counters np<y> location 0/<x>/CPU0 | i DROP, mas isso pode ser perigoso, pois às vezes um contador de queda não tem DROP em seu nome. Você viu um bom exemplo com L3_NOT_MYMAC. Então, talvez cano para DROP|DISCARD|NOT|EXCD.
Você pode limpar os contadores de interface e os contadores NP com clear controller np counters np<y> location 0/<x>/CPU0 aproximadamente ao mesmo tempo para descobrir quais incrementos de contador NP na mesma taxa das quedas de entrada.
Por exemplo, você recebe IPV4_PLU_DROP_PKT nos contadores NP, o que significa que a entrada CEF/PLU está dizendo que o pacote precisa ser descartado. Você não tem uma rota padrão e tem inalcançáveis desativados, de modo que os pacotes não correspondem a uma rota mais específica onde atinge o manipulador CEF padrão, que é uma entrada de queda.
Se você encontrar um contador de queda no NP que possa explicar as quedas de entrada à medida que elas aumentam na mesma taxa, mas o contador de queda NP não é muito autoexplicativo, você pode navegar nesta página para tentar entender o que o contador significa:
ASR9000/XR: Solucionar problemas de descarte de pacotes e entender os contadores de descarte NP
Note: A página de Xander sobre fóruns de suporte contém os motivos para a primeira geração de cartões de linha (Trident) e existem novos nomes de contador para os cartões de linha de nova geração (Typhoon)... mas com base no nome, você deve conseguir encontrar um nome de contador semelhante ao do Trident.
Netio
Você pode coletar um comando show netio idb <int> e isso fornece a você a queda de entrada da interface e os contadores de queda do nó de conexão:
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 quedas no nó Multi-Protocol Label Switching (MPLS) aqui podem ser devido ao tempo de vida do MPLS (TTL) expirado (no caso de um loop ou quando o cliente faz um traceroute) ou à fragmentação necessária e ao bit Do Not Fragment (DF), por exemplo. Você pode executar debug mpls packet drop e debug mpls error com o local da interface para tentar descobrir que tipo de pacote está incrementando esse contador.
Pacotes multicast pontuados. Quando você vê pacotes de queda netio IN mas nenhum nó de netio abaixo com algumas gotas que poderiam explicar os pacotes IN drop, então esses podem ser pacotes punted mcast e você pode habilitar deb mfib netio drop para descobrir que tipo de pacotes
Colaborado por engenheiros da Cisco
- Jean Christophe RodeCisco TAC Engineer
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)