A veces es difícil identificar por qué un firewall Cisco Pix o Cisco ASA está a niveles altos de CPU.
Existe documentación de buenas prácticas en el soporte oficial de Cisco para minimizar el impacto de los procesos sobre la cpu:
El primer comando a ejecutar para ver el consumo de cpu es :
firewall-management# show cpu usage
CPU utilization for 5 seconds = 92%; 1 minute: 92%; 5 minutes: 92%
El output anterior muestra un firewall degradado con valores de consumo de cpu disparados.
Uno de los comandos que resulta más útil es el show tech-support que además permite añadirle un flag para no mostrar la configuración del firewall en pantalla :
show tech-support no-config
Este comando nos saca por pantalla los “shows” más importantes para la resolución de problemas.
Sin embargo, en el ejemplo anterior vemos un 92% de uso y el firewall con el rol de separar una red de gestión fuera de banda ( out of band management ), se encuentra prácticamente sin tráfico, sin ser atacado, además tampoco tiene direccionamiento ip público y únicamente con cuatro sesiones activas.
Este firewall no ha entrado todavía en producción y la configuración del mismo no estaba finalizada
Además, el firewall secundario con el que forma un cluster activo-pasivo también mostraba valores de la misma magnitud, cuando en realidad debería estar prácticamente a cero. Como no me apetece abrir un terminal ssh al firewall secundario, desde el firewall primario ejecutamos el comando sobre el firewall secundario
firewall-management# failover exec mate show cpu usage
CPU utilization for 5 seconds = 91%; 1 minute: 92%; 5 minutes: 92%
Entonces, ¿ Cuál es el problema ?
Ante esto y después de analizar profundamente la configuración del equipo, su tráfico, sus conexiones ect y no encontrar nada anormal, deduje que un proceso debido a un bug del software estaba provocando el problema.
Si miramos la salida del comando show processes, vemos la lista de procesos y una serie de columnas un poco indescifrables ya que no muestra el tanto por ciento de cpu que consume cada proceso.
Para entender la salida del comando, la información completa para la interpretación del show processes está también documentada en el site de Cisco :
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008009456c.shtml
A partir de ahí, empecé a analizar los procesos y me fijé en la columna Runtime que según el link anterior informa :
Runtime (ms) = CPU time the thread has used, in milliseconds
Aunque la salida del comando es larga, pongo el trozo interesante :
Lo que destaca es que el proceso de telnet, si ya sé, que hace activo eso ?? , como ya he comentado la configuración no estaba finalizada …
Pero para saber exactamente que proceso es el culpable, hay que obtener diferentes muestras del show processes, esperando un minuto y restar la columna Runtime
Una herramienta online permite realizar la operación, te muestra el resultado y así podemos determinar fácilmente cuál es el culpable :
http://bogpeople.com/networking/pixhighcpu/compare.cgi
Solución :
Desactivar telnet !! 🙂
firewall-management# show run telnet
telnet 10.x.x.x 255.255.255.255 management
telnet timeout 5
firewall-management(config)# no telnet 10.x.x.x 255.255.255.255 management
firewall-management(config)# end
firewall-management# show cpu usage
CPU utilization for 5 seconds = 0%; 1 minute: 80%; 5 minutes: 88%
Home