Switches : Switches Cisco Catalyst de la serie 6500

Uso Excesivo de CPU en Switches Catalyst 6500/6000

10 Abril 2009 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (27 Agosto 2012) | Comentarios

Contenidos

Introducción
Prerrequisitos
      Requisitos
      Componentes Utilizados
      Convenciones
Diferencia entre el Software de Sistema CatOS y Cisco IOS
Introducción al Uso de CPU en Switches Catalyst 6500/6000
Situaciones y Funciones que Hacen que el Tráfico Pase por Software
      Paquetes Destinados al Switch
      Paquetes y Condiciones que Requieren Procesamiento Especial
      Funciones Basadas en ACL
      Funciones Basadas en NetFlow
      Tráfico Multicast
      Otras Funciones
      Situaciones IPv6
      Módulo DFC
Causas Frecuentes y Soluciones para Problemas de Uso Excesivo de CPU
      Direcciones IP Inalcanzables
      Uso del Espacio de Tabla CEF FIB en la Tabla de Caché de Flujo
      Registro de ACL Optimizado
      Límite de Velocidad de Paquetes al CPU
      Fusión Física de VLAN Debido a Cableado Incorrecto
      Tormenta de Broadcast
      Seguimiento de la Dirección Next-Hop BGP (Proceso del Escáner BGP)
      Tráfico Multicast No RPF
      Comandos show
      Procesos Exec
      Tormenta BPDU
      Sesiones SPAN
      %CFIB-SP-STBY-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched
Verificación del Uso de CPU
Utilidades y Herramientas para Determinar el Tráfico que se Impulsa a la CPU
      Software de Sistema Cisco IOS
      Software de Sistema CatOS
Recomendaciones
Discusiones relacionadas de la comunidad de soporte de Cisco

Introducción

Este documento describe causas de uso excesivo de CPU en los switches Cisco Catalyst 6500/6000 Series. 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. La salida también difiere en su significado. Este documento clarifica estas diferencias. El documento describe el uso de la CPU en los switches y cómo interpretar la salida del comando show processes cpu.

Nota: En este documento, las palabras "switch" y "switches" hacen referencia a los Switches Catalyst 6500/6000.

Prerrequisitos

Requisitos

No existen requisitos específicos para este documento.

Componentes Utilizados

La información incluida en este documento se basa en las versiones de software y hardware para Switches Catalyst 6500/6000.

La información de este documento se ha creado a partir de los dispositivos en un entorno específico de laboratorio. Todos los dispositivos que se utilizan en este documento se iniciaron con una configuración vacía (predeterminada). Si su red está en funcionamiento, asegúrese de comprender el posible efecto de cualquier comando.

Convenciones

Consulte Convenciones de Consejos Técnicos de Cisco para obtener más información sobre las convenciones del documento.

Diferencias 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 la MSFC opcional está instalada, se utiliza una imagen del software Cisco IOS independiente para ejecutar la MSFC.

Cisco IOS Software tanto en el Supervisor Engine como en la 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 proporcionar un indicio bastante preciso de la carga de procesamiento de tráfico en el router.

Los Switches Catalyst 6500/6000 no utilizan el CPU de la misma manera. Estos switches toman decisiones de reenvío en hardware, no en software. Por lo tanto, cuando los switches efectúan el reenvío o toman decisiones de switcheo para la mayoría de las tramas que pasan a través del switch, el proceso no involucra al CPU del Supervisor Engine.

Los Switches Catalyst 6500/6000 poseen dos CPUs. Un CPU es el CPU del Supervisor Engine, que se denomina Network Management Processor (NMP) o Switch Processor (SP). El otro CPU es el CPU del motor de ruteo de Capa 3, denominada MSFC o Route Processor (RP).

El CPU del SP realiza funciones entre las que se encuentran:

  • Colaborar en el aprendizaje y temporizació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 al CPU del switch

    Algunos ejemplos son: tráfico Telnet, HTTP y Simple Network Management Protocol (SNMP).

El 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 protocolos de ruteo

    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

  • 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 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 (checksum)

  • 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 switcheado por software en el Supervisor Engine 720, tanto en el Software Cisco IOS como en CatOS

    El tráfico IPX también es switcheado por software en el Supervisor Engine 2/Software Cisco IOS; pero el tráfico se switchea por hardware en el Supervisor Engine 2/CatOS. El tráfico IPX es switcheado 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 (content-addressable memory - 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 soportados, como host de origen

    En el Supervisor Engine 720, el proceso del tráfico de Capa 3 IPX siempre se efectúa en software.

  • Access Control Entries (ACE) que requieran registro, con la palabra clave log

    Esto se aplica a las funciones de registro (log) de ACL y VLAN ACL (VACL). ACEs en la misma ACL que no requieran registro aún se procesan en hardware. El Supervisor Engine 720 con PFC3 soporta el límite de velocidad de paquetes que se redireccionan a la MSFC para registro ACL y VACL. El Supervisor Engine 2 con PFC3 soporta el límite de velocidad de paquetes que se redireccionan a la MSFC para registro ACL y VACL. Soporte para el 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 soportados

    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 hardware en 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.

  • Autenticación proxy

    La velocidad de un tráfico sujeto a autenticación proxy se puede limitar en el Supervisor Engine 720.

  • Seguridad IP (IPsec) del Cisco IOS Software

    La velocidad de un tráfico sujeto a encripción 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 switchean por hardware.

    Esta disposición de flujo se aplica a ACLs reflexivas, Web Cache Communication Protocol (WCCP) y a Cisco IOS Server Load Balancing (SLB).

    Nota: En el Supervisor Engine 1, las ACLs 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 switchean por hardware.

  • Con la función TCP Intercept, el three-way handshake 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 three-way handshake. 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 switchean por hardware. En el caso de paquetes TCP, se crea un acceso directo de hardware en la tabla NetFlow una vez finalizado el TCP three-way handshake.

    • En Supervisor Engine 2 y Supervisor Engine 1:

      Todo el tráfico que requiera NAT se switchea 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 exclusivamente de software; el tráfico sujeto a inspección no se switchea 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

  • Network-Based Application Recognition (NBAR)

  • Inspección ARP, sólo con CatOS

  • Seguridad de Puertos, sólo con CatOS

  • Indagación 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 (scope enforcement check)

  • 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 switchea por hardware.

Módulo DFC

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.

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 del 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

Direcciones IP Inalcanzables

Cuando un grupo de acceso (access Group) 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 el 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.

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 soporta 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 soporta un máximo de 1,000,000 entradas. Una vez que se excedió el espacio, los paquetes comienzan a switchearse 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

!--- Resultado suprimido.

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

!--- Resultado suprimido.


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

!--- Verá estos mensajes si se excede el espacio de TCAM:

%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 el switcheo por software de más paquetes y, en consecuencia, a un uso excesivo de CPU.

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 (log) 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 (logs).

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 al 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 (denial-of-service attacks). 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

A continuación se presenta 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 al CPU debido a TTL=1, ejecute este comando:

Router(config)#mls rate-limit all ttl-failure 15


!--- donde 15 es la cantidad de paquetes por segundo con TTL=1.
!--- El rango válido es de 10 a 1000000 pps.

El uso excesivo de CPU también puede deberse a paquetes con TTL = 1 que se filtran al CPU. Si desea limitar la cantidad de paquetes que se filtran al 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 VLANs Debido a Cableado Incorrecto

El uso excesivo de CPU también puede ser el resultado de que se fusionen dos o más VLANs debido a cableado incorrecto. Además, si se deshabilita STP en los puertos donde se registra la fusión de las VLANs, 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 Broadcast

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.

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.

Si desea comprender cómo funciona la supresión de broadcast y cómo habilitar la función, consulte:

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 (next hops). 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 (route dampening). 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 tenga 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 recorrida 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 Soporte de 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 ASICs 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 el 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 switcheo rápido del software (asumiendo que el switcheo rápido 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 switcheo 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 al 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 del 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. Esta función se puede utilizar para manejar tráfico no RPF de manera eficiente para 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 transfiere al hardware del switch. La lista de acceso se transfiere al hardware del switch. Esta lista de acceso impide que el 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).

Para obtener 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 este output es un output impulsado por interrupciones. Su única preocupación deberá ser el uso de CPU excesivo en procesos que no sean comandos show.

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 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 del 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 simple carácter a través de estas líneas, utiliza algunos recursos del CPU:

  • En el caso de la consola (Exec), el router emplea una interrupción por carácter.

  • 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.

    1. Compruebe si se ha iniciado algún debug en el router con el comando show debugging.

    2. Deshabilite el registro de la consola en el router con la forma no del comando logging console.

    3. 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.

    1. 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.

    2. 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 del 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>.

Tormenta BPDU

Spanning tree mantiene un entorno de Capa 2 libre de loops en redes switcheadas redundantes y puenteadas (bridged). Sin STP, las tramas forman loops y/o se multiplican de manera indefinida. 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 (bridged) con base en software (IEEE 802.1D); sin embargo, puede resultar complicado implementar exitosamente STP en redes switcheadas de magnitud que cuenten con estas características:

  • Muchas VLANs

  • Muchos switches en un dominio STP

  • Soporte de varios proveedores

  • 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:

  1. Separe las VLANs de los switches.

  2. Utilice una versión mejorada de STP, como MST.

  3. 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 elCPU 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 del 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 switcheará por software. La eliminación de rutas no ayuda a retomar el switcheo por hardware. Una vez que la TCAM ingresa al estado de excepción, se debe reiniciar 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.

Comprobación del Uso del 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

!--- Resultado suprimido.

 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

!--- Resultado suprimido.

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

!--- Resultado suprimido.

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 este output, el primer proceso es Kernel and Idle, que indica la utilización ociosa de recursos del CPU. Este proceso suele consumir muchos recursos, a menos que otros procesos consuman ciclos del CPU. En este ejemplo, el proceso SptBpduRx genera uso excesivo del CPU.

Si el uso del 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 del CPU es excesivo debido a que se impulsa tráfico al 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.

Utilidades y Herramientas para Determinar el Tráfico que Impulsa al 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 este output, puede ver que el tráfico entrante se switchea en la Capa 3 y no en la Capa 2. Esto indica que el tráfico se impulsa al 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 switchean 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 switchea por interrupción, no podrá ver esos paquetes con el comando show buffers input-interface. Si desea ver los paquetes impulsados a RP para ser switcheados 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 switcheado por interrupción en comparación con el uso de CPU switcheado 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.

La siguiente es la sintaxis del comando:

test monitor session 1-66 add {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 el 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

!--- Utilice cualquier interfaz que esté apagada administrativamente.

Router#monitor session 1 destination interface 3/2

Ahora, el turno de la consola SP. A continuación se presenta un ejemplo:

Router-sp#test monitor session 1 add 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

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 del 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.

A continuación se presenta 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 (sniffer trace) 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 al 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 del 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 dicho CPU.

  1. Evalúe (respecto a una línea base) el uso del 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 del CPU.

  2. Cuando resuelva problemas relacionados con el uso del CPU, tenga en cuenta estas preguntas:

    • ¿Qué procesos generan el uso más elevado? ¿Difieren estos procesos de su línea base?

    • ¿El uso del CPU consistentemente elevado sobre 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 (TCNs) en la red?

      Nota: Un puerto inestable o puerto host con STP PortFast deshabilitados generan notificaciones TCNs.

    • ¿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?

  3. De ser posible, aísle la VLAN de administración de las VLANs 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 del CPU del Supervisor Engine y, en casos extremos, interferir con la funcionamiento normal del switch.

  4. Si el consumo de recursos del 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 al CPU.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 63992