NetFlow kontra sFlow - co jest lepsze? - 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: NetFlow kontra sFlow - co jest lepsze? (/showthread.php?tid=31)

NetFlow kontra sFlow - co jest lepsze? - ArturB - 07-30-2019 Pojawiło się kilka debat na temat porównania NetFlow i sFlow, które często podkreślają dlaczego jedna technologia jest lepsza od drugiej. W tym artykule chciałbym podkreślić gdzie te technologie są podobne, i kiedy powinny być zaimplementowane. Oczywiście obie mają pewne zalety, ale jedna technologia zdecydowanie wyprzedza inne. Co to jest FLOW? Zdefiniowane przez IETF. Przepływ (FLOW) jest sekwencją pakietów wysyłanych z aplikacji nadawczej do aplikacji odbiorczej. Technologia sFlow wykorzystuje próbkowanie próbując osiągnąć skalowalność. Architektura systemu sFlow składa się z wielu urządzeń pobierających dwa rodzaje próbek: losowe pobieranie próbek pakietów oraz próbkowanie na bazie liczników w pewnych interwałach czasowych. Próbkowane pakiety o których mowa, stanowiące próbki ruchu, są wysyłane jako datagramy sFlow do centralnego serwera z uruchomionym oprogramowaniem służącym do analizy i sprawozdań dotyczących ruchu w sieci; sFlow kolektor. SFlow może być realizowany sprzętowo lub programowo i choć nazwa "sFlow" oznacza, że jest to technologia przepływu, z definicji jednak nie jest to technologia przepływu w ogóle, a reprezentuje obraz transmisji na zasadzie próbek. Co to jest NetFlow? NetFlow to prawdziwa technologia przepływu. Wpisy odnośnie przepływu generowane są w urządzeniach sieciowych i łączone w pakiety. Każdy przesłany przez sprzęt datagram znajduje odbicie w pakiecie netflow który niesie takie informacje jak: Interfejs źródłowy Typ usługi Źródłowy adres IP Docelowy adres IP Źródło w warstwie 4 Port docelowy w warstwie 4 Protokół IP W momencie eksportowania przepływu liczona jest różnica bajtów pomiędzy pakietami, oraz dołączone jest wiele dodatkowych informacji takich jak maski podsieci oraz np. pola związane z technologiami BGP. Pakiety, które nie pasują do utworzonego zapisu przesyły tworzą nowy obiekt FLOW. NetFlow zapewnia 100% dokładności w analizie ruchu IP, chociaż próbkowanie danych i próbkowanie przepływu jest nadal wspierane. Co to jest Flexible Netflow (FnF) - Elastyczny NetFlow? Flexible NetFlow (FnF) tak naprawdę nie jest nowym formatem eksportu danych. Można powiedzieć, że raczej opiera się na modyfikacji architekturze formatu NetFlow v9. FnF ma jeden z najlepiej aczkolwiek bardziej skomplikowanych implementacji eksportu przepływów jakie widziałem do tej pory. Co FnF może eksportować podlega dodatkowej definicji. Innymi słowy FnF pozwala klientom na eksport niemal wszystkiego co przechodzi przez router, w tym całych pakietów i robi to w czasie rzeczywistym, podobnie jak sFlow. Co to jest IPFIX? IPFIX jest proponowanym standardem strukturyzowanego streamingu informacji i jest oparty na najnowszej wersji (NetFlow v9). W związku z tym, jest czasami błędnie określany jako NetFlow V10. Który jest ważniejszym standardem: NetFlow lub sFlow? Odpowiedź brzmi: żaden. Jeśli przejdziesz do strony internetowej IETF to znajdziesz RFC 3176, w którym omówiono protokół Slow, a gdy otworzysz RFC 3954 to znajdziesz opis NetFlow v9. Technologie te nie są standardami. RFC oznacza prośbę o komentarz (Request for Comment). Często wielu z nas (w tym ja) odwołuje sie do tych technologii, jak do normy jednak nie ma standardu dla ruchu "flow". IPFIX, który jest zdefiniowany w RFC 5101 jest jak na razie proponowanym standardem. Zwracam zatem uwagę na takie dokumenty jak ten z Brocade: sFlow_vs_NetFlow_WP_00 ", którym twierdzi się, że IPFIX zostało źle przyjęte przez twórców sprzętu" co po prostu nie jest prawdą i mogę wymienić kilkunastu dostawców wspierających IPFIX. Która technologia skaluje się lepiej sFlow czy NetFlow? Próbkowanie pakietów może być wykonywane przez sFlow albo NetFlow w sposób, który nie jest do przyjęcia przez większość klientów. Na przykład, masywne wzmożenie się ruchu (np. DoS attack) spowodowałoby w analizie sFlow generowanie nadmiarowych próbek, które potrzebne są do zachowania zasady próbkowania 1:N. Przy analizie NetFlow, liczba dodatkowych próbek sprowadzona zostanie do kilku próbek w których pojawiłyby się duże wartości ruchu. W tym przykładzie ilość dodatkowej pracy dla NetFlow jest minimalna zwłaszcza jeśli porównujemy te technologie w ramach podobnego sprzętu. Spójrzmy na dość stary, ale jednak wartościowy artykuł w NetworkWorld opisujący sFlow oraz NetFlow, gdzie omawiane są obie technologie. NetFlow podaje szczegóły dotyczące 100% ruchu w czasie rzeczywistym natomiast sFlow poprzez charakter próbkowania, często gubi ruch co czyni sFlow prawie bezużytecznym dla wykrywania zagrożeń i analizy nadużyć w sieciach IP. Jeśli sFlow nie może próbkować wystarczająco szybko użytecznych metryk lub jeśli ruch Netflow po prostu przeciąża Twój kolektor przepływu uważam, że najlepszym wyjściem jest przełączenie się na technologię Flexible NetFlow gdzie użytkownik dostaje wybór jakie informacje trafiają do kolektora jednocześnie nie odpuszczając 100% dokładności w analizie. Rozważmy następującą redukcję pól gdzie ich liczba została zmniejszona z 7 pól do 5. Proponowane pola: Interfejs źródłowy Typ usługi Źródłowy adres IP Docelowy adres IP Protokół IP Jeśli odrzucimy pola „Źródło w warstwie 4” oraz „Port” z przesyłanych datagramów Netflow to wyeksportowana wielkość przepływu spadnie do 75 %. Jeśli naprawdę chcesz uzyskać informacje szczegółowe o aplikacjach, radzimy zmniejszyć liczbę generowanych pakietów Netflow a uruchomienie eksportu obiektów NBAR, co drastycznie zmniejsza objętość przepływu. Jeśli muszę próbkować, to co wybrać: próbkowanie przepływu czy próbek pakietów? Jeśli musisz próbkować, zawsze najlepszym wyjściem jest próbkowanie przepływu a nie pakietów. Wybierając jeden pakiet z 1000 lub zmniejszając częstotliwości próbkowania do jednego z każdego 100.000 znacznie zamazujemy obraz obserwowanej transmisji. Podczas pobierania próbek z przepływu, przepływ z 10 pakietów jest tak samo próbkowany jak przepływ ze 100.000 pakietów. W rezultacie, jeśli próbuje uzyskać reprezentatywny obraz pracujących aplikacji w sieci to próbkowanie przepływu zwiększa prawdopodobieństwo uzyskania poprawnego obrazu, ponieważ wszystkie próbki flow traktowane są równorzędnie. Próbkowanie pakietów będzie w stanie pokazać najpopularniejsze aplikacje generujące największą liczbę pakietów. Ruch incydentalny, niosący ze sobą niewiele próbek danych może być całkowicie pominięty. Próbkowanie danych Flow pozwala obserwować ruch zarówno aplikacji z dużym natężeniem pakietów jak i ruch incydentalny. Warto pamiętać, że zarówno sFlow i NetFlow w zależności od używanego sprzętu obsługują próbkowanie w czasie rzeczywistym. Jeśli NetFlow jest lepszy niż sFlow, to dlaczego ktoś miałby kiedykolwiek użyć sFlow? Odpowiedź na to pytanie sprowadza się do wyboru. Wiele przełączników dziś obsługuje tylko sFlow. Firma InMon umożliwiła producentom sprzętu bardzo tanią implementację sFlow przez co wielu producentów sprzętu wspiera sFlow za wyjątkiem Cisco. Dzisiaj, wielu klientów myśli, że mają tylko jeden wybór w odniesieniu do przełączników: sFlow. Istnieje jednak kilku dostawców, którzy implementują Netflow, w tym: Cisco wspierające NetFlow i IPFIX w przełącznikach np. Cisco 3750X z modułem 3KX lub 3850. Podsumowanie Ze względu na większe wsparcie społecznościowe dla IPFIX (np. Astaro, Barracuda, Cisco, Citrix, Dell, Enterasys, Plixer itp.), pojawiające się innowacje w tym zakresie są imponujące. Export danych może zawierać: Wiadomości dziennika (Cisco ASA odmawia połączenia) Wykrytych wiadomości wirusów (Dell SonicWALL) VoIP (Cisco Monitorowanie wydajności i SonicWALL) Strata Jitter i Packet Caller ID Codec SSRC Opóźnienie lub Round Trip Time (Cisco, Citrix, Plixer) URL (Citrix, Dell SonicWALL, Barracuda, Plixer) Przekierowane połączenia (Cisco PFR) Wireless LAN IDs (Cisco) Nazwy użytkowników końcowych login (Cisco, Dell SonicWALL, Palo Alto) [*]Z drugiej strony, nie ma znaczącego udziału społeczności w technologię sFlow (tylko InMon) i należy się spodziewać, że innowacje pochodzące z tej firmy będą mniejsze w porównaniu z tymi pochodzącymi od pozostałych producentów implementujących NetFlow i IPFIX. Wreszcie, jeśli poprosić każdego klienta, który posiada sieć z urządzeń wspierających zarówno sFlow oraz NetFlow, z pewnością powie : "Wolę zbierać NetFlow ale sFlow jest lepsze niż nic."