Ermitteln des Paketverlusts einer transparenten Firewall

Wir verwenden den Cisco ASA 5585 in einem transparenten Layer2-Modus. Die Konfiguration besteht nur aus zwei 10GE-Verbindungen zwischen unserem Geschäftspartner dmz und unserem internen Netzwerk. Eine einfache Karte sieht so aus.

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

Der ASA hat 8.2 (4) und SSP20. Die Schalter sind 6500 Sup2T mit 12,2. Es gibt keine Paketverluste auf einem Switch oder einer ASA-Schnittstelle !! Der maximale Datenverkehr zwischen den Switches beträgt ca. 1,8 Gbit / s, und die CPU-Auslastung des ASA ist sehr gering.

Wir haben ein komisches Problem. Unser nms-Administrator sieht einen sehr schlechten Paketverlust, der irgendwann im Juni einsetzte. Der Paketverlust wächst sehr schnell, aber wir wissen nicht warum. Der Datenverkehr durch die Firewall ist konstant geblieben, aber der Paketverlust nimmt rasch zu. Dies sind die Nagios-Ping-Fehler, die wir durch die Firewall sehen. Nagios sendet 10 Pings an jeden Server. Einige der Fehler verlieren alle Pings, nicht alle Fehler verlieren alle zehn Pings.

Bildbeschreibung hier eingeben

Das Seltsame ist, dass der Paketverlust nicht sehr schlimm ist, wenn wir mtr vom Nagios-Server verwenden.

                             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

Wenn wir zwischen den Switches pingen, verlieren wir nicht viele Pakete, aber es ist offensichtlich, dass das Problem irgendwo zwischen den Switches beginnt.

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#

Wie können wir so viele Ping-Fehler und keine Paketverluste auf den Schnittstellen haben? Wie können wir herausfinden, wo das Problem liegt? Cisco TAC beschäftigt sich mit diesem Problem in Kreisen. Es wird ständig nach Show-Technologie von so vielen verschiedenen Switches gefragt, und es ist offensichtlich, dass das Problem zwischen core01 und dmzsw liegt. Kann jemand helfen?

Update 30. Juli 2013

Vielen Dank an alle, die mir geholfen haben, das Problem zu finden. Es war eine sich schlecht verhaltende Anwendung, die ungefähr 10 Sekunden lang viele kleine UDP-Pakete gleichzeitig sendete. Diese Pakete wurden von der Firewall abgelehnt. Es sieht so aus, als ob mein Manager unsere ASA aktualisieren möchte, damit dieses Problem nicht erneut auftritt.

Mehr Informationen

Aus Fragen in den Kommentaren:

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
quelle

Stimmt der Paketverlust mit dem Zeitpunkt überein, an dem die Verkehrsspitzen erreicht sind? War diese Umgebung zuvor schon einmal kostenlos? Was wurde bisher zur Fehlerbehebung unternommen?

— DrBru

Das Verkehrsniveau spielt keine Rolle. Der Paketverlust tritt auf, wenn der Datenverkehr durch die Firewall niedrig oder hoch ist. Wir haben einen Fall mit TAC für eine Woche offen und sie können keinen Paketverlust auf irgendeiner Schnittstelle feststellen. Keine CPU-Probleme bei Switches oder der Firewall. Wir hatten die DMZ für fast ein Jahr und Paketverlust begann erst im letzten Monat oder so.

— user2096

Hallo Kumpel, haben Sie IPS auf einer der beiden ASA-Schnittstellen aktiviert? Ich glaube, wir finden dort den Täter.

— Laf

Aufgrund der mtr-Informationen und der Tatsache, dass Sie problemlos zwischen Switches pingen können, würde ich Ihnen anbieten, dass das Problem zwischen Ihrem core1-Switch und dem nächsten Sprung zu Ihrem nms liegt.

— Santino

@ Santino, es ist verfrüht zu sagen, ob dies ein Verlust stromaufwärts von core01 ist oder irgendwo zwischen ihm und dem dmzsw. user2096, bitte poste die Ausgabe von show interface detail | i ^Interface|overrun|errorund show resource usageauf der 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

Sie zeigen Überschreitungen auf den InternalData Schnittstellen, so dass Sie werden Verkehr durch die ASA fallen. Bei so vielen Tropfen ist es nicht schwer vorstellbar, dass dies zum Problem beiträgt. Überläufe treten auf, wenn das interne Rx-FIFO einen Überlauf in der Warteschlange aufweist (normalerweise aufgrund eines Problems mit der Auslastung).

BEARBEITEN, um auf eine Frage in den Kommentaren zu antworten :

Ich verstehe nicht, warum die Firewall überlastet ist, es ist nicht nah an der Verwendung von 10 Gbit / s. Können Sie erklären, warum es trotz geringer CPU- und Bandbreitenbelastung zu Überschreitungen kommt? Die CPU ist ungefähr 5% und die Bandbreite in beiden Richtungen ist niemals viel höher als 1,4 Gbit / s.

Ich habe gesehen, dass dies immer wieder passiert, wenn auf einer Verbindung Verkehrsmikrobursts auftreten , die entweder die Bandbreite, die Verbindungsgeschwindigkeit pro Sekunde oder die Paketgeschwindigkeit pro Sekunde des Geräts überschreiten. So viele Leute geben Statistiken für 1 oder 5 Minuten an, als ob der Datenverkehr in diesem Zeitraum relativ konstant wäre.

Ich würde einen Blick auf Ihre Firewall werfen, indem ich diese Befehle alle zwei oder drei Sekunden ausführe (ausführen term pager 0, um Paging-Probleme zu vermeiden) ...

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

Stellen Sie jetzt fest, wie viel Verkehr Sie alle paar Sekunden im Vergleich zu Tropfen sehen. Wenn bei einem Anstieg des Datenverkehrs massive Ausschläge in Bezug auf Richtlinieneinbrüche oder -überschreitungen zu verzeichnen sind, sind Sie dem Schuldigen näher.

Vergiss nicht, dass du damit direkt an der ASA schnüffeln kannst, wenn du Hilfe benötigst, um herauszufinden, was die ASA tötet. Manchmal musst du schnell sein, um das zu fangen.

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

Netflow auf Ihren Upstream-Switches könnte ebenfalls hilfreich sein.

— Mike Pennington
quelle

Süss! Danke für Informationen über "show int detail" ~

— Nachos

Unsere Internaldatenüberschreitungen nehmen sehr schnell zu, daher scheint dies das Problem zu sein. ABER ich verstehe nicht, warum die Firewall überlastet ist, es ist nicht annähernd 10 Gbit / s. Können Sie erklären, warum es trotz geringer CPU- und Bandbreitenbelastung zu Überschreitungen kommt? Die CPU ist ungefähr 5% und die Bandbreite in beiden Richtungen ist niemals viel höher als 1,4 Gbit / s.

— user2096

@ user2096, ich habe meine Antwort bearbeitet, um zu antworten ...

— Mike Pennington

Dies scheint keinen Sinn zu ergeben - es handelt sich um eine transparente Firewall mit einem 10GE-Eingang und einem 10GE-Ausgang. Der interne Datenpfad ist nicht für 10GE bewertet? Scheint wie ein Produktdesignfehler.

— Nikotin

@nicotine, das OP hat einen SSP-20 gekauft und der SSP-20 ist intern auf nicht mehr als 5 Gbit / s begrenzt (siehe Cisco-Datenblatt ). Wenn Sie eine vollständige 10-Gbit / s-Firewall wünschen, müssen Sie eine andere Option erwerben (möglicherweise sogar den SSP-60, wenn CPS ein Problem darstellt). Dies ist nur dann ein Entwurfsfehler, wenn Sie die interne Pufferkapazität der Box überschreiten. Ich habe Anwendungsfälle gesehen, in denen ein SSP-20 mit 10GE in Ordnung ist.

— Mike Pennington