Zawyżone wskazania przepływów NetFlow - przyczyny - Printable Version +- Monitoring Serwerów - Forum o monitoringu infrastruktury IT (https://monitoringserwerow.pl) +-- Forum: MONITORING INFRASTRUKTURY IT (https://monitoringserwerow.pl/forumdisplay.php?fid=1) +--- Forum: Scrutinizer (https://monitoringserwerow.pl/forumdisplay.php?fid=14) +--- Thread: Zawyżone wskazania przepływów NetFlow - przyczyny (/showthread.php?tid=37)

Zawyżone wskazania przepływów NetFlow - przyczyny - ArturB - 07-30-2019 Czy zdarzyło ci się monitorować sieć i nabrać podejrzeń, że wskazywany przez strumienie ruch jest przesadzony? W pierwszej kolejności należy wówczas przyjrzeć się ustawieniom szybkości interfejsu. Ponieważ dane z urządzenia są przesyłane przez protokół SNMP, może zdarzyć że ten parametr będzie źle ustawiony. Po drugie, jeśli analizowany jest przepływ typu NetFlow, należy upewnić się, że parametr „ip flow-cache timeout active 1” został skonfigurowany w ruterze. Bez tej komendy wskazania przepływów będą często przeszacowane albo niedoszacowane. Ten artykuł wyjaśnia, jak i dlaczego strumienie są eksportowane. W klasycznym ujęciu dane o ruchu w sieci, gromadzone w tabeli cache-u strumieni są eksportowane w czterech przypadkach: 1. Wygasa timer dla strumieni trwających przez dłuższy czas. Zwykle jest on ustalony na 60 sekund, i większość narzędzi raportujących używa interwału o długości jednej minuty. Przykładowo, jeśli połączenie lub strumień dla ściąganego pliku trwa 4,5 minuty, jego zawartość określona przez wartość „delta byte count” będzie eksportowana co 60s. W piątej minucie strumień się zakończy i wyeksportowana zostanie pozostała ilość danych oraz pakietów strumienia NetFlow. Sam strumień jest również usunięty z pamięci podręcznej. Analogicznie, jeśli wartość „time-out” jest ustawiona na dłuższy okres (np. na 5 minut), strumień trwający 2 lub 3 minuty może być wyeksportowany za jednym razem. Z timerem ustawionym na 5 minut może pojawić się problem: jeśli narzędzie raportujące oczekuje danych w interwale 1 minuty, na wykresie „data trend” pojawią się czerwone piki oznaczające użycie większe niż 100%. Aby uniknąć tego problemu, należy zawsze ustawiać timer na 60 sekund. 2. Strumień pozostaje nieaktywny po czasie określanym przez parametr „inactive timeout”. Najczęściej jest on ustawiony na 15s. Taka sytuacja ma miejsce kiedy na połączeniu TCP nie ma ruchu lub kiedy strumień używa UDP. 3. Strumień zakończył się, co jest sygnalizowane przez „flagę TCP”: Zakończony (FIN) lub zresetowany (RST). WAŻNE: nie wszystkie urządzenia posiadają tę funkcję. 4. Strumienie są eksportowane wcześniej, jeśli zapełni się cache. W przypadku Cisco nazywa się to „awaryjne wygaśnięcie” i wówczas wybrane losowo strumienie są eksportowane kiedy cache jest zapełniony w 90%. Eksportować przez UDP czy SCTP? W filmiku youtube zatytułowanym „Configuring Flexible Netflow”, krok 2 określa komendę „transport udp 2055”. Numer portu może się zmieniać, jednak UDP jest jak dotąd najbardziej popularną warstwą transportową do przesyłu strumieni. Nie jest jednak jedyny. Ponieważ UDP nie jest do końca wiarygodny jeśli chodzi o przesył datagramów, Cisco oferuje alternatywę w postaci protokołu Stream Control Transmission Protocol (SCTP). W sieci można znaleźć mnóstwo materiałów na ten temat, więc tutaj tylko skrótowo: W informatyce sieci komputerowych, SCTP to warstwa transportowa posiadająca cechy wspólne popularnych protokołów takich jak TCP czy UDP: przesyła informacje w postaci ukształtowanych wiadomości (jak UDP) i zapewnia wiarygodny, sekwencyjny przesył z kontrolą zatłoczenia (podobnie do TCP). Pomimo, że UDP nie gwarantuje dostawy pakietów, inżynierowie z Cisco udostępnili mechanizm weryfikacji liczby strumieni. Nosi on nazwę „flow sequence number”. Ale jednocześnie zagubione strumienie będą wskazywać zaniżone przepływy – ale to jest temat na kolejny post na naszym blogu. Ryan@PLIXER Link do oryginalnego artykułu.