LAN_Testing_and_Ethernet_Troubleshooting

Anno 2005
Corso di Laurea Specialistica in Ingegneria delle Telecomunicazioni
Corso di Misure per la qualificazione di reti di telecomunicazioni
Professore Leopoldo Angrisani
Lan Testing
And
Ethernet Troubleshooting
Relazione a cura di:
Amato Felicetta 887/41
Bramante Daniela 887/42
Cimmino Giovannina 887/43
Colella Ada 887/57
Di Febbraro Barbara 887/44
Indice
Capitolo 1
1
1
Lan testing
1
1.1
Introduzione
1
1.2
LAN (Local Area Network)
2
1.3
Test di monitoraggio sulle LAN
5
1.3.1 Test in service
6
1.3.2 Test out of service
14
1.3.2.1
Test sui cavi
14
1.3.2.2
Interferenze esterne
24
1.4
Test di conformità ed interoperabilità sulle LAN
25
1.5
Test di carico sulle LAN
26
Capitolo 2
29
2
Ethernet troubleshooting
29
2.1
Introduzione
29
2.2
Strumenti
29
2.3
Linee guida del troubleshooting
30
2.4
Sintomi dei problemi in Ethernet
35
2.4.1 Collisioni
36
2.4.2 Collisioni remote e locali
37
2.4.3 Collisioni ritardate (late collision)
38
2.4.4 Altri sintomi di malfunzionamento
39
I
2.5
Problemi di cablaggio
43
2.6
Network Interface Card
44
2.7
MAU (Medium Attachment Unit)
46
2.8 Problemi con schede Ethernet e MAU
51
2.9 Sintomi e Cause di Malfunzionamenti di Schede e MAU
52
2.10 Ripetitori e Hub
57
2.10.1 Problemi causati dall’impiego di hub
61
2.10.2 Problemi dei ripetitori e hub: Sintomi e Cause
62
2.10.3 Problemi con ripetitori ottici in reti Ethernet
67
2.10.4 Problemi con ripetitori ottici non standard
69
2.11 Bridge
69
2.11.1 Funzioni dei bridge
71
2.11.2 Diagnostica dei problemi dei bridge
73
2.11.3 Sintomi e cause dei problemi nei bridge
74
2.12 I router e lo strato di rete
79
2.12.1 Instradamento gerarchico
83
2.12.2 Diagnostica dei problemi dei router
84
2.12.3 Sintomi e le cause connesse ai problemi di routing
85
II
Capitolo 1
Lan testing
1.1 Introduzione
Al fine di potersi assicurare che una rete di comunicazione, di qualunque
genere essa sia, funzioni correttamente è necessario effettuare, durante il suo
intero ciclo di vita, delle procedure di collaudo e misurazione, utili perché in
grado di fornirci parametri prestazionali ed indicazioni tanto sui singoli
elementi quanto sui servizi offerti dalla rete stessa.
Ricordiamo che con il termine procedure di misurazione si intende indicare un
insieme d’azioni coordinate il cui svolgimento ha l’obiettivo di conseguire
un’informazione di misura, mentre con il termine collaudo, traduzione
dell’anglosassone “test”, si intende indicare il confronto fra l’informazione così
ottenuta ed un valore predefinito, al fine di poter stabilire se quanto osservato
rispetta o meno certi vincoli che, secondo un qualche criterio, siano stati
stabiliti.
In questo capitolo, in particolare, ci si pone l’obiettivo di descrivere le principali
tipologie di test che vengono effettuate in uno specifico tipo di reti di
comunicazione, cioè le reti LAN, di cui è fornita di seguito una breve
descrizione.
1
1.2 LAN (Local Area Network)
Le LAN, o reti locali, sono reti di calcolatori private impiegate, ad esempio
all’interno di un edificio o di un’università, per consentire lo scambio di
informazioni e la condivisione di risorse tra i calcolatori e le stazioni di lavoro
presenti in tali stabilimenti. Una caratteristica peculiare di queste reti è
rappresentata dalle loro dimensioni che, essendo ridotte, al più di qualche
centinaio di chilometri, sono tali che il peggior tempo di comunicazione tra due
terminali, che di essa fanno parte, è limitato e noto a priori.
Le LAN tipicamente usano una tecnologia di trasmissione che si serve di un
solo cavo condiviso al quale tutte le macchine sono collegate; la velocità di
trasmissione su di esse raggiungibile è molto elevata: infatti, se già negli anni
‘80 era possibile conseguire velocità di 10 Mbit/s, oggi sono molto comuni
versioni a 100 Mbit/s e addirittura sono disponibili versioni a 1 Gbit/s.
Per tali reti broadcast sono possibili differenti topologie che sono brevemente
descritte di seguito.
Un primo tipo di topologia è quella a bus, cioè a cavo lineare, ove
effettivamente ogni sistema è collegato a tutti gli altri attraverso un unico
mezzo trasmissivo broadcast così che, quando un sistema trasmette, tutti gli
altri ricevono simultaneamente senza doversi preoccupare di effettuare
ripetizioni o istradamenti.
Figura 1.1
2
Il bus è realizzato tipicamente con cavi coassiali ed è ad esempio adoperato
nelle LAN conformi alle tecnologie Ethernet 10Base2 e 10Base5 le quali, è bene
ricordare, sono state le prime a diffondersi in maniera capillare, sebbene oggi
stiano ormai cadendo in disuso.
Una secondo tipo di topologia è quella ad anello (ring), impiegata ad esempio
nelle LAN conformi alla tecnologia Token ring, la quale prevede di collegare
ogni sistema al successivo con un mezzo trasmissivo punto-punto e di collegare
poi l’ultimo sistema al primo.
Figura 1.2
Ciò che ne risulta in tal modo è appunto un anello unidirezionale, in cui ogni
sistema ha anche una funzionalità di ripetizione dei messaggi inviati dagli altri.
In pratica quando un nodo dovrà trasmettere, esso inserirà il messaggio
sull’anello così che questo possa giungere ai sistemi a valle, i quali si
preoccuperanno poi di ripetere il messaggio fino a quando esso tornerà al
mittente che, a questo punto, lo eliminerà dall’anello stesso. In particolare, il
destinatario, oltre a ripetere il messaggio, lo riceverà e potrà modificare un bit
nella coda del messaggio stesso così da confermare al mittente la sua avvenuta
ricezione; questa caratteristica di “conferma dell’avvenuta ricezione”è peculiare
solo delle reti ad anello. Un grave problema in cui però si incorre quando si
3
decide di adottare un tal genere di cablaggio consiste nel fatto che l’operatività
dell’intera rete è compromessa nel caso in cui un sistema si guasti oppure
semplicemente venga spento. Al fine di incrementare l’affidabilità è necessario
allora ricorrere a delle soluzioni che consentano di escludere dalla rete sistemi
o mezzi trasmissivi malfunzionanti. Una prima possibile soluzione, adoperata
ad esempio nelle reti Token ring con una topologia cosiddetta ad anello stellato,
consiste nell’adoperare un concentratore di fili, a cui ogni stazione verrà
fisicamente collegata, il quale continuerà ancora ad assicurare, solo da un punto
di vista logico, l’esistenza di un anello. Tale concentratore sarà dotato al suo
interno di interruttori alimentati dalle stazioni stesse in modo tale che, in caso
di un eventuale guasto di una di esse, la perdita di corrente da ciò derivante
sarà tale da far aprire l’interruttore da questa alimentato così che il suo
aggiramento sarà garantito. Un'altra possibile soluzione consiste invece nel
ricorrere ad un cablaggio a doppio anello controrotante, quale quello adottato
in FDDI, il quale prevede che, in caso di guasto di uno dei due anelli, si possa
ricorrere all’altro che fungerà quindi da riserva.
L’ultima topologia che infine consideriamo è quella a stella, in cui tutte le
stazioni sono collegate tra loro attraverso un dispositivo centrale detto hub, che
è sostanzialmente un ripetitore multiporta, a cui ogni nodo è collegato
attraverso mezzi trasmissivi punto-punto.
Figura 1.3
4
Tale topologia è adoperata ad esempio nelle LAN conformi a Ethernet 10BaseT
e 100BaseT. I vantaggi derivanti dall’utilizzo di un tal genere di topologia sono
molteplici. In primo luogo la presenza dell’hub permette di semplificare
notevolmente la gestione della rete in quanto, ad esempio, qualora ci fosse un
nodo malfunzionante, l’hub sarebbe in grado di rilevare il problema e
automaticamente scollegarlo; inoltre molti hub sono anche in grado di ottenere
informazioni da un host ad esso direttamente collegato e farne poi un
resoconto. È chiaro che il corretto funzionamento di questo centro stella finirà
però per divenire un punto critico per l’affidabilità della rete stessa.
E’ bene sottolineare che, sebbene attualmente esistano molteplici tecnologie
LAN, fra tutte Ethernet è sicuramente la più diffusa, non solo perché è stata la
prima ad alta velocità a diffondersi ma soprattutto perché, a differenza delle
altre tecnologie come FDDI e Token ring, essa è molto meno complessa e i costi
dei suoi apparati sono ridotti (il suo hardware è infatti facilmente reperibile e si
trova a costi contenuti).
1.3 Test di monitoraggio sulle LAN
I primi test che procediamo con l’analizzare sono i test di monitoraggio, cioè
quelli effettuati durante la fase operativa di una rete LAN, volti a controllare
che tutto operi secondo quanto stabilito. E’ chiaro però che, affinché questo
obiettivo possa essere conseguito, tutti i tasselli della rete devono ben
funzionare. L’obiettivo dei test nella fase operativa è quindi effettuare un
monitoraggio costante della rete (dei link, dei dispositivi..) per potere,
attraverso
le
informazioni
raccolte,
sia
rilevare
eventuali
suoi
malfunzionamenti, così da consentire poi di individuare il guasto, isolarlo e
repentinamente ripararlo, sia effettuare una procedura di benchmarking il cui
fine è valutare se i parametri prestazionali seguono l’andamento desiderato e se
5
rientrano in particolari valori limite.
I test effettuati durante la fase operativa di una LAN, in particolare, si dividono
in due categorie: quelli “in service” e quelli “out of service”.
I test in service sono effettuati sulla rete mentre essa è attraversata da traffico
convenzionale, per questa ragione è necessario che essi siano quanto meno
invasivi possibile, al fine di garantire che la rete sotto test possa continuare a
funzionare correttamente senza che l’utenza avverta alcun disagio. Al contrario
i test out of service sono effettuati interrompendo le normali operazioni
effettuate sul link di comunicazione, il che chiaramente implica la sospensione
dei servizi offerti, e procedendo ad una simulazione del flusso informativo.
Mentre nella prima categoria di test è possibile inserire le misurazioni relative
all’integrità del segnale (signal condition measurements), l’analisi di protocolli e
varie misurazioni di tipo statistico, nell’ambito dei test che richiedono la
sospensione della normale attività del segmento o componente sotto test è
possibile invece inserire, ad esempio, i test effettuati sui cavi.
1.3.1 Test in service
Misurazioni dell’integrità del segnale
Come è noto, la trasmissione delle informazioni in forma digitale, richiede
innanzitutto la codifica di tali informazioni in termini di bit; i dati digitali così
ottenuti vengono poi trasmessi associando, mediante un’ulteriore codifica tipo
la Manchester ad esempio, ogni bit ad un fenomeno fisico che può essere
riprodotto a distanza attraverso il mezzo trasmissivo utilizzato. Tutti i fenomeni
fisici adoperati si basano sul trasporto di una qualche forma d’energia che
codifica l’informazione, a cui il sistema attraversato si oppone determinando
un’attenuazione dell’energia trasmessa di un ammontare dipendente dalla
6
frequenza di lavoro.
Il diverso comportamento del mezzo trasmissivo in funzione della frequenza
genera anche distorsione, cioè l’alterazione dell’andamento nel tempo del
segnale, ad alterare il quale concorre però anche il rumore, cioè la
sovrapposizione al segnale utile di energia proveniente da elementi esterni o
interni al sistema trasmissivo. L’insieme di questi aspetti ci fa intuire come
realizzare delle misurazioni volte ad accertare l’integrità di un segnale, cioè
volte ad assicurarsi che esso sia proprio come ce lo si aspetta, possa fornirci
informazioni estremamente utili. Tali misurazioni, in pratica, saranno volte ad
estrarre alcune informazioni dal segnale, come ad esempio la potenza che esso
trasporta, il suo valore di picco, e a confrontare poi i valori osservati dei
parametri d’interesse con quelli che ci si attendeva in base ad esempio al tipo di
tecnologia e di modulazione adoperate o al canale trasmissivo impiegato. In
realtà però queste misurazioni non sono nell’ambito di una LAN significative
tanto quanto avrebbero potuto esserlo ad esempio per una WAN (Wide Area
Network), in quanto dovendo i segnali viaggiare su distanze relativamente
brevi il deterioramento introdotto è ivi sicuramente minore.
Questo tipo di misurazioni richiede l’uso di un oscilloscopio al fine di
determinare la forma fisica del segnale trasmesso, cioè il suo andamento nel
tempo, e poter poi ad esempio verificare che rientri in una maschera specifica,
la quale impone dei vincoli su grandezze quali il tempo e l’ampiezza. Questi
segnali possono essere misurati sia direttamente al connettore, sia all’interfaccia
di componenti attivi di rete, come ripetitori, bridge o router (questi, infatti, sono
anche detti test d’interfaccia).
Si noti che nel momento in cui si andrà a collegare l’oscilloscopio ad
un’interfaccia di un elemento di rete, esso fungerà per quella stessa interfaccia
come un ulteriore carico posto in parallelo a quello che, su di essa, era già
presente, cioè la restante parte della rete ad essa collegata. Al fine di sostenere
questo doppio carico quindi il trasmettitore presente su tale interfaccia dovrà
7
erogare più corrente. Si ricordi però che, per il corretto funzionamento dei
circuiti digitali, la corrente non potrà crescere indefinitamente, ma avrà un
valore oltre il quale si dice che il circuito satura, ovvero non è più in grado di
fornire i livelli di tensione necessari in quanto vi è un tetto di potenza oltre il
quale non è possibile andare. In conseguenza di ciò, è chiaro che un aumento
della corrente che è necessario erogare in conseguenza del doppio carico
presente, potrà comportare degli abbassamenti in tensione con tutti i problemi a
ciò connessi. Per queste ragioni, è molto importante che, nell’effettuare tali test
in service, l’oscilloscopio collegato all’interfaccia sia tale da non caricarla, cioè
esso dovrà essere dotato di un’impedenza di ingresso molto elevata,
praticamente tale da far sì che esso funga da circuito aperto. E’ bene sottolineare
che sarebbe un grave errore dire in questo caso che l’oscilloscopio debba essere
adattato all’interfaccia, in quanto, nel caso di test in service, questo adattamento
già lo si ha in conseguenza del collegamento fra l’interfaccia stessa e l’altro
troncone di rete ad essa collegato, che, appunto, se tutto funziona bene, funge
proprio da carico adattato per quell’interfaccia. Di conseguenza, se supponiamo
ad esempio che quest’impedenza di carico debba valere 50Ω, se si collegasse a
tale interfaccia un oscilloscopio adattato, si finirebbe per avere due impedenze
da 50Ω in parallelo, le quali equivarrebbero quindi ad un’impedenza di 25Ω;
questo implicherebbe allora il venire meno delle condizioni d’adattamento e di
conseguenza, non solo la rete verrebbe deteriorata, ma soprattutto tutte le
informazioni di misura ricavate non avrebbero alcun senso. Quindi nel caso di
test in service l’oscilloscopio non deve fungere da carico adattato ma anzi da
carico elevato, teoricamente infinito, in quanto l’adattamento già c’è; per inciso
è bene sottolineare che il discorso sarebbe perfettamente contrario nel caso di
test out of service effettuati sui cavi, in quanto, poiché questa volta
l’oscilloscopio verrebbe agganciato su un’interfaccia dopo aver da essa
scollegato il restante troncone di rete, proprio al fine
di conservare
l’adattamento, sarebbe questa volta necessario servirsi invece di un
8
oscilloscopio con impedenza d’ingresso di 50Ω.
Informazioni relative alla qualità dell’infrastruttura di cablaggio o all’interfaccia
sotto test possono essere determinate a partire dalla forma del segnale
visualizzata sull’oscilloscopio; per questa ragione questi test sono molto utili al
fine di restringere il range di possibili cause di malfunzionamenti, qualora
queste risiedano appunto in interfacce difettose nei nodi di rete, nei bridge o nei
router o qualora ci siano problemi derivanti dall’infrastruttura di cablaggio.
Analisi dei protocolli e misure statistiche
Mentre i test precedentemente discussi sono sostanzialmente dei test di livello
fisico che si servono quindi di strumenti tradizionali quali, come già detto,
l’oscilloscopio, con i test protocollari si sente l’esigenza di salire nella pila
protocollare e, per far ciò, è allora necessario ricorrere ad un altro genere di
strumento che è il cosiddetto analizzatore di protocollo, unità in grado di
espletare le seguenti funzionalità:
-
catturare i pacchetti in transito sul segmento di rete da esso controllato,
operando nel modo meno intrusivo possibile, cioè non solo non facendo
scomparire i pacchetti catturati, ma neppure introducendo un ritardo
significativo che sarebbe causa di disturbo per l’utente in quanto andrebbe
ad inficiare la qualità del servizio da lui percepita;
-
recuperare l’informazione in essi contenuta;
-
visualizzare a video tali informazioni relative ai vari livelli della pila
protocollare.
Inoltre gli analizzatori di protocollo più moderni sono anche in grado di
riportare statistiche e trend relativi al traffico da essi analizzato.
Nelle topologie broadcast (quali Ethernet a 10/100/1000 Mbit/s, Token ring a
4/16 Mbit/s e FDDI), un analizzatore di protocollo è collegato come ogni altro
9
nodo al segmento di LAN sotto test e può monitorare tutte e sole le
comunicazioni in atto sul segmento su cui è installato; il traffico presente aldilà
di un router o un bridge non può essere testato in conseguenza del fatto che tali
componenti limitano il traffico locale al proprio segmento d’origine.
Nella figura 1.4, di seguito riportata, vengono mostrati i modi in cui un
analizzatore di protocollo può essere collegato ad un segmento LAN, a seconda
della sua diversa topologia:
-
nel caso di una rete Ethernet 10Base2, ove si ricordi che ogni singolo nodo è
collegato al bus adoperando connettori industriali standard BNC che
formano una giunzione a T, l’analizzatore stesso è connesso adoperando
appunto un connettore a T libero o un connettore a T extra;
-
nel caso di Ethernet 10BaseT, si connette l’analizzatore all’hub;
-
nel caso di una Token ring con configurazione ad anello stellato, si connette
l’analizzatore ad una delle porte del centro stella.
-
nel caso di FDDI, si può o connettere l’analizzatore direttamente al doppio
anello (nel qual caso però saranno necessarie due porte), oppure collegarlo
ad esso tramite un concentratore di fili (nel qual caso una sola porta è
sufficiente).
10
Figura 1.4
Se si desidera analizzare il traffico in due segmenti simultaneamente, ad
esempio al fine di osservare come esso attraversa un particolare router o bridge,
è necessario un analizzatore di protocollo a due porte; è, infatti, chiaro che non
è possibile monitorare più segmenti contemporaneamente con un dispositivo a
singola porta per il semplice fatto che esso non può essere connesso in due posti
allo stesso tempo.
Il monitoraggio di una rete più ampia poi, può essere realizzato servendosi di
sistemi di monitoraggio distribuiti, composti da una stazione centrale, che
raccoglie, correla ed analizza i dati provenienti da varie entità, detti agent,
consistenti o in sonde di misurazione o in entità software, installati in tutti i
segmenti LAN. Un’architettura del genere, offrendo una visione real-time di
una vasta area della rete, che può essere monitorata da remoto, rende
chiaramente più semplice l’analisi dei malfunzionamenti e consente di
effettuare interventi repentini.
L’analisi di rete diventa più complessa qualora, piuttosto che considerare come,
finora fatto, delle LAN con una topologia broadcast, si considerino delle LAN
con una topologia basata su un principio di commutazione, come le Switched
11
LAN, le quali, piuttosto che adoperare degli hub, dispositivi dello strato fisico,
che si limitino a ricopiare su tutte le porte d’uscita qualunque pacchetto gli
giunga su una porta d’ingresso, si servono di switch, i quali, essendo dispositivi
in grado di esaminare l’indirizzo di destinazione di livello 2 precisato in ogni
frame che giunge loro su un’interfaccia d’ingresso, inoltrano tale frame solo
all’interfaccia da cui sarà possibile giungere alla destinazione desiderata. E’
allora chiaro che, in una tal topologia, non è possibile connettere direttamente
l’analizzatore allo switch come se fosse un qualunque nodo in quanto, dal
momento
che
nessun
altro
elemento
è
a
conoscenza
dell’esistenza
dell’analizzatore stesso, non ci sarà del traffico ad esso specificamente inviato e
lo switch quindi bloccherà la porta fisica a cui l’analizzatore è connesso. In
questa condizione, l’analizzatore potrà catturare solo il traffico broadcast.
Affinché quindi l’analizzatore possa monitorare almeno il traffico relativo ad
una porta dello switch sarà necessario interporlo fra questa stessa porta e il
server, la workstation o il segmento di LAN, che normalmente è ad essa
connesso. Attraverso un tal genere di connessione quindi, se una data porta di
uno switch LAN è connessa solo ad una singola stazione, ogni porta
dell’analizzatore di protocollo potrà monitorare solo il traffico relativo ad essa.
Figura 1.5
12
Se
invece
si
desidera
contemporaneamente
allora
monitorare
sarà
tutte
necessario
le
porte
adottare
un
dello
switch
analizzatore
multiporta. Proprio per rispondere a questa esigenza si sono sviluppati
analizzatori, con costi sempre più alti, che hanno 4, 8, 12 o più porte, le quali
sono usate per monitorare il corrispondente numero di switch port. In
alternativa a ciò molti commutatori, dotati di maggiori funzionalità, offrono la
possibilità di definire delle cosiddette “mirror port”, cioè porte inutilizzate che
vengono adoperate come porte di test e in cui vengono copiati tutti i pacchetti
che giungono da quelle attive. Questa soluzione, se da un lato consente ad un
analizzatore a singola porta di monitorare i dati provenienti da un certo
numero di porte attive, dall’altro ha lo svantaggio che, in presenza di picchi di
traffico, non è più in grado di garantire un monitoraggio affidabile in quanto la
singola porta di test, di solito, ha esattamente la stessa capacità, in termini di
buffer essenzialmente, di una qualunque di quelle monitorate, per cui in una
condizione del genere i pacchetti che eccedono la sua capacità vengono scartati
a caso e quindi persi. Il limite di questa seconda soluzione consiste quindi nel
fatto che il grado di affidabilità dell’informazione ottenuta decresce
all’aumentare del traffico prodotto sulle porte attive, raggiungendo in
particolare il picco massimo di inaffidabilità quando tutti i link verso lo switch
sono saturi. Nella seguente figura vengono mostrate tutte e due le possibili
soluzioni adesso descritte, quella cioè in cui lo switch ha un’apposita porta di
monitoraggio e quella in cui invece l’analizzatore fa da ripetitore tra lo switch
ed il nodo d’interesse.
13
Figura 1.6
1.3.2 Test out of service
1.3.2.1 Test su cavi
Come già detto prima, le misurazioni effettuate sui cavi sono le più comuni
procedure di test che richiedono l’interruzione dell’attività svolta da un intero
segmento di LAN.
Le caratteristiche dei cavi che in particolare vengono misurate, variano in
dipendenza dello specifico tipo di cavo adoperato: doppino, cavo coassiale o
fibra ottica.
14
Test sui doppini
I doppini in rame rappresentano il più economico e diffuso mezzo trasmissivo;
sebbene essi siano nati per essere adoperati in telefonia, i continui
miglioramenti loro apportati hanno fatto sì che potessero essere utilizzati per
uno svariato range di applicazioni ed è così che essi hanno trovato ampio
spazio nell’ambito delle reti locali, dove attualmente consentono di raggiungere
velocità di trasmissione di 100 Mbit/s (categoria 5) o di addirittura 1 Gbit/s
(categoria 6).
Le tipiche caratteristiche che vengono misurate quando si considerano LAN
cablate con doppini sono ad esempio lunghezza del cavo, attenuazione,
diafonia, assegnazione dei pin, rumore e impedenza, descritte di seguito in
dettaglio.
Assegnazione dei pin
La corretta assegnazione dei pin di un connettore di cavi dovrebbe essere la
prima cosa da controllare prima che degli indicatori di qualità possano essere
testati.
Una scorretta assegnazione dei pin, oltre che essere ovviamente il risultato di
un errore manuale effettuato durante il cablaggio, potrebbe anche essere dovuto
all’uso di differenti sistemi di codifica basati sui colori: si pensi ad esempio al
fatto che gli standard per i sistemi di cablaggio EIA/TIA 568A e EIA/TIA 568B
definiscono due differenti modi per intestare un cavo UTP a 4 coppie su una
presa RJ-45. Nella seguente figura viene mostrato un tale connettore e le due
diverse possibili assegnazioni delle coppie.
15
Figura 1.7
L’assegnazione dei pin è testata connettendo il wall jack (presa utente) a
differenti resistenze, effettuando poi delle misurazioni di resistenza al
permutatore centrale (patch panel) per ogni coppia di fili che giunge qui a
partire dalla presa utente e verificando infine che i risultati ottenuti
corrispondano ai valori di resistenza settati su ciascuna coppia.
Attenuazione
Un importante parametro elettrico di un cavo è l’attenuazione, definita come il
rapporto, in decibel, fra l’ampiezza del segnale in ingresso al cavo e quella
misurabile all’altra estremità. Dato che esistono dei limiti ben specifici
all’attenuazione totale che può essere tollerata su un certo segmento di rete,
queste misurazioni sono un utile strumento per misurare quale sia la reale
perdita in ampiezza del segnale trasmesso e verificare che essa non ecceda il
16
massimo valore permesso, detto “loss budget”.
In particolare è chiaro che l’attenuazione misurata varierà in dipendenza della
lunghezza del cavo e della frequenza a cui si sta lavorando.
Diafonia
Nei cavi in rame, ove più coppie scorrono affiancate le une alle altre all’interno
della stessa guaina, la sorgente più significativa di disturbo è la diafonia, in
inglese cross-talk, una quantità che indica quanto un cavo disturba un altro ad
esso vicino, in conseguenza di fenomeni di accoppiamento fra essi esistenti.
In particolare la diafonia viene misurata come rapporto, in decibel, fra
l’ampiezza del segnale trasmesso, che genera disturbo, e quella del segnale
indotto nel cavo vicino ed esistono, in linea di principio, due diversi modi per
misurarla che differiscono per il lato ove effettivamente la misurazione è
effettuata: se la misurazione del segnale indotto nel cavo vicino è effettuata
dalla stessa parte del trasmettitore, si parla di paradiafonia o NEXT (Near End
Cross-Talk), se invece tale misurazione è effettuata all’estremo opposto si parla
di telediafonia o FEXT (Far End Cross-Talk). In pratica però si misura quasi
sempre soltanto la paradiafonia, la quale è chiaramente molto più critica della
seconda, che infatti rappresenta un’interferenza dovuta ad un segnale
attenuato.
Figura 1.8
Ciò a cui tipicamente si aspira è il conseguimento di un alto valore NEXT, il
17
quale ci starebbe ad indicare basso disturbo presente sulla linea e quindi alta
qualità del percorso trasmissivo e inoltre sarebbe sicura garanzia di un ancor
più alto valore FEXT (mentre si noti che il contrario non sarebbe invece vero).
Anche la diafonia è però influenzata dalla frequenza del segnale trasmesso ed è
per questo molto importante effettuare misurazioni a diverse frequenza e su
ogni possibile combinazione di coppie, con questo si intende dire che, se ad
esempio il cavo sotto test è un doppino a quattro coppie, almeno dodici
misurazioni dovranno essere effettuate.
Si tenga presente, fra l’altro, che proprio la necessità di minimizzare la diafonia
è la ragione per cui i fili di rame di un doppino sono ritorti.
Rapporto fra attenuazione e diafonia
Allo scopo di conseguire una corretta ricezione non interessano tanto
l’attenuazione assoluta del cavo o il suo valore di diafonia, quanto la
combinazione di questi due parametri; proprio al fine di considerare in modo
combinato entrambi i macroeffetti che sono causa di una degradazione della
qualità dell’informazione è interessante valutare il cosiddetto ACR (Attenuation
to Cross-talk Ratio), che esprime il rapporto tra il segnale attenuato, presente su
una coppia, ed il segnale indotto dalla coppia vicina e varia anche esso in
funzione della frequenza e della lunghezza del cavo. Tra l’altro, siccome tanto
l’attenuazione quanto la diafonia sono espresse in decibel, cioè in termini
logaritmici, il loro rapporto è ottenibile come loro differenza; se quest’ultima è
troppo piccola, cioè si avvicina a zero dB, non è più possibile trasmettere sul
cavo in modo affidabile, in quanto il segnale utile è troppo debole rispetto al
rumore e quindi possono verificarsi troppi errori di trasmissione.
L’ACR è quindi importante al fine di stimare gli effetti dell’attenuazione e della
diafonia sul bit error rate caratteristico del percorso trasmissivo sotto analisi.
18
Rapporto segnale-rumore
Il rapporto fra l’ampiezza del segnale e quella del rumore, cioè il cosiddetto
rapporto
segnale
rumore
(SNR),
è
quasi
identico
all’ACR,
di
cui
precedentemente detto, in quanto l’unica differenza fra le due quantità sta nel
fatto che l’SNR tiene conto, non solo dei disturbi dovuti alla diafonia, che però
sono i più significativi, ma anche di quelli causati da altre possibili sorgenti di
rumore.
Impedenza
L’impedenza è il parametro elettrico più importante per un cavo usato alle alte
frequenze; essa, normalmente indicata con il simbolo Z ed espressa in Ω (ohm),
è una grandezza complessa, che sintetizza in un solo valore resistenze, capacità
ed induttanze presenti sul cavo. L’importanza dell’impedenza deriva dal fatto
che, per la trasmissione di segnali a frequenze elevate, l’impedenza d’uscita del
trasmettitore, quella d’ingresso del ricevitore e quella caratteristica del cavo
devono essere uguali; si parla, in tal caso, di “sistemi adattati in impedenza”. Le
variazioni d’impedenza lungo il cavo, che possono essere ad esempio provocate
da alterazioni nella regolarità della geometria dei doppini stessi, provocano
riflessioni del segnale, con conseguenti attenuazioni ed interferenze, causa a
loro volta di jitter ed errori nei bit. A seguito di ciò, se si desidera ottenere una
comunicazione che non risenta di un tal genere di problemi, è necessario fare in
modo che l’impedenza rimanga quanto più possibile costante e vicina
all’impedenza caratteristica del cavo stesso attraverso l’intero segmento.
19
Resistenza
Un'altra caratteristica interessante di un doppino è la sua resistenza. È bene
evidenziare immediatamente che, sebbene i concetti di impedenza e resistenza
di un cavo potrebbero sembrare simili, essi sono invece, in realtà,
profondamente diversi: mentre infatti quando si parla di impedenza di un cavo
sostanzialmente ci si riferisce alla sua impedenza caratteristica e quindi alla sua
capacità di trasferire informazioni ad alta frequenza senza che si generino, ad
esempio, delle riflessioni, quando di parla di resistenza di un cavo, invece ci si
riferisce ad una grandezza caratterizzante il materiale da cui il cavo stesso è
costituito, cioè, nel caso del doppino, l’anima in rame che è all’interno di ogni
suo singolo elemento.
È chiaro che la resistenza di un cavo varia in dipendenza della sua lunghezza,
nel senso che quanto maggiore sarà la lunghezza del tratto considerato tanto
più alta sarà la resistenza sperimentata. Nel caso di un doppino UTP lungo 100
metri, ad esempio, la resistenza dovrebbe assumere un valore compreso fra i 9Ω
e 12Ω, mentre per un STP della stessa lunghezza esso dovrebbe assumere un
valore compreso fra i 6 e 7Ω. Le misurazioni di resistenza sono molto utili
perché in grado di fornire indicazioni sull’integrità dei cavi stessi, in quanto ad
esempio valori misurati diversi da quelli attesi potrebbero essere indice di
connessioni imperfette, corto circuiti o cavi rotti.
Riflessioni
Come già precedentemente detto, anomalie d’impedenza danno origine a
fenomeni di riflessione, che a loro volta causano sovrapposizioni fra i simboli
che rappresentano i vari bit e di conseguenza generano distorsioni nella forma
del segnale trasmesso. Questa distorsione può poi rendere più difficile al
20
ricevitore la ricostruzione del segnale di clock che è necessario conoscere al fine
di capire qual è la cadenza con cui i bit del segnale trasmesso si succedono e
senza il quale il ricevitore non sarebbe in grado di riconoscere il confine fra bit
adiacenti e quindi di interpretare correttamente il segnale ricevuto. Si pensi ad
esempio al caso in cui si codificano i dati digitali da trasmettere sul canale
mediante codifica Manchester: ebbene in questo caso il ricevitore ricava
l’informazione sul clock a partire dai fronti presenti nel segnale ricevuto in ogni
intervallo di bit; è chiaro allora che, qualunque deformazione del segnale che
renda più difficile determinare gli istanti in cui i fronti si verificano, contribuirà
all’insorgere di jitter, nel senso che il clock ricostruito dal ricevitore sarà affetto
da una certa instabilità in quanto il valore istantaneo della frequenza di clock
varierà leggermente rispetto al valore nominale.
Potendo quindi essere le riflessioni causa di un aumento di jitter, è bene che
esse siano misurate (tipicamente in decibel), su un certo range di frequenze.
Lunghezza del cavo
La lunghezza di un segmento di cavo è misurata attraverso il metodo
riflettometrico, cioè servendosi di un TDR (Time-domain reflectometer) che
invia dei segnali impulsivi lungo il segmento sotto test e misura il tempo, in
nanosecondi, che trascorre prima che esso possa ricevere il segnale riflesso
generato alla fine del cavo.
A partire da tale informazione e una volta nota la velocità con cui si propaga il
segnale sul cavo (per i cavi in rame essa è tipicamente compresa fra il 55% ed il
75% di quella della luce nel vuoto), è possibile calcolare la lunghezza del cavo
stesso. Quest’informazione è importante in quanto, per ogni topologia di rete
LAN, esiste un limite massimo consentito per la lunghezza del segmento,
superato il quale le prestazioni complessive della rete possono diminuire, in
21
quanto, ad esempio, l’attenuazione sperimentata dal segnale può divenire
eccessiva. Inoltre, ricorrendo al metodo riflettometrico, è possibile anche
individuare dei punti di guasto presenti sulla rete, in quanto tali guasti
determineranno un disadattamento d’impedenza, la quale a sua volta sarà
causa della generazione di un’onda riflessa; anche in questo caso misurando il
tempo intercorrente tra l’invio del segnale e la ricezione dell’onda riflessa si può
capire in quale punto è localizzato il problema sul link.
Test sui cavi coassiali
Un altro comune mezzo di trasmissione è il cavo coassiale.
.
Figura 1.9
Sebbene esso abbia avuto per lungo tempo notevole diffusione nelle reti locali,
tanto è vero che è stato adoperato in due diversi cablaggi Ethernet (il 10Base5 e
il 10Base2), esso sta gradualmente cadendo in disuso, soppiantato nella fascia
ad alte prestazioni dalle fibre ottiche, e in quella a medie prestazioni dai
doppini che, rispetto ai cavi coassiali, hanno i vantaggi di un minor costo,
minore difficoltà d’istallazione e minor ingombro (si pensi che un cavo Ethernet
10Base2 trasporta un singolo segnale ed occupa circa lo stesso spazio di un cavo
TP a 4 coppie, che può trasportare 4 segnali) ma soprattutto presentano una
maggiore flessibilità e modularità.
22
Le caratteristiche più importanti da misurare nelle infrastrutture realizzate con
cavi coassiali sono la lunghezza del segmento, l’attenuazione e le resistenze di
terminazione (si ricordi infatti che le reti 10Base2 e 10 Base5, devono essere
terminate su resistori a 50 ohm); le informazioni così ricavate aiutano
nell’individuazione di problemi quali corto circuiti, connettori staccati,
curvature dovute ad un inadeguato cablaggio, resistenze di terminazione
imperfette o mancanti, eccessive lunghezze dei segmenti.
Si noti che è molto importante quando ad esempio si effettuano dei test TDR
che ogni ripetitore presente nel segmento sotto test venga disattivato prima di
effettuare delle misurazioni, in quanto alcuni ripetitori sono dotati di una
funzione di segmentazione automatica in grado di disattivare l’intero segmento
su cui sono stati rivelati dei malfunzionamenti e poi trasmettere dei segnali di
test ad intervalli regolari al fine di determinare se questi malfunzionamenti
ancora persistono; ebbene è chiaro che questi segnali devierebbero i risultati dei
test TDR e quindi, al fine di ottenere valori corretti, è necessaria una preventiva
disattivazione di tali ripetitori.
Test sulle fibre ottiche
L’ultimo mezzo trasmissivo di cui parliamo sono le fibre ottiche.
Figura 1.10
23
La trasmissione in fibra ottica si basa sulla propagazione di impulsi di luce,
ciascuno dei quali rappresenta un bit.
Il grande successo delle fibre ottiche è dovuto a diversi fattori fra cui:
-
totale immunità da disturbi elettromagnetici;
-
alta capacità trasmissiva;
-
bassa attenuazione;
-
dimensioni ridottissime e costi contenuti.
I tipici test effettuati sulle fibre sono quelli volti alla misurazione
dell’attenuazione e delle riflessioni lungo il percorso di trasmissione, per
misurare le quali ci si serve di un riflettometro ottico nel dominio del tempo
(OTDR), e quelli invece volti alla misurazione della potenza del segnale al
trasmettitore e ricevitore, per misurare la quale invece ci si serve di misuratori
di potenza ottica. Ricorrendo a questo genere di test è possibile evidenziare
problemi relativi alla potenza della luce, ad un’eccessiva attenuazione lungo la
fibra, ad interruzioni sulle linee e a perdite dovute alle giunture.
1.3.2.2
Interferenze esterne
Seri problemi di trasmissione possono derivare dal rumore indotto nei cavi in
rame, in ambienti caratterizzati da alti livelli di interferenza elettromagnetica
(EMI). Qualora non si riesca ad individuare delle ovvie sorgenti di tal genere di
disturbi nelle vicinanze, potrebbero essere d’aiuto delle misurazioni in
frequenza effettuate attraverso un analizzatore di spettro, in quanto, in tal
modo, si riescono a visualizzare i segnali presenti in un certo range di frequenze
sul mezzo di trasporto; le più comuni sorgenti d’interferenze elettromagnetica,
comunque sono quelle di seguito riportate:
24
Il modo più sicuro di prevenire i problemi di interferenza elettromagnetica
consiste nell’adoperare delle fibre ottiche piuttosto che cavi in rame.
1.4 Test di conformità ed interoperabilità
sulle LAN
I test di conformità ed interoperabilità sono test da effettuare sulla rete in fase di
sviluppo.
In particolare i primi mirano a verificare che il dispositivo sotto test, funzioni in
accordo alle sue specifiche di progetto. Tipicamente essi prendono in
considerazione due diversi aspetti del dispositivo sotto test che sono:
-
la corretta implementazione dei protocolli specificati;
-
il soddisfacimento dei requisiti prestazionali dell’applicazione che
dovrà essere eseguita su di esso.
Generalmente la tecnica impiegata consiste nel sollecitare l’apparato con un set
di messaggi protocollari noti, osservarne la risposta e confrontarla con un
riferimento; si deve tener presente che più complesso diventa il protocollo e più
complessi diventano questi test perché nel verificare la conformità protocollare
occorre essere esaustivi, considerando tutte le possibili combinazioni di stimoli
25
protocollari che si possono inviare al sistema sotto test.
I test di interoperabilità invece, più precisamente, mirano a verificare il
comportamento congiunto di due o più elementi di rete e, poiché questi sono
svolti sempre dopo essersi assicurati che i singoli dispositivi superino i test di
conformità, nel caso in cui un test di interoperabilità dia un esito negativo, non
sarà possibile attribuire un malfunzionamento né a uno dei due dispositivi né
ad entrambi ma il malfunzionamento sarà dovuto solo al modo in cui essi
interagiscono.
La conformità ad uno standard protocollare non è tanto critica nelle LAN, in
quanto le tecnologie LAN sono usate principalmente in reti dati private e
pertanto l’aderenza a standard nazionali ed internazionali per i dispositivi di
rete non è prescritta per legge. Tuttavia, vista la crescente complessità delle
tecnologie LAN e l’importanza dell’interoperabilità tra gli elementi di rete, sono
stati sviluppati un certo numero di suite di test da parte di vari forum
industriali, quali ad esempio il Fast Ethernet Consortium e la Gigabit Ethernet
Alliance. Si tenga presente che sono attualmente disponibili suite di test per
tutte le principali tecnologie LAN, quali ad esempio Ethernet a 10/100/1000
Mbit/s, Token ring e FDDI, che forzano una certa standardizzazione in
ambiente LAN anche se non strettamente necessaria.
Comunque, data la complessità di questi test, essi sono di solito svolti dai
costruttori di apparati che appunto testano i propri componenti LAN così da
garantire la loro conformità agli standard e la loro interoperabilità.
1.5
Test di carico sulle LAN
La conformità prestazionale può essere verificata dall’utente, controllando
determinati aspetti dell’apparato sotto test prima della sua messa in operazione
mediante istallazione, sottoponendolo cioè ai cosiddetti test di carico, i quali
26
mirano tipicamente a valutare quali siano le prestazioni limite dell’elemento di
rete in esame, mandando in overload la rete. Si tenga presente infatti che
attualmente, mentre i componenti di rete adoperati in tecnologie LAN
tradizionali quali Ethernet a 10 Mbit/s, Token ring e FDDI, riescono
generalmente ad operare ad un massimo carico senza incorrere in difficoltà,
non altrettanto può dirsi per quei componenti adoperati in LAN ad alta velocità
quali Ethernet a 100 o 1000 Mbit/s, in quanto in questo range di velocità, le
capacità dei vari componenti possono variare molto a seconda della casa
costruttrice. Sebbene tipicamente i costruttori pubblichino esiti di test
prestazionali da loro eseguiti, tali risultati possono solo essere adoperati come
linee-guida, che debbono poi essere interpretati in termini del traffico presente
sulla rete in cui l’apparato si trova; ad esempio un costruttore di router
potrebbe pubblicare una specifica prestazionale in cui stabilisce il numero di
pacchetti per unità di tempo che possono essere instradati, tuttavia sono molti i
fattori di cui egli potrebbe non aver tenuto conto nell’effettuare i propri test e
che invece influenzano le prestazioni del dispositivo sotto test, quali ad
esempio, la dimensione variabile dei pacchetti, il numero di indirizzi sorgente e
destinazione presenti nella tabella di routing. Tutti questi aspetti hanno poi
l’immediata conseguenza che quando quello stesso router sarà attivo all’interno
di una rete in fase operativa, le sue reali prestazioni saranno solo una frazione
di quelle dichiarate dalla casa costruttrice; è quindi sempre bene che l’utente
effettui dei test, per così dire, “in-house”, prima di mettere il prodotto in
operazione. La tecnica più comunemente adoperata per realizzare questo
genere di test consiste nel catturare il traffico dalla rete reale e replicarla su una
rete di test a cui sia stato connesso il dispositivo da testare per osservarne così i
risultati. Questo è un esempio importante di “emulazione”metodo applicabile
ad un qualunque scenario ma riferito in tal caso al traffico di rete; nel caso
specifico la tecnica emulativa
è impiegata per testare l’apparato di rete
generando un traffico di rete uguale a quello che interviene nelle condizioni
27
reali. L’emulazione è a metà strada tra la simulazione e la realtà; emulare
significa replicare una situazione reale con un opportuna strumentazione,
simulare significa ricreare una situazione reale numericamente, costruendo
modelli numerici per gli apparati e per il traffico.
E’ molto importante inoltre che tutti i costruttori specifichino dei parametri
prestazionali dei propri apparati adoperando
fra
l’altro
un’adeguata
terminologia e metodologia, in modo da rendere più semplice ad un utente il
confronto fra le diverse case produttrici; per questa ragione l’IETF
Benchmarking working Group ha steso una serie di documenti volti proprio a
specificare quanto prima detto, fra i quali ad esempio annoveriamo:
-
Metologie di Benchmarking per dispositivi di commutazione delle LAN
(RFC 2889);
-
Terminologie di Benchmarking per dispositivi di commutazione delle LAN
(RFC 2285);
-
Terminologie di Benchmarking per strumenti di interconnessioni delle reti
(RFC 1242);
-
Metologie di Benchmarking per strumenti di interconnessioni delle reti
2544);
-
Terminologie di Benchmarking per le prestazioni dei firewall (RFC 2647).
I parametri prestazionali, di cui si dice in tali documenti sono ad esempio:
-
throughput di pacchetti;
-
ritardo subito dai pacchetti;
-
tasso di perdita dei pacchetti.
28
Capitolo 2
Ethernet troubleshooting
2.1 Introduzione
Ethernet è la tecnologia LAN di gran lunga più diffusa e la seguente trattazione
riguarderà il troubleshooting relativo a 10/100 /1000 Mbit/s Ethernet.
Il Troubleshooting è una tipologia di collaudo delle reti che viene effettuata con
lo scopo di identificare e localizzare i problemi nel funzionamento della rete e
dei suoi componenti una volta che questi si siano presentati . Non esiste una
procedura generale per fare troubleshooting ma vi sono delle linee guida che si
possono seguire quando si presenta un determinato problema utilizzando
opportuni strumenti.
2.2 Strumenti
Gli strumenti impiegati per il troubleshooting in Ethernet sono principalmente
gli analizzatori di protocollo che possono monitorare l’attività del solo
segmento di rete sul quale sono installati; per estendere l’attività di
monitoraggio a più segmenti si ricorre a sistemi distribuiti .
Questi sistemi prevedono una stazione centralizzata di gestione della rete detta
Management Station su cui gira una manager application che raccoglie i dati
provenienti da entità sparse in diversi punti della rete, detti agent, ovvero
29
processi funzionanti nei dispositivi da gestire chiamati managed devices .
La manager application può interagire con centinaia di managed devices
attraverso il protocollo SNMP (Simple Network Management Protocol). Le
informazioni raccolte dagli agent relativamente ad un managed object vengono
memorizzate in una sorta di database detto MIB (Management Information Base).
Il troubleshooting per individuare ,invece, problemi di livello fisico può essere
realizzato mediante “cable tester”, multimetri. Nella definizione “cable tester”
rientrano gli strumenti in grado di verificare l’integrità e la conformità alle
specifiche delle infrastrutture di cablaggio. Un cable tester potrebbe essere un
oscilloscopio o più semplicemente uno strumento in grado di realizzare una
minima analisi sul segnale sufficiente per la specifica tecnologia. Quest’ultimo
rispetto all’oscilloscopio, che è uno strumento più generale in grado di
effettuare un grande numero di misure, presenterà un costo minore
e
un’affidabilità superiore nell’ambito dello specifico set di misure da esso
reeaizzabili.
2.3 Linee guida del troubleshooting
Il primo passo da compiere consiste nell’analisi della topologia della rete sotto
test, dei componenti di rete, delle connessioni, dei mezzi trasmissivi e delle
relazioni tra le sezioni che la compongono.
Dopodiché si passa alla raccolta dei sintomi e caratteristiche di un problema,
maggiori sono le informazioni a disposizione migliori sono le possibilità di
risolvere il problema velocemente ed efficientemente.
Se la rete è già in opera viene utilizzato un analizzatore di protocollo per la
rilevazione delle principali statistiche operative di un singolo segmento di rete :
-
Percentuale d’uso della capacità di una rete cioè il rapporto tra la quantità di
dati inviati sul canale e capacità massima del canale per cento (se questa
30
percentuale è < 40 % la rete sta funzionando in condizioni ottimali). È
importante osservare che con la definizione dati inviati sulla rete si vuole
indicare il throughput medio calcolato in un intervallo di tempo in quanto
se si realizzasse un’osservazione istantanea del link quest’ultimo o sarebbe
occupato alla massima capacità o non occupato. Quando invece si calcola il
throughput, che è diverso dalla capacità, si fa un’analisi in un certo
intervallo di tempo e si mediano zone di completa occupazione con zone di
completa non occupazione.
- Tasso di trasmissione (throughput) delle frame ovvero il tasso di frame
immesso sulla rete in frame/s; ciascuna stazione non deve inviare più di
5000 frame/s, al fine di garantire che le altre stazioni della rete non vengano
saturate dall’invio di troppi pacchetti.
-
Errori FCS (Frame check sequence) : nelle frame Ethernet è presente il campo
FCS che consente di rilevare se i bit nella frame sono cambiati, l’FCS è
ottenuto correlando gli altri bit nella frame (esclusi i bit nel preambolo).
-
Tasso di collisioni.
-
Percentuale dei pacchetti broadcast e multicast.
-
Numero di pacchetti sovradimensionati.
-
Numero di pacchetti sottodimensionati.
-
Numero di stazioni trasmittenti.
31
Figura 2.1
In molti casi l’analisi delle statistiche operative, ovvero, l’individuazione
dell’esistenza o meno di correlazioni tra le informazioni rilevate e registrate
sistematicamente nel tempo, consente di risalire direttamente alla sorgente del
problema. Per esempio se viene osservata una correlazione tra il numero di
stazioni attive, il numero di collisioni e l’uso della capacità della rete è
altamente probabile che il problema riguardi componenti attivi nella rete (nodi
di rete, ripetitori), invece se non c’è tale correlazione è più probabile che la
sorgente del problema risieda nell’infrastruttura di cablaggio.
Tuttavia il problema non sempre può essere localizzato perché i sintomi rilevati
in un segmento possono essere causati da problemi in segmenti adiacenti o
addirittura in parti più remote di una rete, in tal caso saranno necessarie misure
contemporanee nei diversi segmenti mediante sistemi di monitoraggio
32
distribuiti. L’analisi dei risultati indicherà se sintomi in un segmento sono
causati da problemi in altri. La localizzazione del segmento responsabile del
problema che occorre è conseguita grazie ad un’analisi proattiva conosciuta
come “baseling”, realizzata su più segmenti contemporaneamente nelle normali
condizioni operative, che comprende le seguenti fasi :
-
la raccolta dei dati ad intervalli regolari
-
la creazione dei report ottenuti elaborando e correlando i dati
-
l’interpretazione dei risultati.
L’analisi di rete proattiva
consente di individuare i trend della rete e i
potenziali problemi prima che essi si verifichino ma fornisce anche un potente
strumento impiegato per localizzare i problemi quando essi si manifestano
sottoforma di diversi sintomi. Difatti un confronto tra vecchie e più recenti
analisi realizzate sulla rete durante l’occorrenza del problema può essere di
grande aiuto al fine di restringere l’area interessata dal guasto. Tale fase
presenta enormi difficoltà in quanto le reti LAN si sviluppano localmente con
criteri specifici dell’ambiente in questione, non esistono, pertanto, dei veri e
propri riferimenti, normative o standard che chi gestisce la rete deve essere in
grado di costruirsi, sulla base della propria esperienza, accumulando risultati
relativi a momenti diversi della vita della rete mediante la suddetta analisi.
Una volta individuato il segmento responsabile del problema segue una fase
che ha come obiettivo l’individuazione del guasto a tal fine si rilevano le
principali statistiche operative del segmento in questione.
La fase successiva alla rilevazione delle principali statistiche operative del
segmento dipende dalla natura dei sintomi, difatti se i sintomi sono periodici o
continui sono sufficienti delle misurazioni a breve termine ma se i sintomi
occorrono ad intermittenza sono necessarie misurazioni a lungo termine, perché
devono essere realizzate finché le statistiche operative non sono misurate
durante l’occorrenza del problema.
In ogni caso a questo punto la procedura di troubleshooting è applicata ai
33
componenti della rete più vicini al problema mediante un’analisi che viene
effettuata su tutti i livelli della pila OSI procedendo per ordine dal livello più
basso a quello più alto o viceversa, solitamente è consigliata una strategia di
analisi bottom-up poiché l’80% dei guasti se non anche di più occorrono
principalmente a livello fisico e a livello data link.
Ad esempio se i problemi riguardano un singolo nodo di rete il passo
successivo consiste nell’analisi dei componenti software e hardware della
stazione ma se la sorgente del problema non è individuata il dominio di analisi
è di volta in volta allargato.
Se non viene rilevato alcun guasto l’analisi viene estesa al transceiver, al cavo
mediante cui esso è connesso alla NIC del nodo, al connettore di potenza al
cavo Ethernet, al wall-jack , al cavo verso l’hub , al cavo verso il server , e così
via. Nel caso di sintomi intermittenti si possono definire anche filtri e allarmi
per gli errori delle frame Ethernet , configurando l’analizzatore di protocollo in
modo da catturare i pacchetti Ethernet che vengono trasmessi quando occorre
un errore, inoltre è essenziale registrare l’esatto istante dell’evento errore, in
quanto questa informazione può successivamente essere messa in correlazione
con altri eventi nella rete su un determinato nodo come l’avvio di una specifica
applicazione, connessioni attraverso i router, accesso a Internet.
Se il problema non viene localizzato o se il problema che si pensava potesse
essere localizzato effettivamente non lo è, si cerca la sorgente del problema
mediante una segmentazione sistematica della rete.
Al fine di operare la segmentazione suddetta della rete si ricorre alla
documentazione di rete per identificare quanti hub sono coinvolti.
Se è coinvolto un numero di hub limitato ha senso isolare un hub alla volta e
controllare se il problema scompare. Se, invece, è coinvolto un numero grande
di hub la rete deve essere fisicamente tagliata in due o più parti e monitorata.
Individuata la porzione di rete che produce il problema, questa viene a sua
volta segmentata finché viene trovato il segmento contenente la sorgente del
34
problema.
La procedura di segmentazione consente di individuare la causa del problema
velocemente mediante un’opportuna scelta dei punti di segmentazione ma è un
metodo che può provocare considerevole disordine nelle operazioni di rete, è
quindi applicata, come ultima risorsa, quando il problema comunque
indebolisce pesantemente l’operatività della rete.
Un altro metodo efficiente di troubleshooting consiste nel metodo di analisi e
confronto il quale prevede il confronto di elementi di rete in questione con
elementi di rete in opera simili o identici .
Tuttavia questo metodo viene utilizzato poco perché gli odierni server e router
sono raramente identici o magari soggetti ad usura differente.
2.4 Sintomi dei problemi in Ethernet
Nelle reti Ethernet, molti sintomi dei problemi, quali carichi di traffico,
presenza di collisioni occorrono anche nelle normali condizioni operative.
Difatti il protocollo di accesso al mezzo usato in Ethernet è un protocollo di
accesso casuale (CSMA/CD) che prevede il verificarsi di collisioni. Tuttavia
l’avvento di certi tipi di pacchetti difettosi consente di individuare l’effettiva
occorrenza dei problemi che non rientrano nel regolare funzionamento di una
rete.
I pacchetti difettosi possono essere suddivisi nelle seguenti categorie:
-
frammenti di collisioni locali (local collision)
-
frammenti di collisioni remote (remote collision)
-
frammenti di collisioni ritardate (late collision)
-
pacchetti sottodimensionati
-
pacchetti sovradimensionati
-
errori FCS (Frame Check Sequence)
35
-
errori di allineamento
-
errori di rumore
-
errori di lunghezza
Notiamo che i primi tipi di pacchetti difettosi sono una diretta conseguenza
delle collisioni quindi, prima di descrivere in dettaglio i vari sintomi appena
esposti, nel paragrafo successivo daremo una breve panoramica su cosa si
intende per collisione in una rete Ethernet.
2.4.1 Collisioni
Le collisioni occorrono quando due stazioni sullo stesso segmento cominciano a
trasmettere frame Ethernet contemporaneamente. Con riferimento ad una rete
Ethernet operante a 10Mbit/s in cui vengono rispettati i limiti imposti dallo
standard sulla distanza massima (2.5 km), supponiamo che il nodo 1 voglia
trasmettere dei dati ad un nodo 2 (vedi figura) e le due stazioni si trovano alla
massima distanza possibile.
1
25.51μ
s
25.51μ
s Figura 2.2
Il primo bit di una frame, inviato dalla stazione 1, impiega
2
25.51µs per
raggiungere il nodo 2 e se in un istante di tempo poco inferiore anche quest
ultimo inizia a trasmettere una frame, questa collide con quella inviata dalla
prima stazione.
Nella collisione le tensioni dei due segnali si sommano e il segnale di collisione
36
risultante impiega un massimo di 25.51µs per ritornare al trasmettitore .
Quindi il tempo più lungo che la stazione 1 impiega per riconoscere
l’occorrenza di una collisione normale e fermare la trasmissione è 51.2 µs , o 512
bit
pari a 64 byte; i frammenti di collisione normali sono, pertanto, di
lunghezza inferiore a 64 byte.
Ricordiamo che 64 byte è la lunghezza minima, prevista dallo standard, per una
frame.
Inoltre i frammenti di collisione sono tali che i contenuti della frame sono
completamente distrutti e la checksum non è riconoscibile.
2.4.2 Collisioni remote e locali
Le collisioni che occorrono in un segmento locale sono chiamate collisioni locali,
precisamente avvengono lungo il link in una topologia 10Base2 o 10Base5
(senza ripetitori) o tra un host e l’hub in una topologia 10/100/1000BaseT.
I frammenti
di collisione locale sono di lunghezza minore di 64 byte e
presentano un segnale di tensione più elevato delle frame normali ed un FCS
non valido.
Le collisioni remote sono, invece, collisioni che avvengono tra frame provenienti
da nodi appartenenti a diversi segmenti di una rete trasportati da un ripetitore
o hub all’esterno del proprio segmento di appartenenza.
La collisione è remota perché è riferita a quello specifico hub e non ad un altro
(spesso infatti alla porta di un hub potrebbe essere collegato un segmento Lan
composto da più hub).
I segnali di tensione relativi ai frammenti di collisione remoti non sono più
elevati di quelli relativi a frame normali perché corretti dall’hardware del
ripetitore. Quando il ripetitore rileva una collisione remota completa il
frammento di collisione con una sequenza di bit jam ed inoltra il frammento di
37
collisione con l’aggiunta dei bit jam su tutte le porte in modo da evitare ulteriori
collisioni e fermare le trasmissioni nei segmenti connessi. Sebbene l’occorrenza
delle collisioni rientri nelle normali modalità operative di una rete Ethernet la
crescita del numero di collisioni può dipendere da:
-
resistori di terminazione difettosi o non installati; le reti 10Base2 e 10Base5
devono essere terminate con resistori di 50Ω, le verifiche del valore di tale
resistenza (48Ω<R<52Ω) possono essere realizzate con un multimetro
-
connettori a T allentati o difettosi; per individuare il problema è necessario
controllare tutte le connessioni lungo il percorso trasmissivo d’interesse
-
numero eccessivo di stazioni in un segmento; tale numero non deve essere
superiore a 100 in un segmento 10Base5 e 30 in un segmento 10Base2
-
curvatura dei cavi; in tal caso per localizzare il danno si può utilizzare un
“cable tester”
-
cavi non conformi allo standard 802.3; ciò potrebbe essere causato da chi
installa o, qualora non sia lo stesso, da chi ha fornito all’installatore il
materiale. E’ necessario controllare le specifiche dei cavi che si utilizzano.
2.4.3 Collisioni ritardate (late collision)
Una
collisione
ritardata
occorre
quando
due
stazioni
trasmettono
contemporaneamente ma nessuna delle due rileva l’avvenuta collisione prima
di aver trasmesso 64 byte; i frammenti di collisione ritardata sono, pertanto, di
lunghezza maggiore di 64 byte e possono essere riconosciuti rilevando
l’incremento del segnale di tensione nel caso di collisioni locali ritardate o per
mezzo della mancanza di checksum e presenza di bit jam nel caso di collisioni
remote ritardate. Le collisioni ritardate occorrono quando il tempo di
propagazione del segnale da un nodo terminale all’altro è maggiore del tempo
che impiega una stazione a mandare un pacchetto di dimensione minima sulla
38
rete.
Le cause delle collisioni ritardate sono:
-
NIC (Network Interface Card) difettose; per l’individuazione del nodo
responsabile si deve utilizzare un analizzatore di protocollo che raccolga
informazioni come il numero di collisioni, i nodi attivi e le metta in
correlazione. Se il problema non viene localizzato è necessario passare alla
segmentazione della rete
-
impiego di un numero eccessivo di ripetitori in cascata; bisogna, in tal caso,
limitare a 4 il numero di ripetitori o sostituire un ripetitore con un bridge o
cambiare la configurazione di rete
-
cavi difettosi; per localizzare il problema deve essere impiegato un “cable
tester”
-
cavi più lunghi della lunghezza massima specificata per una data topologia;
i cavi devono essere misurati con un “cable tester”.
2.4.4 Altri sintomi di malfunzionamento
Pacchetti sottodimensionati
Un pacchetto corto presenta una lunghezza minore di 64 byte ma una FCS
valida. Un runt è un pacchetto di lunghezza minore di 64 byte con una FCS non
valida.
Poiché tali frame presentano una dimensione minore di quella minima, non
sempre è incluso l’indirizzo sorgente e risulta, pertanto, difficile associarle ad
un particolare nodo. I pacchetti sottodimensionati sono l’effetto di collisioni
locali o remote oppure sono prodotte da NIC difettose, in tal caso bisogna
utilizzare un analizzatore di protocollo per cercare di catturare i pacchetti
difettosi e identificare la stazione che li ha emessi mediante l’indirizzo sorgente,
39
se l’indirizzo sorgente non è leggibile si deve cercare di individuare la NIC
difettosa mettendo in correlazione le informazioni raccolte.
Pacchetti sovradimensionati
I pacchetti lunghi sono frame di lunghezza maggiore di 1518 byte ma
presentano una FCS valida. Ricordiamo che lo standard prevede, oltre che una
dimensione minima, anche una dimensione massima per una frame pari a 1518
byte. Secondo lo standard IEEE 802.3 un jabber è una frame più lunga di 1518
byte con FCS non valida.
Le cause dei pacchetti sovradimensionati sono:
-
NIC (Network Interface card) difettose; in tal caso si deve utilizzare un
analizzatore di protocollo per identificare la NIC difettosa mediante l’analisi
dell’indirizzo sorgente presente nelle frame
- differenti riferimenti di potenziale nelle reti 10Base2 e 10Base5; ogni rete ha
bisogno di un riferimento e per semplicità si sceglie come potenziale di
riferimento il “ground” ovvero il potenziale di terra perché è quello che
abbiamo a disposizione più facilmente, anche se nessuno ci vieta di
sceglierne un altro. Nell’ambito di una rete Ethernet, che è geograficamente
estesa, è possibile per ragioni di installazione, realizzazione, praticità, avere
più punti diversi in cui riferirsi con potenziali di riferimento e visto che il
riferimento di terra dovrebbe essere lo stesso in ogni punto è chiaro che
posso avere più appoggi allo stesso riferimento. In realtà però ciò è vero solo
teoricamente perché in pratica i potenziali di terra sono differenti a seconda
della zona a cui ci si riferisce (ci potrebbe essere un apparato collegato ad un
riferimento posto vicino ad un dispersore ed un altro no) e impiegando più
agganci allo stesso potenziale in realtà mi sto agganciando a punti che sono
a potenziale diverso e ciò genera una differenza di potenziale ed un
40
passaggio di corrente, generalmente continua o una corrente che sta alla
frequenza industriale di 50Hz, nel cavo della rete. Scendendo un poco più
nel dettaglio tale corrente diventa un problema perché va a polarizzare
diversamente tutti i dispositivi elettronici, portandoli a lavorare a diverse
condizioni di funzionamento (cioè non saranno più garantite quelle
caratteristiche nominali e di conseguenza non avrò più quel preciso livello
di segnale, quel guadagno, quella potenza e tutto ciò che era previsto a quel
potenziale di riferimento) e quindi ad assumere un comportamento diverso
da quello che dovrebbe essere in realtà. La verifica della presenza di
corrente DC nella rete si può effettuare con un multimetro.
Errori FCS
Le frame che presentano una FCS non valida contengono un errore FCS, nella
maggior parte dei casi l’header di queste frame sono leggibili e la stazione
trasmittente può essere identificata da un analizzatore di protocollo che cattura
e decodifica le frame. Gli errori FCS possono essere l’effetto di collisioni ma se
l’analisi condotta da un analizzatore di protocollo non rileva una correlazione
tra il numero di collisioni e il numero di errori FCS in un periodo di tempo le
cause degli errori FCS possono essere:
-
NIC difettose; in tal caso si deve utilizzare un analizzatore di protocollo per
misurare l’attività di una stazione sospetta, per esempio in frame/s, e il
numero di errori FCS e se si riscontra una correlazione tra questi due fattori
c’è una buona probabilità di aver trovato la causa del problema
-
connettori allentati o difettosi sulle NIC, ripetitori e hub; per individuare
questo tipo di problema si devono controllare le connessioni su tutto il
percorso trasmissivo
-
rumore e interferenza sulla rete prodotto da un riferimento di potenziale
41
difettoso o non presente; per controllare il livello di rumore sulla rete si può
utilizzare un cable tester o un multimetro
-
energia elettromagnetica ambientale (causata per esempio da cercapersone,
ascensori, telefoni mobili, etc..) che si disperde nei cavi Ethernet; tale segnale
di disturbo si accoppia con il nostro segnale utile ottenendo un segnale
risultante diverso da quello originario. Questo diventa un problema serio
soprattutto se il segnale e il rumore esterno viaggiano alla stessa frequenza,
in tal caso il segnale utile non si può più recuperare, invece qualora abbiano
frequenze diverse, cioè siano spettralmente diversi e quindi localizzati in
range di frequenza differenti, è possibile con un filtraggio recuperare la
parte di interesse. Si può impiegare un multimetro per effettuare le misure
di interferenza elettromagnetica
-
attenuazione del segnale trasmesso.
Errori di allineamento
Le frame Ethernet che non terminano con un ottetto di bit, ovvero il numero di
bit in tale pacchetto non è un multiplo intero di 8, presentano un errore di
allineamento. Le frame con errori di questo tipo possono essere l’effetto
dell’occorrenza di collisioni altrimenti possibili cause sono:
-
NIC difettose che trasmettono qualche bit in più dopo l’FCS; la NIC difettosa
può essere localizzata con un analizzatore di protocollo che cattura le frame
con gli errori di allineamento e risale attraverso esse all’indirizzo sorgente
-
problemi elettrici nella rete.
42
Errori dovuti al rumore (noise errors)
Gli errori di rumore sono causati da tensioni indotte nei cavi della rete da
sorgenti esterne tali da far ritenere alle altre stazioni che il mezzo sia occupato
dalla trasmissione di dati. Gli errori di rumore provocano un basso uso delle
capacità della rete e calo delle prestazioni della stessa.
Le cause degli errori di rumore sono:
- riferimenti di potenziale difettosi
- dispersione elettrica nel cablaggio.
In entrambi i casi si possono fare delle verifiche utilizzando un multimetro.
Errori di lunghezza
L’errore di lunghezza si manifesta in un disaccordo tra il campo lunghezza
della frame Ethernet e l’effettiva lunghezza del suo campo dati.
2.5 Problemi di cablaggio
I problemi di cablaggio, come già evidenziato nel precedente capitolo, sono
ancora molto comuni nelle reti Ethernet. Cause tipiche dell’occorrenza di tali
problemi sono:
-
cavi difettosi o di bassa qualità. I problemi possono essere causati da una
curvatura dei cavi o da una non conformità dei cavi alle specifiche
- scorretta impedenza caratteristica dei cavi
- cavi di lunghezza superiore a quella specificata per una data topologia
- resistori di terminazione di un segmento di rete difettosi
- dispersione elettrica
43
-
interferenza elettromagnetica che può essere dovuta alla presenza di
dispositivi quali fotocopiatrici, telefoni mobili, cercapersone oppure ad un
riferimento di potenziale difettoso.
2.6 Network Interface Card
Nelle reti Ethernet due tipi di Network Interface Card (NIC) sono usate: quelle
con MAU (Medium Attachment Unit) integrato, in cui la NIC è connessa
direttamente al mezzo di comunicazione tramite BNC, RJ-45 o connettori per
fibre ottiche e quelle con MAU esterno, in cui il collegamento tra la NIC e il
MAU avviene con un cavo AUI (Attachment Unit Interface) come mostra la
seguente figura.
Figura 2.3
La scheda di rete ha la funzione di collegare il nodo alla rete ed è formata da
due interfacce: l’interfaccia verso il bus del calcolatore e l’interfaccia verso la
linea (si veda figura 2.4).
44
Figura 2.4
L’interfaccia con il bus è responsabile della comunicazione con il nodo in cui è
inserita la NIC, essa trasferisce dati e informazioni di controllo tra la CPU del
nodo e la scheda di rete. L’interfaccia con il link è responsabile
dell’implementazione del protocollo dello strato di collegamento effettuando
operazioni come, per esempio, framing e deframing, ricerca dell’errore, accesso
casuale, codifica Manchester, link management.
Per scegliere una scheda di rete da inserire in un impianto, si deve conoscere:
-
il tipo di rete (ogni tipo di rete richiede un tipo preciso di NIC
corrispondente);
- il tipo di cavo necessario (ad esempio cavo twisted pair, cavo coassiale, cavo
FDDI o altro);
-
il tipo di BUS presente nel computer dove deve essere inserita la scheda.
Nell’installare una scheda di rete bisogna fare attenzione che essa lavori
correttamente con altre periferiche collegate al computer. Ogni componente,
infatti, può interagire con la CPU tramite un’opportuna linea di interrupt e per
evitare malfunzionamenti e confusioni ogni componente deve avere la propria.
Tale linea di interrupt da la possibilità alla scheda di rete di essere servita con
una certa priorità dalla CPU.
La CPU, infatti, al verificarsi dell’interrupt, e, sulla base della priorità ad esso
associato, può interrompere le operazioni intraprese per avviare un opportuna
routine (detta routine di risposta all’interrupt) grazie alla quale interagire con la
scheda di rete per ricevere delle informazioni che possono essere, per esempio,
45
tutti i pacchetti da inviare allo strato applicativo. Se non ci fosse stata la linea di
interrupt, invece, la scheda avrebbe dovuto aspettare e sarebbe stata servita solo
dopo che la CPU avrebbe completato le operazioni già intraprese con altre
periferiche.
2.7 MAU (Medium Attachment Unit)
A livello fisico vengono definite tutte le componenti che intervengono nella
trasmissione dei dati tra i dispositivi. Queste componenti servono a specificare:
le caratteristiche elettriche e meccaniche di cavi e connettori, il significato dei
contatti dei connettori, il livello del segnale elettrico utilizzato nella codifica di
linea, la temporizzazione e la relativa durata del bit (bit time) e il transceiver.
Come mostra la figura seguente:
Figura 2.5
il modello IEEE 802 suddivide il livello fisico in quattro sottolivelli che sono
Physical Layer Signalling (PLS), Attachment Unit Interface (AUI), Physical
Medium Attachment (PMA) e Medium Dependent Interface (MDI). PMA e
46
MDI insieme formano il Medium Attachment Unit (MAU).
Il Physical Layer Signalling (PLS) che si interfaccia con il sovrastante
sottolivello MAC è il sottolivello che si occupa di segnalare al MAC stesso tutte
le condizioni del mezzo fisico (per esempio mezzo occupato/libero, collisione
avvenuta). Queste funzioni sono realizzate nel transceiver, conosciuto anche
come MAU.
Figura 2.6
L’Attachment Unit Interface (AUI) definisce le specifiche del cavo transceiver
(cavo AUI o cavo drop) che è costituito da cinque coppie di conduttori
schermati (con l’aggiunta di una schermatura globale) che hanno il seguente
significato (vedi figura 2.6):
47
- “Data Out” per trasmettere i dati dalla stazione al MAU;
- “Data In” per trasmettere i dati dal MAU alla stazione;
- “Control In” per trasmettere (ordinari) segnali di controllo dal MAU alla
stazione;
- “Control Out” per la trasmissione di segnali opzionali di controllo tra il
MAU e la stazione;
- “Voltage” per fornire alimentazione al MAU (dalla stazione).
Bisogna sottolineare che tali collegamenti sono sempre realizzati a coppia per
poter prelevare una differenza di potenziale, infatti la segnalazione che si
ottiene su ciascun collegamento viene vista come variazione rispetto ad un
potenziale di riferimento. Nel nostro caso ci riferiamo alle quattro coppie
destinate rispettivamente per la trasmissione, ricezione, rilevamento delle
collisioni e alimentazione. Sono utilizzati in tal caso otto cavi in rame quattro
dei quali costituiscono i collegamenti di riferimento per ogni coppia. Se, invece,
avessimo impiegato quattro collegamenti in rame e un unico cavo comune da
cui prelevare il livello di tensione di riferimento, avremmo rischiato di
sovraccaricare tale collegamento.
La segnalazione su ciascun collegamento è data dalla differenza di potenziale
per determinare la quale c’è bisogno di una corrente e quest unico collegamento
avrebbe potuto non sopportare tutta la corrente che viene generata quando tutti
i collegamenti sono attivi.
Un’alta corrente, inoltre, può creare un alto accoppiamento magnetico
provocando interferenze condotte che si propagano lungo i cavi.
Per tali ragioni conviene sempre avere più vie di fuga per la corrente in modo
da non sovraccaricare la parte circuitale che gestisce i collegamenti.
Il connettore terminale del cavo AUI è a 15 contatti di tipo "D". Il cavo AUI
presenta un’impedenza di 78 ohm e la sua lunghezza è limitata a 50 metri. La
tabella elenca il significato dei contatti del cavo AUI. La definizione dei
collegamenti è diversa per i cavi Ethernet v2.0 e IEEE 802.3.
48
Assegnazione dei contatti e loro descrizione per i cavi IEEE 802.3
Contatto n.
Ethernet v2.0
IEEE 802.3
1
Shield
Control in shield
2
Collision presence +
Control in A
3
Transmit +
Data out A
4
Reserved
Data in shield
5
Receive +
Data in A
6
Power return
Voltage common
7
Reserved
Control out A
8
Reserved
Control out shield
9
Collision presence -
Control in B
10
Transmit -
Data out B
11
Reserved
Data out shield
12
Receive -
Data in B
13
Power
Voltage
14
Reserved
Voltage shield
15
Reserved
Control out B
Connector shield
-
Protective ground
L’AUI e il MAU sono entità sempre presenti ma non sempre visibili, dipende
dallo standard MDI usato. Nel caso dello standard 10Base5, il transceiver è un
dispositivo esterno alla scheda di rete della stazione (si veda figura 2.3). In
questo caso la connessione al mezzo fisico è realizzata tramite cavo AUI e
transceiver. Negli altri casi MAU e AUI sono integrati nella scheda di rete.
49
Il Signal Quality Error è un segnale inviato dal MAU alla scheda d’interfaccia
quando segnali non standard come le collisioni sono ricevuti. Comunque non
tutte le interfacce di rete usano i segnali SQE allo stesso modo. Le schede
Ethernet 2.0, per esempio, lavorano in heartbeat mode richiedendo un segnale
SQE dopo ogni operazione di lettura e scrittura. Tale modalità di
funzionamento permette alla NIC di tenere sotto controllo l’integrità del
circuito di collisione ed era indispensabile soprattutto quando i transceiver
erano esterni alla scheda.
Il Physical Medium Attachment rappresenta l’interfaccia funzionale con il
mezzo fisico e definisce le operazioni eseguite dal transceiver.
Le funzioni principali di un MAU sono:
-
trasmissione dei segnali elettrici sul mezzo fisico; in tal caso il MAU si
occupa della trasmissione della stringa di bit ricevuti sui conduttori Data
Out sul mezzo fisico
- ricezione dei segnali elettrici dal mezzo fisico
-
funzione di rilevamento della collisione; in tal caso il MAU intercetta le
collisioni che avvengono sul mezzo fisico e avvisa il sottolivello MAC
dell’avvenuta collisione tramite i conduttori Control In. Inoltre, al termine di
ogni trasmissione, sempre sui conduttori Control In viene trasmesso il
segnale di Signal Quality Error (SQE)
-
funzione di jabber; è stata inclusa nello standard IEEE 802.3 allo scopo di
prevenire la possibilità che una stazione occupi il mezzo fisico oltre un
determinato periodo di tempo. Il meccanismo garantisce che il MAU non
occupi il mezzo fisico per oltre 30 secondi consecutivi. Se viene superata la
finestra temporale di trasmissione, l’inoltro dei dati sul mezzo fisico viene
interrotto automaticamente dal MAU, e allo stesso tempo viene trasmesso
un segnale SQE alla stazione relativa.
50
2.8 Problemi con schede Ethernet e MAU
Il primo passo per localizzare una scheda d’interfaccia malfunzionante è di
identificare i nodi sospetti sulla rete. A tal fine si possono utilizzare gli
analizzatori di protocollo che forniscono informazioni relativamente ai nodi che
trasmettono pacchetti difettosi utilizzando programmi di test automatici.
Se gli indirizzi sorgente dei pacchetti difettosi non sono validi e non possono
essere decodificati si ricorre al metodo di correlazione: si inizia con il mappare
l’attività dei nodi sospetti e il numero dei pacchetti difettosi sul segmento, se c’è
una correlazione probabilmente è stata trovata la NIC malfunzionante. Se anche
questa strategia fallisce la sola alternativa è il metodo di segmentazione
descritto prima.
In ambito diagnostico, infatti, si parla di Fault Detection and Isolation intendendo
con tali termini tutto ciò che serve per rilevare (Detection) la presenza di un
malfunzionamento mediante dei sintomi e circoscrivere il problema (Isolation)
una volta rilevato il sintomo per stabilire qual è l’elemento o l’apparato del
sistema che produce degli effetti che poi si traducono in quei sintomi.
Una volta isolati, i nodi sospetti sono sottoposti a test singolarmente.
Schede di interfaccia con connettori AUI sono testati usando un adattatore
installato tra il connettore AUI e il transceiver. L’adattatore di test indica lo
stato dei segnali di linea, il signal quality error (SQE) e la potenza di
alimentazione. Se i pacchetti inviati non attivano i corrispondenti LED sul test
adapter allora la scheda d’interfaccia non è configurata correttamente o è
difettosa. Il passo successivo allora è di controllare i parametri settati sulla
scheda e gli hardware switch che per esempio, permettono di passare dalla
modalità SQE a quella heartbeat. Se la configurazione della scheda è corretta,
allora necessariamente il problema risiede nell’hardware, e bisognerà sostituire
la scheda stessa.
51
Se il MAU è integrato nella scheda essa è testata collegandola in una minirete
(emulazione) piuttosto che lasciandola nella rete di origine. Una minirete
10Base2 Ethernet consisterà in un connettore a T con due terminazioni di 50Ω,
invece una minirete 10/100/1000BaseT consisterà in un computer con una NIC
e un mini-hub. In tal caso per verificare se la scheda funziona correttamente si
inviano loopback packet (pacchetti IP all’indirizzo 127.0.0.1 che vengono
elaborati dal localhost).
2.9 Sintomi e Cause di Malfunzionamenti
di Schede e MAU
Sintomi caratteristici di schede Ethernet malfunzionanti sono:
- Pacchetti con un campo FCS non valido
- Alti tassi di collisione
- Pacchetti jabber e late collision
- Intermittenti problemi di connessioni in singoli nodi di rete.
Le principali cause sono:
- MAU non funzionanti correttamente
- Blown fuse (fusibili distrutti) sulla scheda
- Errori nell’operazione di configurazione della scheda.
Sintomo: pacchetti con FCS non valido e riduzione
dell’efficienza della rete
Checksum non valide sono un effetto delle collisioni che in numero limitato
sono una normale conseguenza dell’algoritmo CSMA/CD. Se gli errori sulle
52
FCS avvengono insieme con le collisioni e se il loro numero rientra in certi limiti
non c’è ragione di preoccuparsi.
Usando un analizzatore di protocollo si può misurare il numero di collisioni e il
numero di errori FCS su un periodo di tempo, confrontando le curve risultanti
si verifica se ci sono correlazioni. In assenza di corrispondenza tra numero di
collisioni ed errori FCS allora la causa di questi ultimi può risiedere nelle NIC.
Per determinare se una scheda malfunzionante è la sorgente di tali errori FCS
bisogna generare statistiche di tutti i pacchetti difettosi originati da un nodo di
rete (questo è un report standard prodotto automaticamente dalla maggior
parte degli analizzatori di protocollo). Se così si individua una stazione
sospetta, si può misurare la sua attività (in pacchetti al secondo per esempio) e
metterla in relazione con il numero di errori FCS che avvengono sul segmento.
Se i due numeri sembrano essere correlati allora molto probabilmente abbiamo
trovato la causa del problema.
Bisogna tener presente che molti problemi che riguardano la scheda di rete
avvengono in maniera intermittente, per esempio solo dopo che la scheda ha
raggiunto una certa temperatura, infatti, lo stato di polarizzazione di un circuito
elettronico dipende fortemente dalla temperatura. Per tale motivo è necessario
fare misurazioni su un lungo periodo di tempo.
Sintomo: alti tassi di collisione e riduzione dell’efficienza
della rete
Alti tassi di collisione spesso sono causati da MAU difettosi. In tal caso infatti la
funzione di carrier sense non opera e la stazione trasmette i pacchetti senza
tener conto del traffico trasmesso da altre stazioni sul segmento. Anche in tal
caso raccogliere statistiche (grazie ad analizzatori di protocollo) riguardo i nodi
attivi e il numero di collisioni per poi confrontarle è utile per individuare i nodi
53
malfunzionanti.
Sintomo: pacchetti jabber e late collision
La causa di tali problemi spesso risiede in schede di rete o MAU che non
funzionano correttamente. Per scoprire tali dispositivi malfunzionanti si
possono usare analizzatori di protocollo per raccogliere statistiche sui nodi che
inviano pacchetti difettosi per poi dedurre correlazioni tra il numero di
collisioni e l’attività di un nodo. Se non si riescono ad individuare tali
correlazioni si ricorre al metodo della segmentazione.
Sintomo: problemi intermittenti di connessione dovuti a
short o jabber packets
Schede di rete difettose spesso sono la causa della generazione di frame troppo
brevi (short packet) o troppo lunghe (jabber packet) che portano a problemi di
connessione nel segmento. Tali pacchetti difettosi si possono catturare usando
un protocol analyzer e si può così risalire alla scheda di interfaccia di rete
malfunzionante attraverso l’indirizzo sorgente. Se tale indirizzo è corrotto si
raccolgono statistiche per risalire a correlazioni o si effettua la segmentazione.
Sintomo: perdita di connessione di un singolo nodo
La perdita improvvisa (breakdown) di connessione di un singolo nodo di rete è
spesso causata da:
-
Plug del MAU non è connesso bene (loose connector)
-
Errori nella configurazione della NIC
54
-
Problemi di Signal Quality Error (modalità SQE o heartbeat)
-
Cablaggio IEEE 802.3 invece di Ethernet v2.0
-
Scheda di rete difettosa: fusibili distrutti (blown fuse).
Loose connector
Problemi intermittenti spesso sono causati da loose connector. Testare i
connettori non è sempre semplice, infatti, il cavo AUI potrebbe essere sotto il
pavimento e quindi non accessibile e in tal caso non si possono testare le
connessioni dei plug direttamente. Si ricorre allora a test di loopback. Bisogna
tener presente che in reti 10Base2 o 10Base5 si devono controllare anche i
resistori di terminazione poiché non è rarissimo che un MAU venga non
correttamente connesso alla fine del cavo in luogo del resistore.
Se invece si riescono a testare le connessioni dei plug ma il problema continua a
persistere, allora, per localizzare il problema si deve disconnettere il MAU dalla
rete e connetterlo ad una minirete. Se qui il test di loopback può essere fatto
senza problemi allora il nodo, il cavo AUI e il MAU funzionano correttamente e
il problema è sulla rete. Se il test di loopback fallisce allora bisogna continuare a
testare per vedere se il malfunzionamento è nel MAU, nella scheda o nel cavo
AUI.
Errori nella configurazione della NIC
Se la stazione non può trasmettere o ricevere pacchetti la prima cosa da
controllare sono i parametri settati nella configurazione della NIC. Errori
comunemente commessi sono:
-
sulla carta è attivata una porta sbagliata per esempio un connettore RJ-45
invece di un connettore AUI o viceversa;
55
-
l’identificativo di interrupt (che serve alla NIC per comunicare con la CPU)
è già in uso da qualche altro dispositivo del calcolatore.
Inviando pacchetti di loopback si verifica se la scheda lavora e se i pacchetti
vengono trasmessi e ricevuti. Si può inoltre sostituire il nodo con un sistema che
si sa funzioni correttamente (notebook) per determinare se il problema è nel
nodo o sulla rete a cui esso è connesso.
Problemi di Signal Quality Error
Il MAU può operare sia in modalità SQE (standard IEEE 802.3) che heartbeat
(Ethernet v2.0). Allora se un MAU che opera in modalità heartbeat è connesso
ad una scheda di rete conforme allo standard IEEE 802.3, quest’ultima
interpreterà tutti i segnali SQE, inviati dal MAU per riscontrare ogni operazione
di lettura e scrittura, come collisioni e di conseguenza interromperà la
trasmissione.
Per accorgersi di tale problema bisogna monitorare i LED sul MAU. Se le luci
relative al segnale SQE si accendono ad ogni trasmissione si deve disattivare la
modalità heartbeat nel MAU.
Cablaggio IEEE 802.3 invece di Ethernet v2.0
Usare un cablaggio AUI conforme allo standard IEEE 802.3 insieme con schede
di rete e MAU Ethernet 2.0 può creare problemi perché, come abbiamo visto, il
pinning è diverso in particolare i pin 1 e 4 sono invertiti nei due standard.
Secondo lo standard IEEE 802.3 il pin 4 è collegato al potenziale di riferimento
(ground), mentre il pin 1 è assegnato al segnale in linea. Tali assegnazioni sono
invertite in Ethernet v2.0.
56
Scheda di rete difettosa
Se la NIC è connessa alla rete attraverso un MAU esterno si usa un cavo AUI di
test per controllare l’interazione tra la scheda e il transceiver. Si può misurare la
tensione che la scheda eroga al MAU tra il pin 13 e 6. Essa dovrebbe essere tra
11.28V e 15.75V. Alcune schede hanno delle protezioni (una sorta di fusibile)
per prevenire danneggiamenti hardware dovuti a picchi di tensione. Se tali
protezioni si sono fuse la NIC non alimenta più il MAU e il nodo non è più
connesso alla rete.
2.10 Ripetitori e Hub
I ripetitori sono usati per connettere diversi segmenti Ethernet consentendo in
tal modo di superare le limitazioni imposte dallo standard relativamente alla
massima estensione di un singolo segmento.
Figura 2.7
Come mostra la figura, il ripetitore opera a livello fisico della pila protocollare
OSI e ripete i segnali ricevuti da una porta a tutte le altre. I ripetitori multiporta
presenti nelle topologie a stella come 10/100/1000BaseT sono detti Hub.
57
Figura 2.8
Le loro funzioni di base, comunque, sono identiche a quelle definite dallo
standard IEEE 802.3 per i ripetitori e sono di seguito elencate.
-
Rigenerazione dell’ampiezza del segnale e rimozione del jitter di fase.
-
Immagazzinamento temporaneo delle frame per ritemporizzare i bit da
trasmettere. A tal fine il ripetitore decodifica (da Manchester) le frame
ricevute da una porta e le ricodifica (in Manchester) prima di ritrasmetterle a
tutte le altre porte.
-
Carrier-Sense cioè, come previsto dal protocollo di Ethernet CSMA/CD,
monitora il canale prima di trasmettere i segnali.
- Reintroduzione dei bit persi nel preambolo. Ogni frame, aderente sia allo
standard 802.3 che allo standard proprietario Ethernet, inizia con sette byte
di preambolo, ognuno costituito da una sequenza di ‘10101010’ bit, necessari
affinché il nodo ricevente si possa sincronizzare correttamente sullo stream
dei dati, seguiti dal byte start of frame, ‘10101011’, che indica al ricevitore
l’inizio della frame. Ma i chip odierni presenti nei dispositivi delle NIC
hanno bisogno di circa 30 bit di tempo per sincronizzarsi e di conseguenza
alcuni bit del preambolo saranno persi nell’attraversare un nodo. Per tale
ragione ogni ripetitore aderente allo standard 802.3 dovrà anche svolgere il
compito di rigenerare tali bit altrimenti il campo preambolo svanirebbe
dopo l’attraversamento del secondo ripetitore. Al contrario i ripetitori
aderenti allo standard proprietario Ethernet ignorano la parte persa e
58
iniziano a trasmettere dal primo bit utile quindi lo standard limita a due il
numero massimo di ripetitori che possono essere attraversati da una trama;
in tal modo si evita di compromettere i dati veri e propri della frame.
-
Estensione dei frammenti. Se durante una trasmissione di dati avviene una
collisione si genereranno frammenti di frame di lunghezza inferiore a 96 bit
(incluso il preambolo) che si propagheranno. Quando giungeranno all’hub,
esso avrà il compito di estendere tali frame con una particolare sequenza di
bit del tipo ‘1010..’, chiamati bit di jam, fino al raggiungimento di 96 bit.
L’estensione di questi ultimi permette a tutte le stazioni presenti sulla rete di
accorgersi dell’avvenuta collisione.
-
Propagazione delle collisioni. Se l’hub riceve una sequenza di jamming su
una porta non generata da lui ma da altri nodi della rete o altri hub a lui
collegati, la rigenera prima di ritrasmetterla su tutte le altre porte.
-
Collision Detection e generazione di jam bit. Quando un ripetitore si accorge
di una collisione su una porta (grazie alla funzione di collision detection
presente nel protocollo di accesso al mezzo CSMA/CD) trasmette un
rumore aggiuntivo, chiamato appunto sequenza di jam, per permettere a
tutte le stazioni presenti sulla rete di accorgersi dell’avvenuta collisione e
evitare in questo modo ulteriori trasmissioni da parte di questi che
porterebbero solo ad uno spreco in banda. Affinché la sequenza dei bit di
jam possa essere rilevata da tutti, la lunghezza di tali frame deve essere
scelta opportunamente. Lo standard 802.3 prevede per la sequenza di jam
una lunghezza di 32 bit (per Ethernet varia da 32 a 48 bit) quindi
aggiungendo i 64 bit di preambolo si arriva a far propagare sulla rete una
sequenza di 96 bit che sicuramente sarà rilevata da tutti.
-
Automatic Partitioning. Il ripetitore può monitorare il numero di collisioni
che osserva su una porta collegata ad un segmento. Se si raggiunge un alto
tasso di collisione, 30 collisioni successive, i ripetitori disattivano tale porta.
Quest’ultima sarà riattivata solo dopo che il ripetitore riceverà 500 bit liberi
59
da collisione.
-
Protezione dal jabber. In tal caso l’hub, come il MAU, disattiva una porta se
da questa riceve un jabber, cioè una frame di lunghezza superiore a 1518
byte.
-
Monitoraggio dello stato del transceiver 10BaseT collegato ad ogni porta. Su
tali interfacce, infatti, i transceiver inviano degli impulsi di test durante i
periodi di assenza di traffico per verificare l’integrità del link detti idle
pulse. Se su tali interfacce non arrivano ne idle pulse ne frame l’hub può
allora disabilitare la porta sospettando che il cavo non funzioni
correttamente.
I ripetitori moderni sono modulari e capaci di connettere segmenti cablati con
diversi mezzi di comunicazione (cavo coassiale, twisted pair e fibra ottica). I
ripetitori, infine, non sono in grado di instradare le frame ad una specifica porta
di uscita (come invece vedremo che ciò accade nei bridge e router) e di
conseguenza tutti i segmenti connessi all’hub costituiranno un unico dominio di
collisione come mostra la figura seguente.
Figura 2.9
Formando un unico dominio di collisione si hanno limiti definiti dallo standard
60
riguardo al numero massimo di nodi, alla distanza massima tra due host e al
numero di livelli consentiti.
Inoltre i ripetitori, essendo apparati dello strato fisico, non possono rilevare
errori come campo FCS non valido o dimensioni errate di una frame.
2.10.1 Problemi causati dall’impiego di hub
In questo paragrafo verranno brevemente enunciati alcuni dei problemi che si
potrebbero presentare nell’adoperare hub come mezzi di interconnessione tra
segmenti di rete.
Localizzazione del dominio di collisione
Come abbiamo detto, una volta rilevata una collisione, l’hub inizia a trasmettere
bit di jam a tutte le porte. Dal momento che, grazie a tale dispositivo, i domini
di collisione dei vari segmenti ad esso connesso vengono unificati, una
collisione che avviene in un segmento viene percepita da tutti gli altri segmenti
come una collisione remota.
Se effettuiamo delle misurazioni simultanee in tutti i segmenti collegati ad un
hub e rileviamo una correlazione tra una remota collisione in un segmento e
una locale collisione in un altro segmento allora la fonte della remota collisione
è stata facilmente trovata. Questa strategia appena enunciata però può essere
praticata solo nei cablaggi 10Base2 e 10Base5, che adottano una topologia a bus,
mentre nei cablaggi 10/100/1000BaseT, che adottano una topologia a stella per
cui ogni nodo è connesso con un proprio segmento all’hub, è necessario
impiegare una diversa strategia. Si potrebbe pensare di correlare il carico di rete
dovuto dai nodi più attivi con il tasso di collisione e se quest ultimo sembra
essere correlato con l’inoltro delle frame da parte di uno di questi nodi allora
61
questa stazione potrebbe essere la causa delle collisioni.
Phantom Addresses (Indirizzi Fantasma)
Se si utilizza un analizzatore di protocollo, nel tentativo di localizzare il
dominio di collisione, esso riporterà frame Ethernet con degli strani indirizzi di
sorgente e destinazione (Phantom Address) del tipo 5555 5555. Pacchetti difettosi
spesso contengono questi tipi di indirizzi che a prima vista sembrano indicare
misteriosi errori di trasmissione ma se analizziamo la corrispondente
rappresentazione binaria di
5555 5555
otteniamo
1010 1010 1010 1010 1010 1010 1010 1010
tali 32 bit non rappresentano altro che la sequenza di jam inviata dal ripetitore a
tutti i segmenti connessi una volta rivelata la collisione.
Si osservi che tali 32 bit preceduti dai 64 bit di preambolo danno luogo ai 96 bit
al segnale di jam complessivo.
2.10.2 Problemi dei ripetitori e hub: Sintomi e
Cause
Sintomi tipici che segnalano problemi relativi ad hub sono per esempio degrado
delle prestazioni della rete, perdite intermittenti di connessioni, alti tassi di
collisioni e alcune cause sono descritte qui di seguito.
62
Perdita di pacchetti dovuta a Inter Frame Gap troppo
breve
Come mostra la figura, due frame consecutive vengono sempre distanziate di
un intervallo di tempo minimo di 9.6µs detto Inter Frame Gap (IFG).
Figura 2.10
Se una scheda di interfaccia di rete non mantiene tale spaziatura tra frame
successive, i ripetitori più lenti non saranno in grado di inoltrarle velocemente
ne potranno memorizzarle provocando così la perdita delle frame o una
ritrasmissione non corretta; in alcuni casi le frame mutano in jabber. Solo i
protocolli di livello più alto si accorgeranno di tali perdite e richiederanno la
ritrasmissione e di conseguenza le prestazioni di alcune applicazioni ne
risentiranno. Si potrebbe impiegare un analizzatore di protocollo per
monitorare l’IFG e identificare così, tramite l’analisi dell’indirizzo di sorgente,
la NIC difettosa.
Anche i frammenti di pacchetti possono causare una riduzione dell’IFG poiché,
come abbiamo visto, ogni hub estende tali frammenti fino al raggiungimento di
96 bit (incluso il preambolo). Se un frammento inferiore a 64 bit è ricevuto
dall’hub esso aggiunge i 32 bit di jam e ciò comporta una riduzione del gap tra
quest ultimo e la frame seguente di 32 bit di tempo (32µs). Questo può far
divenire il gap molto breve.
I moderni hub comunque utilizzando dei buffer sono in grado di mantenere un
63
IFG costante.
Queste cause comporteranno delle perdite intermittenti di connessione che
spesso sono riconoscibili solo a livello di applicazione. Applicazioni di tipo filetransfer, per esempio, risentono fortemente di ciò e possono essere
significativamente più lente tra due stazioni che comunicano attraverso un hub
piuttosto che tra due stazioni localizzate nello stesso segmento. Se tutti i
pacchetti TCP prima del ripetitore presentano un corretto sequence number ma
dopo l’hub si perdono i numeri di sequenza allora la causa risiede nell’hub. Le
prestazioni del file-transfer sono degradate ovviamente poiché i pacchetti persi
devono essere ritrasmessi.
Differenti riferimenti di potenziale in reti 10Base2 e
10Base5
Alti tassi di collisione o addirittura un completo breakdown del funzionamento
della rete spesso sono la conseguenza di problemi di differenti riferimenti di
potenziale. Come abbiamo già illustrato in precedenza, in segmenti 10Base2 o
10Base5 è possibile avere diversi agganci al potenziale di terra in diversi punti
della rete. Può accadere per molteplici motivi, quali la presenza di un
dispersore in prossimità di un aggancio, che il potenziale di riferimento sia
differente e ciò inevitabilmente genererà una corrente DC che circolerà nel cavo
del segmento provocando interferenze e quindi collisioni e problemi di
intermittenza di connessione.
Tramite un cable tester si può monitorare il riferimento di potenziale nella rete e
rilevare la corrente DC. Comunque è importante che per tali reti il riferimento
di potenziale sia solo in un punto.
64
Problemi dovuti ad un eccessivo numero di ripetitori nel
path di trasmissione
Ogni hub presente nella rete introduce un ritardo sul tempo di trasmissione di
una frame.
La tabella riporta i limiti imposti dallo standard relativamente al ritardo di
trasmissione introdotto sulle porte di un ripetitore Ethernet operante a
10Mbit/s che, ovviamente, non devono essere superati.
In conseguenza di ciò, se una frame deve attraversare non solo lunghe distanze
ma anche un gran numero di ripetitori, si può eccedere il massimo ritardo di
trasmissione (25.6μs). Le collisioni allora si presentano nella forma di late
collision provocando perdita di pacchetti di cui ci si accorgerà solo a livello
superiore il che causa una riduzione delle performance della rete e perdite
intermittenti di connessione. Per tali motivi è necessario limitare il numero di
ripetitori a quattro o sostituire al posto degli hub bridge oppure cambiare la
configurazione di rete.
65
Errori nell’installazione, configurazione e hardware
Frequentemente i problemi con hub sono dovuti ad una sua installazione o
configurazione non corretta, come:
-
porte configurate in modo non corretto (per esempio alcune porte vengono
configurate in modo da operare a 10Mbit/s invece di 100Mbit/s)
-
perdite di connessione di un nodo collegato ad un hub (in questo caso ciò
potrebbe essere dovuto a causa di connettori non agganciati bene o a seguito
di un automatic partitioning da parte dell’hub)
-
interruzione del funzionamento dell’hub dopo poco tempo dalla sua
installazione. Ciò potrebbe essere dovuto da molteplici cause come la
temperatura dell’ambiente in cui tale apparato è stato inserito; infatti tra le
specifiche di un hub sono riportati anche il range di valori per la
temperatura
dell’ambiente
circostante
che
assicurano
un
corretto
funzionamento dell’hub. Se tali valori sono stati rispettati è utile andare a
verificare che le aperture che consentono la ventilazione e il riciclo dell’aria
all’interno dell’hub non siano ostruite. Infine la causa è da ricercarsi in una
perdita di potenza, potenza fluttuante o in una mancata potenza di
alimentazione.
Anche l’hardware può avere problemi ma tramite un:
-
monitoraggio sui connettori
-
monitoraggio sulla potenza di alimentazione
-
attivazione della funzione di self-test dell’hub
possono essere facilmente localizzati.
66
2.10.3 Problemi con ripetitori ottici in reti
Ethernet
Tra le varie tecnologie Ethernet è stata anche implementata la 10BaseF, operante
a 10Mbit/s, che introduce e regolamenta l’utilizzo della fibra ottica come mezzo
trasmissivo per le LAN. In esso, a differenza della 10/100/1000BaseT,
l’elemento centrale non è più un hub bensì uno splitter ottico.
Esistono vari tipi di cablaggi in fibra per le reti LAN e tra questi lo standard
10BaseFP che utilizza stelle passive e lo standard 10BaseFB in cui sono presenti
delle stelle attive.
Il cablaggio 10BaseFP (FP: Fiber Passive) permette l’utilizzo della topologia a
stella come mostra la seguente figura.
Figura 2.11
Con la fibra ottica si possono realizzare solo collegamenti punto-punto quindi
per poter connettere più di due stazioni si è fatto uso di stelle passive. Una
stella passiva è basata sul concetto dello splitter ottico, ovvero un ripartitore di
segnale luminoso in cui il segnale che giunge da una porta non viene rigenerato
nelle altre porte ma suddiviso e ciò provoca un’ovvia perdita di gran parte del
67
segnale luminoso nella stella stessa. In tale topologia gli unici elementi attivi
sono i transceiver ottici.
Il cablaggio 10BaseFB (FB: Fiber Backbone) è mostrato in figura.
Figura 2.12
In tal caso la fibra ottica è utilizzata in dorsali che collegano due ripetitori ottici
(active optical star) che sono in grado di svolgere tutte le funzioni definite per i
ripetitori IEEE 802.3 come:
-
rigenerazione del segnale
-
estensione dei frammenti
-
collision detection
-
generazione di jam bit.
Qui, a differenza del cablaggio 10BaseFP, i transceiver ottici sono integrati nei
ripetitori.
Se la potenza ottica emessa da un ripetitore è di scarsa intensità si possono
avere problemi di attenuazione che portano ad una diminuzione delle
prestazioni della rete o all’occorrenza di numerosi short packet (runt). Bisogna
allora monitorare e se necessario modificare il livello di potenza emesso da un
ripetitore.
68
2.10.4 Problemi con ripetitori ottici non
standard
Spesso in luogo dei ripetitori ottici che implementano tutte le funzioni definite
dallo standard IEEE 802.3 si utilizzano semplici convertitori elettro-ottici.
Quando il numero di questi ultimi è elevato si possono presentare dei problemi
i cui sintomi sono per esempio runt, IFG insufficiente o rumore, generato
principalmente
perché
spesso
tali
convertitori
non
provvedono
all’amplificazione dei segnali ne all’eliminazione del jitter.
2.11 Bridge
I Bridge sono dispositivi di livello 2 (MAC) della pila OSI, identificati da un
indirizzo MAC di 48 bit, che interconnettono segmenti LAN.
Figura 2.13
In realtà ciascuna porta del bridge è identificata da un indirizzo MAC, le porte
poi sono sequenzialmente numerate e l’indirizzo del bridge corrisponde a
quello della porta 1. Un bridge opera in modalità “store and forward”, cioè
69
quando riceve una frame Ethernet la immagazzina prima di inoltrarla; ciò
significa che i vari bit che viaggiano serialmente sul link fisico vengono poi per
essere parallelizzati nel dispositivo fisico. Quindi a differenza degli hub che
inoltrano semplicemente i bit del segnale, i bridge eseguono una conversione
seriale-parallelo (all’arrivo della frame) e parallelo-seriale (alla ritrasmissione
della frame). Queste operazioni
introducono naturalmente un
ritardo
aggiuntivo detto di trasmissione (si ricordi che il ritardo di propagazione è
quello legato al trasferimento fisico dell’informazione sul link, che richiede un
certo tempo finito). Inoltre i bridge hanno una capacità di filtraggio, consistente
nell’inoltrare la frame, se indirizzata ad una LAN diversa da quella di
appartenenza della stazione trasmittente, solo all’interfaccia che la porterà a
destinazione.
Figura 2.14
Il bridge per operare in tale modalità si serve dell’indirizzo LAN presente nella
frame e le informazioni contenute in tabelle di instradamento
settate
manualmente da un operatore o costruite con un processo di apprendimento
proprio dei bridge, se la topologia della rete è ad albero, in cui i bridge ogni
volta che ricevono una frame scrivono l’indirizzo LAN nella tabella solo se non
è ancora presente, o con un algoritmo detto “spanning tree”, se la topologia
70
della rete è a maglia. In tal caso una topologia di una rete a maglia viene
riconfigurata in una topologia ad albero, per evitare percorsi chiusi ,”loop”, la
presenza di percorsi alternativi e la conseguente duplicazione dei pacchetti.
Quindi a differenza dei ripetitori che operano a livello fisico ritrasmettendo
semplicemente i bit di una frame a tutte le porte di uscita, i bridge, scartano i
pacchetti difettosi eseguendo il controllo del campo FCS ed esercitando la
suddetta funzionalità di “filtering”, mantengono i domini di collisione isolati,
consentendo pertanto di:
-
evitare diffusione di traffico inutile in rete
-
superare i limiti di una particolare topologia di rete come il massimo
numero di nodi, il ritardo di trasmissione, o i limiti sulla distanza.
Si noti che i bridge garantiscono l’inoltro dei pacchetti nell’esatto ordine di
arrivo e talvolta può essere installato su di essi un protocollo non standard di
load-balancing che consente di distribuire il traffico di rete su diversi percorsi
trasmissivi in parallelo. Infine bridge di versioni più recenti sono plug and play,
cioè non richiedono interventi del servizio di assistenza della rete o dell’utente.
In altre parole quando un amministratore installa un bridge non deve fare altro
che collegare i segmenti LAN all’interfaccia del bridge, senza configurare le
tabelle di instradamento nè all’inserimento né alla rimozione di un host da un
segmento di rete.
2.11.1 Funzioni dei bridge
Bridge filters
I bridge possono essere configurati tramite operazioni manuali in modo che
operino come filtri; i criteri su cui viene realizzato il filtraggio sono vari e
71
possono essere: indirizzo sorgente e di destinazione, il campo tipo presente
nella frame (indicante il protocollo di livello superiore a cui sono destinati i
dati). I bridge filters possono essere pertanto strumenti in grado di limitare il
traffico di rete, ma il loro impiego è limitato in quanto essi sono dispositivi
statici e per alcuni protocolli degli strati sovrastanti, come FTP o Telnet, che
cambiano dinamicamente il numero di porta non fornirebbero un corretto
filtraggio.
Bridge di commutazione MAC
L’ultima generazione di bridge presenta le funzioni tipiche dei bridge
combinate con la funzione di commutazione tipica del livello MAC. Tali bridge
sono
capaci
di
prendere
decisioni
di
inoltro
e
di
instradare
contemporaneamente diversi pacchetti, cioè operano in modo tale da instradare
ciascuna frame direttamente al suo segmento di destinazione senza bloccare le
altre stazioni sulla stessa rete. Tali apparati garantiscono un incremento
considerevole della larghezza di banda.
Bridge remoti
Figura 2.15
Nel progetto OSI i bridge sono stati concepiti per interconnettere LAN su base
72
locale, mentre l'interconnessione su base geografica è demandata ai router,
tuttavia, sono stati modificati per operare anche su scala geografica e sono nati i
cosiddetti bridge remoti questi ultimi sono in grado di connettersi a locazioni
remote mediante link WAN. I protocolli usati sui link WAN sono il PPP (Pointto-Point Protocol) o l’HDLC (High-Level Data Link Control Protocol). Si ricordi
che un bridge può mettere in comunicazione reti LAN eterogenee (Ethernet,
Token Ring, FDDI, ATM) operando una conversione delle frame.
Figura 2.16
2.11.2 Diagnostica dei problemi dei bridge
Per localizzare in una rete problemi connessi ai bridge è necessario
implementare un attento processo di analisi dei segmenti LAN al fine di
individuare una correlazione tra i sintomi (basse prestazioni di rete in alcuni
segmenti, perdita permanente o intermittente di connessioni verso particolari
stazioni, fallimento di servizi) e la causa stessa.
In tale fase si utilizzano pertanto sistemi di monitoraggio basati sull’impiego di
sonde capaci di effettuare le misurazioni nei diversi link, procedendo così via
73
via ad una circoscrizione del problema a componenti specifiche. In particolare
se i sintomi possono essere relazionati a specifiche connessioni si può iniziare
con il controllare tutti i bridge allocati sul corrispondente percorso trasmissivo.
Il primo passo consiste, pertanto, nel preparare una lista di tutte le stazioni,
connessioni, servizi e protocolli affetti dal problema e confrontare la misura dei
parametri correnti prestazionali nei diversi nodi di rete (throughput, uso della
capacità del CPU e del buffer di memorizzazione) con le statistiche effettuate
nelle normali condizioni operative. Ad esempio per misurare i tempi di risposta
delle connessioni attraverso i bridge in analisi si trasmettono dei loop-back
packets (Ethernet configuration test packets, IP pings). Inoltre misure sui tempi
di risposta a lungo termine (utili soprattutto nel caso di problemi intermittenti)
possono essere effettuate utilizzando degli agent distribuiti nella rete. Infine è
buona norma verificare se sono stati effettuati variazioni nella topologia della
rete poco prima dell’insorgere degli errori.
2.11.3 Sintomi e cause dei problemi nei
bridge
Problemi di throughput
La capacità di troughput dei bridge è generalmente misurata in frame a
secondo, dove il valore nominale si riferisce alla lunghezza più breve della
frame consentita dalla topologia di rete in questione. E’ pertanto necessario il
confronto tra il throughput corrente e quello nominale per limitare i problemi
nella rete, tale pratica è comunque realmente indispensabile solo nei bridge di
vecchio modello, in quanto quelli più recenti hanno capacità così elevate da
rendere sporadico il verificarsi di colli di bottiglia.
74
Tali situazioni d’allarme comportano il riempimento dei buffer e la conseguente
perdita di frame integre che il bridge non riesce ad inoltrare a destinazione.
Un’ulteriore causa di perdita dei pacchetti è dovuta allo scarto delle frame
memorizzate nel buffer per un tempo superiore ad un limite stabilito dai bridge
stessi all’inizio del funzionamento della rete (generalmente 4 s). Si noti che un
limite di latenza troppo breve potrebbe causare gravi problemi nelle reti con
traffico pesante.
Problemi connessi ai Bridge Filter
L’errata configurazione dei bridge con funzionalità di filtraggio, può provocare
il blocco di interi flussi dati, ad esempio in reti che presentano più percorsi
verso una stessa destinazione in cui è quindi possibile definire rotte di backup,
queste ultime possono rimanere inutilizzate.
In generale, e in misura diversa a seconda dell’architettura di rete, i bridge
mostrano una significativa riduzione delle prestazioni quando un certo numero
di filtri è attivo sulla rete. Pertanto, è consigliabile consultare i manuali di
lavoro forniti dai produttori che stabiliscono in che modo i filtri possono
influenzare l’attività dei bridge e quindi quale è il numero massimo di Bridge
Filter ammissibile su una rete, cioè tale da non compromettere le prestazioni
della rete stessa.
Errori dovuti a pacchetti fuori sequenze
Come precedentemente detto, i bridge inoltrano i pacchetti nello stesso ordine
nel quale sono ricevuti, perciò se utilizza un protocollo di distribuzione del
carico (Load balancing), per il quale i pacchetti di un singolo processo di
comunicazione sono distribuiti sui vari link , la loro sequenza può variare
75
rispetto all’ordine in cui erano stati inviati e conseguentemente i bridge li
inoltreranno a destinazione nell’ordine sbagliato. Pertanto solo quei protocolli
(TCP) che tollerano cambiamenti nell’ordine di sequenza possono comunicare
con successo attraverso i bridge operanti in tale modalità. Per tali ragioni le
applicazioni UDP, lavorano correttamente solo all’interno di un segmento
locale ma presentano problemi quando si lavora attraverso bridge e router
infatti UDP richiede che i pacchetti siano nel giusto ordine sequenziale. E’
chiaro che in situazioni d’allarme si può decidere di disattivare la funzione di
distribuzione del carico.
Problemi legati alla tabella degli indirizzi
I bridge stabiliscono un tempo massimo di registrazione delle informazioni
contenute nelle tabelle di instradamento. Se si opera in modalità dinamica,
scaduto tale tempo le entry sono eliminate con la conseguente interruzione
delle relative comunicazioni.
Spesso i bridge operano in modalità protetta cioè hanno una tabella degli
indirizzi statica che viene settata manualmente, in tal caso gli indirizzi delle
nuove stazioni non sono inserite automaticamente nella tabella che sono perciò
incapaci di comunicare con i bridge. E’ chiaro che ciò causa interruzioni nelle
comunicazioni con gravi ripercussioni su tutta la rete. L’unica soluzione a tali
problemi è ancora una volta effettuare una costante politica di monitoraggio
della tabella degli indirizzi.
76
Settaggio errato della modalità operativa e problemi di
configurazione
Spesso le porte dei bridge che operano in accordo alla versione Ethernet v2.0
invece che secondo il cablaggio IEEE 802.3, hanno problemi con schede di
interfaccia di rete (NIC) meno recenti che non hanno la capacità di cambiare
automaticamente la loro modalità operativa.
Perdite di una o più connessioni al bridge sono dovuti ad una errata
configurazione delle porte del dispositivo (predisposto ad esempio a lavorare in
una rete Ethernet a 100 Mbit/s è installato invece in una a 10 Mbit/s), errori di
connessioni (connettori allentati) e di installazione dei componenti.
Problemi dovuti a differenti topologie di rete
Le differenti velocità di trasmissione e i diversi meccanismi di accesso che
caratterizzano differenti topologie di rete causano problemi nei bridge che le
interconnettono. Per esempio se una lunga sequenza di frame viene trasmessa
da una Token ring a 16 Mbit/s ad una rete LAN Ethernet a 10 Mbit/s il bridge
non può inoltrare il traffico alla stessa velocità a cui gli arriva e dovrà
memorizzare i pacchetti in un buffer che potrebbe andare in overflow. Un altro
problema è legato alla diversa lunghezza massima del campo dati (1518 byte
per 802.3, 4478 byte per FDDI, 17749 per Token ring); infatti poiché non è
possibile violare tali dimensioni massime e poiché un bridge non implementa
l’operazione di frammentazione tipica del livello 3 quando esso riceve una
frame di dimensione superiore alla massima prevista per la LAN di
destinazione la scarta. Pertanto, la lunghezza massima dei pacchetti, che
possono essere trasmessi da un bridge e che può essere settata manualmente,
deve essere fissata ad un valore abbastanza elevato per limitare ulteriori perdite
77
di pacchetti. Si consideri ora l’interconnessione tra una Token-ring e una LAN
Ethernet , in tal caso un'altra fonte d’errore è dovuta all’assenza in Ethernet del
campo Frame status in cui ci sono due bit (A e C) che forniscono un riscontro
automatico per ogni frame. In questo caso, quando una frame arriva
all’interfaccia della stazione di destinazione, questa attiva il bit A mentre la
frame passa, e quello C se essa è anche copiata nel buffer (una stazione può
fallire nel copiare una frame per varie ragioni quali la mancanza di spazio di
memoria). In tal modo quando il mittente preleva il frame dall’anello capirà se
la trasmissione è andata a buon fine. Per superare la mancanza di tale
funzionalità in una rete Ethernet un bridge può essere configurato per default
per settare i bit A e C a 1 (“pacchetto ricevuto” e “frame copiato”), ciò causerà
notevoli problemi perché il trasmettitore crederà che il suo pacchetto sia stato
processato con successo anche quando in realtà la stazione ricevente non era
attiva e non ha ricevuto la frame in questione, o quando lo era ma la frame non
è stata accettata. Dall’esempio fatto, si comprende che in questi casi il bridge
diventa una vera e propria interfaccia tra 2 LAN diverse e di conseguenza
quanto maggiori saranno le differenze tra le 2 parti, tanto maggiore sarà il
lavoro del bridge e il tempo per far in modo che le cose procedano
correttamente.
Problemi Hardware
E’ chiaro che ci possono essere problemi dovuti all’hardware del dispositivo, in
tal caso per localizzarli bisogna controllare la potenza fornita e attivare le
modalità di automonitoraggio dei bridge.
78
Problemi con Bridge remoti
Come è stato precedentemente detto, spesso LAN a 10 o 100 Mbit/s sono
distribuite geograficamente tra loro e connesse tramite bridge remoti a link
WAN la cui velocità di trasmissione massima è pari a 2,048 Mbit/s. In questo
caso è ovvio che solo una piccola porzione del traffico totale generato dalle
LAN riesce a viaggiare su questi collegamenti, di più bassa qualità, che causano
perdita di pacchetti, elevati BER e scadenza dei timeout. Questo problema può
essere risolto facendo compressione dei dati e naturalmente con l’introduzione
di collegamenti WAN aventi una più ampia larghezza di banda. Anche
frequenti controlli sullo stato di utilizzo della capacità dei link mediante un
analizzatore di protocollo sono utili per evitare seri problemi di comunicazione.
2.12 I router e lo strato di rete
Lo strato di rete si occupa di trasportare pacchetti da una sorgente ad una
destinazione, e di determinare pertanto, in base alla topologia della rete stessa,
il tragitto appropriato che devono seguire i pacchetti. Per raggiungere la
destinazione può essere necessario attraversare lungo il percorso diversi router
intermedi. I router sono componenti inter-networking che connettono segmenti
di rete. Un router, in inglese letteramente instradatore, è un dispositivo di livello
3 del modello OSI che si occupa di instradare pacchetti tra reti diverse ed
eterogenee.
79
figura 2.17
Esso è costituito da:
- porte di ingresso
- porte di uscita
- dispositivo di commutazione
- processore di instradamento
Alcune architetture dello strato di rete richiedono che i router lungo il percorso
si scambino un handshake in modo da impostare lo stato prima che i dati
inizino a fluire; tale processo definito impostazione della chiamata, è invece
assente in Internet.
I router così come i bridge sono commutatori store and forward, essi rigenerano
solo i pacchetti corretti, modificando non il payload ma l’intestazione
(es.decremento del campo Time to Live del pacchetto IP), e scartano i pacchetti
danneggiati che dovranno essere ritrasmessi.
Inoltre, anche i router sono in grado di mantenere domini di collisione isolati,
ma differentemente dai bridge, non sono plug and play, il loro indirizzo e
quello degli host ad essi collegati deve essere configurato, e utilizzano indirizzi
dello strato di rete.
L’indirizzamento di rete (spesso gerarchico) sebbene provochi un aumento dei
tempi di elaborazione dei pacchetti, dovendo analizzarne i campi fino al livello
80
3 della pila ISO-OSI, evita il formarsi di percorsi ciclici attraverso i router.
Infatti, i pacchetti non sono costretti a fluire attraverso lo spanning tree anche
quando ci sono percorsi più diretti tra sorgente e destinazione.
Il router resiste meglio alle tempeste broadcast, infatti se un host impazzisce e
trasmette un flusso senza fine di frame broadcast, i bridge li inoltreranno
causando il collasso della intera rete, tali indirizzi di livello MAC non
passeranno viceversa attraverso i router. Pertanto, nel primo caso il traffico
broadcast viene ricevuto da tutte le stazioni sulla rete, nel secondo caso sarà
ricevuto solo dagli host che si trovano sullo stesso segmento di rete.
Pertanto di interesse per il troubleshooting dei router sono solo i protocolli di
livello 3, perché è a questo livello che avviene il trasporto.
La maggior parte dei router oggigiorno sono Multi-protocol, capaci cioè di
gestire contemporaneamente diversi stack protocollari. Esistono infatti diverse
architetture di rete che differiscono per i servizi offerti dai vari livelli, per le
modalità di indirizzamento, per le dimensioni massime dei pacchetti, e così via.
Pertanto per connettere tra loro reti eterogenee è necessario superare tali
difformità ed utilizzare quindi attrezzature particolari come i già menzionati
router Multi-protocol. Sistemi moderni sono inoltre in grado di implementare
contemporaneamente sia il routing che il bridging.
I router possono essere normali computer che fanno girare un software
apposito o - sempre più spesso - apparati specializzati, dedicati a questo solo
scopo. I router di fascia più alta sono basati su architetture hardware
specializzate per ottenere prestazioni wire speed, letteralmente alla velocità
della linea. Questo significa che un router wire speed può inoltrare pacchetti
alla massima velocità delle linee a cui è collegato, in tal caso sono i link stessi
che provocano colli di bottiglia durante il trasferimento dei dati tra canali
trasmessivi di diverse capacità, in tal caso sono necessari buffer più ampi in
grado di non rendere vano il grosso sforzo di elaborazione dei router.
Per garantire la massima affidabilità e lo sfruttamento ottimale dei
81
collegamenti in caso di reti complesse costituite da molte sottoreti diverse e
variamente interconnesse, i router si scambiano periodicamente fra loro
informazioni su come raggiungere le varie reti che collegano l'un l'altro.
Esistono vari modi per classificare gli algoritmi di instradamento, un primo
modo è funzione del fatto che essi siano globali o decentralizzati. Un algoritmo
di instradamento globale calcola il percorso di minor costo fra una sorgente ed
una destinazione usufruendo di conoscenze complete sulla rete, sulla
connettività e sui costi dei link. Si noti che il costo di un link può riflettere varie
metriche (il livello di congestione, la distanza fisica coperta dal link stesso).
Viceversa, in un algoritmo di instradamento decentralizzato ciascun nodo ha
inizialmente solo la conoscenza del costo dei link ad esso collegati e solo
attraverso un processo iterativo di calcolo e scambio di informazioni con i nodi
ad esso vicini calcola gradualmente il percorso di minor costo verso una
destinazione o un gruppo di destinazioni. Un secondo modo per classificare gli
algoritmi di instradamento è in base al fatto che siano statici o dinamici. I primi
sono utilizzati per rotte che cambiano molto lentamente nel tempo, spesso
conseguentemente ad interventi umani, e che hanno caratteristiche di
trasmissione fissate (larghezza di banda, bit-error-rate), tali algoritmi sono usati
in particolare, quando si vuole implementare una stringente politica di
sicurezza.
Gli
algoritmi
dinamici,
invece,
modificano
il
percorso
di
instradamento non appena varia il traffico in rete o la topologia, sono
largamente diffusi nelle reti locali. Gli algoritmi dinamici maggiormente
utilizzati oggigiorno nei protocolli di routing sono il decentralizzato distance
vector (Bellmann-Ford) e lo shortest path first algorithm basato sullo stato globale
dei link. L’algoritmo distance vector è distribuito perché l’instradamento ottimo
non viene calcolato da un solo nodo, ma c’è una collaborazione fra tutti i nodi
del sistema. Ciascun nodo infatti ha solo informazioni dei costi dei link verso
uno o più vicini ai quali è direttamente collegato e riceve da questi informazioni
sui rispettivi nodi ad essi adiacenti, dopodiché eseguito un calcolo ridistribuisce
82
i risultati ottenuti solo ai nodi vicini. Operando in tal modo, ciascun nodo
costruisce una tabella indicizzata di instradamento contenente per tutte le
destinazioni una registrazione, suddivisa in 2 parti: la linea di uscita prescelta
per quella destinazione e il rispettivo costo. La tabella così ottenuta viene poi
spedita periodicamente, ogni T secondi.
In un algoritmo basato sullo stato del link, la topologia della rete e tutti i costi
dei link sono noti a tutti i nodi, ciò si realizza mediante la trasmissione da parte
di ciascun nodo dei costi dei link ad esso collegati a tutti i router della rete, che
calcoleranno indipendentemente la propria tabella di instradamento.
Si noti che in tale algoritmo la dimensione dei pacchetti inviati per aggiornare le
tabelle di routing non dipende dalla dimensione della rete, in quanto ciascun
nodo trasmette a tutti gli altri solo le informazioni riguardanti i nodi adiacenti.
Pertanto un router potrà al massimo trasmettere un costo incoerente per uno
dei link ad esso adiacente e non potrà mai notificare percorsi sbagliati verso
tutte le destinazioni.
2.12.1 Instradamento gerarchico
All’aumentare del numero dei router in una rete l’overhead dei calcoli, della
memoria necessaria per immagazzinare le informazioni nonché del numero di
trasmissioni delle tabelle di instradamento può diventare proibitivo. Questo
problema può essere risolto mediante l’aggregazione di router in regioni o
Autonomus System, all’interno delle quali è utilizzato lo stesso algoritmo di
instradamento detto pertanto intra-system.
Naturalmente è necessario collegare gli AS tra loro, ci saranno pertanto dei
router gateway preposti alla comunicazione inter-sistema che utilizzeranno
protocolli di instradamento inter-sistema come il BGP(Border Gateway Protocol). I
protocolli maggiormente usati in Internet per la comunicazione intra-system il
RIP(Routine Internet Protocol) e OSPF (Open Shortest Path First) e l’IGRP(Interior-
83
Gateway Routing Protocol).
2.12.2 Diagnostica dei problemi dei router
Il troubleshooting dei problemi dei router inizia con l’analisi dei protocolli di
instradamento utilizzati nei segmenti di rete in esame, a meno che gli errori non
siano causati da problemi hardware o di installazione. Pertanto, il primo passo
per avere una panoramica dello stato operativo della rete è utilizzare un
analizzatore di protocollo per ottenere le statistiche delle prestazioni dei
protocolli stessi. Ad esempio in una rete IP, questo potrebbe includere
statistiche quali porzione del traffico IP rispetto al carico totale della rete,
Pacchetti di routing, broadcast IP, messaggi ICMP.
Inoltre potrebbe essere utile analizzare anche le statistiche operative di tutti i
router attivi. Diversi comandi possono essere impiegati per recuperare dati
quali:
- uso della capacità di memorizzazione
- numero di pacchetti trasmessi e ricevuti per protocollo
- timeouts
- frammentazioni
- numero di connessioni
Se i problemi riscontrati possono essere relazionati ad una particolare
connessione si può iniziare con il controllare tutti i router presenti su quel path.
In particolare per ciascun router sospetto è poi necessario controllare che siano
corretti:
-
gli indirizzi presenti nelle tabelle di instradamento
-
le rotte scelte per raggiungere la rete di destinazione
-
i valori configurati per i vari timer
-
la configurazione del default gateway
-
le porte e le connessioni verso link WAN
84
2.12.3 Sintomi e le cause connesse ai problemi
di routing
Problemi Hardware e software
L’insorgere di situazioni problematiche negli instradatori di livello tre del
modello ISO-OSI può essere causato, come menzionato precedentemente, da
problemi di natura hardware o software. Nel primo caso è consigliabile
controllare i connettori, i livelli di potenza, e attivare funzioni di
automonitoraggio nei router stessi, nel secondo caso per individuare tali
problemi è necessario monitorare l’attività di routing e analizzare il contenuto
dei protocolli di instradamento con il supporto di analizzatori di protocollo.
Problemi di throughput
La tendenza sempre più spiccata verso reti ad alta velocità, rende inevitabile il
formarsi di ingorghi durante i picchi di traffico, nonostante allo stato dell’arte le
attuali
prestazioni
dei
router
siano
molto
elevate.
I
dispositivi
di
interconnessione hanno infatti capacità limitate di gestione del traffico, questo
vuol dire che quando viene inondato da una mole di traffico che è maggiore
della sua capacità di gestione allora andrà in sovraccarico e comincerà a perdere
pacchetti. In particolare se i produttori forniscono dettagliate caratteristiche
operative dei router basati su test standardizzati, questi dati possono essere
confrontati con i picchi di traffico che si sono verificati nella rete e attraverso
questi confronti si può così stimare se è lecito che tali picchi attraverso il router
causino l’insorgere di problemi di throughput. Inoltre il superamento della
85
capacità dei buffer nei router dovuto a traffico intenso lungo il percorso, può
causare rallentamenti nella rete ed elevati tempi di risposta, pertanto l’analisi
delle statistiche operative (numero di porte utilizzate, uso della capacità di
memoria) può essere d’aiuto per rilevare tali problemi. Ad esempio la misura
dei tempi di risposta di un router, attraverso pacchetti sonda (ping), può
identificare il dispositivo stesso come causa della riduzione delle prestazioni
della rete. In tal caso è necessario riconfigurare i dispositivi di rete riducendone
il carico.
Problemi connessi alla tabella degli indirizzi
Molti problemi nei router sono connessi a tabelle degli indirizzi affette da errori
o non aggiornate, a seguito di cambiamenti nella configurazione della rete.
Spesso rilevare questi problemi può richiedere ore o addirittura giorni, ovvero
il tempo necessario affinché il servizio affetto dal problema sia utilizzato. Infatti
se i cambiamenti che avvengono nella rete non sono documentati, come spesso
accade, rilevare una correlazione tra la comparsa di un disservizio (problemi in
un database, un mancato accesso ad Internet) e una alterazione nella
configurazione nella rete può essere estremamente problematico e oneroso in
termini temporali.
Problemi connessi alla mancanza di un Default Gateway
Quando sono possibili dirette connessioni solo tra sottoreti direttamente
collegate ai router, mentre quelle che avvengono attraverso router più distanti
necessitano dell’instradamento dei pacchetti da parte di un Default Gateway, la
sua mancanza o l’errata configurazione dell’indirizzo di default sul router
interessato alla trasmissione, può provocare il fallimento di tali connessioni. Si
86
ricordi, infatti che un pacchetto non destinato ad una delle reti esplicitamente
elencate nella tabella di instradamento (facente parte dell’authonomus System)
è generalmente inviato su un’interfaccia di rete di default.
Configurazioni errate dei Timer
Una delle principali cause dei ritardi nella distribuzione delle informazioni di
routing è un’errata configurazione sui router dei timer previsti nei protocolli di
instradamento. Tale problema diviene particolarmente significativo quando si
utilizzano in una stessa rete, router di diversi produttori, in tal caso per evitare
l’insorgere di situazioni d’allarme è necessario attuare un attenta politica di
controllo per poter intervenire in caso di necessità.
Errori di configurazione e installazione
Anche nei router, così come nei bridge e negli hub, gravi problemi possono
essere causati da errori di configurazione da parte degli operatori (porte di
accesso non attive, modalità operative errate) oppure errori di connessione (cavi
o connettori con perdite). Ad esempio una errata configurazione di router, con
funzioni di filtraggio degli ingressi può causare il blocco di intere rotte di
backup,e di connessioni di un intero segmento di rete al resto della rete. Alcuni
router infatti possiedono anche un firewall incorporato, poiché il punto di
ingresso/uscita di una rete verso l'esterno è ovviamente il luogo migliore dove
effettuare controlli sui pacchetti in transito.
Inoltre durante la fase di installazione della rete è necessario verificare che il
numero di router interconnessi non sia tale da provocare ritardi di trasmissione
inaccettabili per la rete stessa, e la scadenza dei timeouts previsti dai protocolli
di routing.
87
Problemi connessi alle WAN
I router , come già detto precedentemente, sono utilizzati per interconnettere
reti LAN su area geografica.
figura 2.18
Pertanto, una fonte d’errore nell’interconnessione è costituita da problemi nei
link di comunicazione delle reti WAN (insufficienza della larghezza di banda,
lunghi tempi di ritardo, elevati BER, errate configurazioni dei protocolli
utilizzati). Per evitare allora situazioni di stallo è consigliabile attuare una
politica di controllo della capacità e del carico dei link, del BER e del tasso di
frame con FCS invalide usando un analizzatore di protocollo.
Configurazioni errate delle maschere di sottorete.
Un router ha in generale molte interfacce, una per ciascuno dei link ad esso
collegati, a ciascuna interfaccia è associato un indirizzo IP, di 32 bit. In generale
ciascun indirizzo è costituito da una parte che identifica la rete e da una parte
che identifica l’interfaccia dell’host o del router.
Spesso le reti possono essere suddivise in sottoreti ed in tal caso il router deve
88
tener traccia solo degli indirizzi degli host appartenenti alla sua stessa sottorete
e degli indirizzi delle varie sottoreti. Infatti all’arrivo di un pacchetto il router
ne esamina l’indirizzo ed esegue un AND booleano con la maschera di sottorete
della rete, determinando così l’interfaccia verso cui instradarlo. Pertanto è
necessario un controllo sistematico delle maschere di sottorete per evitare gravi
problemi di indirizzamento (un indirizzo di un singolo host può diventare un
indirizzo broadcasts) ed il fallimento di connessioni.
89