Resolución de problemas de uso elevado de la CPU en el proceso de entrada IP

Introducción

Este documento explica cómo solucionar problemas de alta utilización de la CPU debido al proceso de entrada IP.

Nota: Este documento no proporciona estrategias para prevenir diferentes tipos de ataques.

Prerequisites

Requirements

Cisco recomienda leer Solución de problemas de uso elevado de la CPU en routers Cisco antes de continuar con este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

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

Entrada de IP

El proceso del software Cisco IOS^® denominado entrada IP se ocupa de los paquetes IP de conmutación de procesos. Si el proceso de entrada IP utiliza recursos de CPU inusualmente altos, el router conmuta muchos procesos de tráfico IP. Verifique estos problemas:

• La conmutación de interrupciones está inhabilitada en una interfaz (o interfaces) que tiene (tienen) mucho tráfico

  La conmutación de interrupción se refiere al uso de algoritmos de conmutación distintos de la conmutación de procesos. Algunos ejemplos son fast switching, optimum switching, Cisco Express Forwarding Switching, etc. (consulte Conceptos Básicos de Ajuste del Rendimiento para obtener más detalles). Examine el resultado del comando show interfaces switching para ver qué interfaz está cargada de tráfico. Puede verificar el comando show ip interface para ver qué métodos de conmutación se utilizan en cada interfaz. Vuelva a habilitar la interrupción de conmutación en esa interfaz. Recuerde que el fast switching común se configura en las interfaces de salida: si fast switching se configura en una interfaz, los paquetes que salen de esa interfaz son fast-switched. La conmutación de Cisco Express Forwarding se configura en las interfaces de entrada. Para crear entradas de Base de información de reenvío (FIB) y tabla de adyacencia en una determinada interfaz, configure conmutación de Cisco Express Forwarding en todas las interfaces que enrutan a esa interfaz.

• Fast Switching en la misma interfaz está desactivado

  Si una interfaz tiene muchas direcciones o subinterfaces secundarias y hay mucho tráfico originado en la interfaz y destinado a una dirección en esa misma interfaz, entonces todos esos paquetes son conmutados por proceso. En esta situación, debe habilitar ip route-cache same-interface en la interfaz. Cuando se usa la conmutación de Cisco Express Forwarding, no necesita habilitar esta conmutación en la misma interfaz por separado.

• Fast Switching en una interfaz que proporciona el ruteo de políticas inhabilitado

  Si se ha configurado un route-map en una interfaz y el route-map maneja mucho tráfico, entonces el router process-switches este tráfico. En esta situación, debe habilitar la política ip route-cache en la interfaz. Verifique las restricciones mencionadas en la sección "Habilitación del Ruteo Basado en Políticas Fast-Switched" de Configuración del Ruteo Basado en Políticas.

• Llega el tráfico que no se puede conmutar por interrupción

  Puede ser cualquiera de los tipos de tráfico enumerados. Haga clic en los elementos vinculados para obtener más información.

  • Paquetes que aún no tienen una entrada en la memoria caché de conmutación.

    Incluso si se configura la conmutación rápida, óptima o Cisco Express Forwarding (CEF), se procesa un paquete para el que no hay coincidencia en la memoria caché de fast switching o FIB y en las tablas de adyacencia. A continuación, se crea una entrada en la memoria caché o tabla apropiada, y todos los paquetes subsiguientes que coincidan con los mismos criterios son fast, optimum o CEF-switched. En circunstancias normales, estos paquetes procesados no causan una alta utilización de la CPU. Sin embargo, si hay un dispositivo en la red que 1) genera paquetes a una velocidad extremadamente alta para los dispositivos accesibles a través del router, y 2) usa diferentes direcciones IP de origen o destino, no hay coincidencia para estos paquetes en la memoria caché o tabla de switching, por lo que son procesados por el proceso de entrada IP (si se configura la conmutación NetFlow, los puertos TCP de origen y destino también se comprueban con las entradas en la memoria caché de NetFlow). Este dispositivo de origen puede ser un dispositivo no funcional o, más probablemente, un dispositivo que intenta un ataque.

    (*) Sólo con adyacencias de recolección. Consulte Cisco Express Forwarding para obtener más información sobre las adyacencias de Cisco Express Forwarding.

  • Paquetes destinados para el router

    Estos son ejemplos de paquetes destinados al router:

    • Actualizaciones de routing que llegan a una velocidad extremadamente alta. Si el router recibe una enorme cantidad de actualizaciones de ruteo que deben procesarse, esta tarea podría sobrecargar la CPU. Normalmente, esto no puede ocurrir en una red estable. La forma en que puede reunir más información depende del protocolo de ruteo que haya configurado. Sin embargo, puede comenzar a verificar el resultado del comando show ip route summary periódicamente. Los valores que cambian rápidamente son un signo de una red inestable. Los cambios frecuentes en la tabla de ruteo significan un mayor procesamiento del protocolo de ruteo, lo que da como resultado un mayor uso de la CPU. Para obtener más información sobre cómo resolver este problema, refiérase a la sección Resolución de Problemas de TCP/IP de la Guía de Troubleshooting de Internetwork.

    • Cualquier otro tipo de tráfico destinado al router. Compruebe quién ha iniciado sesión en el router y las acciones del usuario. Si alguien está conectado y ejecuta comandos que producen una salida larga, el uso elevado de la CPU por el proceso de "entrada IP" viene seguido de un uso mucho mayor de la CPU por parte del proceso Virtual Exec.

    • Ataque de simulación. Para identificar el problema, ejecute el comando show ip traffic para verificar la cantidad de tráfico IP. Si hay un problema, el número de paquetes recibidos con un destino local es significativo. Luego, examine el resultado de los comandos show interfaces y show interfaces switching para verificar qué interfaz están ingresando los paquetes. Una vez que haya identificado la interfaz receptora, active ip accounting en la interfaz saliente y vea si hay un patrón. Si hay un ataque, la dirección de origen es casi siempre diferente, pero la dirección de destino es la misma. Se puede configurar una lista de acceso para resolver el problema temporalmente (preferiblemente en el dispositivo más cercano al origen de los paquetes), pero la solución real es rastrear el dispositivo de origen y detener el ataque.

  • Tráfico de broadcast

    Verifique el número de paquetes de broadcast en la salida del comando show interfaces. Si compara la cantidad de broadcasts con la cantidad total de paquetes recibidos en la interfaz, puede hacerse una idea de si hay una sobrecarga de broadcasts. Si hay una LAN con varios switches conectados al router, esto puede indicar un problema con el árbol de expansión.

  • Paquetes IP con opciones

  • Paquetes que requieren la traducción del protocolo

  • Multilink Point-to-Point Protocol (compatible con switching de Cisco Express Forwarding)

  • Tráfico comprimido

    Si no hay adaptador de servicio de compresión (CSA) en el router, los paquetes comprimidos deben conmutarse por proceso.

  • Tráfico cifrado

    Si no hay un adaptador de servicio de cifrado (ESA) en el router, los paquetes cifrados deben conmutarse por proceso.

  • Paquetes que pasan por interfaces seriales con encapsulación X.25

    En el conjunto de protocolos X.25, el control de flujo se implementa en la segunda capa de interconexión de sistema abierto (OSI).

• Muchos paquetes, que llegan a una velocidad extremadamente alta, para un destino en una subred conectada directamente, para la que no hay entrada en la tabla de protocolo de resolución de direcciones (ARP). Esto no debería ocurrir con el tráfico TCP debido al mecanismo de ventanas, pero puede ocurrir con el tráfico UDP (protocolo de datagramas de usuario). Para identificar el problema, repita las acciones sugeridas para localizar un ataque de simulación.

• Un montón de tráfico multicast pasa a través del router. Desafortunadamente, no hay una manera fácil de examinar la cantidad de tráfico multicast. El comando show ip traffic sólo muestra información de resumen. Sin embargo, si ha configurado el ruteo multicast en el router, puede habilitar el fast-switching de los paquetes multicast con el comando de configuración de la interfaz ip mroute-cache (el fast-switching de los paquetes multicast está desactivado de forma predeterminada).

• El router está sobresuscrito. Si el router está excesivamente utilizado y no puede manejar esta cantidad de tráfico, intente distribuir la carga entre otros routers o comprar un router de extremo alto.

• La traducción de direcciones de red IP (NAT) se configura en el router y muchos paquetes del sistema de nombres de dominio (DNS) pasan a través del router. Los paquetes UDP o TCP con el puerto de origen o de destino 53 (DNS) siempre son impulsados al nivel de proceso por NAT.

• Existen otros tipos de paquetes que son impulsados al procesamiento.

• Hay fragmentación del datagrama IP. Hay un pequeño aumento en la sobrecarga de memoria y CPU debido al fragmento de un datagrama IP. Consulte Resolución de Problemas de Fragmentación de IP, MTU, MSS y PMTUD con GRE e IPSEC para obtener más información sobre cómo resolver este problema.

Cualquiera sea la razón de la alta utilización de la CPU en el proceso de entrada IP, se puede rastrear el origen del problema si depura los paquetes IP. Dado que la utilización de la CPU ya es alta, el proceso de depuración debe realizarse con extrema precaución. El proceso de depuración produce muchos mensajes, por lo que sólo se debe configurar logging buffered.

El registro en una consola provoca interrupciones innecesarias en la CPU y aumenta el uso de la CPU. El registro en un host (o el registro del monitor) genera tráfico adicional en las interfaces.

El proceso de depuración se puede iniciar con el comando debug ip packet detail exec. Esta sesión no debe durar más de tres a cinco segundos. Los mensajes de depuración se escriben en el búfer de registro. En la sección Sesión de Debugging de Paquetes IP de Ejemplo de este documento se proporciona una captura de una sesión de depuración IP de ejemplo. Una vez que se encuentra el dispositivo de origen de los paquetes IP no deseados, este dispositivo se puede desconectar de la red o se puede crear una lista de acceso en el router para descartar paquetes de ese destino.

Sesión de depuración de paquete del IP de muestra

Los destinos de registro configurados deben verificarse primero con el comando show logging:

router#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) 
    Console logging: level debugging, 52 messages logged 
    Monitor logging: level debugging, 0 messages logged 
    Buffer logging: level debugging, 148 messages logged 
    Trap logging: level informational, 64 message lines logged 
        Logging to 192.168.100.100, 3 message lines logged 
        Logging to 192.168.200.200, 3 message lines logged 
 --More--

Inhabilite todos los destinos de registro excepto el buffer de registro y borre el buffer de registro:

router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
router(config)#no logging console 
router(config)#no logging monitor 
router(config)#no logging 192.168.100.100 
router(config)#no logging 192.168.200.200 
router(config)#^Z 
router#clear logging 
Clear logging buffer [confirm]
router#

Para una mejor lectura de la salida de depuración, se deben habilitar las marcas de fecha y hora y milisegundos:

router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
router(config)#service timestamps log datetime msec 
router(config)#service timestamps debug datetime msec 
router(config)#end 
router#

Ahora se puede iniciar una sesión de depuración:

router#debug ip packet detail 
IP packet debugging is on (detailed)

La depuración no debe durar más de tres o cinco segundos. La sesión se puede detener con el comando undebug all exec:

router#undebug all 
All possible debugging has been turned off

Los resultados se pueden verificar con el comando show logging exec:

router#show logging 
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) 
    Console logging: disabled 
    Monitor logging: disabled 
    Buffer logging: level debugging, 145 messages logged 
    Trap logging: level informational, 61 message lines logged 
Log Buffer (64000 bytes): 

*Mar  3 03:43:27.320: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.204 
   (Ethernet0/0), g=10.200.40.1, len 100, forward 
*Mar  3 03:43:27.324: ICMP type=8, code=0      
*Mar  3 03:43:27.324: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.205 
   (Ethernet0/0), g=10.200.40.1, len 100, forward 
*Mar  3 03:43:27.324: ICMP type=8, code=0      
*Mar  3 03:43:27.328: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.206 
   (Ethernet0/0), g=10.200.40.1, len 100, forward 
*Mar  3 03:43:27.328: ICMP type=8, code=0      
... 

El registro muestra que:

• Se ha recibido un paquete cada cuatro milisegundos

• La dirección IP de origen es 192.168.40.53

• Los paquetes han ingresado en la interfaz Ethernet0/1

• Los paquetes tienen direcciones IP de destino diferentes.

• Los paquetes han sido enviados en la interfaz Ethernet0/0

• La dirección IP del salto siguiente es 10.200.40.1

• Los paquetes eran solicitudes ICMP (type=8)

  En este ejemplo, puede ver que el uso elevado de la CPU en el proceso de entrada IP ha sido causado por una inundación de ping de la dirección IP 192.168.40.53.

  Las inundaciones SYN se pueden detectar fácilmente de esta manera porque la presencia de la bandera SYN se indica en la salida de información de depuración:

  *Mar 3 03:54:40.436: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.204 
     (Ethernet0/0), g=10.200.40.1, len 44, forward     
  *Mar 3 03:54:40.440: TCP src=11004, dst=53, 
     seq=280872555, ack=0, win=4128 SYN

Información Relacionada

• Resolución de problemas por uso excesivo de las CPU de los routers de Cisco
• El comando show processes
• Alta utilización de la CPU en switches de Catalyst 2900XL/3500XL
• Fundamentos del ajuste de rendimiento
• Soporte Técnico y Documentación - Cisco Systems

Historial de revisiones