Molte volte, quando lavoro a un problema, chiedo alle persone di inviarmi una traccia di rete. Una traccia di rete spesso indica la causa alla radice del problema. Come minimo, riduce lo spazio del problema a qualcosa di gestibile. Per esempio, quando una stampante di rete ha iniziato a stampare spazzatura, abbiamo passato diversi giorni a guardare i TTP; quando finalmente abbiamo ricevuto una traccia di rete abbiamo scoperto che stavamo inviando un testo perfetto; il problema era alla stampante. In un altro caso, un problema di prestazioni OSL tra moduli distanti diverse migliaia di chilometri l'uno dall'altro sembrava essere un problema di rete, ma una traccia mostrava chiaramente che il problema era sul modulo server. Lavorerei ancora su entrambi i problemi se non fosse per la traccia di rete.
Come si ottiene una traccia di rete? Ci sono tre possibilità.
monitor_a_pacchetto
Il comando VOS packet_monitor, con alcune limitazioni, permette di monitorare tutto ciò che il modulo invia e riceve dalla rete . Vedere http://community.stratus. .com/blog/openvos/getting-most-out-packetmonitor e http://stratadoc.stratus.com/vos/17.0.1/r419-09/wwhelp/wwhimpl/js/html/wwhelp.html per maggiori informazioni.
Il comando packet_monitor ha diverse limitazioni. Non si può essere sicuri al 100% che un frame che viene segnalato come inviato sia stato effettivamente inviato. Per esempio, errori sull'adattatore possono impedire l'invio del frame. Inoltre, i frame ricevuti con errori, come ad esempio un errore CRC, non saranno inviati a monte in modo che packet_monitor possa vederli. Poiché packet_monitor non mette l'adattatore in modalità promiscua, solo i frame indirizzati all'adattatore o all'indirizzo broadcast verranno trasmessi a monte. Un link può essere occupato al 90% mentre packet_monitor riporta solo 1 frame al secondo perché questo è l'unico frame indirizzato all'adattatore o all'indirizzo broadcast.
In generale, i monitor basati su host, come packet_monitor, sono utili solo come aggiunta ad altre forme di tracciamento, o quando non sono disponibili altre forme di tracciamento di rete.
Porta Mirroring aka SPAN (Switch Port for ANalysis) porta
Una porta mirror o span è una porta su uno switch che replica tutto il traffico visto su una o più porte (o anche su una VLAN) dello switch. La porta mirror deve essere collegata ad un'apparecchiatura di monitoraggio della rete. Questa appliance può essere un dispositivo speciale o un PC con Linux o Microsoft Windows con un monitor basato su host come Wireshark(http://www.wireshark.org/) o tcpdump. Le porte mirror sono facili da configurare, richiedendo la digitazione di pochi comandi sullo switch.
Purtroppo, ci sono diversi svantaggi importanti nell'utilizzo di una porta a specchio. In primo luogo, la porta deve essere configurata correttamente. Porte configurate in modo errato possono portare a frame mancanti o duplicati nella traccia di rete. In secondo luogo, gli switch non replicheranno un frame con nessun tipo di errore, quindi questi frame non saranno tracciati. Terzo, uno switch occupato può far cadere i frame invece di replicarli sulla porta mirror. Quarto, una porta mirror che accetta frame da un'intera VLAN, o da più porte di switch, o anche solo una porta full duplex, può diventare sovraccarica e quindi far cadere alcuni frame. Quinto, gli errori introdotti tra lo switch e l'host non possono essere visti dall'applicazione di monitoraggio della rete collegata ad una porta dello switch completamente diversa. Allo stesso modo, gli errori introdotti tra la porta mirror e l'applicazione di rete daranno all'applicazione di rete una visione distorta di ciò che l'host riceve effettivamente dallo switch.
Rubinetti di rete
Gli switch sono dispositivi passivi che si collegano tra lo switch e l'host; si collegano letteralmente alla connessione di rete. Come una porta mirror, devono essere collegati a un apparecchio di rete, ma hanno meno svantaggi di una porta mirror.
In primo luogo, non c'è tipicamente alcuna configurazione; basta collegarlo e funziona. In secondo luogo, i rubinetti più avanzati si affidano all'alimentazione solo per replicare i frame sulla porta di monitoraggio. e dispongono di doppi alimentatori per garantire che l'attività di replicazione sia affidabile. Se la loro alimentazione si interrompe, questi taps continueranno ad inoltrare i frame tra le porte di rete; solo la replica si ferma. In terzo luogo, un tap ha solo 1 funzione, che è quella di replicare e inoltrare i frame all'applicazione di monitoraggio della rete. Un tap ha molte meno probabilità di essere sopraffatto da un alto volume di traffico. Inoltre, i tap aggreganti hanno uno spazio buffer in modo da poter inoltrare elevati volumi di traffico su un collegamento full duplex senza far cadere i frame. Naturalmente. un tasso elevato sostenuto può comunque sopraffare il buffer. I taps di aggregazione consentono anche di combinare più ingressi. Per esempio, un dispositivo a due porte vi permetterà di monitorare sia gli adattatori attivi che quelli di standby di una coppia di adattatori duplex. Questo assicura un monitoraggio continuo anche in caso di failover dell'adattatore. Infine, collegando il tap all'adattatore host si ha la migliore garanzia possibile che l'applicatore di monitoraggio della rete vedrà tutti i fotogrammi in uscita dall'adattatore host e tutti i fotogrammi in arrivo dall'interruttore all'adattatore host.
Uno svantaggio che molti rubinetti condividono con una porta a specchio è quello di far cadere i fotogrammi danneggiati. Dal momento che molte apparecchiature di monitoraggio di rete, specialmente quelle che sono solo PC con hardware Ethernet standard, lasceranno cadere anche i frame danneggiati, i produttori di taps non considerano questo un difetto critico.
Per ulteriori commenti sui tap e sulle porte di commutazione date un'occhiata a http://www.lovemytool.com/blog/2007/08/span-ports-or-t.html o http://taosecurity.blogspot.com/2009/01/why-network-taps.htm l o digitate "network taps and span ports" nel vostro motore di ricerca preferito.
Sfide di monitoraggio
La prima sfida è quando monitorare e per quanto tempo. Idealmente, i collegamenti di rete critici in un sistema di produzione dovrebbero essere monitorati continuamente. Catturare un problema alla prima occorrenza, e avere una traccia di rete in mano, è molto più veloce che incontrare un problema, impostare il monitoraggio, e cercare di duplicarlo o aspettare che si ripeta. I file di traccia possono essere grandi; un carico del 50% su un link gigabit produce circa 62,5 megabyte al secondo o 3,75 gigabyte al minuto. I file di traccia non devono essere conservati più a lungo del vostro tempo di risposta nel peggiore dei casi. Se è possibile rispondere a un problema segnalato in un'ora, allora è necessario conservare solo un'ora di dati di traccia. Maggiore è il numero di dati di traccia che si salva, maggiore è il margine di manovra di cui si dispone per rispondere o per riconoscere che c'è stato un problema che deve essere indagato. I dischi di grandi dimensioni sono abbastanza economici, almeno in confronto al costo di un'interruzione, quindi prendete in considerazione l'acquisto di una o più unità disco delle dimensioni di terabyte per conservare i dati in traccia.
Il mantenimento di questo livello di monitoraggio può essere difficile quando si utilizza una porta span. In una rete complessa gli amministratori di rete sono tirati in molte direzioni e mantenere una porta di span e un monitoraggio continuo in caso qualcosa vada storto può essere difficile.
D'altra parte, un tap di rete installato accanto all'host è dedicato a quell'host. Si può acquistare un sofisticato apparecchio per il monitoraggio della rete, oppure si può iniziare ad utilizzare un PC di base con un disco rigido da 1 terabyte con Linux o Windows ed eseguire il programma tshark (l'interfaccia non-GUI per wireshark). Questa configurazione vi darà 266 minuti di dati di traccia (supponendo una velocità di trasmissione dati di 500 mbps) ed è perfettamente adeguata per la maggior parte degli scopi. È possibile acquistare un'unità da 1 terabyte per meno di 100 dollari se si acquista in giro.
La salute della rete sottostante è vitale per un'applicazione sempre disponibile. Fare lo sforzo di catturare una traccia accurata dell'attività di rete su una base di routine. Quando i problemi emergono, sarete in grado di risolverli rapidamente senza aspettare che si ripresentino. Come bonus, potrete anche analizzare i dati di traccia e imparare cose sulla vostra rete che erano nascoste prima di.packets