Your Father's Flow Export Protocol (del 1)

Du kanske känner till NetFlow, IPFIX och andra liknande protokoll som J-Flow och sFlow. Dessa protokoll ger användbar insikt i trafikmix och samhällen av intresse. Dessa protokoll innehåller emellertid inte de applikationslagerdetaljer som vissa administratörer önskar. IT-administratörer behöver mer synlighet på applikationsnivå för att kunna utföra APM (Application Performance Management) och felsöka problem i applikationslagret. Aktuella flödesbaserade protokoll saknar applikationslagerdetaljer som behövs för att utföra djupare analys och felsökning.

NetFlow historielektion:

På 1990-talet började NetFlow version 5 som ett Cisco Systems egenutvecklade protokoll för att fånga och skicka information om nätverkstrafikflöden till en insamlingsplats. NetFlow kan aktiveras på nätverksenheter som använder Cisco Press Forwarding (CEF). Den NetFlow-aktiverade enheten fångar information om IP-nätverksströmmar som går igenom gränssnittet och skickar data om flödena i UDP-paket till ett samlersystem. NetFlow-samlaren är vanligtvis en dator som använder insamlings- och analysprogramvaran. NetFlow har blivit mycket populärt under det senaste decenniet och nu finns det en mängd företag som stöder NetFlow på sina enheter och många företag som gör NetFlow-samlings- och analysverktyg.

På grund av den extra bearbetningskostnad som krävs för att stödja NetFlow var den inte lämplig för användning på många nätverksenheter. Cisco utvecklade Sampled NetFlow, Deterministic Netflow och Random Sampled NetFlow för att minska omkostnaderna för att köra NetFlow på upptagna enheter men fortfarande ger viss trafiksynlighet. Senare utvecklade Cisco Flexible NetFlow som gör det möjligt att skicka lager 2, IPv6 och andra typer av data till en samlare.

NetFlow och IPFIX:

När NetFlow började bli mer populärt, har NetFlow version 9 lagt till flödesdetaljer för MPLS-nätverk och IPv6-dataflöden. NetFlow började som ett Cisco-proprietärt protokoll, men dokumenterades i en IETF-information RFC 3954 2004. IETF började arbeta med Internet Protocol Flow Information eXport (IPFIX) 2004. IPFIX-krav dokumenterades först i RFC 3917. I själva verket NetFlow v9 var grunden för IETF IPFIX-standarden. Faktum är att IPFIX och NetFlow v9 delar många fälttyper. NetFlow och IPFIX har gått samman i NetFlow v10 och standardiserats med RFC 5101, RFC 5102, RFC 5103 och RFC 5655. IPFIXs informationsmodell uppdaterades med RFC 6313. IPFIX har uppdaterats nu i följande IETF RFCs 7011, 7012, 7013, 7014 och 7015. Många leverantörs produkter stöder nu IPFIX.

Andra flödesexportprotokoll:

Eftersom NetFlow ursprungligen sågs som en Cisco-proprietär flödesmetod, ville andra leverantörer utveckla sina egna protokoll eller samarbeta om mer "öppna" flödesprotokoll för att arbeta med sin egen hårdvara. Det finns många andra flödesbaserade protokoll för analys av nätverkstrafik och vissa används endast av en enda leverantör.

J-Flow v5 / v8 / v9 är ett flödesbaserat övervakningsprotokoll som utvecklades av Juniper Networks. Den körs på deras JUNOS-enheter och J-Flow är interoperabelt med NetFlow-kapabla samlare.

sFlow är ännu ett paketprovtagningsprotokoll som skickar information om flöden till en samlare. sFlow stöds av en branschorganisation som hjälper till att driva antagandet av protokollet. Skillnaden mellan sFlow och andra flödesexportprotokoll är att det kan utföra paketprover istället för bara flödesbaserad export. Paketprovtagning kan förbättra teknikens prestanda genom att minska den övre belastningen på nätverksenheten. sFlow version 5 har bred leverantörsstöd.

NetStream är ett annat flödesbaserat exportprotokoll som används av 3Com / HP / Huawei.

Ericsson har också sitt eget RFlow-protokoll.

OpenBSD-system kan använda pflow (pseudo-enhetsflöde) som deras metod för att exportera flödesdata. pFlow är kompatibel med NetFlow v5 / v9 och v10 (IPFIX).

Begränsningar av nätverksflödesprotokoll:

Begränsningen med alla flödesbaserade nätverksanalysprotokoll är att de saknar granulitet i trafiken. Ingenting ger mer information i trafiken än den faktiska protokollavkodningen med en protokollanalysator. Att fånga råpaket kan emellertid vara en prestationsbörda för en nätverksenhet och lagra all denna information kan vara dyrt. Paketupptagningar kan vara ett genomförbart alternativ för felsökning och testning med kort varaktighet, men det är inte en hållbar lösning för kapacitetsplanering, trending och långsiktig analys.

Dessutom är förmågan att utföra paketinspelningar på många punkter genom nätverkstopologin vanligtvis inte ett alternativ. Det kan vara omöjligt att ställa in ett större antal kranar med SPAN / portspegelanslutningar. Du har inte alltid en paketövervakningsomkopplare i beredskap eller en Cisco eXtensible Network Controller (XNC) som kör Monitor Manager-applikationen med Nexus 3000-switchar redan inställda.

Idag upplever vi också en förändring av IT-topologin. System som tidigare låg i ett företags egna anläggningar har nu flyttat till molnbaserad infrastruktur. Inte varje applikation ligger säkert borta i företagets datacenter och nås via det interna företagets WAN. Detta gör utförande av protokollanalys av molnbaserade applikationer svårare att utföra. Vi saknar också förmågan att utföra paketfångster på molnbaserade tjänster eller i virtualiseringsplattformar. Som ett resultat saknar många applikationer den synlighet de behöver för att kunna utföra detaljerad applikationsanalys eller felsöka problem.

Sammanfattning:

Företag behöver bättre sätt att kunna förstå applikationstrafiken genom att använda sina lokala och molnbaserade system. NetFlow och IPFIX är användbara, men saknar granuliteten hos en fullständig protokollinspelning. Det är dock kanske inte ett alternativ att fånga rå trafik beroende på topologin. Fler och fler applikationsrelaterade prestandaproblem krävde mer synlighet för att kunna felsöka. Det finns andra protokoll som kan finnas tillgängliga som ger oss den synlighet som vi önskar.

I den andra delen av den här artikeln kommer vi att täcka ett nytt flödesanalysprotokoll som ger denna användbar information.

Scott

Gå med i nätverkets världssamhällen på Facebook och LinkedIn för att kommentera ämnen som är övertygade.