Uso elevado de la CPU del switch Catalyst 6500/6000
Contenido
Introducción
Este documento describe las causas de la elevada utilización de la CPU en los switches Cisco Catalyst 6500/6000 Series y los sistemas basados en Virtual Switching System (VSS) 1440. Al igual que en los routers Cisco, los switches utilizan el comando show processes cpu a fin de mostrar el uso de la CPU para el procesador de Supervisor Engine del switch. Sin embargo, debido a las diferencias en arquitectura y mecanismos de reenvío entre los routers Cisco y los switches, la salida típica del comando show processes cpu difiere significativamente. El significado de la salida también difiere. Este documento aclara estas diferencias y describe el uso de la CPU en los switches y cómo interpretar el resultado del comando show processes cpu.
Nota:En este documento, las palabras "switch" y "switches" hacen referencia a los Switches Catalyst 6500/6000.
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Componentes Utilizados
La información de este documento se basa en las versiones de software y hardware para los switches Catalyst 6500/6000 y los sistemas basados en Virtual Switching System (VSS) 1440.
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). If your network is live, make sure that you understand the potential impact of any command.
Nota: El software compatible con los sistemas basados en Virtual Switching System (VSS) 1440 es Cisco IOS® Software Release 12.2(33)SXH1 o posterior.
Convenciones
Diferencia entre el software de sistema CatOS y Cisco IOS
Catalyst OS (CatOS) en el Supervisor Engine y Cisco IOS® Software en la Multilayer Switch Feature Card (MSFC) (Híbrido): Puede utilizar una imagen de CatOS como software de sistema para ejecutar el Supervisor Engine en switches Catalyst 6500/6000. Si está instalado el MSFC opcional, se utiliza una imagen de software IOS de Cisco separada para ejecutar el MSFC.
Cisco IOS Software en Supervisor Engine y en MSFC (Nativo): Puede utilizar una única imagen del software Cisco IOS como software de sistema para ejecutar tanto el Supervisor Engine como la MSFC en switches Catalyst 6500/6000.
Nota:Consulte la página Comparación de los Sistemas Operativos Cisco Catalyst y Cisco IOS para Cisco Catalyst 6500 Series Switch si necesita más información.
Introducción al Uso de CPU en Switches Catalyst 6500/6000
Los routers basados en software Cisco utilizan software a fin de procesar y direccionar paquetes. El uso de CPU en un router Cisco tiende a incrementarse a medida que el router ejecuta más tareas de procesamiento y ruteo de paquetes. Por lo tanto, el comando show processes cpu puede proveer una indicación bastante precisa de la carga de procesamiento de tráfico en el router.
Los Switches Catalyst 6500/6000 no utilizan la CPU de la misma manera. Estos switches toman decisiones de reenvío en el hardware, no en el software. Por lo tanto, cuando los switches efectúan el reenvío o toman decisiones de conmutación para la mayoría de las tramas que pasan a través del switch, el proceso no involucra a la CPU del Supervisor Engine.
Los Switches Catalyst 6500/6000 poseen dos CPU. Una CPU es la CPU del Supervisor Engine, que se denomina Network Management Processor (NMP) o Switch Processor (SP). La otra CPU es la CPU del motor de ruteo de Capa 3, denominada MSFC o Route Processor (RP).
La CPU del SP realiza funciones entre las que se encuentran:
-
Colaborar en el aprendizaje y desactualización de direcciones MAC
Nota:Al aprendizaje de direcciones MAC también se lo denomina configuración de trayecto.
-
Ejecuta protocolos y procesos que proporcionan control de la red
Algunos ejemplos son: Spanning Tree Protocol (STP), Cisco Discovery Protocol (CDP), VLAN Trunk Protocol (VTP), Dynamic Trunking Protocol (DTP) y Port Aggregation Protocol (PAgP).
-
Maneja el tráfico de administración de la red que se destina a la CPU del switch
Algunos ejemplos son: tráfico Telnet, HTTP y Simple Network Management Protocol (SNMP).
La CPU del RP realiza funciones entre las que se encuentran:
-
Crea y actualiza las tablas de ruteo de Capa 3 y del Address Resolution Protocol (ARP)
-
Genera tablas de Cisco Express Forwarding (CEF), Forwarding Information Base (FIB) y de adyacencia; además, descarga las tablas en la Policy Feature Card (PFC)
-
Maneja el tráfico de administración de red con destino al RP
Algunos ejemplos incluyen: tráfico Telnet, HTTP y SNMP.
Situaciones y Funciones que Hacen que el Tráfico Pase por Software
Paquetes Destinados al Switch
Cualquier paquete que tiene como destino el switch pasa por software. Tales paquetes incluyen:
-
Paquetes de control
Los paquetes de control son recibidos por STP, CDP, VTP, Hot Standby Router Protocol (HSRP), PAgP, Link Aggregation Control Protocol (LACP) y UniDirectional Link Detection (UDLD).
-
Actualizaciones de Routing Protocol
Algunos ejemplos de estos protocolos son: Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), Border Gateway Protocol (BGP) y Open Shortest Path First Protocol (Protocolo OSPF).
-
Tráfico SNMP que tiene como destino el switch
-
Tráfico Telnet y Secure Shell Protocol (SSH) al switch.
La alta utilización de la CPU debido a SSH se ve como:
00:30:50.793 SGT Tue Mar 20 2012 CPU utilization for five seconds: 83%/11%; one minute: 15%; five minutes: 8% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 3 6468 8568 754 69.30% 7.90% 1.68% 1 SSH Process
Incluya estos comandos en el script EEM para verificar el número de sesiones SSH establecidas cuando la CPU aumenta:
-
Respuestas ARP a solicitudes ARP
Paquetes y Condiciones que Requieren Procesamiento Especial
Esta lista proporciona condiciones y tipos de paquetes específicos que obligan a que los paquetes se manejen en el software:
-
Paquetes con opciones IP, un Time to Live (TTL) vencido, o encapsulación que no sea del tipo Advanced Research Projects Agency (ARPA)
-
Paquetes con un manejo especial, como el de tunelización
-
Fragmentación de IP
-
Paquetes que requieren mensajes del tipo Internet Control Message Protocol (ICMP) provenientes de RP o de SP
-
Error de comprobación de la unidad de transmisión máxima (MTU)
-
Paquetes con errores IP, que incluyen errores de longitud y de comprobación de suma IP
-
Si los paquetes de entrada devuelven un error de bit (como el error de bit único (SBE)), los paquetes se envían a la CPU para el procesamiento del software y se corrigen. El sistema asigna un búfer para ellos y utiliza el recurso CPU para corregirlo.
-
Cuando PBR y la lista de acceso reflexiva se encuentran en la trayectoria de un flujo de tráfico, el paquete es conmutado por software, lo que requiere un ciclo de CPU adicional.
-
Misma interfaz de adyacencia
-
Paquetes que fracasan en la comprobación del Reverse Path Forwarding (RPF): rpf-failure
-
Recopilar/recibir (Glean/receive)
"Glean" hace referencia a paquetes que requieren resolución ARP y "receive" a paquetes que llegan a la caja de recepción.
-
Tráfico del tipo Internetwork Packet Exchange (IPX) que es conmutado por software en el Supervisor Engine 720, tanto en el Software Cisco IOS como en CatOS
Tráfico IPX que también se conmute por software en el Supervisor Engine 2/Software Cisco IOS; pero el tráfico se conmuta por hardware en el Supervisor Engine 2/CatOS. Tráfico IPX que se conmuta por hardware en el Supervisor Engine 1A para ambos sistemas operativos.
-
Tráfico AppleTalk
-
Condiciones completas de recursos de hardware
Entre estos recursos podemos mencionar: FIB, memoria con direccionamiento por contenido (CAM) y CAM ternaria (TCAM).
Funciones Basadas en ACL
-
Tráfico rechazado por una ACL (lista de control de acceso) con la función direcciones inalcanzables ICMP activada
Nota: Éste es el valor predeterminado.
Algunos paquetes rechazados por ACL se filtran a la MSFC si se habilita la función de direcciones IP inalcanzables. Los paquetes que requieran direcciones inalcanzables de ICMP se filtran a una velocidad que puede configurar el usuario. De forma predeterminada, la velocidad es de 500 paquetes por segundo (pps).
-
Filtrado IPX en base a parámetros no compatibles, como host de origen
En el Supervisor Engine 720, el proceso del tráfico IPX de Capa 3 IPX siempre se efectúa en el software.
-
Access Control Entries (ACE) que requieran registro, con la palabra clave log
Esto se aplica a las funciones de registro de ACL y VLAN ACL (VACL). ACE en la misma ACL que no requieran registro y que aún se encuentren en proceso en el hardware. El Supervisor Engine 720 con PFC3 es compatible con el límite de velocidad de paquetes que se redireccionan a la MSFC para registro ACL y VACL. El Supervisor Engine 2 con PFC3 es compatible con el límite de velocidad de paquetes que se redireccionan a la MSFC para registro ACL y VACL. La compatibilidad para registro de ACL en el Supervisor Engine 2 está programada para la rama de la versión 12.2S del Cisco IOS Software.
-
Tráfico con ruteo por políticas, con el uso de los parámetros match length, set ip precedence u otros parámetros no compatibles
El parámetro set interface cuenta con soporte en software. Sin embargo, el parámetro set interface null 0 es una excepción. El tráfico es manejado en el Supervisor Engine 2 con PFC2 y el Supervisor Engine 720 con PFC3.
-
ACL de routers que no sean IP ni IPX (RACL)
Las RACL no IP se aplican a todos los Supervisor Engines. Las RACL no IPX se aplican al Supervisor Engine 1a con PFC y al Supervisor Engine 2 con PFC2 exclusivamente.
-
Tráfico de broadcast que sea rechazado en una RACL
-
Tráfico que sea rechazado en una comprobación unicast RPF (uRPF), ACE de ACL
Esta comprobación uRPF se aplica al Supervisor Engine 2 con PFC2 y al Supervisor Engine 720 con PFC3.
-
Proxy de Autenticación
La velocidad de un tráfico sujeto a un proxy de autenticación se puede limitar en el Supervisor Engine 720.
-
Seguridad IP (IPsec) del Cisco IOS Software
La velocidad de un tráfico sujeto a cifrado Cisco IOS se puede limitar en el Supervisor Engine 720.
Funciones Basadas en NetFlow
Las funciones basadas en NetFlow que se describen en esta sección se aplican al Supervisor Engine 2 y al Supervisor Engine 720 exclusivamente.
-
Las funciones basadas en NetFlow siempre necesitan ver el primer paquete de un flujo en software. Una vez que el primer paquete del flujo llega al software, los paquetes subsiguientes del mismo flujo se conmutan por hardware.
Esta disposición de flujo se aplica a ACL reflexivas, Web Cache Communication Protocol (WCCP) y a Cisco IOS Server Load Balancing (SLB).
Nota:En el Supervisor Engine 1, las ACL reflexivas dependen de las entradas TCAM dinámicas para crear accesos directos de hardware para un flujo en particular. El principio es el mismo: el primer paquete de un flujo pasa al software. Los paquetes subsiguientes de ese flujo se conmutan por hardware.
-
Con la función TCP Intercept, el contacto triple y el cierre de sesión se manejan por software. El resto del tráfico se maneja por hardware.
Nota:Los paquetes Synchronize (SYN), SYN acknowledge (SYN ACK) y ACK son los componentes del contacto triple. El cierre de sesión se materializa con finish (FIN) o reset (RST).
-
En el caso de Network Address Translation (NAT), el tráfico se maneja de esta forma:
-
En Supervisor Engine 720:
El tráfico que requiere NAT se maneja por hardware después de la traducción inicial. La traducción del primer paquete de un flujo se ejecuta por software y los paquetes subsiguientes de ese flujo se conmutan por hardware. En el caso de paquetes TCP, se crea un acceso directo de hardware en la tabla NetFlow una vez finalizado el contacto trile TCP.
-
En Supervisor Engine 2 y Supervisor Engine 1:
Todo el tráfico que requiera NAT se conmuta por software.
-
-
Context-based Access Control (CBAC) utiliza accesos directos NetFlow para clasificar el tráfico que requiera inspección. Posteriormente, CBAC envía sólo este tráfico a software. CBAC es una función solo de software; el tráfico que está sujeto a inspección no es conmutado por hardware.
Nota:La velocidad del tráfico sujeto a inspección se puede limitar en el Supervisor Engine 720.
Tráfico Multicast
-
Indagación del tipo Protocol Independent Multicast (PIM)
-
Indagación del tipo Internet Group Management Protocol (IGMP) (TTL = 1)
De hecho, este tráfico tiene al router como destino.
-
Indagación del tipo Multicast Listener Discovery (MLD) (TTL = 1)
De hecho, este tráfico tiene al router como destino.
-
Omisión FIB
-
Paquetes multicast para registro que tengan conexión directa con la fuente multicast
Estos paquetes multicast se tunelizan al punto de encuentro.
-
Multicast IP Version 6 (IPv6)
Otras funciones
-
Reconocimiento de aplicaciones basadas en red (NBAR)
-
Inspección ARP, sólo con CatOS
-
Seguridad de Puertos, sólo con CatOS
-
Snooping DHCP
Situaciones IPv6
-
Paquetes con encabezado de opción hop-by-hop (salto por salto)
-
Paquetes con la misma dirección IPv6 destino que la de los routers
-
Paquetes que no superan la comprobación de imposición de alcance
-
Paquetes que exceden la MTU del enlace de salida
-
Paquetes con un valor TTL menor o igual a 1
-
Paquetes con un valor VLAN de entrada igual al de VLAN de salida
-
IPv6 uRPF
El software ejecuta esta uRPF para todos los paquetes.
-
ACL reflexivas IPv6
El software administra estas ACL reflexivas.
-
Prefijos 6to4 para túneles IPv6 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
El software administra esta tunelización. Cualquier otro tráfico que ingrese a un túnel ISATAP se conmuta por hardware.
Módulo DFC y programable LCP
En una Distributed Forwarding Card (DFC), el proceso lcp schedular que se ejecuta con un uso excesivo de CPU no representa un problema para el funcionamiento. El planificador LCP forma parte del código de firmware. En todos los módulos que no requieren un DFC, el firmware se ejecuta en un procesador específico denominado procesador de tarjeta de línea (LCP). Este procesador se utiliza para programar el hardware ASIC y para comunicarse con el módulo supervisor central.
Cuando se inicia lcp schedular, hace uso de todo el tiempo de proceso disponible. Sin embargo, cuando un nuevo proceso necesita tiempo del procesador, lcp schedular libera tiempo de proceso para el nuevo proceso. No se registra impacto alguno sobre el rendimiento del sistema en relación con este uso excesivo de la CPU. EL proceso simplemente se adueña de todos los ciclos de CPU no utilizados, siempre que ningún otro proceso de mayor prioridad los necesite.
DFC#show process cpu PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 22 0 1 0 0.00% 0.00% 0.00% 0 SCP ChilisLC Lis 23 0 1 0 0.00% 0.00% 0.00% 0 IPC RTTYC Messag 24 0 9 0 0.00% 0.00% 0.00% 0 ICC Slave LC Req 25 0 1 0 0.00% 0.00% 0.00% 0 ICC Async mcast 26 0 2 0 0.00% 0.00% 0.00% 0 RPC Sync 27 0 1 0 0.00% 0.00% 0.00% 0 RPC rpc-master 28 0 1 0 0.00% 0.00% 0.00% 0 Net Input 29 0 2 0 0.00% 0.00% 0.00% 0 Protocol Filteri 30 8 105 76 0.00% 0.00% 0.00% 0 Remote Console P 31 40 1530 26 0.00% 0.00% 0.00% 0 L2 Control Task 32 72 986 73 0.00% 0.02% 0.00% 0 L2 Aging Task 33 4 21 190 0.00% 0.00% 0.00% 0 L3 Control Task 34 12 652 18 0.00% 0.00% 0.00% 0 FIB Control Task 35 9148 165 55442 1.22% 1.22% 1.15% 0 Statistics Task 36 4 413 9 0.00% 0.00% 0.00% 0 PFIB Table Manag 37 655016 64690036 10 75.33% 77.87% 71.10% 0 lcp schedular 38 0 762 0 0.00% 0.00% 0.00% 0 Constellation SP
Causas Frecuentes y Soluciones para Problemas de Uso Excesivo de CPU
IP inalcanzables
Cuando un grupo de acceso rechaza un paquete, la MSFC envía mensajes de ICMP inalcanzable. Esta acción sucede de forma predeterminada.
Debido a la habilitación predeterminada del comando ip unreachables, el Supervisor Engine descarta la mayoría de los paquetes rechazados en hardware. Posteriormente, el Supervisor Engine envía sólo una cantidad reducida de paquetes, con un máximo de 10 pps, a la MSFC para que los descarte. Esta acción genera mensajes de dirección ICMP inalcanzable.
El descarte de paquetes rechazados y la generación de mensajes de ICMP inalcanzable imponen una carga sobre la CPU de la MSFC. A fin de eliminar la carga, puede ejecutar el comando de configuración de interfaz no ip unreachables. Este comando deshabilita los mensajes de ICMP inalcanzable, permitiendo así descartar todos los paquetes rechazados por grupos de acceso en hardware.
Los mensajes de ICMP inalcanzable no se envían en caso de que una VACL rechace un paquete.
Traducciones NAT
NAT utiliza reenvío de hardware y software. El establecimiento inicial de las traducciones NAT se debe realizar en el software y el reenvío adicional se realiza con el hardware. NAT también utiliza la tabla Netflow (128 KB como máximo). Por lo tanto, si la tabla Netflow está llena, el switch también comenzará a aplicar el reenvío NAT a través del software. Esto sucede normalmente con ráfagas de tráfico altas y causará un aumento en la CPU de 6500.
Uso del Espacio de Tabla CEF FIB en la Tabla de Caché de Flujo
El Supervisor Engine 1 incluye una Tabla de Caché de Flujo que admite 128,000 entradas. Sin embargo, sobre la base de la eficiencia del algoritmo de hash, estas entradas oscilan entre 32,000 y 120,000. En el Supervisor Engine 2, la tabla FIB se genera y programa en la PFC. La tabla puede albergar hasta 256,000 entradas. El Supervisor Engine 720 con PFC3-BXL admite un máximo de 1,000,000 entradas. Una vez que se excedió el espacio, los paquetes comienzan a conmutarse por software. Esto puede generar un uso excesivo de CPU en el RP. Si desea comprobar la cantidad de rutas en la tabla CEF FIB, emplee estos comandos:
Router#show processes cpu
CPU utilization for five seconds: 99.26%
one minute: 100.00%
five minutes: 100.00%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
--- ----------- ---------- -------- ------- ------- ------- --- ---------------
1 0 0 0 0.74% 0.00% 0.00% -2 Kernel and Idle
2 2 245 1000 0.00% 0.00% 0.00% -2 Flash MIB Updat
3 0 1 0 0.00% 0.00% 0.00% -2 L2L3IntHdlr
4 0 1 0 0.00% 0.00% 0.00% -2 L2L3PatchRev
5 653 11737 1000 0.00% 0.00% 0.00% -2 SynDi
!--- Output is suppressed.
26 10576 615970 1000 0.00% 0.00% 0.00% 0 L3Aging
27 47432 51696 8000 0.02% 0.00% 0.00% 0 NetFlow
28 6758259 1060831 501000 96.62% 96.00% 96.00% 0 Fib
29 0 1 0 0.00% 0.00% 0.00% -2 Fib_bg_task
!--- Output is suppressed.
CATOS% show mls cef
Total L3 packets switched: 124893998234
Total L3 octets switched: 53019378962495
Total route entries: 112579
IP route entries: 112578
IPX route entries: 1
IPM route entries: 0
IP load sharing entries: 295
IPX load sharing entries: 0
Forwarding entries: 112521
Bridge entries: 56
Drop entries: 2
IOS% show ip cef summary
IP Distributed CEF with switching (Table Version 86771423), flags=0x0
112564 routes, 1 reresolve, 0 unresolved (0 old, 0 new)
112567 leaves, 6888 nodes, 21156688 bytes, 86771426
inserts, 86658859
invalidations
295 load sharing elements, 96760 bytes, 112359 references
universal per-destination load sharing algorithm, id 8ADDA64A
2 CEF resets, 2306608 revisions of existing leaves
refcounts: 1981829 leaf, 1763584 node
!--- You see these messages if the TCAM space is exceeded:
%MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched
%MLSCEF-SP-7-END_FIB_EXCEPTION: FIB TCAM exception cleared, all CEF entries will be
hardware switched
En el Supervisor Engine 2, la cantidad de entradas FIB se reduce a la mitad en caso de que haya configurado la comprobación RPF en las interfaces. La configuración puede derivar en la conmutación por software de más paquetes y, en consecuencia, a un uso excesivo de CPU.
Para resolver el problema de uso elevado de la CPU, habilite el resumen de ruta. El resumen de ruta puede minimizar la latencia en una red compleja al reducir las cargas de trabajo de los procesadores, los requisitos de memoria y la demanda de ancho de banda.
Consulte Introducción a la ACL en los Catalyst 6500 Series Switches si necesita más información sobre el uso y optimización de TCAM.
Registro de ACL Optimizado
El Registro de ACL Optimizado (Optimized ACL Logging, OAL) proporciona soporte de hardware para el registro de ACL. A menos que configure OAL, el proceso de los paquetes que requieren registro se realiza completamente en el software de la MSFC3. OAL permite o descarta paquetes en el hardware de la PFC3. OAL utiliza una rutina optimizada para enviar información a la MSFC3 a fin de generar los mensajes de registro.
Nota:Si necesita información sobre OAL, consulte la sección Registro de ACL Optimizado con una PFC3 de Introducción al Soporte de Cisco IOS para ACL.
Límite de Velocidad de Paquetes a la CPU
En el Supervisor Engine 720, los limitadores de velocidad pueden controlar la velocidad con la que los paquetes pueden pasar al software. Este control de velocidad evita ataques de negación de servicio. También puede utilizar algunos de estos limitadores de velocidad en el Supervisor Engine 2:
Router#show mls rate-limit
Rate Limiter Type Status Packets/s Burst
--------------------- ---------- --------- -----
MCAST NON RPF Off - -
MCAST DFLT ADJ On 100000 100
MCAST DIRECT CON Off - -
ACL BRIDGED IN Off - -
ACL BRIDGED OUT Off - -
IP FEATURES Off - -
ACL VACL LOG On 2000 1
CEF RECEIVE Off - -
CEF GLEAN Off - -
MCAST PARTIAL SC On 100000 100
IP RPF FAILURE On 500 10
TTL FAILURE Off - -
ICMP UNREAC. NO-ROUTE On 500 10
ICMP UNREAC. ACL-DROP On 500 10
ICMP REDIRECT Off - -
MTU FAILURE Off - -
LAYER_2 PDU Off - -
LAYER_2 PT Off - -
IP ERRORS On 500 10
CAPTURE PKT Off - -
MCAST IGMP Off - -
Router(config)#mls rate-limit ?
all Rate Limiting for both Unicast and Multicast packets
layer2 layer2 protocol cases
multicast Rate limiting for Multicast packets
unicast Rate limiting for Unicast packets
Aquí tiene un ejemplo:
Router(config)#mls rate-limit layer2 l2pt 3000
Si desea limitar la velocidad de todos los paquetes impulsados por CEF a la MSFC, ejecute el comando que figura en este ejemplo:
Router(config)#mls ip cef rate-limit 50000
Si desea reducir la cantidad de paquetes impulsados a la CPU debido a TTL=1, ejecute este comando:
Router(config)#mls rate-limit all ttl-failure 15
!--- where 15 is the number of packets per second with TTL=1. !--- The valid range is from 10 to 1000000 pps.
Por ejemplo, este es el resultado de la captura netdr, que muestra que el TTL IPv4 es 1:
Source mac 00.00.50.02.10.01 3644 Dest mac AC.A0.16.0A.B0.C0 4092 Protocol 0800 4094 Interface Gi1/8 3644 Source vlan 0x3FD(1021) 3644 Source index 0x7(7) 3644 Dest index 0x380(896) 3654 L3 ipv4 source 211.204.66.117 762 ipv4 dest 223.175.252.49 3815 ipv4 ttl 1 3656 ipv6 source - 0 ipv6 dest - 0 ipv6 hoplt - 0 ipv6 flow - 0 ipv6 nexthdr - 0
El uso excesivo de CPU también puede deberse a paquetes con TTL = 1 que se filtran a la CPU. Si desea limitar la cantidad de paquetes que se filtran a la CPU, configure un limitador de velocidad por hardware. Los limitadores de velocidad pueden limitar la velocidad de los paquetes que se filtran desde la trayectoria de datos en hardware a la trayectoria de datos en software. Los limitadores de velocidad protegen la trayectoria de control de la congestión al descartar el tráfico que exceda la velocidad configurada. El límite de velocidad se configura con el comando mls rate-limit all ttl-failure.
Fusión Física de VLAN Debido a Cableado Incorrecto
El uso excesivo de CPU también puede ser el resultado de que se fusionen dos o más VLAN debido a cableado incorrecto. Además, si se deshabilita STP en los puertos donde se registra la fusión de las VLAN, se puede generar uso excesivo de CPU.
Para resolver este problema, identifique los errores de cableado y corríjalos. Si sus requisitos lo permiten, también puede habilitar STP en esos puertos.
Tormenta de difusión
Se registra una tormenta de broadcast LAN cuando la LAN se ve inundada por paquetes broadcast o multicast. Esta situación genera tráfico excesivo y degrada el rendimiento de la red. Cualquier error en la implementación de la pila de protocolos o en la configuración de la red puede generar una tormenta de broadcast.
Debido al diseño arquitectónico de la plataforma Catalyst serie 6500, los paquetes de difusión se descartan solo y siempre en el nivel de software.
La supresión de broadcast evita que las interfaces LAN se vean perturbadas por una tormenta de broadcast. La supresión de broadcast utiliza un filtrado que mide la actividad de broadcast en una LAN en un período de 1 segundo y compara la medición con un umbral predefinido. Si se alcanza dicho umbral, se suprime toda actividad de broadcast adicional durante un período de tiempo especificado. La supresión de broadcast está deshabilitada de manera predeterminada.
Nota: El inestabilidad de VRRP de la copia de seguridad a la maestra causada por tormentas de difusión puede provocar un uso elevado de la CPU.
Si desea comprender cómo funciona la supresión de broadcast y cómo habilitar la función, consulte:
-
Configuración de la Supresión de Broadcast (software de sistema Cisco IOS)
-
Configuración de la Supresión de Broadcast (software de sistema CatOS)
Seguimiento de la Dirección Next-Hop BGP (Proceso del Escáner BGP)
El proceso del Escáner BGP recorre la tabla BGP y confirma si se pueden alcanzar los próximos saltos. El proceso también verifica el anuncio condicional para poder determinar si BGP debería anunciar prefijos de condición y/o ejecutar amortiguación de rutas. De forma predeterminada, el proceso escanea cada 60 segundos.
Puede esperar que se registre un uso excesivo de CPU durante breves períodos de tiempo debido al proceso del Escáner BGP en un router que transmite una tabla de ruteo de Internet de magnitudes considerables. Una vez por minuto, el Escáner BGP recorre la tabla BGP Routing Information Base (RIB) y ejecuta importantes tareas de mantenimiento. Entre estas tareas se incluyen:
-
Comprobación del siguiente salto al que se hace referencia en la tala BGP del router
-
Verificación de que se pueden alcanzar los dispositivos next-hop
De este modo, una tabla BGP grande requiere una cantidad de tiempo equivalente para ser transitada y validada. El proceso del Escáner BGP recorre la tabla BGP para poder actualizar cualquier estructura de datos y recorre la tabla de ruteo con fines de redistribución de rutas. Ambas tablas se almacenan separadamente en la memoria del router. Las dos tablas pueden ser muy grandes y, en consecuencia, consumir ciclos de CPU.
Si necesita más información sobre uso de CPU por parte del proceso del Escáner BGP, consulte la sección Uso Excesivo de CPU Debido a BGP Scanner de Resolución de Problemas de Uso Excesivo de CPU Causados por el Proceso del Escáner BGP o del Router BGP.
Si necesita más información sobre la función de Seguimiento de Dirección Next-Hop BGP (BGP Next-Hop Address Tracking) y el procedimiento para habilitar/deshabilitar o ajustar el intervalo de la exploración del Escáner, consulte Compatibildad BGP para el Seguimiento de Dirección Next-Hop.
Tráfico Multicast No RPF
El ruteo multicast (a diferencia del unicast) sólo se preocupa por el origen de un determinado flujo de datos multicast. Esto es, la dirección IP del dispositivo que origina el tráfico multicast. El principio básico es que el dispositivo origen "empuja" el flujo hacia una cantidad indefinida de receptores (dentro de su grupo multicast). Todos los routers crean árboles de distribución, que controlan la trayectoria que adopta el tráfico multicast a través de la red para poder distribuir el tráfico a todos los receptores. Los dos tipos básicos de árboles de distribución multicast son los árboles de origen y los árboles compartidos. RPF es un concepto clave en el reenvío multicast. Permite que los routers reenvíen el tráfico multicast correctamente a través del árbol de distribución. RPF hace uso de la tabla de ruteo unicast existente para determinar los vecinos de flujo ascendente y descendente. Un router reenvía un paquete multicast sólo si es recibido en la interfaz de flujo ascendente. Esta comprobación RPF ayuda a garantizar que el árbol de distribución se encuentre libre de loops.
El tráfico multicast es siempre visible para cualquier router en una LAN puenteada (Capa 2), según la especificación IEEE 802.3 CSMA/CD. En la 802.3 estándar, el bit 0 del primer octeto se utiliza para indicar una trama de broadcast y/o multicast, y se satura cualquier trama de Capa 2 con esta dirección. Esto también ocurre en caso de haberse configurado las indagaciones CGMP o IGMP. Esto se debe a que los routers multicast deben ver el tráfico multicast para poder tomar una decisión de reenvío correcta. Si varios routers multicast poseen interfaces sobre una LAN común, entonces sólo uno reenviará los datos (se lo elige mediante un proceso de selección). Debido a la naturaleza de la saturación de las LAN, el router redundante (el router que no reenvía el tráfico multicast) recibe estos datos en la interfaz de salida para esa LAN. Normalmente, el router redundante descarta este tráfico dado que llegó a la interfaz incorrecta y, en consecuencia, no logra pasar la comprobación RPF. Este tráfico que no logra superar la comprobación RPF se denomina tráfico no RPF o paquetes de error RPF, debido a que fueron transmitidos hacia atrás, en contra del flujo proveniente del origen.
El Catalyst 6500 con una MSFC instalada se puede configurar para funcionar como un router multicast con máximas capacidades. Si se utiliza Multicast Multi-Layer Switching (MMLS), el tráfico suele ser reenviado por el hardware que se encuentra dentro del switch. A los ASIC se les brinda información desde el estado de ruteo multicast (por ejemplo: [*,G] y [S,G]) de modo que se pueda programar un acceso directo de hardware en la tabla Netflow y/o FIB. Este tráfico no RPF todavía es necesario en algunos casos y la CPU de la MSFC requiere de él (en el nivel de proceso) para el mecanismo PIM Assert. De lo contrario, será descartado por la trayectoria de conmutación rápida del software (asumiendo que la conmutación rápida por software no esté deshabilitada en la interfaz RPF).
El Catalyst 6500 que utiliza redundancia no podría manejar eficazmente el tráfico no RPF en ciertas topologías. Por lo general, para este tráfico no RPF, no hay un estado (*,G) o (S,G) en el router redundante y, por lo tanto, no se pueden crear accesos directos de hardware o de software para descartar el paquete. Cada paquete multicast debe ser examinado por el procesador de rutas de la MSFC individualmente; esto se conoce frecuentemente como tráfico de interrupción de CPU (CPU Interrupt). En el caso de conmutación por hardware de Capa 3 y de que existan varias interfaces/redes VLAN conectadas al mismo conjunto de routers, el tráfico no RPF que llega a la CPU de la MSFC redundante ve amplificada su velocidad de origen inicial "N" veces (donde "N" es la cantidad de redes LAN a las que el router está conectado en forma redundante). Si la velocidad del tráfico no RPF excede la capacidad de descarte de paquetes del sistema, se podría generar un uso excesivo de la CPU, desbordamientos de buffer e inestabilidad general en la red.
En el caso del Catalyst 6500, se dispone de un motor de listas de acceso que posibilita que el filtrado se lleve a cabo a la velocidad permitida por el cable. Esta función puede usarse en ciertas situaciones para manejar tráfico no RPF de manera eficiente para los grupos del modo disperso (Sparse Mode). Sólo podrá utilizar el método basado en listas ACL dentro de 'redes stub' del modo disperso, donde no existen routers multicast de flujo descendente (ni sus receptores correspondientes). Además, debido al diseño de reenvío de paquetes de Catalyst 6500, las MSFC redundantes internamente no pueden utilizar esta implementación. Esto se describe en líneas generales en el Id. de error de Cisco CSCdr74908 (sólo para clientes registrados). En grupos que se encuentran en modo denso, se deben ver los paquetes no RPF en el router para que el mecanismo PIM Assert funcione correctamente. Diferentes soluciones, como la limitación de velocidad y QoS basadas en CEF o Netflow, se utilizan para controlar fallas RPF en redes que se encuentren en modo denso y redes de tránsito en modo disperso.
En el caso de Catalyst 6500, se dispone de un motor de listas de acceso que permite que el filtrado se lleve a cabo a la velocidad permitida por el cable. Puede usarse esta función para manejar el tráfico que no es RPF de manera eficiente para los grupos en modo disperso. Con el objetivo de implementar esta solución, ubique una lista de acceso en la interfaz de entrada de la 'red stub' para filtrar el tráfico multicast que no se originó en la 'red stub'. La lista de acceso se descarga al hardware del switch. Esta lista de acceso impide que la CPU vea el paquete y permite que el hardware descarte el tráfico no RPF.
Nota:No ubique esta lista de acceso en una interfaz de tránsito. Está destinada exclusivamente para redes stub (redes con hosts únicamente).
Si desea más información, consulte estos documentos:
Comandos show
El nivel de utilización de CPU cuando se ejecuta un comando show siempre es muy cercano al 100%. Es normal que el uso de CPU sea excesivo cuando se ejecuta un comando show, dicho nivel de uso de CPU normalmente se sostiene sólo durante algunos segundos.
Por ejemplo: es normal que el proceso Virtual Exec se eleve cuando se ejecuta un comando show tech-support ya que esta salida es una salida impulsada por interrupciones. Su única preocupación deberá ser el uso de CPU excesivo en procesos que no sean comandos show.
El comando show cef not-cef-switched muestra por qué los paquetes se envían a la MSFC (recepción, opción ip, sin adyacencia, etc.) y cuántos. Por ejemplo:
Switch#show cef not-cef-switched CEF Packets passed on to next switching layer Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access Frag RP 6222 0 136 0 60122 0 0 0 5 0 0 0 0 0 0 0 0 IPv6 CEF Packets passed on to next switching layer Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access MTU RP 0 0 0 0 0 0 0 0
Los comandos show ibc y show ibc brief muestran la cola de la CPU y se pueden utilizar cuando se monitorea el estado de la CPU.
Procesos Exec
El proceso Exec en Cisco IOS Software es responsable de la comunicación con las líneas TTY (consola, auxiliar, asincrónica) del router. El proceso Virtual Exec (Ejecución virtual) es responsable de las líneas vty (sesiones telnet). Los procesos Exec y Virtual Exec son procesos de prioridad media por lo que, de existir otros procesos con prioridad más alta (Elevada o Crítica), son estos últimos procesos los que consumirán los recursos de la CPU.
En caso de que se transfieran muchos datos a través de estas sesiones, el nivel de utilización de CPU para el proceso Exec se incrementa. Esto se debe a que, cuando el router desea enviar un carácter simple a través de estas líneas, utiliza algunos recursos de la CPU:
-
En el caso de la consola (Exec), el router emplea un interruptor por caracter.
-
En el caso de la línea VTY (Virtual Exec), la sesión Telnet debe generar un paquete TCP por carácter.
En esta lista se detallan algunos de los posibles motivos para que se registre uso excesivo de CPU en el proceso Exec:
-
Se envían demasiados datos a través del puerto de la consola.
-
Compruebe si se ha iniciado algún debug en el router con el comando show debugging.
-
Deshabilite el registro de la consola en el router con la forma no del comando logging console.
-
Verifique si se imprime una salida extensa en la consola. Por ejemplo: un comando show tech-support o uno show memory.
-
-
El comando exec se configura para las líneas asincrónicas y auxiliares.
-
Si por una línea sólo circula tráfico saliente, deshabilite el proceso Exec para esta línea. Debe hacerlo porque, si el dispositivo (por ejemplo, un módem) adjunto a esta línea, envía algunos datos no solicitados, el proceso Exec comenzará en esta línea.
-
Si se utiliza el router como un servidor terminal (para Telnet inversa u otras consolas de dispositivos), le recomendamos que configure el comando no exec en las líneas que están conectadas a la consola de los otros dispositivos. De lo contrario, los datos que regresan de la consola podrían dar inicio a un proceso Exec, proceso que utiliza recursos de la CPU.
-
Un posible motivo para que se registre un uso excesivo de CPU en el proceso Virtual Exec es el siguiente:
-
Se envían demasiados datos a través de las sesiones Telnet.
El motivo más habitual por el que se registra un uso excesivo de CPU en el proceso Virtual Exec es que se transfieren demasiados datos desde el router a la sesión Telnet. Esto puede darse cuando se ejecutan comandos con salidas extensas como show tech-support, show memory, entre otros, desde la sesión Telnet. La cantidad de datos transferidos a través de cada sesión VTY se puede verificar con el comando show tcp vty <line number>.
Proceso de caducidad de L3
Cuando el proceso de envejecimiento L3 exporta una gran cantidad de valores de ifindex mediante NetFlow Data Export (NDE), el uso de la CPU puede alcanzar el 100%.
Si encuentra este problema, verifique si estos dos comandos están habilitados:
set mls nde destination-ifindex enable
set mls nde source-ifindex enable
Si habilita estos comandos, el proceso debe exportar todos los valores de ifIndex de origen y destino mediante NDE. La utilización del proceso de envejecimiento L3 es alta, ya que debe realizar la búsqueda de FIB para todos los valores de ifindex de origen y destino. Debido a esto, la tabla se llena, el proceso de envejecimiento L3 aumenta y el uso de la CPU alcanza el 100%.
Para resolver este problema, inhabilite estos comandos:
set mls nde destination-ifindex disable
set mls nde source-ifindex disable
Utilice estos comandos para verificar los valores:
Tormenta BPDU
El spanning tree mantiene un entorno de Capa 2 libre de loops en redes conmutadas redundantes y puenteadas. Sin STP, las tramas se repiten y/o se multiplican indefinidamente. Esto genera un colapso de la red porque el tráfico elevado interrumpe todos los dispositivos en el dominio de broadcast.
En algunos aspectos, STP es un protocolo antiguo que se desarrolló inicialmente para especificaciones de puente con base en software (IEEE 802.1D); sin embargo, puede resultar complicado implementar exitosamente STP en redes conmutadas de magnitud que cuenten con estas características:
-
Muchas VLAN
-
Muchos switches en un dominio STP
-
Soporte de varios proveedores
-
Nuevas mejoras del IEEE
Si la red debe hacer frente a frecuentes cálculos de spanning tree o el switch debe procesar más BPDU, se puede generar un uso excesivo de CPU y, además, descartes BPDU.
Para poder solucionar estos inconvenientes, recurra a alguno o a todos estos pasos:
-
Separe las VLAN de los switches.
-
Utilice una versión mejorada de STP, como MST.
-
Actualice el hardware del switch.
Además, consulte las recomendaciones de uso para implementar el protocolo Spanning Tree Protocol en la red.
Sesiones SPAN
En base a la arquitectura de los switches Catalyst 6000/6500 Series, las sesiones SPAN no afectan el rendimiento del switch pero, si la sesión SPAN incluye un puerto de tráfico elevado/uplink o un EtherChannel, puede incrementar la carga del procesador. Si posteriormente aísla una VLAN específica, aumenta aun más la carga de trabajo. Si existe tráfico dañado en el enlace, es posible que la carga de trabajo se incremente aun más.
En algunas situaciones, la función RSPAN puede generar loops y, en consecuencia, la carga del procesador se eleva. Si necesita más información, consulte ¿Por Qué la Sesión SPAN Crea un Loop de Bridging?
El switch puede transferir tráfico en forma habitual porque todo sucede a nivel de hardware, pero es posible que la CPU sufra un nivel excesivo de utilización de recursos si intenta determinar qué tráfico debe enviarse. Le recomendamos que configure sesiones SPAN sólo cuando resulte necesario.
%CFIB-SP-STBY-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched
%CFIB-SP-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched %CFIB-SP-STBY-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched
Se recibe este mensaje de error cuando se excede la cantidad de espacio disponible en TCAM. Esto genera uso excesivo de la CPU. Se trata de una limitación FIB TCAM. Una vez que la TCAM se llena, se configurará un indicador y se recibirá una excepción FIB TCAM. De esta manera, se dejan de añadir nuevas rutas a la TCAM. En consecuencia, todo el material se conmutará por software. La eliminación de rutas no ayuda a retomar la conmutación por hardware. Una vez que la TCAM ingresa al estado de excepción, se debe volver a cargar el sistema para salir de ese estado. La cantidad máxima de rutas que se puede instalar en la TCAM se incrementa mediante el comando mls cef maximum-routes.
Catalyst 6500/6000 con CPU alta tiene una ACL IPv6 con puertos L4
Habilite mls ipv6 acl compress address unicast . Este comando es necesario si la ACL IPv6 coincide en los números de puerto del protocolo L4. Si este comando no está habilitado, el tráfico IPv6 se enviará a la CPU para el procesamiento de software. Este comando no está configurado de forma predeterminada.
SPF de cobre
En los switches Ethernet de la serie Cisco ME 6500, los SFP de cobre requieren más interacción de firmware que otros tipos de SFP, lo que aumenta la utilización de la CPU.
Los algoritmos de software que administran SFP de cobre se han mejorado en las versiones de Cisco IOS SXH.
IOS modular
En los switches Catalyst de Cisco serie 6500 que ejecutan el software IOS modular, la utilización normal de la CPU es un poco mayor que la del software IOS no modular.
El software IOS modular paga un precio por actividad más de lo que paga un precio por paquete. El software IOS modular mantiene los procesos consumiendo cierta CPU incluso si no hay muchos paquetes, por lo que el consumo de la CPU no se basa en el tráfico real. Sin embargo, cuando los paquetes se procesan a alta velocidad, la CPU consumida en el software del IOS modular no debe ser mayor que la del software del IOS no modular.
Comprobación del Uso de la CPU
Si el uso de la CPU es excesivo, ejecute el comando show processes cpu como primera medida. La salida le indicará el nivel de utilización de la CPU en el switch y, además, el consumo de recursos de la CPU por parte de cada proceso.
Router#show processes cpu CPU utilization for five seconds: 57%/48%; one minute: 56%; five minutes: 48% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 5 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 12 18062 0 0.00% 0.00% 0.00% 0 Load Meter 4 164532 13717 11994 0.00% 0.21% 0.17% 0 Check heaps 5 0 1 0 0.00% 0.00% 0.00% 0 Pool Manager !--- Output is suppressed. 172 0 9 0 0.00% 0.00% 0.00% 0 RPC aapi_rp 173 243912 2171455 112 9.25% 8.11% 7.39% 0 SNMP ENGINE 174 68 463 146 0.00% 0.00% 0.00% 0 RPC pm-mp !--- Output is suppressed.
En esta ejemplo, la utilización total de recursos de la CPU es del 57% y el uso de CPU por interrupciones es del 48%. Aquí, estos porcentajes aparecen en negrita. El switch de interrupción del tráfico por parte de la CPU causa utilización de recursos de CPU por interrupción. La salida del comando enumera los procesos que causan la diferencia entre ambas utilizaciones. En este caso, el responsable es el proceso SNMP.
En el Supervisor Engine que ejecuta CatOS, la salida tiene el siguiente aspecto:
Switch> (enable) show processes cpu
CPU utilization for five seconds: 99.72%
one minute: 100.00%
five minutes: 100.00%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
--- ----------- ---------- -------- ------- ------- ------- --- ---------------
1 0 0 0 0.28% 0.00% 0.00% -2 Kernel and Idle
2 2 261 1000 0.00% 0.00% 0.00% -2 Flash MIB Updat
3 0 1 0 0.00% 0.00% 0.00% -2 L2L3IntHdlr
4 0 1 0 0.00% 0.00% 0.00% -2 L2L3PatchRev
!--- Output is suppressed.
61 727295 172025 18000 0.82% 0.00% 0.00% -2 SptTimer
62 18185410 3712736 106000 22.22% 21.84% 21.96% -2 SptBpduRx
63 845683 91691 105000 0.92% 0.00% 0.00% -2 SptBpduTx
En esta salida, el primer proceso es Kernel and Idle, que indica la utilización ociosa de recursos de la CPU. Este proceso suele consumir muchos recursos, a menos que otros procesos consuman ciclos de la CPU. En este ejemplo, el proceso SptBpduRx genera uso excesivo de la CPU.
Si el uso de la CPU es excesivo debido a alguno de estos procesos, usted puede diagnosticar el problema y determinar por qué este proceso consume muchos recursos. Pero, si el consumo de recursos de la CPU es excesivo debido a que se impulsa tráfico a la CPU, deberá determinar el motivo de esa situación. Cuando descubra el motivo podrá identificar más fácilmente cuál es el tráfico.
Para la resolución de problemas, utilice este ejemplo de secuencia de comandos EEM para recopilar la salida del switch cuando experimente un uso elevado de la CPU:
event manager applet cpu_stats event snmp oid "1.3.6.1.4.1.9.9.109.1.1.1.1.3.1" get-type exact entry-op gt entry-val "70" exit-op lt exit-val "50" poll-interval 5 action 1.01 syslog msg "------HIGH CPU DETECTED----, CPU:$_snmp_oid_val%" action 1.02 cli command "enable" action 1.03 cli command "show clock | append disk0:cpu_stats" action 1.04 cli command "show proc cpu sort | append disk0:cpu_stats" action 1.05 cli command "Show proc cpu | exc 0.00% | append disk0:cpu_stats" action 1.06 cli command "Show proc cpu history | append disk0:cpu_stats" action 1.07 cli command "show logging | append disk0:cpu_stats " action 1.08 cli command "show spanning-tree detail | in ieee|occurr|from|is exec | append disk0:cpu_stats" action 1.09 cli command "debug netdr cap rx | append disk0:cpu_stats" action 1.10 cli command "show netdr cap | append disk0:cpu_stats" action 1.11 cli command "undebug all" !
Nota: El comando debug netdr capture rx es útil cuando la CPU es alta debido a la conmutación de procesos de paquetes en lugar de hardware. Captura 4096 paquetes entrantes a la CPU cuando se ejecuta el comando. El comando es completamente seguro y es la herramienta más conveniente para los problemas de CPU altos en el 6500. No causa carga extra a la CPU.
Utilidades y Herramientas para Determinar el Tráfico que se Impulsa a la CPU
En esta sección, se identifican algunas utilidades y herramientas que pueden ayudarlo a analizar este tráfico.
Software de sistema Cisco IOS
En Cisco IOS Software, el procesador de switch del Supervisor Engine se conoce como SP, y la MSFC se denomina RP.
El comando show interface brinda información básica acerca del estado de la interfaz y la velocidad del tráfico en la interfaz. El comando también ofrece contadores de errores.
Router#show interface gigabitethernet 4/1
GigabitEthernet4/1 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 000a.42d1.7580 (bia 000a.42d1.7580)
Internet address is 100.100.100.2/24
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 100Mb/s
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 5/75/1/24075 (size/max/drops/flushes); Total output drops: 2
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 7609000 bits/sec, 14859 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
L2 Switched: ucast: 0 pkt, 184954624 bytes - mcast: 1 pkt, 500 bytes
L3 in Switched: ucast: 2889916 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
2982871 packets input, 190904816 bytes, 0 no buffer
Received 9 broadcasts, 0 runts, 0 giants, 0 throttles
1 input errors, 1 CRC, 0 frame, 28 overrun, 0 ignored
0 input packets with dribble condition detected
1256 packets output, 124317 bytes, 0 underruns
2 output errors, 1 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
En esta salida, puede ver que el tráfico entrante se conmuta en la Capa 3 y no en la Capa 2. Esto indica que el tráfico se impulsa a la CPU.
El comando show processes cpu le indica si estos paquetes son de tráfico regular o de tráfico de control.
Router#show processes cpu | exclude 0.00 CPU utilization for five seconds: 91%/50%; one minute: 89%; five minutes: 47% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 5 881160 79142 11133 0.49% 0.19% 0.16% 0 Check heaps 98 121064 3020704 40 40.53% 38.67% 20.59% 0 IP Input 245 209336 894828 233 0.08% 0.05% 0.02% 0 IFCOM Msg Hdlr
Si los paquetes se conmutan por proceso, verá que el proceso IP Input consumirá muchos recursos. Ejecute este comando para ver estos paquetes:
show buffers input-interface
Router#show buffers input-interface gigabitethernet 4/1 packet Buffer information for Small buffer at 0x437874D4 data_area 0x8060F04, refcount 1, next 0x5006D400, flags 0x280 linktype 7 (IP), enctype 1 (ARPA), encsize 14, rxtype 1 if_input 0x505BC20C (GigabitEthernet4/1), if_output 0x0 (None) inputtime 00:00:00.000 (elapsed never) outputtime 00:00:00.000 (elapsed never), oqnumber 65535 datagramstart 0x8060F7A, datagramsize 60, maximum size 308 mac_start 0x8060F7A, addr_start 0x8060F7A, info_start 0x0 network_start 0x8060F88, transport_start 0x8060F9C, caller_pc 0x403519B4 source: 100.100.100.1, destination: 100.100.100.2, id: 0x0000, ttl: 63, TOS: 0 prot: 17, source port 63, destination port 63 08060F70: 000A 42D17580 ..BQu. 08060F80: 00000000 11110800 4500002E 00000000 ........E....... 08060F90: 3F11EAF3 64646401 64646402 003F003F ?.jsddd.ddd..?.? 08060FA0: 001A261F 00010203 04050607 08090A0B ..&............. 08060FB0: 0C0D0E0F 101164 ......d
Si el tráfico se conmuta por interrupción, no podrá ver esos paquetes con el comando show buffers input-interface. Si desea ver los paquetes impulsados a RP para que se los conmute por interrupción, puede ejecutar una captura del tipo Switched Port Analyzer (SPAN) del puerto RP.
Nota:Consulte este documento si necesita más información acerca del uso de CPU conmutado por interrupción en comparación con el uso de CPU conmutado por proceso:
SPAN RP-Inband y SP-Inband
Se dispone de un analizador SPAN para el puerto RP o SP en la versión 12.1(19)E de Cisco IOS Software y versiones posteriores.
Esta es la sintaxis del comando:
test monitor session 1-66 add {rp-inband | sp-inband} [rx | tx | both]
Utilice esta sintaxis para las versiones del software Cisco IOS 12.2 SX:
test monitor add {1..66} {rp-inband | sp-inband} {rx | tx | both}
Nota:En el caso de la versión SXH, deberá utilizar el comando monitor session para poder configurar una sesión SPAN local y, posteriormente, emplear este comando para asociar la sesión SPAN con la CPU:
source {cpu {rp | sp}} | single_interface | interface_list |
interface_range | mixed_interface_list | single_vlan |
vlan_list | vlan_range | mixed_vlan_list} [rx | tx | both]
Nota:Si necesita más información acerca de estos comandos, consulte Configuración de SPAN Local (Modo de Configuración de SPAN) en la Guía de Configuración del Software Catalyst 6500 Versión 12.2SX.
A continuación le ofrecemos un ejemplo sobre una consola RP:
Router#monitor session 1 source interface fast 3/3 !--- Use any interface that is administratively shut down. Router#monitor session 1 destination interface 3/2
Ahora, el turno de la consola SP. Aquí tiene un ejemplo:
Router-sp#test monitor session 1 add rp-inband rx
Nota: En las versiones del Cisco IOS 12.2 SX, el comando se ha cambiado a test monitor add 1 rp-inband rx.
Router#show monitor Session 1 --------- Type : Local Session Source Ports : Both : Fa3/3 Destination Ports : Fa3/2 SP console: Router-sp#test monitor session 1 show Ingress Source Ports: 3/3 15/1 Egress Source Ports: 3/3 Ingress Source Vlans: <empty> Egress Source Vlans: <empty> Filter Vlans: <empty> Destination Ports: 3/2
Nota: En las versiones del Cisco IOS 12.2 SX, el comando se ha cambiado a test monitor show 1.
A continuación le ofrecemos un ejemplo sobre una consola SP:
Router-sp#test monitor session 1 show Ingress Source Ports: 3/3 15/1 Egress Source Ports: 3/3 Ingress Source Vlans: <empty> Egress Source Vlans: <empty> Filter Vlans: <empty> Destination Ports: 3/2
Software de sistema CatOS
En el caso de switches que ejecutan el software de sistema CatOS, el Supervisor Engine ejecuta CatOS y la MSFC ejecuta Cisco IOS Software.
Si ejecuta el comando show mac, podrá ver la cantidad de tramas que se impulsan a la MSFC. El puerto 15/1 es la conexión del Supervisor Engine a la MSFC.
Nota:El puerto para Supervisor Engines en la ranura 2 es el 16/1.
Console> (enable) show mac 15/1 Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast -------- -------------------- -------------------- -------------------- 15/1 193576 0 1 Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast -------- -------------------- -------------------- -------------------- 15/1 3 0 0 Port Rcv-Octet Xmit-Octet -------- -------------------- -------------------- 15/1 18583370 0 MAC Dely-Exced MTU-Exced In-Discard Out-Discard -------- ---------- ---------- ---------- ----------- 15/1 0 - 0 0
Un incremento veloz en esta cifra indica que los paquetes son impulsados a la MSFC, lo que genera un uso excesivo de la CPU. Entonces, se puede dividir a los paquetes de esta forma:
Puerto 15/1 o 16/1 de la MSFC del Analizador SPAN
Configure una sesión SPAN en la que el origen sea el puerto 15/1 (o el 16/1) de la MSFC y el puerto de destino sea uno Ethernet.
Aquí tiene un ejemplo:
Console> (enable) set span 15/1 5/10 Console> (enable) show span Destination : Port 5/10 Admin Source : Port 15/1 Oper Source : None Direction : transmit/receive Incoming Packets: disabled Learning : enabled Multicast : enabled Filter : - Status : active
Si recoge una señal de rastreador en el puerto 5/10, le mostrará paquetes que se transmiten hacia y desde la MSFC. Configure la sesión SPAN como tx para poder capturar paquetes que estén destinados sólo a la MSFC y no que provengan de la MSFC.
SPAN sc0
Configure una sesión SPAN con la interfaz sc0 como origen para poder capturar tramas que se dirijan a la CPU del Supervisor Engine.
Console> (enable) set span ? disable Disable port monitoring sc0 Set span on interface sc0 <mod/port> Source module and port numbers <vlan> Source VLAN numbers
Nota:En el caso de Optical Services Modules (OSM), no podrá efectuar una captura SPAN de tráfico.
Recomendaciones
El uso de la CPU del Supervisor Engine no refleja el rendimiento de reenvío por hardware del switch. Pese a eso, deberá evaluar y controlar el uso de dicha CPU.
-
Evalúe el uso de la CPU del Supervisor Engine para el switch en una red estable con patrones y carga de tráfico normales.
Observe qué procesos generan el mayor uso de recursos de la CPU.
-
Cuando resuelva problemas relacionados con el uso de la CPU, tenga en cuenta estas preguntas:
-
¿Qué procesos generan el uso más elevado? ¿Difieren estos procesos de su evaluación inicial?
-
¿El uso de la CPU resulta siempre excesivo y supera la línea de base? ¿O se registran picos de uso excesivo y, posteriormente, se regresa a los niveles iniciales?
-
¿Existen notificaciones del tipo Topology Change Notifications (TCN) en la red?
Nota:Un puerto inestable o puerto host con STP PortFast deshabilitados generan notificaciones TCN.
-
¿Se registra tráfico broadcast o multicast excesivo en las subredes/VLAN de administración?
-
¿Se registra tráfico de administración excesivo, como consultas SNMP, en el switch?
-
-
Durante el tiempo de CPU elevado (cuando la CPU es del 75% o superior), recopile el resultado de estos comandos:
-
De ser posible, aísle la VLAN de administración de las VLAN con tráfico de datos de usuario, particularmente en tráfico pesado de broadcast.
Entre algunos ejemplos de este tipo de tráfico podemos mencionar: IPX RIP/Service Advertising Protocol (SAP), AppleTalk y otras clases de tráfico broadcast. Este tráfico puede afectar el uso de la CPU del Supervisor Engine y, en casos extremos, interferir con la funcionamiento normal del switch.
-
Si el consumo de recursos de la CPU es excesivo debido a que se impulsa tráfico al RP, determine cuál es el tráfico y por qué se lo impulsa.
Para poder hacerlo, emplee las utilidades que describe la sección Utilidades y Herramientas para Determinar el Tráfico que se Impulsa a la CPU.
Información Relacionada
- Comandos útiles para solucionar problemas de uso elevado de la CPU en Catalyst 6500 con Sup720
- Mensajes de Error Comunes de CatOS en Catalyst 6500/6000 Series Switches
- Mensajes de Error Comunes en Catalyst 6500/6000 Series Switches que Ejecutan Cisco IOS Software
- Solución de problemas de hardware y problemas comunes en switches Catalyst Serie 6500/6000 con software de sistema Cisco IOS
- Saturación de unidifusión en redes de oficinas centrales conmutadas
- Soporte de Productos de Cisco Catalyst 6500 Series Switches
- Script EEM para recopilar datos durante un problema de CPU alto intermitente
- Soporte de Producto de LAN
- Soporte de Tecnología de LAN Switching
- Soporte Técnico y Documentación - Cisco Systems
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
11-Feb-2005
|
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)