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 diferencia también. Este documento aclara estas diferencias y describe la utilización de la CPU en el Switches y cómo interpretar la salida del comando show processes cpu.
Nota: En este documento, las palabras “conmutan” y el “Switches” refiere al Switches del Catalyst 6500/6000.
No hay requisitos específicos para este documento.
La información en este documento se basa en las versiones de software y hardware para el Switches y el sistema de transferencia virtual (VSS) del Catalyst 6500/6000 1440 sistemas basados.
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.
Nota: El software admitido para el sistema de transferencia virtual (VSS) 1440 sistemas basados es la versión 12.2(33)SXH1 del Cisco IOS ® Software o más adelante.
Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.
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: Refiérase a Comparación de los Sistemas Operativos Cisco Catalyst y Cisco IOS para Cisco Catalyst 6500 Series Switch para obtener más información.
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: El MAC Address Learning también se llama configuración de la trayectoria.
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.
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 del 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
Telnet y el protocolo secure shell (SSH) trafican al Switch.
CPU elevada el ultilization debido a SSH se ve como:
00:30:50.793 SGT Tue Mar 20 2012CPU 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 pasa a ALTO el CPU:
Respuestas ARP a solicitudes ARP
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 vuelven un error de bit (tal como el error de un solo bit (SBE)), los paquetes se envían al CPU para el software que procesa y se corrigen. El sistema afecta un aparato un buffer para ellos y utiliza a los recursos de la CPU para corregirlo.
Cuando el PBR y la lista de acceso reflexiva están en la trayectoria de un flujo de tráfico, el paquete es conmutado por software, que requiere un ciclo de la CPU adicional.
Misma interfaz de adyacencia
¿Paquetes que fallan el control del reenvío de trayecto inverso (RPF)? falla de RPF
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).
Tráfico rechazado por una ACL (lista de control de acceso) con la función direcciones inalcanzables ICMP activada
Nota: Este 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.
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, el ACL reflexivo confía en las entradas TCAM dinámicas para crear los accesos directos por hardware para un flujo determinado. 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: Sincronice (SYN), SYN reconocen (SYN ACK), y los paquetes ACK comprenden la entrada en contacto de tres vías. 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 el 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. El CBAC es una característica software solamente; trafique que está conforme al examen no es conmutado por hardware.
Nota: Trafique que está conforme al examen puede ser tarifa limitada en el Supervisor Engine 720.
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)
Network-Based Application Recognition (NBAR)
Inspección ARP, sólo con CatOS
Seguridad de Puertos, sólo con CatOS
Snooping del DHCP
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.
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 LCP cedular es parte del código del firmware. En todos los módulos que no requieran un DFC, el firmware se ejecuta en un procesador específico llamado el (LCP) del procesador del linecard. Este procesador se utiliza para programar el hardware ASIC y para comunicar al módulo de la central supervisor.
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 cpuPID 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
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.
El NAT utiliza ambo la expedición del hardware y software. El establecimiento inicial de los tranlsations NAT debe ser hecho en el software y la expedición adicional se hace con el hardware. El NAT también utiliza la tabla del Netflow (máximo 128 KB). Por lo tanto, si la tabla del Netflow es llena, el Switch también comenzará a aplicar la expedición NAT vía el software. Esto sucede con las explosiones del mucho tráfico y causará normalmente un aumento en el CPU de 6500.
El Supervisor Engine 1 incluye una Tabla de Caché de Flujo que admite 128,000 entradas. Sin embargo, en base de la eficacia del algoritmo de troceo, estas entradas se extienden a partir del 32,000 a 120,000. En el Supervisor Engine 2, la tabla de FIB se genera y se programa en el 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 cpuCPU 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 Idle2 2 245 1000 0.00% 0.00% 0.00% -2 Flash MIB Updat3 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 cefTotal L3 packets switched: 124893998234Total L3 octets switched: 53019378962495Total route entries: 112579 IP route entries: 112578 IPX route entries: 1 IPM route entries: 0IP load sharing entries: 295IPX load sharing entries: 0Forwarding entries: 112521Bridge entries: 56Drop entries: 2IOS% show ip cef summaryIP 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, 86771426inserts, 86658859invalidations 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 CPU elevada el problema de la utilización, resumen de Route del permiso. El resumen de Route puede minimizar el tiempo de espera en una red compleja reduciendo las cargas de trabajo del procesador, los requisitos de memoria, y la demanda del 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.
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 paquetes que requieran registro se lleva a cabo íntegramente mediante software en la MSFC3. El OAL admite o descarta paquetes en hardware en la PFC3. El OAL utiliza una rutina optimizada para enviar información a la MSFC3 con el objetivo de generar mensajes de registro.
Nota: Para la información sobre el OAL, refiera al registro de ACL optimizado con una sección PFC3 comprensión del soporte del Cisco IOS ACL.
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 10ICMP 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, ésta es la salida de la captura del netdr, que muestra que el IPv4 TTL es 1:
Source mac 00.00.50.02.10.01 3644Dest mac AC.A0.16.0A.B0.C0 4092Protocol 0800 4094Interface Gi1/8 3644Source vlan 0x3FD(1021) 3644Source index 0x7(7) 3644Dest index 0x380(896) 3654 L3 ipv4 source 211.204.66.117 762ipv4 dest 223.175.252.49 3815ipv4 ttl 1 3656ipv6 source - 0ipv6 dest - 0ipv6 hoplt - 0ipv6 flow - 0ipv6 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.
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.
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 de las Catalyst 6500 Series, los paquetes de broadcast se caen solamente 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 cambio VRRP del respaldo a dominar causado por las tormentas de broadcast pudo causar CPU elevada la utilización.
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)
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.
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 empuja hacia abajo al hardware en el 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 ponga esta lista de acceso en una interfaz del transitar. Está destinada exclusivamente para redes stub (redes con hosts únicamente).
Si desea más información, consulte estos documentos:
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 porqué los paquetes se llevan en batea al MSFC (reciba, opción del IP, ninguna adyacencia, etc) y cuántos. Por ejemplo:
Switch#show cef not-cef-switchedCEF Packets passed on to next switching layerSlot No_adj No_encap Unsupp'ted Redirect Receive Options Access FragRP 6222 0 136 0 60122 0 0 05 0 0 0 0 0 0 0 0IPv6 CEF Packets passed on to next switching layerSlot No_adj No_encap Unsupp'ted Redirect Receive Options Access MTURP 0 0 0 0 0 0 0 0
El ibc de la demostración y el ibc de la demostración informan los comandos show la cola CPU y pueden ser utilizados cuando usted está monitoreando el estatus CPU.
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>.
Cuando el proceso de desactualización L3 exporta un gran número de valores del ifindex usando la Exportación de datos de NetFlow (NDE), el USO de la CPU pudo golpear el 100%.
Si usted encuentra este problema, marque si estos dos comandos están habilitados:
set mls nde destination-ifindex enable
set mls nde source-ifindex enable
Si usted habilita estos comandos, el proceso debe exportar todos los valores del ifindex del destino y de la fuente usando el NDE. La utilización del proceso de desactualización L3 pasa a ALTO puesto que debe realizar las operaciones de búsqueda de la BOLA para todos los valores del ifindex del destino y de la fuente. Debido a esto, la tabla se convierte por completo, el proceso de desactualización L3 pasa a ALTO, y el USO de la CPU golpea el 100%.
Para resolver este problema, inhabilite estos comandos:
set mls nde destination-ifindex disable
set mls nde source-ifindex disable
Utilice estos comandos de verificar los valores:
El spanning tree mantiene un entorno de Capa 2 libre de loops en redes conmutadas redundantes y puenteadas. Sin el STP, las tramas colocan 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:
Muchos VLA N
Muchos switches en un dominio STP
Soporte de varios proveedores
Más nuevas mejoras de 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.
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-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 softwareswitched
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.
Unicast del direccionamiento de la compresa acl del IPv6 de los mls del permiso. Este comando es necesario si el IPv6 ACL está correspondiendo con en los números del puerto del protocolo L4. Si este comando no se habilita, el tráfico del IPv6 será llevado en batea al CPU para el proceso del software. Este comando no se configura por abandono.
En el Cisco ME 6500 Series Ethernet Switches, el cobre SFP requiere más interacción del firmware que otros tipos de SFP, que aumenta la utilización de la CPU.
Los algoritmos de software que manejan los SFP de cobre se han mejorado en las versiones del Cisco IOS SXH.
En los Cisco Catalyst 6500 Series Switch que funcionan con el software IOS modular, la utilización de la CPU normal es un software IOS poco mayor que NON-modular.
El software IOS modular paga un precio por la actividad más que paga un precio por el paquete. El software IOS modular mantiene los procesos consumiendo cierto CPU incluso si no hay mucho los paquetes, así que el consumo de la CPU no se basa en el tráfico real. Sin embargo, cuando van los paquetes procesado alta velocidad, el CPU consumido en el software IOS modular no debe ser más que eso en el software IOS NON-modular.
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 cpuCPU 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 Idle2 2 261 1000 0.00% 0.00% 0.00% -2 Flash MIB Updat3 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 resolver problemas, utilice este ejemplo de secuencia de comandos EEM para recoger la salida del Switch cuando usted experimenta CPU elevada la utilización:
event manager applet cpu_statsevent 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 5action 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 | appenddisk0: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 del rx de la captura del netdr del debug es útil cuando el CPU es elevado debido al process switching de los paquetes en vez de hardware. Captura 4096 paquetes entrantes al CPU cuando se funciona con el comando. El comando es totalmente seguro y es la herramienta más conveniente para CPU elevada los problemas en los 6500. No causa la carga adicional al CPU.
En esta sección, se identifican algunas utilidades y herramientas que pueden ayudarlo a analizar este tráfico.
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/1GigabitEthernet4/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:
Router#show buffers input-interface gigabitethernet 4/1 packetBuffer 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 6308060F70: 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: Refiera a este documento para más información sobre interrupt-switched contra la utilización de la CPU process-switched:
Sección Uso Excesivo de la CPU Debido a Interrupciones de Resolución de Problemas por Uso Excesivo de CPU en Routers Cisco
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.
Ésta es la sintaxis de los comandos:
test monitor session 1-66 add {rp-inband | sp-inband} [rx | tx | both]
Utilice este sintaxis para el Cisco IOS Software 12.2 versiones SX:
test monitor add {1..66} {rp-inband | sp-inband} {rx | tx | both}
Nota: Para la versión SXH, usted debe utilizar el comando monitor session para configurar una sesión del SPAN local, y después utiliza este comando de asociar a la sesión SPAN al 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: Para más información sobre estos comandos, refiera a configurar el SPAN local (modo de la configuración de SPAN) en la guía de configuración de software de la versión 12.2SX del Catalyst 6500.
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 el Cisco IOS 12.2 versiones SX, el comando se han cambiado para probar el monitor agregan 1 rx RP-inband.
Router#show monitor Session 1---------Type : Local SessionSource Ports :Both : Fa3/3Destination Ports : Fa3/2SP console:Router-sp#test monitor session 1 showIngress 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 el Cisco IOS 12.2 versiones SX, el comando se han cambiado para probar la demostración 1. del monitor.
A continuación le ofrecemos un ejemplo sobre una consola SP:
Router-sp#test monitor session 1 showIngress 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
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 es 16/1 para los motores del supervisor en el slot 2.
Console> (enable) show mac 15/1Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast-------- -------------------- -------------------- --------------------15/1 193576 0 1Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast-------- -------------------- -------------------- --------------------15/1 3 0 0Port Rcv-Octet Xmit-Octet-------- -------------------- --------------------15/1 18583370 0MAC 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:
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/10Console> (enable) show spanDestination : Port 5/10Admin Source : Port 15/1Oper Source : NoneDirection : transmit/receiveIncoming Packets: disabledLearning : enabledMulticast : enabledFilter : -Status : active
Si usted recoge una traza de sniffer en el puerto 5/10, la traza de sniffer muestra los paquetes que transmiten a y desde el MSFC. Configure a la sesión SPAN como tx para capturar los paquetes que se destinan solamente al MSFC, y no del MSFC.
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: Para los módulos Optical Services Modules (OS), usted no puede realizar una captura del SPAN del tráfico.
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: Los puertos inestables o los puertos de host con los minusválidos del STP portfast causan los 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 alto hora de la CPU (cuando el CPU es el 75% o arriba), recoja la salida 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.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
27-Aug-2012 |
Versión inicial |