Trouver la perte transparente de paquets de pare-feu

Nous utilisons Cisco ASA 5585 en mode transparent layer2. La configuration est seulement deux liaisons 10GE entre notre partenaire commercial dmz et notre réseau interne. Une carte simple ressemble à ceci.

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

L'ASA a 8.2 (4) et SSP20. Les commutateurs sont 6500 Sup2T avec 12.2. Il n'y a aucune perte de paquets sur aucun commutateur ou interface ASA !! Notre trafic maximal est d'environ 1,8 Gbit / s entre les commutateurs et la charge CPU sur l'ASA est très faible.

Nous avons un étrange problème. Notre administrateur nms voit une très mauvaise perte de paquets qui a commencé en juin. La perte de paquets augmente très rapidement, mais nous ne savons pas pourquoi. Le trafic via le pare-feu est resté constant, mais la perte de paquets augmente rapidement. Ce sont les échecs ping nagios que nous voyons à travers le pare-feu. Nagios envoie 10 pings à chaque serveur. Certains échecs perdent tous les pings, tous les échecs ne perdent pas les dix pings.

entrez la description de l'image ici

Ce qui est étrange, c'est que si nous utilisons mtr depuis le serveur nagios, la perte de paquets n'est pas très mauvaise.

                             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

Lorsque nous faisons un ping entre les commutateurs, nous ne perdons pas beaucoup de paquets, mais il est évident que le problème commence quelque part entre les commutateurs.

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#

Comment pouvons-nous avoir autant d'échecs de ping et aucune perte de paquets sur les interfaces? Comment trouver le problème? Cisco TAC tourne en rond sur ce problème, ils continuent de demander la technologie show de tant de commutateurs différents et il est évident que le problème est entre core01 et dmzsw. Quelqu'un peut-il aider?

Mise à jour du 30 juillet 2013

Merci à tous de m'aider à trouver le problème. C'était une application qui se comportait mal et qui envoyait beaucoup de petits paquets UDP pendant environ 10 secondes à la fois. Ces paquets ont été refusés par le pare-feu. Il semble que mon manager souhaite mettre à niveau notre ASA afin que nous n'ayons plus ce problème.

Plus d'information

Des questions dans les commentaires:

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#

— user2096
source

La perte de paquets coïncide-t-elle avec le pic de trafic? cet environnement a-t-il déjà été exempt de problèmes avant cela? Qu'est-ce qui a été fait pour résoudre les problèmes jusqu'à présent?

— DrBru

Peu importe le niveau de trafic. La perte de paquets se produit lorsque le trafic via le pare-feu est faible ou élevé. Nous avons un dossier ouvert avec TAC pendant une semaine et ils ne peuvent pas trouver de perte de paquets sur aucune interface. Aucun problème de processeur sur les commutateurs ou le pare-feu. Nous avons eu le dmz pendant près d'un an et la perte de paquets n'a commencé que le mois dernier.

— user2096

Salut mon pote, Avez-vous activé IPS sur l'une des deux interfaces ASA? Je crois que nous pourrions trouver le coupable.

— laf

Sur la base des informations mtr, et que vous pouvez envoyer une requête ping entre les commutateurs sans problème, je proposerais que le problème se situe entre votre commutateur core1 et son prochain saut vers votre nms.

— Santino

@Santino, il est prématuré de dire s'il s'agit d'une perte en amont de core01, ou quelque part entre lui et le dmzsw. user2096, veuillez poster la sortie de show interface detail | i ^Interface|overrun|erroret show resource usagesur le pare

— 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

Vous présentez des dépassements sur les interfaces InternalData, de sorte que vous êtes laissez tomber le trafic par l'ASA. Avec autant de gouttes, il n'est pas difficile d'imaginer que cela contribue au problème. Les dépassements se produisent lorsque les files d'attente Rx FIFO internes débordent (normalement en raison d'un problème de charge).

EDIT pour répondre à une question dans les commentaires :

Je ne comprends pas pourquoi le pare-feu est surchargé, il n'est pas près d'utiliser 10Gbps. Pouvez-vous expliquer pourquoi nous constatons des dépassements même lorsque le processeur et la bande passante sont faibles? Le processeur est d'environ 5% et la bande passante dans les deux sens ne dépasse jamais 1,4 Gbps.

J'ai vu cela se produire à plusieurs reprises lorsqu'un lien voit des microrafales de trafic , qui dépassent la bande passante, la connexion par seconde ou la puissance par paquet par seconde de l'appareil. Tant de gens citent des statistiques de 1 ou 5 minutes comme si le trafic était relativement constant sur cette période.

Je voudrais jeter un œil à votre pare-feu en exécutant ces commandes toutes les deux ou trois secondes (exécutez term pager 0pour éviter les problèmes de pagination) ...

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

Maintenant, représentez graphiquement le trafic que vous voyez toutes les quelques secondes par rapport aux baisses; si vous voyez des pics massifs dans les baisses ou les dépassements de politique lorsque vos pics de trafic, alors vous êtes plus près de trouver le coupable.

N'oubliez pas que vous pouvez flairer directement sur l'ASA avec cela si vous avez besoin d'aide pour identifier ce qui tue l'ASA ... vous devez être rapide pour attraper cela parfois.

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

Netflow sur vos commutateurs en amont pourrait également vous aider.

— Mike Pennington
source

sucré! merci pour les informations sur 'show int detail' ~

— Nachos

Nos dépassements internes de données augmentent très rapidement, donc cela ressemble au problème. MAIS je ne comprends pas pourquoi le pare-feu est surchargé, il n'est pas près d'utiliser 10Gbps. Pouvez-vous expliquer pourquoi nous constatons des dépassements même lorsque le processeur et la bande passante sont faibles? Le processeur est d'environ 5% et la bande passante dans les deux sens ne dépasse jamais 1,4 Gbps.

— user2096

@ user2096, j'ai modifié ma réponse pour répondre ...

— Mike Pennington

Cela ne semble pas logique - c'est un pare-feu transparent, avec une entrée 10GE et une sortie 10GE. Le chemin de données interne n'est pas évalué pour 10GE? Cela ressemble à un échec de la conception du produit.

— nicotine

@nicotine, l'OP a acheté un SSP-20 et le SSP-20 est limité en interne à pas plus de 5 Gbps (réf . Fiche technique Cisco ). Si vous voulez un pare-feu complet à 10 Gbit / s, vous devez acheter une autre option (peut-être même le SSP-60, si CPS est un problème). Ce n'est un échec de conception que si vous dépassez la capacité de mise en mémoire tampon interne de la boîte. J'ai vu des cas d'utilisation où un SSP-20 avec 10GE est très bien.

— Mike Pennington