Het Flow Export Protocol van je vader (deel 1)

U bent wellicht bekend met NetFlow, IPFIX en andere vergelijkbare protocollen zoals J-Flow en sFlow. Deze protocollen bieden nuttig inzicht in de verkeersmix en de interessegemeenschappen. Deze protocollen bevatten echter niet de toepassingslaagdetails die sommige beheerders wensen. IT-beheerders hebben meer zichtbaarheid op applicatieniveau nodig om Application Performance Management (APM) uit te kunnen voeren en problemen met applicatielagen op te lossen. Huidige stroomgebaseerde protocollen missen details van de toepassingslaag die nodig zijn om diepere analyse en probleemoplossing uit te voeren.

NetFlow geschiedenisles:

In de jaren negentig begon NetFlow versie 5 als een eigen protocol van Cisco Systems voor het vastleggen en verzenden van informatie over netwerkverkeersstromen naar een verzamelpunt. NetFlow kan worden ingeschakeld op netwerkapparaten die gebruikmaken van Cisco Press Forwarding (CEF). Het voor NetFlow geschikte apparaat legt informatie vast over IP-netwerkstromen die de interface doorlopen en verzendt de gegevens over de stromen in UDP-pakketten naar een collectorsysteem. De NetFlow-verzamelaar is doorgaans een computer waarop de verzamel- en analysesoftware wordt uitgevoerd. NetFlow is het afgelopen decennium erg populair geworden en nu zijn er een groot aantal bedrijven die NetFlow op hun apparaten ondersteunen en veel bedrijven die NetFlow-hulpprogramma's voor het verzamelen en analyseren maken.

Vanwege de extra verwerkingsoverhead die nodig is om NetFlow te ondersteunen, was het niet geschikt voor gebruik op veel netwerkapparaten. Cisco heeft Sampled NetFlow, Deterministic Netflow en Random Sampled NetFlow ontwikkeld om de overhead van het draaien van NetFlow op drukke apparaten te verminderen, maar zorgt toch voor enig zicht op het verkeer. Later ontwikkelde Cisco Flexible NetFlow waarmee laag 2, IPv6 en andere soorten gegevens naar een verzamelaar kunnen worden verzonden.

NetFlow en IPFIX:

Toen NetFlow aan populariteit begon te winnen, voegde NetFlow versie 9 stroomdetails toe voor MPLS-netwerken en IPv6-gegevensstromen. NetFlow begon als een eigen protocol van Cisco, maar werd gedocumenteerd in een informatieve RFC 3954 van IETF in 2004. De IETF begon in 2004 te werken aan Internet Protocol Flow Information eXport (IPFIX). IPFIX-vereisten werden voor het eerst gedocumenteerd in RFC 3917. In feite werd NetFlow v9 was de basis voor de IETF IPFIX-standaard. Feit is dat IPFIX en NetFlow v9 veel veldtypen delen. NetFlow en IPFIX zijn samengekomen in NetFlow v10 en gestandaardiseerd met RFC 5101, RFC 5102, RFC 5103 en RFC 5655. Het informatiemodel van IPFIX is bijgewerkt met RFC 6313. IPFIX is nu bijgewerkt in de volgende IETF RFC's 7011, 7012, 7013, 7014 , en 7015. Veel producten van leveranciers ondersteunen nu IPFIX.

Andere Flow Export Protocols:

Omdat NetFlow aanvankelijk werd gezien als een Cisco-eigen stroommethode, wilden andere leveranciers hun eigen protocollen ontwikkelen of samenwerken aan meer 'open' stroomprotocollen om op hun eigen hardware te werken. Er zijn veel andere stroomgebaseerde protocollen voor netwerkverkeeranalyse en sommige worden slechts door één leverancier gebruikt.

J-Flow v5 / v8 / v9 is een stroomgebaseerd monitoringprotocol dat is ontwikkeld door Juniper Networks. Het werkt op hun JUNOS-apparaten en J-Flow is interoperabel met NetFlow-compatibele verzamelaars.

sFlow is nog een ander pakketbemonsteringsprotocol dat informatie over stromen naar een verzamelaar verzendt. sFlow wordt ondersteund door een brancheorganisatie die de acceptatie van het protocol stimuleert. Het verschil tussen sFlow en andere stroomexportprotocollen is dat het pakketbemonstering kan uitvoeren in plaats van alleen stroomgebaseerde export. Pakketbemonstering kan de prestatie van de techniek verbeteren door de overheadbelasting op het netwerkapparaat te verminderen. sFlow versie 5 heeft brede leveranciersondersteuning.

NetStream is een ander stroomgebaseerd exportprotocol dat wordt gebruikt door 3Com / HP / Huawei.

Ericsson heeft ook een eigen RFlow-protocol.

OpenBSD-systemen kunnen pflow (pseudo-apparaatstroom) gebruiken als hun methode om stroomgegevens te exporteren. pFlow is compatibel met NetFlow v5 / v9 en v10 (IPFIX).

Beperkingen van netwerkstroomprotocollen:

De beperking met alle stroomgebaseerde netwerkanalyseprotocollen is dat ze niet gedetailleerd zijn in het verkeer. Niets geeft meer details over het verkeer dan de daadwerkelijke protocoldecodering met een protocolanalysator. Het vastleggen van onbewerkte pakketten kan echter een prestatiedruk zijn op een netwerkapparaat en het opslaan van al die informatie kan duur zijn. Het vastleggen van pakketten is misschien een haalbare optie voor het oplossen en testen van korte duur, maar het is geen duurzame oplossing voor capaciteitsplanning, trending en analyse op lange termijn.

Bovendien is de mogelijkheid om pakketopnames op veel punten uit te voeren via de netwerktopologie meestal geen optie. Het opzetten van een groter aantal tikken van SPAN / poort-mirroring-verbindingen kan onmogelijk zijn. U hebt niet altijd een pakketbewakingsschakelaar bij de hand of een Cisco eXtensible Network Controller (XNC) met de Monitor Manager-applicatie met Nexus 3000-switches die al zijn ingesteld.

Vandaag ervaren we ook een veranderend gezicht van de IT-topologie. Systemen die zich vroeger binnen de eigen faciliteiten van een onderneming bevonden, zijn nu verplaatst naar een cloudgebaseerde infrastructuur. Niet elke applicatie is veilig weggestopt in het bedrijfsdatacenter en toegankelijk via het interne bedrijfs-WAN. Dit maakt het uitvoeren van protocolanalyses van cloudgebaseerde applicaties moeilijker. We missen ook de mogelijkheid om pakketvastlegging uit te voeren op cloudgebaseerde services of in virtualisatieplatforms. Als gevolg hiervan missen veel applicaties de zichtbaarheid die ze nodig hebben om een ​​gedetailleerde applicatieanalyse uit te voeren of problemen op te lossen.

Overzicht:

Bedrijven hebben betere manieren nodig om het applicatieverkeer dat hun on-premise- en cloudgebaseerde systemen doorloopt, te begrijpen. NetFlow en IPFIX zijn nuttig, maar missen de granulariteit van een volledige protocolopname. Het vastleggen van onbewerkt verkeer is echter mogelijk geen optie, afhankelijk van de topologie. Steeds meer toepassingsgerelateerde prestatieproblemen vereisten meer zichtbaarheid om problemen op te lossen. Er zijn mogelijk andere protocollen beschikbaar die ons de zichtbaarheid geven die we wensen.

In het tweede deel van dit artikel behandelen we een nieuw stroomanalyseprotocol dat deze nuttige informatie biedt.

Scott

Word lid van de Network World-gemeenschappen op Facebook en LinkedIn om commentaar te geven op onderwerpen die voorop staan.