Netflow v9 – format eksportu danych czy usługa?

0

Netflow v5, Netflow v9, Netflow Collector, Flexible Netflow – terminy te pojawiają się często w literaturze fachowej. Jednak czy każdy z nas jest do końca świadomy co kryje się pod tymi pojęciami? Czy wiemy dlaczego Netflow zyskał popularność i co spowodowało pojawienie się wersji 9? Czy obecnie dostępne na rynku rozwiązania Netflow Collector’ów są w stanie efektywnie odbierać informacje od urządzeń sieciowych przy pomocy formatu eksportu Netflow v9?

Zacznijmy od wyjaśnienia, co kryje się pod terminem Netflow. Wydaje mi się, że najlepsze wyjaśnienie tego pojęcia znajdziemy w dokumencie RFC 3954 „Cisco Systems NetFlow Services Export Version 9”.
A zatem – „usługa (często mówimy też o aplikacji) Netflow dostarcza administratorom sieciowym informacji o strumieniach (ang. flow) IP przesyłanych przez urządzenia sieciowe”. Czytając dalej, znajdziemy wyjaśnienie terminu „flow” – jest to „jednokierunkowa sekwencja pakietów posiadających pewne wspólne właściwości” takie jak docelowy i źródłowy adres IP, protokół sieciowy, docelowy i źródłowy numer portu, np. numer portu TCP/UDP, ToS oraz numer interfejsu (ifIndex), z którego pochodzą powyższe informacje.

Dane uzyskane przez usługę Netflow eksportowane są do zewnętrznych serwerów (tzw. Netflow Collector’ów) w formacie eksportu danych określonym numerem wersji protokołu Netflow. Dlatego często mówimy o protokole eksportu danych NetFlow w wersji X, np. Netflow v5. Przez ostatnie kilka lat najczęściej wykorzystywaną wersją była wersja 5 lub wersja 8. Wersja 8 różni się od wersji 5 tym, że informacje zebrane przez urządzenie sieciowe zostają wstępnie zagregowane zanim zostaną przesłane do Netflow Collectora. Skutkuje to znacznie mniejszą ilością danych przesyłanych przez sieć, ale jednocześnie tracone są pewne informacje, które zostały zagregowane. Parę lat temu pojawiła się wersja 9 formatu eksportu danych nazywana w skrócie Netflow v9. Co było przyczyną powstania kolejnej wersji – odpowiedź znajdziecie Państwo w poniższym tekście. Już teraz chciałbym podkreślić, że każda z wersji eksportu obsługuje tę samą aplikację/usługę Netflow.

Zastosowanie aplikacji Netflow
Informacje dostępne dzięki usłudze NetFlow umożliwiają:

  • monitorowanie użytkowników oraz aplikacji (pamiętajmy, że NetFlow dostarcza jedynie informacji do poziomu warstwy 4 modelu OSI włącznie),
  • planowanie zasobów sieciowych,
  • identyfikację zagrożeń sieciowych,
  • uruchomienie systemu bilingowego,
  • inżynierię ruchu sieciowego.

Zanim pojawiła się wersja 9 protokołu NetFlow możliwe było jedynie zbieranie informacji o ruchu IPv4. Jest to bardzo duże ograniczenie – na przykład większość ruchu w sieci operatorów telekomunikacyjnych przesyłane jest wewnątrz ramek MPLS. W ciągu ostatnich kilku lat widzimy również coraz więcej ruchu IPv6. To powodowało, że nie wszędzie można było uruchomić aplikację NetFlow, gdyż uzyskane dane były w takich wypadkach niewiarygodne.

Jednocześnie, ze względu na to, że każda z dotychczasowych wersji protokołu eksportu danych NetFlow miała ściśle określony format, nie można było dołożyć żadnej nowej informacji w eksportowanym strumieniu danych bez opracowania nowej wersji protokołu. Wersja 9 była przełomem – wprowadzono, tzw. szablony (ang. templates) opisujące rodzaj danych w polach rekordów. Pozwoliło to na rozszerzenie analizy ruchu o, np. protokół IPv6, ruch przełączany z wykorzystaniem ramek MPLS, zbieranie informacji z warstwy drugiej, takie jak numeracja VLAN oraz adresy MAC. Możliwa stała się „pełna” analiza ruchu multicastowego uwzględniająca jego replikację. Zachęcam do zapoznania się z dokumentem NetFlow version 9 Flow-Record Format wyjaśniającym w detalach format ramki protokołu Netflow w wersji 9.

Wiele osób zadaje sobie pytanie, jak dostępne na rynku oprogramowanie, tzw. Netflow Collector, wspiera wersję 9 protokołu NetFlow? W przypadku komercyjnych pakietów obsługa jest zwykle bardzo dobra. Te same dane, jakie dotychczas były eksportowane wersją 5 lub na przykład wersją 8, mogą być teraz eksportowane, korzystając z wersji 9 protokołu NetFlow. Większość urządzeń Cisco wspiera protokół eksportu danych Netflow w wersji 9 od kilku lat. Szczególnie mocno widać to na rynku urządzeń operatorów telekomunikacyjnych, gdzie wprowadzone kilka lat temu oprogramowanie IOS XR wspierało od samego początku tylko protokół Netflow w wersji 9.

Flexible Netflow
Jednocześnie, wraz z wprowadzeniem wersji 9 protokołu Netflow, zaczęto mówić o tzw. Flexible Netflow. Jest to zmodyfikowana aplikacja NetFlow, w której definicja flow’u jest tworzona na etapie konfiguracji przez administratora. Ma on możliwość określenia elementów wyznaczających elementy kluczowe strumienia pakietów IP (ang. key-fields) oraz dane, jakie są dodatkowo zbierane (ang. non-key fields). W tradycyjnej aplikacji Netflow mowa jest o 7 elementach określających poszczególny strumień IP. W aplikacji Flexible Netflow ilość elementów „key-fields” jest w zasadzie dowolna. Można zdefiniować „flow” jako, np. strumień pakietów IPv6 przesyłanych na danym interfejsie sieciowym mających wspólne pole DSCP.

Jako administrator mogę nie być zainteresowany źródłowymi i docelowymi adresami IP. Chciałbym mieć jedynie informację o przesyłanym ruchu pod względem jego oznaczenia QoS. Należy tutaj podkreślić, że Flexible Netflow jest odmianą, rozszerzeniem aplikacji Netflow. Podobnie jak czyni to NetFlow, Flexible Netflow używa do eksportu protokołu Netflow w wersji 9. Pojawienie się funkcjonalności Flexible Netflow nie oznacza zaprzestania wsparcia dla funkcjonalności Netflow. Obie te aplikacje są konfigurowane niezależnie.

Wprowadzenie szablonów w protokole eksportu Netflow spowodowało pojawienie się kilku nowych ciekawych zastosowań:

  • Dzięki integracji usługi Flexible Netflow z usługą NBAR (Network-Based Application Recognition) możliwe jest klasyfikowanie przesyłanego ruchu nie tylko pod kątem informacji L2-L4, ale również pod kątem aplikacji warstw wyższych. NBAR rozpozna, jaka aplikacja jest źródłem danego rodzaju ruchu, a informacja o tym zostanie zawarta w rekordzie przypisanym do definicji flow’u.
  • Wyzwaniem dla popularnych ostatnio rozwiązań CGv6 (Carrier Grade IPv6), umożliwiających operatorom telekomunikacyjnym migrację usług dostępu do Internetu z wykorzystaniem protokołu IPv4 do protokołu IPv6, jest gromadzenie danych o przeprowadzonych translacjach adresów użytkowników. Częścią rozwiązania 6RD oraz DS-lite jest NAT44 wykonujący translację pomiędzy adresem prywatnym abonenta a współdzielonym adresem publicznym. Podobna sytuacja ma miejsce w rozwiązaniu NAT64, gdzie często jeden publiczny adres IPv4 przypisany będzie kilku adresom IPv6. Ilość translacji, jaka wykonywana jest na urządzeniu sieciowym operatora jest ogromna. Niezależne badania jednego z uniwersytetów pokazały, że 100 tysięcy aktywnych użytkowników generuje nawet 70 tysięcy nowych translacji na sekundę. Eksport tych danych poprzez protokół SNMP wydaje się bardzo problematyczny. Dlatego wszystkie znane mi rozwiązania wykorzystują do tego celu protokół Netflow w wersji 9.
  • Integracja aplikacji Flexible Netflow z mechanizmami QoS urządzeń sieciowych pozwoli na zbieranie dokładniejszych informacji o ruchu powodującym, np. natłok w sieci. Na podstawie zebranych danych administrator będzie mógł bardziej precyzyjnie określić przyczyny degradacji jakości usług w swojej sieci.

Wspominałem poprzednio o eksporcie danych aplikacji NetFlow do serwerów NewFlow Collector. O ile eksport danych z tradycyjnej aplikacji NetFlow jest obsługiwany od kilku lat, to eksport danych z aplikacji Flexible NetFlow nie zawsze jest interpretowany poprawnie. Wynika to z faktu, że rozwiązanie Flexible NetFlow używa niestandardowej kombinacji pól definiujących strumień danych. Również specyficzne zastosowania, w których do eksportu danych stosowany jest protokół Netflow w wersji 9, np. wspomniany już zbiór rozwiązań Cisco Carrier Grade IPv6, wymagają od NetFlow Collectora zrozumienia zastosowanych w rozwiązaniu szablonów. Dlatego też wybierając dane oprogramowanie Netflow Collectora, należy upewnić się, że spełni ono nasze wymagania.

Podsumowanie
Netflow v9 to format eksportu danych stosowany na przykład przez aplikację Netflow, Flexible Netflow czy też inne specjalizowane rozwiązania sieciowe. Jego główną cechą odróżniającą go od poprzednich wersji protokołu Netflow to pojawienie się, tzw. szablonów definiujących rodzaj przesyłanych danych. Dzięki temu możliwa jest ewaluacja protokołu NetFlow do wsparcia nowych funkcjonalności poprzez określenie jedynie formatu nowego szablonu.

Dodatkowe informacje na temat usługi Netflow można znaleźć na stronach Cisco np. pod adresem www.cisco.com/go/netflow

Autor: Krzysztof Mazepa, inżynier i konsultant w firmie Cisco Systems

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ