Din fars Flow Export Protocol (del 1)

Du kender måske NetFlow, IPFIX og andre lignende protokoller som J-Flow og sFlow. Disse protokoller giver nyttig indsigt i trafikmix og samfund af interesse. Disse protokoller indeholder dog ikke de applikationslagdetaljer, som nogle administratorer ønsker. IT-administratorer har brug for mere synlighed på applikationsniveau for at være i stand til at udføre Application Performance Management (APM) og fejlfinde applikationslagsproblemer. Aktuelle flowbaserede protokoller mangler applikationslagdetaljer, der er nødvendige for at udføre dybere analyse og fejlfinding.

NetFlow historielektion:

I 1990'erne startede NetFlow version 5 som en Cisco Systems proprietær protokol til indfangning og afsendelse af oplysninger om netværkstrafikstrømme til et indsamlingssted. NetFlow kan aktiveres på netværksenheder, der bruger Cisco Press Forwarding (CEF). Den NetFlow-aktiverede enhed indfanger oplysninger om IP-netværksstrømme, der krydser grænsefladen og sender data om strømningerne i UDP-pakker til et samlersystem. NetFlow-samleren er typisk en computer, der kører indsamlings- og analysesoftwaren. NetFlow er blevet meget populært i det sidste årti, og nu er der en række virksomheder, der understøtter NetFlow på deres enheder, og mange virksomheder, der fremstiller NetFlow-indsamlings- og analyseværktøjer.

På grund af den ekstra behandlingsomkostning, der kræves for at understøtte NetFlow, var den ikke egnet til brug på mange netværksenheder. Cisco udviklede Sampled NetFlow, Deterministic Netflow og Random Sampled NetFlow for at reducere omkostningen ved at køre NetFlow på travle enheder, men stadig give en vis trafiksynlighed. Senere udviklede Cisco Fleksibel NetFlow, som gør det muligt at sende lag 2, IPv6 og andre typer data til en samler.

NetFlow og IPFIX:

Da NetFlow begyndte at vinde popularitet, tilføjede NetFlow version 9 flowdetaljer for MPLS-netværk og IPv6-datastrømme. NetFlow startede som en Cisco-proprietær protokol, men blev dokumenteret i en IETF-information RFC 3954 i 2004. IETF begyndte at arbejde med Internet Protocol Flow Information eXport (IPFIX) i 2004. IPFIX-krav blev først dokumenteret i RFC 3917. Faktisk NetFlow v9 var grundlaget for IETF IPFIX-standarden. Faktum er, at IPFIX og NetFlow v9 deler mange felttyper. NetFlow og IPFIX er samlet i NetFlow v10 og standardiseret med RFC 5101, RFC 5102, RFC 5103 og RFC 5655. IPFIXs informationsmodel blev opdateret med RFC 6313. IPFIX er blevet opdateret nu i følgende IETF RFCs 7011, 7012, 7013, 7014 , og 7015. Mange sælgers produkter understøtter nu IPFIX.

Andre floweksportprotokoller:

Da NetFlow oprindeligt blev betragtet som en Cisco-proprietær flowmetode, ønskede andre leverandører at udvikle deres egne protokoller eller samarbejde om mere “åbne” flowprotokoller for at arbejde på deres egen hardware. Der er mange andre flowbaserede netværkstrafikanalyseprotokoller, og nogle bruges kun af en enkelt leverandør.

J-Flow v5 / v8 / v9 er en flow-baseret overvågningsprotokol, der blev udviklet af Juniper Networks. Det kører på deres JUNOS-enheder, og J-Flow er interoperabel med NetFlow-kompatible samlere.

sFlow er endnu en pakkeudtagningsprotokol, der sender information om strømme til en samler. sFlow understøttes af en brancheorganisation, der hjælper med at drive vedtagelse af protokollen. Forskellen mellem sFlow og andre flow-eksportprotokoller er, at det er kan udføre pakkesampling i stedet for blot flowbaseret eksport. Pakkeudtagning kan forbedre teknikens ydelse ved at reducere overheadbelastningen på netværksenheden. sFlow version 5 har bred sælgersupport.

NetStream er en anden flowbaseret eksportprotokol, der bruges af 3Com / HP / Huawei.

Ericsson har også deres egen RFlow-protokol.

OpenBSD-systemer kan bruge pflow (pseudo-enhedsstrøm) som deres metode til at eksportere flowdata. pFlow er kompatibel med NetFlow v5 / v9 og v10 (IPFIX).

Begrænsninger af netværksflowprotokoller:

Begrænsningen med alle flowbaserede netværksanalyseprotokoller er, at de mangler granularitet i trafikken. Intet giver flere detaljer i trafikken end den faktiske protokollekodning med en protokolanalysator. At fange rå pakker kan imidlertid være en ydelsesbyrde for en netværksenhed og lagring af al denne information kan være dyrt. Pakkeoptagelser kan være en levedygtig mulighed til fejlfinding og test af kortvarig periode, men det er ikke en bæredygtig løsning til kapacitetsplanlægning, trending og langtidsanalyse.

Desuden er muligheden for at udføre pakkeoptagelser på mange punkter gennem netværkstopologien normalt ikke en mulighed. Det kan være umuligt at indstille et større antal vandhaner med SPAN / port-spejlforbindelser. Du har ikke altid en pakkeovervågningskontakt klar, eller en Cisco eXtensible Network Controller (XNC), der kører Monitor Manager-applikationen med Nexus 3000-switches allerede konfigureret.

I dag oplever vi også et skiftende ansigt for IT-topologien. Systemer, der tidligere var placeret i en virksomheds egne faciliteter, er nu flyttet til skybaseret infrastruktur. Ikke alle applikationer ligger sikkert inde i virksomhedens datacenter og fås adgang til det interne virksomheds WAN. Dette gør udførelse af protokollanalyse af skybaserede applikationer vanskeligere at udføre. Vi mangler også evnen til at udføre pakkeoptagelser på skybaserede tjenester eller i virtualiseringsplatforme. Som et resultat mangler mange applikationer den synlighed, de har brug for for at kunne udføre detaljeret applikationsanalyse eller fejlfinding af problemer.

Resumé:

Virksomheder har brug for bedre måder at være i stand til at forstå applikationstrafikken gennem deres on-premiss- og cloud-basesystemer. NetFlow og IPFIX er nyttige, men mangler granulariteten i en fuld protokoloptagelse. Imidlertid er det muligvis ikke en mulighed at fange rå trafik, afhængigt af topologien. Flere og flere applikationsrelaterede ydelsesproblemer krævede mere synlighed for at kunne fejlfinde. Der er andre protokoller, der muligvis er tilgængelige, og som giver os den synlighed, vi ønsker.

I den anden del af denne artikel vil vi dække en ny flowanalyseprotokol, der giver disse nyttige oplysninger.

Scott

Deltag i Network World-samfundene på Facebook og LinkedIn for at kommentere emner, der er øverste af sindet.