Encontrar la pérdida de paquetes de firewall transparente

Utilizamos el Cisco ASA 5585 en un modo transparente de capa 2. La configuración son solo dos enlaces 10GE entre nuestro socio comercial dmz y nuestra red interna. Un mapa simple se ve así.

10.4.2.9/30                    10.4.2.10/30
core01-----------ASA1----------dmzsw

El ASA tiene 8.2 (4) y SSP20. Los interruptores son 6500 Sup2T con 12.2. ¡No hay caídas de paquetes en ningún conmutador o interfaz ASA! Nuestro tráfico máximo es de aproximadamente 1.8 Gbps entre los conmutadores y la carga de la CPU en el ASA es muy baja.

Tenemos un problema extraño Nuestro administrador de nms ve una pérdida de paquetes muy mala que comenzó en algún momento de junio. La pérdida de paquetes está creciendo muy rápido, pero no sabemos por qué. El tráfico a través del firewall se ha mantenido constante, pero la pérdida de paquetes está creciendo rápidamente. Estas son las fallas de ping de nagios que vemos a través del firewall. Nagios envía 10 pings a cada servidor. Algunas de las fallas pierden todos los pings, no todas las fallas pierden los diez pings.

ingrese la descripción de la imagen aquí

Lo extraño es que si usamos mtr desde el servidor nagios, la pérdida de paquetes no es muy mala.

                             My traceroute  [v0.75]
nagios    (0.0.0.0)                                    Fri Jul 19 03:43:38 2013
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                  Packets               Pings
 Host                           Loss%   Snt Drop   Last  Best   Avg  Wrst StDev
 1. 10.4.61.1                    0.0%  1246    0    0.4   0.3   0.3  19.7   1.2
 2. 10.4.62.109                  0.0%  1246    0    0.2   0.2   0.2   4.0   0.4
 3. 10.4.62.105                  0.0%  1246    0    0.4   0.4   0.4   3.6   0.4
 4. 10.4.62.37                   0.0%  1246    0    0.5   0.4   0.7  11.2   1.7
 5. 10.4.2.9                     1.3%  1246   16    0.8   0.5   2.1  64.8   7.9
 6. 10.4.2.10                    1.4%  1246   17    0.9   0.5   3.5 102.4  11.2
 7. dmz-server                   1.1%  1246   13    0.6   0.5   0.6   1.6   0.2

Cuando hacemos ping entre los conmutadores, no perdemos muchos paquetes, pero es obvio que el problema comienza en algún lugar entre los conmutadores.

core01#ping ip 10.4.2.10 repeat 500000

Type escape sequence to abort.
Sending 500000, 100-byte ICMP Echos to 10.4.2.10, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (499993/500000), round-trip min/avg/max = 1/2/6 ms
core01#

¿Cómo podemos tener tantas fallas de ping y ninguna caída de paquetes en las interfaces? ¿Cómo podemos encontrar dónde está el problema? Cisco TAC va en círculos sobre este problema, siguen pidiendo tecnología de espectáculos de tantos conmutadores diferentes y es obvio que el problema está entre core01 y dmzsw. Alguien puede ayudar?

Actualización 30 de julio de 2013

Gracias a todos por ayudarme a encontrar el problema. Era una aplicación que se comportaba mal y que enviaba muchos paquetes UDP pequeños durante unos 10 segundos a la vez. El firewall denegó estos paquetes. Parece que mi gerente quiere actualizar nuestro ASA para que no tengamos este problema nuevamente.

Más información

De las preguntas en los comentarios:

ASA1# show inter detail | i ^Interface|overrun|error
Interface GigabitEthernet0/0 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/1 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/2 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/3 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/4 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/5 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/6 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/7 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface Internal-Data0/0 "", is up, line protocol is up
     2749335943 input errors, 0 CRC, 0 frame, 2749335943 overrun, 0 ignored, 0 abort
         0 output errors, 0 collisions, 0 interface resets
           RX[00]: 156069204310 packets, 163645512578698 bytes, 0 overrun
           RX[01]: 185159126458 packets, 158490838915492 bytes, 0 overrun
           RX[02]: 192344159588 packets, 197697754050449 bytes, 0 overrun
           RX[03]: 173424274918 packets, 196867236520065 bytes, 0 overrun
Interface Internal-Data1/0 "", is up, line protocol is up
    26018909182 input errors, 0 CRC, 0 frame, 26018909182 overrun, 0 ignored, 0 abort
    0 output errors, 0 collisions, 0 interface resets
           RX[00]: 194156313803 packets, 189678575554505 bytes, 0 overrun
           RX[01]: 192391527307 packets, 184778551590859 bytes, 0 overrun
           RX[02]: 167721770147 packets, 179416353050126 bytes, 0 overrun
           RX[03]: 185952056923 packets, 205988089145913 bytes, 0 overrun
Interface Management0/0 "Mgmt", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface Management0/1 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface TenGigabitEthernet0/8 "Inside", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface TenGigabitEthernet0/9 "DMZ", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets

ASA1#

— usuario2096
fuente

¿La pérdida de paquetes coincide con cuando los niveles de tráfico están llegando a su punto máximo? ¿Ha sido este entorno libre de problemas antes de esto? ¿Qué se ha hecho para solucionar problemas hasta ahora?

— DrBru

Los niveles de tráfico no importan. La pérdida de paquetes ocurre cuando el tráfico a través del firewall es bajo o alto. Tenemos un caso abierto con TAC durante una semana y no pueden encontrar la pérdida de paquetes en ninguna interfaz. No hay problemas de CPU en los interruptores o el firewall. Tuvimos el dmz durante casi un año y la pérdida de paquetes solo comenzó en el último mes más o menos.

— user2096

Hola amigo, ¿tienes IPS habilitado en cualquiera de las dos interfaces ASA? Creo que allí podríamos encontrar al culpable.

— laf

Según la información de mtr, y que puede hacer ping entre los conmutadores sin problemas, le ofrecería que el problema está entre su conmutador core1 y su próximo salto hacia sus nms.

— Santino

@Santino, es prematuro decir si se trata de una pérdida aguas arriba de core01, o en algún lugar entre él y el dmzsw. user2096, publique la salida de show interface detail | i ^Interface|overrun|errory show resource usageen el firewall

— Mike Pennington

Interface Internal-Data0/0 "", is up, line protocol is up
     2749335943 input errors, 0 CRC, 0 frame, 2749335943 overrun, 0 ignored, 0 abort
                                              ^^^^^^^^^^^^^^^^^^
         0 output errors, 0 collisions, 0 interface resets

Muestra excesos en las interfaces InternalData, por lo que está eliminando el tráfico a través del ASA. Con tantas gotas, no es difícil imaginar que esto esté contribuyendo al problema. Los desbordamientos ocurren cuando las colas internas Rx FIFO se desbordan (normalmente debido a algún problema con la carga).

EDITAR para responder a una pregunta en los comentarios :

No entiendo por qué el firewall está sobrecargado, no está cerca de usar 10 Gbps. ¿Puede explicar por qué estamos viendo excesos incluso cuando la CPU y el ancho de banda son bajos? La CPU es de aproximadamente 5% y el ancho de banda en cualquier dirección nunca va mucho más alto que 1.4Gbps.

He visto que esto sucede una y otra vez cuando un enlace ve micro ráfagas de tráfico , que exceden el ancho de banda, la conexión por segundo o la potencia de paquete por segundo del dispositivo. Muchas personas citan estadísticas de 1 o 5 minutos como si el tráfico fuera relativamente constante en ese período de tiempo.

Echaría un vistazo a su firewall ejecutando estos comandos cada dos o tres segundos (ejecutar term pager 0para evitar problemas de paginación) ...

show clock
show traffic detail | i ^[a-zA-Z]|overrun|packets dropped
show asp drop

Ahora grafica cuánto tráfico ves cada pocos segundos frente a las caídas; si ve picos masivos en las caídas de políticas o excesos cuando aumenta su tráfico, entonces está más cerca de encontrar al culpable.

No olvides que puedes oler directamente en el ASA con esto si necesitas ayuda para identificar lo que está matando al ASA ... tienes que ser rápido para detectar esto a veces.

capture FOO circular-buffer buffer <buffer-size> interface <intf-name>

Netflow en sus conmutadores ascendentes también podría ayudar.

— Mike Pennington
fuente

¡dulce! gracias por la información sobre 'show int detail' ~

— Nachos

Nuestros excesos de datos internos están aumentando muy rápidamente, por lo que este parece ser el problema. PERO no entiendo por qué el firewall está sobrecargado, no está cerca de usar 10 Gbps. ¿Puede explicar por qué estamos viendo excesos incluso cuando la CPU y el ancho de banda son bajos? La CPU es de aproximadamente 5% y el ancho de banda en cualquier dirección nunca va mucho más alto que 1.4Gbps.

— user2096

@ user2096, edité mi respuesta para responder ...

— Mike Pennington

Esto no parece tener sentido: es un firewall transparente, con una entrada de 10GE y una salida de 10GE. ¿La ruta de datos interna no está clasificada para 10GE? Parece una falla de diseño del producto.

— nicotina

@nicotine, el OP compró un SSP-20 y el SSP-20 está limitado internamente a no más de 5 Gbps (consulte la hoja de datos de Cisco ). Si desea un firewall completo de 10 Gbps, debe comprar otra opción (quizás incluso el SSP-60, si CPS es un problema). Es solo una falla de diseño si excede la capacidad de almacenamiento interno de la caja. He visto casos de uso donde un SSP-20 con 10GE está bien.

— Mike Pennington