ASA 8.3 y posterior: Supervisión y resolución de problemas de rendimiento
Contenido
Introducción
Este documento proporciona información sobre los comandos ASA que puede utilizar para supervisar y resolver problemas del rendimiento de un Cisco Adaptive Security Appliance (ASA).
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Componentes Utilizados
La información de este documento se basa en un Cisco Adaptive Security Appliance (ASA) que ejecuta la versión 8.3 y posteriores.
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
Troubleshoot
Para resolver problemas de funcionamiento, verifique las áreas básicas descritas en esta sección.
Configuración de velocidad y dúplex
El dispositivo de seguridad se configura previamente para detectar automáticamente las configuraciones de velocidad y dúplex en una interfaz. Sin embargo, hay varias situaciones que pueden hacer que el proceso de negociación automática falle, lo que provoca discordancias dúplex (y problemas de funcionamiento). Para la infraestructura de red de misión crítica, Cisco codifica manualmente la velocidad y el dúplex en cada interfaz para que no haya posibilidad de error. Estos dispositivos por lo general no se mueven, de manera que si los configura correctamente, no es necesario cambiarlos.
En cualquier dispositivo de red, la velocidad del link puede ser detectada, pero el dúplex debe ser negociado. Si dos dispositivos de red se configuran para autonegociar la velocidad y el dúplex, intercambian las tramas (llamadas Pulsos de Links Rápidos, o FLP) que anuncian sus capacidades de velocidad y dúplex. Para un link partner que no está al tanto (de la autonegociación), estos pulsos son similares a tramas regulares de 10 Mbps. Para un link partner que puede decodificar los pulsos, los FLPs contienen todas las configuraciones de velocidad y dúplex que el link partner puede proporcionar. La estación que recibe los FLPs reconoce las tramas, y los dispositivos acuerdan mutuamente las configuraciones más altas de velocidad y dúplex que cada uno puede alcanzar. Si un dispositivo no soporta la autonegociación, el otro dispositivo recibe los FLPs y las transiciones al modo de detección paralela. Para detectar la velocidad del socio, el dispositivo escucha la longitud de los pulsos, y luego configura la velocidad en consecuencia. El problema surge con la configuración dúplex. Debido a que se debe negociar el dúplex, el dispositivo que se configura en autonegociar no puede determinar los ajustes en el otro dispositivo, por lo que el valor predeterminado es semidúplex, como se establece en el estándar IEEE 802.3u.
Por ejemplo, si configura la interfaz ASA para la negociación automática y la conecta a un switch codificado para 100 Mbps y dúplex completo, el ASA envía FLPs. Sin embargo, el switch no responde porque es codificado para la velocidad y el dúplex y no participa en la autonegociación. Debido a que no recibe respuesta del switch, el ASA pasa al modo de detección paralela y detecta la longitud de los pulsos en las tramas que el switch envía. Es decir, el ASA detecta que el switch está configurado en 100 Mbps, por lo que configura la velocidad de la interfaz en consecuencia. Sin embargo, debido a que el switch no intercambia FLP, el ASA no puede detectar si el switch puede ejecutar el dúplex completo, por lo que el ASA configura el dúplex de la interfaz en semidúplex, como se establece en el estándar IEEE 803.2u. Debido a que el switch está codificado a 100 Mbps y dúplex completo, y el ASA acaba de negociar automáticamente a 100 Mbps y semidúplex (como debería), el resultado es una discordancia dúplex que puede causar graves problemas de rendimiento.
Se revela una velocidad o una discordancia dúplex con mayor frecuencia cuando los contadores de errores en las interfaces en cuestión aumentan. La mayoría de los errores comunes son trama, verificaciones por redundancia cíclica (CRC), y runts. Si estos valores se incrementan en su interfaz, se produce una discrepancia de dúplex/velocidad o un problema de cableado. Debe resolver este problema antes de continuar.
Ejemplo:
Interface GigabitEthernet0/0 "outside", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
Input flow control is unsupported, output flow control is unsupported
MAC address 0013.c480.b2b8, MTU 1500
IP address 192.168.17.4, subnet mask 255.255.255.0
311981 packets input, 20497296 bytes, 0 no buffer
Received 311981 broadcasts, 157 runts, 0 giants
379 input errors, 107 CRC, 273 frame, 0 overrun, 0 ignored, 0 abort
0 pause input, 0 resume input
0 L2 decode drops
121 packets output, 7744 bytes, 0 underruns
0 pause output, 0 resume output
0 output errors, 0 collisions, 1 interface resets
0 late collisions, 0 deferred
0 input reset drops, 0 output reset drops, 0 tx hangs
input queue (blocks free curr/low): hardware (255/249)
output queue (blocks free curr/low): hardware (255/254)
Uso de CPU
Si notó que la utilización de la CPU es alta, complete estos pasos para resolver problemas:
- Verifique que el recuento de conexiones en el conteo show xlate sea bajo.
- Verifique que el bloque de memoria sea normal.
- Verifique que el número de ACL sea más alto.
- Ejecute el comando show memory detail y verifique que la memoria utilizada por el ASA sea de uso normal.
- Verifique que los conteos en show processes cpu-hog y show processes memory sean normales.
- Ningún host presente dentro o fuera del dispositivo de seguridad puede generar el tráfico malintencionado o total que puede ser un tráfico multicast/broadcast y provocar el uso elevado de la CPU. Para resolver este problema, configure una lista de acceso para negar el tráfico entre los hosts ( de principio a fin) y verifique el uso.
- Verifique la configuración de dúplex y velocidad en las interfaces ASA. La configuración de discordancia con las interfaces remotas puede aumentar el uso de CPU.
Este ejemplo muestra el número más elevado en el error de entrada y se satura debido a la discordancia de velocidad. Utilice el comando show interface para verificar los errores:
Ciscoasa#sh int GigabitEthernet0/1 Interface GigabitEthernet0/1 "inside", is up, line protocol is up Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps) Input flow control is unsupported, output flow control is unsupported MAC address 0013.c480.b2b8, MTU 1500 IP address 192.168.17.4, subnet mask 255.255.255.0 311981 packets input, 20497296 bytes, 0 no buffer Received 311981 broadcasts, 157 runts, 0 giants 7186 input errors, 0 CRC, 0 frame, 7186 overrun, 0 ignored, 0 abort 0 pause input, 0 resume input 0 L2 decode drops 121 packets output, 7744 bytes, 0 underruns 0 pause output, 0 resume output 0 output errors, 0 collisions, 1 interface resets 0 late collisions, 0 deferred 0 input reset drops, 0 output reset drops, 0 tx hangs input queue (blocks free curr/low): hardware (255/249) output queue (blocks free curr/low): hardware (255/254)Para resolver este problema, configure la velocidad como automática a la interfaz correspondiente.
- Otro motivo del uso de CPU elevado puede ser la existencia de demasiadas rutas multicast. Ejecute el comando show mroute para verificar si ASA recibe demasiadas rutas multicast.
- Utilice el comando show local-host para ver si la red experimenta un ataque de negación de servicio, que puede indicar un ataque de virus en la red.
- Es posible que se produzca un uso excesivo de la CPU debido al Id. de bug Cisco CSCsq48636 . Consulte Cisco bug ID CSCsq48636 (sólo clientes registrados) para obtener más información.
Uso de Memoria Intensivo
Las siguientes son algunas posibles causas y resoluciones para el uso de memoria intensivo:
- Registro de evento: El registro de evento puede consumir una gran cantidad de memoria. Para resolver este problema, instale y registre todos los eventos a un servidor externo, tal como un servidor syslog.
- Pérdida de Memoria: Un problema conocido en el software del dispositivo de seguridad puede resultar en un consumo alto de memoria. Para resolver este problema, actualice el software del dispositivo de seguridad.
- Debugging Habilitado: El debugging puede consumir una gran cantidad de memoria. Para resolver este problema, inhabilite el debugging con el comando undebug all.
- Puertos de Bloqueo: El bloqueo de puertos en la interfaz exterior de un dispositivo de seguridad hace que el dispositivo de seguridad consuma grandes cantidades de memoria para bloquear los paquetes a través de los puertos especificados.Para resolver este problema, bloquee el tráfico ofensivo en el extremo ISP.
- Detección de amenazas: La característica de la detección de la amenaza consiste en diversos niveles de estadísticas que recolectan diversas amenazas, y escanean la detección de amenazas, que determina cuando un host realiza un escaneo. Apague esta característica para consumir menos memoria.
PortFast, Canalización y Trunking
De forma predeterminada, muchos switches, tales como los switches Cisco que ejecutan el sistema operativo Catalyst (OS), están diseñados para ser dispositivos listos para el uso. Como tal, muchos de los parámetros de puerto predeterminados no son deseables cuando un ASA se conecta al switch. Por ejemplo, en un switch que ejecuta Catalyst OS, la canalización predeterminada se configura en al Automática, y PortFast se inhabilita. Si conecta un ASA a un switch que ejecuta el Catalyst OS, inhabilite la canalización, inhabilite el trunking y habilite PortFast.
La canalización, también conocida como Fast EtherChannel o EtherChannel de Giga, se utiliza para vincular dos o más puertos físicos en un grupo lógico con el fin de aumentar el rendimiento de procesamiento general a través del link. Cuando un puerto se configura para la canalización automática, envía las tramas del Port Aggregation Protocol (PAgP) mientras que el link se vuelve activo para determinar si es parte de un canal. Estas tramas pueden causar problemas si el otro dispositivo intenta autonegociar la velocidad y dúplex del link. Si la canalización en el puerto se configura en Automática, también provoca una demora adicional de cerca de 3 segundos antes de que el puerto comience a reenviar tráfico después de que el link se active.
El trunking, también conocido por los protocolos de trunking comunes Inter-Switch Link (ISL) o Dot1q, combina varias LANs virtuales (VLANs) en un puerto único (o link). La conexión troncal se usa normalmente entre dos switches cuando ambos tienen más de una VLAN definida. Cuando un puerto se configura para el trunking automático, envía las tramas del Dynamic Trunking Protocol (DTP) mientras que el link sube para determinar si el puerto con el que se conecta desea conectarse mediante trunking. Estas tramas DTP pueden provocar problemas con la negociación automática del link. Si el trunking se configura en Automático en un puerto del switch, agrega una demora adicional de cerca de 15 segundos antes de que el puerto comience a reenviar tráfico después de que el link se active.
PortFast, también conocido como Fast Start, es una opción que informa al switch que un dispositivo de la Capa 3 está conectado fuera de un puerto del switch. El puerto no espera los 30 segundos predeterminados (15 segundos para escuchar y 15 segundos para aprender); en cambio, esta acción hace que el switch coloque al puerto en el estado de reenvío inmediatamente después que el link se inicie. Es importante comprender que cuando habilita PortFast, el spanning tree no se inhabilita. El Spanning tree todavía está activo en ese puerto. Cuando habilita PortFast, se informa al switch solamente que no hay otro switch o hub (dispositivo de capa 2 solamente) conectado en el otro extremo del link. El switch elimina la demora normal de 30 segundos mientras intenta determinar si surge un loop de Capa 2 al activarse ese puerto. Una vez activado el link, todavía participa en el spanning tree. El puerto envía las unidades de datos de paquetes de bridge (BPDU), y el switch todavía escucha las BPDUs en ese puerto. Por estas razones, se recomienda que habilite PortFast en cualquier puerto del switch que se conecte a un ASA.
traducción de Dirección de Red (NAT)
A cada NAT o sesión de Sobrecarga NAT (PAT) se le asigna una ranura de traducción conocida como xlate. Estas xlates pueden persistir incluso después de realizar cambios a las reglas de NAT que las afectan. Esto puede llevar a un agotamiento de las ranuras de traducción o a una conducta inesperada, o a ambas por el tráfico que experimenta la traducción. Esta sección explica cómo ver y borrar las xlates en el dispositivo de seguridad.
Ejemplo de configuración ASA para PAT que utiliza la dirección IP de la interfaz externa:
object network OBJ_GENERIC_ALL subnet 0.0.0.0 0.0.0.0 nat (inside,outside) source dynamic OBJ_GENERIC_ALL interface
El tráfico que fluye a través del dispositivo de seguridad por lo general se somete a NAT. Para ver las traducciones que funcionan en el dispositivo de seguridad, ejecute el comando show xlate:
Ciscoasa#show xlate
5 in use, 5 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
NAT from any:192.168.1.10 to any:172.16.1.1/24
flags s idle 277:05:26 timeout 0:00:00
Las ranuras de traducción pueden persistir después de que se realicen los cambios clave. Para borrar las ranuras de la traducción actual en el dispositivo de seguridad, ejecute el comando clear xlate:
Ciscoasa#clear xlate
Ciscoasa#show xlate 0 in use, 1 most used
El comando clear xlate borra toda la traducción dinámica actual de la tabla xlate. Para borrar una traducción determinada de IP, puede utilizar el comando clear xlate con la palabra clave global [ip address].
A continuación se muestra una configuración de ASA de ejemplo para NAT:
object network inside-net subnet 0.0.0.0 0.0.0.0 object network outside-pat-pool range 10.10.10.10 10.10.10.100 nat (inside,outside) source dynamic inside-net outside-pat-pool
Observe el resultado show xlate para la traducción para la dirección 10.2.2.2 interna a la dirección externa global 10.10.10.10:
Ciscoasa#show xlate 2 in use, 2 most used Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice TCP PAT from inside:10.2.2.2/1429 to any:10.10.10.10/64768 flags ri idle 62:33:57 timeout 0:00:30 TCP PAT from inside:10.5.5.5/1429 to any:10.10.10.11/64768 flags ri idle 62:33:57 timeout 0:00:30
Borre la traducción para la dirección IP global de 10.10.10.10:
Ciscoasa# clear xlate global 10.10.10.10
En este ejemplo, desaparece la traducción para la dirección 10.2.2.2 interna a la dirección externa global 10.10.10.10:
Ciscoasa#show xlate 1 in use, 2 most used Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice TCP PAT from inside:10.5.5.5/1429 to any:10.10.10.11/64768 flags ri idle 62:33:57 timeout 0:00:30
Registros del sistema
Los registros del sistema le permiten resolver problemas en el ASA. Cisco ofrece un servidor syslog gratuito para Windows NT llamado ASA Firewall Syslog Server (PFSS). Puede descargar el PFSS de la página Descargas de Software (sólo clientes registrados).
Otros vendedores, tales como Kiwis Enterprises , ofrecen los servidores de syslog para las diversas plataformas de Windows, como Windows 2000 y Windows XP. 
La mayoría de los equipos UNIX y Linux tienen servidores syslog instalados de forma predeterminada.
Cuando configure el servidor syslog, configure el ASA para enviarle registros.
Por ejemplo:
logging on
logging host <ip_address_of_syslog_server>
logging trap debugging
Si tiene un problema con el funcionamiento lento, abra el syslog en un archivo de texto y busque la dirección IP de origen asociada al problema de funcionamiento. (Si utiliza UNIX, puede buscar cadenas (grep) con el syslog para la dirección IP de origen). Verifique si hay mensajes que indiquen que el servidor externo intentó acceder a la dirección IP interna en el puerto TCP 113 (para el protocolo de identificación o Ident), pero el ASA negó el paquete. El mensaje debe ser similar a este ejemplo:
%ASA-2-106001: Inbound TCP connection denied from 10.64.10.2/35969 to 172.17.110.179/113 flags SYN
Si recibe este mensaje, ejecute el comando service resetinbound al ASA. El ASA no descarta paquetes silenciosamente; en su lugar, este comando hace que el ASA restablezca inmediatamente cualquier conexión entrante denegada por la política de seguridad. El servidor no espera el paquete del Identificador para interrumpir su conexión TCP; en su lugar, recibe inmediatamente un paquete de restablecimiento.
SNMP (Protocolo de administración de red simple)
La supervisión del rendimiento de Cisco ASA mediante SNMP es el método recomendado para las implementaciones empresariales. Cisco ASA admite la supervisión de red con las versiones 1, 2c y 3 de SNMP.
Puede configurar el dispositivo de seguridad para enviar trampas a un servidor de administración de red (NMS) o puede utilizar el NMS para examinar las MIB del dispositivo de seguridad. Las MIB son una colección de definiciones y el dispositivo de seguridad mantiene una base de datos de valores para cada definición. Para obtener más información sobre esto, consulte Configuración de SNMP en Cisco ASA.
Todas las MIBs soportadas para Cisco ASA se pueden encontrar en la Lista de Soporte de MIB ASA . A partir de esta lista, estas MIB son útiles para el monitoreo del rendimiento:
- CISCO-FIREWALL-MIB — Contiene objetos útiles para la conmutación por fallas
- CISCO-PROCESS-MIB: contiene objetos útiles para el uso de la CPU
- CISCO-MEMORY-POOL-MIB: contiene objetos útiles para objetos de memoria.
Búsquedas de DNS inverso
Si experimenta un rendimiento lento con el ASA, verifique que tenga registros de Puntero de sistema de nombres de dominio (DNS PTR), también conocidos como registros de búsqueda de DNS inverso, en el servidor DNS autorizado para las direcciones externas que utiliza el ASA. Esto incluye cualquier dirección en su conjunto de traducción de direcciones de red (NAT) global (o en la interfaz exterior de ASA si sobrecarga la interfaz), cualquier dirección estática y dirección interna (si no utiliza NAT con ellas). Algunas aplicaciones, tales como File Transfer Protocol (FTP ) y servidores Telnet, pueden utilizar las búsquedas de DNS inversas para determinar de dónde proviene el usuario y si es un host válido. Si la búsqueda de DNS inversa no se resuelve, el funcionamiento se degrada ya que se interrumpe la solicitud.
Para asegurarse de que un registro PTR exista para estos hosts, ejecute el comando nslookup de su equipo o máquina UNIX; incluya la dirección IP global que utiliza para conectar con Internet.
Ejemplo:
% nslookup 198.133.219.25 25.219.133.198.in-addr.arpa name = www.cisco.com.
Debe recibir una respuesta con el nombre DNS del dispositivo asignado a esa dirección IP. Si no recibe una respuesta, comuníquese con la persona que controla sus DNS para pedir la adición de registros PTR para cada una de sus direcciones IP globales.
Excesiones en la interfaz
Si tiene una ráfaga de tráfico, los paquetes perdidos pueden ocurrir si la ráfaga excede la capacidad de almacenamiento en búfer del búfer FIFO en el NIC y los búfers de anillo de recepción. La habilitación de tramas de pausa para el control de flujo puede aliviar este problema. Las tramas de pausa (XOFF) y XON son generadas automáticamente por el hardware NIC en función del uso del búfer FIFO. Se envía una trama de pausa cuando el uso del búfer excede la marca de agua alta. Para habilitar las tramas de pausa (XOFF) para el control de flujo, utilice este comando:
hostname(config)#interface tengigabitethernet 1/0 hostname(config-if)# flowcontrol send on
Consulte Habilitación de la Interfaz Física y Configuración de los Parámetros Ethernet para obtener más información.
Comandos show
show cpu usage
El comando show cpu usage se utiliza para determinar la carga de tráfico colocada en la CPU ASA. Durante tráfico máximo, sobrecargas de red o ataques, puede producirse un pico en el uso de CPU.
El ASA tiene una sola CPU para procesar una variedad de tareas; por ejemplo, procesa los paquetes e imprime los mensajes de debug en la consola. Cada proceso tiene su propio propósito, y algunos procesos requieren más tiempo de uso de CPU que otros procesos. El cifrado es probablemente el proceso más intensivo de la CPU, por lo que si su ASA pasa mucho tráfico a través de túneles cifrados, debería considerar un ASA más rápido, un concentrador VPN dedicado, como el VPN 3000. El VAC descarga el cifrado y el descifrado de la CPU ASA y lo realiza en hardware en la tarjeta. Esto permite al ASA cifrar y descifrar 100 Mbps de tráfico con 3DES (cifrado de 168 bits).
Registrarse es otro proceso que puede consumir enormes cantidades de recursos del sistema. Debido a esto, se recomienda inhabilitar el registro de la consola, el monitor y el buffer en el ASA. Puede habilitar estos procesos al resolver un problema, pero debe inhabilitarlos para el funcionamiento diario, especialmente si se queda sin capacidad de CPU. También se sugiere que syslogging o el registro Simple Network Management Protocol (SNMP) (historial de registro) deben configurarse al nivel 5 (Notificación) o inferior. Además, puede inhabilitar las IDs específicas de syslog message con el comando no logging message <syslog_id>.
Cisco Adaptive Security Device Manager (ASDM) también proporciona un gráfico en la ficha Supervisión que permite ver el uso de la CPU del ASA a lo largo del tiempo. Puede utilizar este gráfico para determinar la carga en su ASA.
El comando show cpu usage puede utilizarse para mostrar las estadísticas de uso de la CPU.
Ejemplo:
Ciscoasa#show cpu usage CPU utilization for 5 seconds = 1%; 1 minute: 2%; 5 minutes: 1%
Visualización del Uso de CPU en ASDM
Complete estos pasos para ver el uso de la CPU en el ASDM:
- Vaya a Monitoring > Properties > System Resources Graphics > CPU en ASDM y elija el Título de la ventana de gráficos. A continuación, elija los gráficos requeridos de la lista de Gráficos disponibles y haga clic en Agregar como se muestra.
- Una vez agregado el nombre del gráfico requerido en la sección Gráficos seleccionados, haga clic en Mostrar Gráficos.
La siguiente imagen muestra el gráfico Uso de CPU en el ASDM. Hay disponibles diferentes vistas de este gráfico, que se pueden cambiar seleccionando la vista en la lista desplegable Ver. Esta salida se puede imprimir o guardar en el equipo según sea necesario.
Descripción del Resultado
Esta tabla describe los campos en el resultado de show cpu usage.
| Campo | Descripción |
|---|---|
| Uso de CPU por 5 segundos | Uso de CPU durante los últimos cinco segundos |
| 1 minuto | Promedio de muestras de 5 segundos de utilización de la CPU durante el último minuto |
| 5 minutos | Promedio de muestras de 5 segundos de la utilización de la CPU durante los últimos cinco minutos |
show traffic
El comando show traffic muestra cuánto tráfico pasa a través del ASA durante un período de tiempo determinado. Los resultados se basan en los intervalos de tiempo desde la última vez que se ejecutó el comando.. Para los resultados precisos, ejecute el comando clear traffic primero y en luego espere 1 a 10 minutos antes de ejecutar el comando show traffic. También ejecute el comando show traffic y espere 1 a 10 minutos antes de ejecutar el comando otra vez, pero solamente el resultado de la segunda instancia es válido.
Puede utilizar el comando show traffic para determinar cuánta cantidad de tráfico pasa a través de su ASA. Si tiene interfaces múltiples, el comando puede ayudarlo a determinar qué interfaces envían y reciben la mayoría de los datos. Para los dispositivos ASA con dos interfaces, la suma del tráfico entrante y saliente en la interfaz exterior debe ser igual a la suma del tráfico entrante y saliente en la interfaz interna.
Ejemplo:
Ciscoasa#show traffic
outside:
received (in 124.650 secs):
295468 packets 167218253 bytes
2370 pkts/sec 1341502 bytes/sec
transmitted (in 124.650 secs):
260901 packets 120467981 bytes
2093 pkts/sec 966449 bytes/sec
inside:
received (in 124.650 secs):
261478 packets 120145678 bytes
2097 pkts/sec 963864 bytes/sec
transmitted (in 124.650 secs):
294649 packets 167380042 bytes
2363 pkts/sec 1342800 bytes/sec
Si se aproxima o alcanza el rendimiento nominal en una de sus interfaces, debe actualizar a una interfaz más rápida o limitar la cantidad de tráfico que entra o sale de esa interfaz. Si no lo hace, pueden producirse descartes de paquetes. Como se explica en la sección show interface , puede examinar los contadores de interfaz con el fin de obtener información acerca del rendimiento.
show perform
El comando show perfmon se utiliza para monitorear la cantidad y los tipos de tráfico que el ASA inspecciona. Este comando es la única manera de determinar el número de traducciones (xlates) y de conexiones (conn) por segundo. Las conexiones se vuelven a dividir en conexiones TCP y de protocolo de datagrama de usuario (UDP). Consulte Descripción de Resultados para obtener las descripciones del resultado que este comando genera.
Ejemplo:
PERFMON STATS Current Average Xlates 18/s 19/s Connections 75/s 79/s TCP Conns 44/s 49/s UDP Conns 31/s 30/s URL Access 27/s 30/s URL Server Req 0/s 0/s TCP Fixup 1323/s 1413/s TCPIntercept 0/s 0/s HTTP Fixup 923/s 935/s FTP Fixup 4/s 2/s AAA Authen 0/s 0/s AAA Author 0/s 0/s AAA Account 0/s 0/s
Descripción del Resultado
Esta tabla describe los campos en el resultado show perfmon .
| Campo | Descripción |
|---|---|
| Xlates | Traducciones construidas por segundo |
| Conexiones | Conexiones que se establecen por segundo |
| TCP Conns | Conexiones TCP por segundo |
| UDP Conns | Conexiones UDB por segundo |
| URL Access | URL (sitios web) a los que se accede por segundo |
| URL Server Req | Las solicitudes enviadas a Websense y al N2H2 por segundo (requiere el comando filter) |
| TCP Fixup | Número de paquetes TCP que el ASA reenvía por segundo |
| TCPIntercept | Cantidad de paquetes SYN por segundo que han excedido el límite embrionario establecido en una sentencia estática |
| HTTP Fixup | Cantidad de paquetes destinados al puerto 80 por segundo (requiere el comando fixup protocol http) |
| FTP Fixup | Comandos FTP inspeccionados por segundo |
| AAA Authen | Solicitudes de autenticación por segundo |
| AAA Autor | Pedidos de autorización por segundo |
| AAA Account | Solicitud de cuentas por segundo. |
show blocks
Junto con el comando show cpu usage, puede utilizar el comando show blocks para determinar si el ASA está sobrecargado.
Bloques de procesamiento de paquetes (1550 y 16384 bytes)
Cuando entra en la interfaz ASA, un paquete se coloca en la cola de interfaz de entrada, se pasa al sistema operativo y se coloca en un bloque. Para los paquetes Ethernet, se utilizan los bloques 1550 bytes; si el paquete viene dentro en una tarjeta Gigabit Ethernet de 66 MHz, se utilizan los bloques de 16384 bytes. El ASA determina si el paquete está permitido o denegado en función del algoritmo de seguridad adaptable (ASA) y procesa el paquete a la cola de salida en la interfaz de salida. Si el ASA no admite la carga de tráfico, el número de bloques de 1550 bytes disponibles (o bloques de 16384 bytes para 66 MHz GE) se sitúa cerca de 0 (como se muestra en la columna CNT de la salida del comando). Cuando la columna CNT llega a cero, el ASA intenta asignar más bloques, hasta un máximo de 8192. Si no hay más bloques disponibles, el ASA descarta el paquete.
Bloques de conmutación por fallas y Syslog (256 bytes)
Los bloques de 256 bytes se utilizan principalmente para conmutación por error. El ASA activo genera y envía paquetes al ASA en espera para actualizar la tabla de traducción y conexión. Durante los períodos de tráfico congestionado donde se crean o se desactivan las altas velocidades de conexiones, el número de bloques disponibles de 256 bytes puede llegar a 0. Esta caída indica que una o más conexiones no se actualizan al ASA en espera. Esto es generalmente aceptable porque la próxima vez el protocolo de stateful failover captura la xlate o la conexión que se pierde. Sin embargo, si la columna CNT para bloques de 256 bytes permanece en o cerca de 0 durante periodos prolongados, el ASA no puede estar al día con las tablas de traducción y conexión que se sincronizan debido al número de conexiones por segundo que procesa el ASA. Si esto sucede de forma uniforme, actualice el ASA a un modelo más rápido.
Los mensajes de Syslog enviados desde el ASA también utilizan los bloques de 256 bytes, pero generalmente no se liberan en tal cantidad que causa un agotamiento del conjunto de bloques de 256 bytes. Si la columna CNT muestra que el número de bloques de 256 bytes está cerca de 0, asegúrese de que no registre en el Debugging (nivel 7) al servidor de syslog. Esto es indicado por la línea de trampa de registro en la configuración ASA. Se recomienda que establezca el registro a la Notificación (el nivel 5) o inferior, a menos que requiera la información adicional para los propósitos de debugging.
Ejemplo:
Ciscoasa#show blocks
SIZE MAX LOW CNT
4 1600 1597 1600
80 400 399 400
256 500 495 499
1550 1444 1170 1188
16384 2048 1532 1538
Descripción del Resultado
Esta tabla describe las columnas en el resultado de show blocks.
| Columna | Descripción |
|---|---|
| TAMAÑO | Tamaño E, en bytes, del conjunto de bloques. Cada tamaño representa un tipo determinado |
| MAX | Número máximo de bloques disponibles para el conjunto de bloques de bytes especificado. El número máximo de bloques se extraen de la memoria en el arranque. Típicamente, el número máximo de bloques no cambia. La excepción es para los bloques de 256 y 1550 bytes, donde el dispositivo de seguridad adaptable puede crear dinámicamente más cuando sea necesario, hasta un máximo de 8192. |
| BAJO | Marca de agua baja. Este número indica el menor número de bloques de este tamaño disponibles desde que se encendió el dispositivo de seguridad adaptable, o desde la última limpieza de los bloques (con el comando clear blocks). Un cero en la columna LOW indica un evento anterior donde la memoria estaba llena. |
| CNT | Número actual de bloques disponibles para ese grupo de bloques de tamaño específico. Un cero en la columna CNT significa que la memoria está llena ahora. |
Esta tabla describe los valores de la fila SIZE (TAMAÑO) en el resultado show blocks .
| Valor SIZE (TAMAÑO) | Descripción |
|---|---|
| 0 | Usada por bloques dupb. |
| 4 | Duplica los bloques existentes en aplicaciones como los módulos DNS, ISAKMP, filtrado de URL, uauth, TFTP y TCP. Además, este bloque de tamaño puede ser utilizado normalmente por el código para enviar paquetes a los controladores, etc. |
| 80 | Se utiliza en la intercepción TCP para generar paquetes de reconocimiento y para mensajes hello de conmutación por fallas. |
| 256 | Usado para las actualizaciones de conmutación por error con estado, syslogging y otras funciones de TCP. Estos bloques se utilizan principalmente para los mensajes de conmutación por fallas stateful. El dispositivo de seguridad adaptable activo genera y envía paquetes al dispositivo de seguridad adaptable en espera para actualizar la tabla de traducción y conexión. En el tráfico en ráfaga, donde se crean o desactivan altas tasas de conexiones, el número de bloques disponibles puede caer a 0. Esta situación indica que una o más conexiones no se actualizaron al dispositivo de seguridad adaptable en espera. El protocolo Stateful Failover detecta la traducción o conexión faltante la próxima vez. Si la columna CNT para bloques de 256 bytes permanece en o cerca de 0 durante periodos prolongados, entonces el dispositivo de seguridad adaptable tiene problemas para mantener sincronizadas las tablas de traducción y conexión debido al número de conexiones por segundo que el dispositivo de seguridad adaptable está procesando. Los mensajes de Syslog enviados desde el dispositivo de seguridad adaptable también utilizan los bloques de 256 bytes, pero generalmente no se liberan en tal cantidad para causar un agotamiento del conjunto de bloques de 256 bytes. Si la columna CNT muestra que el número de bloques de 256 bytes está cerca de 0, asegúrese de que no está registrando en Debugging (nivel 7) en el servidor syslog. Esto lo indica la línea de trampa de registro en la configuración del dispositivo de seguridad adaptable. Le recomendamos que establezca el registro en Notification (nivel 5) o inferior, a menos que necesite información adicional para fines de depuración. |
| 1550 | Se utiliza para almacenar paquetes Ethernet para su procesamiento a través del dispositivo de seguridad adaptable. Cuando un paquete ingresa a una interfaz de dispositivo de seguridad adaptable, se coloca en la cola de interfaz de entrada, se pasa al sistema operativo y se coloca en un bloque. El dispositivo de seguridad adaptable determina si se debe permitir o denegar el paquete según la política de seguridad y lo procesa a la cola de salida en la interfaz de salida. Si el dispositivo de seguridad adaptable está teniendo problemas para mantenerse al día con la carga de tráfico, el número de bloques disponibles rondará cerca de 0 (como se muestra en la columna CNT del resultado del comando). Cuando la columna CNT es cero, el dispositivo de seguridad adaptable intenta asignar más bloques, hasta un máximo de 8192. Si no hay más bloques disponibles, el dispositivo de seguridad adaptable descarta el paquete. |
| 16384 | Solo se utiliza para las tarjetas Gigabit Ethernet de 64 bits y 66 MHz (i82543). Consulte la descripción de 1550 para obtener más información sobre los paquetes Ethernet. |
| 2048 | Controlar o guiar las tramas utilizadas para las actualizaciones de control. |
show memory
El comando show memory muestra la memoria física total (o RAM) para el ASA, junto con el número de bytes actualmente disponibles. Para utilizar esta información, primero debe comprender cómo ASA utiliza la memoria. Cuando el ASA se inicia, copia el OS desde Flash a RAM y ejecuta el OS desde la RAM (al igual que los routers). A continuación, ASA copia la configuración de inicio desde Flash y la coloca en RAM. Por último, ASA asigna la RAM para crear los agrupamientos de bloques analizados en la sección show blocks. Una vez completada esta asignación, el ASA sólo necesita RAM adicional si la configuración aumenta su tamaño. Además, ASA almacena las entradas de traducción y conexión en RAM.
Durante el funcionamiento normal, la memoria libre en el ASA debería cambiar muy poco, si es que cambia. Por lo general, la única vez que debe quedarse sin memoria es si está siendo atacado y cientos de miles de conexiones pasan a través del ASA. Para verificar las conexiones, ejecute el comando show conn count, que muestra el número actual y máximo de conexiones a través del ASA. Si el ASA se queda sin memoria, finalmente se desmorona. Antes del desperfecto, es posible que observe mensajes de error de asignación de memoria en el syslog (%ASA-3-211001). Si se queda sin memoria porque el equipo sufre un ataque, comuníquese con el el Centro de Asistencia Técnica de Cisco (TAC).
Ejemplo:
Ciscoasa# show memory Free memory: 845044716 bytes (79%) Used memory: 228697108 bytes (21%) ------------- ---------------- Total memory: 1073741824 bytes (100%)
show xlate
El comando show xlate count muestra el número actual y máximo de traducciones a través del ASA. Una traducción es un mapping de una dirección interna a una dirección externa y puede ser un mapping uno a uno, tal como Traducción de Dirección de Red (NAT), o un mapping de varios a uno, por ejemplo la Traducción de Dirección de Puerto (PAT). Este comando es un subconjunto del comando show xlate, que envía cada traducción a través del ASA. El resultado del comando muestra las traducciones "en uso", que se refiere al número de traducciones activas en el ASA cuando se ejecuta el comando; "más utilizado" se refiere a las traducciones máximas que se han visto en el ASA desde que se encendió.
Ejemplo:
Ciscoasa# show xlate count 84 in use, 218 most used
Ciscoasa(config)#show xlate
3 in use, 3 most used
Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,
o - outside, r - portmap, s - static
TCP PAT from inside:10.1.1.15/1026 to outside:192.150.49.1/1024 flags ri
idle 62:33:57 timeout 0:00:30
UDP PAT from 10.1.1.15/1028 to outside:192.150.49.1/1024 flags ri
idle 62:33:57 timeout 0:00:30
ICMP PAT from inside:10.1.1.15/21505 to outside:192.150.49.1/0 flags ri
idle 62:33:57 timeout 0:00:30
La primera entrada es una Traducción de Dirección del puerto TCP para el puerto de host (10.1.1.15, 1026) en la red interna al puerto de host (192.150.49.1, 1024) en la red externa. El indicador “r” significa que la traducción es una Traducción de Dirección de Puerto. Los indicadores "i" significan que la traducción se aplica a address-port interno.
La segunda entrada es una Traducción de Dirección de Puerto UDP para el puerto de host (10.1.1.15, 1028) en la red interna al puerto de host (192.150.49.1, 1024) en la red externa. El indicador “r” significa que la traducción es una Traducción de Dirección de Puerto. Los indicadores "i" significan que la traducción se aplica a address-port interno.
La tercera entrada es una Traducción de Dirección de Puerto ICMP para host-ICMP-id (10.1.1.15, 21505) en la red interna al host-ICMP-id (192.150.49.1, 0) en la the red externa. El indicador “r” significa que la traducción es una Traducción de Dirección de Puerto. Los indicadores "i" significan que la traducción se aplica a la address-ICMP-id interna.
Los campos de la dirección interna aparecen como direcciones de origen en los paquetes que atraviesan la interfaz más segura a la interfaz menos segura. Inversamente, aparecen como la dirección de destino en los paquetes que atraviesan la interfaz menos segura a la interfaz más segura.
show conn count
El comando show conn count muestra el número actual y máximo de conexiones a través del ASA. Una conexión es una asignación de información de Capa 4 desde una dirección interna a una dirección externa. Las conexiones se acumulan cuando el ASA recibe un paquete SYN para sesiones TCP o cuando llega el primer paquete en una sesión UDP. Las conexiones se desactivan cuando el ASA recibe el paquete ACK final, que ocurre cuando se cierra el intercambio de señales de sesión TCP o cuando el tiempo de espera caduca en la sesión UDP.
Los recuentos de conexiones extremadamente altos (50-100 veces normales) podrían indicar que está siendo atacado. Ejecute el comando show memory para asegurarse de que el conteo de conexión alta no haga que el ASA se quede sin memoria. Si está siendo atacado, puede establecer un número máximo de conexiones por entrada estática, y también poner un límite al número de conexiones embrionarias. Esta acción protege sus servidores internos para que no se saturen. Refiérase a Referencias de Comandos de Cisco ASA 5500 Series Adaptive Security Appliances para obtener más información.
Ejemplo:
Ciscoasa#show conn count 2289 in use, 44729 most used
show interface
El comando show interface puede ayudar a determinar los problemas de discordancia dúplex y los problemas de cable. También puede comprender mejor si la interfaz está desbordada o no. Si el ASA se queda sin capacidad de CPU, el número de bloques de 1550 bytes se sitúa cerca de 0. (Observe los bloques de 16384 bytes en las tarjetas Gig de 66 MHz). Otro indicador es el aumento de "no hay suficiente buffers" en la interfaz. El mensaje no buffers indica que la interfaz no puede enviar el paquete al sistema operativo ASA porque no hay ningún bloque disponible para el paquete y el paquete se descarta. Si se produce un aumento en los niveles sin buffer regularmente, ejecute el comando show proc cpu para verificar el uso de la CPU en el ASA. Si el uso de la CPU es alto debido a una carga de tráfico pesada, actualice a un ASA más potente que pueda manejar la carga.
Cuando un paquete ingresa primero en una interfaz, se ubica en la cola de hardware de entrada. Si la cola de hardware de entrada está completa, el paquete se coloca en la cola de software de entrada. El paquete se pasa de su cola de entrada y se coloca en un bloque de 1550 bytes (o en un bloque de 16384 bytes en interfaces Gigabit Ethernet de 66 MHz). El ASA luego determina la interfaz de salida para el paquete y coloca el paquete en la cola de hardware apropiada. Si la cola de hardware está llena, el paquete se coloca en la cola de software de salida. Si los bloques máximos en cualquiera de las colas del software son grandes, la interfaz se desborda. Por ejemplo, si 200 Mbps entran en el ASA y todos salen de una única interfaz de 100 Mbps, la cola de software de salida indica números altos en la interfaz de salida, lo que indica que la interfaz no puede manejar el volumen de tráfico. Si experimenta esta situación, actualice a una interfaz más rápida.
Ejemplo:
Ciscoasa#show interface
Interface GigabitEthernet0/1 "inside", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
Input flow control is unsupported, output flow control is unsupported
MAC address 0013.c480.b2b8, MTU 1500
IP address 192.168.17.4, subnet mask 255.255.255.0
311981 packets input, 20497296 bytes, 0 no buffer
Received 311981 broadcasts, 157 runts, 0 giants
379 input errors, 107 CRC, 273 frame, 0 overrun, 0 ignored, 0 abort
0 pause input, 0 resume input
0 L2 decode drops
121 packets output, 7744 bytes, 0 underruns
0 pause output, 0 resume output
0 output errors, 0 collisions, 1 interface resets
0 late collisions, 0 deferred
0 input reset drops, 0 output reset drops, 0 tx hangs
input queue (blocks free curr/low): hardware (255/249)
output queue (blocks free curr/low): hardware (255/254)
También debe controlar si hay errores en la interfaz. Si recibe los recuentos ignorados, los errores de entrada, los CRC, o los errores de trama, es probable que tenga una discordancia dúplex. El cable también podría ser defectuoso. Consulte las configuraciones de la velocidad y el dúplex para obtener más información sobre los problemas de dúplex. Recuerde que cada contador de errores representa el número de paquetes que se caen debido a ese error particular. Si ve un contador específico que aumenta regularmente, es muy probable que el rendimiento de su ASA se vea afectado y debe encontrar la causa principal del problema.
Mientras examina los contadores de la interfaz, observe que si la interfaz se configura en dúplex completo, no debe experimentar colisiones, colisiones tardías ni paquetes postergados. Por el contrario, si la interfaz se configura en semidúplex, debe recibir las colisiones, algunas colisiones tardías y posiblemente algunos paquetes postergados. El número total de colisiones, colisiones tardías y paquetes postergados no debe exceder del 10% de la suma de los contadores de paquetes de entrada y de salida. Si sus colisiones exceden el 10% de su tráfico total, entonces el link presenta una utilización excesiva y debe actualizar a dúplex completo o a una velocidad más rápida (10 Mbps a 100 Mbps). Recuerde que las colisiones del 10% significan que el ASA descarta el 10% de los paquetes que pasan por esa interfaz; cada uno de estos paquetes deberá retransmitirse.
Refiérase al comando interface en las Referencias de Comandos de Dispositivos de Seguridad Adaptables Cisco ASA 5500 Series para obtener información detallada sobre los contadores de la interfaz.
show processes
El comando show processes en el ASA muestra todos los procesos activos que se ejecutan en el ASA en el momento en que se ejecuta el comando. Esta información es útil para determinar qué procesos reciben demasiado tiempo de uso de CPU y qué procesos no reciben nada de tiempo de uso de CPU. Para conseguir esta información, ejecute el comando show processes dos veces; espere cerca de 1 minuto entre cada vez. Para el proceso en cuestión, reste el valor del tiempo de ejecución visualizado en el segundo resultado del valor del tiempo de ejecución visualizado en el primer resultado. Este resultado muestra el tiempo de CPU (en milisegundos) que el proceso recibió en ese intervalo de tiempo. Observe que algunos procesos están programados para ejecutarse en intervalos determinados, y algunos procesos se ejecutan solamente cuando tienen información para procesar. El proceso 577poll probablemente tenga el valor del tiempo de ejecución más grande de todos sus procesos. Esto es normal porque el proceso 577poll sondea las interfaces de Ethernet para considerar si tienen algunos datos que deben ser procesados.
Resumen de Comandos
En resumen, utilice el comando show cpu usage para identificar la carga en la que se encuentra ASA. Recuerde que el resultado es un promedio del funcionamiento; el ASA puede tener picos más altos de uso de CPU que se enmascaran por el promedio en ejecución. Una vez que ASA alcanza el 80% de uso de la CPU, la latencia a través del ASA aumenta lentamente hasta alcanzar aproximadamente el 90% de la CPU. Cuando el uso de la CPU es superior al 90%, el ASA comienza a descartar paquetes.
Si el uso de CPU es alto, use el comando show processes para identificar los procesos que utilizan el mayor tiempo de CPU posible. Utilice esta información para reducir parte del tiempo que consumen los procesos intensivos (como el registro).
Si la CPU no se ejecuta en caliente, pero usted cree que los paquetes aún se descartan, utilice el comando show interface para verificar la interfaz ASA sin buffers ni colisiones, posiblemente causados por una discordancia dúplex. Si el conteo del no buffer aumenta, pero el uso de la CPU no es bajo, la interfaz no puede soportar el tráfico que la atraviesa.
Si las memorias intermedias están bien, verifique los bloques. Si la columna CNT actual en la salida show blocks está cerca de 0 en los bloques de 1550 bytes (bloques de 16384 bytes para las tarjetas Gig de 66 MHz), el ASA descarta probablemente los paquetes Ethernet porque está demasiado ocupado. En este caso, el CPU llega a un pico.
Si experimenta problemas cuando realiza nuevas conexiones a través del ASA, utilice el comando show conn count para verificar el conteo actual de conexiones a través del ASA.
Si el conteo actual es alto, verifique el resultado show memory para asegurarse de que el ASA no se quede sin memoria. Si la memoria es baja, investigue la fuente de las conexiones con el comando show conn o el comando show local-host para verificar que su red no ha experimentado un ataque de negación de servicio.
Puede utilizar otros comandos para medir la cantidad de tráfico que pasa a través del ASA. El comando show traffic muestra los paquetes agregados y los bytes por interfaz, y el show perfmon divide el tráfico en diferentes tipos que el ASA inspecciona.
Información Relacionada
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)