Seguridad : Dispositivos de seguridad Cisco PIX de la serie 500

PIX/ASA: Problemas de rendimiento del monitor y del Troubleshooting

25 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Abril 2015) | Comentarios


Contenido


Introducción

Este documento describe los comandos PIX/ASA que puede utilizar para monitorear y para resolver problemas con el funcionamiento de Cisco PIX 500 Series/ASA 5500 Security Appliance.

Nota: Refiera a ASA 8.3 y posterior: Monitoree y resolver problemas los problemas de rendimiento para el troubleshooting similar en el dispositivo de seguridad adaptante de Cisco (ASA) con la versión 8.3 y posterior.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

La información en este documento se basa en Cisco PIX Firewall Software Versión 6.2(1) y posterior.

Nota: La información en este documento también se puede utilizar con Cisco ASA 5500 Series Security Appliance que ejecuta 7.x y versión posterior.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

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

Troubleshooting

Para resolver problemas de funcionamiento, verifique las áreas básicas descritas en esta sección.

Nota: Si tiene el resultado del comando show de su dispositivo de Cisco, puede utilizar la Herramienta Output Interpreter (sólo clientes registrados) para ver los problemas y las soluciones posibles. La Herramienta Output Interpreter soporta ciertos comandos show. Si utiliza la Herramienta Output Interpreter, debe ser un cliente registrado, debe haber iniciado sesión en su cuenta de Cisco, y debe tener Javascript habilitado en su navegador.

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. Puesto que el dúplex debe ser negociado, el dispositivo que se configura para autonegociar no puede determinar las configuraciones en el otro dispositivo, por lo que se vuelve semidúplex de forma predeterminada, como se afirma en el estándar IEEE 802.3u.

Por ejemplo, si configura la interfaz PIX para la autonegociación y la conecta con un switch codificado para dúplex de 100 Mbps y de modo completo, el PIX envía los FLPs. Sin embargo, el switch no responde porque es codificado para la velocidad y el dúplex y no participa en la autonegociación. Como no recibe ninguna respuesta del switch, el PIX cambia al modo paralelo de detección y detecta la longitud de los pulsos en las tramas que el switch envía. Es decir, el PIX 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 los FLP, el PIX no puede detectar si el switch puede funcionar con el dúplex completo, así que el PIX configura el dúplex de la interfaz a semidúplex, como se afirma en el estándar IEEE 803.2u. Puesto que el switch es codificado a 100 Mbps y a dúplex completo, y el PIX acaba de autonegociarse a 100 Mbps y semidúplex (como debe), el resultado es una discordancia dúplex que puede causar problemas graves de funcionamiento.

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 ethernet0 "outside" is up, line protocol is up
  Hardware is i82559 ethernet, address is 00d0.b78f.d579
  IP address 192.168.1.1, subnet mask 255.255.255.0
  MTU 1500 bytes, BW 100000 Kbit half duplex
        7594 packets input, 2683406 bytes, 0 no buffer
        Received 83 broadcasts, 153 runts, 0 giants
        378 input errors, 106 CRC, 272 frame, 0 overrun, 0 ignored, 0 abort
        2997 packets output, 817123 bytes, 0 underruns
        0 output errors, 251 collisions, 0 interface resets
        0 babbles, 150 late collisions, 110 deferred

Uso de CPU

Si observó que el uso de CPU es alto, siga los siguientes pasos para resolver problemas:

  1. Verifique que el recuento de conexiones en el conteo show xlate sea bajo.

  2. Verifique que el bloque de memoria sea normal.

  3. Verifique que el número de ACL sea más alto.

  4. Publique el comando show memory detail , y verifique que la memoria utilizada por el PIX sea de uso normal.

  5. Verifique que los conteos en show processes cpu-hog y show processes memory sean normales.

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

  7. Verifique las configuraciones de dúplex y de velocidad en las interfaces PIX. 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:

    pix#show int e1 
    interface ethernet1 "inside" is up, line protocol is up
      Hardware is i82559 ethernet, address is 0050.54ff.d053
      IP address 172.16.1.5, subnet mask 255.255.255.0
      MTU 1500 bytes, BW 100000 Kbit full duplex
            154755357 packets input, 3132291269 bytes, 0 no buffer
            Received 5352738 broadcasts, 0 runts, 0 giants
            7182 input errors, 0 CRC, 0 frame, 7182 overrun, 0 ignored, 0 abort
            2595913856 packets output, 3842928626 bytes, 0 underruns
            0 output errors, 0 collisions, 0 interface resets
            0 babbles, 0 late collisions, 0 deferred
    

    Para resolver este problema, configure la velocidad como automática a la interfaz correspondiente.

    Nota: Cisco recomienda que habilite el comando ip verify reverse-path interface en todas las interfaces ya que descartará paquetes que no tienen una dirección de origen válida y, por lo tanto, reduce el uso de la CPU. Esto se aplica al FWSM que hace frente CPU elevada a los problemas.

  8. Otro motivo del uso de CPU elevado puede ser la existencia de demasiadas rutas multicast. Ejecute el comando show mroute para verificar si PIX/ASA recibe demasiadas rutas multicast.

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

    Nota: CPU elevada la actividad pudo ocurrir debido al problema descrito en CPU elevada cuando el nameif/nivel de seguridad cambió para la nueva interfaz (clientes registrados solamente). Refiera al Id. de bug Cisco CSCsq48636 (clientes registrados solamente) para más información.

Nota: Si la solución proporcionó arriba no resuelve el problema, actualiza la plataforma ASA según los requisitos. Refiera a la hoja de datos del Dispositivos de seguridad adaptable Cisco ASA de la serie 5500 para más información sobre las capacidades y las capacidades adaptantes de la plataforma del dispositivo de seguridad. Entre en contacto TAC (clientes registrados solamente) para 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: Los puertos de bloqueo en la interfaz externa de un dispositivo de seguridad hacen que el dispositivo de seguridad consuma gran cantidad de memoria para bloquear los paquetes a través de los puertos especificados. Para resolver este problema, bloquee el tráfico defectuoso en el extremo de ISP.

  • Amenaza-detección: 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 del puerto predeterminado no son deseables cuando un PIX se conecta en el 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 PIX con un switch que ejecuta 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.

Nota: En los Catalyst XL Series Switches, la canalización no se configura en Automática de forma predeterminada. Por este motivo, debe inhabilitar la canalización en cualquier puerto del switch que conecte con un PIX.

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 conecte con un PIX.

Nota: Catalyst OS releases 5.4 y posterior incluyen el comando set port host <mod>/<port> que le permite utilizar un solo comando para inhabilitar la canalización, inhabilitar trunking, y habilitar PortFast.

traducción de Dirección de Red (NAT)

Todas las sesiones que se conectan a través del dispositivo de seguridad deben experimentar una cierta forma de traducción de dirección de red, o 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.

Nota: Siempre borre las xlates después de agregar, cambiar, o quitar los comandos aaa-server, access-list, alias, global, nat, route, o los comandos static en su configuración.

precaución Precaución: Una interrupción momentánea del flujo de todo el tráfico a través del dispositivo puede producirse cuando borra las xlates de forma global en el dispositivo de seguridad.

Ejemplo de la configuración PIX para PAT que utiliza la dirección IP de la interfaz externa:

global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0

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:

pix#show xlate
1 in use, 1 most used
PAT Global 192.168.1.2(1) Local 10.2.2.2 ICMP id 21
pix#show xlate detail
1 in use, 1 most used
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
       r - portmap, s - static
ICMP PAT from inside:10.2.2.2/22 to outside:192.168.1.2/2 flags ri

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:

pix#clear xlate
pix#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].

El siguiente es un ejemplo de la configuración PIX para NAT:

global (outside) 1 10.10.10.10-10.10.10.100
nat (inside) 1 0.0.0.0 0.0.0.0

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:

pixfirewall#show xlate detail
2 in use, 2 most used
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
       r - portmap, s - static
NAT from inside:10.2.2.2 to outside:10.10.10.10 flags i
NAT from inside:10.5.5.5 to outside:10.10.10.11 flags i

Borre la traducción para la dirección IP global de 10.10.10.10:

pixfirewall# 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:

pixfirewall#show xlate detail
1 in use, 2 most used
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
       r - portmap, s - static
NAT from inside:10.5.5.5 to outside:10.10.10.11 flags i

Cuando borra las ranuras de traducción, asegúrese de tener en cuenta los diversos tipos de traducciones:

  • Una xlate estática es una xlate persistente que se crea con el comando static. Para quitar las xlates estáticas, debe quitar el comando static de la configuración. El comando clear xlate no quita la regla de traducción estática. Si quita un comando static de la configuración, las conexiones preexistentes que utilizan la regla estática aún pueden reenviar tráfico. Utilice el comando clear local-host para desactivar estas conexiones.

  • Una xlate dinámica es una xlate que se crea a pedido con el procesamiento del tráfico (a través del comando nat o global). El comando clear xlate quita las xlates dinámicas y sus conexiones asociadas. Si quita un comando nat o un comando global de la configuración, la xlate dinámica y las conexiones asociadas posiblemente permanezcan activas.

Registros del sistema

Los syslogs le permiten resolver problemas en el PIX. Cisco ofrece un servidor de syslog libre para Windows NT llamado PIX 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.leavingcisco.com La mayoría de los equipos UNIX y Linux tienen servidores syslog instalados de forma predeterminada.

Cuando configura el servidor syslog, configure el PIX para enviar los registros.

Por ejemplo:

logging on
logging host <ip_address_of_syslog_server>
logging trap debugging

Nota: Este ejemplo configura el PIX para enviar el Debugging (nivel 7) y más syslogs críticos al servidor de syslog. Puesto que estos registros PIX son los más detallados, utilícelos solamente para resolver un problema. Para obtener un funcionamiento normal, configure el nivel de registro a Advertencia (nivel 4) o Error (nivel 3).

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 Identificador), pero el PIX rechazó el paquete. El mensaje debe ser similar a este ejemplo:

%PIX-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 reset inbound al PIX. El PIX no descarta paquetes silenciosamente; en lugar, este comando hace que el PIX restablezca inmediatamente cualquier conexión de entrada que sea negada 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. Consulte los Problemas de Funcionamiento de PIX causados por el Protocolo IDENT para obtener más información sobre el PIX y la Identificación.

Búsquedas de DNS inverso

Si experimenta un funcionamiento lento con el PIX, verifique que tiene registros del Puntero de Sistema de Nombres de Dominio (DNS PTR), también conocidos como registros de Búsqueda Inversa de DNS, en el servidor DNS autorizado para las direcciones externas que usa el PIX. Esto incluye cualquier dirección en su conjunto de Traducción de Dirección de Red global (NAT) (o la interfaz exterior PIX si realiza una sobrecarga en la interfaz), cualquier dirección estática y dirección interna (si no utiliza la 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. Consulte Funcionamiento Deficiente o Intermitente FTP/HTTP con un PIX para obtener más información sobre los problemas de funcionamiento en el PIX causados por los registros PTR que se pierden.

Sobrantes en la interfaz

Si usted tiene una ráfaga de tráfico, los paquetes perdidos pueden ocurrir si la explosión excede la capacidad que mitiga de la memoria intermedia primero en entrar, primero en salir en el NIC y los buffers del anillo de recepción. Habilitar las tramas de pausa para el control de flujo puede paliar este problema. La pausa (XOFF) y las tramas XON son generadas automáticamente por el hardware NIC basado en el uso de la memoria intermedia primero en entrar, primero en salir. Se envía una trama de pausa cuando el uso de búfer excede la marca de alta. Para habilitar las tramas de la pausa (XOFF) para el control de flujo, utilice el siguiente comando:

hostname(config)#interface tengigabitethernet 1/0
hostname(config-if)# flowcontrol send on

Refiera a habilitar la interfaz física y a configurar los parámetros de los Ethernetes para más información.

Comandos show

show cpu usage

El comando show cpu usage se introdujo por primera vez en PIX 6.0(1) y se usa para determinar la carga de tráfico que soporta la PIX CPU. Durante tráfico máximo, sobrecargas de red o ataques, puede producirse un pico en el uso de CPU.

El PIX tiene una CPU única 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. La encripción probablemente sea el proceso que exige un uso de CPU más extensivo, por lo que si su PIX pasa mucho tráfico a través de los túneles encriptados, debe considerar un PIX más rápido, una Tarjeta Aceleradora de VPN (VAC) [Part # PIX-VPN-ACCEL] para el PIX, o un VPN Concentrator dedicado, tal como el VPN3000. El VAC descarga la encripción y el descifrado desde la PIX CPU y lo hace en hardware en la tarjeta. Esto permite que el PIX cifre y descifre 100 Mbps del tráfico con 3DES (encripción de 168 bits).

Registrarse es otro proceso que puede consumir enormes cantidades de recursos del sistema. Debido a esto, se recomienda que inhabilite la consola, el monitor, y el buffer al iniciar sesión en el PIX. 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>.

El Administrador del Dispositivo PIX (PDM) también proporciona un gráfico en la pestaña Monitoring que le permite ver el uso de CPU del PIX a través del tiempo. Puede utilizar este gráfico para determinar la carga en su PIX.

El comando show cpu usage puede utilizarse para mostrar las estadísticas de uso de la CPU.

Ejemplo:

pixfirewall#show cpu usage

CPU utilization for 5 seconds = 1%; 1 minute: 2%; 5 minutes: 1%

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 la cantidad de tráfico que pasa a través del PIX 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ánto tráfico pasa por su PIX. 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 PIX con dos interfaces, la suma del tráfico entrante y saliente en la interfaz externa debe igualar la suma del tráfico entrante y saliente en la interfaz interna.

Ejemplo:

pixfirewall#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 usa para monitorear la cantidad y los tipos de tráfico que el PIX examina. 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 en 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 Cantidad de paquetes TCP que el PIX 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 PIX está sobrecargado.

Bloques de procesamiento de paquetes (1550 y 16384 bytes)

Cuando entra en la interfaz PIX, un paquete se coloca en la cola de la interfaz de entrada, se pasa hasta el OS, 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 PIX determina si el paquete es autorizado o es rechazado 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 PIX no puede soportar la carga de tráfico, el número de bloques de 1550 bytes disponible (o los bloques 16384-byte para 66 MHz GE) se aproxima a 0 (tal como se muestra en la columna CNT del resultado de comando). Cuando la columna CNT alcanza el valor cero, el PIX intenta asignar más bloques, hasta un máximo de 8192. Si no se encuentran disponibles más bloques, el PIX pierde el paquete.

Bloques de conmutación por error y Syslog (256 bytes)

Los bloques de 256 bytes se utilizan principalmente para conmutación por error. El PIX activo genera y envía los paquetes al PIX en espera para actualizar la traducción y la tabla de conexiones. 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. Este descenso indica que una o más conexiones no están actualizadas al PIX 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 los bloques de 256 bytes permanece en 0 o cerca de éste durante períodos extendidos, el PIX no puede continuar con la traducción y las tablas de conexiones que se sincronizan debido al número de conexiones por segundo que el PIX procesa. Si sucede esto constantemente, actualice el PIX a un modelo más rápido.

Los mensajes de syslog enviados del PIX también utilizan los bloques de 256 bytes, pero no se liberan generalmente en tal cantidad como 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 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 PIX. 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:

pixfirewall#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 El tamaño, en bytes, del conjunto de bloques.
MÁX El número máximo de bloques disponibles para el conjunto de bloques especificado en bytes. Observe que la cantidad máxima de bloques son extraídos de la memoria durante el inicio. Típicamente, el número máximo de bloques no cambia. La anomalía es para los bloques de 256 bytes y 1550 bytes, donde el PIX puede crear dinámicamente más cuando lo necesita, hasta un máximo de 8192.
BAJO Marca de agua inferior. Este valor es el número más bajo de bloques de este tamaño disponibles desde que el PIX fue conectado, o desde la última vez que los bloques fueron borrados con el comando clear blocks.
CNT La cantidad actual de bloques disponibles para ese agrupamiento de bloques de tamaño específico.

Esta tabla describe los valores de la fila SIZE (TAMAÑO) en el resultado show blocks .

Valor SIZE (TAMAÑO) Descripción
4 Se usa para duplicar los bloques que existen en los DNS, el Internet Security Association and Key Management Protocol (ISAKMP), el filtrado URL, uauth, h323, tftp, y los módulos TCP.
80 Se usa en la Intercepción de TCP para generar los paquetes de reconocimiento (ACK) y para los mensajes hello de failover.
256 Se usa para las actualizaciones de stateful failover, syslogging, y otras funciones TCP.
1550 Se usa para almacenar los paquetes Ethernet que se procesan con el PIX.
16384 Se usa para las tarjetas Gigabit Ethernet de 64 bits y 66 MHz solamente (i82543) en el PIX 535.

show memory

El comando show memory visualiza la memoria física total (o RAM) para el PIX, junto con la cantidad de bytes actualmente disponible. Para utilizar esta información, primero debe comprender cómo el PIX utiliza la memoria. Cuando el PIX se inicia, copia el OS de la Flash a la RAM y ejecuta el OS de la RAM (como los routers). Luego, el PIX copia la configuración de inicio de la Flash y la coloca en la RAM. Finalmente, el PIX asigna la RAM para crear los conjuntos de bloques analizados en la sección show blocks . Una vez que esta asignación se completa, el PIX necesita RAM adicional solamente si la configuración aumenta de tamaño. Además, el PIX almacena las entradas de conexión y traducción en RAM.

Durante el funcionamiento normal, la memoria libre en el PIX debe cambiar muy poco, o permanecer igual. Típicamente, la única vez que experimentaría memoria baja es si el equipo sufre un ataque y cientos de miles de conexiones pasan a través del PIX. Para verificar las conexiones, ejecute el comando show conn count, que visualiza la cantidad actual y máxima de conexiones a través del PIX. Si el PIX se queda sin memoria, a la larga se bloqueará. Antes del bloqueo, probablemente observe mensajes de conmutación por error de la asignación de memoria en el syslog (PIX-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).

Nota: Cuando Cisco ASA se ejecuta de la memoria, valida no más las nuevas conexiones VPN, cae todas las conexiones existentes, y vuelve este error del mensaje de error: %ASA-3-336003: Ningunos buffers disponibles para el paquete de bytes del <bytes>.

Nota: Utilice el comando del mem de la demostración para verificar la asignación de los recursos de memoria y actualizar la memoria si procede. Si persiste el problema, entre en contacto el TAC de Cisco para el troubleshooting adicional.

Ejemplo:

pixfirewall#show memory
1073741824 bytes total, 1022992384 bytes free

show xlate

El comando show del xlate count muestra el número máximo actual de traducciones con el PIX. 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 subgrupo del comando show xlate, que envía cada traducción a través de PIX. La salida de comando muestra las traducciones “funcionando,” que se refiere al número de traducciones activas en el PIX cuando se publica el comando; “más usado” se refiere a las traducciones máximas que se han visto en el PIX desde que fue encendido.

Nota: Un solo host puede tener múltiples conexiones a varios destinos, pero solamente una traducción. Si la cuenta de xlate es mucho más grande que el número de hosts en su red interna, es posible que uno de sus hosts internos se vea comprometido. Si se ha comprometido su host interno, simula la dirección de origen y envía los paquetes fuera del PIX.

Nota: Cuando se habilita la configuración vpnclient y el host interior envía las solicitudes DNS, el comando show xlate puede enumerar xlates múltiples para una traducción estática.

Ejemplo:

pixfirewall#show xlate count
84 in use, 218 most used

Este ejemplo muestra el resultado del comando show xlate detail con tres Traducciones de la Dirección de Puerto activas (PATs):

pixfirewall(config)#show xlate detail

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

UDP PAT from inside:10.1.1.15/1028 to outside:192.150.49.1/1024 flags ri

ICMP PAT from inside:10.1.1.15/21505 to outside:192.150.49.1/0 flags ri

La primera entrada es una traducción de la 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 la cantidad actual y la cantidad máxima de conexiones a través del PIX. 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 establecen cuando el PIX recibe un paquete SYN para las sesiones TCP o cuando llega el primer paquete en una sesión UDP. Las conexiones se desactivan cuando el PIX recibe el paquete ACK final, que se produce cuando el contacto por sesión TCP se cierra o cuando expira el tiempo de espera en la sesión UDP.

Los recuentos de conexión extremadamente altos (50 a 100 veces los valores normales) pueden ser un indicador de ataque. Ejecute el comando show memory para asegurarse de que el conteo de conexiones alto no haga que el PIX 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. Consulte Referencias del Comando Cisco Secure PIX Firewall para obtener más información.

Ejemplo:

pixfirewall#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 con el cable; también puede comprender mejor si la interfaz está desbordada o no. Si el PIX se queda sin capacidad de CPU, el número de bloques de 1550 bytes se acerca a 0. (Consulte 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 de ningún buffer indica que la interfaz no puede enviar el paquete al PIX OS porque no hay bloque disponible para el paquete, y éste se pierde. Si no se produce un aumento en los niveles de ningún buffer regularmente, ejecute el comando show proc cpu para verificar el uso de la CPU en el PIX. Si el uso de la CPU es alto debido a una carga de tráfico intensa, actualice a un PIX 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 es pasado desde su cola de entrada hasta el PIX OS y colocado en un bloque 1550-byte (o en un bloque 16384-byte en las interfaces Ethernet Gigabit 66 MHz). El PIX luego determina la interfaz de salida para el paquete y ubica 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 PIX y todo sale de una sola interfaz de 100 Mbps, la cola del software de salida indica los números altos en la interfaz de salida, lo que sugiere 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:

pixfirewall#show interface
interface ethernet0 "inside" is up, line protocol is up
  Hardware is i82559 ethernet, address is 0002.b31b.99ff
  IP address 9.9.9.1, subnet mask 255.255.255.0
  MTU 1500 bytes, BW 100000 Kbit full duplex
        4630 packets input, 803174 bytes, 0 no buffer
        Received 2 broadcasts, 0 runts, 0 giants
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        4535 packets output, 445424 bytes, 0 underruns
        0 output errors, 0 collisions, 0 interface resets
        0 babbles, 0 late collisions, 0 deferred
        0 lost carrier, 0 no carrier
        input queue (curr/max blocks): hardware (128/128) software (0/1)
        output queue (curr/max blocks): hardware (0/2) software (0/1)

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 estar 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 observa que un contador específico se incrementa regularmente, es muy probable que el rendimiento de su PIX se vea afectado , y debe encontrar la causa raíz 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 de 10% significan que el PIX pierde 10% de los paquetes que pasan a través de esa interfaz; cada uno de estos paquetes deberá retransmitirse.

Consulte el comando interface en las Referencias de Comandos de Secure PIX firewall para obtener información detallada sobre los contadores de la interfaz.

show processes

El comando show processes en el PIX visualiza todos los procesos activos que se ejecutan en el PIX al mismo tiempo 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 le indica cuánto tiempo de uso de CPU (en milisegundos) recibió el proceso 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.

Nota: El examen de cada proceso PIX no se incluye en este documento, pero se menciona en forma breve para completarlo. Consulte el comando show processes PIX para obtener más información sobre los procesos PIX.

Resumen de Comandos

En resumen, utilice el comando show cpu usage para identificar la carga que soporta el PIX. Recuerde que el resultado es un promedio del funcionamiento; el PIX puede tener puntos más altos de uso de CPU que son enmascarados por el promedio del funcionamiento. Una vez que el PIX alcanza un uso de CPU del 80%, el tiempo de espera con el PIX aumenta lentamente a cerca de 90% de CPU. Cuando el uso de CPU es mayor que el 90%, el PIX comienza a perder los 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 algo del tiempo que es consumido por los procesos intensivos (como el registro).

Si la CPU no se sobrecaliente, pero cree que los paquetes todavía están perdidos, utilice el comando show interface para verificar que la interfaz PIX no tenga buffers ni colisiones, posiblemente provocados 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 el resultado show blocks se aproxima a 0 en los bloques de 1550 bytes (bloques de 16384 bytes para tarjetas MHz Gig), el PIX posiblemente pierda paquetes Ethernet porque está muy ocupado. En este caso, el CPU llega a un pico.

Si experimenta problemas cuando establece nuevas conexiones con el PIX, utilice el comando show conn count para verificar el conteo actual de conexiones con el PIX.

Si la cuenta actual es alta, verifique el resultado show memory para asegurarse de que el PIX 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 por el PIX. El comando show traffic muestra los bytes y paquetes agregados por interfaz, y el show perfmon divide al tráfico en diferentes tipos que inspecciona el PIX.

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.


Información Relacionada


Document ID: 22040