Ruch NetFlow

Dzisiejsze infrastruktury sieciowe obsługują miliardy zdarzeń na sekundę. Skala rodzi swoje problemy, a próby zdiagnozowania wymagają odpowiedniego podejścia. Przedstawimy kilka metod realizacji takiego monitoringu sieci.

Wykorzystanie bezpośrednich analizatorów pakietów (np tcpdump czy wireshark)

Tego typu oprogramowanie jest częściej używane na klienckich końcówkach sieci, niż na jej węzłach. Przyczyn ku temu jest kilka.

  • Węzły sieciowe, routery, przełączniki najczęściej nie posiadają dostatecznie dużego wolnego miejsca dla tak dużej ilości danych, gdyż pakiety są zrzucane w całości razem z danymi, które są w tych pakietach zawarte.
  • Ciągłe wykonywanie tego zadania zbytnio obciąży urządzenie sieciowe.
  • Brak odpowiednich narzędzi oraz możliwości przeanalizowania zebranych danych “na miejscu”. Rodzi to konieczność przerzucania zebranych danych na zewnętrzne systemy, co zdecydowanie nie jest wygodne i wydłuża czas analizy.

Minusem obserwacji ruchu ze wskazanej końcówki PC jest oczywisty fakt analizy tylko własnych pakietów oraz ruchu rozgłoszeniowego. O ile pozwala to na diagnozę indywidualnego przypadku to nie wnosi wiele o stanie całości sieci.

Przykład realizacji w Wireshark.

Wykorzystanie Port Mirroringu

Port Mirring, zwany czasami SPAN Port jest funkcjonalnością większości przełączników sieciowych. Pozwala na wysłanie kopii całego ruchu ze wskazanego lub grupy portów (również vlanu) na inny, konkretny port. Do tego portu się wpina końcówkę z narzędziami typu sniffer (patrz punkt wyżej). Daje to sporo szerszy pogląd na przepływ pakietów w sieci, ponieważ przełącznik pozwala na wgląd w 100% transmisji z jaką ma do czynienia. Dobrą cechą SPAN Portu jest fakt, że nie obciąża systemu węzła sieciowego. Minus tego podejścia jest taki, że końcówka, na której jest uruchamiany analizator jest wpinana bezpośrednio w urządzenie. W praktyce zużywamy na to jeden fizyczny port urządzenia, co może być problematyczne w przypadku braku wolnych portów na urządzeniu.

Wykorzystanie protokołów typu Flow

NetFlow oraz wszystkie protokoły pochodne takie jak IPFIX, jFlow, sFlow zostały zaprojektowane na potrzeby jak najbardziej optymalnego analizowania całości ruchu sieciowego. Zyskiem z wykorzystania protokołu Flow jest brak konieczności przerzucania 100% ruchu do celów analizy i praca z informacjami pochodzących z jego agregacji. I tak pojedynczy pakiet Flow pozwala podsumować całą sesję sieciową wygenerowaną podczas pracy użytkownika z aplikacją. Przesyłana jest tylko i wyłącznie informacja o pakietach bez ich zawartości. Te informacje są grupowane i wysyłane w stosunkowo dużych paczkach, więc zmniejsza się narzut na obciążenie sieci. Jeżeli mamy szukać minusów tej metody to na pewno należy zwrócić uwagę na mnogość wykorzystywanych protokołów typu Flow, ich wersji i deklarowanej przez producenta zgodność.

2. Warianty ruchu NetFlow

Realizacji jest dużo, ale opiszę najpopularniejsze

sFlow

chyba najpopularniejsza realizacjam jest realizowana w urządzeniach takich firm jak: Alcatel Lucent, Brocade, Cisco, F5 Big-IP, HP, IBM, Juniper, NetGear i innych

JFlow

Wykorzystywany wyłącznie przez urządzenia firmy Juniper.

Cflowd

Alcatel Lucent, Juniper

IPFIX

Cisco, Juniper, Mikrotik.

Każda z tych implementacji posiada swoje wersje, oparte na różnych wersjach NetFlow. Wersje protokołu:

v1

Pierwsza implementacja, ograniczona tylko do IPv4, bez informacji o Maskach podsieci, czy numerów AS.

v2,v3,v4

Wewnętrzne wersje Cisco które nigdy się nie ukazały.

v5

Najpopularniejsza (na razie) wersja dostępna od 2009 roku. Ale dalej ograniczona tylko do IPv4.

v6

Już nie supportowana przez Cisco wersja.

v7

Uzupełniona o informacje o ruter Wersja v5.

v8

Usprawniona i przeorganizowana wersja v5.

v9

Wersja oparta na dynamicznych wzorcach. Umożliwia to (i najczęściej do tego jest używane) przesyłanie informacji o pakietach IPv6, MPLS albo IPv4 z informacjami o BGP.

v10

Służy do określenia protokołu IPFIX, który mimo że jest oparty na NetFlow zdecydowanie od niego odbiega. Został opracowany przez organizacje IETF