Infatti le maggiori cause di rallentamento sono:
- Congestione
- Corruzione dei dati
- Collisioni
- Cambiamenti della topologia STP
Solitamente le basse performance non vengono notate nell’intera rete,bensì da qualche workstation o da qualche applicativo che accede ad uno o più server.
In questo caso prima di concentrarsi sugli switch è bene controllare il carico di lavoro e le risorse disponibili dei server e delle workstation.
Una volta accertati dell’effettiva disponibilità delle risorse, dobbiamo andare ad identificare i percorsi “lenti” cercando gli apparati e le porte che sono coinvolte.
Congestioni
Il primo step consiste nel cercare delle porte sovraccariche
Quando una porta è sovraccarica alcuni pacchetti vengono scartati. Questo provoca un notevole decremento del transfer-rate poiché i pacchetti dovranno essere ritrasmessi.
Per individuare le porte sovraccariche si devono analizzare i pacchetti scartati e l’utilizzo di ogni singola porta.
-Individuare i pacchetti scartati:
Switch#show interfaces counters error
Dall’output di questo comando dobbiamo prendere in considerazione le colonne Xmit-Err e OutDiscards. Questi errori indicano che una o più porte con transfer-rate maggiore stanno inviando pacchetti ad una porta con transfer-rate minore saturando il buffer.
Un utilissimo commando disponibile solo per la serie 6500 è il “show top”, che mostra la percentuale di utilizzo di ogni porta ed i pacchetti scartati per congestione.
Switch#show top
Per modelli più economici come la serie 2900 si può utilizzare
Switch#Show controllers utilization (disponibile dalla versione 12.1(22)EA1)
Corruzione dei dati.
Se I pacchetti sono corrotti a causa di una cablatura danneggiata,interferenze elettromagnetiche o problemi hardware dello switch, i pacchetti corrotti vengono scartati (dropped) dallo switch ricevente. Un alto volume di pacchetti danneggiati possono causare un crollo generale delle performance, in quanto l’host che invia pacchetti corrotti deve continuamente ritrasmetterli.
Possiamo utilizzare nuovamente i comandi “show interfaces counters error” e “show interfaces” per vedere gli errori CRC
Switch#show interfaces counters error
Switch#show interfaces
Questa volta dobbiamo prendere in considerazione i campi CRC e FRAME. Un valore superiore a zero può indicare disturbi elettromagnetici o problemi di cablatura.
Collisioni.
Un altro caso da considerare è un alto numero di collisioni, teoricamente due porte impostate in full-duplex non dovrebbero generare collisioni,in quanto i pacchetti ricevuti ed inviati viaggiano su canali separati.
Se in una porta individuiamo delle collisioni probabilmente è impostata in full-duplex mentre l’altra è in half-duplex, in questo caso la porta in full-duplex invierà dati anche mentre la porta in half-duplex stà trasmettendo, causando numerose collisioni che abbassano il throughput.
Solitamente un “duplex mismatch” avviene quando una porta è impostata con speed e duplex fissi, mentre l’altra porta è in auto negoziazione, la seconda non sentendo lo stato dell’altra si configura al valore di default (half duplex).
La soluzione ovvia è impostare entrambe le porte in half o full duplex.
Possiamo individuare facilmente le porte con collisioni utilizzando il comando:
Switch#show interfaces counters error
Prendendo in considerazione i campi Single-Col,Multi-Col ,Late-Col,Excess-Col
Single-Col e Multi-Col sono contatori che indicano quante volte la porta ha determinato una collisione mentre tentava di inviare un frame.
Late-Col indica quante volte lo switch rileva una ricezione dopo che ha già inviato 64byte di un pacchetto, in questo caso la porta interessata è sicuramente in half-duplex.
Excess-Col questo contatore viene incrementato ogni volta che la porta tenta di inviare per 16 volte un pacchetto e rileva una collisione.
Cambiamenti della Topologia STP
Un altro problema che può causare rallentamenti intermittenti in reti che utilizzano un protocollo di Spanning Tree è un eccessivo cambio di topologia.
Quando una porta “STP Attiva” cambia lo stato del link, lo switch invia un messaggio di Topology Change Notification (TCN) agli altri switch che partecipano allo spanning tree,questi ultimi devono svuotare le tabelle MAC e ARP.
A questo punto gli switch devono ricalcolare i percorsi e per un determinato periodo si trovano in uno stato di “learning”,durante il quale i pacchetti vengono inoltrati a tutte le porte(come fossero degli HUB).
In questa fase la rete può risultare congestionata per il numero di pacchetti in transito che poi verranno scartati.
Un frequente TCN può essere causato da un collegamento mal funzionante(ad esempio un cavo patch ossidato) oppure da un collegamento edge non configurato in port-fast.
Un collegamento edge è una porta che arriva alla scheda di rete di una workstation, in questo caso è bene configurare tale porta in modalità port-fast, in modo da escluderla dall’STP.
È possibile visualizzare tutta l’attività dello Spanning Tree Protocol attivando il debug.
Switch#debug spanning-tree events
Per maggiori informazioni riguardo lo Spanning-Tree potete consultare il seguente articolo.
View Comments (2)
Complimenti, è interessante anche se avrei preso in considerazione anche l'utilizzo cpu.
Ciao, ti ringrazio.
Dal mio punto di vista l'intenso utilizzo cpu non è una causa, ma una conseguenza dei problemi descritti nell'articolo.
Comunque è possibile vedere l'utilizzo del processore con il comando:
Switch#show processes cpu