09. 06. 2016 Luca Di Stefano Uncategorized

Network Performance Monitoring: Port Mirroring vs. Network TAPs vs. Hardware Timestamp

Fino a poco tempo fa, il monitoring del traffico di rete era unicamente finalizzato ad evidenziare la tipologia di traffico e la quantità di pacchetti/byte trasmessi nel tempo.
Queste informazioni risultano fondamentali per l’analisi di anomalie, per l’ottimizzazione dei flussi (bilanciamento del traffico) e per il dimensionamento dell’infrastruttura.

Per la raccolta delle informazioni sul traffico di rete, generalmente si usa il protocollo NetFlow. Questo può essere generato dagli apparati di rete stessi (se hanno implementato questa funzionalità) o da apparati ad-hoc come le nBox. L’uso di una nBox è consigliato in quanto evita un carico di lavoro aggiuntivo nell’apparato di rete per la generazione del NetFlow. Un ulteriore vantaggio nell’uso di una nBox è il fatto che il NetFlow non viene campionato ed i flussi generati non vengono aggregati a 5 minuti come avviene solitamente negli apparati di rete.

Nel caso si usi un apparato esterno per generare il netflow, spesso si usa un port mirror che duplica il traffico e lo invia alla sonda.

Per l’analisi quantitativa del traffico, le caratteristiche di un port mirror non sono particolarmente stringenti, si richiede che tutti i pacchetti siano inoltrati alla sonda in un tempo ragionevole.

Con l’avvento di sistemi di monitoraggio delle performance della rete e dei servizi (APM NPM) i requisiti del meccanismo port span o port mirror sono diventati più stringenti.

Port Mirroring

Il tempo di elaborazione dello switch per eseguire la copia del pacchetto, il suo l’accodamento e l’invio verso la sonda, può risultare troppo invasivo, specialmente se si tratta di valutare latenze di rete dell’ordine di microsecondi come nelle reti moderne.  Si aggiunga il fatto che alcuni apparati di rete, non inoltrano immediatamente i pacchetti in uscita dal port mirror ma aspettano che la coda di uscita contenga un certo numero di pacchetti. Questo significa annullare la distanza temporale tra un pacchetto e l’altro nella coda e quindi falsare i rilevamenti effettuati dalla sonda.

Port Mirroring

È importante considerare che nel caso in cui si usi il port mirroring il tempo intercoso tra packet ingress e packet egress del mirror può essere rilevante.

Per ovviare a questi problemi esistono due soluzioni: i network TAP e l’hardware timestamp.

Network TAP

I network TAP sono degli apparecchi il cui unico scopo è eseguire immediatamente il mirror del traffico per poter collegare una sonda.

Network TAP

Sono molto affidabili , garantiscono zero perdite di pacchetti sul mirror (cosa che al contrario si potrebbe avere su un port mirror non correttamente dimensionato), non fanno buffering e riducono il carico di lavoro allo switch. Ne esistono per connessioni in rame e fibra e sono una soluzione economica.

TAP Fibra TAP Rame

Hardware Timestamp

In commercio esistono switch che prima di accodare i pacchetti nel buffer di uscita del port mirror aggiungono un timestamp al pacchetto. Nel caso esista questo timestamp ‘hardware’ la sonda nBox utilizzerà questo al posto del timestamp preso nel momento della ricezione del pacchetto, eliminando così le latenze introdotte dal tempo di elaborazione e di inoltro introdotti dal port mirror. Questi apparati sono più costosi ma offrono maggiore flessibilità (mirror di più porte, configurazione a caldo).

Port Mirroring with Hardware Timestamp

In conclusione i port mirror svolgono egregiamente il loro lavoro per le finalità di IDS (Intrusion Detection System) o analisi quantitative del traffico, mentre per il monitoraggio di performance dove i tempi sono molto importanti, la miglior soluzione risulta essere un network TAP

 

Luca Di Stefano

Luca Di Stefano

Solution Architect at Würth Phoenix
Hi everyone, I’m Luca, graduated in electrical engineering from the University of Bologna. I am employed by Würth Phoenix since its foundation. I worked mainly as enterprise architect and quality assurance engineer. Previously I was involved in systems measurement and embedded systems programming. I have gained experience on Unix (Solaris, HPUX), Windows, and C, C + +, Java. I personally contribute to the Open Source community as beta tester and developer. During my spare time I love piloting airplanes fly over the beautiful Alps. I practice many sports: tennis, broomball, skiing, alpine skiing, volleyball, soccer, mountain biking, middle distance, none have a sample but the competition excites me! I love hiking, tracking and traveling.

Author

Luca Di Stefano

Hi everyone, I’m Luca, graduated in electrical engineering from the University of Bologna. I am employed by Würth Phoenix since its foundation. I worked mainly as enterprise architect and quality assurance engineer. Previously I was involved in systems measurement and embedded systems programming. I have gained experience on Unix (Solaris, HPUX), Windows, and C, C + +, Java. I personally contribute to the Open Source community as beta tester and developer. During my spare time I love piloting airplanes fly over the beautiful Alps. I practice many sports: tennis, broomball, skiing, alpine skiing, volleyball, soccer, mountain biking, middle distance, none have a sample but the competition excites me! I love hiking, tracking and traveling.

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive