¿Tiene una cuenta?
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.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo resolver problemas de caídas de entrada en la interfaz en los routers XR.
No hay requisitos específicos para este documento.
Este artículo trata sobre los routers de la serie ASR 9000, los routers de la serie CRS y los routers de la serie GSR 12000.
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. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Las caídas de entrada en IOS XR tienen un significado completamente diferente al de las caídas de entrada en IOS. Puede confundirlo cuando migra IOS a IOS XR y comienza a ver sus contadores de caídas de entrada en la interfaz show.
En IOS, una caída de entrada se debió a la cola de entrada de la interfaz que se llena. Esto significa que demasiados paquetes fueron impulsados a la CPU para la conmutación de procesos y no pudo manejarlos lo suficientemente rápido. La cola de entrada se genera hasta que se llena y hay algunas caídas.
En IOS XR, no hay una definición estricta de una caída de entrada. Así que depende básicamente de los desarrolladores de un componente decidir si quieren aumentar el contador de caídas de entrada cuando deciden descartar un paquete. La clave aquí es que en algún momento del código, el router decide descartar el paquete, lo que significa que es probable que el router no deba reenviar ese paquete y el router decidan conscientemente descartarlo. Por lo tanto, esto no está relacionado con la congestión como en IOS. Sin embargo, es más bien un paquete que fue recibido por el router y que se suponía que no debía ser reenviado, por lo que el router decidió descartarlo y es muy probable que no sea una razón para estar alarmado. Aunque, no se puede decir si es algo de lo que preocuparse o no hasta haber entendido completamente el tipo de paquetes que están incrementando el contador de caídas de entrada y eso no es tan simple, desafortunadamente.
Examples:
Cuando se informa de las caídas de entrada, el problema es averiguar si son caídas legítimas como en el ejemplo 1 o la consecuencia de un problema como en el ejemplo 2.
Este documento enumera las razones de las caídas de entrada que se incrementan y cómo verificar si es por esa razón:
Ejecuciones, Secuencia de comprobación de tramas (FCS), abortos, desbordamientos de la primera entrada de la primera salida (FIFO), gigantes Paquetes sobre 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 una interfaz ethernet (gige, tengige...), verifique algo como:
show controllers gigabitEthernet 0/0/0/18 stats
Vea si hay un contador en las estadísticas del controlador que aumenta a la misma velocidad que el contador de caídas de entrada en show interface. Algunos de estos contadores de errores también deben estar en show interface.
Los paquetes con una dirección MAC de destino que no es la de la interfaz o con una red de área local virtual (VLAN) no coinciden con una subinterfaz. Esto puede ocurrir cuando hay alguna inundación en un dominio L2 de direcciones MAC de unidifusión desconocidas, por lo que el router XR conectado a ese dominio L2 recibe tramas con una dirección MAC de destino que no es uno de sus controladores. También es posible cuando un router IOS está enviando señales de mantenimiento Ethernet en su interfaz gige para que estas señales de mantenimiento aumenten las caídas de entrada en el router XR ya que no tienen la dirección MAC de destino del router XR. O cuando la interfaz está conectada a otro dispositivo que tiene más vlan/subinterfaces dot1q configuradas como en el router XR para que el router XR reciba tramas con una etiqueta dot1q desconocida.
En un CRS Physical Layer Interface Modules (PLIM) fijo, puede encontrar estas caídas 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 las estadísticas del controlador de tengige o 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: Existe el error CSCub74803, la caída de entrada otra se incrementa en lugar de la caída de entrada no válida de DMAC al menos en el PLIM fijo de tengige de 8 puertos del CRS.
Para los adaptadores de puerto compartido (SPA) (CRS, XR 12000), los paquetes con MAC inválido serían descartados por la estafa de l2 del SPA para que pueda encontrar estas caídas en show controllers TenGigE a/b/c/d all:
Input drop other = 107 l2-tcam Invalid DA Drops: 107
En un ASR 9000, la caída de entrada no válida DMAC y la caída de entrada otros contadores en las estadísticas del controlador no se incrementan. La manera de reconocer estas caídas en el ASR 9000 es encontrar el NP que maneja la interfaz con las 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#
Así que puede ver que la interfaz gig 0/0/0/30 es manejada por el NP 0 en 0/0/CPU0.
Verifiquemos los contadores 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#
Por lo tanto, L3_NOT_MYMAC en el contador NP significa que el router recibió una trama en una interfaz de Capa 3 con una dirección MAC de destino que no es una de las interfaces. Y el router lo descarta como se esperaba y esto se informa como caídas de entrada en show interface.
En el ASR 9000 para los paquetes recibidos con una VLAN dot1q no configurada en una subinterfaz del ASR 9000, el contador descarte de entrada desconocido 802.1Q no se incrementa en show controllers gigabitEthernet 0/0/0/30 stats. El procedimiento es el mismo que el anterior para el DMAC desconocido: identifique qué NP maneja las interfaces y luego verifique estos contadores NP. Verá que el contador NP UIDB_TCAM_MISS_AGG_DROP aumenta en ese caso.
Este es fácil de detectar ya que hay un contador para estas caídas una línea por debajo de las caídas de entrada en 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
Aquí puede ver que todas las caídas de entrada se debieron a un protocolo de nivel superior no reconocido.
Esto significa que los paquetes se recibieron con un protocolo Ethernet en el que el router no está interesado. Esto significa que una función se configura en el vecino (o en un host conectado al dominio de capa 2 conectado a esa interfaz) para que nos envíe tramas con un protocolo no configurado en el router XR.
Examples: BPDU, sistema intermedio a sistema intermedio (ISIS), conexión menos protocolo de red (CLNP), IPv6, UDLD, protocolo de detección de Cisco (CDP), protocolo de enlace troncal de VLAN (VTP), protocolo de enlace troncal dinámico (DTP), protocolo de detección de capa de enlace (LLDP), etc..
Cuando estas funciones no se configuran en la interfaz XR, el cuadro XR las descarta como se esperaba. Para averiguar qué tipo de tramas están incrementando este contador, tendrá que comparar qué funciones están habilitadas en el router XR con las funciones habilitadas en el vecino (puede ser un router o un switch), o las funciones habilitadas en todos los dispositivos conectados a los dominios de capa 2 conectados a esa interfaz (mucho menos fácil). Si el router XR está conectado a un switch, puede probar un span en ese switch de los paquetes que envía al router XR en la interfaz con caídas de entrada. Consulte:
ASR9000/XR : Caídas por error de protocolo de nivel superior no reconocido
Los contadores de caídas en el proceso de red (NP) del ASR 9000 se informan como caídas de entrada cuando se aplican a un paquete recibido en una interfaz y descartado. Esto no sucede con las caídas de Packet Switch Engine (PSE) en el CRS y el XR 12000: no se cuentan como caídas de entrada.
Así que si tiene caídas de entrada en un ASR 9000 y no coinciden con una de estas razones, entonces haría un show controllers np ports all location 0/<x>/CPU0 para encontrar el NP que maneja la interfaz con caídas de entrada y luego verificar sus contadores NP con show np counters np<y> location 0/<x>/CPU0.
Puede canalizar la salida para mantener solamente los contadores DROP con un comando como sh np counters np<y> location 0/<x>/CPU0 | i DROP pero esto puede ser peligroso ya que a veces un contador de caídas no tiene DROP en su nombre. Ha visto un buen ejemplo con L3_NOT_MYMAC. Así que tal vez encaje para DESCARTAR|NO|EXCD.
Puede borrar los contadores de interfaz y los contadores NP con clear controller np counters np<y> location 0/<x>/CPU0 aproximadamente al mismo tiempo para averiguar qué contador NP aumenta a la misma velocidad que las caídas de entrada.
Por ejemplo, obtiene IPV4_PLU_DROP_PKT en los contadores NP, lo que significa que la entrada CEF/PLU está diciendo que el paquete debe ser descartado. No tiene una ruta predeterminada y tiene inalcanzables inhabilitados para que los paquetes que no coincidan con una ruta más específica en la que se presione el controlador CEF predeterminado que es una entrada de descarte.
Si encuentra un contador de caídas en el NP que puede explicar las caídas de entrada a medida que aumentan a la misma velocidad pero el contador de caídas NP no se explica demasiado por sí mismo, puede navegar por esta página para tratar de entender lo que significa el contador:
ASR9000/XR: Solución de problemas de caídas de paquetes y comprensión de los contadores de caídas NP
Nota: La página de Xander en los foros de soporte contiene las razones de caída para la primera generación de tarjetas de línea (Trident) y hay nuevos nombres de contador para las tarjetas de línea de nueva generación (Tifón)... pero en función del nombre, debe poder encontrar un nombre de contador similar al de Trident.
Puede recolectar un show netio idb <int> y esto le da la caída de entrada de la interfaz y los contadores de caídas del nodo de conexión:
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>
Las caídas en el nodo MPLS podrían deberse a que el tiempo de vida de MPLS (TTL) expiró (en caso de un bucle o cuando el cliente realiza un traceroute) o a que se requiere fragmentación y, por ejemplo, se estableció un bit Do Not Fragment (DF). Puede ejecutar debug mpls packet drop y debug mpls error con la ubicación de la interfaz para intentar averiguar qué tipo de paquete está incrementando este contador.
Paquetes multicast ingresados. Cuando ve paquetes de descarte IN pero ningún nodo de conexión a continuación con algunas caídas que podrían explicar los paquetes de descarte IN, esto podría ser paquetes de percaje mcast y puede habilitar la interrupción de la conexión deb mfib para determinar qué tipo de paquetes