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 CPU elevada los problemas en un router de las ASR1000 Series.
Cisco recomienda que usted entiende la arquitectura ASR1000 para interpretar y para utilizar este documento.
CPU elevada en un router Cisco puede ser definido como la condición donde está la utilización de la CPU en el router sobre la utilización normal. En algunos escenarios se espera el uso de la CPU incrementada mientras que en otros escenarios podría indicar un problema. La utilización del transeúnte CPU elevada en el router debido al cambio de la red o al cambio de configuración se puede ignorar y es conducta esperada.
Sin embargo, un router que experimenta CPU elevada la utilización por los períodos ampliados sin ningunos cambios en la red o la configuración es inusual y necesita ser analizado. Por lo tanto cuando está utilizado demasiado, el CPU no puede mantener activamente el resto de los procesos, que da lugar a la línea de comando lenta, al tiempo de espera plano del control, a las caídas de paquetes, y al error de servicios.
Las causas de CPU elevada están:
CPU elevada no están siempre los problemas con el router de las ASR1000 Series al igual que es directamente proporcional a la carga en el router. Por ejemplo si hay un cambio de la red, éste causará una gran cantidad de tráfico del plano del control pues re-convergerá la red. Por lo tanto, necesitamos determinar la causa raíz de la sobre-utilización CPU de determinar si es conducta esperada o un problema.
Abajo está un diagrama que detalla un proceso gradual en cómo resolver problemas CPU elevada un problema:
ASR1000 tiene vario diverso CPU a través de los diversos módulos. Por lo tanto, necesitamos ver qué módulo muestra mayor que la utilización normal. Esto se puede ver con el valor ocioso, como el más bajo el valor ocioso, más alta es la utilización de la CPU de ese módulo. Este diverso CPU todo refleja el avión del control de los módulos.
Determine qué módulo dentro del dispositivo se observa para experimentar CPU elevada. Está el RP, el ESP, o el SORBO con el comando abajo
muestre la descripción del Control Processor del estatus del software de plataforma
Refiera a la salida abajo para ver la columna resaltada
Si el RP tiene un valor ocioso bajo, después proceda a la punta 1 del paso 2
Si el ESP tiene un valor ocioso bajo, después proceda a la punta 2 del paso 3
Si el SORBO tiene un valor ocioso bajo, después proceda a la punta 3 del paso 4
Descripción del Control Processor del estatus del software de plataforma de Router#show
Promedio de carga
Estatus 1-Min 5-Min 15-Min del slot
RP0 0.00 0.02 0.00 sano
ESP0 0.01 0.02 0.00 sano
SIP0 0.00 0.01 0.00 sano
Memoria (kB)
Total del estatus del slot usado (el PCT) (el PCT) confiado libremente (el PCT)
RP0 2009376 1879196 (el 94%) 130180 (el 6%) 1432748 sanos (los 71%)
ESP0 2009400 692100 (el 34%) 1317300 (el 66%) 472536 sanos (el 24%)
SIP0 471804 284424 (el 60%) 187380 (el 40%) 193148 sanos (los 41%)
Utilización de la CPU
Marcha lenta IRQ SIRQ IOwait del sistema de usuario del slot CPU Niza
RP0 0 2.59 2.49 0.00 94.80 0.00 0.09 0.00
ESP0 0 2.30 17.90 0.00 79.80 0.00 0.00 0.00
SIP0 0 1.29 4.19 0.00 94.41 0.09 0.00 0.00
Si los valores ociosos son todo el relativamente altos, puede no ser un problema del avión del control. Para resolver problemas los datos acepille el QFP ESP necesita ser observado. Los síntomas de “CPU elevada” pueden todavía ser observado debido a un QFP excesivo excesivamente, que no resultará adentro CPU elevada en los procesadores del avión del control. Proceda al PASO 6.
Confirme dentro del RP que el procesador se observa para tener CPU elevada utilización con el comando abajo. ¿Es el proceso de Linux o el IOS?
muestre el monitor activo del slot RP del proceso del software de plataforma
Si el porcentaje IOS CPU es alto (linux_iosd-imag), después es es el IOS RP. Proceda al PASO 3
Si el porcentaje CPU de otros procesos es alto, después es probable ser el proceso de Linux. Proceda al PASO 4
Confirme dentro del ESP si el procesador del avión del control se observa para tener CPU elevada utilización. ¿Es el FECP?
muestre el monitor activo del slot FP del proceso del software de plataforma
Si los procesos son altos entonces es el FECP, después procede al PASO 5
Si no es el FECP, no es un asunto relacionado de los procesos del avión del control dentro del ESP. Si los síntomas tales como latencia de red o las caídas de la cola todavía se observan, el avión de los datos puede necesitar ser revisado para la sobre-utilización. Proceda al PASO 6
Si el SORBO se observa para tener CPU elevada utilización entonces el IOCP será observado para tener CPU elevada. Determine qué proceso o procesos dentro del IOCP se observan para tener CPU elevada utilización.
Realice a una captura de paquetes e identifique qué tráfico es más alto que usual y qué procesos se asocian a este tipo de tráfico. Proceda al PASO 7
Refiera a la salida abajo, el primer porcentaje es el uso total de la CPU, y el segundo porcentaje es la utilización de la CPU de la interrupción, que es la cantidad de CPU usada para procesar los paquetes llevados en batea.
Si el porcentaje de la interrupción es alto entonces significa que una gran cantidad de tráfico está llevado en batea al RP, (esto puede ser confirmado con la batea de la infraestructura del software del comando show platform)
Si el porcentaje de la interrupción es bajo, pero el CPU total es alto, después hay un proceso o los procesos que serán observados para utilizar el CPU durante un largo período.
Confirme dentro del IOS que el proceso o los procesos se observa para tener CPU elevada utilización con el comando abajo.
muestre la CPU de los procesos clasificada
Identifique qué porcentaje es alto (el CPU total o interrumpe el CPU), y después si procede identifique el proceso individual/los procesos. Proceda al PASO 7
Router#show procesa la CPU clasificada
Utilización de la CPU por cinco segundos: 0%/0%; un minuto: el 1%; cinco minutos: el 1%
El PID Runtime(ms) invocó el proceso de los uSecs 5Sec 1Min 5Min TTY
El PID Runtime(ms) invocó el proceso de los uSecs 5Sec 1Min 5Min TTY
188 8143 434758 18 0.15% 0.18% 0.19% 0 Ti milisegundo de los Ethernetes
515 380 7050 53 0.07% 0.00% 0.00% 0 procesos de la tubería SBC
3 2154 215 10018 0.07% 0.00% 0.19% 0 ejecutivos
380 1783 55002 32 0.07% 0.06% 0.06% 0 TEMPORIZADORES MUTTAHIDA MAJLIS-E-AMAL DB
63 3132 11143 281 0.07% 0.07% 0.07% 0 tareas IOSD ipc
5 1 2 500 0.00% 0.00% 0.00% 0 IPC ISSU Dispatc
6 19 12 1583 0.00% 0.00% 0.00% 0 Th principales auxiliares RF
8 0 1 0 0.00% 0.00% 0.00% 0 RO notifican los temporizadores
7 0 1 0 0.00% 0.00% 0.00% 0 EDDRI_MAIN
10 6 75 80 0.00% 0.00% 0.00% 0 administradores de conjunto
9 5671 538 10540 0.00% 0.14% 0.12% verificares almacenamiento dinámicos 0
Si el IOS se observa para haber utilizado el CPU excesivamente, después necesitamos observar la utilización de la CPU para el proceso individual del linux. Estos procesos son los otros procesos enumerados del monitor activo del slot RP del proceso del software de plataforma de la demostración. Identifique qué proceso o procesos se observan para experimentar CPU elevada entonces proceden al PASO 7.
Si un proceso o los procesos es altos entonces él es probables ésos es los procesos dentro de los FECP que son responsables CPU elevada de la utilización, proceda al PASO 7
El procesador del flujo de Quantum es ASIC de envío. Para determinar la carga en el motor de reenvío, el QFP puede ser monitoreado. Las listas de comandos abajo los paquetes de entrada y de salida (prioridad y no prioritario) en los paquetes por segundo, y bits por segundo. La línea visualizaciones final la cantidad total carga de la CPU de debido al reenvío de paquete en un porcentaje.
muestre a qfp del hardware de plataforma la utilización activa del datapath
Identifique si la entrada o la salida es alta, y vea la carga de proceso y después proceda al PASO 7
Utilización activa del datapath del qfp del hardware de plataforma de Router#show
CPP 0: Subdev 0 5 secs 1 minuto 5 minuto del minuto 60
Entrada: Prioridad (pps) 0 0 0 0
(BPS) 208 176 176 176
(Pps) 0 2 2 2 no prioritarios
(BPS) 64 784 784 784
Total (pps) 0 2 2 2
(BPS) 272 960 960 960
Salida: Prioridad (pps) 0 0 0 0
(BPS) 192 160 160 160
(Pps) 0 1 1 1 no prioritario
(BPS) 0 6488 6496 6488
Total (pps) 0 1 1 1
(BPS) 192 6648 6656 6648
Proceso: Carga (el PCT) 0 0 0 0
Con el proceso o los procesos que se observan para haber utilizado el CPU excesivamente identificado, hay una imagen más clara de porqué CPU elevada ha ocurrido. Para proceder, investigue las funciones realizadas por el proceso identificado. Esto ayudará adentro a determinar un plan de acción en cómo abordar el problema. Por ejemplo - Si el proceso es responsable de un protocolo particular entonces usted puede querer mirar la configuración relacionada con este protocolo.
Si usted todavía experimenta los asuntos relacionados CPU, se recomienda para entrar en contacto TAC para permitir que un ingeniero le ayude a resolver problemas más lejos. Los pasos antedichos a resolver problemas ayudarán al ingeniero a aislar el problema más eficientemente.
En este ejemplo nos ejecutaremos con el proceso para resolver problemas e intentar al mejor identifique una causa raíz posible para el router CPU elevada. Para comenzar, determine qué módulo se observa para experimentar CPU elevada, nosotros tienen la salida abajo:
Descripción del Control Processor del estatus del software de plataforma de Router#show
Promedio de carga
Estatus 1-Min 5-Min 15-Min del slot
RP0 0.66 0.15 0.05 sano
ESP0 0.00 0.00 0.00 sano
SIP0 0.00 0.00 0.00 sano
Memoria (kB)
Total del estatus del slot usado (el PCT) (el PCT) confiado libremente (el PCT)
RP0 2009376 1879196 (el 94%) 130180 (el 6%) 1432756 sanos (el 71%)
ESP0 2009400 692472 (el 34%) 1316928 (el 66%) 472668 sanos (el 24%)
SIP0 471804 284556 (el 60%) 187248 (el 40%) 193148 sanos (el 41%)
Utilización de la CPU
Marcha lenta IRQ SIRQ IOwait del sistema de usuario del slot CPU Niza
RP0 0 57.11 14.42 0.00 0.00 28.25 0.19 0.00
ESP0 0 2.10 17.91 0.00 79.97 0.00 0.00 0.00
SIP0 0 1.20 6.00 0.00 92.80 0.00 0.00 0.00
Pues la cantidad ociosa dentro de RP0 es muy baja, sugiere CPU elevada un problema dentro del Route Processor. Por lo tanto para resolver problemas más lejos nos identificaremos observan a qué procesador dentro del RP para experimentar CPU elevada.
Router#show procesa la CPU clasificada
Utilización de la CPU por cinco segundos: 84%/36%; un minuto: el 34%; cinco minutos: el 9%
El PID Runtime(ms) invocó el proceso de los uSecs 5Sec 1Min 5Min TTY
SE de la batea 107 303230 50749 5975 46.69% 18.12% 4.45% 0 IOSXE-RP
63 105617 540091 195 0.23% 0.10% 0.08% 0 tareas IOSD ipc
159 74792 2645991 28 0.15% 0.06% 0.06% 0 subprocesos principales VRRS
116 53685 169683 316 0.15% 0.05% 0.01% por segundo trabajos 0
9 305547 26511 11525 0.15% 0.28% 0.16% verificares almacenamiento dinámicos 0
188 362507 20979154 17 0.15% 0.15% 0.19% 0 Ti milisegundo de los Ethernetes
3 147 186 790 0.07% 0.08% 0.02% 0 ejecutivos
2 32126 33935 946 0.07% 0.03% 0.00% 0 medidores de carga
446 416 33932 12 0.07% 0.00% 0.00% 0 procesos VDC
164 59945 5261819 11 0.07% 0.04% 0.02% 0 edades de la recomprobación IP ARP
43 1703 16969 100 0.07% 0.00% 0.00% 0 señales de mantenimiento M de IPC
De esta salida, puede ser observado que el porcentaje total CPU y el porcentaje de la interrupción son más altos que esperados. El proceso superior que utiliza el CPU es “el SE de la batea IOSXE-RP” que es el proceso que maneja el tráfico para el RP CPU, por lo tanto que podemos mirar más lejos en este tráfico que se lleve en batea al RP.
Batea de la infraestructura del software de plataforma de Router#show
Stats interno de la interfaz LSMPI:
enabled=0, disabled=0, throttled=0, unthrottled=0, estado está listo
Memorias intermedias de entrada = 90100722
Búferes de salida = 100439
cuenta del rxdone = 90100722
cuenta del txdone = 100436
Rx ninguna cuenta del particletype = 0
Tx ninguna cuenta del particletype = 0
Txbuf de la cuenta de la sombra = 0
Ningún comienzo del paquete = 0
Ningún extremo del paquete = 0
Stats del descenso de la batea:
Mala versión 0
Mún tipo 0
Tenía encabezado 0 de la característica
Tenía encabezado 0 de la plataforma
Encabezado de la característica que falta 0
Discordancía común 0 de la encabezado
Mala longitud total 0
Mala Longitud del paquete 0
La mala red compensó 0
No encabezado 0 de la batea
Tipo de link desconocido 0
Ningún swidb 1
Mala encabezado 0 de la característica ESS
Ninguna característica 0 ESS
Ninguna característica 0 SSLVPN
Batea para nosotros desconocido 0 del tipo
Causa de la batea fuera del rango 0
Causas del paquete de la batea IOSXE-RP:
control 62210226Layer2ypaquetes de laherencia
Pedido ARP 147 o paquetes de respuesta
27801234 Para-nosotros paquetes de datos
84426 paquetes de keepalive RP<->QFP
6 paquetes de la adyacencia de recolección
1647 Para-nosotros paquetes de control
Stats del protcol del IPv4 del control FOR_US:
1647 paquetes OSPF
Bytes/compartimiento del paquete histogram(500), tamaño del avg en 92, hacia fuera 56:
Hacia fuera-cuenta de la En-cuenta del Pak-tamaño
0+: 90097805 98790
500+: 0 7
De esta salida, podemos ver que hay una gran cantidad de paquetes en “Para-nosotros los paquetes de datos” que indica el tráfico dirigido hacia el router, este contador fue confirmado para ser ha incrementado de la observación de los tiempos múltiples del comando durante varios minutos. Esto confirma que el CPU es utilizado excesivamente por una gran cantidad de tráfico llevado en batea, que es a menudo tráfico del plano del control. El tráfico del plano del control puede incluir ARP, SSH, SNMP, las actualizaciones de la ruta (BGP, EIGRP, OSPF) etc. De esta información, podemos identificar la causa potencial del CPU elevada y ésta ayuda a resolver problemas para la causa raíz. Por ejemplo, una captura de paquetes o un monitor de diverso tráfico podría ser implementada para considerar el tráfico exacto llevado en batea al RP que permitiría que solucionaa la causa raíz fuera identificada y para prevenir un problema similar en el futuro.
Una vez que completan a una captura de paquetes, algunos ejemplos del tráfico llevado en batea potencial son:
Esto resaltados cómo la causa raíz se puede aislar a través de la identificación de la causa del CPU elevada, cuando baja a un nivel del proceso individual. De aquí, el proceso individual o el protocolo se puede analizar en el aislamiento para identificar si es un problema de configuración, un problema de software, un diseño de red, o una práctica prevista.
El abajo es una lista de otros comandos útiles adicionales de utilizar y se clasifica por con cuyo procesador él se relacione: