Znajdowanie przezroczystej utraty pakietu zapory ogniowej

Używamy Cisco ASA 5585 w trybie transparentnym warstwy 2. Konfiguracja to tylko dwa łącza 10GE między naszym partnerem biznesowym dmz a naszą siecią wewnętrzną. Prosta mapa wygląda tak.

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

ASA ma 8.2 (4) i SSP20. Przełączniki to 6500 Sup2T z 12,2. Brak spadków pakietów na dowolnym przełączniku lub interfejsie ASA !! Nasz maksymalny ruch wynosi około 1,8 Gb / s między przełącznikami, a obciążenie procesora w ASA jest bardzo niskie.

Mamy dziwny problem. Nasz administrator nms widzi bardzo złą utratę pakietów, która rozpoczęła się w czerwcu. Utrata pakietów rośnie bardzo szybko, ale nie wiemy dlaczego. Ruch przez zaporę sieciową pozostaje stały, ale utrata pakietów szybko rośnie. Są to błędy pingowania nagios, które widzimy przez zaporę. Nagios wysyła 10 pingów na każdy serwer. Niektóre awarie tracą wszystkie pingi, nie wszystkie awarie tracą wszystkie dziesięć pingów.

wprowadź opis zdjęcia tutaj

Dziwne jest to, że jeśli użyjemy mtr z serwera nagios, utrata pakietów nie jest bardzo zła.

                             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

Kiedy pingujemy między przełącznikami, nie tracimy wielu pakietów, ale oczywiste jest, że problem zaczyna się gdzieś między przełącznikami.

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#

Jak możemy mieć tyle błędów pingowania i brak upuszczania pakietów na interfejsach? Jak możemy ustalić, gdzie jest problem? Cisco TAC krąży w kółko nad tym problemem, wciąż proszą o show tech z tak wielu różnych przełączników i oczywiste jest, że problemem jest między core01 i dmzsw. Czy ktoś może pomóc?

Zaktualizuj 30 lipca 2013 r

Dziękuję wszystkim za pomoc w znalezieniu problemu. Była to źle zachowująca się aplikacja, która wysyłała wiele małych pakietów UDP przez około 10 sekund na raz. Te pakiety zostały odrzucone przez zaporę ogniową. Wygląda na to, że mój menedżer chce zaktualizować nasz ASA, więc nie mamy tego problemu ponownie.

Więcej informacji

Z pytań w komentarzach:

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#

cisco switch cisco-asa firewall packet-loss użytkownik2096
źródło

Czy utrata pakietów zbiega się w czasie, gdy poziomy ruchu osiągają maksimum? czy to środowisko było wcześniej wolne od problemów? co zrobiono w celu rozwiązania problemów do tej pory?

DrBru

Poziomy ruchu nie mają znaczenia. Utrata pakietów ma miejsce, gdy ruch przez zaporę ogniową jest niski lub wysoki. Przez tydzień mamy otwartą skrzynkę z TAC i nie mogą oni znaleźć utraty pakietu na żadnym interfejsie. Brak problemów z procesorem na przełącznikach lub zaporze. Mamy dmz przez prawie rok, a utrata pakietów rozpoczęła się dopiero w ostatnim miesiącu.

user2096

Cześć kolego, czy masz włączony IPS na jednym z dwóch interfejsów ASA? Wierzę, że tam możemy znaleźć winowajcę.

laf

Opierając się na informacjach mtr, i że możesz pingować między przełącznikami bez problemu, proponuję, że problem dotyczy między przełącznikiem core1 a jego następnym skokiem do nms.

Santino

@ Santino, przedwczesne jest stwierdzenie, czy jest to strata powyżej rdzenia01, czy gdzieś pomiędzy nim a dmzsw. user2096, proszę opublikować dane wyjściowe show interface detail | i ^Interface|overrun|errori show resource usagena zaporze

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

Pokazujesz przekroczeń na interfejsach InternalData, więc są upuszczenie ruchu przez ASA. Przy tak wielu kroplach nietrudno wyobrazić sobie, że przyczynia się to do powstania problemu. Przekroczenia występują, gdy wewnętrzne kolejki Rx FIFO przepełniają się (zwykle z powodu jakiegoś problemu z ładowaniem).

EDYTUJ, aby odpowiedzieć na pytanie w komentarzach :

Nie rozumiem, dlaczego zapora jest przeciążona, nie jest blisko użycia 10 Gb / s. Czy możesz wyjaśnić, dlaczego mamy do czynienia z przekroczeniami, nawet jeśli procesor i przepustowość są niskie? Procesor wynosi około 5%, a przepustowość w obu kierunkach nigdy nie przekracza dużo więcej niż 1,4 Gb / s.

Widziałem to w kółko, gdy łącze widzi mikroburstery ruchu , które przekraczają przepustowość, połączenie na sekundę lub moc pakietu na sekundę urządzenia. Tak wiele osób podaje statystyki z 1 lub 5 minut, jakby ruch był względnie stały w tym przedziale czasowym.

Spojrzałbym na twoją zaporę, uruchamiając te polecenia co dwie lub trzy sekundy (uruchom, term pager 0aby uniknąć problemów ze stronicowaniem) ...

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

Teraz sprawdź, ile ruchu widzisz co kilka sekund w porównaniu do spadku; jeśli zauważysz znaczne skoki spadków lub przekroczeń zasad, gdy ruch wzrośnie, oznacza to, że jesteś bliżej znalezienia winowajcy.

Nie zapominaj, że możesz wąchać bezpośrednio na ASA, jeśli potrzebujesz pomocy w określeniu, co zabija ASA ... musisz czasem szybko to złapać.

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

Netflow na twoich przełącznikach może również pomóc.

Mike Pennington
źródło

Słodkie! dzięki za informacje o 'show int detail' ~

Nachos

Przekroczenia naszych internaldata rosną bardzo szybko, więc wygląda to na problem. ALE nie rozumiem, dlaczego zapora jest przeciążona, nie jest blisko użycia 10 Gb / s. Czy możesz wyjaśnić, dlaczego mamy do czynienia z przekroczeniami, nawet jeśli procesor i przepustowość są niskie? Procesor wynosi około 5%, a przepustowość w obu kierunkach nigdy nie przekracza dużo więcej niż 1,4 Gb / s.

user2096,

@ user2096, zredagowałem swoją odpowiedź, aby odpowiedzieć ...

Mike Pennington,

Nie wydaje się to mieć sensu - jest to przezroczysta zapora ogniowa z wejściem 10GE i wyjściem 10GE. Wewnętrzna ścieżka danych nie jest oceniana dla 10GE? Wydaje się, że nie udało się zaprojektować produktu.

nikotyna

@nicotine, OP zakupił SSP-20, a SSP-20 jest wewnętrznie ograniczony do nie więcej niż 5 Gb / s (patrz Arkusz danych Cisco ). Jeśli chcesz pełnej zapory sieciowej 10 Gb / s, musisz kupić inną opcję (być może nawet SSP-60, jeśli problem stanowi CPS). To tylko błąd projektu, jeśli przekroczysz wewnętrzną pojemność buforowania skrzynki. Widziałem przypadki użycia, w których SSP-20 z 10GE jest w porządku.

Mike Pennington

Znajdowanie przezroczystej utraty pakietu zapory ogniowej

Odpowiedzi: