Pesquise defeitos caídas de entrada em IO XR

Introdução

Este original descreve como pesquisar defeitos caídas de entrada na relação no Roteadores XR.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

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 sua rede está viva, assegure-se de que você compreenda o impacto potencial do comando any.

Informações de Apoio

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:

• Um roteador XR é conectado a um interruptor que envie alguns pacotes do andUDLD do Bridge Protocol Data Unit (BPDU). O roteador XR não tem a medir-árvore nem UDLD configurado em suas relações da camada 3 assim apenas deixa cair estes quadros e incrementa as caídas de entrada contra na relação da mostra. Neste caso, não há nada preocupar-se aproximadamente porque é apenas a coisa certa para fazer a gota estes quadros porque as características não são configuradas.
  
  
• Um ASR 9000 tem um errada programado da entrada do Cisco Express Forwarding (CEF) devido a um erro de modo que não aponte em uma adjacência válida. Neste caso, o processador de rede do line card (LC) ASR 9000 realiza que o roteador falta um loadinfo e incrementa um contador de queda do processador de rede (NP) que seja transferido arquivos pela rede ao contador de queda da entrada de interface.

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.

Problema: Incremento na caída de entrada

Este original recruta as razões para que as caídas de entrada que está incrementado e como verifique se é essa razão:

Gotas do controlador

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.

Endereço médio do controle de acesso do destino desconhecido (DMAC) ou dot1q VLAN

Pacotes com um MAC address do destino não essa da relação ou com uma rede de área local virtual (VLAN) não combinada por um 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 MAC address do 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 MAC address do 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

Note: 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 MAC address do 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 um subinterface do ASR 9000, o contador desconhecido do 802.1Q da caída de entrada não é incrementado no stats do gigabitEthernet 0/0/0/30 dos controladores da mostra. 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.

Deixado cair pacotes devido a protocolo não reconhecido do nível superior

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

Gotas NP no ASR 9000

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

Note: A página de Xander em fóruns do apoio contém as razões da gota para a primeira geração de linecards (Trident) e há uns nomes contrários novos para os linecards da nova geração (tufão)… mas baseado no nome, você deve poder encontrar um nome contrário similar como em Trident.

Netio

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 pkts da gota mas o nenhum nó do netio abaixo com algumas gotas que poderiam explicar em pkts 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