CPU elevada utilización en los Catalyst 4500 Switch basados en software del Cisco IOS
Contenido
Introducción
Los switches Catalyst 4500 Series, que incluyen los switches Catalyst 4948, tienen una metodología de dirección del paquete sofisticada para el tráfico dirigido hacia la CPU. Un problema comúnmente conocido es la elevada utilización de la CPU de estos switches. Este documento proporciona detalles sobre la arquitectura de dirección del paquete de la CPU y muestra cómo identificar las causas de la elevada utilización de la CPU en estos switches. El documento también enumera algunos escenarios comunes de configuración o de red que causan una elevada utilización de la CPU en las series Catalyst 4500.
Nota: Si usted funciona con el Catalyst OS (CatOS) - el Switches de las 4500/4000 Series del Catalyst basado, refiere a la utilización de la CPU del documento en el Catalyst 4500/4000, 2948G, 2980G, y los 4912G Switch que funcionan con el software CatOS.
prerrequisitos
Requisitos
No hay requisitos específicos para este documento.
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
-
Catalyst 4500 Series Switch
-
Catalyst 4948 Series Switch
Nota: Este documento se aplica solamente al Switches basado en software y no a los switches basados en CatOS del ® del Cisco IOS.
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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
Convenciones
Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.
Antecedentes
Antes de que usted mire la arquitectura de la dirección del paquete CPU y resuelva problemas CPU elevada la utilización, usted debe entender que las maneras diferentes en las cuales la expedición basado en hardware conmuta y los routeres basados en software del Cisco IOS utilizan el CPU. El concepto erróneo común es que CPU elevada la utilización indica el agotamiento de recursos en un dispositivo y la amenaza de una caída. Un problema de capacidad es uno de los síntomas de una alta utilización de la CPU en el Routers del Cisco IOS. Sin embargo, un problema de capacidad casi nunca es síntomas de una alta utilización de la CPU con el Switches basado en hardware de la expedición como el Catalyst 4500. El Catalyst 4500 se diseña para remitir los paquetes en las velocidades del reenvío de tráfico del circuito específico de la aplicación (ASIC) y del alcance del hardware de hasta 102 millones de paquetes por segundo (Mpps).
El Catalyst 4500 CPU realiza estas funciones:
-
Manages configuró los protocolos del software, por ejemplo:
-
Spanning Tree Protocol (STP)
-
Routing Protocol
-
Cisco Discovery Protocol (CDP)
-
Port Aggregation Protocol (PAgP)
-
VLAN Trunk Protocol (VTP)
-
Protocolo de enlace troncal dinámico (DTP)
-
-
Programa la configuración/las entradas dinámicas al ASIC de hardware, por ejemplo:
-
Listas de control de acceso (ACL)
-
Entradas CEF
-
-
Internamente maneja los diversos componentes, por ejemplo:
-
Poder sobre el linecards de los Ethernetes (PoE)
-
Fuentes de alimentación
-
BANDEJA DE VENTILACIÓN
-
-
Maneja el acceso al Switch, por ejemplo:
-
Telnet
-
Consola
-
‘Protocolo de administración de red simple (SNMP)
-
-
Adelante paquetes vía el trayecto por software, por ejemplo:
-
Intercambio de paquetes entre redes (IPX) - paquetes ruteados, que se soportan solamente en el trayecto por software
-
Fragmentación de la Unidad máxima de transmisión (MTU) (MTU)
-
Según esta lista, CPU elevada la utilización puede resultar del recibo o del proceso de los paquetes por el CPU. Algunos de los paquetes que se envían para el proceso pueden ser esenciales para la operación de la red. Un ejemplo de estos paquetes básicos es la Unidad de bridge protocol data (BPDU) para las configuraciones de la topología del árbol de expansión. Sin embargo, otros paquetes pueden ser tráfico de datos del software remitido. Estos escenarios requieren Asics que conmuta enviar los paquetes al CPU para procesar:
-
Los paquetes que se copian al CPU, solamente los paquetes originales se conmutan en hardware
Un ejemplo es MAC Address Learning del host.
-
Paquetes que se envían al CPU para procesar
Los ejemplos incluyen:
-
Actualizaciones del Routing Protocol
-
BPDU
-
Una inundación intencional o involuntaria del tráfico
-
-
Paquetes que se envían al CPU para remitir
Un ejemplo es los paquetes que necesitan la encaminamiento IPX o del APPLETALK.
Entienda la arquitectura de la dirección del paquete del Catalyst 4500 CPU
El Catalyst 4500 tiene un mecanismo integrado del Calidad de Servicio (QoS) para distinguir entre los tipos de tráfico que se destinan al CPU. El mecanismo hace la diferenciación en base de la capa 2 (L2)/Layer 3 (información del paquete de la capa 4 L3)/ (L4). El motor del paquete supervisor tiene 16 colas de administración del tráfico para manejar los diversos tipos de paquetes o de eventos. El cuadro 1 muestra estas colas de administración del tráfico. El cuadro 1 enumera las colas de administración del tráfico y los tipos de paquete que hacen cola en cada uno. Las 16 colas de administración del tráfico permiten que el Catalyst 4500 haga cola los paquetes en base del tipo de paquete o de la prioridad.
Cuadro 1 – Colas de administración del tráfico múltiples de las aplicaciones CPU del Catalyst 4500 
| Número de la cola | Nombre de la cola | Paquetes hechos cola |
|---|---|---|
| 0 | Esmp | ESMP1 paquetes (paquetes de administración internos) para el linecard Asics o la otra Administración componente |
| 1 | Control | Paquetes del avión del control L2, tales como STP, CDP, PAgP, LACP2, o UDLD3 |
| 2 | Aprendizaje del host | Capítulos con las direcciones MAC de la fuente desconocida que se copian al CPU para construir la tabla de reenvío L2 |
| 3, 4, 5 | L3 Fwd lo más arriba posible, reenvío alto L3/media, L3 Fwd bajo | Los paquetes que se deben remitir en el software, tal como GRE4 túneles si ARP5 es sin resolver para el IP Address de destino, los paquetes se envían a esta cola. |
| 6, 7, 8 | L2 Fwd lo más arriba posible, reenvío alto L2/media, L2 Fwd bajo | Paquetes que se remiten como resultado del bridging
|
| 9, 10 | Rx L3 alto, rx L3 bajo | El tráfico del plano del control L3, por ejemplo, los Routing Protocol, que es destinado por los ejemplos de los IP Addresses CPU incluye Telnet, SNMP, y SSH8. |
| 11 | Falla de RPF | Paquetes de multidifusión que fallaron RPF9 el control |
| 12 | Fwd(snooping) ACL | Paquetes que son procesados por el snooping del DHCP10, la inspección ARP dinámica, o las características del snooping IGMP11 |
| 13 | Registro ACL, unreach | Los paquetes que golpearon ACE12 con la palabra clave o los paquetes del registro que eran caído debido a una negación en un ACL de salida o a la falta de una ruta al destino estos paquetes requieren la generación de mensajes inalcanzables de ICMP. |
| 14 | Proceso interruptor ACL | Paquetes que se llevan en batea al CPU debido a una falta de Recursos de hardware adicionales ACL, tales como TCAM13, para el ACL de seguridad |
| 15 | Fall MTU/inválido | Paquetes que necesitan ser hechos fragmentos porque la talla del MTU de la interfaz de salida es más pequeña que el tamaño del paquete |
1 ESMP = incluso Management Protocol simple.
2 LACP = protocolo link aggregation control.
3 UDLD = detección de link unidireccional.
4 GRE = Generic Routing Encapsulation.
5 ARP = protocolo Protocolo de resolución de la dirección (ARP).
6 SVI = Switched Virtual Interface.
7 TTL = Time to Live.
8 SSH = protocolos secure shell.
9 RPF = reenvío de trayecto inverso
10 DHCP = protocolos DHCP.
11 IGMP = Internet Group Management Protocol.
12 ACE = entrada de control de acceso.
13 TCAM = Ternary Content Addressable Memory.
Estas colas de administración del tráfico son colas aparte:
-
L2 Fwd lo más arriba posible o L3 Fwd lo más arriba posible
-
Reenvío alto L2/media o reenvío alto L3/media
-
Punto bajo o L3 Fwd L2 Fwd bajo
-
Alto del rx L3 o rx L3 bajo
Los paquetes se hacen cola en estas colas de administración del tráfico en base de la escritura de la etiqueta de QoS, que es el valor del Differentiated Services Code Point (DSCP) del tipo de servicio IP (TOS). Por ejemplo, los paquetes con un DSCP de 63 se hacen cola a la cola más alta L3 Fwd. Usted puede ver los paquetes que se reciben y se caen para estas 16 colas de administración del tráfico en la salida del comando show platform cpu packet statistics all. La salida de este comando es muy larga. Publique el comando show platform cpu packet statistics para mostrar solamente los eventos distintos a cero. Un comando alterno es el comando show platform cpuport. Utilice solamente el comando show platform cpuport si usted funciona con el Cisco IOS Software Release 12.1(11)EW o Anterior. Este comando se ha desaprobado desde entonces. Sin embargo, este más viejo comando era una parte del comando show tech-support en las versiones de Cisco IOS Software anterior que el Cisco IOS Software Release 12.2(20)EWA.
Utilice el comando show platform cpu packet statistics para todo el troubleshooting.
Switch#show platform cpu packet statistics all !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 0 0 0 0 0 Control 48 0 0 0 0 Host Learning 0 0 0 0 0 L3 Fwd High 0 0 0 0 0 L3 Fwd Medium 0 0 0 0 0 L3 Fwd Low 0 0 0 0 0 L2 Fwd High 0 0 0 0 0 L2 Fwd Medium 0 0 0 0 0 L2 Fwd Low 0 0 0 0 0 L3 Rx High 0 0 0 0 0 L3 Rx Low 0 0 0 0 0 RPF Failure 0 0 0 0 0 ACL fwd(snooping) 0 0 0 0 0 ACL log, unreach 0 0 0 0 0 ACL sw processing 0 0 0 0 0 MTU Fail/Invalid 0 0 0 0 0 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 0 0 0 0 0 Control 0 0 0 0 0 Host Learning 0 0 0 0 0 L3 Fwd High 0 0 0 0 0 L3 Fwd Medium 0 0 0 0 0 L3 Fwd Low 0 0 0 0 0 L2 Fwd High 0 0 0 0 0 L2 Fwd Medium 0 0 0 0 0 L2 Fwd Low 0 0 0 0 0 L3 Rx High 0 0 0 0 0 L3 Rx Low 0 0 0 0 0 RPF Failure 0 0 0 0 0 ACL fwd(snooping) 0 0 0 0 0 ACL log, unreach 0 0 0 0 0 ACL sw processing 0 0 0 0 0 MTU Fail/Invalid 0 0 0 0 0
El Catalyst 4500 CPU asigna las ponderaciones a las diversas colas de administración del tráfico que el cuadro 1 enumera. El CPU asigna las ponderaciones en base de la importancia, o el tipo, y en base de la prioridad de tráfico, o del DSCP. El CPU mantiene la cola en base de las ponderaciones relativas de la cola. Por ejemplo, si un paquete de control, tal como un BPDU, y un pedido de eco ICMP están pendientes, el CPU mantiene el paquete de control primero. Una cantidad excesiva de prioridad baja o de tráfico menos-importante no muere de hambre el CPU de la capacidad de procesar o de manejar el sistema. Este mecanismo garantiza que la red es estable incluso bajo utilización intensa del CPU. Esta capacidad de la red de seguir siendo estable es la información crítica que usted debe entender.
Hay otro detalle de instrumentación muy importante de la dirección del paquete del Catalyst 4500 CPU. Si el CPU ha mantenido los paquetes con prioridad alta o los procesos pero tiene ya más ciclos de la CPU de repuesto por un período de tiempo determinado, el CPU mantiene los paquetes de la cola de baja prioridad o realiza los procesos de origen de la prioridad baja. CPU elevada la utilización como resultado del proceso o de los procesos de origen del paquete de prioridad baja se considera normal porque el CPU intenta constantemente utilizar todo el tiempo disponible. De esta manera, el CPU se esfuerza para el rendimiento máximo del Switch y de la red sin un compromiso de la estabilidad del Switch. El Catalyst 4500 considera el CPU underutilized a menos que el CPU se utilice en el 100 por ciento para un solo slot de tiempo.
El Cisco IOS Software Release 12.2(25)EWA2 y Posterior ha aumentado el paquete CPU y mecanismo y el considerar de la proceso-dirección. Por lo tanto, utilice estas versiones en sus implementaciones del Catalyst 4500.
Identifique la razón CPU elevada de la utilización en el Catalyst 4500
Ahora que usted entiende la arquitectura y el diseño de la dirección del paquete del Catalyst 4500 CPU, usted puede todavía desear identificar porqué su utilización de la CPU del Catalyst 4500 es alta. El Catalyst 4500 tiene los comandos y las herramientas que son necesarios identificar la causa raíz CPU elevada de la utilización. Después de que usted identifique la razón, los administradores pueden realizar cualquiera de estas acciones:
-
Acción correctiva — Esto puede incluir la configuración o los cambios de la red, o la creación de un pedido del servicio de soporte técnico de Cisco el análisis adicional.
-
Ninguna acción — El Catalyst 4500 se realiza según la expectativa. El CPU exhibe CPU elevada la utilización porque el Supervisor Engine maximiza los ciclos de la CPU para realizar todos los trabajos del reenvío de paquete y de fondo del software necesario.
Esté seguro de identificar la razón CPU elevada de la utilización aunque la acción correctiva no es necesaria en todos los casos. CPU elevada la utilización puede ser apenas un síntoma de un problema en la red. Una resolución de la causa raíz de ese problema puede ser necesaria para bajar la utilización de la CPU.
El cuadro 2 muestra la metodología de Troubleshooting para utilizar para identificar la causa raíz de la utilización del Catalyst 4500 CPU elevada.
Cuadro 2 – CPU elevada metodología de Troubleshooting de la utilización en los Catalyst 4500 Switch 
Los pasos de Troubleshooting general son:
-
Publique el comando show processes cpu para identificar los procesos del Cisco IOS que consumen los ciclos de la CPU.
-
Publique el comando show platform health para identificar más lejos los procesos específicos de la plataforma.
-
Si el proceso activo es altamente estudio del K2CpuMan, publique la identidad del comando show platform cpu packet statistics para el tipo de tráfico que golpea el CPU.
Si la actividad no es debido al proceso del estudio del K2CpuMan, salte el paso 4 y continúe al paso 5.
-
Identifique los paquetes que golpean el CPU con el uso de las herramientas de Troubleshooting de analizar el tráfico destinado al CPU, en caso necesario.
Un ejemplo de las herramientas de Troubleshooting a utilizar es el Switched Port Analyzer (SPAN) CPU.
-
Revise este documento y los problemas de utilización del campo común del Troubleshooting de la sección CPU elevada para las causas comunes.
Si usted todavía no puede identificar la causa raíz, entre en contacto el Soporte técnico de Cisco.
Línea de fondo el USO de la CPU
El primer paso importante es conocer la utilización de la CPU de su Switch para su configuración y configuración de la red. Utilice el comando show processes cpu para identificar la utilización de la CPU en el Catalyst 4500 Switch. La actualización continua de utilización de la CPU de línea de base puede ser necesaria mientras que usted agrega más configuración a la configuración de la red o mientras que sus cambios del patrón de tráfico de red. El cuadro 2 indica este requisito.
Esta salida es de un Catalyst 4507R completamente cargado. El CPU de estado estacionario es el cerca de 32 a 38 por ciento, que es necesario para realizar las funciones de administración para este Switch:
Switch#show processes cpu CPU utilization for five seconds: 38%/1%; one minute: 32%; five minutes: 32% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 63 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 60 50074 1 0.00% 0.00% 0.00% 0 Load Meter 3 0 1 0 0.00% 0.00% 0.00% 0 Deferred Events !--- Output suppressed. 27 524 250268 2 0.00% 0.00% 0.00% 0 TTY Background 28 816 254843 3 0.00% 0.00% 0.00% 0 Per-Second Jobs 29 101100 5053 20007 0.00% 0.01% 0.00% 0 Per-minute Jobs 30 26057260 26720902 975 12.07% 11.41% 11.36% 0 Cat4k Mgmt HiPri 31 19482908 29413060 662 24.07% 19.32% 19.20% 0 Cat4k Mgmt LoPri 32 4468 162748 27 0.00% 0.00% 0.00% 0 Galios Reschedul 33 0 1 0 0.00% 0.00% 0.00% 0 IOS ACL Helper 34 0 2 0 0.00% 0.00% 0.00% 0 NAM Manager
la Cinco-segunda utilización de la CPU se expresa como:
x%/y%
El x% representa el uso total de la CPU, y el y% representa el CPU que está pasado en el nivel de interrupción. Cuando usted resuelve problemas los Catalyst 4500 Switch, céntrese solamente en el uso total de la CPU.
Entienda el comando show processes cpu en los Catalyst 4500 Switch
Esta demostración procesa la salida CPU muestra que hay dos procesos que utilizan el CPU — mgmt HiPri Cat4k y mgmt LoPri Cat4k. Estos dos procesos agregan los procesos específicos de la plataforma múltiples que realizan las funciones de administración esenciales en el Catalyst 4500. Avión así como paquetes de datos del control de proceso de estos procesos que necesitan ser conmutados por software o procesaron.
Para ver cuáles de los procesos específicos de la plataforma utilizan el CPU bajo contexto del mgmt HiPri Cat4k y del mgmt LoPri Cat4k, publique el comando show platform health.
Cada uno de los procesos específicos de la plataforma tiene una blanco/una utilización prevista del CPU. Cuando ese proceso está dentro de la blanco, el CPU ejecuta el proceso en el contexto prioritario. La salida del comando show processes cpu cuenta esa utilización bajo el mgmt HiPri Cat4k. Si un proceso excede la blanco/la utilización prevista, los funcionamientos de ese proceso bajo contexto de la prioridad baja. La salida del comando show processes cpu cuenta esa utilización adicional bajo el mgmt LoPri Cat4k. Este mgmt LoPri Cat4k también se utiliza para funcionar con el fondo y otros procesos de baja prioridad, tales como contadores de la interfaz de la Verificación de consistencia y de la lectura. Este mecanismo permite que el CPU funcione con los procesos de prioridad alta cuando sea necesario, y los ciclos de la CPU ociosos que sigue habiendo se utilizan para los procesos de baja prioridad. Para exceder la utilización de la CPU de la blanco por un muy poco, o un punto momentáneo en la utilización, no es una indicación de un problema que necesite la investigación.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
S2w-JobEventSchedule 10.00 0.32 10 7 100 500 0 0 0 10:14
Stub-JobEventSchedul 10.00 12.09 10 6 100 500 14 13 9 396:35
StatValueMan Update 1.00 0.22 1 0 100 500 0 0 0 6:28
Pim-review 0.10 0.00 1 0 100 500 0 0 0 0:22
Ebm-host-review 1.00 0.00 8 0 100 500 0 0 0 0:05
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:01
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:00
Acl-Flattener e 1.00 0.00 10 0 100 500 0 0 0 0:00
KxAclPathMan create/ 1.00 0.00 10 5 100 500 0 0 0 0:39
KxAclPathMan update 2.00 0.00 10 0 100 500 0 0 0 0:00
KxAclPathMan reprogr 1.00 0.00 2 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 30.00 10.19 30 28 100 500 14 13 9 397:11
K2AccelPacketMan: Tx 10.00 2.20 20 0 100 500 2 2 1 82:06
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
K2AclCamMan stale en 1.00 0.00 10 0 100 500 0 0 0 0:00
K2AclCamMan hw stats 3.00 1.04 10 5 100 500 1 1 0 39:36
K2AclCamMan kx stats 1.00 0.00 10 5 100 500 0 0 0 13:40
K2AclCamMan Audit re 1.00 0.00 10 5 100 500 0 0 0 13:10
K2AclPolicerTableMan 1.00 0.00 10 1 100 500 0 0 0 0:38
K2L2 Address Table R 2.00 0.00 12 5 100 500 0 0 0 0:00
K2L2 New Static Addr 2.00 0.00 10 1 100 500 0 0 0 0:00
K2L2 New Multicast A 2.00 0.00 10 5 100 500 0 0 0 0:01
K2L2 Dynamic Address 2.00 0.00 10 0 100 500 0 0 0 0:00
K2L2 Vlan Table Revi 2.00 0.00 12 9 100 500 0 0 0 0:01
K2 L2 Destination Ca 2.00 0.00 10 0 100 500 0 0 0 0:00
K2PortMan Review 2.00 0.72 15 11 100 500 1 1 0 37:22
Gigaport65535 Review 0.40 0.07 4 2 100 500 0 0 0 3:38
Gigaport65535 Review 0.40 0.08 4 2 100 500 0 0 0 3:39
K2Fib cam usage revi 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib IrmFib Review 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Default Ro 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib AdjRepop Revie 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Unpunt Rev 2.00 0.01 15 0 100 500 0 0 0 0:23
K2Fib Consistency Ch 1.00 0.00 5 2 100 500 0 0 0 29:25
K2FibAdjMan Stats Re 2.00 0.30 10 4 100 500 0 0 0 6:21
K2FibAdjMan Host Mov 2.00 0.00 10 4 100 500 0 0 0 0:00
K2FibAdjMan Adj Chan 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibMulticast Signa 2.00 0.01 10 2 100 500 0 0 0 2:04
K2FibMulticast Entry 2.00 0.00 10 7 100 500 0 0 0 0:00
K2FibMulticast Irm M 2.00 0.00 10 7 100 500 0 0 0 0:00
K2FibFastDropMan Rev 2.00 0.00 7 0 100 500 0 0 0 0:00
K2FibPbr route map r 2.00 0.06 20 5 100 500 0 0 0 16:42
K2FibPbr flat acl pr 2.00 0.07 20 2 100 500 0 0 0 3:24
K2FibPbr consolidati 2.00 0.01 10 0 100 500 0 0 0 0:24
K2FibPerVlanPuntMan 2.00 0.00 15 4 100 500 0 0 0 0:00
K2FibFlowCache flow 2.00 0.01 10 0 100 500 0 0 0 0:23
K2FibFlowCache flow 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibFlowCache adj r 2.00 0.01 10 0 100 500 0 0 0 0:20
K2FibFlowCache flow 2.00 0.00 10 0 100 500 0 0 0 0:06
K2MetStatsMan Review 2.00 0.14 5 2 100 500 0 0 0 23:40
K2FibMulticast MET S 2.00 0.00 10 0 100 500 0 0 0 0:00
K2QosDblMan Rate DBL 2.00 0.12 7 0 100 500 0 0 0 4:52
IrmFibThrottler Thro 2.00 0.01 7 0 100 500 0 0 0 0:21
K2 VlanStatsMan Revi 2.00 1.46 15 7 100 500 2 2 1 64:44
K2 Packet Memory Dia 2.00 0.00 15 8 100 500 0 1 1 45:46
K2 L2 Aging Table Re 2.00 0.12 20 3 100 500 0 0 0 7:22
RkiosPortMan Port Re 2.00 0.73 12 7 100 500 1 1 1 52:36
Rkios Module State R 4.00 0.02 40 1 100 500 0 0 0 1:28
Rkios Online Diag Re 4.00 0.02 40 0 100 500 0 0 0 1:15
RkiosIpPbr IrmPort R 2.00 0.02 10 3 100 500 0 0 0 2:44
RkiosAclMan Review 3.00 0.06 30 0 100 500 0 0 0 2:35
MatMan Review 0.50 0.00 4 0 100 500 0 0 0 0:00
Slot 3 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 3 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 4 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 4 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 5 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 5 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 6 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 6 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 7 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 7 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
EthHoleLinecardMan(1 1.66 0.04 10 0 100 500 0 0 0 1:18
EthHoleLinecardMan(2 1.66 0.02 10 0 100 500 0 0 0 1:18
EthHoleLinecardMan(6 1.66 0.17 10 6 100 500 0 0 0 6:38
-------------
%CPU Totals 212.80 35.63
Entienda el comando show platform health en los Catalyst 4500 Switch
El comando show platform health proporciona mucha información que sea relevante solamente para un ingeniero de desarrollo. Para resolver problemas CPU elevada la utilización, busque un número más elevado en %CPU la columna real en la salida. También, esté seguro de echar un vistazo en el lado derecho de esa fila para verificar el USO de la CPU de ese proceso en las columnas de 1 minuto y de 1 media de la hora %CPU. A veces, los procesos momentáneamente máximos pero no celebran el CPU durante mucho tiempo. Algo momentáneamente CPU elevada de la utilización sucede durante la programación del hardware o la optimización de la programación. Por ejemplo, un punto de la utilización de la CPU es normal durante la programación del hardware de un ACL grande en el TCAM.
En la salida del comando show platform health en la sección entienda el comando show processes cpu en los Catalyst 4500 Switch, el stub-JobEventSchedul y los procesos del estudio del K2CpuMan utilizan un número más elevado de los ciclos de la CPU. El cuadro 2 proporciona una cierta información básica sobre los procesos específicos de la plataforma comunes que aparecen en la salida del comando show platform health.
Cuadro 2 – Descripción de los procesos específicos de la plataforma del comando show platform health| Nombre del proceso específico de la plataforma | Descripción |
|---|---|
| Pim-estudio | Administración de estados del chasis/del linecard |
| Ebm | Módulo de puente de Ethernet, tal como envejecimiento y supervisión |
| ACL-Flattener/K2AclMan | Proceso de la fusión de ACL |
| KxAclPathMan - TagMan-estudio de la trayectoria | Administración del estado de ACL y mantenimiento |
| Estudio del K2CpuMan | El proceso que realiza el reenvío de paquete del software si usted ve CPU elevada el utilización debido a este proceso, investiga los paquetes que golpean el CPU con el uso del comando show platform cpu packet statistics. |
| K2AccelPacketMan | El driver que obra recíprocamente con el motor del paquete para enviar los paquetes que son destinados del CPU |
| K2AclCamMan | Maneja el hardware TCAM entrada y salida para QoS y las funciones de seguridad |
| K2AclPolicerTableMan | Maneja el policers entrada y salida |
| K2L2 | Representa el subsistema de la expedición L2 del Cisco IOS Software del Catalyst 4500 que estos procesos son responsables del mantenimiento de las diversas tablas L2. |
| Estudio K2PortMan | Maneja las diversas funciones programadas portuarias |
| K2Fib | FIB1 Administración |
| K2FibFlowCache | PBR2 administración de caché |
| K2FibAdjMan | Administración de la tabla de adyacencia de la BOLA |
| K2FibMulticast | Maneja las entradas de la BOLA del Multicast |
| Estudio K2MetStatsMan | Maneja MET3 las estadísticas |
| Estudio K2QosDblMan | Maneja QoS DBL4 |
| IrmFibThrottler Thro | Módulo del Routing IP |
| K2L2 tabla de envejecimiento con referencia a | Maneja la función del envejecimiento L2 |
| GalChassisVp-estudio | El monitorear del estado del chasis |
| S2w-JobEventSchedule | Maneja S2W5 los protocolos para monitorear el estado del linecards |
| Stub-JobEventSchedul | El monitorear ASIC basado y mantenimiento del linecard del stub |
| Puerto del RkiosPortMan con referencia a | El monitorear y mantenimiento del estado de puerto |
| Estado R del módulo de Rkios | El monitorear y mantenimiento del linecard |
| EthHoleLinecardMan | Maneja GBIC6 en cada uno del linecards |
1 BOLA = base de información de reenvío.
2 PBR = Policy-Based Routing.
3 ENCONTRADO = tabla de la extensión del Multicast.
4 DBL = limitación dinámica del buffer.
5 S2W = serial-a-alambre.
6 GBIC = convertidor de la interfaz de Gigabite.
Problemas de utilización del campo común del Troubleshooting CPU elevada
Esta sección cubre algunos de los problemas de utilización del campo común CPU elevada en los Catalyst 4500 Switch.
CPU elevada utilización debido a los paquetes process-switched
Una de las razones comunes para CPU elevada la utilización es que el Catalyst 4500 CPU está ocupado con el proceso de los paquetes para los paquetes o los paquetes de control del software remitido. Los ejemplos de los paquetes del software remitido son IPX o paquetes de control, tales como BPDU. Una pequeña cantidad de estos paquetes se envían típicamente al CPU. Sin embargo, un número grande de paquetes puede indicar constantemente un Error de configuración o un evento de red. Usted debe identificar la causa de los eventos que llevan al delantero de los paquetes al CPU para procesar. Esta identificación le permite para hacer el debug de CPU elevada los problemas de utilización.
Algunas de las razones comunes para CPU elevada el utilización debido a los paquetes process-switched están:
Otras razones del Switch de los paquetes al CPU son:
-
Fragmentación de MTU — Esté seguro que todas las interfaces a lo largo de la trayectoria del paquete tienen el mismo MTU.
-
ACL con los indicadores TCP con excepción de establecido
-
El rutear del IP versión 6 (IPv6) — Esto se soporta solamente vía la trayectoria de la software-transferencia.
-
GRE — Esto se soporta solamente vía la trayectoria de la software-transferencia.
-
Negación del tráfico en el router ACL (RACL) de la entrada o de la salida
Nota: Ésta es tarifa limitada en el Cisco IOS Software Release 12.1(13)EW1 y Posterior.
Publique el comando no ip unreachables bajo interfaz del ACL.
-
El tráfico excesivo ARP y del DHCP golpea el CPU para procesar debido a un gran número directamente de host conectados
Si usted sospecha un ataque del DHCP, utilice el tráfico del DHCP del tarifa-límite del snooping DCHP de cualquier puerto de host específico.
-
Consulta SNMP excesiva por un legítimo o una estación terminal en mal funcionamiento
Un número alto de casos del puerto de árbol de expansión
El Catalyst 4500 soporta 3000 casos o puertos activos del puerto de árbol de expansión en por el árbol de expansión de VLAN + el modo (PVST+). El soporte está en todos los motores del supervisor, excepto el Supervisor Engine II+ y II+TS, y el Catalyst 4948. El Supervisor Engine II+ y II+TS y el soporte del Catalyst 4948 hasta 1500 casos del puerto. Si usted excede estas recomendaciones del STP-caso, el Switch exhibe CPU elevada la utilización.
Este diagrama muestra que un Catalyst 4500 con tres puertos troncales ese cada uno lleva los VLA N 1 a 100. Esto compara a 300 casos del puerto de árbol de expansión. Usted puede calcular generalmente los casos del puerto de árbol de expansión con esta fórmula:
Total number of STP instances = Number of access ports + Sum of all VLANs that are carried in each of the trunks
En el diagrama, no hay puertos de acceso, pero los tres trunks llevan los VLA N 1 a 100:
Total number of STP instances = 0 + 100 + 100 + 100 = 300
Paso 1: Marque para saber si hay el proceso del Cisco IOS con el comando show processes cpu.
Esta sección revisa los comandos que un administrador utiliza para estrechar abajo el problema CPU elevada de la utilización. Si usted publica el comando show processes cpu, usted puede ver que dos procesos principales, el mgmt LoPri Cat4k y el Spanning-tree, utilizan sobre todo el CPU. Con solamente esta información, usted sabe que el atravesar - el proceso del árbol consume una porción importante de los ciclos de la CPU.
Switch#show processes cpu CPU utilization for five seconds: 74%/1%; one minute: 73%; five minutes: 50% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 198 20 0.00% 0.00% 0.00% 0 Chunk Manager 2 4 290 13 0.00% 0.00% 0.00% 0 Load Meter !--- Output suppressed. 25 488 33 14787 0.00% 0.02% 0.00% 0 Per-minute Jobs 26 90656 223674 405 6.79% 6.90% 7.22% 0 Cat4k Mgmt HiPri 27 158796 59219 2681 32.55% 33.80% 21.43% 0 Cat4k Mgmt LoPri 28 20 1693 11 0.00% 0.00% 0.00% 0 Galios Reschedul 29 0 1 0 0.00% 0.00% 0.00% 0 IOS ACL Helper 30 0 2 0 0.00% 0.00% 0.00% 0 NAM Manager !--- Output suppressed. 41 0 1 0 0.00% 0.00% 0.00% 0 SFF8472 42 0 2 0 0.00% 0.00% 0.00% 0 AAA Dictionary R 43 78564 20723 3791 32.63% 30.03% 17.35% 0 Spanning Tree 44 112 999 112 0.00% 0.00% 0.00% 0 DTP Protocol 45 0 147 0 0.00% 0.00% 0.00% 0 Ethchnl
Paso 2: Marque para saber si hay el proceso del Catalyst 4500-specific con el comando show platform health.
Para entender qué proceso específico de la plataforma consume el CPU, publique el comando show platform health. De esta salida, usted puede ver que el proceso del estudio del K2CpuMan, un trabajo de manejar los paquetes del CPU-límite, las aplicaciones sube el CPU:
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 30.00 37.62 30 53 100 500 41 33 1 2:12
K2AccelPacketMan: Tx 10.00 4.95 20 0 100 500 5 4 0 0:36
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
Paso 3: Marque la cola CPU que recibe el tráfico para identificar el tipo de tráfico dirigido hacia la CPU.
Publique el comando show platform cpu packet statistics para marcar que la cola CPU recibe el paquete del CPU-límite. La salida en esta sección muestra que la cola del control recibe muchos paquetes. Utilice la información en el cuadro 1 y la conclusión que usted drenó en el paso 1. Usted puede determinar que los paquetes que el CPU procesa y la razón CPU elevada de la utilización son proceso BPDU.
Switch#show platform cpu packet statistics !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 202760 196 173 128 28 Control 388623 2121 1740 598 16 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Control 17918 0 19 24 3
Paso 4: Identifique la causa raíz.
Publique el comando show spanning-tree summary. Usted puede marcar si el recibo de los BPDU está debido a un número alto de casos del puerto de árbol de expansión. La salida identifica claramente la causa raíz:
Switch#show spanning-tree summary Switch is in pvst mode Root bridge for: none Extended system ID is enabled Portfast Default is disabled PortFast BPDU Guard Default is disabled Portfast BPDU Filter Default is disabled Loopguard Default is disabled EtherChannel misconfig guard is enabled UplinkFast is disabled BackboneFast is disabled Configured Pathcost method used is short !--- Output suppressed. Name Blocking Listening Learning Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------- 2994 vlans 0 0 0 5999 5999
Hay un gran número de VLA N con la configuración de modo PVST+. Para resolver el problema, cambie al modo STP a Múltiples Árboles de expansión (MST). En algunos casos, el número de casos STP es alto porque un número alto de VLA N se remite en todos los puertos troncales. En este caso, pode manualmente los VLA N que no son necesarios del trunk para caer el número de puertos activos STP a bien debajo del valor recomendado.
Consejo: Esté seguro que usted no configura los puertos del teléfono del IP como puertos troncales. Esto es configuraciones erróneas más comunes. Puertos del teléfono del IP de la configuración con una configuración de VLAN de la Voz. Esta configuración crea un pseudotroncal, pero no le requiere podar manualmente los vlanes innecesaria. Para más información sobre cómo configurar los puertos de voz, refiera a la guía de configuración de software de las interfaces de voz que configura. Los Teléfonos IP del no Cisco no soportan esta configuración del VLA N o del VLAN auxiliar de la Voz. Usted debe podar manualmente los puertos con los Teléfonos IP del no Cisco.
Redirecciones ICMP; Paquetes de ruteo en lo mismo interfaz
Los paquetes de ruteo en lo mismo interconectan, o el ingreso y la salida del tráfico en la misma interfaz L3, pueden dar lugar a una redirección ICMP por el Switch. Si el Switch sabe que el dispositivo de Next Hop al destino final está en la misma subred como el dispositivo remitente, el Switch genera la redirección ICMP a la fuente. Los mensajes de la reorientación indican a la fuente para enviar el paquete directamente al dispositivo de Next Hop. Los mensajes indican que el dispositivo de Next Hop tiene una mejor ruta al destino, una ruta de una menos salto que este Switch.
En el diagrama en esta sección, el PC A comunica con el servidor Web. El default gateway de las puntas PC A a la dirección IP de la interfaz del VLAN 100. Sin embargo, el Next Hop Router que permite al Catalyst 4500 para alcanzar el destino está en la misma subred como PC A. El mejor trayecto en este caso es enviar directamente al “router”. El Catalyst 4500 envía un mensaje de la redirección ICMP al PC A. El mensaje da instrucciones el PC A para enviar los paquetes destinados al servidor Web vía el router, en vez vía del Catalyst 4500. Sin embargo, en la mayoría de los casos, los dispositivos extremos no responden a la redirección ICMP. La falta de respuesta hace el Catalyst 4500 gastar muchos ciclos de la CPU en generación de estas redirecciones ICMP para todos los paquetes esos el Catalyst adelante vía la misma interfaz que los paquetes de ingreso.
Por abandono, se habilita la redirección ICMP. Para inhabilitarla, utilice el comando no ip icmp redirects. Publique el comando bajo interfaz relevante SVI o L3.
Nota: Puesto que el ICMP del IP reorienta es comando default, él no es visible en la salida del comando show running-configuration.
Paso 1: Comprobación para el proceso del Cisco IOS con el comando show processes cpu.
Publique el comando show processes cpu. Usted puede ver que dos procesos principales, el mgmt LoPri Cat4k y la entrada IP, utilizan sobre todo el CPU. Con solamente esta información, usted sabe que el proceso de los paquetes del IP gasta una porción importante del CPU.
Switch#show processes cpu CPU utilization for five seconds: 38%/1%; one minute: 32%; five minutes: 32% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 63 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 60 50074 1 0.00% 0.00% 0.00% 0 Load Meter 3 0 1 0 0.00% 0.00% 0.00% 0 Deferred Events !--- Output suppressed. 27 524 250268 2 0.00% 0.00% 0.00% 0 TTY Background 28 816 254843 3 0.00% 0.00% 0.00% 0 Per-Second Jobs 29 101100 5053 20007 0.00% 0.01% 0.00% 0 Per-minute Jobs 30 26057260 26720902 975 5.81% 6.78% 5.76% 0 Cat4k Mgmt HiPri 31 19482908 29413060 662 19.64% 18.20% 20.48% 0 Cat4k Mgmt LoPri !--- Output suppressed. 35 60 902 0 0.00% 0.00% 0.00% 0 DHCP Snooping 36 504625304 645491491 781 72.40% 72.63% 73.82% 0 IP Input
Paso 2: Marque para saber si hay el proceso del Catalyst 4500-specific con el comando show platform health.
La salida del comando show platform health confirma el uso del CPU para procesar los paquetes del CPU-límite.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 330.00 19.18 150 79 25 500 20 19 18 5794:08
K2AccelPacketMan: Tx 10.00 4.95 20 0 100 500 5 4 0 0:36
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
Paso 3: Marque la cola CPU que recibe el tráfico para identificar el tipo de tráfico dirigido hacia la CPU.
Publique el comando show platform cpu packet statistics para marcar que la cola CPU recibe el paquete del CPU-límite. Usted puede ver que la cola baja L3 Fwd recibe el bastantes de tráfico.
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 48613268 38 39 38 39 Control 142166648 74 74 73 73 Host Learning 1845568 2 2 2 2 L3 Fwd High 17 0 0 0 0 L3 Fwd Medium 2626 0 0 0 0 L3 Fwd Low 4717094264 3841 3879 3873 3547 L2 Fwd Medium 1 0 0 0 0 L3 Rx High 257147 0 0 0 0 L3 Rx Low 5325772 10 19 13 7 RPF Failure 155 0 0 0 0 ACL fwd(snooping) 65604591 53 54 54 53 ACL log, unreach 11013420 9 8 8 8
Paso 4: Identifique la causa raíz.
En este caso, utilice el SPAN CPU para determinar el tráfico que golpea el CPU. Para la información sobre el SPAN CPU, vea la herramienta 1: Monitoree el tráfico CPU con el SPAN — Sección del Cisco IOS Software Release 12.1(19)EW y Posterior de este documento. Complete un análisis del tráfico y una configuración con el uso del comando show running-configuration. En este caso, un paquete se rutea a través de la misma interfaz, que lleva a la aplicación una redirección ICMP para cada paquete. Esta causa raíz es una de las razones comunes para CPU elevada la utilización en el Catalyst 4500.
Usted puede esperar que el dispositivo de la compra de componentes actúe en la redirección ICMP que el Catalyst 4500 envía y cambia el salto siguiente para el destino. Sin embargo, no todos los dispositivos responden a una redirección ICMP. Si no responde el dispositivo, el Catalyst 4500 debe enviar reorienta para cada paquete que el Switch reciba del dispositivo remitente. Éstos reorientan pueden consumir a muchos recursos de la CPU. La solución es inhabilitar la redirección ICMP. Publique el comando no ip redirects bajo interfaces.
Este escenario puede ocurrir cuando usted también ha configurado las driección IP secundarias. Cuando usted habilita las driección IP secundarias, la redirección de IP se inhabilita automáticamente. Esté seguro que usted no habilita manualmente el IP reorienta.
Como este redirecciones ICMP; Los paquetes de ruteo en la misma sección de la interfaz han indicado, la mayoría de los dispositivos extremos no responden a las redirecciones ICMP. Por lo tanto, como práctica general, inhabilite esta característica.
Encaminamiento IPX o del APPLETALK
El Catalyst 4500 soporta el IPX y la encaminamiento del APPLETALK vía la trayectoria de la software-expedición solamente. Con la configuración de tales protocolos, una utilización de la CPU más alta es normal.
Nota: La transferencia del IPX y del tráfico del APPLETALK en el mismo VLA N no requiere el process switching. Solamente los paquetes que necesitan ser ruteados requieren la expedición del trayecto por software.
Paso 1: Marque para saber si hay el proceso del Cisco IOS con el comando show processes cpu.
Publique el comando show processes cpu para marcar que el proceso del Cisco IOS consume el CPU. En esta salida de comando, note que el proceso superior es el mgmt LoPri Cat4k:
witch#show processes cpu CPU utilization for five seconds: 87%/10%; one minute: 86%; five minutes: 87% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 53 75 0.00% 0.00% 0.00% 0 Chunk Manager !--- Output suppressed. 25 8008 1329154 6 0.00% 0.00% 0.00% 0 Per-Second Jobs 26 413128 38493 10732 0.00% 0.02% 0.00% 0 Per-minute Jobs 27 148288424 354390017 418 2.60% 2.42% 2.77% 0 Cat4k Mgmt HiPri 28 285796820 720618753 396 50.15% 59.72% 61.31% 0 Cat4k Mgmt LoPri
Paso 2: Comprobación para el proceso del Catalyst 4500-specific con el comando show platform health.
La salida del comando show platform health confirma el uso del CPU para procesar los paquetes del CPU-límite.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 4 100 500 0 0 0 0:00
K2CpuMan Review 30.00 27.39 30 53 100 500 42 47 42 4841:
K2AccelPacketMan: Tx 10.00 8.03 20 0 100 500 21 29 26 270:4
Paso 3: Marque la cola CPU que recibe el tráfico para identificar el tipo de tráfico dirigido hacia la CPU.
Para determinar el tipo de tráfico que golpea el CPU, publique el comando show platform cpu packet statistics.
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 48613268 38 39 38 39 Control 142166648 74 74 73 73 Host Learning 1845568 2 2 2 2 L3 Fwd High 17 0 0 0 0 L3 Fwd Medium 2626 0 0 0 0 L3 Fwd Low 1582414 1 1 1 1 L2 Fwd Medium 1 0 0 0 0 L2 Fwd Low 576905398 1837 1697 1938 1515 L3 Rx High 257147 0 0 0 0 L3 Rx Low 5325772 10 19 13 7 RPF Failure 155 0 0 0 0 ACL fwd(snooping) 65604591 53 54 54 53 ACL log, unreach 11013420 9 8 8 8
Paso 4: Identifique la causa raíz.
Puesto que el administrador ha configurado la encaminamiento IPX o del APPLETALK, la identificación de la causa raíz debe ser directa. Pero para confirmar, ATRAVIESE el tráfico CPU y esté seguro que el tráfico que usted ve es el tráfico previsto. Para la información sobre el SPAN CPU, vea la herramienta 1: Monitoree el tráfico CPU con el SPAN — Sección del Cisco IOS Software Release 12.1(19)EW y Posterior de este documento.
En este caso, el administrador debe poner al día la línea de fondo CPU al valor actual. El Catalyst 4500 CPU se comporta como se esperaba cuando el CPU procesa los paquetes conmutados por software.
Aprendizaje del host
El Catalyst 4500 aprende las direcciones MAC de los diversos host, si la dirección MAC no está ya en la tabla de la dirección MAC. El motor de Switching adelante una copia del paquete con la nueva dirección MAC al CPU.
Todas las interfaces VLAN (uso de la capa 3) la dirección de hardware de la base del chasis como su dirección MAC. Como consecuencia, no hay una entrada en la tabla de la dirección MAC, y los paquetes destinados a estas interfaces VLAN no se envían al CPU para procesar.
Si hay una cantidad excesiva de nuevas direcciones MAC para que el Switch aprenda, CPU elevada la utilización puede resultar.
Paso 1: Marque para saber si hay el proceso del Cisco IOS con el comando show processes cpu.
Publique el comando show processes cpu para marcar que el proceso del Cisco IOS consume el CPU. En esta salida de comando, note que el proceso superior es el mgmt LoPri Cat4k:
Switch#show processes cpu CPU utilization for five seconds: 89%/1%; one minute: 74%; five minutes: 71% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 53 75 0.00% 0.00% 0.00% 0 Chunk Manager !--- Output suppressed. 25 8008 1329154 6 0.00% 0.00% 0.00% 0 Per-Second Jobs 26 413128 38493 10732 0.00% 0.02% 0.00% 0 Per-minute Jobs 27 148288424 354390017 418 26.47% 10.28% 10.11% 0 Cat4k Mgmt HiPri 28 285796820 720618753 396 52.71% 56.79% 55.70% 0 Cat4k Mgmt LoPri
Paso 2: Comprobación para el proceso del Catalyst 4500-specific con el comando show platform health.
La salida del comando show platform health confirma el uso del CPU para procesar los paquetes del CPU-límite.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 4 100 500 0 0 0 0:00
K2CpuMan Review 30.00 46.88 30 47 100 500 30 29 21 265:01
K2AccelPacketMan: Tx 10.00 8.03 20 0 100 500 21 29 26 270:4
Paso 3: Marque la cola CPU que recibe el tráfico para identificar el tipo de tráfico dirigido hacia la CPU.
Para determinar el tipo de tráfico que golpea el CPU, publique el comando show platform cpu packet statistics.
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 48613268 38 39 38 39 Control 142166648 74 74 73 73 Host Learning 1845568 1328 1808 1393 1309 L3 Fwd High 17 0 0 0 0 L3 Fwd Medium 2626 0 0 0 0 L3 Fwd Low 1582414 1 1 1 1 L2 Fwd Medium 1 0 0 0 0 L2 Fwd Low 576905398 37 7 8 5 L3 Rx High 257147 0 0 0 0 L3 Rx Low 5325772 10 19 13 7 RPF Failure 155 0 0 0 0 ACL fwd(snooping) 65604591 53 54 54 53 ACL log, unreach 11013420 9 8 8 8
Paso 4: Identifique la causa raíz.
La salida del comando show platform health le muestra que el CPU ve muchas nuevas direcciones MAC. Esta situación es a menudo el resultado de la inestabilidad de la topología de red. Por ejemplo, si los cambia la topología del árbol de expansión, el Switch generan las notificaciones del cambio de la topología (TCN). La aplicación los TCN reduce el tiempo de envejecimiento a 15 segundos en el modo PVST+. Se vacian las entradas de MAC Address si los direccionamientos no se aprenden detrás dentro del período de tiempo. En el caso de STP rápido (RSTP) (IEEE 802.1W) o de MST (IEEE 802.1S), las entradas envejecen inmediatamente hacia fuera si el TCN viene de otro Switch. Esta edad hacia fuera hace las direcciones MAC ser aprendida de nuevo. Esto no es un aspecto importante si los cambios de la topología son raros. Pero puede haber una cantidad excesiva de cambios de la topología debido a un link inestable, switch defectuoso, o los puertos de host que no se habilitan para PortFast. Un gran número de rubores de la tabla MAC y de volver a aprender subsiguiente pueden resultar. El siguiente paso en la identificación de la causa raíz es resolver problemas la red. El Switch funciona como se esperaba y envía los paquetes al CPU para el aprendizaje de la dirección de host. Identifique y repare el dispositivo defectuoso ese los resultados en los TCN excesivos.
Su red puede tener muchos dispositivos que envíen el tráfico en las explosiones, que hace las direcciones MAC ser envejecido hacia fuera y ser vuelto a aprender posteriormente en el Switch. En este caso, aumente el tiempo de envejecimiento de la tabla de la dirección MAC para proporcionar un cierto alivio. Con un tiempo de envejecimiento más largo, el Switches conserva los MAC Address del dispositivos en la tabla por un período de tiempo más largo antes de la edad hacia fuera.
Precaución: Realice este cambio de la edad-hacia fuera sólo después de la consideración apropiada. El cambio puede llevar a un agujero negro del tráfico si usted tiene dispositivos en su red que sean móviles.
Fuera de los Recursos de hardware (TCAM) para el ACL de seguridad
El Catalyst 4500 programa los ACL configurados con el uso de Cisco TCAM. El TCAM permite la aplicación de los ACL en la trayectoria del hardware que reenvía. No hay impacto en el funcionamiento del Switch, con o sin los ACL en el trayecto de reenvío. El funcionamiento es constante a pesar del tamaño del ACL porque el funcionamiento de las búsquedas ACL está en la línea tarifa. Sin embargo, el TCAM es un recurso limitado. Por lo tanto, si usted configura una cantidad excesiva de entradas ACL, usted excede la capacidad TCAM. El cuadro 3 muestra el número de Recursos TCAM disponibles en cada uno de los motores y del Switches del supervisor del Catalyst 4500.
Cuadro 3 – Capacidad TCAM en los motores/el Switches del supervisor del Catalyst 4500| Producto | Característica TCAM (por la dirección) | QoS TCAM (por la dirección) |
|---|---|---|
| Supervisor Engine II+/II+TS | 8192 entradas con 1024 máscaras | 8192 entradas con 1024 máscaras |
| Supervisor Engine III/IV/V y Catalyst 4948 | 16,384 entradas con 2048 máscaras | 16,384 entradas con 2048 máscaras |
| V-10GE y Catalyst 4948-10GE del Supervisor Engine | 16,384 entradas con 16,384 máscaras | 16,384 entradas con 16,384 máscaras |
El Switch utiliza la característica TCAM para programar el ACL de seguridad, tal como RACL y VLA N ACL (VACL). El Switch también utiliza la característica TCAM para las funciones de seguridad como la Protección de origen IP (IPSG) para los ACL dinámicos. El Switch utiliza el QoS TCAM para programar la clasificación y el policer ACL.
Cuando el Catalyst 4500 se ejecuta de los Recursos TCAM durante la programación de un ACL de seguridad, una aplicación parcial del ACL ocurre vía el trayecto por software. Los paquetes que golpean esos ACE se procesan en el software, que causa CPU elevada la utilización. El ACL se programa de arriba hacia abajo. Es decir si el ACL no cabe en el TCAM, ACE en la porción inferior del ACL no se programa probablemente en el TCAM.
Este mensaje de advertencia aparece cuando sucede un desbordamiento TCAM:
%C4K_HWACLMAN-4-ACLHWPROGERRREASON: (Suppressed 1times) Input(null, 12/Normal) Security: 140 - insufficient hardware TCAM masks. %C4K_HWACLMAN-4-ACLHWPROGERR: (Suppressed 4 times) Input Security: 140 - hardware TCAM limit, some packet processing will be software switched.
Usted puede ver este mensaje de error en la salida del comando show logging. El mensaje indica concluyente que ocurrirá un cierto proceso del software y, por lo tanto, puede haber CPU elevada utilización.
Nota: Si usted cambia un ACL grande, usted puede ver este mensaje abreviadamente antes de que el ACL cambiado se programe otra vez en el TCAM.
Paso 1: Marque para saber si hay el proceso del Cisco IOS con el comando show processes cpu.
Publique el comando show processes cpu. Usted puede ver que la utilización de la CPU es alta porque el proceso de LoPri del mgmt Cat4k toma la mayor parte de los ciclos de la CPU.
Switch#show processes cpu CPU utilization for five seconds: 99%/0%; one minute: 99%; five minutes: 99% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 11 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 9716 632814 15 0.00% 0.00% 0.00% 0 Load Meter 3 780 302 2582 0.00% 0.00% 0.00% 0 SpanTree Helper !--- Output suppressed. 23 18208 3154201 5 0.00% 0.00% 0.00% 0 TTY Background 24 37208 3942818 9 0.00% 0.00% 0.00% 0 Per-Second Jobs 25 1046448 110711 9452 0.00% 0.03% 0.00% 0 Per-minute Jobs 26 175803612 339500656 517 4.12% 4.31% 4.48% 0 Cat4k Mgmt HiPri 27 835809548 339138782 2464 86.81% 89.20% 89.76% 0 Cat4k Mgmt LoPri 28 28668 2058810 13 0.00% 0.00% 0.00% 0 Galios Reschedul
Paso 2: Marque para saber si hay el proceso del Catalyst 4500-specific con el comando show platform health.
Publique el comando show platform health. Usted puede ver que el estudio del K2CpuMan, un trabajo de manejar los paquetes del CPU-límite, utiliza el CPU.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.01 2 0 100 500 0 0 0 13:45
GalChassisVp-review 3.00 0.20 10 16 100 500 0 0 0 88:44
S2w-JobEventSchedule 10.00 0.57 10 7 100 500 1 0 0 404:22
Stub-JobEventSchedul 10.00 0.00 10 0 100 500 0 0 0 0:00
StatValueMan Update 1.00 0.09 1 0 100 500 0 0 0 91:33
Pim-review 0.10 0.00 1 0 100 500 0 0 0 4:46
Ebm-host-review 1.00 0.00 8 4 100 500 0 0 0 14:01
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:20
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:01
Acl-Flattener 1.00 0.00 10 5 100 500 0 0 0 0:04
KxAclPathMan create/ 1.00 0.00 10 5 100 500 0 0 0 0:21
KxAclPathMan update 2.00 0.00 10 6 100 500 0 0 0 0:05
KxAclPathMan reprogr 1.00 0.00 2 1 100 500 0 0 0 0:00
TagMan-InformMtegRev 1.00 0.00 5 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 14 100 500 0 0 0 0:18
K2CpuMan Review 30.00 91.31 30 92 100 500 128 119 84 13039:02
K2AccelPacketMan: Tx 10.00 2.30 20 0 100 500 2 2 2 1345:30
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
Paso 3: Marque la cola CPU que recibe el tráfico para identificar el tipo de tráfico dirigido hacia la CPU.
Usted necesita entender más lejos qué cola CPU y, por lo tanto, qué tipo de tráfico golpea la cola CPU. Publique el comando show platform cpu packet statistics. Usted puede ver que el interruptor ACL que procesa la cola recibe un número alto de paquetes. Por lo tanto, el desbordamiento TCAM es la causa de este CPU elevada problema de la utilización.
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Control 57902635 22 16 12 3 Host Learning 464678 0 0 0 0 L3 Fwd Low 623229 0 0 0 0 L2 Fwd Low 11267182 7 4 6 1 L3 Rx High 508 0 0 0 0 L3 Rx Low 1275695 10 1 0 0 ACL fwd(snooping) 2645752 0 0 0 0 ACL log, unreach 51443268 9 4 5 5 ACL sw processing 842889240 1453 1532 1267 1179 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- L2 Fwd Low 3270 0 0 0 0 ACL sw processing 12636 0 0 0 0
Paso 4: Resolver el problema.
En el paso 3, usted determinó la causa raíz en este escenario. Quite el ACL que causó el desbordamiento o minimiza el ACL para evitar el desbordamiento. También, revise la seguridad de la red que configura con la pauta de configuración ACL para optimizar la configuración ACL y la programación en el hardware.
La palabra clave del registro en el ACL
El Catalyst 4500 soporta el registro del detalle de los paquetes que golpea cualquier entrada ACL específica, pero el registro excesivo puede causar CPU elevada la utilización. Evite el uso de las palabras claves del registro, excepto durante la etapa de detección del tráfico. Durante la etapa de detección del tráfico, usted identifica el tráfico que atraviesa su red para la cual usted no ha configurado explícitamente los ACE. No utilice la palabra clave del registro para recopilar las estadísticas. En el Cisco IOS Software Release 12.1(13)EW y Posterior, los mensajes del registro son tarifa limitada. Si usted utiliza los mensajes del registro para contar el número de paquetes que hagan juego el ACL, la cuenta no es exacta. En lugar, utilice el comando show access-list para las estadísticas exactas. La identificación de esta causa raíz es más fácil porque un estudio de la configuración o de los mensajes del registro puede indicar el uso de la característica del registro de ACL.
Paso 1: Marque para saber si hay el proceso del Cisco IOS con el comando show processes cpu.
Publique la CPU de los procesos de la demostración para marcar que el proceso del Cisco IOS consume el CPU. En esta salida de comando, usted encuentra que el proceso superior es el mgmt LoPri Cat4k:
Switch#show processes cpu CPU utilization for five seconds: 99%/0%; one minute: 99%; five minutes: 99% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 11 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 9716 632814 15 0.00% 0.00% 0.00% 0 Load Meter !--- Output suppressed. 26 175803612 339500656 517 4.12% 4.31% 4.48% 0 Cat4k Mgmt HiPri 27 835809548 339138782 2464 86.81% 89.20% 89.76% 0 Cat4k Mgmt LoPri 28 28668 2058810 13 0.00% 0.00% 0.00% 0 Galios Reschedul
Paso 2: Comprobación para el proceso del Catalyst 4500-specific con el comando show platform health.
Marque el proceso específico de la plataforma que utiliza el CPU. Publique el comando show platform health. En la salida, note que el proceso del estudio del K2CpuMan utiliza la mayor parte de los ciclos de la CPU. Esta actividad indica que el CPU está ocupado como él procesa los paquetes destinados a él.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.01 2 0 100 500 0 0 0 13:45
GalChassisVp-review 3.00 0.20 10 16 100 500 0 0 0 88:44
S2w-JobEventSchedule 10.00 0.57 10 7 100 500 1 0 0 404:22
Stub-JobEventSchedul 10.00 0.00 10 0 100 500 0 0 0 0:00
StatValueMan Update 1.00 0.09 1 0 100 500 0 0 0 91:33
Pim-review 0.10 0.00 1 0 100 500 0 0 0 4:46
Ebm-host-review 1.00 0.00 8 4 100 500 0 0 0 14:01
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:20
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:01
Acl-Flattener 1.00 0.00 10 5 100 500 0 0 0 0:04
KxAclPathMan create/ 1.00 0.00 10 5 100 500 0 0 0 0:21
KxAclPathMan update 2.00 0.00 10 6 100 500 0 0 0 0:05
KxAclPathMan reprogr 1.00 0.00 2 1 100 500 0 0 0 0:00
TagMan-InformMtegRev 1.00 0.00 5 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 14 100 500 0 0 0 0:18
K2CpuMan Review 30.00 91.31 30 92 100 500 128 119 84 13039:02
K2AccelPacketMan: Tx 10.00 2.30 20 0 100 500 2 2 2 1345:30
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
Paso 3: Marque la cola CPU que recibe el tráfico para identificar el tipo de tráfico dirigido hacia la CPU.
Para determinar el tipo de tráfico que golpea el CPU, publique el comando show platform cpu packet statistics. En esta salida de comando, usted puede ver que el recibo de los paquetes es debido a la palabra clave de registro de ACL:
Switch#show platform cpu packet statistics !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ----------------- -------------------- --------- --------- --------- ---------- Control 1198701435 35 35 34 35 Host Learning 874391 0 0 0 0 L3 Fwd High 428 0 0 0 0 L3 Fwd Medium 12745 0 0 0 0 L3 Fwd Low 2420401 0 0 0 0 L2 Fwd High 26855 0 0 0 0 L2 Fwd Medium 116587 0 0 0 0 L2 Fwd Low 317829151 53 41 31 31 L3 Rx High 2371 0 0 0 0 L3 Rx Low 32333361 7 1 2 0 RPF Failure 4127 0 0 0 0 ACL fwd (snooping) 107743299 4 4 4 4 ACL log, unreach 1209056404 1987 2125 2139 2089 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ----------------- -------------------- --------- --------- --------- ---------- ACL log, unreach 193094788 509 362 437 394
Paso 4: Resolver el problema.
En el paso 3, usted determinó la causa raíz en este escenario. Para prevenir este problema, quite la palabra clave del registro de los ACL. En el Cisco IOS Software Release 12.1(13)EW1 y Posterior, los paquetes son tarifa limitada de modo que la utilización de la CPU no consiga demasiado alta. Utilice los contadores de la lista de acceso como manera de no perder de vista los hit ACL. Usted puede ver los contadores de la lista de acceso en la salida del comando show access-list acl_id.
Loopes de envío de la capa 2
Los loopes de envío de la capa 2 se pueden causar por la implementación pobre del Spanning Tree Protocol (STP) y de los diversos problemas que puede afectar al STP.
Paso 1: Marque para saber si hay el proceso del Cisco IOS con el comando show processes cpu
Esta sección revisa los comandos que un administrador utiliza para estrechar abajo el problema CPU elevada de la utilización. Si usted publica el comando show processes cpu, usted puede ver que dos procesos principales, el mgmt LoPri Cat4k y el Spanning-tree, utilizan sobre todo el CPU. Con solamente esta información, usted sabe que el atravesar - el proceso del árbol consume una porción importante de los ciclos de la CPU.
Switch#show processes cpu CPU utilization for five seconds: 74%/1%; one minute: 73%; five minutes: 50% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 198 20 0.00% 0.00% 0.00% 0 Chunk Manager 2 4 290 13 0.00% 0.00% 0.00% 0 Load Meter !--- Output suppressed. 25 488 33 14787 0.00% 0.02% 0.00% 0 Per-minute Jobs 26 90656 223674 405 6.79% 6.90% 7.22% 0 Cat4k Mgmt HiPri 27 158796 59219 2681 32.55% 33.80% 21.43% 0 Cat4k Mgmt LoPri 28 20 1693 11 0.00% 0.00% 0.00% 0 Galios Reschedul 29 0 1 0 0.00% 0.00% 0.00% 0 IOS ACL Helper 30 0 2 0 0.00% 0.00% 0.00% 0 NAM Manager !--- Output suppressed. 41 0 1 0 0.00% 0.00% 0.00% 0 SFF8472 42 0 2 0 0.00% 0.00% 0.00% 0 AAA Dictionary R 43 78564 20723 3791 32.63% 30.03% 17.35% 0 Spanning Tree 44 112 999 112 0.00% 0.00% 0.00% 0 DTP Protocol 45 0 147 0 0.00% 0.00% 0.00% 0 Ethchnl
Paso 2: Marque para saber si hay el proceso del Catalyst 4500-specific con el comando show platform health
Para entender qué proceso específico de la plataforma consume el CPU, publique el comando show platform health. De esta salida, usted puede ver que el proceso del estudio del K2CpuMan, un trabajo de manejar los paquetes del CPU-límite, las aplicaciones sube el CPU:
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 30.00 37.62 30 53 100 500 41 33 1 2:12
K2AccelPacketMan: Tx 10.00 4.95 20 0 100 500 5 4 0 0:36
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
Paso 3: Marque la cola CPU que recibe el tráfico para identificar el tipo de tráfico dirigido hacia la CPU
Publique el comando show platform cpu packet statistics para marcar que la cola CPU recibe el paquete del CPU-límite. La salida en esta sección muestra que la cola del control recibe muchos paquetes. Utilice la información en el cuadro 1 y la conclusión que usted drenó en el paso 1. Usted puede determinar que los paquetes que el CPU procesa y la razón CPU elevada de la utilización son proceso BPDU.
Switch#show platform cpu packet statistics !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 202760 196 173 128 28 Control 388623 2121 1740 598 16 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Control 17918 0 19 24 3
Paso 4: Identifique la causa raíz y repare el problema
Generalmente, usted puede completar estos pasos para resolver problemas (dependiendo de la situación, algunos pasos no son ser necesarios):
-
Identifique el loop.
-
Descubra el alcance del loop.
-
Rompa el loop.
-
Repare la causa para el loop.
-
Restablezca el redunancy.
Cada uno de los pasos se explica detalladamente en los loopes de la expedición del troubleshooting - resolver problemas el STP en los switches de Catalyst que funcionan con el software del sistema del Cisco IOS.
Paso 5: Implement avanzó las características STP
-
Guardia BDPU — Asegura el STP de los dispositivos de red desautorizados conectados con los puertos habilitados del portfast. Refiera a la mejora de la protección BPDU del árbol de expansión Portfast para más información.
-
Loop Guard — Aumenta la estabilidad de las redes de la capa 2. Refiera a las mejoras del Spanning-Tree Protocol usando el Loop Guard y a las características de detección oblicua BPDU para más información.
-
Protección raíz — Aplica la colocación del Root Bridge en la red. Consulte Mejora de Protección de Raíz en Spanning-Tree Protocol para obtener más información.
-
UDLD — Detecta los links unidireccionales y evita el envío de los loopes. Refiera a entender y a configurar la función del Unidirectional Link Detection Protocol para más información.
Otras causas CPU elevada de la utilización
Éstas son algunas otras causas sabidas CPU elevada de la utilización:
-
Puntos en la utilización de la CPU debida MENTIR la Verificación de consistencia
-
CPU elevada utilización en el proceso del movimiento del host del K2FibAdjMan
-
CPU elevada utilización en el proceso del estudio del puerto del RkiosPortMan
-
CPU elevada la utilización con el RSPAN y acoda 3 paquetes de control
-
Punto durante la programación grande ACL
El punto en la utilización de la CPU ocurre durante la aplicación o el retiro de un ACL grande de una interfaz.
Aletas excesivas del link
El Catalyst 4500 exhibe CPU elevada la utilización cuando uno o más de los links asociados comienzan a agitar excesivamente. Esta situación ocurre en las versiones de Cisco IOS Software anterior que el Cisco IOS Software Release 12.2(20)EWA.
Paso 1: Marque para saber si hay el proceso del Cisco IOS con el comando show processes cpu.
Publique el comando show processes cpu para marcar que el proceso del Cisco IOS consume el CPU. En esta salida de comando, note que el proceso superior es el mgmt LoPri Cat4k:
Switch#show processes cpu CPU utilization for five seconds: 96%/0%; one minute: 76%; five minutes: 68% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 9840 463370 21 0.00% 0.00% 0.00% 0 Load Meter 3 0 2 0 0.00% 0.00% 0.00% 0 SNMP Timers !--- Output suppressed. 27 232385144 530644966 437 13.98% 12.65% 12.16% 0 Cat4k Mgmt HiPri 28 564756724 156627753 3605 64.74% 60.71% 54.75% 0 Cat4k Mgmt LoPri 29 9716 1806301 5 0.00% 0.00% 0.00% 0 Galios Reschedul
Paso 2: Comprobación para el proceso del Catalyst 4500-specific con el comando show platform health.
La salida del comando show platform health indica que el KxAclPathMan crea las aplicaciones de proceso encima del CPU. Este proceso está para la creación del trayecto interno.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.03 2 0 100 500 0 0 0 9:49
GalChassisVp-review 3.00 1.11 10 62 100 500 0 0 0 37:39
S2w-JobEventSchedule 10.00 2.85 10 8 100 500 2 2 2 90:00
Stub-JobEventSchedul 10.00 5.27 10 9 100 500 4 4 4 186:2
Pim-review 0.10 0.00 1 0 100 500 0 0 0 2:51
Ebm-host-review 1.00 0.00 8 4 100 500 0 0 0 8:06
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:14
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:00
Acl-Flattener 1.00 0.00 10 5 100 500 0 0 0 0:00
KxAclPathMan create/ 1.00 69.11 10 5 100 500 42 53 22 715:0
KxAclPathMan update 2.00 0.76 10 6 100 500 0 0 0 86:00
KxAclPathMan reprogr 1.00 0.00 2 1 100 500 0 0 0 0:00
TagMan-InformMtegRev 1.00 0.00 5 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 227 100 500 0 0 0 0:00
K2CpuMan Review 30.00 8.05 30 57 100 500 6 5 5 215:0
K2AccelPacketMan: Tx 10.00 6.86 20 0 100 500 5 5 4 78:42
Paso 3: Identifique la causa raíz.
Habilite el registro para los mensajes arriba/abajos del link. Este registro no se habilita por abandono. La habilitación le ayuda a estrechar abajo los links que ofenden muy rápidamente. Publique el comando logging event link-status bajo todas las interfaces. Usted puede utilizar el comando interface range para habilitar convenientemente en un rango de las interfaces, pues este ejemplo muestra:
Switch#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Switch(config)#interface range gigabitethernet 5/1 - 48 Switch(config-if-range)#logging event link-status Switch(config--if-range)#end
Switch#show logging !--- Output suppressed. 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to down 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to up 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to down 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to up 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to down 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to up
Después de que usted haya identificado el defectuoso o la interfaz inestable, apague la interfaz para resolver CPU elevada el problema de la utilización. El Cisco IOS Software Release 12.2(20)EWA y Posterior ha mejorado el comportamiento del Catalyst 4500 para esta condición de los links alternados. Por lo tanto, el impacto en el CPU no es tan grande como antes de la mejora. Recuerde que este proceso es un proceso de origen. CPU elevada la utilización debido a este problema no causa los efectos adversos en los Catalyst 4500 Switch.
Puntos en la utilización de la CPU debida MENTIR la Verificación de consistencia
El Catalyst 4500 puede mostrar los puntos momentáneos en la utilización de la CPU durante una Verificación de consistencia de la tabla de FIB. La tabla de FIB es la tabla de reenvío L3 que el proceso CEF crea. La Verificación de consistencia mantiene el estado coherente entre la tabla de FIB del Cisco IOS Software y las entradas del hardware. Este estado coherente se asegura de que los paquetes no estén encaminados erróneamente. El control ocurre cada 2 segundos y se ejecuta como proceso de origen de la prioridad baja. Este proceso es comportamiento normal y no interfiere con otros procesos de prioridad alta o paquetes.
La salida del comando show platform health muestra que el estado coherente Ch K2Fib consume la mayor parte del CPU.
Nota: La utilización de la CPU media para este proceso es insignificante durante un minuto o una hora, que confirma que el control es una revisión periódica corta. Este proceso de origen utiliza solamente los ciclos de la CPU ociosos.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
!--- Output suppressed.
K2Fib cam usage revi 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib IrmFib Review 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Default Ro 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib AdjRepop Revie 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Unpunt Rev 2.00 0.01 15 0 100 500 0 0 0 0:23
K2Fib Consistency Ch 1.00 60.40 5 2 100 500 0 0 0 100:23
K2FibAdjMan Stats Re 2.00 0.30 10 4 100 500 0 0 0 6:21
K2FibAdjMan Host Mov 2.00 0.00 10 4 100 500 0 0 0 0:00
K2FibAdjMan Adj Chan 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibMulticast Signa 2.00 0.01 10 2 100 500 0 0 0 2:04
CPU elevada utilización en el proceso del movimiento del host del K2FibAdjMan
El Catalyst 4500 puede visualizar CPU elevada la utilización en el proceso del movimiento del host del K2FibAdjMan. Esta utilización intensa aparece en la salida del comando show platform health. Muchas direcciones MAC expiran o se aprenden con frecuencia en los nuevos puertos, que causa esta CPU elevada utilización. El valor predeterminado del tiempo de envejecimiento del mac-address-table es 5 minutos o 300 segundos. La solución alternativa para este problema es aumentar el tiempo de envejecimiento de la dirección MAC, o usted puede dirigir la red para evitar el número alto de movimientos de la dirección MAC. El Cisco IOS Software Release 12.2(18)EW y Posterior ha aumentado este comportamiento del proceso para consumir menos CPU. Refiera al Id. de bug Cisco CSCed15021
(clientes registrados solamente).
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
S2w-JobEventSchedule 10.00 0.32 10 7 100 500 0 0 0 10:14
!--- Output suppressed.
K2FibAdjMan Stats Re 2.00 0.30 10 4 100 500 0 0 0 6:21
K2FibAdjMan Host Mov 2.00 18.68 10 4 100 500 25 29 28 2134:39
K2FibAdjMan Adj Chan 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibMulticast Signa 2.00 0.01 10 2 100 500 0 0 0 2:04
K2FibMulticast Entry 2.00 0.00 10 7 100 500 0 0 0 0:00
Usted puede modificar el tiempo máximo de desactualización de una dirección MAC en el modo de configuración global. La sintaxis de los comandos es segundos del tiempo de envejecimiento del mac-address-table para un router y el [vlan vlan-id] de los segundos del tiempo de envejecimiento del mac-address-table para un switch de Catalyst. Para más información, refiera al guía de referencia de comandos del Cisco IOS Switching Services.
CPU elevada utilización en el proceso del estudio del puerto del RkiosPortMan
El Catalyst 4500 puede visualizar CPU elevada la utilización en el proceso del estudio del puerto del RkiosPortMan en la salida del comando show platform health en el Cisco IOS Software Release 12.2(25)EWA y 12.2(25)EWA1. El Id. de bug Cisco CSCeh08768 (clientes registrados solamente) causa la utilización intensa, que el Cisco IOS Software Release 12.2(25)EWA2 resuelve. Este proceso es un proceso de origen y no afecta a la estabilidad de los Catalyst 4500 Switch.
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
S2w-JobEventSchedule 10.00 0.32 10 7 100 500 0 0 0 10:14
!--- Output suppressed.
K2 Packet Memory Dia 2.00 0.00 15 8 100 500 0 1 1 45:46
K2 L2 Aging Table Re 2.00 0.12 20 3 100 500 0 0 0 7:22
RkiosPortMan Port Re 2.00 87.92 12 7 100 500 99 99 89 1052:36
Rkios Module State R 4.00 0.02 40 1 100 500 0 0 0 1:28
Rkios Online Diag Re 4.00 0.02 40 0 100 500 0 0 0 1:15
CPU elevada utilización cuando está conectado con un teléfono del IP con el uso de los puertos troncales
Si un puerto se configura para la opción del VLA N de la Voz y la opción del VLA N del acceso, el puerto actúa como puerto de acceso del VLAN multi. La ventaja es que solamente esos VLA N que se configuran para las opciones del VLA N de la Voz y del acceso son trunked.
Los VLA N que son trunked al aumento del teléfono el número de STP citan como ejemplo. El Switch maneja los casos STP. La Administración del aumento en el STP cita como ejemplo también aumenta la utilización de la CPU STP.
El enlace de todos los VLA N también hace el broadcast innecesario, el Multicast, y el tráfico de la unidifusión desconocida golpear el link del teléfono.
Switch#show processes cpu CPU utilization for five seconds: 69%/0%; one minute: 72%; five minutes: 73% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 165 24 0.00% 0.00% 0.00% 0 Chunk Manager 2 29012 739091 39 0.00% 0.00% 0.00% 0 Load Meter 3 67080 13762 4874 0.00% 0.00% 0.00% 0 SpanTree Helper 4 0 1 0 0.00% 0.00% 0.00% 0 Deferred Events 5 0 2 0 0.00% 0.00% 0.00% 0 IpSecMibTopN 6 4980144 570766 8725 0.00% 0.09% 0.11% 0 Check heaps 26 539173952 530982442 1015 13.09% 13.05% 13.20% 0 Cat4k Mgmt HiPri 27 716335120 180543127 3967 17.61% 18.19% 18.41% 0 Cat4k Mgmt LoPri 33 1073728 61623 17424 0.00% 0.03% 0.00% 0 Per-minute Jobs 34 1366717824 231584970 5901 38.99% 38.90% 38.92% 0 Spanning Tree 35 2218424 18349158 120 0.00% 0.03% 0.02% 0 DTP Protocol 36 5160 369525 13 0.00% 0.00% 0.00% 0 Ethchnl 37 271016 2308022 117 0.00% 0.00% 0.00% 0 VLAN Manager 38 958084 3965585 241 0.00% 0.01% 0.01% 0 UDLD 39 1436 51011 28 0.00% 0.00% 0.00% 0 DHCP Snooping 40 780 61658 12 0.00% 0.00% 0.00% 0 Port-Security 41 1355308 12210934 110 0.00% 0.01% 0.00% 0 IP Input
CPU elevada la utilización con el RSPAN y acoda 3 paquetes de control
Acode 3 paquetes de control que se capturen con el RSPAN se destinen al CPU bastante que apenas la interfaz del destino RSPAN, que causa CPU elevada. Los paquetes de control L3 son capturados por las entradas de CAM estáticas con delantero a la acción CPU. Las entradas de CAM estáticas son globales a todos los VLA N. Para evitar la inundación innecesaria CPU, utilice la característica de la interceptación del tráfico de control del por el VLAN, disponible en los Cisco IOS Software Release 12.2(37)SG y Posterior.
Switch(config)# access-list hardware capture mode vlan
Los ACL estáticos están instalados en el top en la característica TCAM de la entrada para capturar los paquetes de control destinados a los IP Multicast Address bien conocidos en el rango 224.0.0.*. Los ACL estáticos están instalados en el tiempo del inicio y aparecen antes de cualquier usuario configurado ACL. Los ACL estáticos se golpean siempre primero e interceptan el tráfico de control al CPU en todos los VLA N.
La característica de la interceptación del tráfico de control del por el VLAN proporciona el modo manejado trayectoria selectiva del por el VLAN de capturar el tráfico de control. Las entradas de CAM estáticas correspondientes en la característica TCAM de la entrada se invalidan en el nuevo modo. Los paquetes de control son capturados por la característica ACL específico asociados a los VLA N en los cuales se habilita el snooping o las funciones de ruteo. No hay característica ACL específico asociada al VLA N RSPAN. Por lo tanto, todos acodan 3 paquetes de control recibidos del VLA N RSPAN no se remiten al CPU.
Herramientas de Troubleshooting para analizar el tráfico destinado al CPU
Pues este documento ha mostrado, trafique que se destina al CPU es una de las causas principales CPU elevada de la utilización en el Catalyst 4500. El tráfico CPU-destinado puede ser intencional debido a la configuración, o involuntario debido al misconfiguration o un establecimiento de rechazo del servicio. El CPU tiene un mecanismo de Calidad de servicio (QoS) integrado para prevenir cualquier efecto adverso de la red debido a este tráfico. Sin embargo, identifique la causa raíz del tráfico dirigido hacia la CPU y elimine el tráfico si es indeseable.
Herramienta 1: Monitoree el tráfico CPU con el SPAN — Cisco IOS Software Release 12.1(19)EW y Posterior
El Catalyst 4500 permite el monitor del tráfico dirigido hacia la CPU, ingreso o salida, con el uso de la función estándar del SPAN. La interfaz de destino conecta con un monitor del paquete o una laptop del administrador que funcione con el software del sabueso de paquete. Esta herramienta ayuda analiza a rápidamente y exactamente el tráfico ese los procesos CPU. La herramienta proporciona la capacidad de monitorear las colas de administración del tráfico individuales que están limitadas al motor de paquetes de la CPU.
Nota: El motor de Switching tiene 32 colas de administración del tráfico para el tráfico CPU, y el motor de paquetes de la CPU tiene 16 colas de administración del tráfico.
Switch(config)#monitor session 1 source cpu ?
both Monitor received and transmitted traffic
queue SPAN source CPU queue
rx Monitor received traffic only
tx Monitor transmitted traffic only
<cr>
Switch(config)#monitor session 1 source cpu queue ?
<1-32> SPAN source CPU queue numbers
acl Input and output ACL [13-20]
adj-same-if Packets routed to the incoming interface [7]
all All queues [1-32]
bridged L2/bridged packets [29-32]
control-packet Layer 2 Control Packets [5]
mtu-exceeded Output interface MTU exceeded [9]
nfl Packets sent to CPU by netflow (unused) [8]
routed L3/routed packets [21-28]
rpf-failure Multicast RPF Failures [6]
span SPAN to CPU (unused) [11]
unknown-sa Packets with missing source address [10]
Switch(config)#monitor session 1 source cpu queue all rx
Switch(config)#monitor session 1 destination interface gigabitethernet 1/3
Switch(config)#end
4w6d: %SYS-5-CONFIG_I: Configured from console by console
Switch#show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
RX Only : CPU
Destination Ports : Gi1/3
Encapsulation : Native
Ingress : Disabled
Learning : Disabled
Si usted conecta un PC que funcione con un programa del sniffer, usted puede analizar rápidamente el tráfico. En la salida que aparece en la ventana en esta sección, usted puede ver que la causa CPU elevada de la utilización es una cantidad excesiva de STP BPDU.
Nota: El STP BPDU en el rastreador de CPU es normal. Pero si usted ve más que usted esperar, usted pudo haber excedido los límites recomendados para su Supervisor Engine. Vea un número alto de sección de los casos del puerto de árbol de expansión de este documento para más información.
Herramienta 2: Rastreador de CPU integrado — Cisco IOS Software Release 12.2(20)EW y Posterior
El Catalyst 4500 proporciona un rastreador de CPU y un decodificador integrados para identificar rápidamente el tráfico que golpea el CPU. Usted puede habilitar este recurso con el comando debug, pues el ejemplo en esta sección muestra. Esto ofrece implementa un buffer circular que pueda conservar 1024 en un momento de los paquetes. Mientras que llegan los nuevos paquetes, sobregraban los paquetes más viejos. Esta característica es segura de utilizar cuando usted resuelve problemas CPU elevada los problemas de la utilización.
Switch#debug platform packet all receive buffer platform packet debugging is on Switch#show platform cpu packet buffered Total Received Packets Buffered: 36 ------------------------------------- Index 0: 7 days 23:6:32:37214 - RxVlan: 99, RxPort: Gi4/48 Priority: Crucial, Tag: Dot1Q Tag, Event: Control Packet, Flags: 0x40, Size: 68 Eth: Src 00-0F-F7-AC-EE-4F Dst 01-00-0C-CC-CC-CD Type/Len 0x0032 Remaining data: 0: 0xAA 0xAA 0x3 0x0 0x0 0xC 0x1 0xB 0x0 0x0 10: 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 0x63 0x28 20: 0x62 0x0 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 30: 0x63 0x28 0x62 0x80 0xF0 0x0 0x0 0x14 0x0 0x2 40: 0x0 0xF 0x0 0x0 0x0 0x0 0x0 0x2 0x0 0x63 Index 1: 7 days 23:6:33:180863 - RxVlan: 1, RxPort: Gi4/48 Priority: Crucial, Tag: Dot1Q Tag, Event: Control Packet, Flags: 0x40, Size: 68 Eth: Src 00-0F-F7-AC-EE-4F Dst 01-00-0C-CC-CC-CD Type/Len 0x0032 Remaining data: 0: 0xAA 0xAA 0x3 0x0 0x0 0xC 0x1 0xB 0x0 0x0 10: 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 0x63 0x28 20: 0x62 0x0 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 30: 0x63 0x28 0x62 0x80 0xF0 0x0 0x0 0x14 0x0 0x2 40: 0x0 0xF 0x0 0x0 0x0 0x0 0x0 0x2 0x0 0x63
Nota: La utilización de la CPU cuando usted publica un comando debug es siempre el casi 100%. Es normal tener CPU elevada utilización cuando usted publica un comando debug.
Herramienta 3: Identifique la interfaz que envía el tráfico al CPU — Cisco IOS Software Release 12.2(20)EW y Posterior
El Catalyst 4500 proporciona otra herramienta útil para identificar las interfaces superiores que envían el tráfico/los paquetes para procesamiento de la CPU. Esta herramienta le ayuda rápidamente a identificar un dispositivo errante que envíe un número alto de broadcast o de otros establecimientos de rechazo del servicio al CPU. Esta característica es también segura de utilizar cuando usted resuelve problemas CPU elevada los problemas de la utilización.
Switch#debug platform packet all count platform packet debugging is on Switch#show platform cpu packet statistics !--- Output suppressed. Packets Transmitted from CPU per Output Interface Interface Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Gi4/47 1150 1 5 10 0 Gi4/48 50 1 0 0 0 Packets Received at CPU per Input Interface Interface Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Gi4/47 23130 5 10 50 20 Gi4/48 50 1 0 0 0
Nota: La utilización de la CPU cuando usted publica un comando debug es siempre el casi 100%. Es normal tener CPU elevada utilización cuando usted publica un comando debug.
Resumen
Los Catalyst 4500 Switch manejan una alta velocidad versión IP del reenvío de paquete 4 (del IPv4) en hardware. Algunas de las características o de las excepciones pueden causar el delantero de algunos paquetes vía proceso de la CPU la trayectoria. El Catalyst 4500 utiliza un mecanismo de Calidad de servicio (QoS) sofisticado para manejar los paquetes del CPU-límite. Este mecanismo asegura la confiabilidad y la estabilidad del Switches y, al mismo tiempo, maximiza el CPU para el reenvío de paquetes del software. El Cisco IOS Software Release 12.2(25)EWA2 y Posterior proporciona las optimizaciones para paquetes adicionales/proceso que dirige así como que considera. El Catalyst 4500 también tiene los suficientes comandos y herramientas potentes de ayudar en la identificación de la causa raíz de los altos escenarios de la Utilización de la CPU. Pero, en la mayoría de los casos, CPU elevada la utilización en el Catalyst 4500 no es una causa de la inestabilidad de la red ni de una tema de inquietud.
Información Relacionada
ComentariosDéjenos ayudarlo
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)