Protokół eksportu przepływu twojego ojca (część 1)

Być może znasz NetFlow, IPFIX i inne podobne protokoły, takie jak J-Flow i sFlow. Te protokoły zapewniają użyteczny wgląd w mieszankę ruchu i interesujące społeczności. Jednak te protokoły nie zawierają szczegółów warstwy aplikacji wymaganych przez niektórych administratorów. Administratorzy IT potrzebują większej widoczności na poziomie aplikacji, aby móc zarządzać wydajnością aplikacji (APM) i rozwiązywać problemy z warstwami aplikacji. W aktualnych protokołach opartych na przepływie brakuje szczegółów warstwy aplikacji, które są potrzebne do głębszej analizy i rozwiązywania problemów.

Lekcja historii NetFlow:

W latach 90. NetFlow w wersji 5 zaczął jako zastrzeżony protokół Cisco Systems do przechwytywania i wysyłania informacji o przepływach ruchu sieciowego do punktu odbioru. NetFlow można włączyć na urządzeniach sieciowych korzystających z Cisco Press Forwarding (CEF). Urządzenie obsługujące NetFlow przechwytuje informacje o strumieniach IP przemierzających interfejs i wysyła dane o przepływach w pakietach UDP do systemu kolektora. Kolektor NetFlow to zazwyczaj komputer z oprogramowaniem do gromadzenia i analizy. NetFlow stał się bardzo popularny w ostatnim dziesięcioleciu, a teraz istnieje wiele firm, które obsługują NetFlow na ich urządzeniach oraz wiele firm, które tworzą narzędzia do gromadzenia i analizy NetFlow.

Ze względu na dodatkowy narzut przetwarzania wymagany do obsługi NetFlow, nie był odpowiedni do użycia na wielu urządzeniach sieciowych. Firma Cisco opracowała Sampled NetFlow, Deterministic Netflow i Random Sampled NetFlow, aby zmniejszyć obciążenie związane z uruchomieniem NetFlow na zajętych urządzeniach, ale nadal zapewnia pewną widoczność ruchu. Później Cisco opracowało Elastyczny NetFlow, który pozwala na wysyłanie do kolektora warstw 2, IPv6 i innych typów danych.

NetFlow i IPFIX:

Gdy NetFlow zaczął zdobywać popularność, NetFlow w wersji 9 dodał szczegóły przepływu dla sieci MPLS i przepływów danych IPv6. NetFlow zaczął jako zastrzeżony protokół Cisco, ale został udokumentowany w informacyjnym dokumencie RFC 3954 IETF w 2004 r. IETF rozpoczął pracę nad protokołem Internet Information Flow eXport (IPFIX) w 2004 r. Wymagania IPFIX zostały po raz pierwszy udokumentowane w RFC 3917. W rzeczywistości NetFlow Wersja 9 była podstawą standardu IETF IPFIX. Faktem jest, że IPFIX i NetFlow v9 mają wiele typów pól. NetFlow i IPFIX połączyły się w NetFlow v10 i ustandaryzowały je z RFC 5101, RFC 5102, RFC 5103 i RFC 5655. Model informacyjny IPFIX został zaktualizowany o RFC 6313. IPFIX został teraz zaktualizowany w następujących dokumentach IETF RFC 7011, 7012, 7013, 7014 i 7015. Wiele produktów dostawcy obsługuje teraz IPFIX.

Inne protokoły eksportu eksportu:

Ponieważ NetFlow był początkowo postrzegany jako zastrzeżona przez firmę Cisco metoda przepływu, inni dostawcy chcieli opracować własne protokoły lub współpracować przy bardziej „otwartych” protokołach przepływu w celu pracy na własnym sprzęcie. Istnieje wiele innych protokołów analizy ruchu sieciowego opartych na przepływie, a niektóre są używane tylko przez jednego dostawcę.

J-Flow v5 / v8 / v9 to oparty na przepływie protokół monitorowania opracowany przez Juniper Networks. Działa na urządzeniach JUNOS, a J-Flow współpracuje z kolektorami obsługującymi NetFlow.

sFlow to kolejny protokół próbkowania pakietów, który wysyła informacje o przepływach do kolektora. sFlow jest wspierany przez organizację branżową, która pomaga przyspieszyć przyjęcie protokołu. Różnica między sFlow a innymi protokołami eksportu przepływu polega na tym, że można wykonać próbkowanie pakietów zamiast tylko eksportu opartego na przepływie. Próbkowanie pakietów może poprawić wydajność techniki, zmniejszając obciążenie urządzenia sieciowego. Wersja sFlow 5 ma szeroką obsługę dostawców.

NetStream to kolejny oparty na przepływach protokół eksportowy używany przez 3Com / HP / Huawei.

Ericsson ma również własny protokół RFlow.

Systemy OpenBSD mogą wykorzystywać pflow (przepływ pseudo-urządzeń) jako metodę eksportowania danych przepływu. pFlow jest kompatybilny z NetFlow v5 / v9 i v10 (IPFIX).

Ograniczenia protokołów przepływu sieci:

Ograniczeniem wszystkich protokołów analizy sieci opartej na przepływie jest to, że nie mają one szczegółowości w ruchu. Nic nie dostarcza więcej szczegółów na temat ruchu niż rzeczywiste dekodowanie protokołu za pomocą analizatora protokołów. Jednak przechwytywanie nieprzetworzonych pakietów może być obciążeniem wydajności urządzenia sieciowego, a przechowywanie wszystkich tych informacji może być kosztowne. Przechwytywanie pakietów może być realną opcją do krótkotrwałego rozwiązywania problemów i testowania, ale nie jest to trwałe rozwiązanie do planowania wydajności, trendów i analizy długoterminowej.

Ponadto zdolność do przechwytywania pakietów w wielu punktach za pośrednictwem topologii sieci zwykle nie jest opcją. Utworzenie większej liczby dotknięć połączeń SPAN / dublowanie portów może być niemożliwe. Nie zawsze masz gotowy przełącznik monitorowania pakietu lub kontroler sieci Cisco eXtensible Network Controller (XNC) z uruchomioną aplikacją Monitor Manager z już skonfigurowanymi przełącznikami Nexus 3000.

Dziś doświadczamy również zmieniającego się oblicza topologii IT. Systemy, które kiedyś znajdowały się we własnych obiektach przedsiębiorstwa, teraz przeszły na infrastrukturę chmurową. Nie każda aplikacja jest bezpiecznie umieszczona w korporacyjnym centrum danych i jest dostępna przez wewnętrzną korporacyjną sieć WAN. Utrudnia to wykonywanie analizy protokołów aplikacji w chmurze. Brakuje nam również możliwości przechwytywania pakietów w usługach chmurowych lub na platformach wirtualizacyjnych. W rezultacie wiele aplikacji nie ma widoczności, aby móc przeprowadzić szczegółową analizę aplikacji lub rozwiązać problemy.

Podsumowanie:

Przedsiębiorstwa potrzebują lepszych sposobów na zrozumienie ruchu aplikacji przechodzącego przez systemy lokalne i chmurowe. NetFlow i IPFIX są przydatne, ale brak szczegółowości przechwytywania pełnego protokołu. Jednak przechwytywanie nieprzetworzonego ruchu może nie być opcją zależną od topologii. Coraz więcej problemów związanych z wydajnością aplikacji wymagało większej widoczności, aby móc rozwiązać problemy. Istnieją inne protokoły, które mogą być dostępne, które zapewniają nam pożądaną widoczność.

W drugiej części tego artykułu omówimy nowy protokół analizy przepływu, który zawiera te przydatne informacje.

Scott

Dołącz do społeczności Network World na Facebooku i LinkedIn, aby komentować najważniejsze tematy.