Esercizi Routing.pdf - the Netgroup at Politecnico di Torino

Politecnico di Torino
Corso di Tecnologie per Reti di Calcolatori
Esercizi di riepilogo: Routing
Fulvio Risso
October 18, 2010

Contents
I. Esercizi 4
1. Distance Vector 5
1.1. Distance Vector con e senza Split Horizon . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Distance Vector e Triggered Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Convergenza del Distance Vector (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Convergenza del Distance Vector (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5. Convergenza del Distance Vector (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6. Convergenza del Distance Vector (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Link State 12
2.1. Convergenza del Link State (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Convergenza del Link State (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Determinazione del Link State Database con OSPF in area singola . . . . . . . . . . . 14
2.4. OSPF con area multipla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3. Domande di teoria 16
3.1. Algoritmi di Forwarding e Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3. Link State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
II. Soluzioni 20
4. Distance Vector 21
4.1. Distance Vector con e senza Split Horizon . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1. Split Horizon disabilitato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.2. Split Horizon abilitato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Distance Vector e Triggered Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3. Convergenza del Distance Vector (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.1. Fault 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.2. Fault 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4. Convergenza del Distance Vector (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5. Convergenza del Distance Vector (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5.1. Partenza a freddo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5.2. Tempo di convergenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5.3. Guasto (route poisoning non abilitato) . . . . . . . . . . . . . . . . . . . . . . . 25
4.5.4. Guasto (route poisoning abilitato) . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6. Convergenza del Distance Vector (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6.1. Partenza a freddo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2

4.6.2. Guasto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6.3. Guasto con hold-down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6.4. Tempo di convergenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5. Link State 34
5.1. Convergenza del Link State (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.1. Accensione di R1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2. Guasto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2. Convergenza del Link State (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.1. Accensione di R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.2. Shortest Path Spanning Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.3. Guasto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3. Determinazione del Link State Database con OSPF in area singola . . . . . . . . . . . 39
5.3.1. Albero di instradamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.2. Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.3. Link State Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.4. Designated e Backup Designated Router . . . . . . . . . . . . . . . . . . . . . . 41
5.4. OSPF con area multipla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6. Domande di teoria 43
6.1. Algoritmi di Forwarding e Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2. RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3. Link State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3

Part I.
Esercizi
4

1. Distance Vector
1.1. Distance Vector con e senza Split Horizon
Sia data le rete sottostante, nella quale ogni router scambia informazioni di routing attraverso un
protocollo di tipo distance vector che segue fedelmente l’algoritmo teorico. Si scrivano i distance
vector generati da R2 non appena questo router rileva il guasto, differenziandone il comportamento a
seconda che l’algoritmo di split horizon sia disabilitato oppure abilitato.
192.168.2.1/24
R1 R2 R3
192.168.1.1/30
5
192.168.1.6/30
R4
192.168.3.1/24
192.168.1.9/30
192.168.4.1/24

1.2. Distance Vector e Triggered Updates
Sia data le rete sottostante, nella quale ogni router scambia informazioni di routing attraverso un
protocollo di tipo distance vector che segue fedelmente l’algoritmo teorico con l’aggiunta delle Triggered
Updates.
Si scrivano i distance vector scambiati tra R2 ed R4 a fronte del rilevamento del guasto da parte di
R2, supponendo che i router abbiano l’algoritmo di Split Horizon with Poisonous Reverse abilitato.
192.168.2.1/24
R1 R2 R3
192.168.1.1/30
6
192.168.1.6/30
R4
192.168.3.1/24
192.168.1.9/30
192.168.4.1/24

1.3. Convergenza del Distance Vector (1)
Sia data le rete sottostante, nella quale ogni router scambia informazioni di routing attraverso un
protocollo di tipo distance vector che segue fedelmente l’algoritmo teorico.
Supponga che nella rete si possano verificare due guasti, identificati nel disegno come Fault1 e
Fault2.
Si calcoli dopo quanto tempo il router R4 vedrà sparire dalla sua routing table la rete 192.168.2.0/24
nei due casi, supponendo che:
• i router non facciano uso di Triggered Updates
• i router abbiano un Route Invalid Timer di 180s e un Route Flush Timer di 240s
• l’algoritmo di Route Poisoning sia disabilitato
• l’algoritmo di Split Horizon sia abilitato su tutti i router.
R1 S1
R2 R3 R4
192.168.2.0/24
Fault1 Fault2
7

1.4. Convergenza del Distance Vector (2)
Sia data le rete sottostante, nella quale ogni router scambia informazioni di routing attraverso un
protocollo di tipo distance vector che segue fedelmente l’algoritmo teorico, e che si verifichi ad un
certo punto un guasto come indicato nella figura.
Si calcoli dopo quanto tempo il router R4 vedrà sparire dalla sua routing table la rete 192.168.2.0/24,
supponendo che:
• i router facciano uso di Triggered Updates, che sono ritardate di 5s
• i router abbiano un Route Invalid Timer di 180s e un Route Flush Timer di 240s
• l’algoritmo di Route Poisoning sia abilitato
• l’algoritmo di Split Horizon sia abilitato su tutti i router.
R1 R2 R3 R4
192.168.2.0/24
8

1.5. Convergenza del Distance Vector (3)
Data la rete rappresentata in figura, ipotizzando che su ogni router sia configurato un protocollo di
routing basato su distance vector che non implementi alcun accorgimento per incrementare la stabilità
e la velocità di convergenza:
1. Simulare la partenza a freddo di tale protocollo, elencando i distance vector scambiati fino al
raggiungimento di una situazione stabile.
2. Ipotizzando che i messaggi di update siano scambiati in modo sincrono, con una cadenza di 30s
(update timer), qual è il tempo di convergenza della rete?
3. Data la rete a regime, simulare un guasto sul link C tra R1 ed R3, sia nel caso in cui non sia
presente un meccanismo di route poisoning, sia nel caso in cui questo sia presente. Che differenze
di comportamento si rilevano tra i due casi?
9

R1
Link A
Net E
R2
Link C
Link B
Net D Net F
1.6. Convergenza del Distance Vector (4)
H G
C
R4 R3
D B
A
R1 R2
E
Data la rete rappresentata in figura, ipotizzando che su ogni router sia configurato il protocollo RIP
con split horizon:
1. Simulare la partenza a freddo, elencando i distance vector scambiati fino al raggiungimento di
una situazione stabile.
10
R3
F

2. Data la rete a regime, simulare un guasto sull’interfaccia di R2 attestata sulla rete F.
3. Ripetere il punto 2, ipotizzando che sia implementato un meccanismo di route hold-down (holddown
timer = 180s).
4. Data la rete di Figura 2 a regime simulare l’inserimento di un router RIP (R5) sulla rete E (il
router R5 ha due interfacce: una si affaccia sulla rete E e l’altra si affaccia sulla rete I).
5. Ipotizzando che i messaggi di update siano scambiati in modo sincrono, con una cadenza di 30s
(update timer), qual è il tempo di convergenza della rete nel caso proposto nel punto 4?
11

2. Link State
2.1. Convergenza del Link State (1)
Data la rete rappresentata in figura, ipotizzando che su ogni router sia configurato un protocollo
link-state (si supponga inoltre che il costo di tutti i link sia unitario):
1. Simulare le operazioni effettuate dal protocollo quando R1 viene acceso, descrivendo i messaggi
scambiati sulla rete (supporre che R2 e R3 siano già operativi che la rete sia in una situazione
stabile e che il meccanismo usato dall’algoritmo sia lo stesso di OSPF).
2. Supponendo la rete in una situazione stabile, simulare un guasto sul link C tra R1 e R3 (si ipotizzi
che il meccanismo usato dall’algoritmo sia lo stesso di OSPF).
R1
Link A
Net E
R2
Link C
Link B
Net D Net F
12
R3

2.2. Convergenza del Link State (2)
Data la rete rappresentata in figura, ipotizzando che su ogni router sia configurato un protocollo
link-state (i costi dei link sono indicati nell’immagine):
1. Simulare le operazioni effettuate dal protocollo quando R3 viene acceso, descrivendo i messaggi
scambiati sulla rete (supporre che R1, R2 e R4 siano già operativi, che la rete sia in una situazione
stabile e che il meccanismo usato dall’algoritmo sia lo stesso di OSPF).
2. Calcolare lo shortest path spanning tree per ogni router.
3. Supponendo la rete in una situazione stabile, simulare un guasto sul link C tra R1 e R3 (si ipotizzi
che il meccanismo usato dall’algoritmo sia lo stesso di OSPF).
4. Il guasto sul link scatena qualche cambiamento nelle routing table?
1
H 1 G
C
R4 R3
3
D B
A
R1
4
R2
1
2
E
13
1
F
2

2.3. Determinazione del Link State Database con OSPF in area singola
Data la rete sottostante composta da un insieme di router e di links i cui costi di attraversamento
sono indicati in blu, determinare:
• l’albero di instradamento dei vari router
• la routing table dei vari router
• il link state database presente sui router.
Indicare infine se dalla lettura del database sia possibile stabilire gli indirizzi del Designated Router
e del Backup Designated Router per quanto riguarda la rete NetL.
NetA NetB
1 1
3
NetL
R1
NetF
4
R2
R5
2
NetM
NetI
3
1 1
NetE NetD
R4
NetG
NetH
Si supponga che l’intera rete appartenga ad un solo dominio di tipo Link State (es. OSPF in area
0).
14
2
2
R3
1
NetC

2.4. OSPF con area multipla
Si consideri la rete in figura dove sono indicati router, reti e costi associati alle interfacce dei router.
Nell’ipotesi di usare il protocollo di routing OSPF e di suddividere la rete in 3 aree come indicato,
disegnare la rete vista dal Router R1.
R1 R2
N2 (1) N3 (1)
N4 (1)
R5 R6
R7
N6 (2)
N1 (1)
N7 (2)
N5 (2)
R3
R4
15
N8 (2)
Network (cost)
N9 (1) N10 (2)
R8 R9 R10
N11 (1)

3. Domande di teoria
3.1. Algoritmi di Forwarding e Routing
1. Quali sono le principali differenze tra le tecniche denominate “forwarding by network address”
e “label swapping”?
2. A cosa serve un algoritmo di routing?
3. A cosa serve un algoritmo di forwarding?
4. In cosa consiste un routing loop? In quali circostanze può verificarsi?
5. Che cos’è un black-hole? In quali circostanze può verificarsi?
6. Il routing dinamico è sempre preferibile al routing statico? Argomentare.
7. In cosa consiste il “selective flooding”? Quali accorgimenti richiede rispetto al “flooding” puro?
8. Comparare il routing centralizzato col routing isolato, evidenziando vantaggi e svantaggi delle
due tecniche.
9. Quali informazioni vengono scambiate tra i nodi di rete che utilizzano un algoritmo di routing
di tipo distance vector?
10. Cos’è un “triggered update”?
11. Quali miglioramenti apporta la tecnica dello split-horizon ad un algoritmo di tipo distance vector?
Che tipo di problemi non è in grado di risolvere?
12. A cosa serve l’hold-down timer?
16

3.2. RIP
1. Che cos’è il RIP?
2. Quale tipo di metrica utilizza? Qual è la metrica che indica una rete irraggiungibile?
3. Descrivere il funzionamento dei timer del protocollo RIP
4. Dopo quanti update mancati una route viene etichettata come irraggiungibile?
5. A cosa servono i messaggi di tipo “request” nel RIP?
6. Qual è la maggiore differenza tra le due versioni del protocollo RIP?
7. Che cos’è e a cosa serve il route poisoning?
17

3.3. Link State
1. Quali sono le informazioni trasportate nei pacchetti link state?
2. A che cosa servono i pacchetti di Hello?
3. Descrivere il meccanismo usato dai routers per sincronizzare i rispettivi link state database
4. Come vengono calcolate le tabelle di routing in un algoritmo link state?
5. In quale modo gli algoritmi link state garantiscono la coerenza della rete?
6. Perchè le reti che utilizzano un protocollo link state convergono più velocemente rispetto a quelle
che fanno uso di protocolli distance vector?
7. Perchè i numeri di sequenza sono importanti nei protocolli link state?
8. Illustrare come le reti broadcast (es. LAN Ethernet) vengono viste e gestite negli algoritmi di
routing link state
18

3.4. OSPF
1. Che cos’è OSPF?
2. Che cos’è un’area stub?
3. Per quale motivo in OSPF viene utilizzato il concetto di “area”?
4. Che cos’è un area border router?
5. Che cos’è un network link state?
6. Che cos’è un router link state?
7. Perchè la sommarizzazione è importante in OSPF?
19

Part II.
Soluzioni
20

4. Distance Vector
4.1. Distance Vector con e senza Split Horizon
4.1.1. Split Horizon disabilitato
Quando il router R2 rileva il guasto indicato in figura, l’algoritmo del distance vector prevede che
vengano eseguiti i seguenti passi:
1. Cancellazione dei distance vector provenienti dal link non più funzionante (che sono memorizzati
all’interno del router); in questo caso viene eliminato il vettore generato da R1;
2. Fusione dei distance vector rimanenti;
3. Calcolo della nuova tabella di routing, e se questa cambia rispetto alla versione precedente, viene
inoltrato un nuovo distance vector; in questo caso la tabella varia, poichè, subito dopo il guasto,
R2 tenterà di utilizzare R4 oppure R3 per raggiungere, ad esempio, la rete 192.168.2.0/24.
Questo comportamento è naturalmente errato, ma i router R3 e R4 non sono in grado di riconoscere
il guasto verificatosi, pertanto nelle loro routing table compare ancora quella rete,
avente come next hop R2 (che viene creduto ancora valido), e quindi la rete viene annunciata
nei loro distance vector.
Pertanto, uno dei possibili distance vector generati da R2 subito dopo aver rilevato il guasto è:
4.1.2. Split Horizon abilitato
DV(R2)
Rete annunciata Costo
192.168.1.0/30 3
192.168.1.4/30 1
192.168.1.8/30 1
192.168.2.0/24 4
192.168.3.0/24 2
192.168.4.0/24 2
Nel caso in cui l’algoritmo di split horizon sia abilitato, la situazione è totalmente differente. In
questo caso infatti, i router R3 e R4, nei distance vector generati verso R2, non annunciano più la
rete 192.168.2.0/24, perchè i due router utilizzano proprio R2 come next hop per quella route. Di
conseguenza, i distance vector inviati da R2 verso i link ai quali si trovano connessi R3 e R4 sono,
rispettivamente:
DV(R2) verso R3
Rete annunciata Costo
192.168.1.4/30 1
192.168.3.0/24 2
21
DV(R2) verso R4
Rete annunciata Costo
192.168.1.8/30 1
192.168.4.0/24 2

4.2. Distance Vector e Triggered Updates
Nel momento in cui R2 rileva il guasto, il meccanismo delle triggered updates prevede che si attenda
un tempo casuale (per evitare intasamenti nella rete e accumulare altre possibili rilevazioni di guasto).
Dopo questa attesa, il router invia sui suoi link (e quindi anche verso R4) un pacchetto di triggered
update, contenente le informazioni sulle sole route che sono cambiate in seguito alla variazione di
connettività; in questo caso quindi, in questo pacchetto verranno annunciate le reti 192.168.2.0/24
e 192.168.1.0/30 a costo infinito. Di conseguenza, R4, dopo aver ricevuto il triggered update da
R2, rileverà a sua volta una variazione delle route nella routing table (poichè una rete è diventata
irraggiungibile), e quindi genererà anche lui un triggered update, contenente le stesse informazioni di
quello precedente.
Inoltre, utilizzando l’algoritmo di split horizon con l’opzione Poisonous Reverse abilitata, due possibili
distance vector scambiati tra R2 e R4 dopo il guasto sono:
DV(R2) verso R4
Rete annunciata Costo
192.168.1.4/30 infinito
192.168.1.8/30 1
192.168.3.0/24 infinito
192.168.4.0/24 2
22
DV(R4) verso R2
Rete annunciata Costo
192.168.1.4/30 infinito
192.168.1.8/30 infinito
192.168.3.0/24 1
192.168.4.0/24 infinito

4.3. Convergenza del Distance Vector (1)
4.3.1. Fault 1
• Istante 0 (secondi): Si verifica il guasto; R2 non lo rileva (poichè non gli arriva il segnale di link
down, essendo il guasto “oltre” lo switch) e continua a annunciare la rete;
• Istante 180: R2, essendo scaduto il route invalid timer, rileva il guasto, e inizia a inviare i distance
vector senza la rete; R3 non rileva comunque il guasto e continua a annunciare la rete;
• Istante 360: R3, essendo scaduto il route invalid timer, rileva il guasto, e inizia a inviare i distance
vector senza la rete; R4 non rileva comunque il guasto e continua a annunciare la rete;
• Istante 540: R4, essendo scaduto il route invalid timer, rileva il guasto, e inizia a inviare i distance
vector senza la rete; La rete è comunque ancora presente nella sua routing table;
• Istante 780: R4, essendo scaduto il route flush timer, rimuove la rete dalla sua routing table;
Tutte queste tempistiche possono essere soggette ad un “offset” che va da 0 a 30 secondi, in base
all’istante in cui si verifica il guasto rispetto all’ultimo distance vector inviato da R1 e ricevuto da R2.
4.3.2. Fault 2
• Istante 0 (secondi): Si verifica il guasto; R2 lo rileva (essendo il guasto “prima” del collegamento
con lo switch) e non annuncia più la rete 192.168.2.0/24;
• Istante 180: R3, essendo scaduto il route invalid timer, rileva il guasto, e inizia a inviare i distance
vector senza la rete; R4 non rileva comunque il guasto e continua a annunciare la rete;
• Istante 360: R4, essendo scaduto il route invalid timer, rileva il guasto, e inizia a inviare i distance
vector senza la rete; La rete è comunque ancora presente nella sua routing table;
• Istante 600: R4, essendo scaduto il route flush timer, rimuove la rete dalla sua routing table;
Tutte queste tempistiche possono essere soggette ad un “offset” che va da 0 a 30 secondi, in base
all’istante in cui si verifica il guasto rispetto all’ultimo distance vector inviato da R2 e ricevuto da R3.
23

4.4. Convergenza del Distance Vector (2)
• Istante 0 (secondi): Si verifica il guasto; R2 lo rileva e riconosce come irraggiungibile la rete
192.168.2.0/24;
• Istante 5: R2 invia un triggered update su tutte le interfacce, annunciando la rete a costo infinito
(essendo il route poisoning abilitato); R3 rileva quindi il guasto e riconosce come irraggiungibile
la rete;
• Istante 10: R3 invia un triggered update su tutte le interfacce, annunciando la rete a costo infinito
(essendo il route poisoning abilitato); R4 rileva quindi il guasto e riconosce come irraggiungibile
la rete;
• Istante 250: R4, essendo scaduto il route flush timer, rimuove la rete dalla sua routing table;
24

4.5. Convergenza del Distance Vector (3)
4.5.1. Partenza a freddo
Siccome in questo specifico caso non viene implementata nessuna particolare opzione (come lo split
horizon), ogni router invierà lo stesso distance vector su tutte le sue interfacce. Per simulare la
partenza a freddo, si suppone di inizializzare la rete alimentando tutti i nodi contemporaneamente. In
questo stato, ciascuno dei nodi è caratterizzato unicamente da una conoscenza locale, e dopo un certo
numero di passi (corrispondenti a scambi di distance vector), la rete raggiunge una situazione stabile:
DV(R1)
Rete Costo
A 1
C 1
D 1
DV(R1)
Rete Costo
A 1
B 2
C 1
D 1
E 2
F 2
4.5.2. Tempo di convergenza
Passo 1
DV(R2)
Rete Costo
A 1
B 1
E 1
Passo 2
DV(R2)
Rete Costo
A 1
B 1
C 2
D 2
E 1
F 2
DV(R3)
Rete Costo
B 1
C 1
F 1
DV(R3)
Rete Costo
A 2
B 1
C 1
D 2
E 2
F 1
Se si suppone che i messaggi scambiati siano sincroni, si può osservare, dal passo precedente, che dopo
il primo scambio di distance vector tutti i router conoscono tutte le reti (quindi i vettori annunciati
non cambiano più). Il tempo necessario affinchè si verifichi questa situazione è pari al route update
timer; in questo caso quindi, 30 secondi.
4.5.3. Guasto (route poisoning non abilitato)
Nel caso in cui il route poisoning non sia abilitato, una possibile simulazione della rete dopo il guasto
è:
1. R1 e R3 rilevano immediatamente il guasto; entrambi da questo momento in poi utilizzano come
next hop R2 per le route che prima erano raggiungibili attraverso il link ora guasto (C, D e F); i
distance vector inviati da R1 e R3 sono pertanto:
25

DV(R1)
Rete Costo
A 1
B 2
C 3
D 1
E 2
F 3
DV(R3)
Rete Costo
A 2
B 1
C 3
D 3
E 2
F 1
2. R2, ricevendo i nuovi distance vector da R1 e R3 rileva che il costo per la rete C è aumentato, e
di conseguenza il suo distance vector cambia in:
DV(R2)
Rete Costo
A 1
B 1
C 4
D 2
E 1
F 2
Si verifica chiaramente un fenomeno di count to infinity, in cui ad ogni scambio di distance vector
aumenta di un’unità il costo verso la destinazione C.
4.5.4. Guasto (route poisoning abilitato)
Nel caso in cui il route poisoning sia abilitato, una possibile simulazione della rete dopo il guasto è:
1. R1 e R3 rilevano immediatamente il guasto; quando inviano i rispettivi distance vector, annunciano
la rete C a costo infinito, poichè è divenuta irraggiungibile; inoltre, entrambi da questo
momento in poi utilizzano come next hop R2 per le route che prima erano raggiungibili attraverso
il link ora guasto (D e F); i distance vector inviati da R1 e R3 sono pertanto:
DV(R1)
Rete Costo
A 1
B 2
C infinito
D 1
E 2
F 3
DV(R3)
Rete Costo
A 2
B 1
C infinito
D 3
E 2
F 1
2. R2, ricevendo i nuovi distance vector da R1 e R3 rileva che la rete C è diventata irraggiungibile
da entrambe le direzioni, e di conseguenza il suo distance vector cambia in:
26

DV(R2)
Rete Costo
A 1
B 1
C infinito
D 2
E 1
F 2
In questo caso, siccome il route poisoning è abilitato, e quindi le route irraggiungibili vengono annunciate
a costo infinito, non si ha nessun fenomeno di instabilità sulla rete.
27

4.6. Convergenza del Distance Vector (4)
4.6.1. Partenza a freddo
Siccome in questo specifico caso è attivo il meccanismo dello split horizon, ogni router invierà un
distance vector diverso a seconda dell’interfaccia sulla quale questo viene inoltrato. Per simulare la
partenza a freddo, si suppone di inizializzare la rete alimentando tutti i nodi contemporaneamente. In
questo stato, ciascuno dei nodi è caratterizzato unicamente da una conoscenza locale, e dopo un certo
numero di passi (corrispondenti a scambi di distance vector), la rete raggiunge una situazione stabile:
DV(R1) su A
Rete Costo
D 1
E 1
DV(R2) su A
Rete Costo
B 1
F 1
DV(R3) su B
Rete Costo
C 1
G 1
DV(R4) su C
Rete Costo
D 1
H 1
Passo 1
DV(R1) su D
Rete Costo
A 1
E 1
DV(R2) su B
Rete Costo
A 1
F 1
DV(R3) su C
Rete Costo
B 1
G 1
DV(R4) su D
Rete Costo
C 1
H 1
28
DV(R1) su E
Rete Costo
A 1
D 1
DV(R2) su F
Rete Costo
A 1
B 1
DV(R3) su G
Rete Costo
B 1
C 1
DV(R4) su H
Rete Costo
C 1
D 1

DV(R1) su A
Rete Costo
C 2
D 1
E 1
H 2
DV(R2) su A
Rete Costo
B 1
C 2
F 1
G 2
DV(R3) su B
Rete Costo
C 1
D 2
G 1
H 2
DV(R4) su C
Rete Costo
A 2
D 1
E 2
H 1
Passo 2
DV(R1) su D
Rete Costo
A 1
B 2
E 1
F 2
DV(R2) su B
Rete Costo
A 1
D 2
E 2
F 1
DV(R3) su C
Rete Costo
A 2
B 1
F 2
G 1
DV(R4) su D
Rete Costo
B 2
C 1
G 2
H 1
29
DV(R1) su E
Rete Costo
A 1
B 2
C 2
D 1
F 2
H 2
DV(R2) su F
Rete Costo
A 1
B 1
C 2
D 2
E 2
G 2
DV(R3) su G
Rete Costo
A 2
B 1
C 1
D 2
F 2
H 2
DV(R4) su H
Rete Costo
A 2
B 2
C 1
D 1
E 2
G 2

DV(R1) su A
Rete Costo
C 2
D 1
E 1
H 2
G 3
DV(R2) su A
Rete Costo
B 1
C 2
F 1
G 2
DV(R3) su B
Rete Costo
C 1
D 2
G 1
H 2
DV(R4) su C
Rete Costo
A 2
D 1
E 2
H 1
4.6.2. Guasto
Passo 3
DV(R1) su D
Rete Costo
A 1
B 2
E 1
F 2
DV(R2) su B
Rete Costo
A 1
D 2
E 2
F 1
H 3
DV(R3) su C
Rete Costo
A 2
B 1
E 3
F 2
G 1
DV(R4) su D
Rete Costo
B 2
C 1
F 3
G 2
H 1
Dall’istante in cui si verifica il guasto, uno dei possibili scenari sulla rete è:
30
DV(R1) su E
Rete Costo
A 1
B 2
C 2
D 1
F 2
G 3
H 2
DV(R2) su F
Rete Costo
A 1
B 1
C 2
D 2
E 2
G 2
H 3
DV(R3) su G
Rete Costo
A 2
B 1
C 1
D 2
E 3
F 2
H 2
DV(R4) su H
Rete Costo
A 2
B 2
C 1
D 1
E 2
F 3
G 2

1. R2 rileva immediatamente il guasto (ma supponendo i triggered updates disabilitati, non invia
comunque nessuna informazione in rete);
2. Allo scadere dell’update timer, R2 invia i suoi distance vector, simili a quelli del passo precedente,
tranne per il fatto che la rete F non viene più annunciata, poichè è diventata irraggiungibile (e
si suppone disabilitato il route poisoning):
DV(R2) su A
Rete Costo
B 1
C 2
G 2
DV(R2) su B
Rete Costo
A 1
D 2
E 2
H 3
3. R3 non riceve più nessun annuncio della rete F (da ogni direzione), ma continua ad annunciarla
fino allo scadere del suo route invalid timer nel suo distance vector verso R4:
DV(R3) su C
Rete Costo
A 2
B 1
E 3
F 2
G 1
4. Dal punto di vista di R4, nulla è cambiato per ora, poichè R3 non ha ancora invalidato la route,
quindi il suo distance vector verso R1 è:
DV(R4) su D
Rete Costo
B 2
C 1
F 3
G 2
H 1
5. R1 non riceve più l’annuncio della rete F da R2, ma continua a ricevere quello da R4 (a costo 3).
Allo scadere del suo route invalid timer, assumerà come next hop proprio R4 per la rete F, e la
annuncierà nel suo distance vector verso R2:
DV(R1) su A
Rete Costo
C 2
D 1
E 1
F 4
H 2
G 3
31

A questo punto, si può verificare il fenomeno del count to infinity, in cui R2 annuncierà la rete F a
costo 5 verso R3 e così via, poi R3 la annuncierà a costo 6 verso R4, ...
4.6.3. Guasto con hold-down
Dall’istante in cui si verifica il guasto, uno dei possibili scenari sulla rete è:
1. R2 rileva immediatamente il guasto (ma supponendo i triggered updates disabilitati, non invia
comunque nessuna informazione in rete);
2. Allo scadere dell’update timer, R2 invia i suoi distance vector, simili a quelli in caso di rete stabile,
tranne per il fatto che la rete F non viene più annunciata, poichè è diventata irraggiungibile (e
si suppone disabilitato il route poisoning):
DV(R2) su A
Rete Costo
B 1
C 2
G 2
DV(R2) su B
Rete Costo
A 1
D 2
E 2
H 3
3. R3 non riceve più nessun annuncio della rete F (da ogni direzione), ma continua ad annunciarla
fino allo scadere del suo route invalid timer nel suo distance vector verso R4:
DV(R3) su C
Rete Costo
A 2
B 1
E 3
F 2
G 1
4. R1 non riceve più l’annuncio della rete F da R2, ma continua a ricevere quello da R4 (a costo 3).
Allo scadere del suo route invalid timer tuttavia, la precedente route viene dichiarata irraggiungibile
e questo scatena l’attivarsi dell’hold-down timer, che blocca la route per 180 secondi; in
questo intervallo di tempo, il suo distance vector verso R2 non conterrà la rete F (a differenza
del caso precedente, in cui l’assenza dell’hold-down permetteva al router di cambiare immediatamente
la route):
DV(R1) su A
Rete Costo
C 2
D 1
E 1
H 2
G 3
32

In questo caso, il fenomeno del count to infinity può quindi essere evitato, perchè R1 ha congelato la
route relativa a F (nel caso precedente invece, alla scadenza del route invalid timer veniva immediatamente
preso come next hop R4, e questo comportava l’inizio del count to infinity). In questa situazione
quindi, tutta la rete ha il tempo di accorgersi del guasto. Si noti comunque che non si ha la certezza
di evitare il count to infinity: tutto dipende dalle tempistiche con le quali vengono mandati gli update
dai router; potrebbe capitare infatti, che nel momento in cui R1 termina l’hold-down, R4 stia ancora
inviando gli annunci per la rete F a costo 3; questo potrebbe nuovamente portare al verificarsi del
fenomeno.
4.6.4. Tempo di convergenza
Se si ipotizza che la fase in cui vengono scambiati i messaggi di RIP Update e RIP Request tra R1 e
R5 avvenga in un tempo trascurabile e che i messaggi di update siano scambiati in modo sincrono tra
i router, è necessario attendere 60 secondi affinchè la rete riconverga:
• Istante 0 (secondi): solo R1 e R5 sono a conoscenza della rete I;
• Istante 30: R1 invia il distance vector aggiornato sulle sue interfacce, quindi anche R2 e R4
rilevano I;
• Istante 60: R2 e R4 inviano il distance vector aggiornato, quindi anche R3 rileva I; la rete
converge.
Si noti che questo tempo di convergenza può essere notevolmente diminuito se si abilitano i triggered
updates.
33

5. Link State
5.1. Convergenza del Link State (1)
5.1.1. Accensione di R1
Quando viene acceso R1, si verificano due fasi:
• Neighbor discovery: permette a R1 di rilevare i router ad esso adiacenti, in questo caso R2 e R3;
• Database Synchronization: il processo permette ai router di sincronizzare i database, scambiandosi
messaggi fino a quando tutti i router non avranno le stesse informazioni a disposizione;
Più in dettaglio, i seguenti passi avvengono sia sul link A tra R1 e R2 che sul link C tra R1 e R3; per
semplicità viene analizzato il comportamento e il traffico sul solo link A:
1. R1 diventa attivo e invia un pacchetto di Hello sull’interfaccia connessa al link A; questo pacchetto
non conterrà nessuna informazione (mentre in situazioni di rete stabile contiene l’elenco dei vicini
già conosciuti e identificati dal router mittente);
2. Dopo aver ricevuto il pacchetto di Hello di R1, R2 identifica il nuovo vicino, e nei suoi successivi
pacchetti di Hello, invia questa informazione (aggiungendo R1 alla lista dei router adiacenti
conosciuti);
3. Dopo aver ricevuto il primo pacchetto di Hello da R2, R1 ha la conferma di essere stato identificato
correttamente dal suo vicino (poichè il suo ID compare nei pacchetti appena ricevuti); di
conseguenza, genera un pacchetto Database Description vuoto (senza LSA summary) per iniziare
la fase di negoziazione del master/slave sul link (necessaria per la procedura di sincronizzazione);
4. R2 risponde al precedente pacchetto con un altro Database Description, sempre necessario per
la negoziazione master/slave; viene eletto master il router che ha l’ID maggiore (in questo caso
si suppone R2);
5. Dopo aver rilevato che R2 è il master, R1 invia un Database Description indicando che durante
questa fase è lo slave; questo pacchetto viene popolato con gli header LSA contenuti nel suo
Link State Summary List;
6. R2 invia un altro Database Description, contenente gli header LSA ricavati dal rispettivo Link
State Summary List;
7. R1 invia un pacchetto di acknowledgment in risposta al Database Description appena ricevuto.
Questo processo continua, con R2 che invia Database Description e poi aspetta la conferma
di ricezione, fino a quando R2 invia l’ultimo Database Description (contenente l’ultimo LSA
Summary);
8. Dopo aver ricevuto l’ultimo Database Description, R1 controlla la sua Link State Request List, e
vede che ovviamente non è vuota, poichè contiene tutti i LSA header che gli sono stati comunicati
da R2 e che prima non erano conosciuti (perchè il router è stato appena acceso);
34

9. Anche R2 ha degli LSA header pendenti nella sua Link State Request List, in quanto il router
R1 ha inviato l’LSA header relativo alla rete I;
10. R1 invia pacchetti di Link State Request esplicitando gli LSA a lui mancanti, e R2 comunica le
informazioni richieste nei pacchetti di Link State Update; questo avviene fino a quando la Link
State Request List di R1 non è vuota; ovviamente avviene lo stesso anche nell’altra direzione, in
quanto R2 deve poter ottenere l’LSA relativo alla rete I;
5.1.2. Guasto
Nel caso si verifichi un guasto sul link C, entrambi i router R1 e R3 rilevano immediatamente il problema
(grazie al segnale di link down) ed effettuano i seguenti passi:
1. Ricalcolo della tabella di routing, poichè l’informazione topologica in loro possesso è cambiata;
2. Invio di un Link State Update “speciale”, contenente l’informazione che invalida la rete divenuta
irraggiungibile (ad esempio nell’implementazione cisco questo viene fatto assegnando all’opzione
“age“ il valore 3600); questo pacchetto è inviato in flooding su tutta la rete; attraverso il suo
invio si comunica agli altri router che dovranno immediatamente cancellare le informazioni memorizzate
precedentemente e ricalcolare la tabella di routing;
3. Viene attesa la ricezione dei rispettivi acknowledgment, per confermare la corretta ricezione del
precedente update; se non viene ricevuto l’acknowledgment da un particolare router, il pacchetto
di link state update viene di nuovo inoltrato, ma questa volta in unicast (prima era inviato in
multicast) direttamente al router che non ha confermato la ricezione;
35

5.2. Convergenza del Link State (2)
5.2.1. Accensione di R3
Questa fase è sostanzialmente uguale a quella dell’esercizio precedente; la negoziazione master/slave,
lo scambio di database description e la sequenza di pacchetti link state request/update avviene sia tra
R3 e R2 che tra R3 e R4.
5.2.2. Shortest Path Spanning Tree
1
Router R1
H 1 G
C
R4 R3
3
2
D B
A
R1
4
R2
1
1
E
Router R2
C
R4 R3
3
D B
A
R1
4
R2
1
2
H 1 G
E
36
1
1
F
F
2
2

5.2.3. Guasto
1
Router R3
H 1 G
C
R4 R3
3
2
D B
A
R1
4
R2
1
1
E
Router R4
H 1 G
C
R4 R3
3
D B
A
R1
4
R2
1
2
E
Al verificarsi del guasto, i router R1 e R3 eseguiranno gli stessi passi elencati nell’esercizio precedente.
In questo caso, i cambiamenti nelle tabelle di routing sono:
• Tutti i router eliminano l’informazione relativa alla rete C;
• Nel ricalcolo della nuova topologia, i router che utilizzavano il link C per raggiungere altre
destinazioni avranno uno shortest path spanning tree diverso rispetto a quello precedente, ed
37
1
1
F
F
2
2

eseguendo l’algoritmo per il calcolo della tabella di routing, otterranno route con next hop
differenti rispetto a prima.
38

5.3. Determinazione del Link State Database con OSPF in area singola
L’esercizio include tre domande, le cui soluzioni vengono presentate singolarmente.
5.3.1. Albero di instradamento
L’albero di instradamento si ottiene calcolando l’albero dei cammini minimi da ogni router verso la
ogni possibile destinazione (le reti NetX ) utilizzando l’algoritmo di Dijkstra.
Nel disegno si riportano le soluzioni per quanto riguardano i router R1 ed R5.
NetA NetB
1 1
R1
NetF
4
R2
3
NetL
R5
2
NetM
NetI
3
1 1
NetE NetD
NetG
2
2
R4
NetH
R3
1
NetC
NetA NetB
1 1
R1
NetF
4
R2
R5
NetM
NetI
3
NetE NetD
Per quanto riguarda gli altri router, gli alberi di instradamento si ricavano in modo analogo.
5.3.2. Routing Table
La routing table si ricava seguendo, per ogni possibile destinazione, il next hop indicato dall’albero di
instradamento minimo (ricavato al punto precedente).
In questa soluzione vengono adottati le seguenti convenzioni in quanto utilizzate dal protocollo IP:
• Il costo per raggiungere una certa rete include il costo di attraversamento della rete stessa. Ad
esempio, il costo di raggiungere la rete NetA da R1 è pari a 1 e non 0. In altre parole, il costo
di attraversamento è inteso come un costo di attraversamento dell’interfaccia del router anzichè
come un costo di attraversamento della rete.
• Le reti connesse ad un router hanno come Next Hop il router stesso. Ad esempio il next hop per
raggiungere la rete NetA da R1 è il router R1 stesso.
La figura seguente riporta (in forma letterale) gli indirizzi di tutte le interfacce del router che sono
necessarie ai fini della compilazione della routing table.
39
3
NetL
1
2
1
NetG
2
2
R4
NetH
R3
1
NetC

NetA NetB
1 1
R1
R1_F NetF
4
R2_B
R2_F
R2
R1_A
R1_L
3
NetL
R5_L
R5_E
1
R1_M
R5
R5_I
2
NetM
NetI
3
R4
1
NetE NetD
R2_G
2
2
NetG
R3
NetH
R3_G R3_C
La routing table risultante è riportata nella seguente tabella (la seconda e la terza colonna sono
riferite rispettivamente ai router R1 ed R5):
Destinazione Next hop (R1) Cost (R1) Next hop (R5) Cost (R5)
NetA R1 A 1 R1 L 4
NetB R2 F 5 R1 L,R4 I 8
NetC R4 M 5 R4 I 6
NetD R4 M 3 R4 I 4
NetE R5 l 4 R5 E 1
NetF R1 F 4 R1 L 7
NetG R2 F,R4 M 6 R4 I 7
NetH R4 M 4 R4 I 5
NetI R4 M 5 R5 I 3
NetL R1 L 3 R5 L 3
NetM R1 M 2 R1 L,R4 I 5
Si noti come per raggiungere la rete NetF da R5 il percorso più conveniente passi attraverso il next
hop R1. Tuttavia, la rete NetF non viene utilizzata per raggiungere la rete NetB: in questo caso il
percorso più conveniente passa attraverso il next hop R4. Per quanto riguarda la rete NetM, invece,
esistono due percorso equivalenti a partire da R5, che può pertanto scegliere indifferentemente o R1 o
R4 come next hop.
40
R4_I
R4_M
R4_D
R4_H
R3_H
1
NetC

5.3.3. Link State Database
Il Link State Database include solamente LSA di tipo Router Link e Network Link, in quanto (a) la rete
include solamente un’area OSPF, che (b) non connessa è ad altri domini. I Router Link riporteranno
le adiacenze dei vari router con (a) le reti IP presenti, (b) i router adiacenti, (c) le eventuali reti di
transito generate dall’OSPF per gestire le LAN con più di 2 routers. I Network Link riporteranno i
dati relativi alle reti di transito; in questo caso sarà presente un solo Network Link relativo alla rete
NetL che è l’unica rete di transito presente nella topologia indicata.
La soluzione per quanto riguarda i router R1, R4 ed R5 è riportata in figura. La soluzione per quanto
riguarda i router R2 ed R3 viene omessa per brevità.
Router LSA (Router R1, #items: 6)
Router Link (Link to a stub network)
Router Link (Link to a stub network)
Router Link (Link to a stub network)
Router Link (Link to a stub network)
Router Link (Point-to-point link to another router)
Router Link (Point-to-point link to another router)
Router Link (Link to a transit network)
Router LSA (Router R4, #items: 7)
Router Link (Link to a stub network)
Router Link (Link to a stub network)
Router Link (Link to a stub network)
Router Link (Link to a stub network)
Router Link (Point-to-point link to another router)
Router Link (Point-to-point link to another router)
Router Link (Point-to-point link to another router)
Router LSA (Router R5, #items: 5)
Router Link (Link to a stub network)
Router Link (Link to a stub network)
Router Link (Link to a stub network)
Router Link (Point-to-point link to another router)
Router Link (Link to a transit network)
Network Link State (Router R5, #items: 1)
Netmask: MaskL Attached Routers: R1, R5
5.3.4. Designated e Backup Designated Router
Link ID (Network): NetA
Link ID (Network): NetF
Link ID (Network): NetM
Link ID (Network): NetL
Link ID (Neighbor RouterID): R2
Link ID (Neighbor RouterID): R4
Link ID (DR IP address): R5_L
Link ID (Network): NetM
Link ID (Network): NetH
Link ID (Network): NetI
Link ID (Network): NetD
Link ID (Neighbor RouterID): R1
Link ID (Neighbor RouterID): R3
Link ID (Neighbor RouterID): R5
Link ID (Network): NetL
Link ID (Network): NetI
Link ID (Network): NetE
Link ID (Neighbor RouterID): R4
Link ID (DR IP address): R5_L
Link Data (Netmask): MaskA
Link Data (Netmask): MaskF
Link Data (Netmask): MaskM
Link Data (Netmask): MaskL
Link Data (Router If. Addr.): R1_F
Link Data (Router If. Addr.): R1_M
Link Data (Router If. Addr.) R1_L
Link Data (Netmask): MaskM
Link Data (Netmask): MaskH
Link Data (Netmask): MaskI
Link Data (Netmask): MaskD
Link Data (Router If. Addr.): R4_M
Link Data (Router If. Addr.): R4_H
Link Data (Router If. Addr.): R4_I
Link Data (Netmask): MaskL
Link Data (Netmask): MaskI
Link Data (Netmask): MaskE
Link Data (Router If. Addr.): R5_I
Link Data (Router If. Addr.) R5_L
L’indirizzo IP del Designated Router si può ricavare dal LSA relativo al Router Link verso la rete di
transito (ad es. il sesto LSA contenuto nel RouterLSA di R1), ed è riportato nel campo Link ID.
Per quanto riguarda il Backup Designated Router non è specificato esplicitamente nel database
OSPF. In questo caso è facilmente ricavabile considerando che sulla rete NetL vi sono solamente 2
router e che essendo R5 il Designated Router, R1 dovrà per forza essere il Backup (a meno che il campo
Priority ne impedisca la sua elezione).
In generale, l’identità del Backup Designated Router è ricavabile qualora si sia in grado di intercettare
un pacchetto OSPF Hello sulla LAN di transito, in quanto questi pacchetti riportano sia
l’indirizzo IP del Designated Router che quello del Backup Designated Router.
41

5.4. OSPF con area multipla
La vista della rete da parte del router R1 è la seguente:
1
R1 R2
1 1
1
N2 N3
N4
N1
5
1
R3
2 4
N5 N6
6
42
1
N7
N8
2
4 5
R4
N9 N10
3
N11

6. Domande di teoria
6.1. Algoritmi di Forwarding e Routing
1. Nella tecnica di forwarding by network address ogni pacchetto deve contenere l’indirizzo del
nodo destinatario della comunicazione, il quale viene usato come chiave di accesso alla tabella
di routing. Nel Label Swapping invece, viene inserita una particolare informazione detta “label”
all’interno di ogni pacchetto in transito, la quale contribuisce ad identificare univocamente il
percorso che verrà effettuato dal pacchetto. Le due tecnologie sono profondamente diverse sotto
vari aspetti:
• Semplicità: il primo non richiede nessuna fase di setup, nè il mantenimento di alcun stato;
nel secondo è necessario preparare il percorso e mantenere lo stato di ogni sessione;
• Scalabilità del processo di forwarding: il primo è decisamente più scalabile del secondo,
grazie al fatto che non è necessario mantenere nessuno stato per le sessioni;
• Scalabilità del processo di routing: il primo può portare ad avere tabelle di routing estremamente
grandi; nel secondo le tabelle sono più piccole;
• Efficienza: nel primo gli header possono essere di dimensioni abbastanza notevoli; nel secondo
sono senza dubbio più “snelli”;
• Multipath: il primo non supporta percorsi multipli tra due destinazioni; il secondo offre
nativamente questa possibilità;
2. Un algoritmo di routing ha lo scopo di trovare quale è il percorso migliore all’interno di una rete
data per tutti i nodi della rete. Più formalmente, è un processo che, in automatico, è in grado di
procedere alla disseminazione delle informazioni di routing in una rete. Un generico algoritmo di
routing può essere classificato sulla base delle sue caratteristiche, tra cui semplicità, robustezza,
ottimalità, stabilità, equità.
3. Lo scopo di un algoritmo di forwarding è quello di determinare qual è la migliore porta di uscita
verso una destinazione, a fronte di un pacchetto entrante in un nodo di rete. In generale un
algoritmo di forwarding opera indipendentemente su ogni nodo della rete, non ha una conoscenza
globale della rete e utilizza informazioni locali al nodo per l’inoltro dei pacchetti.
4. Il fenomeno del routing loop avviene quando un pacchetto viene rimpallato ciclicamente su un
insieme di più nodi. Si verifica quando alcune route della rete innescano un percorso circolare.
Rappresenta una situazione particolarmente pericolosa perché i pacchetti all’interno del loop
circolano nella rete finché non sono scartati per eccessivo “time to live”, situazione che può
portare al progressivo intasamento della rete.
5. Un black-hole è un fenomeno che si verifica quando i pacchetti verso una data destinazione sono
inviati ad un router il quale, non disponendo di un percorso per la destinazione, li scarta.
6. Sebbene il routing statico, essendo un algoritmo non adattativo, presenti numerosi svantaggi,
tra cui l’incapacità di modificare i percorsi a fronte di un guasto, rappresenta una tecnologia
estremamente semplice che permette al gestore di controllare con estrema precisione i percorsi
43

del traffico sulla rete (anche se è necessario un suo intervento manuale per il loro reinstradamento
in presenza di variazioni topologiche). Può quindi essere una buona scelta in un ambiente poco
dinamico (ad esempio una rete periferica) e di piccole dimensioni, in cui non si ha un’alta
frequenza di variazione delle route e della topologia.
7. Il selective flooding è un algoritmo che cerca di limitare i problemi del flooding tradizionale
(principalmente l’altissimo carico indotto sulla rete) senza perderne i vantaggi (cioè l’altissima
probabilità che il pacchetto giunga a destinazione). Per far si che questo sia possibile, è necessario
che ogni nodo emetta i pacchetti con un numero di sequenza crescente ed univoco, che permetta
ad ogni router di riconoscere se un pacchetto è già stato ricevuto (e quindi evitare di trasmetterlo)
oppure no (e quindi inviarlo in tutte le direzioni tranne quella da cui è arrivato). Bisogna inoltre
riservare una quantità di memoria aggiuntiva nei nodi, poichè vanno memorizzati i numeri di
sequenza di tutti i pacchetti, per poter verificare se sono già passati.
8. Vantaggi routing centralizzato: gestione della rete molto accurata; facilità nell’eseguire il debugging
della rete; Svantaggi routing centralizzato: introduce un single point of failure (il nodo
centrale) nella rete; poco adatto in reti con elevata frequenza di variazione delle route
9. Nel distance vector, ogni nodo comunica tutte le informazioni di connettività in suo possesso a
tutti i router adiacenti. Le informazioni sono trasportate in una unità chiamata appunto distance
vector, che contiene:
• la lista delle destinazioni raggiungibili;
• la direzione che si può utilizzare per raggiungere le destinazioni;
• il costo per raggiungimento delle destinazioni;
10. Un triggered update è una tecnica per migliorare il tempo di convergenza in una rete che utilizza
un protocollo di routing di tipo distance vector, come il RIP, al prezzo di generare traffico
addizionale. Un triggered update permette ad un router di annunciare un cambiamento di metrica
in una entry della sua routing table quasi immediatamente, invece di aspettare il prossimo
aggiornamento periodico, come previsto dalla “teoria” dell’algoritmo. I triggered update sono
inviati dopo un piccolo intervallo di tempo (casuale) rispetto alla rilevazione del cambiamento,
per impedire intasamenti della rete.
11. Lo split horizon modifica il principio base di funzionamento di un algoritmo di tipo distance
vector, permettendo di differenziare i vari vettori inviati sulle linee di un router (che secondo
l’algoritmo classico dovrebbero essere tutti uguali). Questo permette di ottenere una serie di
vantaggi, tra cui impedire il loop tra due nodi e rendere la convergenza della rete più veloce.
Tuttavia non è in grado di far fronte a loop che investono maglie composte da più nodi, in quanto
ha una visione locale della rete.
12. L’hold-down timer impedisce ad un router di modificare le route che fanno riferimento ad un
link sul quale si è rilevato un guasto, così da lasciare un intervallo di tempo in cui gli altri nodi
possono riconfigurarsi, ed evitare un routing loop.
44

6.2. RIP
1. Il Routing Information Protocol (RIP) è un protocollo di routing tra i più usati su reti locali ed
aiuta i router ad adattarsi dinamicamente ai cambiamenti dei collegamenti di rete, scambiandosi
informazioni riguardo a quali reti ogni router può raggiungere e quanto siano lontane. RIP è
un protocollo di tipo distance-vector e usa l’algoritmo Bellman-Ford. In molti ambienti di rete
RIP non è la prima scelta tra i protocolli di routing poiché il tempo di convergenza è lungo e ha
una scalabilità della rete modesta se confrontato con le alternative disponibili, inoltre il basso
numero di hop supportati limita severamente la grandezza della rete. D’altra parte, è molto
facile da configurare ed è implementato anche nei router di fascia bassa.
2. Di default, RIP utilizza una metrica basata sul numero di links che vengono attraversati per
raggiungere la destinazione. Questa distanza è espressa come un numero intero variabile tra 1 e
15; 16 rappresenta una distanza infinita, cioè una rete irraggiungibile.
3. Il protocollo RIP prevede l’utilizzo di vari tipi di timers:
• Routing update timer (default 30 s): intervallo di tempo per l’invio degli annunci
• Route invalid timer (default 90 s): intervallo di tempo dopo il quale una route è dichiarata
irraggiungibile (distanza posta ad infinito)
• Route flush timer (default 270 s): intervallo di tempo dopo il quale la route è cancellata
dalla routing table
• Timer per i triggered updates: sono inviati con un ritardo casuale compreso tra 1 e 5
secondi, per evitare intasamenti della rete e per far sì di poter eventualmente comunicare
più cambi di route con un messaggio solo.
4. In assenza di guasti, ogni 30 secondi un router x manda il proprio distance vector a tutti i suoi
vicini. Ognuno di essi a sua volta manderà al router x il proprio distance vector. Il router x
riceve quindi ogni 30 secondi diversi distance vector che userà per aggiornare la propria tabella di
routing e calcolare quindi una nuova stima del suo vettore. Se uno dei vicini non invia il proprio
distance vector per 90 secondi (la durata di default del route invalid timer), lo si considera
irraggiungibile e si assegna distanza infinita. Con i valori di default, questo avviene quindi dopo
3 update mancati.
5. I messaggi di request vengono normalmente inviati da un router appena acceso per venire a
conoscenza delle route della rete; questo permette di velocizzare il tempo di convergenza della
rete, senza dover attendere lo scadere del routing update timer.
6. La versione 2 del RIP ingloba diversi miglioramenti rispetto all’originale. Tale protocollo, per
mantenere la retrocompatibilità con il suo predecessore, usa una metrica basata sugli hop (massimo
15). Nell’ambito degli update, però, invia informazioni relative alle subnet (permettendo
di trasferire quindi le maschere di rete) e prevede un meccanismo di autenticazione basato su
password. Inoltre, a differenza della versione 1, invia gli update in multicast.
7. Il route poisoning è un meccanismo utilizzato dai router per comunicare l’irraggiungibilità di
alcune route. In particolare, una route irraggiungibile (ad esempio un’interfaccia fisica che si
scollega dalla rete) viene annunciata a costo infinito, mentre secondi l’algoritmo classico questa
non dovrebbe essere più annunciata. Permette di aumentare la velocità di convergenza della
rete, e quindi evitare i problemi che si possono verificare durante il transitorio.
45

6.3. Link State
1. Il Link State memorizza la coppia link-costo per ogni nodo adiacente conosciuto dal nodo in
esame. Di conseguenza, ogni riga del LS conterrà le informazioni relative alla destinazione (il
nome del nodo adiacente sul quale il link termina) e al costo relativo. Se, ad esempio, un nodo
ha quattro nodi adiacenti, esso propagherà un pacchetto contenente quattro righe corrispondenti
alle quattro adiacenze.
2. I pacchetti di Hello permettono di implementare il riconoscimento delle adiacenze. Attraverso lo
scambio di questi messaggi, l’algoritmo è in grado di accorgersi autonomamente della presenza /
mancanza dei nodi adiacenti senza fare affidamento a meccanismi esterni quali il segnale link-up.
3. Il meccanismo è implementato nell’algoritmo di bringing up adjiacencies. Questo componente
permette ad un nodo di evitare di attendere l’invio del LS da parte di tutti i nodi e prevede che
il nodo si attivi facendo un’apposita query ai suoi nodi vicini richiedendo loro il database. Ogni
qualvolta un nodo rileva di avere una nuova adiacenza, effettuera una fase di sincronizzazione del
proprio database con il nodo adiacente in modo da essere operativo prima possibile e velocizzare
la convergenza della rete.
4. Il Link State ingloba l’algoritmo SPF (che è in grado di calcolare il cammino migliore tra due
nodi) per il calcolo della routing table. A partire dal database topologico (che ogni nodo si
è calcolato nelle fasi precedenti dell’algoritmo), è possibile, mediante semplici passi, ottenere
l’albero di instradamento, e quindi la routing table.
5. L’idea dei protocolli di routing “link state” è di mantenere una copia sincronizzata del database
sullo stato dei link in tutti i nodi della rete. In questo modo, se tutti i nodi contengono lo stesso
database ed eseguono lo stesso algoritmo per la creazione delle tabelle di routing, i percorsi sono
coerenti e non si verificano loops.
6. Le reti che utilizzano algoritmi link state hanno una convergenza estremamente rapida grazie
al fatto che i pacchetti contenenti i link state si propagano molto velocemente sulla rete. A
differenza dei link state, infatti, i distance vector vengono ricavati dalla tabella di routing,
pertanto ogni nodo deve prima ricavare la tabella di routing, poi generare il proprio vettore e
propagarlo. Tutto questo richiede molto più tempo rispetto al primo caso.
7. A seguito di frequenti variazioni di topologia un router può ricevere un pacchetto link state
vecchio dopo uno nuovo, quindi deve essere in grado di valutare il più recente. Pertanto, quando
un nodo riceve un pacchetto link state confronta il numero di sequenza del pacchetto con quello
dell’ultimo pacchetto ricevuto da quel nodo, e se il numero di sequenza indica che il pacchetto
è più recente di quello memorizzato, allora viene memorizzato e inoltrato a tutti i nodi collegati
(eccetto quello da cui è stato ricevuto); in caso contrario il pacchetto viene scartato.
8. Per gestire le reti broadcast, viene introdotta l’idea dello pseudo-nodo, o nodo fittizio, che
trasforma la rete da magliata a stellare. Ogni router della rete, infatti, rileverà una sola adiacenza
con lo pseudo-nodo stesso il quale farà da transito per il calcolo della topologia. Lo pseudo-nodo
non è un nodo aggiuntivo inserito in sostituzione della rete broadcast, ma i protocolli reali
selezionano un particolare router e lo designano come pseudo-nodo. Questa modifica “virtuale”
di topologia non influenza tuttavia il computo delle route per i router partecipanti alla rete
broadcast.
46

6.4. OSPF
1. Il protocollo OSPF (Open Shortest Path First) è uno dei protocolli di instradamento più diffusi,
che gestisce le tabelle di instradamento di una rete IP con il metodo del Link State. Il protocollo
implementa i classici algoritmi previsti dalla teoria del link state, e aggiunge altre funzionalità
particolarmente sfruttate in situazioni reali, come l’aggiunta di ulteriori gradi nella gerarchia dei
domini di routing.
2. Per Stub Area si intendono quei tipi di area che non ricevono route esterne. Le route esterne
saranno poi definite e distribuite da un altro protocollo di Routing. Quindi, le stub area necessitano
di relegare ad una route di default lo scambio per il traffico con quelle esterne al dominio
di appartenenza.
3. L’introduzione del concetto di area permetta la creazione di gruppi logici non sovrapposti di
router le cui informazioni posso essere sommarizzate rispetto al resto della rete. Questo è molto
importante in quanto garantisce al protocollo la caratteristica di scalabilità, fattore fondamentale
se si vuole utilizzare OSPF in reti piuttosto ampie e/o complesse. Attraverso l’uso delle aree, è
infatti possibile ridurre il consumo in termini di memoria, CPU e utilizzo di rete dei router che
utilizzano il protocollo.
4. Un area border router è un particolare router che connette una o più aree OSPF all’area di
backbone. È membro di tutte le aree alle quali è connesso. Inoltre mantiene in memoria copie
multiple del database link state, uno per ciascuna area alla quale appartiene.
5. Un network link state è un record che si trova all’interno di un database OSPF. Insieme agli
altri tipi di record, fornisce le informazioni necessarie al calcolo della topologia della rete. In
particolare, questo record è generato dal designated router per le reti di transito, ed elenca tutti
i router presenti sulla LAN; viene propagato sul backbone dai backbone router.
6. Un router link state è un record che si trova all’interno di un database OSPF. Insieme agli
altri tipi di record, fornisce le informazioni necessarie al calcolo della topologia della rete. In
particolare, questo record riporta le informazioni su tutti i link connessi al router che sta facendo
l’advertising. Le informazioni riportate comprendono quindi tutti i router adiacenti e tutte le
LAN collegate; viene propagato solo all’interno dell’area (sia per le aree non backbone che per
il backbone).
7. La corretta sommarizzazione delle route porta alla creazione di routing table concise e di dimensioni
relativamente piccole, che sono tuttavia in grado di instradare correttamente i pacchetti.
Pertanto la sommarizzazione è molto importante in qualsiasi protocollo progettato per avere la
caratteristica di scalabilità, come OSPF.
47