Wiele porzuconych pakietów, gdy tcpdumping na zajętym interfejsie

Moje wyzwanie

Muszę zrobić tcpdump dużej ilości danych - właściwie z 2 interfejsów pozostawionych w trybie rozwiązłym, które są w stanie zobaczyć duży ruch.

Podsumowując

• Rejestruj cały ruch w trybie rozwiązłym z 2 interfejsów
• Interfejsy te nie mają przypisanego adresu IP
• Pliki pcap muszą być obracane o ~ 1G
• Po zapisaniu 10 TB plików rozpocznij obcinanie najstarszego

Co aktualnie robię

Obecnie używam tcpdump w następujący sposób:

ifconfig ethX promisc
ifconfig ethX promisc
tcpdump -n -C 1000 -z /data/compress.sh -i any -w /data/livedump/capture.pcap $FILTER

$FILTERZawiera filtry src / dst tak, że można używać -i any. Powodem tego jest to, że mam dwa interfejsy i chciałbym uruchomić zrzut w jednym wątku zamiast dwóch.

compress.sh zajmuje się przypisaniem tar do innego rdzenia procesora, kompresowania danych, nadania rozsądnej nazwy pliku i przeniesienia go do lokalizacji archiwum.

Nie mogę określić dwóch interfejsów, dlatego zdecydowałem się na użycie filtrów i zrzut z anyinterfejsu.

W tej chwili nie zajmuję się sprzątaniem, ale planuję monitorować dysk, a kiedy pozostanie 100G, zacznę wymazywać najstarsze pliki - powinno być dobrze.

I teraz; mój problem

Widzę upuszczone pakiety. Jest to zrzut, który działał przez kilka godzin i zebrał około 250 koncertów plików pcap:

430083369 packets captured
430115470 packets received by filter
32057 packets dropped by kernel  <-- This is my concern

Jak mogę uniknąć upuszczenia tylu pakietów?

Te rzeczy, które już próbowałem lub na które patrzyłem

Zmieniłem wartość /proc/sys/net/core/rmem_maxi /proc/sys/net/core/rmem_defaultco rzeczywiście pomogło - w rzeczywistości zajęło to około połowy upuszczonych pakietów.

Patrzyłem też na gulp - problem z gulp polega na tym, że nie obsługuje wielu interfejsów w jednym procesie i denerwuje się, jeśli interfejs nie ma adresu IP. Niestety w moim przypadku jest to przełom.

Kolejny problem polega na tym, że gdy ruch przepływa przez rurę, nie mogę uruchomić automatycznego obrotu. Zdobycie jednego ogromnego pliku 10 TB nie jest bardzo wydajne i nie mam komputera z 10 TB + RAM, na którym mogę uruchomić Wireshark, więc to nie działa.

Masz jakieś sugestie? Może nawet lepszy sposób na zrobienie mojego zrzutu.

tcpdump przechowuje przychodzące dane w buforze pierścieniowym. Jeśli bufor przepełni się, zanim tcpdump przetwarza jego zawartość, tracisz pakiety.

Domyślny rozmiar bufora dzwonka to prawdopodobnie 2048 (2MiB).

Aby zwiększyć rozmiar bufora, dodaj -Bopcję:

tcpdump -B 4096 ...

Powinieneś także spróbować użyć szybszej pamięci dyskowej.

W końcu znalazłem rozwiązanie, z którym można żyć. Porzucone pakiety zostały zmniejszone z 0,0047% do .00013% - co na początku nie wydaje się zbyt duże, ale kiedy mówimy o milionach pakietów, to całkiem sporo.

Rozwiązanie składało się z kilku rzeczy. Jednym z nich była zmiana rozmiaru bufora pierścieniowego, jak zasugerował Michael Hampton.

Poza tym stworzyłem ramfs i zrzuciłem to na żywo, przepisałem skrypt kompresujący, aby zająć się przenoszeniem zrzutów z ramfów na dysk. To tylko nieznacznie zmniejszyło ilość, ale wystarczająco, aby być godnym uwagi - nawet jeśli wszystkie testy i testy porównawcze dysku pokazują, że dysk nie powinien stanowić wąskiego gardła. Myślę, że czas dostępu jest tutaj bardzo ważny.

Wyłączenie hiperwątkowości również zrobiło więcej, niż się spodziewałeś.