Routing alla fermata del tram

Routing e tram

Nel mio precedente articolo avevo affrontato, di sfuggita, alcuni temi riguardanti le reti dei Service Provider. Mi sono arrivate molte mail a riguardo, soprattutto di persone interessate a capire realmente quali siano i cambiamenti strutturali tra le canoniche reti aziendali e l’infrastruttura di un ISP.

In questo articolo vedremo, attraverso un esempio, che una di queste differenze risiede nel diverso ambito di utilizzo da parte dei protocolli di routing interni, i cosiddetti IGP (Interior Gateway Protocol). Quello che spesso distingue un ingegnere di rete junior da un professionista più navigato è proprio la conoscenza del comportamento di tali protocolli nei più disparati ambiti di utilizzo. Non per niente, ad esempio, vediamo che IS-IS è maggiormente diffuso nelle reti degli ISP di grandi dimensioni, dove la scalabilità è un fattore primario ed il protocollo serve quasi esclusivamente per il trasporto delle informazioni di routing, a discapito invece di OSPF, più conosciuto ed impiegato nelle reti aziendali.

L’esempio forse più lampante di questa differenza può essere notato se consideriamo una pratica comune dell’amministratore di reti: la ricerca del tempo di convergenza più breve possibile. Siamo abituati a pensare che meno impieghi il protocollo di routing a convergere dopo un fallimento, meglio sia; eppure nelle reti dei Service Provider, che sono di fatto degli AS di transito, una convergenza troppo veloce può portare ad enormi problemi, persino a bloccare tutto il traffico (il famoso black hole routing).

Nel seguito prenderemo in esame una classica situazione in cui quanto detto può verificarsi molto facilmente, e vedremo quali soluzioni sono state pensate per risolvere tali, comuni, problemi.

Amministratori di rete

Supponiamo di essere gli amministratori della Canistracci Oil S.p.A. La rete aziendale è quella mostrata in figura, dove abbiamo esclusivamente evidenziato i router che formano il backbone dell’infrastruttura, dei Cisco 7200.

Diagramma rete aziendale

A ciascun router è associato, come di consueto, un indirizzo di loopback. Il protocollo di routing interno è IS-IS; i collegamenti sono tutti di livello uno (intra-area) per semplicità, anche se in una realtà aziendale ci troveremmo probabilmente ad utilizzare diverse aree separate e collegamenti di livello due inter-area. Di seguito la configurazione del protocollo per il router R1:

R1#sh run | se ^router isis
router isis
net 00.0200.0010.0100.1001.00
is-type level-1
passive-interface Loopback0

Ecco invece il database IS-IS:

R1#sh isis database

IS-IS Level-1 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R1.00-00 * 0x000000DF 0x52C3 1028 0/0/0
R2.00-00 0x000000E9 0x2FC9 690 0/0/0
R2.01-00 0x000000DD 0xEBE4 540 0/0/0
R3.00-00 0x000000E4 0x4113 1079 0/0/0
R3.02-00 0x00000070 0xE7EE 920 0/0/0
R4.00-00 0x000000DF 0xC04C 1007 0/0/0
R4.01-00 0x000000DA 0x3E0D 999 0/0/0
R5.00-00 0x000000DF 0xDECA 1116 0/0/0
R5.01-00 0x000000DC 0x6638 1127 0/0/0
R5.02-00 0x000000DD 0x5B63 875 0/0/0

Possiamo anche verificare l’albero di routing a regime, partendo dal nodo R1 (radice dell’albero):

R1#sh isis topology

IS-IS paths to level-1 routers
System Id Metric Next-Hop Interface SNPA
R1 —
R2 10 R2 Fa1/0 ca01.48c0.001c
R3 20 R2 Fa1/0 ca01.48c0.001c
R4 10 R4 Fa1/1 ca03.48c0.001c
R5 20 R4 Fa1/1 ca03.48c0.001c

Ecco infine la tabella di routing per R1:

R1#sh ip route

Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
i L1 2.2.2.2 [115/10] via 10.200.12.2, FastEthernet1/0
3.0.0.0/32 is subnetted, 1 subnets
i L1 3.3.3.3 [115/20] via 10.200.12.2, FastEthernet1/0
4.0.0.0/32 is subnetted, 1 subnets
i L1 4.4.4.4 [115/10] via 10.200.14.4, FastEthernet1/1
5.0.0.0/32 is subnetted, 1 subnets
i L1 5.5.5.5 [115/20] via 10.200.14.4, FastEthernet1/1
10.0.0.0/29 is subnetted, 5 subnets
C 10.200.14.0 is directly connected, FastEthernet1/1
C 10.200.12.0 is directly connected, FastEthernet1/0
i L1 10.200.23.0 [115/20] via 10.200.12.2, FastEthernet1/0
i L1 10.200.35.0 [115/30] via 10.200.14.4, FastEthernet1/1
[115/30] via 10.200.12.2, FastEthernet1/0
i L1 10.200.45.0 [115/20] via 10.200.14.4, FastEthernet1/1

Come abbiamo fatto notare in precedenza, uno degli obiettivi che ci prefiggiamo è quello di avere, in caso di guasti (riavvio di un router, rottura di un cavo e così via), un tempo di convergenza che sia più breve possibile, idealmente nell’ordine di pochi secondi. Ci sono molte vie per raggiungere questo risultato: possiamo ad esempio effettuare un tuning molto spinto dei timer del protocollo, oppure utilizzare BFD per avere Fault Detection nell’ordine dei decimi di secondo. Questi argomenti verranno affrontati in un prossimo articolo; ci limiteremo per ora ad utilizzare i timer di default.

Convergenza Maxima

Il nostro scopo è vedere come si comporta la rete, ed in particolare il protocollo di routing, in caso di malfunzionamento. Potremo ad esempio immaginare di essere un utente della LAN servita da R1, e di voler raggiungere un servizio presente nella LAN dietro ad R3. La tabella di routing di R1 ci dirà quale percorso (dei due possibili) verrà scelto per instradare i pacchetti:

R1#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "isis", distance 115, metric 20, type level-1
Redistributing via isis
Last update from 10.200.12.2 on FastEthernet1/0, 23:31:05 ago
Routing Descriptor Blocks:
* 10.200.12.2, from 3.3.3.3, via FastEthernet1/0
Route metric is 20, traffic share count is 1

Come prevedibile, il percorso più breve si ha passando per R2 (indirizzo del next-hop 10.200.12.2). Possiamo verificarlo meglio utilizzando traceroute:

R1#traceroute 3.3.3.3 source loopback 0

Type escape sequence to abort.
Tracing the route to 3.3.3.3
1 10.200.12.2 16 msec 36 msec 4 msec
2 10.200.23.3 16 msec 20 msec *

Supponiamo ora che il link tra R2 ed R3 si guasti; il protocollo di routing dovrà riconvergere ed R1 dovrà instradare i pacchetti seguendo il percorso alternativo R4-R5-R3. Simuleremo il guasto eseguendo lo shutdown dell’interfaccia fa1/1 di R2 e generando contemporaneamente del traffico con un ping:

R1#ping 3.3.3.3 size 1200 repeat 100

Type escape sequence to abort.
Sending 100, 1200-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!U.U.U.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 94 percent (94/100), round-trip min/avg/max = 4/24/72 ms

Il risultato è quello che ci aspettavamo: quando il collegamento tra R1 ed R2 si interrompe, R1 non sa più come inviare i pacchetti ad R3, e genera in risposta un pacchetto ICMP di tipo destination unreachable (la U nell’output). Dopo circa due secondi, il protocollo di routing riconverge, identificando in R1-R4-R5-R3 un nuovo, valido percorso verso R3. Il traffico riprende a scorrere e noi abbiamo perso solo 6 pacchetti.

Ancora migliore è la situazione inversa, nella quale un link guasto torna ad essere disponibile. In questo caso non perderemmo nemmeno un pacchetto, poiché il router R1 re-indirizzerebbe nuovamente il traffico verso R2 solo nel momento in cui la convergenza fosse stata raggiunta. Provare per credere:

R1#ping 3.3.3.3 size 1200 repeat 100

Type escape sequence to abort.
Sending 100, 1200-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/28/126 ms

Come volevasi dimostrare, 100% di affidabilità, nonostante IS-IS abbia dovuto riconvergere nel frattempo.

La Canistracci diventa ISP

Quella che sembra essere una situazione ideale nell’ambito delle reti aziendali diventa invece un grosso problema nel caso degli ISP, ed in generale di tutti gli AS (Autonomous System) che accettano traffico di passaggio. Come dicevamo all’inizio, una delle grandi differenze tra une rete normale e la rete di un Service Provider risiede proprio nell’uso del nostro protocollo di routing super veloce.

Mentre in una canonica rete aziendale noi usiamo un IGP per diffondere le informazioni di routing relative al traffico da trasportare, in un ISP questo compito è riservato a BGP, o più precisamente a iBGP. L’unico scopo dell’IGP è di assicurare la raggiungibilità interna per dare modo a iBGP di formare la maglia di adiacenze. Distingueremo quindi, secondo la terminologia comunemente usata, le due tipologie di routing: core routing per la raggiungibilità interna e customer routing quando trasportiamo informazioni sulle rotte dei clienti (o di altri AS a loro volta collegati).

Prendiamo dunque in considerazione la nostra nuova rete, che questa volta è diventata un AS di transito.

ISP e clienti

Avremo due clienti che vogliono comunicare tra loro, identificati dai due codici AS, AS100 e AS150. Perchè sia possibile un loro collegamento, dovremo configurare eBGP (external BGP) tra i nostri router di confine (R1 per AS100 ed R3 per AS150) ed i router dei clienti:

RouterA#sh run | se router bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
network 10.100.0.0 mask 255.255.0.0
neighbor 1.1.1.1 remote-as 200
neighbor 1.1.1.1 ebgp-multihop 255
neighbor 1.1.1.1 update-source Loopback1
no auto-summary

All’interno della rete, invece, avremo adiacenze iBGP (internal BGP). Ecco la configurazione su R1:

R1#sh run | se router bgp
router bgp 200
template peer-session iBGP
remote-as 200
description iBGP neighbor
password cisco
update-source Loopback0
exit-peer-session
!
no synchronization
bgp log-neighbor-changes
network 10.100.0.0 mask 255.255.0.0
neighbor 2.2.2.2 inherit peer-session iBGP
neighbor 2.2.2.2 next-hop-self
neighbor 3.3.3.3 inherit peer-session iBGP
neighbor 3.3.3.3 next-hop-self
neighbor 4.4.4.4 inherit peer-session iBGP
neighbor 4.4.4.4 next-hop-self
neighbor 5.5.5.5 inherit peer-session iBGP
neighbor 5.5.5.5 next-hop-self
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 ebgp-multihop 255
neighbor 6.6.6.6 update-source Loopback0
no auto-summary

Due ulteriori interfacce di loopback, come mostrato in figura, saranno le LAN clienti di ciascun AS cliente (rispettivamente 10.100.0.0/16 per AS100 e 10.150.0.0/16 per AS150).

Nel diagramma seguente possiamo visualizzare graficamente le adiacenze tra i vari router.

Adiacenze BGP

Le linee tratteggiate rosse rappresentano le adiacenze iBGP. Come i lettori più esperti sapranno, iBGP non permette di inviare ad altri peer iBGP le rotte imparate a sua volta da un altro peer iBGP, in modo da prevenire qualsiasi loop – una tecnica simile allo split horizon. È perciò necessario che la rete sia completamente connessa, e che tutti (quasi tutti, nel nostro caso) i nodi sono connessi tra di loro.
Le linee blu illustrano invece le adiacenze eBGP con i due AS client, AS100 e AS150.

Gli utenti del cliente AS100 per raggiungere la rete interna di AS150 passeranno attraverso l’infrastruttura messa a disposizione dal nostro Canistracci Provider. Proviamo ad effettuare un ping da RouterA usando come indirizzo sorgente un IP facente parte della rete interna, e come indirizzo di destinazione un IP della rete di AS150:

RouterA# ping 10.150.0.1 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.150.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.100.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 108/136/204 ms

Una volta che il traffico è entrato nella rete interna dell’ISP, sarà compito del protocollo di routing interno indirizzare i pacchetti verso la destinazione nel modo ottimale. Abbiamo già visto che il percorso di regime, ossia quello che abbiamo una volta terminata la convergenza, è R1-R2-R3. Ci aspettiamo quindi che anche il traffico esterno utilizzi la stessa rotta; possiamo provarlo facilmente dando un’occhiata alla tabella di routing di R1:

R1#sh ip route

Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
i L1 2.2.2.2 [115/10] via 10.200.12.2, FastEthernet1/0
3.0.0.0/32 is subnetted, 1 subnets
i L1 3.3.3.3 [115/20] via 10.200.12.2, FastEthernet1/0
4.0.0.0/32 is subnetted, 1 subnets
i L1 4.4.4.4 [115/10] via 10.200.14.4, FastEthernet1/1
5.0.0.0/32 is subnetted, 1 subnets
i L1 5.5.5.5 [115/20] via 10.200.14.4, FastEthernet1/1
6.0.0.0/32 is subnetted, 1 subnets
S 6.6.6.6 [1/0] via 192.168.100.2
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
B 10.100.0.0/16 [20/0] via 6.6.6.6, 00:58:46
B 10.150.0.0/16 [200/0] via 3.3.3.3, 00:24:48
C 10.200.14.0/29 is directly connected, FastEthernet1/1
C 10.200.12.0/29 is directly connected, FastEthernet1/0
i L1 10.200.23.0/29 [115/20] via 10.200.12.2, FastEthernet1/0
i L1 10.200.35.0/29 [115/30] via 10.200.14.4, FastEthernet1/1
[115/30] via 10.200.12.2, FastEthernet1/0
i L1 10.200.45.0/29 [115/20] via 10.200.14.4, FastEthernet1/1
192.168.100.0/30 is subnetted, 1 subnets
C 192.168.100.0 is directly connected, FastEthernet0/0

e provando un traceroute da RouterA:

RouterA#traceroute 10.150.0.1 source loopback 0

Type escape sequence to abort.
Tracing the route to 10.150.0.1
1 192.168.100.1 28 msec 92 msec 44 msec
2 10.200.12.2 64 msec 64 msec 24 msec
3 10.200.23.3 112 msec 68 msec 100 msec
4 192.168.150.2 172 msec 124 msec *

Come avevamo immaginato, il percorso seguito è proprio RouterA-R1-R2-R3-RouterB. È da sottolineare come il routing interno della Canistracci ISP sia del tutto trasparente ai due clienti, ai quali deve essere garantita solamente la raggiungibilità. In caso di guasto, infatti, di un router o di un link, l’instadamento interno subirà una modifica, che però sarà del tutto invisibile ai due clienti. Questo risultato si ottiene grazie alla lenta convergenza del protocollo BGP, che impega diverso tempo (nell’ordine delle decine di secondi, a volte anche minuti) a trasmettere le informazioni relative alle proprie rotte.

Supponiamo ora che il router R2 si guasti o venga volontariamente riavviato. Come in precedenza, ci aspetteremmo di perdere quei pochi pacchetti in attesa che il protocollo di routing interno IS-IS riconverga:

RouterA#ping 10.150.0.1 repeat 100 source loopback 0

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.150.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.100.0.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!........!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 92 percent (92/100), round-trip min/avg/max = 48/132/228 ms

Come nell’esempio precedente, pochi secondi affinché il protocollo riconverga e solamente otto pacchetti persi. Il traffico a questo punto viene indirizzato da R1 verso R4, seguendo il percorso R1-R4-R5-R3:

RouterA#traceroute 10.150.0.1 source loopback 0

Type escape sequence to abort.
Tracing the route to 10.150.0.1

1 192.168.100.1 40 msec 44 msec 48 msec
2 10.200.14.4 164 msec 48 msec 156 msec
3 10.200.45.5 124 msec 92 msec 288 msec
4 10.200.35.3 248 msec 148 msec 84 msec
5 192.168.150.2 128 msec 156 msec *

Sul router R1 possiamo notare i messaggi di errore relativi alla sessione BGP con R2:

*Feb  4 12:06:47.119: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Down BGP Notification sent
*Feb 4 12:06:47.119: %BGP-3-NOTIFICATION: sent to neighbor 2.2.2.2 4/0 (hold time expired) 0 bytes

Sempre seguendo la stessa procedura dell’esempio precedente, dopo un certo periodo di tempo il router R2 viene ripristinato. Ci aspetteremmo, come prima, che IS-IS riconverga e che, una volta ristabilito il percorso R1-R2-R3, i pacchetti siano indirizzati correttamente. Nell’esempio precedente non avevamo perso nemmeno un pacchetto; vediamo cosa succede stavolta:

RouterA#ping 10.150.0.1 repeat 200 source loopback 0

Type escape sequence to abort.
Sending 200, 100-byte ICMP Echos to 10.150.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.100.0.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!.......U.U.U.U.U....U.U.U.U.U.U.U..............!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 76 percent (153/200), round-trip min/avg/max = 52/213/1928 ms

Quasi 50 pacchetti persi e più di un minuto di downtime: un risultato inaccettabile! Che cosa è accaduto?

Uno sguardo all’interno

Sappiamo che sicuramente non è colpa di IS-IS, sulla cui convergenza abbiamo effettuato un test poco fa. Forse per analizzare le cause di questo comportamento dobbiamo capire bene come funzionano i protocolli di routing e quali decisioni vengano prese dal router quando deve indirizzare il traffico.

Tutto parte nella tabella di routing di R1. Arriva un pacchetto con IP di destinazione 10.150.0.1: per sapere dove indirizzare questo traffico, il router controlla la tabella di routing e trova un match per la rete 10.150.0.0:

R1#sh ip route 10.150.0.1
Routing entry for 10.150.0.0/16
Known via "bgp 200", distance 200, metric 0
Tag 150, type internal
Last update from 3.3.3.3 02:09:58 ago
Routing Descriptor Blocks:
* 3.3.3.3, from 3.3.3.3, 02:09:58 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 150

L’informazione ricavata è: per raggiungere la rete 10.150.0.0/16, inviare il traffico al next-hop 3.3.3.3. Noi sappiamo che questo indirizzo si riferisce all’interfaccia di loopback di R3, ma il router ancora non sa come raggiungerlo. Bisogna quindi effettuare un’altra query per scoprire dove si trova 3.3.3.3:

R1#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "isis", distance 115, metric 20, type level-1
Redistributing via isis
Last update from 10.200.12.2 on FastEthernet1/0, 00:00:06 ago
Routing Descriptor Blocks:
* 10.200.12.2, from 3.3.3.3, via FastEthernet1/0
Route metric is 20, traffic share count is 1

Ecco finalmente la riposta desiderata: il nome di una interfaccia alla quale inviare il traffico, in questo caso quella collegata a R2.

La differenza tra queste due route è evidente: mentre la prima è stata imparata da BGP, la seconda proviene dal protocollo IS-IS.

Cosa ha potuto causare quindi quel downtime di qualche minuto? Se ricordate, abbiamo detto che IS-IS è molto veloce a convergere, nell’ordine di qualche secondo, mentre BGP è molto piu’ lento. Quando il router R2 torna in funzione, quindi, la rete all’interno della Canistracci ISP riconverge: il next hop da R1 per raggiungere R3 diventa R2. Tuttavia in quel momento BGP non è ancora attivo, dovendo ancora convergere verso la stabilità; quando il pacchetto arriva ad R2 (next-hop di R1) con destinazione 10.150.0.0/16, il router (non sapendo dove inviarlo, perchè l’informazione non esiste ancora nella tabella di routing) semplicemente lo scarta. Esattamente quello che abbiamo chiamato prima un Black Hole Routing.

La storia ci aiuta

Il problema non sussisterebbe se, ovviamente, potessimo fare in modo che IS-IS non riconverga con rapidità, ma aspetti quel tanto che basta perché anche BGP riconverga.

Per fortuna IS-IS dispone di una interessante caratteristica, l’overload bit, che risale ai tempi in cui i router avevano una memoria limitata e cpu poco potenti. Il funzionamento dei protocolli di tipo link-state presuppone che ciascun router abbia una mappa completa della rete di cui fa parte, e possa così decidere autonomamente (applicando l’algoritmo di Dijkstra) quale sia il percorso migliore per raggiungere una destinazione.

Se per ipotesi un router non avesse avuto abbastanza risorse per ricevere ed elaborare queste informazioni, potrebbe avere una visione parziale o errata di ciò che lo circonda, e questo metterebbe a rischio tutta la rete. I creatori del protocollo hanno quindi riservato un bit, chiamato appunto overload, per comunicare ai router vicini la propria situazione a rischio, con un messaggio del tipo “Non sono in grado di processare le tue informazioni, quindi escludimi dalla rete e non mandarmi traffico se non quello locale destinato a me”.

Oggigiorno il bit di overload non è più necessario, perché i router hanno raggiunto una potenza tale da non soffrire più di questi problemi. Possiamo però usarlo per altri scopi: ad esempio, impedire ai router vicini di inviare alcun traffico di transito per un tempo predefinito o, nel caso di router Cisco, finché BGP stesso non abbia finito la propria convergenza, risolvendo di fatto il nostro problema.

Configuriamo quindi il processo IS-IS sul router R2 in questo modo:

R2#sh run | se ^router isis
router isis net 00.0200.0020.0200.2002.00
is-type level-1
set-overload-bit on-startup wait-for-bgp
passive-interface Loopback0

Grazie al comando set-overload-bit con opzione wait-for-bgp, IS-IS segnalerà ai peer di non considerare R2 affidabile e, per il momento, di non indirizzargli alcun traffico di transito. Il next hop per 3.3.3.3 su R1 resterà quindi il router R4 fino a che il processo BGP non avrà raggiunto la convergenza su R2, dopodiche IS-IS segnalerà ad R1 di essere pronto a ricevere traffico e la rete avrà raggiunto stabilità senza perdere nemmeno un pacchetto. Ecco il log su R1:

R1#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "isis", distance 115, metric 30, type level-1
Redistributing via isis
Last update from 10.200.14.4 on FastEthernet1/1, 00:06:51 ago
Routing Descriptor Blocks:
* 10.200.14.4, from 3.3.3.3, via FastEthernet1/1
Route metric is 30, traffic share count is 1
R1#
*Feb 4 14:35:19.439: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up

R1#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "isis", distance 115, metric 20, type level-1
Redistributing via isis
Last update from 10.200.12.2 on FastEthernet1/0, 00:00:00 ago
Routing Descriptor Blocks:
* 10.200.12.2, from 3.3.3.3, via FastEthernet1/0
Route metric is 20, traffic share count is 1

Si noti il timer dell’ultimo update: appena il neighbor 2.2.2.2 è attivo, IS-IS invia un LinkState Update a R1 con la nuova rotta. R1 riconverge e il next-hop cambia da 10.200.14.4 (R4) a 10.200.12.2 (R2).

Il ping effettuato in contemporanea mostra una affidabilità del 100%:

RouterA#ping 10.150.0.1 repeat 100 source loopback 0

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.150.0.1, timeout is 2 seconds:
Packet sent with a source address of 10.100.0.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 16/134/312 ms

Grazie ad una modifica nella configurazione di IS-IS abbiamo quindi raggiunto un risultato molto importante: la nostra rete non correrà più il rischio, in caso di guasti, di scartare tutto il traffico di transito. Tanto per avere un’idea, in alcuni istituti bancari un downtime di un minuto può provocare perdite di qualche milione di dollari: quando tutto l’hardware è ridondante e cerchiamo una affidabilità da cinque nove, non potrà certo essere il protocollo di routing a farci perdere il lavoro!

Comments

  1. axterics says:

    Sebbene io abbia sì e no un infarinatura sui protocolli IGP devo fare i complimenti all’autore, è riuscito a spiegare alla “for dummies” concetti che sono tutt’altro che semplici.

  2. Marco i miei complimenti. Veramente un bell’articolo su un argomento non proprio da principianti. State facendo veramente un ottimo lavoro…ancora i miei complimenti.

Policy per i commenti: Apprezzo moltissimo i vostri commenti, critiche incluse. Per evitare spam e troll, e far rimanere il discorso civile, i commenti sono moderati e prontamente approvati poco dopo il loro invio.