12.06.2013 Views

Esercizi Routing.pdf - the Netgroup at Politecnico di Torino

Esercizi Routing.pdf - the Netgroup at Politecnico di Torino

Esercizi Routing.pdf - the Netgroup at Politecnico di Torino

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

5. Link St<strong>at</strong>e<br />

5.1. Convergenza del Link St<strong>at</strong>e (1)<br />

5.1.1. Accensione <strong>di</strong> R1<br />

Quando viene acceso R1, si verificano due fasi:<br />

• Neighbor <strong>di</strong>scovery: permette a R1 <strong>di</strong> rilevare i router ad esso a<strong>di</strong>acenti, in questo caso R2 e R3;<br />

• D<strong>at</strong>abase Synchroniz<strong>at</strong>ion: il processo permette ai router <strong>di</strong> sincronizzare i d<strong>at</strong>abase, scambiandosi<br />

messaggi fino a quando tutti i router non avranno le stesse informazioni a <strong>di</strong>sposizione;<br />

Più in dettaglio, i seguenti passi avvengono sia sul link A tra R1 e R2 che sul link C tra R1 e R3; per<br />

semplicità viene analizz<strong>at</strong>o il comportamento e il traffico sul solo link A:<br />

1. R1 <strong>di</strong>venta <strong>at</strong>tivo e invia un pacchetto <strong>di</strong> Hello sull’interfaccia connessa al link A; questo pacchetto<br />

non conterrà nessuna informazione (mentre in situazioni <strong>di</strong> rete stabile contiene l’elenco dei vicini<br />

già conosciuti e identific<strong>at</strong>i dal router mittente);<br />

2. Dopo aver ricevuto il pacchetto <strong>di</strong> Hello <strong>di</strong> R1, R2 identifica il nuovo vicino, e nei suoi successivi<br />

pacchetti <strong>di</strong> Hello, invia questa informazione (aggiungendo R1 alla lista dei router a<strong>di</strong>acenti<br />

conosciuti);<br />

3. Dopo aver ricevuto il primo pacchetto <strong>di</strong> Hello da R2, R1 ha la conferma <strong>di</strong> essere st<strong>at</strong>o identific<strong>at</strong>o<br />

correttamente dal suo vicino (poichè il suo ID compare nei pacchetti appena ricevuti); <strong>di</strong><br />

conseguenza, genera un pacchetto D<strong>at</strong>abase Description vuoto (senza LSA summary) per iniziare<br />

la fase <strong>di</strong> negoziazione del master/slave sul link (necessaria per la procedura <strong>di</strong> sincronizzazione);<br />

4. R2 risponde al precedente pacchetto con un altro D<strong>at</strong>abase Description, sempre necessario per<br />

la negoziazione master/slave; viene eletto master il router che ha l’ID maggiore (in questo caso<br />

si suppone R2);<br />

5. Dopo aver rilev<strong>at</strong>o che R2 è il master, R1 invia un D<strong>at</strong>abase Description in<strong>di</strong>cando che durante<br />

questa fase è lo slave; questo pacchetto viene popol<strong>at</strong>o con gli header LSA contenuti nel suo<br />

Link St<strong>at</strong>e Summary List;<br />

6. R2 invia un altro D<strong>at</strong>abase Description, contenente gli header LSA ricav<strong>at</strong>i dal rispettivo Link<br />

St<strong>at</strong>e Summary List;<br />

7. R1 invia un pacchetto <strong>di</strong> acknowledgment in risposta al D<strong>at</strong>abase Description appena ricevuto.<br />

Questo processo continua, con R2 che invia D<strong>at</strong>abase Description e poi aspetta la conferma<br />

<strong>di</strong> ricezione, fino a quando R2 invia l’ultimo D<strong>at</strong>abase Description (contenente l’ultimo LSA<br />

Summary);<br />

8. Dopo aver ricevuto l’ultimo D<strong>at</strong>abase Description, R1 controlla la sua Link St<strong>at</strong>e Request List, e<br />

vede che ovviamente non è vuota, poichè contiene tutti i LSA header che gli sono st<strong>at</strong>i comunic<strong>at</strong>i<br />

da R2 e che prima non erano conosciuti (perchè il router è st<strong>at</strong>o appena acceso);<br />

34

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!