05. 03. 2024
Unified Monitoring
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.
È 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.
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.
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).
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
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
Latest posts by Luca Di Stefano
27. 04. 2017
Uncategorized
Chi si sta mangiando la banda? Scoprilo con ntopng
27. 04. 2017
Uncategorized
Identifizieren Sie Bandbreitenfresser mit ntopng
22. 09. 2016
NetEye, Real User Experience Monitoring
Warum erhöht sich meine Netzwerk-Latenz an Arbeitstagen?
22. 09. 2016
NetEye, Predictive Analysis, Real User Experience, Unified Monitoring
Why does my local network latency increase during working hours?