Protocollo di esportazione del flusso di tuo padre (parte 1)

Potresti avere familiarità con NetFlow, IPFIX e altri protocolli simili come J-Flow e sFlow. Questi protocolli forniscono informazioni utili sul mix di traffico e sulle comunità di interesse. Tuttavia, questi protocolli non contengono i dettagli a livello di applicazione desiderati da alcuni amministratori. Gli amministratori IT necessitano di maggiore visibilità a livello di applicazione per poter eseguire Application Performance Management (APM) e risolvere i problemi a livello di applicazione. I protocolli attuali basati sul flusso mancano di dettagli a livello di applicazione necessari per eseguire analisi e risoluzione dei problemi più approfondite.

Lezione sulla storia di NetFlow:

Negli anni '90, NetFlow versione 5 è nata come protocollo proprietario di Cisco Systems per l'acquisizione e l'invio di informazioni sui flussi di traffico di rete verso un punto di raccolta. NetFlow può essere abilitato su dispositivi di rete che utilizzano Cisco Press Forwarding (CEF). Il dispositivo abilitato NetFlow acquisisce informazioni sui flussi di rete IP che attraversano l'interfaccia e invia i dati sui flussi nei pacchetti UDP a un sistema di raccolta. Il raccoglitore NetFlow è in genere un computer che esegue il software di raccolta e analisi. NetFlow è diventato molto popolare nell'ultimo decennio e ora ci sono una moltitudine di aziende che supportano NetFlow sui loro dispositivi e molte aziende che producono utilità di raccolta e analisi NetFlow.

A causa del sovraccarico di elaborazione aggiuntivo richiesto per supportare NetFlow, non era adatto per l'uso su molti dispositivi di rete. Cisco ha sviluppato Sampled NetFlow, Deterministic Netflow e Random Sampled NetFlow per ridurre le spese generali di esecuzione di NetFlow su dispositivi occupati, ma mantenendo comunque una certa visibilità sul traffico. Successivamente, Cisco ha sviluppato NetFlow flessibile che consente l'invio a un raccoglitore di livello 2, IPv6 e altri tipi di dati.

NetFlow e IPFIX:

Quando NetFlow ha iniziato a guadagnare popolarità, NetFlow versione 9 ha aggiunto i dettagli del flusso per le reti MPLS e i flussi di dati IPv6. NetFlow è iniziato come un protocollo proprietario Cisco, ma è stato documentato in una RFC 3954 informativa IETF nel 2004. L'IETF ha iniziato a lavorare su Internet Protocol Flow Information eXport (IPFIX) nel 2004. I requisiti IPFIX sono stati documentati per la prima volta in RFC 3917. In realtà, NetFlow v9 era la base per lo standard IETF IPFIX. Il fatto è che IPFIX e NetFlow v9 condividono molti tipi di campi. NetFlow e IPFIX si sono uniti in NetFlow v10 e standardizzati con RFC 5101, RFC 5102, RFC 5103 e RFC 5655. Il modello informativo di IPFIX è stato aggiornato con RFC 6313. IPFIX è stato ora aggiornato nei seguenti RFC IETF 7011, 7012, 7013, 7014 e 7015. Molti prodotti del fornitore ora supportano IPFIX.

Altri protocolli di esportazione del flusso:

Poiché NetFlow era inizialmente visto come un metodo di flusso proprietario di Cisco, altri fornitori volevano sviluppare i propri protocolli o collaborare su protocolli di flusso più "aperti" per lavorare sul proprio hardware. Esistono molti altri protocolli di analisi del traffico di rete basati sul flusso e alcuni sono utilizzati solo da un singolo fornitore.

J-Flow v5 / v8 / v9 è un protocollo di monitoraggio basato sul flusso sviluppato da Juniper Networks. Funziona sui loro dispositivi JUNOS e J-Flow è interoperabile con i collezionisti compatibili con NetFlow.

sFlow è l'ennesimo protocollo di campionamento dei pacchetti che invia informazioni sui flussi a un raccoglitore. sFlow è supportato da un'organizzazione del settore che aiuta a guidare l'adozione del protocollo. La differenza tra sFlow e altri protocolli di esportazione del flusso è che è possibile eseguire il campionamento dei pacchetti anziché solo l'esportazione basata sul flusso. Il campionamento dei pacchetti può migliorare le prestazioni della tecnica riducendo l'onere ambientale sul dispositivo di rete. sFlow versione 5 ha un ampio supporto per i fornitori.

NetStream è un altro protocollo di esportazione basato sul flusso utilizzato da 3Com / HP / Huawei.

Ericsson ha anche il proprio protocollo RFlow.

I sistemi OpenBSD possono utilizzare pflow (flusso pseudo-dispositivo) come metodo di esportazione dei dati di flusso. pFlow è compatibile con NetFlow v5 / v9 e v10 (IPFIX).

Limitazioni dei protocolli di flusso di rete:

La limitazione con tutti i protocolli di analisi di rete basati sul flusso è che mancano di granularità nel traffico. Nulla fornisce più dettagli nel traffico della decodifica di protocollo effettiva con un analizzatore di protocollo. Tuttavia, l'acquisizione di pacchetti non elaborati può essere un onere per le prestazioni su un dispositivo di rete e la memorizzazione di tutte queste informazioni potrebbe essere costosa. L'acquisizione di pacchetti può essere un'opzione praticabile per la risoluzione dei problemi e i test di breve durata, ma non è una soluzione sostenibile per la pianificazione della capacità, le tendenze e l'analisi a lungo termine.

Inoltre, la possibilità di eseguire acquisizioni di pacchetti in molti punti attraverso la topologia di rete non è di solito un'opzione. L'impostazione di un numero maggiore di tocchi di connessioni SPAN / port-mirroring potrebbe essere impossibile. Non hai sempre uno switch di monitoraggio dei pacchetti pronto o un Cisco eXtensible Network Controller (XNC) che esegue l'applicazione Monitor Manager con gli switch Nexus 3000 già configurati.

Oggi stiamo sperimentando anche un volto mutevole della topologia IT. I sistemi che prima erano situati all'interno delle strutture di un'azienda ora sono passati a un'infrastruttura basata su cloud. Non tutte le applicazioni sono inserite in modo sicuro nel data center aziendale e vi si accede tramite la WAN aziendale interna. Ciò rende più difficile eseguire l'analisi del protocollo delle applicazioni basate su cloud. Ci manca anche la capacità di eseguire acquisizioni di pacchetti su servizi basati su cloud o su piattaforme di virtualizzazione. Di conseguenza, molte applicazioni non hanno la visibilità di cui hanno bisogno per essere in grado di eseguire analisi dettagliate delle applicazioni o risolvere i problemi.

Sommario:

Le aziende hanno bisogno di modi migliori per essere in grado di comprendere il traffico delle applicazioni che attraversa i propri sistemi on-premise e basati su cloud. NetFlow e IPFIX sono utili, ma mancano della granularità di un'acquisizione completa del protocollo. Tuttavia, l'acquisizione del traffico non elaborato potrebbe non essere un'opzione a seconda della topologia. Sempre più problemi relativi alle prestazioni delle applicazioni hanno richiesto maggiore visibilità per poter risolvere i problemi. Ci sono altri protocolli che potrebbero essere disponibili che ci danno la visibilità che desideriamo.

Nella seconda parte di questo articolo tratteremo un nuovo protocollo di analisi del flusso che fornisce queste informazioni utili.

Scott

Unisciti alle community di Network World su Facebook e LinkedIn per commentare argomenti che sono importanti.