Input Drops del Troubleshooting en IOS XR

Introducción

Este documento describe cómo resolver problemas el Input Drops en la interfaz en el Routers XR.

Prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este artículo cubre a los 9000 Series Router ASR, CRS los routeres de la serie y los routeres de la serie GSR12000.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

El Input Drops en IOS XR tiene un significado totalmente diverso que el del Input Drops en el IOS. Puede confundirle cuando emigra el IOS a IOS XR y comienza a ver sus contadores del Input Drop en la demostración interconectar.

En el IOS, un Input Drop era debido a la cola de entrada de la interfaz que consigue por completo. Esto significa que demasiados paquetes fueron llevados en batea al CPU para el process switching y no podía manejarlos rápidamente bastante. Se acumula la cola de entrada hasta que consiga por completo y hay algunos descensos.

En IOS XR, no hay definición estricta de un Input Drop. Está tan básicamente hasta los desarrolladores de un componente para decidir a si quieren incrementar el contador del Input Drop cuando deciden a caer un paquete. La cosa dominante aquí es ésa en algún momento del código, el router decide caer el paquete de modo que signifique que es probable que no supongan al router remitir que el paquete y el router deciden consciente a caerlo. Por lo tanto, esto no se relaciona con la congestión como en el IOS. Sin embargo, es bastante un paquete que fueron recibidos por el router y que no fue supuesto ser remitido así que el router decidía caerlo y es muy probable no una razón para ser alarmado. Aunque, usted no pueda decir si es algo preocuparse alrededor o no hasta que usted ha entendido totalmente la clase de paquetes que están incrementando el contador del Input Drop y que no es ésa simple, desafortunadamente.

Ejemplos:

• Un router XR está conectado con un Switch que envíe algunos paquetes del andUDLD de la Unidad de bridge protocol data (BPDU). El router XR no tiene el atravesar-árbol ni UDLD configurado en sus interfaces de la capa 3 así que apenas cae estas tramas y incrementa el Input Drops al revés en la interfaz de la demostración. En este caso, no hay nada preocuparse alrededor pues es apenas la cosa correcta para hacer el descenso estas tramas pues las características no se configuran.
  
  
• Un ASR 9000 tiene un incorrecto programada de la entrada del Cisco Express Forwarding (CEF) debido a un bug de modo que no señale en una adyacencia válida. En este caso, el procesador de red del line card (LC) ASR 9000 realiza que el router falta un loadinfo y incrementa a un contador de caídas del procesador de red (NP) que esté cargado al contador de caídas de la entrada de la interfaz.

Cuando el Input Drops está señalado, el problema es imaginar si éstos son descensos legítimos como en el ejemplo 1 o la consecuencia de un problema como en el ejemplo 2.

Problema: Incremento en el Input Drop

Este documento alista las razones del Input Drops se incrementa que y de cómo marcar si es esa razón:

Descensos del regulador

Runts, Secuencia de verificación de tramas (FCS), abortos, primeros desbordamientos de la salida de la primera entrada ((Primero en Entrar, Primero en Salir FIFO)), paquete de los gigantes sobre los descensos 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 un Ethernet (gige, tengige…) interfaz, control algo como:

muestre a reguladores el gigabitethernet 0/0/0/18 stats

Vea si hay un contador en el stats del regulador que incrementa a la misma tarifa que el contador del Input Drop en la interfaz de la demostración. Algunos de estos contadores de errores deben también estar en la interfaz de la demostración.

Direccionamiento medio del control de acceso del destino desconocido (DMAC) o VLA N del dot1q

Paquetes con una dirección MAC del destino no la que está de la interfaz o con una red de área local virtual (VLA N) no correspondida con por una subinterfaz. Éstos pueden suceder cuando hay una cierta inundación en un dominio L2 de las direcciones MAC de la unidifusión desconocida así que el router XR conectado con ese dominio L2 recibe las tramas con una dirección MAC del destino que no sea uno de sus reguladores. Es también posible cuando un router IOS está enviando el Keepalives de los Ethernetes en su interfaz del gige así que este Keepalives está incrementando el Input Drops en el router XR pues él no tiene el MAC address del destino del router XR. O cuando la interfaz está conectada con otro dispositivo que tenga más vlans/subinterfaces del dot1q configurados como en el router XR de modo que el router XR reciba las tramas con una etiqueta desconocida del dot1q.

En los módulos de interfaz de capa física CRS fijos (PLIM), usted podría encontrar tales descensos en:

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           

O en el stats del regulador del tengige o del 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: El bug CSCub74803 existe, Input Drop que otro se incrementa en vez del Input Drop DMAC inválido por lo menos en el 8-port PLIM reparado tengige del CRS.

Para los adaptadores de puerto compartidos (SPA) (CRS, XR 12000), los paquetes con el MAC inválido serían caídos por el SPA l2-tcam así que usted puede encontrar estos descensos en los reguladores TenGigE a/b/c/d todo de la demostración:

    Input drop other            = 107

   l2-tcam Invalid DA Drops: 107

En un ASR 9000, el Input Drop DMAC inválido y el Input Drop que otros contadores en el stats del regulador no se incrementan. Tan la manera de reconocer estos descensos en el ASR 9000 es encontrar el NP el manejar de la interfaz con el Input Drops:

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#

Usted puede ver tanto como el carruaje 0/0/0/30 de la interfaz es manejado por el NP 0 en 0/0/CPU0.
Marquemos los contadores NP de NP0 en 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#

L3_NOT_MYMAC en el contador NP significa tanto como el router recibió una trama en una interfaz de la capa 3 con una dirección MAC del destino que no es una de las interfaces. Y el router lo cae como se esperaba y esto está señalada mientras que el Input Drops en la demostración interconecta.
En el ASR 9000 para los paquetes recibidos con un VLA N del dot1q no configurado en una subinterfaz del ASR 9000, el contador desconocido del 802.1Q del Input Drop no se incrementa en el gigabitethernet de los reguladores de la demostración 0/0/0/30 stats. El procedimiento es lo mismo que arriba para el DMAC desconocido: identifique qué NP maneja las interfaces y después marque los contadores este NP. Usted ve que el contador UIDB_TCAM_MISS_AGG_DROP NP que incrementa en ese caso.

Caída paquetes debido al protocolo superior desconocido

Que uno es directo detectar pues hay un contador para estos descensos una línea debajo del Input Drops en la interfaz de la demostración:

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

Usted puede ver aquí que todo el Input Drops era debido al protocolo superior desconocido.
Eso significa que ese los paquetes fueron recibidos con un protocolo Ethernet que el router no está interesado adentro. De modo que signifique que una característica está configurada en el vecino (o en un host conectado con el dominio de la capa 2 conectado con esa interfaz) de modo que nos envíe las tramas con un protocolo no configurado en el router XR.
Ejemplos: BPDU, Intermediate System to Intermediate System (ISIS), conexión menos Network Protocol (CLNP), IPv6, UDLD, Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP), Dynamic Trunking Protocol (DTP), Discovery Protocol de la capa de link (LLDP) etc….

Cuando estas características no se configuran en la interfaz XR, después el cuadro XR las cae como se esperaba. Para descubrir qué clase de tramas están incrementando este contador, usted tendrá que comparar qué características se habilitan en el router XR con las características habilitadas en el vecino (puede ser un router o un Switch), o las características habilitadas en todos los dispositivos conectados con los dominios de la capa 2 conectados con esa interfaz (mucho menos fácil). Si el router XR está conectado con un Switch, usted puede intentar un palmo en ese Switch de los paquetes que envía al router XR en la interfaz con el Input Drops. Vea:
ASR9000/XR: Descensos para el error del protocolo superior desconocido

Descensos NP en el ASR 9000

Los contadores de los descensos en el proceso de la red (NP) del ASR 9000 están señalados como Input Drops cuando se aplican a un paquete recibido en una interfaz y caído. Esto no sucede para los descensos del motor del Packet Switch (PSE) en CRS y el XR 12000: no se cuentan como Input Drops.

Tan si usted tiene Input Drops en un ASR 9000 y no hacen juego una de estas razones, después le haría los reguladores de una demostración que NP vira toda la ubicación hacia el lado de babor 0/<x>/CPU0 para encontrar el NP el manejar de la interfaz con el Input Drops y después para marcar sus contadores NP con la ubicación 0/<x>/CPU0 del np<y> de los contadores NP del contr de la demostración.

Usted puede transmitir la salida para guardar solamente a los contadores de caídas con un comando como la ubicación sh 0/<x>/CPU0 del np<y> de los contadores NP del contr | CAIGO pero esto puede ser peligroso pues un contador de caídas no tiene a veces DESCENSO en su nombre. Usted ha visto un buen ejemplo con L3_NOT_MYMAC. Tan quizá tubo para el DESCENSO|DESCARTAR|NO|EXCD.

Usted puede borrar los contadores de la interfaz y los contadores NP con la ubicación clara 0/<x>/CPU0 del np<y> de los contadores NP del regulador en áspero la misma época de descubrir que el contador NP incrementa a la misma tarifa que el Input Drops.

Por ejemplo, usted consigue IPV4_PLU_DROP_PKT en los contadores NP que signifique que la entrada CEF/PLU está diciendo que el paquete tiene que ser caído. Usted no tiene una ruta predeterminado y tuvo tan paquetes inhabilitados unreachables que no corresponden con una ruta más específica donde golpeando al programa piloto del valor por defecto CEF que es una entrada del descenso.

Si usted encuentra a un contador de caídas en el NP que puede explicar el Input Drops como él incrementa en la misma tarifa pero el contador de caídas NP no es muy que se explica por sí mismo, usted puede navegar esta página para intentar entender lo que significa el contador:
ASR9000/XR: Caídas de paquetes del Troubleshooting y contadores de caídas de comprensión NP

Nota: La página de Xander en los foros del soporte contiene las razones del descenso de la primera generación de linecards (Trident) y hay nuevos nombres contrarios para el linecards de la generación nueva (tifón)… pero basado en el nombre, usted debe poder encontrar un nombre contrario similar como en Trident.

Netio

Usted puede recoger un <int> del idb del netio de la demostración y éste le da el descenso de la entrada de la interfaz y los contadores de caídas del nodo del 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>

Los descensos en el nodo del (MPLS) del Multi-Protocol Label Switching aquí podrían ser debido al Time to Live MPLS (TTL) expirado (en caso de un loop o cuando el cliente hace un traceroute) o la fragmentación requirió y no hace fragmentos del conjunto de bits (DF) por ejemplo. Usted puede funcionar con la caída de paquetes de los mpls del debug y hacer el debug del error de los mpls con la ubicación de la interfaz para intentar imaginar qué clase de paquete está incrementando este contador.

Paquetes de multidifusión llevados en batea. Cuando usted ve el netio EN el pkts del descenso pero ningún nodo del netio abajo con algunos descensos que podrían explicar EN el pkts del descenso, después éste pudo ser paquetes llevados en batea mcast y usted puede permitir al descenso del netio del mfib DEB para imaginar qué clase de paquetes