Configurazione dei router Cisco

Internet: configurazione dei Router

(draft 2)

Il materiale di questo libro non e’ sponsorizzato o sottoscritto da Cisco Systems, Inc. Cisco
e’ un trademark di Cisco Systems, Inc. negli Stati Uniti e in altri stati. L’autore di questo
libro non si assume nessuna responsabilita’ e non da nessuna garanzia riguardante
l’accuratezza e la completezza delle informazioni presenti nonche’ da conseguenze sull’uso
delle informazioni presenti in questa pagina.

Copyright 2002-2010 Gianrico Fichera

Nessuna parte di questa pubblicazione puo' essere riprodotta o trasmessa, in qualsiasi

forma o con qualsiasi mezzo, elettronico, meccanico, fotocopie, registrazione, senza il
consenso dell'autore.

This material is not sponsored by, endorsed by, or affiliated with Cisco Systems, Inc.,
Cisco, Cisco Systems, and the Cisco Systems logo are trademarks or registered trade
marks of Cisco Systems, Inc. or its affiliates. All other trademarks are trademarks of their
respective owners.

Audience

Per la comprensione di questo libro e' necessario avere una conoscenza di base di
networking e dell'interfaccia di configurazione dei router Cisco. Inoltre e' necessario avere
una conoscenza di base dei protocolli di rete TCP/IP. Il libro non e' rivolto a chi non ha
alcuna conoscenza sui principi di funzionamento dei router e di Internet. Non e' neppure
rivolto al sistemista avanzato il quale si presume sia gia' a conoscenza della maggior
parte degli argomenti trattati.
L'approccio non e' dogmatico ma trova ispirazione dal "Learning by doing" di John Dewey
(1859-1952), un filosofo americano che ha avuto profonda influenza nell'educazione negli
Stati Uniti. La filosofia e' basata sull'imparare dall'applicazione pratica dei concetti, ovvero

Pagina 1
 Configurazione dei router Cisco

imparare lavorando da subito sui casi concreti piuttosto che focalizzarsi sui dogmi e sulla
teoria, pratica purtroppo molto comune nell'ambiente accademico italiano.
Per Dewey era di vitale importanza nell'educazione non l'insegnamento in se, ma le
conoscenze e l'esperienza che si possono trasmettere agli studenti. Per questo motivo
questo libro utilizza esempi e casi concreti, limitando l'approccio dogmatico a quando
indispensabile. Il libro e' rivolto a chi deve applicare nel mondo del lavoro gli argomenti
trattati.
Revisioni e aggiornamenti

Versione 1.4, Agosto 2010: Revisione

Ringraziamenti

Si ringrazia per il supporto i colleghi di ITESYS srl, in particolare nella persona

dell'Ing.Maurizio Intravaia. Il libro e' dedicato alla memoria del caro collega Dott. Aldo
Schinina', la cui prematura scomparsa e stata una gravissima perdita e di cui non
potremo mai dimenticare la lucidita' intellettuale e il suo contributo da protagonista nelle
attivita' dell'azienda.
Feedback

L'evoluzione della tecnologia informatica e' continua e non concede tregua. Inoltre gli
ambiti di applicazione dei concetti informatici sono svariati. Per quanta cura sia stata
impiegata nella redazione di questo volume, possono essere presenti delle inesattezze.
Pertanto ogni indicazione di errore, omissione e' la benvenuta e potra' essere comunicata
via email ad uno degli indirizzi [email protected] o [email protected].

Introduzione
Internet e' fatta di router e switch. Qualsiasi dato preleviate da Internet ha attraversato
switch e router, l'ultimo dei quali e' presente a casa vostra probabilmente collegato ad
una linea ADSL. Dietro ai router e agli switch ci sono i datacenter con decine o centinaia o
migliaia di computer che forniscono i servizi che utilizziamo quotidianamente, come posta
elettronica e siti internet.
Cisco Systems e' il principale produttore di dispositivi di networking del mondo ed ha
fatto da sempre la parte del leone tra i produttori di router e switch. Quando visitiamo
una pagina web e' molto probabile che i dati abbiano attraversato uno o piu' router Cisco.
Questo libro tratta alcuni argomenti sulla configurazione di questi dispositivi. Non e'
completo perche' non e' possibile trattare la materia con completezza in un singolo
volume. Inoltre i contenuti vanno letti con attenzione perche' non c'e' tecnologia che
evolve piu' rapidamente di internet e quindi alcuni metodi o processi sono differenti a
seconda dei modelli degli apparati e della versione dei sistemi operativi in uso.
Sicuramente il libro va visto come una guida che vi indirizza nella direzione giusta
lasciando poi a voi il compito di concludere i vostri lavori con successo.

Concetti e terminologia sul routing

Compito di un router e' quello di reinstradare i pacchetti dati (noi qui intendiamo per
pacchetto dati un pacchetto della pila protocollare TCP/IP) provenienti da alcune sue

Pagina 2
 Configurazione dei router Cisco

interfacce su altre, in base alle informazioni contenute in una tabella di instradamento

chiamata tabella di routing. Una interfaccia fisica in un router e' una porta fisica su cui
si connette una linea di trasmissione dati. Un router puo' contenere piu' interfacce fisiche,
ad esempio verso la rete Ethernet, oppure per la connettivita' ADSL o HDSL.
Per routing intendiamo l'algoritmo di ricerca del percorso per raggiungere una certa
destinazione (ricerca effettuata con ricorsione nella tabella di routing) che utilizza
informazioni di Layer 3. Per switching di layer 2 intendiamo l'algoritmo di invio del
pacchetto che utilizza le informazioni di layer 2 ovvero i frame (quindi i MAC nel caso di
Ethernet, i VP/VC nel caso di ATM, i DLCI in caso del frame-relay).
Gli switch sono degli apparati che nascono con sole funzionalita' di switching. Negli
apparati di fascia piu' alta le metodologie di switching sono integrate con quelle di routing
e per questo si utilizza la terminologia di switch di layer 3.
La tabella di routing e' un elenco di tutte le destinazioni conosciute dal router. Queste
informazioni vengono raccolte dal router dal file di configurazione e dagli algoritmi di
routing dinamico eventualmente in esecuzione, ovvero comunicate da altri router.
Tutte le informazioni di routing generano la Routing Information Base (RIB). Per
ottimizzare le prestazioni dei router nel corso degli anni alla RIB sono state affiancate
delle tabelle aggiuntive per consentire la determinazione dell'interfaccia di uscita il quanto
piu' rapidamente possibile con un solo lookup. Si parla quindi di switching IP di layer 3.
Inizialmente si sono utilizzate tabelle chiamate route cache in seguito tabelle chiamate
Forwarding Information Base (FIB) e poi altre metodologie. Gli algoritmi di switching
di layer 3 verranno discussi piu' avanti. Il routing viene accelerato ulteriormente quando il
router possiede delle memorie hardware dedicate allo scopo, come le TCAM.
Per quanto riguarda gli algoritmi di routing dinamico per ora basti sapere che si tratta di
algoritmi che consentono ai router di comunicare tra loro trasferendosi informazioni sui
percorsi possibili per raggiungere le destinazioni conosciute. Gli algoritmi piu' usati sono
RIP, IGRP, OSPF, BGP.
In reti con molti router e' fondamentale utilizzare questi algoritmi per evitare di dover
inserire manualmente migliaia di destinazioni in ogni file di configurazione e anche per
automatizzare il backup tra piu' percorsi possibili in reti che offrono diverse alternative per
il raggiungimento di alcuni nodi.

Il sistema operativo degli apparati Cisco

Il sistema operativo della stragrande maggioranza dei router e degli switch Cisco si
chiama Internetworking Operating System (IOS). In precedenza alcuni switch Cisco
utilizzavano un sistema operativo differente chiamato CatOS, oramai in disuso. I firewall
Cisco utilizzano un sistema operativo specifico, che per i Firewall Cisco ASA e' il Cisco
Adaptive Security Appliance Software. In ogni caso l'operatore inserisce una serie di
comandi di configurazione tramite una Command Line Interface (CLI) che permette di
generare il file di configurazione del router. Sempre piu' spesso e' disponibile anche
una interfaccia web per la configurazione.
Primo collegamento ad un router Cisco

UNDER CONSTRUCTION

Interfacce di tipo ethernet

Pagina 3
 Configurazione dei router Cisco

UNDER CONSTRUCTION

Interfacce di tipo seriale

UNDER CONSTRUCTION

Interfacce di tipo ADSL/ATM

UNDER CONSTRUCTION

La shell dei comandi

UNDER CONSTRUCTION

Comandi di shell

UNDER CONSTRUCTION

La tabella di routing

Per visionare il contenuto della RIB si utilizza il comando "show ip route". L'output e'
l’intera tabella di routing. Ecco un esempio:

Router#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D -
EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA
external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 -
OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P
- periodic downloaded static route

Gateway of last resort is not set

116.0.0.0/24 is subnetted, 1 subnets

C 116.30.40.0 is directly connected, ATM0
C 192.168.30.0/24 is directly connected, Ethernet0
151.117.0.0/24 is subnetted, 1 subnets
S 151.117.6.0 [1/0] via 192.168.30.2
D 192.168.81.0/24 [90/14082560] via 192.168.38.10, 00:13:02, Tunnel3

Figura 1 - Esempio di tabella di routing -

- La prima colonna (rosso) indica la provenienza della route ed e' indicata mediante una
lettera. Eccone il significato:

Pagina 4
 Configurazione dei router Cisco

C La route e' generata dal router in quanto trattasi di rete direttamente

connessa
S La route proviene da una statica ovvero da un comando di tipo "ip route"
presente nel file di configurazione
R La route e' stata comunicata attraverso il protocollo RIP
D La route e' stata comunicata attraverso il protocollo EIGRP
O La route e' stata comunicata attraverso il protocollo OSPF
B La route e' stata comunicata attraverso il protocollo BGP

Figura 2 - I tipi di route nella tabella di routing –

- La seconda colonna (blu) indica la rete di destinazione con netmask;
- La terza colonna (verde) quando presente indica la distanza amministrativa (AD) e
la metrica. Ad esempio, per un routing di tipo S troveremo normalmente i valori [1/0].
In questo caso si ha una AD pari ad 1 e una metrica pari a 0. Nei paragrafi successivi
verra' spiegato piu' esattamente il significato di questi due valori;
- La quarta colonna (rosa) determina il next-hop ovvero a chi deve essere inoltrato il
pacchetto per raggiungere la destinazione indicata nella seconda colonna. Nel caso in cui il
next-hop sia un indirizzo IP e non vi sia indicazione d’interfaccia (come nel caso dalla
penultima riga in figura 1) si avra' una chiamata ricorsiva nella tabella di routing (che in
figura 1 portera' all'interfaccia Ethernet0 nel caso della rete di destinazione 151.117.6.0)
fino all'ottenimento di un'interfaccia fisica. Ad esempio se si vuole raggiungere l'indirizzo
151.117.6.2 il next-hop e' 192.168.30.2. Con una chiamata ricorsiva si individua la rete
192.168.30.0 e quindi il next-hop finale cioe' l'Ethernet0;
- La quinta colonna (nero) , presente nel caso di routing dinamico, indica l'eta’ della
route. Alcuni protocolli di routing dinamico come OSPF e EIGRP permettono a questa di
crescere, altri invece ne azzerano periodicamente il valore come RIP (ogni 30 secondi di
default) o IGRP (ogni 90 secondi di default). Nella figura 1 l'ultima riga ne e' un esempio.
La trattazione dei protocolli di routing dinamico e' piu' avanti in questa trattazione.
Pertanto, l'idea piu' semplice e' fare una o piu' ricerche (look up) nella RIB per
individuare la destinazione di ciascun pacchetto che transita nel router.
La distanza amministrativa

La distanza amministrativa e' un numero compreso tra 0 e 255. Questo parametro

permette di associare un valore di peso, o di importanza ad ogni informazione di routing.
L'informazione di routing, proveniente da varie fonti come gli algoritmi di routing dinamico
e la configurazione dei router, ha necessita' di una priorita' in quanto di fatto non tutte le
informazioni hanno il medesimo valore e, in molti casi, vi sono piu' indicazioni differenti
per raggiungere la medesima destinazione, provenienti da fonti diverse, quindi bisogna
scegliere la migliore.
Poiche' solo le informazioni 'migliori' e non duplicate vanno inserite nella tabella di
routing (a meno di forzature imposte dal file di configurazione) e' necessario un processo
di selezione. La AD consente di risolvere questo tipo di conflitti. La AD usa un algoritmo
per il processo di selezione.
La regola e' che ha priorita' maggiore la route che possiede un valore piu' vicino allo
zero mentre ha priorita' minore chi ha un valore piu' alto ma comunque minore di 255.
Allora una AD pari a 255 indica una riga di routing che verra' sempre scartata nel
confronto con altre route di medesima destinazione. D'altra parte una AD pari a zero
dara' precedenza ad una route su tutte le altre con analoga destinazione. I valori di AD
sono preassegnati e in generale sono modificabili dall'utente. Eccoli in figura 3.

Pagina 5
 Configurazione dei router Cisco

Connessa C AD pari a 0
Statica S AD pari a 1
RIP R AD pari a 120
IGRP I AD pari a 100
EIGRP D AD pari a 90 (interno)
EIGRP EX AD pari a 170 (esterno)
EIGRP D AD pari a 5 (summarization)
OSPF O AD pari a 110
EBGP B AD pari a 20
IBGP B AD pari a 200

Figura 3 - Valori di distanza amministrativa –

Cerchiamo di comprendere il criterio con il quale sono stati scelti questi valori. E'
evidente che un'interfaccia di un router direttamente connessa ad una rete ne determina
il percorso piu' breve ed efficiente per raggiungerla da cui una AD pari a zero. Una route
statica, ovvero presente nel file di configurazione e quindi forzata dall'operatore, avra'
un'alta priorita' e verra' subito le interfacce direttamente connesse con una AD pari ad
uno.
Per quanto riguarda le route dinamiche va valutato che tra gli algoritmi di routing i piu'
efficienti sono quelli che danno le informazioni piu' accurate per raggiungere una
destinazione e con tempo di convergenza minore pertanto le route provenienti da EIGRP
(un protocollo di routing dinamico proprietario Cisco) hanno priorita' maggiore di quelle
provenienti da IGRP (un protocollo meno preciso ma comunque ratificato da uno
standard) mentre priorita' piu' bassa e' data al RIP che ha numerose limitazioni come
l'impossibilita' di propagare informazioni sulle netmask delle route o di funzionare gia' su
reti medie (il meno efficiente in assoluto a meno di non usare RIPv2).
Vanno trattati separatamente OSPF e BGP che non sono utilizzati negli stessi ambiti di
RIP o IGRP o EIGRP ma su reti di grandi dimensioni. In genere in una internetwork RIP,
IRGP e EIGRP operano all'interno di WAN medio/piccole mentre OSPF/BGP vanno sul
medio/grande. Solo reti medio/grandi utilizzano OSPF (sull'ordine del centinaio di router)
pertanto le route provenienti da OSPF o BGP non sono normalmente confrontate con
quelle degli altri algoritmi perche' operano in punti differenti della rete.
EBGP viene utilizzato per collegare reti di scala ancora superiore rispetto OSPF. BGP e'
pensato per scambiare informazioni tra operatori differenti, con reti gestite da diverse
organizzazioni, e si utilizza normalmente su internet per scambiare informazioni di routing
di diversi operatori. Se un router ha una sessione EBGP aperta riceve informazioni per
raggiungere reti non presenti nell'unita' amministrativa dove si trova (che in genere
contiene un numero significativo di router). Siamo certi che queste informazioni hanno
priorita' superiore a qualsiasi algoritmo di routing locale e quindi l'AD di EBGP e' la piu'
bassa tra tutti gli algoritmi di routing dinamico.
La metrica

Abbiamo ormai compreso che l'AD e' una misura del 'valore' di una riga di routing e che
e' stabilita secondo parametri oggettivi e generali non basati sulle caratteristiche
specifiche di una rete ma piuttosto sull'efficienza e le finalita' dei vari protocolli di routing.
La metrica invece e' una misura del valore di una route determinata a partire da alcune
caratteristiche fisiche specifiche della rete su cui si opera. Queste ultime sono l'hop count
per il RIP, ovvero il numero di router da attraversare per raggiungere una determinata
destinazione, il delay e bandwidth per IGRP e EIGRP che misurano invece l'ampiezza di

Pagina 6
 Configurazione dei router Cisco

banda e il ritardo di propagazione per raggiungere una determinata destinazione. Questi

parametri inseriti in delle formule creano le metriche composte che sono una specifica di
ogni algoritmo di routing dinamico e che forniscono il numero da associare alla riga di
route.
Basandosi sull'hop-count l'algoritmo RIP considera piu' efficiente il percorso con il
numero minore di router (un hop e' un passaggio cioe' normalmente un router) tra una
sorgente e una destinazione. IGRP e EIGRP invece non considerano il numero di hop per
andare ad esempio da A a B ma piuttosto i ritardi di propagazione dei vari router sul
percorso (delay) e la capacita' di banda dei vari link (bandwidth). I valori di metrica sono
valutati nel processo di selezione solo a parita' di AD e ora il motivo e' evidente: non ha
senso confrontare metriche provenienti da algoritmi di router distinti in quanto sono
valori numerici calcolati con formule diverse e quindi non confrontabili. A parita' di AD
invece si opera nell'ambito dello stesso algoritmo pertanto i dati sono confrontabili.
E' evidente anche perche' la AD ha priorita' sulla metrica nel processo di selezione del
percorso migliore, in quanto prima bisogna raggruppare le differenti route per AD. Ad
esempio le route fornite da un processo IGRP hanno priorita' su quelle provenienti da un
processo RIP indipendentemente dai valori di metrica in quanto le informazioni che
fornisce IGRP hanno un "valore" maggiore rispetto a quelle fornite dal RIP. In un contesto
in cui vi sono due percorsi, per raggiungere, ad esempio, un router B da un router A, di 2
e 3 hop rispettivamente, RIP darebbe priorita' al primo percorso anche nel caso in cui
fosse costituito da link con poca banda e alti delay mentre scarterebbe il secondo
percorso perche' piu' lungo anche se costituito da link con grande ampiezza di banda e
bassi delay, e pertanto migliore.
L'algoritmo di routing

Di tutte le righe di routing che arrivano ad un router, nella RIB entreranno solo quelle
che vincono la selezione con la distanza amministrativa e la metrica. Ma non solo.
Gli algoritmi RIP e IGRP non conservano (tranne dal 12.0 per il RIP) nessuna delle
informazioni scartate e quindi non inserite nella tabella di routing per motivi di AD o
metrica. Pertanto tutto cio’ che proviene dai vicini e non entra nella tabella di routing
viene perduto. OSPF e EIGRP conservano invece anche parte delle informazioni non
inserite in tabella di routing e si vedra’ che questo e’ il loro segreto per la veloce
convergenza in quanto le informazioni scartate sono determinanti in caso di guasti di rete
e quindi nella ricerca di percorsi alternativi.
Abbiamo scritto che le route vengono scartate confrontandone le AD e le metriche a
parita’ di AD. Esaminiamo adesso qualche caso particolare.
Cosa accade quando vi sono due righe di routing dove la prima e' un sottoinsieme
dell’altra? Cosa scegliere tra 172.43.0.0 e 172.43.20.0 quando la destinazione e'
172.43.20.23? Questa domanda e' di fondamentale importanza ed e' importante averne
la risposta che e' data dalla regola del "longest match rule". La risposta e' che ha
priorita' la rete di destinazione che ha piu' bit in comune con l'indirizzo di
destinazione. In questo caso 172.43.20.0. Ovvero il routing piu' specifico vince sul piu'
generico. Si consideri la seguente tabella di routing:

Router#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR

Pagina 7
 Configurazione dei router Cisco

P - periodic downloaded static route

Gateway of last resort is not set

116.0.0.0/24 is subnetted, 1 subnets

C 116.30.40.0 is directly connected, ATM0
C 192.168.30.0/24 is directly connected, Ethernet0
151.117.0.0/16 is variably subnetted, 2 subnets, 2 masks
S 151.117.0.0/16 [1/0] via 192.168.30.3
S 151.117.6.0/24 [1/0] via 192.168.30.2

Figura 4 - Output del comando 'show ip route'

Qual’e la scelta per 151.117.6.5? La risposta e’, per la regola del longest-match, ‘via
192.168.30.2’.
Nel caso di 151.117.8.0? Si andra' via 192.168.30.3. Per la destinazione 151.116.5.0?
In quest'ultimo caso il router SCARTA il pacchetto! Ecco nel dettaglio cosa succede:

Router#show ip route 151.117.6.5

Routing entry for 151.117.6.0/24
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 192.168.30.2
Route metric is 0, traffic share count is 1

Router#show ip route 151.117.8.0

Routing entry for 151.117.0.0/16
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 192.168.30.3
Route metric is 0, traffic share count is 1

Router#show ip route 151.116.5.0

% Network not in table

Figura 5 - Visualizzare percorsi di routing specifici

Concentriamo la nostra attenzione sull'ultimo caso. Ecco cosa succede provando un ping
verso un elemento della classe 151.116.5.0:

Router#ping 151.116.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 151.116.5.1, timeout is 2 seconds:
01:33:26: IP: s=192.168.30.1 (local), d=151.116.5.1, len 100, unroutable
01:33:26: ICMP type=8, code=0.
...
Success rate is 0 percent (0/5)

Figura 6 - Ping per destinazioni non in tabella di routing

Aggiungiamo nella configurazione una riga di routing aggiuntiva. Una route di default,
ovvero una destinazione di default in cui ricadranno tutte le reti di destinazione non
presenti in tabella di routing:

ip route 0.0.0.0 0.0.0.0 192.168.30.2

e riproviamo:

Router#ping 151.116.5.1
Type escape sequence to abort.

Pagina 8
 Configurazione dei router Cisco

Sending 5, 100-byte ICMP Echos to 151.116.5.1, timeout is 2 seconds:

01:36:35: IP: s=192.168.30.1 (local), d=151.116.5.1 (Ethernet0), len 100, sending
01:36:35: ICMP type=8, code=0.
...

Figura 7 - Ping per destinazione con routing di default

Questa volta il pacchetto e' partito, grazie sempre alla regola del longest-match. Infatti
nella peggiore delle ipotesi un pacchetto fara' matching con 0.0.0.0. Cosi' abbiamo
definito quello che si chiama gateway di default con la riga "ip route 0.0.0.0 0.0.0.0
192.168.30.2". Allora 192.168.30.2 sara' per noi un gateway ovvero un router che si
presume essere in possesso delle informazioni necessarie per raggiungere tutte le
destinazioni cercate (ad esempio un router che accede ad Internet).
La regola del longest-match non funziona in un solo caso indicato dalla seguente regola:
"quando una parte di una major network e' conosciuta, i pacchetti per la parte
restante sono scartati". Per capire il significato di questa seconda regola cancelliamo
dalla nostra tabella di routing il riferimento a 151.116.0.0, ma conserviamo il routing di
default:

Router#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 192.168.30.2 to network 0.0.0.0

116.0.0.0/24 is subnetted, 1 subnets

C 116.30.40.0 is directly connected, ATM0
C 192.168.30.0/24 is directly connected, Ethernet0
151.117.0.0/24 is subnetted, 1 subnets
S 151.117.6.0 [1/0] via 192.168.30.2
S* 0.0.0.0/0 [1/0] via 192.168.30.2

Figura 8 - Longest-match rule

Secondo quanto affermato in precedenza un riferimento alla rete 151.117.7.0 dovrebbe,
per la regola del longest-match portarci alla route di default. Ma 151.117 e' una rete di
classe B, che il router ritiene di gestire per intero come indicato nella riga
"151.117.0.0/24 is subnetted". Ecco cosa succede:

Router#ping 151.117.5.0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 151.117.5.0, timeout is 2 seconds:

01:43:11: IP: s=192.168.30.1 (local), d=151.117.5.0, len 100, unroutable

01:43:11: ICMP type=8, code=0.

Figura 9 - Ping e longest-match rule

La regola del longest-match funziona quando la classe della rete di destinazione non e'
conosciuta dal router. Questo perche' il router fa distinzione tra le classi di indirizzamento
A, B, C, D. In altri termini si suole dire che il router lavora in modalita' "classfull" ovvero il

Pagina 9
 Configurazione dei router Cisco

router distingue le classi come appartenenti ai gruppi A, B, C, D. Pertanto se un indirizzo

appartiene ad una classe sconosciuta si va verso il default route ma se una subnet di una
classe e' conosciuta le altre subnet, se non presenti, non usano la longest-match.
Il Classful addressing (Class A, Class B, Class C, etc) oramai non e' piu' in uso nella rete
Internet. Fortunatamente c'e' una via di uscita a questa limitazione. Si puo' passare
dall'ambiente "classfull" alla modalita' "classless" disabilitando il controllo sulle classi
(attivo di default in molte versioni di IOS) con il comando "ip classless". Dopo averlo
inserito, la tabella di routing non cambia nei contenuti, ma la regola del longest-match ha
un'applicazione piu' estesa.

Router#ping 151.117.5.0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 151.117.5.0, timeout is 2 seconds:

01:47:40: IP: s=192.168.30.1 (local), d=151.117.5.0 (Ethernet0), len 100, sending

01:47:40: ICMP type=8, code=0
.

Figura 10 - Ping nel caso di reti classless

Quindi con i comandi "ip classless" e "ip route 0.0.0.0 0.0.0.0 A.B.C.D" siamo sicuri che
il router provera' sempre a consegnare i pacchetti giunti da una delle sue interfacce e che
non li scartera'. Ovviamente, a meno di non avere reti connesse ad Internet, lo scarto dei
pacchetti con destinazioni inesistenti e' la normalita'. Quindi ricordiamoci che:

Router#show ip route 18.181.0.31

% Network not in table

Figura 11 - Network not in table -

non vuol dire necessariamente che il router scarta il pacchetto.
Per vedere la scelta di routing per una determinata destinazione anche quando la
destinazione non e' presente esplicitamente nella tabella di routing si puo' usare il
comando "show ip route A.B.C.D longer-prefixes"
€€
Il routing di default

La gestione del routing di default e' abbastanza articolata. Inserire un "ip route 0.0.0.0
0.0.0.0 serial0" non sempre porta ai risultati sperati. Un esempio e’ stato analizzato nel
paragrafo precedente in un ambiente classful. Il principio di funzionamento del default
route si basa sulla regola del longest match: se una destinazione non fa match non nulla
lo fara’ con la classe 0.0.0.0. In alcuni casi particolari il motore di routing ip di un router
puo' essere disabilitato, con il comando "no ip routing".
Il comando "ip routing" che abilita o disabilita il motore di routing IP. Normalmente e'
abilitato di default ma in alcuni casi non e' utilizzabile. Ad esempio se ci troviamo nell'IOS
in modalita' boot mode (ad esempio sulla vecchia serie Cisco 2500) il motore di routing
potrebbe non essere attivabile (col comando "ip routing”) impedendo il raggiungimento
magari di un server TFTP. Il comando "ip default-gateway xx.xx.xx.xx" consente di
indicare un gateway di default senza l'utilizzo del motore di routing di IOS e risolve casi
come questo.
In circostanze piu' comuni l'unica alternativa utile a "ip route 0.0.0.0 0.0.0.0 A.B.C.D"
e' il comando "ip default-network xx.xx.xx.xx". Indicando una rete di default, e non

Pagina 10
 Configurazione dei router Cisco

un indirizzo ip, l'effettivo gateway di default cambiera’ dinamicamente insieme alla route
che conduce alla rete A.B.C.D . Bisogna fare molta attenzione al fatto che questo
comando in generale e’ classful (dipende dall'IOS). Ad esempio "ip default-network
151.97.0.0" e' corretto ma "ip default-network 151.97.10.0" potrebbe essere errato.
Tuttavia normalmente (dipende dalla versione di IOS) quando si introduce una sottorete il
router automaticamente crea una routing statica per la rete classless. Il router poi
cerchera' nella sua tabella di routing come raggiungere 151.97.10.0 e, non appena
trovata la migliore subnet, considerera' quella come default.
Questo metodo e' il piu' robusto per configurare il routing di default in quanto, a parte
che con piu' comandi di questo genere si possono scegliere dei percorsi di back-up, la
caduta di un gateway in una rete a maglia consente ancora di raggiungere comunque
‘l'uscita’.
Quando si utilizzano protocolli di routing dinamico la route di default viene gestita
differentemente, in base al protocollo utilizzato. In presenza della route di default: "ip
route 0.0.0.0 0.0.0.0 A.B.C.D" si ha propagazione senza problemi solo dal RIP ma
attenzione, dalle versioni 12.0T dell'IOS anche il RIP non lo rileva e bisogna utilizzare il
comando “default-information originate”. EIGRP e IGRP distribuiscono la route di
default nel caso di ridistribuzione delle statiche o se si usa "ip default-network" (con il
comando "redistribute static" presente oltretutto anche in RIP, IGRP, OSPF, EIGRP).
Con IGRP e EIGRP, con il comando “ip default-network”, si ha la propagazione purche’ la
rete di destinazione partecipi al routing dinamico. In presenza di piu' comandi 0.0.0.0 con
la stessa AD il router fa bilanciamento di carico (vedi paragrafi successivi) . In presenza di
piu' comandi default-network sceglie quello con AD piu' bassa. In caso di entrambi i
metodi a precedenza quello con AD piu' bassa (in genere 0.0.0.0 perche' e' una statica)
che capita per default-network se viene associato con una statica.
Ricordo che per far funzionare correttamente il default gateway si deve usare il
comando "ip classless". Questo perche' quando un router cerchera' nella tabella di routing
una net non presente, anche nel caso di subnet della classe propagata, ci sara' sempre
una direzione per il pacchetto piuttosto che uno scarto. Senza "ip classless" il routing di
default funzionerebbe solo all'esterno delle classi routate e quindi andrebbe verificata la
continuita' di subnet nella tabella di routing per non lasciare mai nessuno isolato (cosa che
puo’ essere spiacevole in casi di redistribuzione da VLSM a FSLM e viceversa).

Configurazione di interfacce WAN

UNDER CONSTRUCTION
Configurazione di interfacce Frame-Relay

UNDER CONSTRUCTION
Configurazione di interfacce ADSL

UNDER CONSTRUCTION
Diverse tipologie di ADSL

UNDER CONSTRUCTION
ADSL di tipo PPPoA

UNDER CONSTRUCTION

Pagina 11
 Configurazione dei router Cisco

ADSL di tipo PPPoE

UNDER CONSTRUCTION
Gli algoritmi di switching: fast-switching e CEF

L'algoritmo che invia il pacchetto e quindi che, data la destinazione, trova l'interfaccia
fisica corrispondente il piu' rapidamente possibile e' lo "switching". L'algoritmo di routing
dei paragrafi precedenti va affiancato ad un'efficiente algoritmo di switching che
determina la velocita' del router. Se per ogni pacchetto in transito il router dovesse
andare a visionare l'intera tabella di routing ricorsivamente per decidere il next-hop allora
il processo di routing sarebbe lento. Il router genera allora una o piu' tabelle aggiuntive
per permettere lo switching dei pacchetti, ovvero il loro passaggio da una interfaccia ad
un'altra possibilmente con un solo lookup e senza ricorsione. Il piu' semplice algoritmo di
switching e' il "process switching" che consulta sempre la RIB per la ricerca
dell'interfaccia di uscita di un pacchetto.
Ci sono delle tecnologie di switching differenti per velocizzare la scelta del next-hop, con
la creazione di tabelle efficienti che consentono una piu' rapida selezione del percorso. Vi
sono insomma differenti "tecnologie di switching" che utilizzano delle strutture in
memoria per velocizzare lo switching. Invece del process switching nell'ultimo decennio
si e' utilizzato molto il fast-switching e adesso si va verso l'uso esclusivo del cisco
express forwarding (CEF) introdotto con IOS 11.1. Il fast switching dovrebbe essere
ufficialmente rimosso a partire dal Cisco IOS 12.4(20)T. Pertanto si dovra' acquisire
dimestichezza con il CEF necessariamente.
Infine esiste il distributed CEF (DCEF) utilizzabile in alcuni router modulari di fascia alta
dove i singoli moduli hanno una copia della FIB e quindi possono fare switching in
autonomia senza scomodare il processore del router se non quando necessario. Ad
esempio la piattaforma Cisco Catalyst 6500/7600 di switch router supporta il DCEF se
equipaggiata con schede con modulo DFC e supervisor 720 o un modulo chiamato "switch
fabric". Infatti sia la scheda processore che gli altri moduli devono supportare il DCEF. E'
ovvio che con DCEF le prestazioni salgono considerevolmente.
Fast-switching

Il fast-switching utilizza una route cache dove si crea una nuova entry quando un primo
pacchetto con una specifica destinazione viene esaminato dall'algoritmo di routing. La
tabella di routing viene esaminata, ricorsivamente se necessario, e il next-hop viene
inserito nella cache. In questo modo le richieste successive di switching per la stessa
destinazione saranno piu' rapide perche' non sara' piu' necessario consultare la tabella di
routing.
Il fast switching si attiva introducendo il comando "ip route-cache" nelle interfacce del
router e spesso e' attivo di default. Ecco come vedere la cache del fast switching:

giagw#show ip cache
IP routing cache 886 entries, 156592 bytes
3126929 adds, 3126043 invalidates, 0 refcounts
Minimum invalidation interval 2 seconds, maximum interval 5 seconds,
quiet interval 3 seconds, threshold 0 requests
Invalidation rate 0 in last second, 0 in last 3 seconds
Last full cache invalidation occurred 5w6d ago

Prefix/Length Age Interface Next Hop

10.0.0.0/8 00:01:18 FastEthernet0/0 192.168.21.1
24.0.0.0/8 00:38:54 Di2 24.203.217.164
38.0.0.0/8 00:17:53 Di1 38.103.164.171

Pagina 12
 Configurazione dei router Cisco

41.0.0.0/8 00:53:30 Di2 41.201.65.129

58.0.0.0/8 00:17:13 Di1 58.39.0.125
59.0.0.0/8 00:16:17 Di1 59.112.208.172
...

giag#show ip cache verbose

IP routing cache 1592 entries, 255208 bytes
1059998 adds, 1058406 invalidates, 0 refcounts
Minimum invalidation interval 2 seconds, maximum interval 5 seconds,
quiet interval 3 seconds, threshold 0 requests
Invalidation rate 0 in last second, 0 in last 3 seconds
Last full cache invalidation occurred 1w0d ago

Prefix/Length Age Interface Next Hop

24.0.0.0/8-0 00:05:44 Se1/1/0 24.222.0.94
4 0F000800
41.0.0.0/8-0 00:21:58 Se0/1/0 41.248.245.159
4 0F000800
58.0.0.0/8-0 00:05:03 Se0/1/0 58.9.203.124
4 0F000800
...

Figura 12 - Cache nel fast switching

Le limitazioni del fast-switching sono risolte dal CEF. La route-cache del process
switching puo' diventare molto grande e non e' in relazione con la tabella ARP ovvero, se
una entry diventa non valida nella tabella ARP non c'e' modo di invalidare la cache. Per
risolvere questo problema nel caso di fast-switching 1/20mo (casuale) della cache viene
invalidata ogni minuto. Il CEF considera anche l'utilizzo delle connessioni durante il tempo
e quindi gestisce in modo piu' efficente la sua cache.
Il fast-switching utilizza la route-cache, il CEF utilizza una FIB (forwarding Information
Base) insieme ad una tabella di adiacenza che contiene le informazioni di layer 2
associate ai next-hop. La FIB riflette il cambiamento della RIB in tempo reale, e cosi' si
evitano le operazioni di manutenzione della route-cache necessarie al fast-switching. La
tabella di adiacenza contiene le informazioni di layer 2 per le destinazioni raggiungibili
attraverso un singolo hop. L'utilizzo del CEF implica meno risorse di processore rispetto al
fast-switching. Con il comando 'show interfaces stats' potete verificare quanti pacchetti
sono 'process switched' e quanti 'fast-switched o cef switched'. Con il fast switching ci puo'
essere un consumo di processore anche 10 volte superiore rispetto al CEF.

giagw#show interfaces stats

FastEthernet0/0
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 55 7894 88 8930
Route cache 23437 11588528 20682 3246212
Total 23492 11596422 20770 3255142
FastEthernet0/1
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 111 8013 74 12347
Route cache 20428 3256819 23183 11543634
Total 20539 3264832 23257 11555981

L'attivazione del CEF in una interfaccia non disabilita necessariamente il fast-switching.

Questo perche' parte del traffico non utilizza il CEF, ad esempio quello cryptato o i
broadcast o quelli per cui non c'e' una entry nella tabella CEF.

ITESYS-1800#show ip interface fastEthernet 0/0

Pagina 13
 Configurazione dei router Cisco

FastEthernet0/0 is up, line protocol is up

Internet address is 192.168.50.1/24
...
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF Feature Fast switching turbo vector
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
...
IP route-cache flags are Fast, CEF

Figura 13 - CEF e fast switching

CEF

Il CEF si abilita con il comando "ip cef" in global configuration mode. Il CEF utilizza
anch'esso le sue tabelle:€

gia#show adjacency
Protocol Interface Address
IP FastEthernet0/1 173.16.0.191(5)
IP FastEthernet0/1 173.16.0.185(5)
...

gian#show ip cef
Prefix Next Hop Interface
0.0.0.0/0 attached Serial0/0/0.1
0.0.0.0/32 receive
10.0.3.0/24 attached Tunnel13
10.0.4.0/24 attached Tunnel12
10.1.1.0/24 attached Tunnel6

Figura 14 - CEF: i comandi 'show adjacency' e 'show ip cef'

La tabella delle adiacenze viene costruita a partire dalla tabella ARP e indica l'interfaccia
di uscita per un prefisso. Non appena cambia una entry nella tabella ARP la tabella di
adiacenze e la tabella del CEF sono immediatamente aggiornate.

IOS utilizza CEF se questo e' abilitato sull'interfaccia di ingresso del pacchetto. Se cosi'
non e', il router utilizzera' la configurazione nell'interfaccia d'uscita per stabilire la
modalita' di switching. Allora se c'e' fast-switching nell'interfaccia d'ingresso allora si
utilizzera' questo anche se c'e' il CEF in quella d'uscita.
In una interfaccia possono essere abilitati contemporaneamente piu' metodi di
switching. Per verificare il tipo di switching attivo utilizzate il comando "show ip interface
...". Esiste una priorita' del CEF su fast-switching e poi sul process-switching. Nella figura
che segue si vede come interrogare le tabelle di fast-switching e quindi CEF.€

gia#show ip cache 61.0.0.0 255.0.0.0

IP routing cache 30 entries, 5640 bytes
7921 adds, 7891 invalidates, 0 refcounts
Minimum invalidation interval 2 seconds, maximum interval 5 seconds,
quiet interval 3 seconds, threshold 0 requests
Invalidation rate 0 in last second, 0 in last 3 seconds
Last full cache invalidation occurred 6d19h ago

Prefix/Length Age Interface Next Hop

Pagina 14
 Configurazione dei router Cisco

61.0.0.0/8 00:11:18 Serial0/0/0.1 61.139.54.94

gian#show ip cef 61.0.0.0

0.0.0.0/0, version 406, epoch 0, attached, cached adjacency to Serial0/0/0.1
0 packets, 0 bytes
via Serial0/0/0.1, 0 dependencies
valid cached adjacency

Figura 15 - CEF: esempi di 'show ip cache' e comando 'show ip cef '

Nota: con IPv6 non c'e' la modalita' fast-switching.

Switching ad alte prestazioni: piattaforme Catalyst 6500, Cisco 7600

Il CEF viene realizzato in hardware nelle piattaforme Cisco di fascia alta. Per capire
come funziona e' bene capire cosa si nasconde dietro due sigle: CAM e TCAM. TCAM vuol
dire Ternary Content Addressable Memory.
Si tratta di chip di memoria a cui si fornisce un valore e che restituiscono i posti dove e'
memorizzato quel valore. Sono ideali in contesti dove bisogna fare rapidamente delle
ricerce, da cui l'applicazione in router e switch che devono, con la massima rapidita',
sapere dove mandare un pacchetto dato l'indirizzo di destinazione.
Mentre la CAM in input puo' avere 0 o 1, una TCAM puo' avere tre valori: 0,1,X. La 'X'
indica un valore qualsiasi ed e' l'ideale per gestire le netmask.
Allora fornendo un MAC address in binario ad una CAM potremmo avere in risposta la
porta dello switch dove inviare il pacchetto e altre informazioni, come la VLAN. Come si
capisce e' il principio di funzionamento di uno switch in layer 2. Infatti tutti gli switch Cisco
Catalyst hanno una memoria CAM.
Allora fornendo una network ad una TCAM questa restituisce il next-hop ed e' l'ideale per
uno switch in layer 3. Lo switching in hardware, effettuato mediante chip ASIC, nasce con
gli switch layer 2 e si evolve per gli switch layer 3. Ad esempio la serie di router Cisco
7500 faceva switching in software. La serie Cisco 7600 invece usa l'hardware, in quanto
ha lo stesso route processor della serie Catalyst 6500.
CAM e TCAM sono utilizzate anche per le access control list (ACL) e permettono una
velocita' di gestione a line rate (ovvero alla stessa velocita' delle porte dello switch).
Nel momento della stesura di questo articolo le piattaforme WAN Cisco per applicazioni
di fascia medio/alta sono la serie Cisco 6500 e la Cisco 7600, gia' citate. Si tratta di
piattaforme modulari estremamente flessibili e performanti. Queste piattaforme fanno
switching utilizzando una TCAM che memorizza la tabella CEF.
Queste piattaforme sono estremamente modulari e nel route processor, che si chiama
supervisor, hanno una scheda figlia di Policy Feature Card (PFC). Questa contiene la
memoria TCAM. La tecnologia Multilayer Switch (MLS) e quella che effettua lo switch in
hardware. MLS e' un termine nato per i catalyst per denotare la tecnologia che permette
routing e switching in hardware. Le piattaforme attuali utilizzano il CEF con MLS.
Piattaforme piu' vecchie utilizzavano MLS differentemente (vedi catalyst 5000) ma non
verranno trattate in questo documento.
Nella piattaforma Cisco 6500/7600 la CEF FIB viene preparata in software dalla scheda
MSFC della supervisor il quale scarica nel modulo PFC che contiene la memoria TCAM.
Fino alla versione PFC3B vi e' un limite di 256k prefissi IPV6. Dalla versione PFC3BXL e'
stata aumentata la capacita' della TCAM per contenere fino a 1 milione di prefissi IPV4. E'
molto interessante notare, per chi usa il protocollo BGP, che nel 2007 il numero di route

Pagina 15
 Configurazione dei router Cisco

mondiali ha superato la soglia dei 256k. Quando la TCAM non e' in grado di contenere
tutti i prefissi l'eccedenza viene gestita in software. Attualmente, Agosto 2009, la tabella
BGP mondiale ha circa 290000 entry.
Ovviamente MLS e' attivo di default in ogni caso con "no mls ip" si puo' disabilitare ma
difficilmente utilizzerete questo comando.
Vediamo un esempio di TCAM piena. Questo catalyst 6500 ha una tabella BGP con
290000 entry e una PFC3B. Come vedete risultano 262144 entries nella TCAM, e
mancano route:

catagia#show mls cef hardware

CEF TCAM v2:

Size: 262144 entries
65536 rows/device, 4 device(s)
32 entries/mask-block
8192 total blocks (32b wide)
1212416 s/w table memory

catagia#show mls cef maximum-routes

FIB TCAM maximum routes :
=======================
Current :-
-------
IPv4 + MPLS - 192k (default)
IPv6 + IP Multicast - 32k (default)

Figura 16 - Comando 'show mls cef hardware'

Il problema e' segnalato con il messaggio "FIB is in exception state" come in figura:

giacat#show mls cef

Codes: decap - Decapsulation, + - Push Label

***** FIB is in exception state for IPv4 unicast *****
Index Prefix Adjacency

73 192.168.79.255/32 receive
74 192.168.72.180/32 Gi5/3 , 0011.43e4.3648
75 192.168.72.67/32 Gi5/3 , 0050.56b5.2b19
76 192.168.74.142/32 Gi5/3 , 001a.9224.001b
77 192.168.74.201/32 Gi5/3 , 0050.56b5.04ccgiacat#show mls cef detail

Codes: M - mask entry, V - value entry, A - adjacency index, P - priority bit

D - full don't switch, m - load balancing modnumber, B - BGP Bucket sel
V0 - Vlan 0,C0 - don't comp bit 0,V1 - Vlan 1,C1 - don't comp bit 1
RVTEN - RPF Vlan table enable, RVTSEL - RPF Vlan table select
***** FIB is in exception state for IPv4 unicast *****
Format: IPV4_DA - (8 | xtag vpn pi cr recirc tos prefix)
Format: IPV4_SA - (9 | xtag vpn pi cr recirc prefix)
M(64 ): E | 1 FFF 0 0 0 0 255.255.255.255
V(64 ): 8 | 1 0 0 0 0 0 0.0.0.0 (A:14 ,P:1,D:0,m:0 ,B:0 )
M(65 ): E | 1 FFF 0 0 0 0 255.255.255.255
V(65 ): 8 | 1 0 0 0 0 0 255.255.255.255 (A:14 ,P:1,D:0,m:0 ,B:0 )
M(71 ): E | 1 FFF 0 0 0 0 255.255.255.255
V(71 ): 8 | 1 0 0 0 0 0 192.168.72.1 (A:14 ,P:1,D:0,m:0 ,B:0 )
M(72 ): E | 1 FFF 0 0 0 0 255.255.255.255
V(72 ): 8 | 1 0 0 0 0 0 192.168.72.0 (A:14 ,P:1,D:0,m:0 ,B:0 )
M(73 ): E | 1 FFF 0 0 0 0 255.255.255.255

Pagina 16
 Configurazione dei router Cisco

V(73 ): 8 | 1 0 0 0 0 0 192.168.79.255 (A:14 ,P:1,D:0,m:0 ,B:0 )

M(74 ): E | 1 FFF 0 0 0 0 255.255.255.255
V(74 ):8 | 1 0 0 0 0 0 192.168.72.180 (A:147456 ,P:1,D:0,m:0 ,B:0 )
M(75 ):E | 1 FFF 0 0 0 0 255.255.255.255

giacat#show mls cef adjacency entry 147456

Index: 147456 smac: 0009.1182.6900, dmac: 0011.43e4.3648

mtu: 1518, vlan: 1024, dindex: 0x0, l3rw_vld: 1
packets: 0, bytes: 0

Figura 17 - Comando 'show mls cef'

Nella figura vediamo anche i comandi per vedere il contenuto del CEF in hardware. Nella
parte in neretto vedete che, per l'indirizzo 192.168.72.180 c'e' una entry nella tabella
delle adiacenze per il mittente e il destinatario. Infatti di default i flussi vengono definiti
sia dal mittente che dal destinatario. Il flusso e unidirezionale pertanto una comunicazione
tra A e B genera due flussi.
Il bilanciamento di carico nel fast-switching

Un caso ancora non trattato si ha in presenza di piu' route identiche con medesima AD e
metrica ma differente next-hop. Un caso particolarmente interessante e' quando nel file
di configurazione di un router inseriamo qualcosa del genere:

ip route 0.0.0.0 0.0.0.0 serial0

ip route 0.0.0.0 0.0.0.0 serial1€

Figura 18 - Bilanciamento di carico e route statiche

Le due route sono statiche e quindi hanno AD pari ad 1 e non hanno metrica. Quello che
accade e' che entrambe le righe di routing entrano in tabella di routing FIB come si puo'
vedere con "show ip route":

...
S* 0.0.0.0/0 is directly connected, Serial0
€€€€€€€€€€€€€is directly connected, Serial1
...

Figura 19 - Tabella di routing e bilanciamento di carico

In questo paragrafo si parte dal presupposto che si stia utilizzando il "fast-switching". In
questo caso con due righe di routing uguali il router fa un bilanciamento di carico per
destinazione. Con il "process switching" il bilanciamento di carico e' per pacchetto. Per
avere il fast swiching nelle interfacce coinvolte ci vuole esplicitamente il comando "no ip
route-cache cef" (specialmente in quelle di ingresso per i pacchetti) e "ip route-cache" nel
caso in cui nella configurazione del router sia abilitato il cef con il comando "ip cef".
I pacchetti IP che ricadono nella route di default verranno allora distribuiti in entrambe
le interfacce. Abbiamo capito che ci sono due modalita' per eseguire questa operazione:
per destinazione, per pacchetto. Per destinazione vuol dire che tutto il traffico da un
mittente ad un destinatario ben preciso utilizza un solo percorso. Per pacchetto vuol dire
che i pacchetti sono equamente distribuiti tra i percorsi possibili ovvero nel nostro
esempio un primo pacchetto nella seriale0 e un secondo nella seriale1.
Anche se la distribuzione del traffico e' meno "equa" conviene spesso utilizzare la
distribuzione per destinazione. Infatti cambiare interfaccia puo' determinare una perdita

Pagina 17
 Configurazione dei router Cisco

di qualita' dovuta alla probabile differenza di latenza nei due possibili percorsi. Ad
esempio la VoIP trae svantaggio dalla consegna dei pacchetti fuori sequenza. In alcuni
contesti, come l'utilizzo del NAT distribuito tra due interfacce, la differenza dell'IP mittente
nel caso della distribuzione per pacchetto puo' rendere problematica la visualizzazione di
alcuni siti Internet, specialmente se si attraversano firewall o sono in SSL. Questo perche'
alcuni siti Internet, come l'home-banking, vedono i pacchetti provenire da due indirizzi IP
differenti, e interpretano questa cosa come un tentativo di violazione della sicurezza. Ma
cio' capita in alcune specifiche applicazioni. Inoltre nel caso di bilanciamento per
destinazione il router utilizza una cache pertanto lo switching e' piu' veloce ed efficiente
(vedi sotto)
Per scegliere la modalita' di distribuzione, nelle interfacce coinvolte vanno usati i
comandi ip route-cache nel caso di bilanciamento per destinazione (normalmente di
default nelle interfacce e quindi non visibile) oppure no ip route-cache nel caso di
bilanciamento per pacchetto (fast switching disabilitato) Ripeto: se il router e' in
modalita' route-cache si utilizza il fast-switching. In modalita' per pacchetto si deve
utilizzare il process-switching oppure if cef (vedi paragrafo successivo)
Il bilanciamento di carico con CEF

Utilizzando CEF si puo' fare load balancing sia per-destination che per-packet. Il load-
balancing per destinazione e' piu' efficiente del fast-switching in quanto CEF considera
mittente, destinatario e le porte mentre il fast switching solo la destinazione. Pertanto e'
un po' improprio chiamarlo "per destinazione".
Rispetto al fast-switching i comandi sono differenti. Innanzitutto assicuratevi che il CEF
sia attivo router globalmente con il comando "ip cef". Poi nelle interfacce coinvolte se non
e' di default inserite il comando "ip route-cache cef".
Nel momento in cui siete sicuri che il CEF e' abilitato nelle interfacce coinvolte
aggiungere piu' route statiche di egual peso per una stessa destinazione (che ovviamente
deve ricadere in una interfaccia con il CEF attivo). A questo punto abilitate, nelle
interfacce coinvolte il load-sharing per packet, con il comando "ip load-sharing per-
packet" oppure per destinazione, con il comando "ip load-sharing per-destination" .
Attenzione che in base alla piattaforma questi comandi possono essere o meno attivi di
default. Con il comando "show cef state" e "show cef interface" potete in ogni caso
essere sicuri che sia attivo.

gia#show cef interface gigabitEthernet 5/9

€ GigabitEthernet5/9 is up (if_number 12)
€ Corresponding hwidb fast_if_number 12
€ Corresponding hwidb firstsw->if_number 12
€ Internet address is 192.168.148.170/30
€ ICMP redirects are never sent
€ IP unicast RPF check is disabled
€ Output features: HW Shortcut Installation
€ …
€ Hardware idb is GigabitEthernet5/9
€ Fast switching type 22, interface type 146
IP CEF switching enabled
€ IP CEF switching turbo vector
€ IP Null turbo vector
€ IP prefix lookup IPv4 mtrie generic
€ Input fast flags 0x0, Output fast flags 0x0
€ ifindex 11(11)
€ Slot 5/0 (5) Slot unit 9 VC -1
€ Transmit limit accumulator 0x0 (0x0)
IP MTU 1500

Pagina 18
 Configurazione dei router Cisco

Figura 20 - Verifica dell'attivazione del CEF su un'interfaccia –

Ecco come appare nella tabella CEF una destinazione con due percorsi attivi:

gia#show ip cef
Prefix Next Hop Interface
...
3.0.0.0/8 192.168.148.169 GigabitEthernet5/9
192.168.150.137 GigabitEthernet6/9
...

Figura 21 - CEF e load-balancing

Di default il load-sharing e' attivo in modalita' "per-destination". Per capire se e' attiva la
modalita' per pacchetto potete utilizzare il comando "show ip cef DESTINAZIONE
detail". Con il comando "show ip cef ... internal" e' possibile avere tutti i dettagli su
ogni entry della tabella cef e sul load-balancing. Ad esempio, per la entry della figura di
cui sopra:

catalyst-primario#show ip cef 3.0.0.0 internal

3.0.0.0/8, epoch 8, flags rib only nolabel, rib defined all labels, RIB[B],
refcount 6, per-destination sharing
sources: RIB
feature space:
Broker: linked
IPRM: 0x00018000
ifnums:
GigabitEthernet5/9(12): 192.168.148.169
GigabitEthernet6/9(21): 192.168.150.137
path 5913A724, path list 524CDFC4, share 1/1, type recursive nexthop, for IPv4,
flags resolved
path 5913A140, path list 524CDC80, share 1/1, type recursive nexthop, for IPv4,
flags resolved
recursive via 192.168.148.169[IPv4:Default], fib 47550BE4, 1 terminal fib
path 5913A310, path list 524CE860, share 1/1, type adjacency prefix, for IPv4
attached to GigabitEthernet5/9, adjacency IP adj out of GigabitEthernet5/9, addr
192.168.148.169 5BE18080
path 5913632C, path list 524CDC80, share 1/1, type recursive nexthop, for IPv4,
flags resolved
recursive via 192.168.150.137[IPv4:Default], fib 5B7D5360, 1 terminal fib
path 59138270, path list 524CDDFC, share 1/1, type adjacency prefix, for IPv4
attached to GigabitEthernet6/9, adjacency IP adj out of GigabitEthernet6/9, addr
192.168.150.137 5BE14A80
output chain:
loadinfo 47513BDC, per-session, 2 choices, flags 0003, 281978 locks
flags: Per-session, for-rx-IPv4
16 hash buckets
< 0 > IP adj out of GigabitEthernet5/9, addr 192.168.148.169 5BE18080
< 1 > IP adj out of GigabitEthernet6/9, addr 192.168.150.137 5BE14A80
…
<12 > IP adj out of GigabitEthernet5/9, addr 192.168.148.169 5BE18080
<13 > IP adj out of GigabitEthernet6/9, addr 192.168.150.137 5BE14A80
<14 > IP adj out of GigabitEthernet5/9, addr 192.168.148.169 5BE18080
<15 > IP adj out of GigabitEthernet6/9, addr 192.168.150.137 5BE14A80
Subblocks:
None

Figura 22 - Dettaglio delle route nella tabella CEF

Le 16 righe indicate con "16 hash buckets" sono relative all'algoritmo di load-balancing
usato da CEF che qui non approfondiamo.

Pagina 19
 Configurazione dei router Cisco

E' possibile applicare il load-sharing anche per interfacce ethernet. Ad esempio si puo'
fare in modo che una interfaccia ethernet di partenza distribuisca il carico su due
interfacce di destinazione differenti (ovviamente la ethernet avra' piu' ip secondari).
Oppure si puo' fare in modo che per raggiungere una unica interfaccia ethernet di
destinazione si inviano i pacchetti da piu' interfacce ethernet sorgente. Ad esempio se
abbiamo un router con piu' ethernet a 100megabit che si deve interfacciare con un router
con una interfaccia gigabit ethernet. Infatti nelle righe di routing statico uguali ma con
destinazioni differenti non e' necessario che la destinazione sia una interfaccia fisica
(abbastanza ovvio nel caso di seriali) ma puo' essere anche un indirizzo ip (tipico nel caso
di interfacce ethernet). Sara' la ricorsione a decidere l'interfaccia di uscita e quindi, alla
fine, di usare il load-sharing.
Per il load-balancing "per-packet" si utilizza il comando "ip load-sharing per-packet".
Questa funzionalita' non e' sempre disponibile. Su alcune piattaforme e configurazioni non
e' utilizzabile.
Nella piattaforma Catalyst 6500/7600 il load-sharing e' limitato ad un massimo di 6
percorsi differenti. Viene realizzato considerando mittente, destinazione e porte. Questo
permette una buona distribuzione del traffico tra piu' link (a meno di non avere pochi
flussi).
Il bilanciamento di carico con interfacce di tipo dialer e backup

Nel caso di piu' interfacce di tipo dialer e di righe di routing del tipo:

ip route 0.0.0.0 0.0.0.0 dialer0

ip route 0.0.0.0 0.0.0.0 dialer1

Figura 23 - Statiche e bilanciamento di carico in interfacce Dialer

puo' accadere che entrambe le righe di routing restino in tabella di routing anche se una
delle due interfacce non e' funzionante. Questo perche' le interfacce dialer sono sempre
nello stato di "up". Semmai l'interfaccia "virtual-access" associata puo' essere presente o
meno a seconda di un collegamento presente o meno.
Questo puo' creare dei problemi rendendo difficoltosa la navigazione se uno dei due
collegamenti non funziona. Una soluzione e' questa:

track 10 interface Dialer0 ip routing

delay down 5 up 30
track 11 interface Dialer1 ip routing
delay down 5 up 30

ip route 0.0.0.0 0.0.0.0 Dialer0 track 10

ip route 0.0.0.0 0.0.0.0 Dialer1 track 11

1841-gia#sh track 10
Track 10
Interface Dialer0 ip routing
IP routing is Down (no ip addr)
1 change, last change 00:43:32
Delay up 30 secs, down 5 secs
Tracked by:
STATIC-IP-ROUTING 0

1841-gia#sh track 11
Track 11
Interface Dialer1 ip routing
IP routing is Up

Pagina 20
 Configurazione dei router Cisco

1 change, last change 00:43:33

Delay up 30 secs, down 5 secs
Tracked by:
STATIC-IP-ROUTING 0

Figura 24 - Dialer, load-balancing e comando track -

In questo esempio monitoriamo non lo stato del protocollo, ma il fatto che la dialer
abbia o meno un indirizzo IP. La dialer non avra' l'indirizzo IP se non riesce a negoziarlo,
anche se il protocollo e' up. In questo modo nella tabella di routing entra SOLO la riga di
routing relativa all'interfaccia UP.

Cisco Access-list

€€ Le access-list sono dei "filtri" che permettono di bloccare il passaggio di parte del traffico IP
rispondente a determinate caratteristiche. E' possibile filtrare il traffico in ingresso oppure in
uscita da una interfaccia. E' possibile filtrare il traffico in base all'indirizzo IP mittente o
destinatario, oppure in base alle porte TCP o UDP presenti. Ci sono due tipi principali di
access-list: standard e extended.
Le prime controllano solo l'ip mittente del pacchetto mentre con le seconde e' possibile
specificare protocollo, porte e ip mittente o destinatario. Le access-list vengono lette dall'alto
verso il basso finche' non si abbia un match con un permit o con un deny. Implicitamente c'e'
un deny any al termine di ogni access-list (non visibile nella configurazione). Con il comando
"ip access-group" si agganciano le access-list alle interfacce. Con il comando "access-list" si
configurano.

€€€ A partire dalla release 15.0 dell'IOS (anche dalla 12.4(4)T ma non e' consigliato) e' possibile
utilizzare efficacemente anche il Flexible Packet Matching (FPM), che rappresenta la nuova
generazione di ACL. Si configurano con le class-map. Non sono trattate in questo paragrafo.

Configurazione 1

!
interface Ethernet0/0
ip address 192.168.30.211 255.255.255.0
ip access-group 10 in <--- sono controllati i pacchetti in
INGRESSO alla ethernet
! <--- (ovvero quelli che 'provengono'
dal patch collegato)
!
!
!
access-list 10 deny 192.168.30.241 (*) <--- standard access-list (hanno
numerazione da 1 a 99)
access-list 10 permit any <--- 192.168.30.241 e' l'ip del
MITTENTE
!

Figura 25 - Access-list in ingresso

Risultato: dall'ip 192.168.30.241 non sara' possibile 'entrare' dalla ethernet0 (neanche
ping sulla stessa)
Configurazione equivalente:

Pagina 21
 Configurazione dei router Cisco

access-list 100 deny ip host 192.168.30.241 any <--- access-list estesa (hanno
numerazione da 100 a 199)
access-list 100 permit ip any any <--- 192.168.30.241 e' l'ip
del mittente

Figura 26 - Access-list in ingresso estesa

Configurazione non equivalente:

interface Ethernet0/0
ip address 192.168.30.211 255.255.255.0
ip access-group 100 out <--- out e' cio' che arriva
all'interfaccia eth dalle altre interfacce
! <--- del router (ovvero che ha
attraversato il router)
!
!
access-list 100 deny ip any host
192.168.30.241
access-list 100 permit ip any any

Figura 27 - Access-list in uscita

Qui dall'ip 192.168.30.241 sara' possibile attraversare il router, a differenza di prima in
quanto l'access-list in uscita considera i pacchetti in ingresso da tutte le altre interfacce del
router
Allora concludiamo che:
1) Le ACL in ingresso "in" hanno sorgente sull'interfaccia dove viene applicata e
destinazione di uscita su tutte le altre interfacce;
2) Le ACL in uscita "out" hanno sorgente su ogni interfaccia DIVERSA da quella a cui e
applicata e destinazione in uscita sull'interfaccia dove e' applicata.
Normalmente le access-list si mettono in ingresso. Infatti il principio e' di non far
attraversare il router dal traffico, e quindi usare risorse di elaborazione, per andare a
controllare in uscita, magari su piu' interfacce.
Il comando "show access-list" mostra le access-list configurate e' il numero di pacchetti
IP con match

itesys#show access-list
Standard IP access list 10
deny 192.168.30.241 (799 matches)
Extended IP access list 100
deny ip any host 192.168.30.241
permit ip any any (488 matches)

Figura 28 - Comando "show access-list"

Il routing dinamico

Gli algoritmi di routing dinamico

Nel caso di piccole WAN la configurazione di IOS e’ piuttosto semplice nella definizione
delle route. Normalmente poche righe di statiche consentono di risolvere tutte le
problematiche presenti.

Pagina 22
 Configurazione dei router Cisco

Col crescere della rete l’idea di inserire in ogni configurazione solo route statiche non fa
altro che aumentare i tempi per le operazioni di manutenzione e soprattutto non consente
di gestire percorsi multipli. In caso di reti gia’ di dimensione media, magari con struttura
magliata e quindi con piu’ percorsi alternativi, l’impossibilita’ di scalare del routing statico
e’ una seria limitazione.
Un protocollo di routing consente la propagazione automatica delle route a tutti senza
la necessita’ dell'uso delle statiche, ovvero di comandi “ip route <network> <mask>
<nexthop>”. Ogni router annuncia, con le specifiche dell’algoritmo di routing prescelto, i
percorsi di routing di sua conoscenza provenienti normalmente da reti direttamente
connesse, come le ethernet e le seriali.
Esistono due famiglie di algoritmi di routing: distance-vector e link state. I primi
periodicamente inviano l’intera tabella di routing ai propri vicini e conservano solo
informazioni di ‘distanza’ e ‘vettore’ cioe’ metrica e next-hop. I secondi creano un grafo
topologico della rete dal quale determinano i percorsi ottimali utilizzando algoritmi come
Dijkstra shortest path first (SPF) nel caso di OSPF. Il metodo link state e’ il piu’ efficiente
ma computazionalmente il piu’ esigente. Sono distance-vector RIP, IGRP e BGP; OSPF e'
link-state.
EIGRP ha funzionalita' di entrambe le famiglie il che ne fa un caso particolare. Si
chiama “balanced hybrid protocol”. Invece di usare SPF utilizza l’algoritmo DUAL (Diffuse
Update Algorithm). Si tratta di un algoritmo che conserva informazioni riguardanti solo i
vicini di un router (invece dell'intera rete come nei link-state) ma e’ piu’ leggero
computazionalmente rispetto Dijkstra (SPF).
Gli algoritmi di routing si differenziano anche come classful e classless. I primi operano
nei classful boundaries, cioe’ non gestiscono le subnet (sono detti anche FLSM, fixed
lenght subnet mask) e si tratta di RIP e IGRP. I secondi invece (detti anche VLSM cioe’
variable lenght subnet mask) gestiscono pienamente le subnet quindi operano senza le
limitazioni date dalle classi di appartenenza. Esempio sono EIGRP, OSPF e BGP. Questa
differenza e’ vitale per la corretta configurazione degli apparati di rete.

Routing RIP

Il protocollo RIP e' il piu' datato tra i protocolli di routing dinamico oggi in uso in una
rete IP. Le specifiche sono indicate in RFC 1058 datato Giugno 1988. In seguito, nel 1995,
e' stato pubblicato l'RFC 1388 che specifica il successore di RIP, il RIPv2, di cui non si
parlera' in questo documento, ma che presenta una valida alternativa al RIPv1 in
ambienti dove non si possono ignorare le subnet.
RIP e’ un protocollo IGP, "Interior Gateway Protocol", ovvero pensato per essere usato
in piccole parti di Internet o in WAN isolate da internet, ma non per connettere tra loro
diversi AS di Internet (per i quali e' necessario un protocollo External di tipo EGP)
RIPv1 e' l'ideale per piccole reti WAN con indirizzamento IP privato e omogenee in
termini di larghezza di banda dei link dati presenti. Anche se il piu' datato e' presente su
molti apparati di rete anche di fascia bassa ed e' quindi molto diffuso.
RIP utilizza la porta 520 dell'UDP.

Configurazione

Partiamo subito da un esempio concreto. Consideriamo la seguente configurazione IOS:

router rip
network 116.0.0.0
network 192.168.30.0

Pagina 23
 Configurazione dei router Cisco

Figura 29 - Configurazione minimale RIP

Nota: Introducendo 116.30.40.0 invece di 116.0.0.0 in automatico IOS inserisce
116.0.0.0 poiche' RIP e' classful e 116 e' una classe A.
La configurazione presentata e' completa e attiva il protocollo RIP per le due network
indicate. Le due reti sono state scelte in quanto presenti sulle interfacce fisiche del router.
Ad esempio la ethernet di questo router ha ip 116.30.40.1 mentre la seriale
192.168.30.2.
RIP e' cosi' attivo sulle interfacce definite col comando “network”. Si faccia attenzione
al fatto che affinche’ RIP sia operativo su un’interfaccia questa deve avere un indirizzo IP
che ricade dentro un comando “network”. Se ad esempio una seriale S ha indirizzo N e la
classe di N non viene indicata nella configurazione RIP allora non si accetteranno route in
ingresso su S e non si faranno annunci RIP in uscita su S. Attraverso le altre interfacce
verra' comunque annunciata la network N. Si ricordi che le informazioni inviate sono prive
di dati relativi alla netmask (non supportata da RIPv1) ma comprensive di metrica. La
metrica per RIP e’ basata sull’hop-count e puo’ variare tra 0 e 15 (con 16 la route viene
scartata). L’hop-count rappresenta il numero di router da attraversare per raggiungere
una rete. Poiche' il valore massimo e' 15 si evince che, in reti con diametro superiore a
15, non si puo' utilizzare RIP.
RIP manda l'intera tabella di routing ogni 30 secondi con broadcast 255.255.255.255 su
tutte le interfacce su cui e' attivo. Se vi e' un cambiamento in una tabella di routing, ad
esempio perche' abbiamo cambiato la classe IP di una interfaccia ethernet, questo si
propaga subito, come nel caso della rete 192.168.30.0 che potete vedere sotto, indicata
come FLASH-UPDATE (magari prima l'indirizzo era 192.168.20.X). Ecco l'output del
comando "debug ip rip" attivo sul router con la configurazione di cui sopra:

Router#
02:18:05: RIP: sending request on Ethernet0 to 255.255.255.255
02:18:07: RIP: sending v1 flash update to 255.255.255.255 via ATM0 (116.30.40.1)
02:18:07: RIP: build flash update entries
02:18:07: network 192.168.30.0 metric 1
02:18:07: RIP: sending v1 flash update to 255.255.255.255 via Ethernet0
(192.168.30.1)
02:18:07: RIP: build flash update entries - suppressing null update
02:18:11: RIP: sending v1 update to 255.255.255.255 via ATM0 (116.30.40.1)
02:18:11: RIP: build update entries
02:18:11: network 192.168.30.0 metric 1
02:18:11: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.30.1)
02:18:11: RIP: build update entries
02:18:11: network 116.0.0.0 metric 1
02:18:39: RIP: sending v1 update to 255.255.255.255 via ATM0 (116.30.40.1)
02:18:39: RIP: build update entries
02:18:39: network 192.168.30.0 metric 1
02:18:39: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.30.1)
02:18:39: RIP: build update entries
02:18:39: network 116.0.0.0 metric 1
02:19:07: RIP: sending v1 update to 255.255.255.255 via ATM0 (116.30.40.1)
02:19:07: RIP: build update entries
02:19:07: network 192.168.30.0 metric 1
02:19:07: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.30.1)
02:19:07: RIP: build update entries
02:19:07: network 116.0.0.0 metric 1

Figura 30 - Debug: pacchetti RIP

vedete come, ogni 30 secondi (con piccole discrepanze dovute all'output del log) viene

Pagina 24
 Configurazione dei router Cisco

inviata la tabella di routing in broadcast sulle due interfacce presenti in questo router,
ovvero ATM0 e Ethernet0. La periodicita' non e' valida per il "flash update".
Il problema delle subnet

Nell'esempio precedente abbiamo utilizzato una network di classe A e una di classe

C. Questo non stupisce in quanto RIP e’ un algoritmo di routing classful. Certo c’e’ da
domandarsi cosa si possa fare ai giorni nostri con un algoritmo di routing che lavori solo
nei class boundaries ... probabilmente converrebbe usare solo RIPv2. Ma puo' non essere
disponibile nei nostri apparati. E inoltre con RIPv1 ci sono dei margini all'interno dei quali
si possono usare le subnet. RIP consente di far uso di subnetting anche se con pesanti
limitazioni. Tecnicamente diciamo che RIP e’ un algoritmo FLSM (Fixed Lenght Subnet
Mask) ovvero consente di utilizzare subnetting ma mantenento la netmask fissa su tutta
per tutta la WAN (primo vincolo). Poi RIP e’ un algoritmo che richiede la continuita’ delle
subnet nella rete ovvero ogni router deve avere una subnet della classe che propaga la
quale deve proseguire nella direzione di propagazione.

Figura 31 - RIP e subnet

Osservate la figura. Supponiamo di avere tre router A e B e C collegati linearmente
tramite seriali con indirizzi del tipo 192.168.30.0/27. Ogni router ha una interfaccia
ethernet con indirizzi del tipo 172.16.X.0/24. Il router A inviera’ e ricevera’ informazioni di
routing da B secondo i seguenti criteri:
In invio:
· Da ogni interfaccia con RIP attivo inviera’ tutte le sottoreti conosciute della major
network di appartenenza dell’interfaccia stessa;
· Da ogni interfaccia con RIP attivo inviera’ solo le major network di appartenenza nel
caso di major network differente (ovvero 172.16.0.0 invece di 172.16.10.0) ;
· Se una network da inviare ha stessa major network ma netmask differente viene
scartata .
In ricezione:
· Se un aggiornamento e’ della stessa major class della interfaccia da cui proviene gli da
lo stesso netmask dell’interfaccia (nel caso di 192.168.30.62);
· Se un aggiornamento e’ di major class differente lo summarizza alla major class MA se
nella tabella di routing vi e’ un’altra sottorete qualsiasi della stessa major class scarta

Pagina 25
 Configurazione dei router Cisco

l’aggiornamento (cosi’ 172.16.0.0 proveniente da B viene scartata) .

Cosi’ la configurazione in figura non e’ corretta. Il router A sara’ in grado di
raggiungere tutte le subnet di 192.168.30.0 ma non le subnet di 172.16.0.0 perche’ per
queste viene meno la continuita’. Per far funzionare una configurazione del genere
avremmo dovuto usare tre classi B differenti sulle tre reti Ethernet.
Per dirla in breve conviene utilizzare in una WAN tutte sottoreti della stessa major
network per le seriali. Possiamo cosi' risparmiare un buon numero di indirizzi IP su queste
interfacce. Se si utilizza per una ethernet una major network accertarsi di non usare altre
sottoreti della stessa (con lo stesso o differente netmask) da nessun'altra parte altrimenti
non appena arrivera' l'aggiornamento questo verra' scartato. Se non si puo' evitare usare
delle statiche. E' questo che si intende per continuita' nel subnetting. Tutto il discorso fatto
vale per RIP v1. Il RIP v2 consente di evitare queste limitazioni in quanto non e' FLSM ma
VLSM (Variable Lenght Subnet Mask) cioe' propaga anche le subnet masks.
Supponiamo di avere la seguente tabella di routing:

Router#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

116.0.0.0/24 is subnetted, 1 subnets

C 116.30.40.0 is directly connected, ATM0
151.99.0.0/24 is subnetted, 2 subnets
C 151.99.100.0 is directly connected, Ethernet0
S 151.99.105.0 is directly connected, ATM0

Figura 32 - Access-list in uscita

ecco come vengono propagate le reti 151.99.X.X con RIP attivo:

02:44:12: RIP: sending v1 update to 255.255.255.255 via ATM0 (116.30.40.1)

02:44:12: RIP: build update entries
02:44:12: network 151.99.0.0 metric 1
02:44:12: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (151.99.100.1)

02:44:12: RIP: build update entries

02:44:12: network 116.0.0.0 metric 1
02:44:12: subnet 151.99.105.0 metric 1

02:44:40: RIP: sending v1 update to 255.255.255.255 via ATM0 (116.30.40.1)

02:44:40: RIP: build update entries
02:44:40: network 151.99.0.0 metric 1
02:44:40: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (151.99.100.1)

Figura 33 - Access-list in uscita

Come si vede, non vengono inviate informazioni riguardo le mask delle sottoreti.
Tempo di convergenza

RIP e’ un algoritmo distance-vector ovvero un router con RIP attivo propaga l’intera

Pagina 26
 Configurazione dei router Cisco

tabella di routing ai propri vicini e non solo gli aggiornamenti. Per default ogni 30 secondi
un nodo RIP invia la propria tabella di routing aggiornata. Questo tempo si chiama
broadcast time.

Supponiamo di avere due router con RIP attivo. Supponiamo che il router di nome R2
non riceva piu' aggiornamenti dal suo vicino di nome R1 per un guasto di linea. Invece di
scartare subito le route che R1 aveva inviato nel precedente ciclo di 30 secondi, R2
attende per un totale di 180 secondi continuando ad utilizzare le informazioni di routing
inviate precedentemente da R1. Questo tempo si chiama "invalid time". Superati i 180
secondi il router R2 presume con sufficiente certezza che R1 sia irraggiungibile e inizia il
processo di cessazione dell'uso delle route che aveva ricevuto. Inizia quindi un processo di
cancellazione per queste route: la loro metrica viene posta a 16 (irraggiungibile) e
vengono propagate con tale metrica per un periodo di altri 60 secondi. In questi 60
secondi le route sono nello stato di "hold-down" non figurano nella tabella di routing ma
appaiono nel database del RIP come "possibly-down".
Se un terzo router R3 riceve le route con metrica 16 da R2 mette le network
direttamente nello stato di "hold-down". Superato il tempo di l'hold-down le route
vengono scartate dalla tabella di routing. Pero' risultano ancora nel database del RIP fino
al "flush-time" che vale 240 secondi di default. Durante l'hold-down le informazioni
riguardanti nuovi percorsi per raggiungere le reti in oggetto provenienti da altri router
vengono scartate (per evitare possibili routing loops). Il tempo di "flush-time" e' ottenuto
dalla somma del tempo di hold-down piu' un periodo di tempo che in questo caso e' 60
secondi.
Possiamo quindi osservare che in caso di guasto nella WAN il percorso alternativo viene
attivato dopo circa 4 minuti. Non e' sicuramente un tempo breve ma e' motivato dalla
necessita' di evitare i routing loops. Questo si chiama "tempo di convergenza" cioe' il
tempo necessario affinche' tutte le tabelle di routing di tutti i router si aggiornino dopo un
cambiamento di topologia (ad esempio dovuto a un guasto in un link). Le versioni recenti
di RIP utilizzano tuttavia i "flash updates" con i quali inviano con immediatezza degli
aggiornamenti relative a modifiche nella topologia di rete senza attendere i 30 secondi.
Se abbiamo sufficiente banda (nei collegamenti odierni cio' e' altamente probabile)
possiamo ridurre tale tempo (eccessivo per alcune applicazioni) cambiando i timer RIP.
Tramite il comando "timers basic" e' possibile effettuare le modifiche:

timers basic <update> <invalid> <holddown> <flush>

Figura 33 - RIP: comando "timers basic"

Split-
Split-horizont e poison-
poison-reverse

Insieme ai timers sono i metodi per evitare il problema dei routing loop. Per default
se RIP riceve una route da una interfaccia S non invia verso S l'aggiornamento relativo
alla network ricevuta. Questo meccanismo si chiama split-horizont. Questa funzionalita’
e’ per default disabilitata nel caso di collegamenti di tipo Frame Relay o ATM. In questi
casi infatti una interfaccia potrebbe portare verso differenti network (tramite VC o DLCI)
e lo split-horizon renderebbe incompleta la propagazione di tali informazioni. E’ possibile
attivare o disattivare manualmente lo split-horizon col comando “ip split-horizont”. RIP
utilizza split-horizon con poison reverse ovvero invece di non ripropagare verso il
mittente una route la invia con metrica 16.

Redistribuzione

Pagina 27
 Configurazione dei router Cisco

La redistribuzione, ovvero l'iniezione di route RIP in altri protocolli di routing, non viene
trattata in questo articolo. Basti sapere che in caso di redistribuzione in altri algoritmi di
routing bisogna forzare un valore di metrica altrimenti di default questa sara' pari a 16.
Interfacce passive

Vedi il paragrafo corrispondente relativo a EIGRP.

Monitoraggio RIP

Col comando "show ip protocols" si possono vedere tutti i settaggi RIP:

Router#show ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 15 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Triggered RIP Key-chain
ATM0 1 1 2
Ethernet0 1 1 2
Automatic network summarization is in effect
Routing for Networks:
116.0.0.0
151.99.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)

Figura 34 - Comando "show ip protocols"

Col comando "debug" e' possibile visualizzare in tempo reale i messaggi RIP in ingresso
e uscita dalle interfacce. Ecco le opzioni possibili:

router#debug ip rip ?
database RIP database events
events RIP protocol events
trigger RIP trigger extension

Figura 35 - Comando "debug ip rip"

Route di default e RIP

Il tipico comando utilizzato per la route di default e' il seguente:

ip route 0.0.0.0 0.0.0.0 A.B.C.D

Figura 36 - Comando "debug ip rip"

Questo viene propagato senza problemi dal RIP ma attenzione, dalle versioni 12.0T
dell'IOS il RIP non lo rileva e bisogna utilizzare il comando “default-information originate”.
Ecco cosa succede con queste modifiche al nostro esempio, dove il router ha una versione
di IOS superiore alla 12.0T:

router rip
network 116.0.0.0

Pagina 28
 Configurazione dei router Cisco

network 151.99.0.0
default-information originate

Figura 37 - Comando "router rip"

Notate che i router vicini ricevono adesso la riga di default che appare in tabella di
routing con la notazione "S*"

Router#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

116.0.0.0/24 is subnetted, 1 subnets

C 116.30.40.0 is directly connected, ATM0
151.117.0.0/24 is subnetted, 1 subnets
S 151.117.6.0 [1/0] via 192.168.30.2
151.99.0.0/24 is subnetted, 2 subnets
C 151.99.100.0 is directly connected, Ethernet0
S 151.99.105.0 is directly connected, ATM0
S* 0.0.0.0/0 is directly connected, ATM0

Figura 38 - Comando "show ip route"

Ecco come appare il messaggio relativo alla route di default dal debug:

02:53:04: RIP: sending v1 update to 255.255.255.255 via ATM0 (116.30.40.1)

02:53:04: RIP: build update entries
02:53:04: network 151.99.0.0 metric 1
02:53:04: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (151.99.100.1)

02:53:04: RIP: build update entries

02:53:04: subnet 0.0.0.0 metric 1
02:53:04: network 116.0.0.0 metric 1
02:53:04: subnet 151.99.105.0 metric 1

Figura 39 - debug RIP pacchetti route di default

Esempio - lab -

L'esercitazione si basa su un laboratorio con due router Cisco collegati tra loro tramite
la seriale in back-to-back, simulando quindi un collegamento WAN a 2megabit. Ogni
router Cisco ha una sua ethernet con un suo switch e una LAN. Qui ci focalizziamo su uno
dei due router essendone il secondo l'esatto simmetrico.
Ecco la condizione iniziale:

Il router 'remoto' ha una ethernet 192.168.0.1/24 e una seriale 192.168.40.2/30

Il router 'locale' ha una ethernet 192.168.30.1/24 e una seriale 192.168.40.1/30
Sia assegnata questa configurazione:

interface FastEthernet0/0
ip address 192.168.30.1 255.255.255.0
no ip directed-broadcast

Pagina 29
 Configurazione dei router Cisco

duplex auto
speed auto
!
interface Serial0/0
ip address 192.168.40.1 255.255.255.252
no ip directed-broadcast
no ip mroute-cache
!
router rip
network 192.168.30.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0/0

Figura 40 - Esempio RIP: lab

L'effetto di questa configurazione e' quello attivare il RIP per la rete 192.168.30.0 e
quindi per la FastEthernet 0/0. A questo punto il router inviera' gli aggiornamenti RIP sulla
FastEthernet0/0 come si vede dalla figura successiva.

00:20:48: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (192.168.30.1)

00:20:48: RIP: build update entries - suppressing null update
gianrico#

Figura 41 - Debug RIP: update

come si puo' il comando network definisce non cosa propagare ma bensi' dove. In
questa configurazione il RIP e' disabilitato dall'interfaccia seriale 0/0. Pertanto gli
aggiornamenti RIP non sono accettati in ingresso dalla seriale0/0 come si vede dalla
figura successiva:

00:23:36: RIP: ignored v1 packet from 192.168.40.2 (not enabled on Serial0/0)

Figura 42 - Debug RIP: interfaccia senza RIP

Se vogliamo abilitare RIP nella seriale dobbiamo modificare la configurazione come
segue:

router rip
network 192.168.30.0
network 192.168.40.0

Figura 43 - Abilitiamo il RIP nella seriale

Dopo questa modifica viene inviato un flash update ovvero non si attendono i 30 secondi
per propagare le nuove route

00:24:51: RIP: sending request on FastEthernet0/0 to 255.255.255.255

00:24:51: RIP: sending request on Serial0/0 to 255.255.255.255
00:24:53: RIP: sending v1 flash update to 255.255.255.255 via FastEthernet0/0
(192.168.30.1)
00:24:53: RIP: build flash update entries
00:24:53: network 192.168.40.0 metric 1
00:24:53: RIP: sending v1 flash update to 255.255.255.255 via Serial0/0
(192.168.40.1)
00:24:53: RIP: build flash update entries
00:24:53: network 192.168.30.0 metric 1

Figura 44 - RIP debug: flash update

Pagina 30
 Configurazione dei router Cisco

dopo i 30 secondi l'intera tabella di routing viene propagata (tranne la default):

00:25:24: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0

(192.168.30.1)
00:25:24: RIP: build update entries
00:25:24: network 192.168.40.0 metric 1
00:25:24: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (192.168.40.1)
00:25:24: RIP: build update entries
00:25:24: network 192.168.30.0 metric 1

Figura 45 - RIP debug: update

Vediamo adesso l'uso del comando "passive-interface". Nella configurazione precedente i
messaggi RIP sono inviati dalle interfaccia FastEthernet0/0 e seriale. Se non vogliamo
mandare gli update sulla fasteth0/0, ad esempio perche' e' priva di router che gestiscono
il RIP:

router rip
passive-interface FastEthernet0/0
network 192.168.30.0
network 192.168.40.0

Figura 46 - RIP: comando "passive-interface"

dal debug si evince che gli aggiornamenti non sono piu' inviati sulla FastEthernet0/0:

00:35:18: RIP: received v1 update from 192.168.40.2 on Serial0/0

00:35:18: 192.168.0.0 in 1 hops
00:35:32: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (192.168.40.1)
00:35:32: RIP: build update entries
00:35:32: network 192.168.30.0 metric 1

Figura 47 - RIP debug: update

Se una interfaccia su cui e' attivo RIP passa allo stato di shutdown, che possiamo
simulare staccandone il cavo in una sessione di laboratorio, l'aggiornamento viene inviato
immediatamente dal RIP. Scolleghiamo la ethernet 192.168.0.1 da router remoto e
vediamo cosa succede nel router locale.

00:37:20: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (192.168.40.1)

00:37:20: RIP: build update entries
00:37:20: network 192.168.30.0 metric 1
00:37:23: RIP: received v1 update from 192.168.40.2 on Serial0/0
00:37:23: 192.168.0.0 in 16 hops (inaccessible)
00:37:25: RIP: sending v1 flash update to 255.255.255.255 via Serial0/0
(192.168.40.1)
00:37:25: RIP: build flash update entries
00:37:25: network 192.168.0.0 metric 16

Figura 48 - RIP debug: simulazione di guasto su Ethernet

locale#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Pagina 31
 Configurazione dei router Cisco

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

C 192.168.30.0/24 is directly connected, FastEthernet0/0

192.168.40.0/30 is subnetted, 1 subnets
C 192.168.40.0 is directly connected, Serial0/0
S* 0.0.0.0/0 is directly connected, Serial0/0

locale#sh ip rip database

192.168.0.0/24 is possibly down
192.168.30.0/24 auto-summary
192.168.30.0/24 directly connected, FastEthernet0/0
192.168.40.0/24 auto-summary
192.168.40.0/30 directly connected, Serial0/0

Figura 49 - RIP: route "possibly down"

Dopo qualche secondo sparisce dal database. Praticamente subito dalla tabella di
routing. Il tutto avviene entro pochi secondi, sia come cancellazione che come ripristino.
Riproviamo ma col "debug ip rip database":

locale#sh ip rip database

192.168.0.0/24 is possibly down
192.168.30.0/24 auto-summary
192.168.30.0/24 directly connected, FastEthernet0/0
192.168.40.0/24 auto-summary
192.168.40.0/30 directly connected, Serial0/0

00:41:03: RIP-DB: garbage collect 192.168.0.0/24

locale#sh ip rip database

192.168.30.0/24 auto-summary
192.168.30.0/24 directly connected, FastEthernet0/0
192.168.40.0/24 auto-summary
192.168.40.0/30 directly connected, Serial0/0 €€€€€

Figura 50 - RIP: il database viene aggiornato a causa di un cambio di topologia

Con il comando "show ip protocol" possiamo vedere lo stato del RIP nel nostro router:

locale#sh ip protocol
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 17 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Triggered RIP Key-chain
Serial0/0 1 1 2
Automatic network summarization is in effect
Routing for Networks:
192.168.30.0
192.168.40.0
Passive Interface(s):
FastEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
192.168.40.2 120 00:00:54
Distance: (default is 120)

Pagina 32
 Configurazione dei router Cisco

Figura 51 - RIP: comando "show ip protocol"

Simuliamo un fault sulla rete. Il router remoto non invia piu' aggiornamenti RIP sulla
rete 192.168.0.1

locale#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

C 192.168.30.0/24 is directly connected, FastEthernet0/0

192.168.40.0/30 is subnetted, 1 subnets
C 192.168.40.0 is directly connected, Serial0/0
R 192.168.0.0/24 [120/1] via 192.168.40.2, 00:00:20, Serial0/0
S* 0.0.0.0/0 is directly connected, Serial0/0
locale#
locale#
locale#sh ip rip database
192.168.0.0/24 auto-summary
192.168.0.0/24
[1] via 192.168.40.2, 00:00:25, Serial0/0
192.168.30.0/24 auto-summary
192.168.30.0/24 directly connected, FastEthernet0/0
192.168.40.0/24 auto-summary
192.168.40.0/30 directly connected, Serial0/0

Figura 52 - RIP: simulazione di guasto

la route rimane anche nella tabella di route. Dopo tre minuti (non fase caso
all'imprecisione dei secondi dovuta alle condizioni di test) scade l'hold-down e parte il
poison:

01:05:41: RIP-DB: flush route of 192.168.0.0/24 via 192.168.40.2

01:05:41: RIP-DB: Remove 192.168.0.0/24, (metric 4294967295) via 192.168.40.2, S
erial0/0
01:05:41: RIP-DB: hold down 192.168.0.0/24
01:05:41: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (192.168.40.1)
01:05:41: RIP: build update entries
01:05:41: network 192.168.0.0 metric 16
01:05:41: network 192.168.30.0 metric 1
01:05:43: RIP: sending v1 flash update to 255.255.255.255 via Serial0/0 (192.168
.40.1)
01:05:43: RIP: build flash update entries
01:05:43: network 192.168.0.0 metric 16

Figura 53 - RIP debug: 'hold-down' e 'poison'

adesso la route non verra' piu' usata ma e' nel database RIP nello stato di possibly
down:

locale#sh ip rip database

192.168.0.0/24 is possibly down
192.168.0.0/24 is possibly down
192.168.30.0/24 auto-summary

Pagina 33
 Configurazione dei router Cisco

192.168.30.0/24 directly connected, FastEthernet0/0

192.168.40.0/24 auto-summary
192.168.40.0/30 directly connected, Serial0/0
locale#
locale#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

C 192.168.30.0/24 is directly connected, FastEthernet0/0

192.168.40.0/30 is subnetted, 1 subnets
C 192.168.40.0 is directly connected, Serial0/0
S* 0.0.0.0/0 is directly connected, Serial0/0

01:06:08: RIP-DB: garbage collect 192.168.0.0/24

01:06:08: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (192.168.40.1)
01:06:08: RIP: build update entries
01:06:08: network 192.168.30.0 metric 1

Figura 54 - RIP: route possibly down

dopo all'incirca altri 60 secondi dai tre minuti (e siamo a 180+60=240) la route viene
rimossa dal database
(non fate caso al tempo qui sopra di 01:06:08 che e' relativo alla summary):

01:06:34: RIP-DB: garbage collect 192.168.0.0/24

01:06:34: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (192.168.40.1)
01:06:34: RIP: build update entries
01:06:34: network 192.168.30.0 metric 1
locale#
locale#sh ip rip database
192.168.30.0/24 auto-summary
192.168.30.0/24 directly connected, FastEthernet0/0
192.168.40.0/24 auto-summary
192.168.40.0/30 directly connected, Serial0/0
locale#sparita

Figura 55 - RIP: rimozione route dal database

RIP Lab: Continuita' della subnet.

Supponiamo che la ethernet del router remoto diventi 192.168.40.5/30. Vediamo che succede:

locale#
01:21:00: RIP: sending request on Serial0/0 to 255.255.255.255
01:21:00: RIP: received v1 update from 192.168.40.2 on Serial0/0
01:21:00: 192.168.40.4 in 1 hops
01:21:02: RIP: sending v1 flash update to 255.255.255.255 via Serial0/0 (192.168
.40.1)
01:21:02: RIP: build flash update entries
01:21:02: network 192.168.30.0 metric 1
locale#
01:21:06: RIP: received v1 update from 192.168.40.2 on Serial0/0

Pagina 34
 Configurazione dei router Cisco

01:21:06: 192.168.40.4 in 1 hops

locale#
locale#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

C 192.168.30.0/24 is directly connected, FastEthernet0/0

192.168.40.0/30 is subnetted, 2 subnets
C 192.168.40.0 is directly connected, Serial0/0
R 192.168.40.4 [120/1] via 192.168.40.2, 00:00:05, Serial0/0
S* 0.0.0.0/0 is directly connected, Serial0/0
locale#sh ip route 192.168.40.5
Routing entry for 192.168.40.4/30
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 192.168.40.2 on Serial0/0, 00:00:10 ago
Routing Descriptor Blocks:
* 192.168.40.2, from 192.168.40.2, 00:00:10 ago, via Serial0/0
Route metric is 1, traffic share count is 1

locale#sh ip rip database

192.168.30.0/24 auto-summary
192.168.30.0/24 directly connected, FastEthernet0/0
192.168.40.0/24 auto-summary
192.168.40.0/30 directly connected, Serial0/0
192.168.40.4/30
[1] via 192.168.40.2, 00:00:08, Serial0/0

Figura 56 - RIP: propagazione subnet con successo

mettiamo ora nel router remoto 192.168.50.1/25 e vediamo cosa succede:

locale#sh ip route 192.168.50.1

Routing entry for 192.168.50.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 192.168.40.2 on Serial0/0, 00:00:08 ago
Routing Descriptor Blocks:
* 192.168.40.2, from 192.168.40.2, 00:00:08 ago, via Serial0/0
Route metric is 1, traffic share count is 1

locale#sh ip rip database

192.168.30.0/24 auto-summary
192.168.30.0/24 directly connected, FastEthernet0/0
192.168.40.0/24 auto-summary
192.168.40.0/30 directly connected, Serial0/0
192.168.50.0/24 auto-summary
192.168.50.0/24
[1] via 192.168.40.2, 00:00:11, Serial0/0
locale#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

Pagina 35
 Configurazione dei router Cisco

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

C 192.168.30.0/24 is directly connected, FastEthernet0/0

192.168.40.0/30 is subnetted, 1 subnets
C 192.168.40.0 is directly connected, Serial0/0
R 192.168.50.0/24 [120/1] via 192.168.40.2, 00:00:14, Serial0/0
S* 0.0.0.0/0 is directly connected, Serial0/0

Figura 57 - RIP: propagazione subnet fallita

notate che mentre nel primo esempio la netmask e' stata propagata nel secondo no e
questo perche' nel secondo esempio viene meno la continuita' della subnet. Attiviamo ora
ripv2 sulla configurazione di sopra (quella col 192.168.50.1/25):

01:32:45: RIP: sending request on Serial0/0 to 224.0.0.9

01:32:45: RIP: received v2 update from 192.168.40.2 on Serial0/0
01:32:45: 192.168.50.0/25 via 0.0.0.0 in 1 hops
01:32:46: RIP: received v2 update from 192.168.40.2 on Serial0/0
01:32:46: 192.168.50.0/25 via 0.0.0.0 in 1 hops
01:32:47: RIP: sending v2 flash update to 224.0.0.9 via Serial0/0 (192.168.40.1)
01:32:47: RIP: build flash update entries
01:32:47: 192.168.30.0/24 via 0.0.0.0, metric 1, tag 0
locale#
01:32:52: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (192.168.40.1)
01:32:52: RIP: build update entries
01:32:52: 192.168.30.0/24 via 0.0.0.0, metric 1, tag 0

locale#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

C 192.168.30.0/24 is directly connected, FastEthernet0/0

192.168.40.0/30 is subnetted, 1 subnets
C 192.168.40.0 is directly connected, Serial0/0
192.168.50.0/25 is subnetted, 1 subnets
R 192.168.50.0 [120/1] via 192.168.40.2, 00:00:15, Serial0/0
S* 0.0.0.0/0 is directly connected, Serial0/0

locale#sh ip rip database

192.168.30.0/24 auto-summary
192.168.30.0/24 directly connected, FastEthernet0/0
192.168.40.0/24 auto-summary
192.168.40.0/30 directly connected, Serial0/0
192.168.50.0/24 auto-summary
192.168.50.0/25
[1] via 192.168.40.2, 00:00:01, Serial0/0

Figura 58 - RIPv2 e propagazione subnet

attenzione: per default e' attivo l'auto-summary. Mettere "no auto-summary" per vedere

Pagina 36
 Configurazione dei router Cisco

la propagazione della /25

Configurazione IGRP

IGRP e’ FLSM e opera seguendo gli stessi principi di RIP. Quanto detto per RIP per la
propagazione delle subnet continua a valere. IGRP e’ distance-vector. Le differenze di
IGRP rispetto RIP sono fondamentalmente nell’algoritmo di calcolo della metrica e nella
gestione della stessa. IGRP infatti calcola la metrica utilizzando la somma dei delay e delle
larghezze di banda presenti per raggiungere una network remota. Delay e bandwidth
sono parametri introdotti manualmente nella configurazione con i comandi “delay” e
“bandwidth” e rappresentano il ritardo di propagazione dei pacchetti e la larghezza di
banda a disposizione. E’ possibile anche l’utilizzo di una metrica composta piu' estesa
comprendente “reliability”, “load” e “MTU”. Per intenderci IGRP e’ molto piu’ efficiente di
RIP nel calcolare i percorsi migliori (non a caso ha una AD di 100 contro i 120 di RIP)
infatti RIP paradossalmente darebbe priorita’ ai percorsi con meno hop anche in situazioni
di congestione con alternative con piu’ hop ma senza congestione.

routing igrp 12
network 172.18.0.0
network 192.168.30.0
network 10.0.0.0

Figura 59 - Configurazione di base IGRP

Si faccia attenzione al fatto che affinche’ IGRP sia operativo su un’interfaccia questa
deve avere un indirizzo IP che ricade dentro un comando “network”. In caso contrario non
si accetteranno route in ingresso su una interfaccia e non si propaghera’ nulla attraverso
quell’interfaccia.
Una route IGRP con metrica –1 viene scartata. In caso di redistribuzione bisogna
indicare la metrica altrimenti sara’ –1. Quando si redistribuisce IGRP in OSPF di default
sara’ assegnata una metrica pari a 20 di default.
Tempo di convergenza

IGRP propaga la tabella di routing ogni 90 secondi (broadcast time). Se per tre volte
questo tempo (invalid time pari a 270 sec.) non riceve un aggiornamento per una route la
dichiara “possibly down”. Quindi attende un periodo di 280 secondi (holddown time pari
per default a tre volte invalid time piu’ 10) nel quale non accetta nessun aggiornamento
riguardante la route “possibly down”. Superato anche questo intervallo di tempo la route
viene cancellata dalla tabella di routing dopo altri 350 secondi. Complessivamente il
tempo e’ 10 minuti e 30 secondi (flush time pari a 7 volte il broadcast time). Durante
l’holddown la route viene annunciata con metrica infinita pari a -1.
Complessivamente si tratta di oltre 10 minuti, un tempo non indifferente motivato dalla
necessita’ di evitare routing loops. Per aumentare l’efficienza IGRP utilizza come RIP i
“flash updates” che consistono nell’inviare un aggiornamento dovuto a un cambiamento di
stato di un’interfaccia (e quindi di una route) non appena questo avviene invece di
completare un ciclo di 90 secondi. Questo funziona bene nel caso di modifiche agli IP
nella nostra WAN ma non nel caso di caduta di link.
Una rete IGRP puo’ avere diametro massimo pari a 255 ma per default e’ settato a
100. Se si ha un hop-count superiore al diametro massimo le route non si propagano. I
parametri per il calcolo della metrica: “bandwidth” e “delay”, sono valori inseriti
manualmente dall’operatore in ogni router per ogni link.

Pagina 37
 Configurazione dei router Cisco

Split-horizont e poison-reverse

Per evitare i routing loops come per il RIP si utilizza split-horizon. Split-horizon previene
routing loop tra router adiacenti. Per evitare la possibilita’ di loop coinvolgenti un gran
numero di router, detti grandi router loop, si utilizza il route poisoning. L’idea consiste nel
controllare il tasso di crescita nell'aumento di metrica delle route. Un tasso eccessivo puo’
indicare la presenza di un loop e quindi si mette in hold-down la route che ne e' coinvolta.
Il fattore consigliato di crescita e’ 1.1. Una route in hold-down verra’ annunciata con
metrica infinita (pari a -1).
Interfacce passive

Vedi il paragrafo corrispondente relativo a EIGRP.

Route di default

Il tipico comando utilizzato per la route di default e' il seguente:

ip route 0.0.0.0 0.0.0.0 A.B.C.D

Figura 60 - Route di default

IGRP non propaga di default questa route. Affinche' venga propagata la route di default
bisogna utilizzare il comando "ip default-network A.B.C.D".
EIGRP

L'algoritmo

Gli algoritmi distance-vector come RIP e IGRP prendono la loro denominazione dal
fatto che ogni scelta di routing e’ basata su un valore di distanza (che prende il nome di
metrica) e dal fatto che il next-hop e’ dato da un vettore. Tali algoritmi prendono le loro
decisioni esclusivamente in base a quanto presente nella tabella di routing in quanto non
conservano informazioni aggiuntive. Tutto cio' che proviene dai vicini e che non viene
inserito nella tabella di routing non viene utilizzato (ad eccezione di RIPV2 dalla 12.0).
EIGRP si basa proprio su queste informazioni aggiuntive per migliorare il proprio
tempo di convergenza. RIP e IGRP non possono evitare routing loop se non con hold-
down e flush timers. Ricordiamo che cio’ porta, di default, ad un tempo di convergenza di
circa 10,5 minuti per IGRP e un po’ meno per RIP. EIGRP conserva informazioni sulla
topologia della rete fino ai router direttamente connessi. Questo vedremo che consente di
evitare routing loops senza l’uso di hold-down e flush-timers. EIGRP si basa su un
algoritmo chiamato DUAL.
Gli algoritmi link-state come EIGRP e OSPF non propagano l’intera tabella di routing
ai loro vicini ma soltanto le sue variazioni. Pertanto e’ necessario un nuovo metodo per
poter stabilire quando un vicino non e’ piu’ raggiungibile (con RIP e IGRP basta verificare
l'arrivo periodico la tabella di routing dai vicini). La soluzione consiste nell’utilizzo di
speciali pacchetti, detti di HELLO, periodicamente inviati per segnalare il proprio stato di
on-line (e altre informazioni aggiuntive).
EIGRP invia i pacchetti di HELLO ogni 5 secondi sui collegamenti piu’ affidabili e a
velocita’ maggiori (come ethernet, token ring, NBMA superiori a T1), ogni 60 secondi per
reti meno affidabili o a velocita’ minore (ISDN, NBMA minori o uguali a T1). I pacchetti di
HELLO sono inviati al multicast 224.0.0.10. Questo tempo si chiama “hello-interval” ed e’
modificabile col comando “ip hello-interval eigrp NN”. Dopo tre volte questo tempo, valore
di hold-time, se non si ricevono HELLO il vicino sara’ considerato DOWN. Questo valore e’

Pagina 38
 Configurazione dei router Cisco

modificabile con il comando “ip hold-time eigrp NN”.

Una volta che la sessione tra due router e’ attiva ognuno dei due conservera’ tutte le
informazioni inviate dal vicino. Queste gli consentono di determinare un valore di metrica,
chiamato “REPORTED-DISTANCE”, che indica la metrica con cui il router mittente
raggiunge una certa destinazione. A questa il router affianca sempre la “FEASIBLE-
DISTANCE” ovvero la metrica che lui adotta per raggiungere una determinata
destinazione. Al momento in cui una destinazione non e’ piu’ raggiungibile un router RTA
determinera' il nuovo percorso dal confronto tra REPORTED e FEASIBLE. Se FEASIBLE <
REPORTED allora utilizza il percorso in suo possesso. Altrimenti RTA entra nello stato di
ACTIVE e interroga i router adiacenti con una QUERY chiedendo per percorsi alternativi
che gli consentano di soddisfare la regola di cui sopra. Il router vicino, diciamo RTB, dara'
una risposta se possiede tale percorso altrimenti girera’ la QUERY a monte. Si inviano
percio' una serie di richieste di QUERY in cascata che, se senza risposta affermativa, fara’
si che RTA dichiarera’ la rete remota come irraggiungile. Se per qualche ragione RTA non
riceve risposta alla sua QUERY entrera' nello stato di SIA (Stuck in Active). Per sbloccare
la situazione, dopo un certo tempo, 3 minuti di default, (modificabile col comando “timers
active-time NN”) si considerera’ la rete remota irraggiungibile.
Grazie a questo meccanismo EIGRP evita routing loops ed ha un basso tempo di
convergenza. Poiche’ gestisce la VLSM e' l’alternativa naturale a RIP e IGRP.
Quando EIGRP ha piu’ path per una medesima destinazione fa bilanciamento di carico
di default. E’ possibile fare bilanciamento di carico anche tra path con metriche differenti.
Dati ad esempio tre percorsi A, B, C per la medesima destinazione e con metrica 100,
200, 300, col comando “variance 3” io affermo che i path con metrica da quella piu’ bassa
alla stessa moltiplicata per tre devono partecipare ad un load-balancing. In questo caso
con “variance 3” i tre path 100, 200, 300 parteciperanno. La distribuzione dei pacchetti
tra i tre link sara’ calcolata dividendo la metrica piu' alta, che si indica con MAXMET, per i
valori di metrica dei singoli path. Questa forma di bilanciamento quindi NON consiste nel
mandare a ruota un pacchetto su ogni link (non e' round-robin).
Nel caso di collegamenti punto-multipunto EIGRP considera come metrica del singolo
VC la metrica sull' interfaccia divisa per il numero di virtual-link nella stessa. Si consiglia
allora di dare col comando “bandwidth” il valore pari al CIR (nel caso di FR) piu’ basso tra
quelli forniti dall'operatore TELCO per i VC. Questo evita un uso eccessivo di banda da
parte di EIGRP che utilizza fino ad un max del 50% della banda disponibile per i suoi
pacchetti di protocollo. Tale valore e’ settabile col comando “ip bandwidth-percent eigrp
ASNUMBER VALORE”.
Configurazione

Ecco un esempio di configurazione di base con EIGRP:

router eigrp 10
network 116.0.0.0
network 151.99.0.0
auto-summary
no eigrp log-neighbor-changes

Figura 61 - Configurazione di base EIGRP

Affinche' EIGRP sia attivo in un’interfaccia questa deve avere un indirizzo IP dichiarato
con il comando “network”. In caso contrario EIGRP non sara' attivo su quell' interfaccia e
quindi si scarteranno eventuali messaggi in ingresso oltre a non inviarne in uscita.

Pagina 39
 Configurazione dei router Cisco

I comandi auto-summary e 'no eigrp log-neighbor-changes' sono presenti di default.

Tabella di routing

Nella tabella di routing entra solo la route che ha valore di metrica inferiore, ovvero il
percorso migliore. Se ci sono piu' percorsi possibili per una destinazione le route che non
entrano in tabella di route restano nel database dell'EIGRP consultabile con il comando
"show ip eigrp topology". Nelle figure a seguire e' possibile vedere un esempio

gianrico#show ip route 192.168.66.0

Routing entry for 192.168.66.0/24
Known via "eigrp 100", distance 90, metric 14082560, type internal
Redistributing via eigrp 100
Last update from 192.168.38.9 on Tunnel3, 00:13:12 ago
Routing Descriptor Blocks:
* 192.168.38.9, from 192.168.38.9, 00:13:12 ago, via Tunnel3
Route metric is 14082560, traffic share count is 1
Total delay is 500100 microseconds, minimum bandwidth is 2000 Kbit
Reliability 255/255, minimum MTU 1476 bytes
Loading 1/255, Hops 1

Figura 62 - Tabella di routing e metrica

gianrico# show ip route eigrp

...
D 192.168.66.0/24 [90/14082560] via 192.168.38.9, 00:13:53, Tunnel3
...

gianrico#show ip eigrp topology

IP-EIGRP Topology Table for AS(100)/ID()

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

...
P 192.168.66.0/24, 1 successors, FD is 14082560
via 192.168.38.9 (14082560/28160), Tunnel3
via 192.168.37.6 (17922560/28160), Tunnel2 <-- solo qui si vede la 2a opzione
...

Figura 63 - Tabella di routing e database EIGRP

EIGRP Timers

In questo paragrafo trattiamo le tempistiche adottate da EIGRP per valutare la

validita' della topologia. EIGRP si aspetta aggiornamenti da parte dei router adicenti per
un tempo dato da "hello-time". Se per "hold-time" non riceve aggiornamenti allora la
route associata viene considerata non valida.
Di default "hold-time" e' 15 secondi, "hello-time" e' 5 secondi. Nella tabella che segue si
vede il timer associato ad ogni riga di routing:

itesys#show ip eigrp neighb

IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 192.168.38.2 Tu1 13 00:11:02 128 768 0 2818
1 192.168.37.5 Tu0 14 00:11:15 106 5000 0 19754

Pagina 40
 Configurazione dei router Cisco

3 192.168.38.6 Tu2 10 1w2d 90 540 0 1307

0 192.168.38.10 Tu3 10 1w4d 80 480 0 18251

Figura 64 - EIGRP timers

La colonna "hold" e' un contatore che parte da 15 e decresce. Se raggiunge lo zero la
route viene invalidata:

*May 14 09:14:34.391: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.37.5

(Tunnel0) is down: holding time expired
*May 14 09:14:37.419: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.38.2
(Tunnel1) is down: holding time expired
*May 14 09:14:37.491: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.37.5
(Tunnel0) is up: new adjacency
*May 14 09:14:41.943: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.38.2
(Tunnel1) is up: new adjacency

Figura 65 - EIGRP - l'holding time scade dopo 15 secondi -

In alcuni casi, ad esempio nel caso di collegamenti instabili, questo "up" e "down"
potrebbe essere troppo frequente portando falsi positivi. In questi casi vanno cambiati i
timers. Nell'esempio di cui sopra ad esempio nelle interfacce TU1 e TU0 la sessione e' up
da 11 minuti mentre TU2 e TU3 da 1 settimana e oltre. Se questa condizione si ripete
puo' essere un sintomo di falso positivo indotto da qualche errore sul collegamento dati
che non necessariamente ne pregiudica l'efficienza.
Aumentando l'hold time da 15 a 30 secondi si da piu' possibilita' alla WAN di recapitare
correttamente i pacchetti HELLO, ma si ritarda anche il detect di un collegamento in fault.
Per fare questo, all'interno della configurazione delle interfacce si utilizza il seguente
comando:

ip hold-time eigrp 100 30 <--- ovvero as 100 e hold-time 30 (*)

Figura 66 - EIGRP - configurazione dell'holding time

Vediamo gli effetti del comando:

itesys#show ip eigrp 100 neig

IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 192.168.37.5 Tu0 22 00:14:58 103 5000 0 19780
1 192.168.38.2 Tu1 28 00:24:48 104 624 0 2844
3 192.168.38.6 Tu2 26 1w2d 90 540 0 1307
0 192.168.38.10 Tu3 26 1w4d 80 480 0 18251

Figura 67 - Comando "show ip eigrp neighbor"

Come potete vedere adesso i contatori partono da 30 secondi. In circostanze normali
non e' necessario alterare i valori dei timer.
Redistribuzione

Nel caso di redistribuzione qualsiasi route proveniente da altri algoritmi (RIP, IGRP
etc.) per default entra in EIGRP con una metrica pari a -1. Pertanto e' necessario fissare
manualmente i valori di metrica da associare a queste route. A tal fine si usa il comando
"default-metric" che ha la sintassi: “default-metric BANDWIDTH(in k) DELAY
RELIABILITY LOAD MTU” . La distanza amministrativa invece e' settata al valore di 170.
Compattamento delle route (summarization)

Pagina 41
 Configurazione dei router Cisco

EIGRP fa summarization in automatico. E’ possibile disabilitare la summarization con il

comando “no auto-summary”. E’ possibile fare manual summarization con “ip summary-
address eigrp AS NETWORK NETMASK”. Nell’ipotesi in cui questa feature non sia voluta,
come quando vi e’ discontinuita’ nell’uso delle subnet in una rete, basta inserire il
comando ‘no auto-summary’ nella propria configurazione di EIGRP.
Interfacce passive

Questo argomento vale per RIP, IGRP e EIGRP. Se in una interfaccia non fanno capo
altri router coinvolti nel routing dinamico non ha senso che da quella interfaccia vi siano
annunci o si ricevano.
Per evitare che da una interfaccia, in cui e' attivo il protocollo di routing, vi siano
annunci si utilizza il comando 'passive-interface nome' nella configurazione EIGRP.
Il comando passive-interface ha anche importanza per la sicurezza della rete. Se le
sessioni EIGRP tra neighbors non sono autenticate chiunque potrebbe inserire route
EIGRP nella LAN e annunciare reti. Quindi le interfacce che non sono coinvolte nel traffico
EIGRP devono essere passive.
IP secondari

EIGRP usa l'ip primario di una interfaccia per fare gli annunci. Interfacce con l'ip
secondario possono generare l'errore:

*May 12 12:25:48.602: IP-EIGRP(Default-IP-Routing-Table:100): Neighbor

192.168.184.1 not on common subnet for FastEthernet0/1

Figura 68 - EIGRP e IP secondari

Se ne siamo consapevoli e vogliamo evitare che la segnalazione arrivi in console dentro
la configurazione di EIGRP usiamo il comando 'no eigrp log-neighbor-warnings'
Route di default

Il tipico comando utilizzato per la route di default e' il seguente:

ip route 0.0.0.0 0.0.0.0 A.B.C.D

Figura 69 - EIGRP e routing di default

EIGRP propaga la route di default 0.0.0.0 se e' presente il comando "redistribute
static" e se e' presente una riga di routing di default statica. Se si vuole propagare una
rete di defalt differente bisogna specificarla col comando “ip default-network NETWORK”.
Questo a differenza di IGRP che vuole sempre “ip default-network ...”.
Conclusione

Per concludere una serie di brevi su EIGRP:

- EIGRP funziona solo per gli ip primari di un collegamento. Se ci sono indirizzi secondari
su un’interfaccia non saranno usati per identificare un vicino;
- EIGRP usa il numero di protocollo IP 88;
- Per default l’hop-count massimo di EIGRP e’ posto a 100, e’ settabile a max 255;
- EIGRP ha distanza amministrativa pari a 90;
- La metrica di EIGRP e 256 volte quella di IGRP. Se in un router girano entrambi gli
algoritmi la redistribuzione tra loro si ha di default.

Pagina 42
 Configurazione dei router Cisco

Esempi sulla propagazione della route di default in RIP-IGRP-EIGRP

Nell'esempio a seguire due router, "itesys1" e "itesys2" sono collegati tra loro tramite
WAN. Il router "itesys2" ha accesso ad internet tramite un gateway in LAN, con IP
192.168.0.1. L'esempio mostra come si propagano le route di default con RIP, IGRP e
EIGRP.

... snip ...

!
interface FastEthernet0/0
ip address 192.168.0.2 255.255.255.0
!
interface Serial0/0
ip address 128.10.10.2 255.255.255.252
!
router rip
network 128.10.0.0
network 192.168.0.0
default-information originate
!
router igrp 10
network 128.10.10.0
network 192.168.190.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.0.1
... snip ...

Figura 70 - RIP,IGRP e EIGRP route di default - Router 'itesys2'

Vediamo cosa succede in itesys1(anch'esso con RIP che IGRP):

itesys1#sh ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 128.10.10.2 to network 0.0.0.0

C 192.168.94.0/24 is directly connected, FastEthernet0/0

128.10.0.0/30 is subnetted, 1 subnets
C 128.10.10.0 is directly connected, Serial0/0
I 192.168.0.0/24 [100/8486] via 128.10.10.2, 00:00:00, Serial0/0
R* 0.0.0.0/0 [120/1] via 128.10.10.2, 00:00:25, Serial0/0

Figura 71 - Router 'itesys1': tabella di routing

IGRP non propaga la route di default cosi' non la sovrascrive. Invece la route RIP
relativa alla classe 192.168.0.0 viene sovrascritta a causa della minore AD di IRGP.

Adesso togliamo il RIP. Ad 'itesys2' facciamo propagare tramite IGRP la route di default.
"default-information originate" non serve allo scopo cosi' come "redistribute static" o "ip
default-gateway". E' necessario l'uso del comando "ip default-network".

itesys2(config)#ip default-network ?

Pagina 43
 Configurazione dei router Cisco

A.B.C.D IP address of default network

itesys2(config)#ip default-network 192.168.0.0
itesys2#sh run
Building configuration...
...snip...
!
router igrp 10
network 128.10.0.0
network 192.168.0.0
!
ip classless
ip default-network 192.168.0.0
ip route 0.0.0.0 0.0.0.0 192.168.0.1
ip route 192.168.0.0 255.255.255.0 192.168.0.1
...snip...

Figura 72 - Router 'itesys2': comando default-network

Comando "ip default-network" nel router itesys2

itesys2#sh ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 192.168.0.1 to network 0.0.0.0

I 192.168.94.0/24 [100/8486] via 128.10.10.1, 00:00:05, Serial0/0

128.10.0.0/30 is subnetted, 1 subnets
C 128.10.10.0 is directly connected, Serial0/0
C* 192.168.0.0/24 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 [1/0] via 192.168.0.1

Figura 73 - Router 'itesys2': tabella di routing dopo l'inserimento di "ip default-network"

Notate come la Fast0/0 abbia C* nella tabella di routing. La presenza dell'asterisco e'
conseguenza della default-network. Questa informazione sara' propagata da IGRP come
si vede in figura:

itesys1#sh ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 128.10.10.2 to network 192.168.0.0

C 192.168.94.0/24 is directly connected, FastEthernet0/0

128.10.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 128.10.10.0/30 is directly connected, Serial0/0
D 128.10.0.0/16 is a summary, 00:01:42, Null0
D* 192.168.0.0/24 [90/2172416] via 128.10.10.2, 00:01:16, Serial0/0

Pagina 44
 Configurazione dei router Cisco

Figura 74 - Router 'itesys1': tabella di routing

Rivediamo la configurazione di itesys2 togliendo RIP e aggiungendo EIGRP. Togliamo il
comando "ip default-network":

...snip...
!
router eigrp 15
network 128.10.0.0
network 192.168.0.0
!
router igrp 10
network 128.10.0.0
network 192.168.0.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.0.1
ip route 192.168.0.0 255.255.255.0 192.168.0.1
...snip...

Figura 75 - Router 'itesys2'

itesys1#sh ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 128.10.10.2 to network 192.168.0.0

C 192.168.94.0/24 is directly connected, FastEthernet0/0

128.10.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 128.10.10.0/30 is directly connected, Serial0/0
D 128.10.0.0/16 is a summary, 00:02:23, Null0
D 192.168.0.0/24 [90/2172416] via 128.10.10.2, 00:00:25, Serial0/0

Figura 76 - Router 'itesys1'

Togliamo il comando "ip default-network" e, per propagare la route di default con EIGRP
utilizziamo il comando "redistribute static":

itesys2(config)#router eigrp 15
itesys2(config-router)#redistribute static

Figura 77 - Router 'itesys2'

Modifica della configuraizione di itesys2. Ecco come cambia la tabella di routing in

itesys1:

itesys1#sh ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR

Pagina 45
 Configurazione dei router Cisco

P - periodic downloaded static route

Gateway of last resort is 128.10.10.2 to network 0.0.0.0

C 192.168.94.0/24 is directly connected, FastEthernet0/0

128.10.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 128.10.10.0/30 is directly connected, Serial0/0
D 128.10.0.0/16 is a summary, 00:02:57, Null0
D 192.168.0.0/24 [90/2172416] via 128.10.10.2, 00:00:59, Serial0/0
D*EX 0.0.0.0/0 [170/2172416] via 128.10.10.2, 00:00:14, Serial0/0

Figura 78 - Tabella di routing di 'itesys1'

Come si puo' osservare una riga di routing di default e' stata aggiunta. Con EIGRP e'
utilizzabile anche il comando "ip default-network".

Il monitoraggio

Cisco IP Service Level Agreement (IP SLA)

Per Service Level Agreement (SLA) si intende un contratto siglato tra un fornitore
(network provider) ed un cliente dove ci si impegna a fornire un servizio con delle
specifiche ben definite. Ad esempio una continuita' di servizio del 99% con una latenza
massima ben precisa, con un servizio di assistenza con risposta garantita entro un certo
tempo dalla chiamata.

Il network provider per poter garantire questi servizi deve configurare i circuiti dati
opportunamente. In caso di reti provviste di un buon supporto alla qualita' del servizio,
come le reti ATM o Frame-Relay o le piu' moderne MPLS, e' possibile fare cio' utilizzando
le funzionalita' dei protocolli. In caso di reti sprovviste di tali protocolli ma basate sul
TCP/IP (Internet) non e' altrettanto semplice. Se ci fossero a disposizione una serie di
comandi con cui il router potesse automaticamente verificare la rispondenza di un link ai
valori contrattualizzati, intervenendo di conseguenza quanto piu' automaticamente
possibile, il network provider potrebbe utilizzare in modo piu' efficiente la propria rete e
aumentarne la produttivita'. Questo e' di fatto possibile con la funzionalita' Cisco IP SLA,
disponibile su tutte le piattaforme hardware IOS all'incirca della versione 12.2T
(Catalyst 65XX a partire dalla 12.2(33)SXI1 per il comando "ip sla").
Abbiamo pertanto a disposizione una nuova famiglia di comandi pensata
principalmente per consentire misure sulle performance della rete in tempo reale ed
intervenire automaticamente con delle azioni in conseguenza al verificarsi di determinati
eventi. Quindi non si ha la possibilita' di monitorare un servizio Internet, come la
raggiungibilita' di un indirizzo IP, oppure la raggiungibilita' di un servizio web, o lo stato di
una interfaccia, o la latenza ma anche di eseguire delle azioni in conseguenza all'attivita'
monitorata. Il numero di attivita' monitorabili dipende dalla versione di IOS. E'
interessante notare che le performance vengono monitorate attivamente, ovvero con la
generazione di traffico.

La quantita' di servizi e funzionalita' monitorabili e' davvero ampia. Con qualche

esempio si potra' capirne il principio di funzionamento.
E' anche possibile configurare dei threshold per cui al superare di determinate soglie il
router invia una trap SNMP. In alternativa da CLI si possono verificare gli SLA.
Per alcune funzionalita' di monitoraggio e' necessario configurare un router mittente e
uno ricevente, quest'ultimo in modalita' "IP SLA responder" che replica ai pacchetti di

Pagina 46
 Configurazione dei router Cisco

monitoraggio inviati dal primo, in modo da verificare alcuni parametri di circuito. Con il
comando "ip sla responder" (oppure "ip sla monitor responder") e' possibile attivare in un
secondo router Cisco un risponditore automatico per alcuni tipi di richieste inviate da una
configurazione "ip sla" di un primo router. Ad esempio se si utilizza il monitoraggio
dell'UDP Jitter (udp-jitter), che poi monitorizza anche il packet-loss e altri parametri, e'
necessario un risponditore all'altro capo della tratta da monitorare. Questo e'
estremamente utile per la VoIP perche' la qualita' del link e' fondamentale per la qualita'
della voce.
Configurazione IP SLA

In questi parametri ci limiteremo a delle configurazioni di base. Una volta capito il

principio di funzionamento sara' possibile preparare delle configurazioni piu' specifiche.
Supponiamo di voler monitorare la raggiungibilita' di un indirizzo IP.
La configurazione di uno SLA viene effettuata con il comando "ip sla". Dopo aver
preparato il proprio SLA si attiva utilizzando il comando "ip sla schedule". Una volta attivo
non e' piu' modificabile. Se necessario dovremo cancellarlo dalla configurazione e
ricrearlo.
Per verificare le possibilita' di monitoraggio offerte dall'IOS del nostro router possiamo
aiutarci con l'help di linea del CLI, come in figura:

giarout(config)#ip sla 12
giarout(config-ip-sla)#?
IP SLAs entry configuration commands:
dhcp DHCP Operation
dns DNS Query Operation
ethernet Ethernet Operations
exit Exit Operation Configuration
frame-relay Frame-relay Operation
ftp FTP Operation
http HTTP Operation
icmp-echo ICMP Echo Operation
icmp-jitter ICMP Jitter Operation
mpls MPLS Operation
path-echo Path Discovered ICMP Echo Operation
path-jitter Path Discovered ICMP Jitter Operation
tcp-connect TCP Connect Operation
udp-echo UDP Echo Operation
udp-jitter UDP Jitter Operation
voip Voice Over IP Operation
giarout(config-ip-sla)#voip ?
delay Delay measurement rtp RTP Stream VoIP Measurements

Figura 79 - Comando "ip sla"

Nel nostro SLA pretendiamo un tempo di risposta inferiore ai 20ms. Il test viene
effettuato ogni 70 secondi. Nel caso in cui per 5 volte consecutive il test fallisce si genera
una trap e si genera un trigger. Quest'ultimo ha la funzione di fare partire un secondo
sla, il numero "11" che non e' riportato nell'esempio ma che effettua dei test aggiuntivi. E'
possibile evitare il trigger e lasciare la trap. Utilizzando il comando "track" o "Cisco EEM" e'
possibile alterare il funzionamento del router (vedi paragrafi successivi). Oppure possiamo
evitare sia trap che trigger e limitare le verifiche a quella manuale tramite CLI, in una
configurazione di base. In questo esempio non e' necessario configurare il router
ricevente l'ICMP come responder, in quanto l'ICMP da se implica una risposta da parte del
router remoto. Ovviamente il router remoto deve essere configurato per rispondere
all'ICMP.

ip sla 10

Pagina 47
 Configurazione dei router Cisco

icmp-echo 192.168.30.1 source-interface GigabitEthernet0/1

timeout 20
frequency 70
ip sla schedule 10 life forever start-time now
ip sla reaction-configuration 10 react connectionLoss threshold-type consecutive
5 action-type trapAndTrigger
ip sla reaction-trigger 10 11

Figura 80 - Configurazione di base 'ip sla'

Con il comando "show ip sla configuration 10" possiamo verificare che la configurazione
dello sla 10 sia stata recepita correttamente, e visionarne i parametri in dettaglio:

giatisc#show ip sla configuration 10

IP SLAs, Infrastructure Engine-II.
Entry number: 10
Owner:
Tag:
Type of operation to perform: icmp-echo
Target address/Source interface: 192.168.30.1/GigabitEthernet0/1
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Operation timeout (milliseconds): 20
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 70 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000 (not considered if react RTT is configured)
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Enhanced History:

Figura 81 - Comando 'show ip sla configuration'

Verifiche SLA

Relativamente all'esempio del paragrafo precedente vediamo come verificare che lo

SLA sia correttamente funzionante e come vedere le statistiche. Come si vede nel
riquadro successivo dal momento dell'avvio ci sono stati 4 successi e 1 fallimento, non
sufficiente all'invio di una trap e all'avvio dello sla "11".

giarout#show ip sla statistics 10

IPSLAs Latest Operation Statistics

IPSLA operation id: 10

Type of operation: icmp-echo

Pagina 48
 Configurazione dei router Cisco

Latest RTT: 1 milliseconds

Latest operation start time: *14:18:43.961 UTC Fri Sep 11 2009
Latest operation return code: OK
Number of successes: 4
Number of failures: 1
Operation time to live: Forever

Figura 82 - Comando 'show ip sla statistics'

giarout#show ip sla reaction-configuration 10

Entry number: 10
Index: 1
Reaction: connectionLoss
Threshold Type: Consecutive
Threshold CountX: 5
Threshold CountY: 5
Action Type: Trap and trigger

Figura 83 - Comando 'show ip sla reaction-configuration'

giarout#show ip sla reactiontrigger 10

Entry number: 10
Target Entry Number: 11
Status of Entry (SNMP RowStatus): active
Operational State: pending

Figura 84 - Comando 'show ip sla reactiontrigger'

Esempio di monitoraggio "ftp"

Modificando l'esempio precedente con i seguenti comandi monitoriamo in base alla

raggiungibilita' ftp:

ip sla 10
ftp get ftp://anonymous:test@@ftp.gianrico.com/ mode active
ip sla schedule 10 life forever start-time now

Figura 85 - Monitoraggio ftp con 'ip sla'

Il comando "track"

Il comando "track" viene utilizzato normalmente per monitorare lo stato di

un'interfaccia, spesso in configurazioni con la ridondanza HSRP o GLBP. Sostanzialmente
piu' router partecipano ad un gruppo ed hanno priorita' variabili in base allo stato delle
loro interfacce, monitorate ("tracked" da cui "track"). Un evoluzione del comando si lega
all'IP SLA e permette delle azioni diverse rispetto la generazione di trap oppure trigger
nel caso di superamento di un threshold. Il comando da utilizzare e' "track ip sla", ovvero
"track rtr" nei primi IOS dove e' stata introdotta la funzionalita'. Questa funzionalita' e'
stata introdotta con IOS 12.3(4)T .
Esempio di uso tradizionale del comando "track"

Siano allora assegnati i seguenti comandi di configurazione:

track 10 interface ATM0/3/0 line-protocol

Pagina 49
 Configurazione dei router Cisco

delay down 5 up 30
ip route 18.181.0.0 255.255.255.0 dialer0 track 10 (1)

Figura 86 - Comando 'track'

Allora se il protocollo dell'interfaccia ATM0/3/0 cambia nello stato di down per oltre 5
secondi la riga di routing (1) viene tolta dalla tabella di routing.
Con i comandi "show track" e "show track brief" si puo' verificare lo stato del monitoring:

gia-gw#show track 10
Track 10
Interface ATM0/3/0 line-protocol
Line protocol is Up
1 change, last change 00:06:27
Delay up 30 secs, down 5 secs
Tracked by:
STATIC-IP-ROUTING 0

gia-gw#show track brief

Track Object Parameter Value Last Change
10 interface ATM0/3/0 line-protocol Up 00:07:07

Figura 87 - Comando 'show track'

Con il comando "debug track" e' possibile fare il debugging degli eventi. Ecco cosa
succede quando il protocollo dell'interfaccia Atm0/3/0 passa nello stato di down:

000917: Jan 20 16:09:43.646: Track: 10 Down change delayed for 5 secs

000923: Jan 20 16:09:48.646: Track: 10 Down change delay expired
000924: Jan 20 16:09:48.646: Track: 10 Change #4 interface ATM0/3/0, line-
protocol Up->Down

Figura 88 - Debug: track transizione down su interfaccia

in questo punto non c'e' la route (1) in tabella di routing.

000934: Jan 20 16:12:29.079: Track: 10 Up change delay expired

000935: Jan 20 16:12:29.079: Track: 10 Change #5 interface AT0/3/0, line-protocol
Down->Up

Figura 89 - Debug: track transizione up su interfaccia

Con il comando "show ip route track-table" si puo' vedere lo stato delle route con
tracking:

gia-gw#show ip route track-table

ip route 18.181.0.0 255.255.255.0 Dialer1 track 10 state is [up]

Figura 90 - Comando 'show ip route track-table'

Esempio "track" con "ip sla"

Siano assegnati i seguenti comandi di configurazione:

ip name-server 192.168.30.30
ip domain-lookup
ip sla 10
http get http://www.itesys.it

Pagina 50
 Configurazione dei router Cisco

frequency 100
ip sla schedule 10 life forever start-time now

track 50 ip sla 10 ("track 50 rtr 10" in vecchie versioni)

ip route 18.181.0.31 255.255.255.255 Serial0/0/0.1 track 50 (2)

Figura 91 - Esempio di configurazione 'ip sla' con 'track'

Anche se praticamente la configurazione puo' non avere molto senso, dal punto di vista
didattico e' utile. Se il sito web http://www.itesys.it diventa irraggiungibile la riga di
routing (2) viene tolta dalla tabella di routing. Con il comando "debug ip sla trace" si puo'
vedere lo stato del tracking:

*Jan 20 16:26:16.532: IP SLAs(10) Scheduler: saaSchedulerEventWakeup

*Jan 20 16:26:16.532: IP SLAs(10) Scheduler: Starting an operation
*Jan 20 16:26:16.532: IP SLAs(10) http operation: Starting http operation
*Jan 20 16:26:16.532: IP SLAs(10) dns operation: Starting dns operation
*Jan 20 16:26:16.532: IP SLAs(10) dns operation: Query name - www.itesys.it
*Jan 20 16:26:16.532: IP SLAs(10) dns operation: Query name server - 151.99.125.2
*Jan 20 16:26:16.532: IP SLAs(10) dns operation: actual target queried =
www.itesys.it
*Jan 20 16:26:16.616: IP SLAs(10) dns operation: Query return code - no error
*Jan 20 16:26:16.616: IP SLAs(10) dns operation: received IP Address 82.85.14.71
*Jan 20 16:26:16.616: IP SLAs(10) dns operation: RTT=87
*Jan 20 16:26:16.760: IP SLAs(10) http operation: Sent 18 of 18 bytes
*Jan 20 16:26:16.760: IP SLAs(10) http operation: Wait connection - connected
*Jan 20 16:26:16.948: IP SLAs(10) http operation: Time to first byte: 328 ms
*Jan 20 16:26:16.948: IP SLAs(10) http operation: RTT=417
*Jan 20 16:26:16.948: IP SLAs(10) Scheduler: Updating result

Figura 92 - Comando 'debug ip sla trace'

Nel caso in cui la risoluzione del nome fallisca, oppure l'indirizzo ip del sito web diventa
irraggiungibile, oppure il server web non risponde alla porta 80 per il sito web indicato, la
riga di routing (2) viene tolta dalla tabella di routing.
E' possibile unire piu' sla con un track del tipo:

track 111 list boolean and

object 10
object 20

Figura 93 - Comando 'object' con 'track'

Integrando gli esempi precedenti e aggiungendo un routing di default del tipo:

ip route 0.0.0.0 0.0.0.0 192.168.10.1 track 223

ip route 0.0.0.0 0.0.0.0 192.168.20.2 track 324 200

Figura 94 - 'ip route' con 'track'

In questo caso possiamo cambiare il gateway in accordo ad uno o piu' eventi monitorati.
Le "floating route" individuate da una metrica piu' alta hanno il limite di essere utilizzate
solo nel caso in cui il next-hop non sia raggiungibile e cio' accade solo nel caso di
interfacce fisiche del router nello stato di down.

Nota 1: spesso i server web rispondono comunque nel caso in cui un singolo sito web non
sia funzionante, magari con messaggi del tipo "service unavailable". In questo caso per il

Pagina 51
 Configurazione dei router Cisco

router il sito web e' funzionante!

Nota 2: nelle prime versioni di IOS si puo' trovare il comando "rtr" invece di "ip sla".
Nelle versioni dalla 12.4(20)T invece "track ... sla..." invece di "track ... rtr..."

Nota 3: Nel caso si utilizzi il 'track' con 'rtr' osservate che non si puo' utilizzare il
"consecutive" in "ip sla react configuration". Per fare in modo tale da scatenare un evento
dopo un certo numero di ping falliti bisogna utilizzare un "delay" sufficientemente lungo in
'track' e dei valori di 'frequency' e 'timeout' sufficientemente corti in 'ip sla' in modo da
farci cadere il numero di pacchetti icmp voluti
Cisco ASA, "track" & "ip sla"

Molte delle funzionalita' dei paragrafi precedenti, seppur con alcune differenze, sono
anche disponibili sui firewall Cisco ASA e PIX 7.X. Ecco come, con un Cisco ASA gestire un
backup su un gateway differente in caso di irraggiungibilita' di in un primo gateway:

sla monitor 123

type echo protocol ipIcmpEcho 18.87.179.129 interface outside
num-packets 5
frequency 5
sla monitor schedule 123 life forever start-time now

track 1 rtr 123 reachability

route outside 0.0.0.0 0.0.0.0 18.87.157.93 1 track 1

route outside 0.0.0.0 0.0.0.0 18.87.157.90 100

Figura 95 - Cisco ASA: comandi 'sla monitor' e 'track'

Con i comandi "show ip sla statistics", "show ip sla configuration", "show track" e'
possibile monitorare lo stato:

gia#show ip sla statistics

Round Trip Time (RTT) for Index 10
Latest RTT: 0 milliseconds
Latest operation start time: *17:00:33.988 UTC Tue Jan 20 2009
Latest operation return code: DNS query error <-- sito web non raggiungibile
per errore nella risoluzione del nome
Latest DNS RTT: 0 ms
Latest TCP Connection RTT: 0 ms
Latest HTTP Transaction RTT: 0 ms
Number of successes: 0
Number of failures: 13
Operation time to live: Forever

gia#show track 50
Track 50
Response Time Reporter 10 state
State is Down <-- stato down, route non in tabella, in quanto il
sito web non e' raggiungibile
11 changes, last change 00:21:11
Latest operation return code: DNS query error
Tracked by:
STATIC-IP-ROUTING 0

gia#show ip sla configuration 10

IP SLAs, Infrastructure Engine-II.
Entry number: 10
Owner:

Pagina 52
 Configurazione dei router Cisco

Tag:
Type of operation to perform: http
Target address/Source address: 0.0.0.0/0.0.0.0
Target port/Source port: 80/0
Operation timeout (milliseconds): 60000
Type Of Service parameters: 0x0
HTTP Operation: get
HTTP Server Version: 1.0
URL: http://www.itesys2.it
Proxy:
Raw String(s):
Cache Control: enable
Schedule:
Operation frequency (seconds): 100 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None

gia#show ip route track-table

ip route 18.181.0.31 255.255.255.255 Serial0/0/0.1 track 50 state is [down]

Figura 96 - Cisco ASA: comandi 'show ip sla' e 'show track'

Cisco EEM - Embedded Event Manager -

Cisco IOS Embedded Event Manager (EEM) e' un potente modulo di Cisco IOS che
permette il monitoraggio di eventi e gestione delle casistiche conseguenti a tali eventi.
Puo' essere immaginato come un'evoluzione del "IP SLA" ma in realta' lo affianca e le due
funzionalita' si possono integrare. Disponibile nella versione 1.0 a partire dalla versione di
IOS 12.0(26)S e' consigliabile utilizzarlo a partire da IOS 12.3(4)T.
Event Manager permette di generare script di monitoraggio con IOS o con TCL
consentendo di gestire, dall'interno del router, una gamma infinita di eventi e di
automazione in conseguenza al verificarsi di tali eventi, comprendendo la riconfigurazione
automatica del router stesso per il ripristino di condizioni di fault.
EEM 3.0 e' richiede IOS 12.4(22)T e introduce l'uso di variabili e espressioni regolari.
EEM 3.1 e' stato introdotto con IOS 15.0 con TCL 8.3.4. A seconda della release presente
in IOS, che partono dalla 1.0, le funzionalita' a disposizione possono variare. Verificate
con il "Cisco Feature Navigator" disponibile nel sito web Cisco.
Per conoscere quale versione di EEM avete a disposizione:

Gian-7204#show event manager version

Embedded Event Manager Version 3.10
Component Versions:
eem: (v310_throttle)4.1.1
eem-gold: (v310_throttle)1.0.7

Pagina 53
 Configurazione dei router Cisco

eem-call-home: (v310_throttle)1.0.6
Event Detectors:
Name Version Node Type
application 01.00 node0/0 RP
syslog 01.00 node0/0 RP
...

Figura 97 - Cisco EEM: comando "show event manager"

Configurazione di EEM

Con il comando "event manager applet" (IOS 12.4, dal Cisco 1800 ma non presente in
"IP BASE,PLUS,VOICE,BROADBAND" se non nella fascia alta di modelli, tipo serie 7000,
12.2 altri modeli, quali Catalyst 65XX ) usato insieme a "ip sla reaction-configuration" e'
possibile in conseguenza a degli eventi, in relazione allo sla o al di fuori di esso, come un
messaggio di log del router, definire delle azioni, che possono essere la riconfigurazione
del router stessa. Per esempio:

event manager applet PIPPO

event syslog pattern "Interface Ethernet 0/0, changed status to down"
action 1.0 cli command "enable"
action 1.1 cli command "term mon"
action 1.2 cli command "ip route 10.10.10.0 255.255.255.0 eth1/0"
action 1.2 mail server "192.85.14.73" to "[email protected]" from
"ciscorouter26" subject "interfaccia down" body "attivato routing secondario"

Figura 98 - Cisco EEM: invio email in caso di evento

in caso del messaggio di log indicato, emesso dal router stesso, si inserira' una nuova
riga di route e inviera' una email (EEM V.2.1 almeno per l'invio di email da applet).
Sostanzialmente il router e' in grado di riconfigurarsi!!!
Nell'esempio che segue, in caso di irraggiungibilita' di un indirizzo ip si riconfigura una
interfaccia ethernet aggiungendo il comando "description prova":

catalyst_backup#sh run | section sla

ip sla 10
icmp-echo 10.11.12.13 source-ip 10.11.12.14
timeout 100
ip sla schedule 10 life forever start-time now
track 1 ip sla 10 reachability

catalyst_backup#sh run | section event

event manager applet pingfailed
event track 1 state down <-- 12.4(2)T in IOS almeno
action 1.0 syslog msg " ping failed "
action 1.1 cli command "enable"
action 1.2 cli command "conf termi"
action 2.0 cli command "interface gigabitethernet5/5"
action 3.0 cli command "description prova"
action 4.0 cli command "exit"

Figura 99 - Cisco EEM: riconfigurazione automatica in caso di evento

Nell'esempio che segue monitoriamo due collegamenti e solo nel caso in cui entrambi
siano DOWN eseguiamo l'evento:

catalyst_backup#show run | section sla

Pagina 54
 Configurazione dei router Cisco

ip sla 10
icmp-echo 10.11.12.13 source-ip 10.11.12.14
timeout 100
frequency 20
ip sla schedule 10 life forever start-time now

ip sla 11
icmp-echo 10.11.12.17 source-ip 10.11.12.18
timeout 100
frequency 20
ip sla schedule 11 life forever start-time now

track 111 ip sla 10 reachability

track 112 ip sla 11 reachability

catalyst_backup#show run | section track

track 1 list boolean or

object 111
object 112
track 111 ip sla 10 reachability
track 112 ip sla 11 reachability

catalyst_backup#show run | section event

event manager applet pingfailed
event track 1 state down <-- 12.4(2)T in IOS almeno
action 1.0 syslog msg " ping failed "
action 1.1 cli command "enable"
action 1.2 cli command "conf termi"
action 2.0 cli command "interface gigabitethernet5/5"
action 3.0 cli command "description pippo"
action 4.0 cli command "exit"
action 5.0 mail server "112.112.12.12" to "[email protected]" from
"[email protected]"
subject "corpo del messaggio" body "messaggio di test"

catalyst_backup#show track 1
Track 1
List boolean and
Boolean OR is Up
6 changes, last change 00:10:14
object 111 Up
object 112 Up
Tracked by:
EEM applet pingfailed
catalyst_backup#

Figura 100 - Cisco EEM: riconfigurazione e email in caso di DOWN su due collegamenti
Attenzione che "AND" e "OR" del comando track sono booleani. Ovvero ci vuole un OR
per generare un evento nel caso di contemporaneita' di due FAIL.
Riprendiamo l'esempio 3:

ip sla 10
icmp-echo 18.181.0.31
frequency 120
ip sla schedule 10 life forever start-time now

Figura 101 - Cisco EEM: configurazione di esempio

Pagina 55
 Configurazione dei router Cisco

Con EEM possiamo personalizzare l'evento generato in caso di irraggiungibilita' dell'ip

18.181.0.31 come segue:

track 10
event manager applet PingHasFailed
event track 100 state down
action 1.0 syslog msg "Ping has failed, reloading the router"
action 2.0 reload

Figura 102 - Cisco EEM: evento in caso di irraggiungibilita' ICMP

Con il comando "event manager run" si puo' testare l'applet, ma prima che sia
EEM e gli script TCL di sistema

Gli script TCl forniti da Cisco operano in 'full TCL mode' mentre quelli scritti da un utente
in 'safe TCL mode', una versione di TCL priva di alcuni comandi che, se utilizzati,
potrebbero compromettere il buon funzionamento del sistema.
Ci sono delle policy che Cisco mette a disposizione degli utenti. Per vederle si procede
come segue.
Consideriamo questo ambiente: (C1841-ADVSECURITYK9-M), Version 12.4(9)T6

giarouter#sh event manager policy available

No. Type Time Created Name
€ 1 system Thu Feb 7 06:28:15 2036 sl_intf_down.tcl
2 system Thu Feb 7 06:28:15 2036 tm_cli_cmd.tcl
3 system Thu Feb 7 06:28:15 2036 tm_crash_reporter.tcl
4 system Thu Feb 7 06:28:15 2036 tm_fsys_usage.tcl

routernew#show event manager policy registered

No. Class Type Event Type Trap Time Registered Name

Figura 103 - Cisco EEM: script TCL in dotazione Cisco 1841

Come si vede non ci sono policy registrate. Questo perche' nella configurazione del
router non abbiamo ancora configurato degli eventi.

Ecco l'output del comando equivalente su Cisco 7204 con IOS 15.0(1)M e EEM 3.1

TISC-7204#sh event manager policy available

No. Type Time Created Name
1 system Thu Feb 7 06:28:15 2036 ap_perf_test_base_cpu.tcl
2 system Thu Feb 7 06:28:15 2036 cl_show_eem_tech.tcl
3 system Thu Feb 7 06:28:15 2036 no_perf_test_init.tcl
4 system Thu Feb 7 06:28:15 2036 sl_intf_down.tcl
5 system Thu Feb 7 06:28:15 2036 tm_cli_cmd.tcl
6 system Thu Feb 7 06:28:15 2036 tm_crash_reporter.tcl
7 system Thu Feb 7 06:28:15 2036 tm_fsys_usage.tcl

Figura 104 - Cisco EEM: script TCL in dotazione Cisco 7204

Ecco la descrizione di alcune policy:

Nome Desrizione
Quando un ben preciso messaggio appare nel syslog
sl_intf_down.tcl si esegue un comando CLI configurato, inviandone via
email i risultati.

Pagina 56
 Configurazione dei router Cisco

Questa policy viene eseguita a tempi prefissati

tm_cli_cmd.tcl tramite cron ed esegue un comando, inviando via
email il risultato.
Per vedere il sorgente della policy e quindi le variabili necessarie per poterla utilizzare:

TISC-7204#show event manager policy available detailed tm_cli_cmd.tcl

::cisco::eem::event_register_timer cron name crontimer2 cron_entry $_cron_entry
maxrun 240
#----------------------------------
# EEM policy that will periodically execute a cli command and email the
# results to a user.
#
# July 2005, Cisco EEM team
#
# Copyright (c) 2005-2006 by cisco Systems, Inc.
# All rights reserved.
#----------------------------------
### The following EEM environment variables are used:
###
### _cron_entry (mandatory) - A CRON specification that determines
### when the policy will run. See the
### IOS Embedded Event Manager
### documentation for more information
### on how to specify a cron entry.
### Example: _cron_entry 0-59/1 0-23/1 * * 0-7
###
### _log_file (mandatory without _email_....)
### - A filename to append the output to.
### If this variable is defined, the
### output is appended to the specified
### file with a timestamp added.
### Example: _log_file disk0:/my_file.log
###
### _email_server (mandatory without _log_file)
### - A Simple Mail Transfer Protocol (SMTP)
### mail server used to send e-mail.
### Example: _email_server mailserver.customer.com
###
### _email_from (mandatory without _log_file)
### - The address from which e-mail is sent.
### Example: _email_from [email protected]
###
### _email_to (mandatory without _log_file)
### - The address to which e-mail is sent.
### Example: _email_to [email protected]
###
### _email_cc (optional) - The address to which the e-mail must
### be copied.
### Example: _email_cc [email protected]
###
### _show_cmd (mandatory) - The CLI command to be executed when
### the policy is run.
### Example: _show_cmd show version
###
# check if all the env variables we need exist
# If any of them doesn't exist, print out an error msg and quit
if {![info exists _log_file]} {
if {![info exists _email_server]} {
set result \
"Policy cannot be run: variable _log_file or _email_server has
not been set"

Pagina 57
 Configurazione dei router Cisco

error $result $errorInfo

}
if {![info exists _email_from]} {
set result \
"Policy cannot be run: variable _log_file or _email_from has not
been set"
error $result $errorInfo
}
if {![info exists _email_to]} {
set result \
"Policy cannot be run: variabl _log_file ore _email_to has not
been set"
error $result $errorInfo
}
if {![info exists _email_cc]} {
#_email_cc is an option, must set to empty string if not set.
set _email_cc ""
}
}if {![info exists _show_cmd]} {
set result \
"Policy cannot be run: variable _show_cmd has not been set"
error $result $errorInfo
}
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*
#query the event info and log a message
array set arr_einfo [event_reqinfo]
if {$_cerrno != 0} {
set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \
$_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]
error $result
}
global timer_type timer_time_sec
set timer_type $arr_einfo(timer_type)
set timer_time_sec $arr_einfo(timer_time_sec)
set routername [info hostname]
#log a message
set msg [format "timer event: timer type %s, time expired %s" \
$timer_type [clock format $timer_time_sec]]
action_syslog priority info msg $msg
if {$_cerrno != 0} {
set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \
$_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]
error $result
}
# 1. execute the command
if [catch {cli_open} result] {
error $result $errorInfo
} else {
array set cli1 $result
}
if [catch {cli_exec $cli1(fd) "en"} result] {
error $result $errorInfo
}
# save exact execution time for command
set time_now [clock seconds]
# execute command
if [catch {cli_exec $cli1(fd) $_show_cmd} result] {
error $result $errorInfo
} else {
set cmd_output $result
# format output: remove trailing router prompt
set prompt [format "(.*\n)(%s)(\\(config\[^\n\]*\\))?(#|>)" $routername]

Pagina 58
 Configurazione dei router Cisco

if [regexp "[set prompt]" $result dummy cmd_output] {

# do nothing, match will be in $cmd_output
} else {
# did not match router prompt so use original output
set cmd_output $result
}
}
if [catch {cli_close $cli1(fd) $cli1(tty_id)} result] { error $result $errorInfo
}
# 2. log the success of the CLI command
set msg [format "Command \"%s\" executed successfully" $_show_cmd]
action_syslog priority info msg $msg
if {$_cerrno != 0} {
set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \
$_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]
error $result
}
# 3. if _log_file is defined, then attach it to the file
if {[info exists _log_file]} {
# attach output to file
if [catch {open $_log_file a+} result] {
error $result
}
set fileD $result
# save timestamp of command execution
# (Format = 00:53:44 PDT Mon May 02 2005)
set time_now [clock format $time_now -format "%T %Z %a %b %d %Y"]
puts $fileD "%%% Timestamp = $time_now"
puts $fileD $cmd_output
close $fileD
}
# 4. if _email_server is defined send the email out
if {[info exists _email_server]} {
if {[string match "" $routername]} {
error "Host name is not configured"
}
if [catch {smtp_subst [file join $tcl_library email_template_cmd.tm]} \
result] {
error $result $errorInfo
}
if [catch {smtp_send_email $result} result] { error $result $errorInfo }
}

Figura 105 - Cisco EEM: come vedere il sorgente di uno script

Per utilizzare questa policy in modalita' config bisogna inizializzare i valori delle variabili.
Quindi si registra la policy, ovvero la si attiva.

GIA-7204(config)#event manager environment _cron_entry 0-59/2 0-23/1 * * 0-6

GIA-7204(config)#event manager policy tm_cli_cmd.tcl type system
GIA-7204#show event manager environment all
No. Name Value
1 _cron_entry 0-59/2 0-23/1 * * 0-6
...
GIA-7204#show event manager policy registered
No. Class Type Event Type Trap Time Registered Secu Name
1 script system timer cron Off Sat Dec 26 13:20:42 2009 none
tm_cli_cmd.tcl
name {crontimer2} cron entry {0-59/2 0-23/1 * * 0-6}
nice 0 queue-priority normal maxrun 240.000 scheduler rp_primary

Figura 106 - Cisco EEM: registrazione delle policy

Per utilizzare la policy tm_cli_cmd.tcl e' necessario che siano configurati i comandi

Pagina 59
 Configurazione dei router Cisco

'hostname' e 'ip domain-name'

Verifichiamo se e' stata eseguita:

GIA-7204#show event manager history events

No. Job Id Proc Status Time of Event Event Type Name
1 1 Actv success Sat Dec26 13:22:00 2009 timer cron script: tm_cli_cmd.tcl
2 2 Actv success Sat Dec26 13:24:00 2009 timer cron script: tm_cli_cmd.tcl

Figura 107 - Cisco EEM: comando "show event manager history events"
Se ci sono problemi usare: debug event manager
Per modificare le policy di sistema e' necessario creare un nuovo file copiandone il
contenuto e caricarlo nella cartella dei propri file tcl personali, creata secondo come
spiegato nel successivo paragrafo.
EEM e gli script TCL creati dall'utente

La prima cosa da fare quando si vogliono scrivere script TCL e' definire nel router la
directory dove verranno posizionati. Procediamo come segue:

TISC-7204#mkdir disk2:/usertclscript
Ceate directory filename [usertclscript]?
Created dir disk2:/usertclscript

Directory of disk2:/
...
3 drw- 0 Dec 26 2009 13:33:42 +00:00 usertclscript
...
128679936 bytes total (40960000 bytes free)

Figura 108 - Cisco EEM: creazione directory con il comando 'mkdir'

GIA-7204#conf t
Enter configuration commands, one per line. End with CNTL/Z.
GIA-7204(config)#event manager directory user library disk2:/usertclscript
GIA-7204(config)#event manager directory user policy disk2:/usertclscript
GIA-7204#show event manager directory user library
disk2:/usertclscript
GIA-7204#show event manager directory user policy
disk2:/usertclscript
GIA-7204#

Figura 109 - Cisco EEM: registrazione directory per gli script

I nomi degli script TCL devono seguire le convenzioni Cisco. Ci limitiamo alla piu'
comune, ovvero tutti i file devono terminare con ".tcl".
Minicorso di TCL

Ovviamente non si puo' apprendere un linguaggio di programmazione con un paragrafo di

spiegazioni. Per imparare il TCL si rimanda ad un testo specifico. In ogni caso in questo
paragrafo diamo qualche indicazione.

Per poter inserire comandi TCL si deve entrare nella shell TCL di IOS. Si entra nella shell
comandi TCL con il comando "tclsh".

Pagina 60
 Configurazione dei router Cisco

Sequenza comandi Output

gian(tcl)#puts "ciao" ciao

gian(tcl)#set miavar 5 5

gian(tcl)#puts $miavar 5

Cisco IOS Software, 1841 Software (C1841-

gian(tcl)#exec "show ver | include IOS" ADVSECURITYK9-M), Version 12.4(9)T6,
RELEASE SOFTWARE (fc2)
gian(tcl)#ios_config "ip cef"

usage: snmp_getbulk community_string

gian(tcl)#snmp_getbulk non_repeaters max_repetitions oid [oid2 oid3
...]

gian(tcl)#snmp_getone itesys88 1.3.6.1.2.1.1.4.0 {<obj oid='system.4.0' val=''/>}

'itesys88' e' la password di snmp del router.
L'interrogazione restituisce:
{<obj oid='system.1.0' val='Cisco IOS
gian(tcl)#snmp_getid itesys88 Software, 1841 Software (C1841-
ADVSECURITYK9-M), Version 12.4(9)T6,
RELEASE SOFTWARE (fc2)
...
usage: snmp_setany community_string oid
type val [oid2 type2 val2...]
where type is:
-i integer32
-u unsigned32
gian(tcl)#snmp_setany -c counter32
-g gauge
-o octet string
-d display string
-ipv4 ip address
-oid object identifier
usage: snmp_getone community_string oid
gian(tcl)#snmp_getone
[oid2 oid3 ...]

gian(tcl)#set X "Variabile stringa" Variabile stringa

gian(tcl)#set Y 1.25 1.25

gian(tcl)#puts $X Variabile stringa

gian(tcl)#puts $Y 1.25

gian(tcl)#puts "il valore numerico e': $Y" il valore numerico e': 1.25

1
gian(tcl)#puts "1 \n 2 \n"
2

gian(tcl)#puts "\$Y" $Y

gian(tcl)#puts "\t colonna1 \t colonna2" colonna1 colonna2

gian(tcl)#puts {$X $Y} $X $Y

gian(tcl)#puts "$Y*2" 1.25*2

gian(tcl)#expr {$Y*3} 3.75

Pagina 61
 Configurazione dei router Cisco

<--- ci vuole lo spazio dopo "expr". Le

parentesi quadre valutano l'espressione,
gian(tcl)#puts [expr{$Y*3}] come l'apice nella shell di linux
invalid command name "expr{1.25*3}" ^
% Invalid input detected at '^' marker.

gian(tcl)#puts [expr {$Y*3}] 3.75

gian(tcl)#set b(1) 1 <--array 1

gian(tcl)#set b(2) 2 2

gian(tcl)#puts $b(2) 2

0
1
2
3
4
5
6
7
8
9
gian(tcl)#for {set i 0 } { $i <= 20} {incr i} {puts $i} 10
11
12
13
14
15
16
17
18
19
20

gian(tcl)#while {$x < 12} {

+>puts $x 10
+>set x [expr {$x +1}] 11
+>}

gia(tcl)#set x 10 10

vale 3
gia(tcl)#if {$x == 2} {puts "vale 2"} else {puts "vale 3"}

gia(tcl)#if {$x != 3} {puts "ciao"} ciao

gia(tcl)#set x 20 20

gia(tcl)#switch $x {
+>"10" { puts "dieci"}
venti
+>"20" { puts "venti"}
+>}

gia(tcl)#set x 12 12

gia(tcl)#incr x 13

gia(tcl)#incr x 14

gia(tcl)#puts $x 14

Pagina 62
 Configurazione dei router Cisco

gia(tcl)#proc moltiplica {var1 var2} {

+>set x [expr {$var1 * $var2}]
+>return $x
6
+>}

gia(tcl)#puts [moltiplica 2 3]

gia(tcl)#set a [list a b c 1 5 6] abc156

gia(tcl)#set x [lsearch $a 5] 4

gia(tcl)#set y [lsort $a] 156abc

gia(tcl)#string match *gia* "oggi egian" 1

gia(tcl)#string match *gia* "oggi egan" 0

gia(tcl)#string length [set x "ciao"] 4

Figura 110 - Il linguaggio TCL

I namespace in TCL sono collezioni di procedure e variabili. Sono un po' come le classi in
C. Permettono di creare librerie di funzioni che non interferiscono con il codice esterno al
namespace. Per esempio le variabili in un namespace possono avere lo stesso nome di
altre variabili in altri namespace. I "::" indicano la gerarchia e all'inizio indicano il
namespace globale. Sotto il namespace globale c'e' definito il namespace "cisco" che ha
"eem" come namespace nidificato.
- La prima riga di uno script TCL e' di fondamentale importanza in quanto definisce
quando lo script verra' eseguito. Ci sono numerose possibilita' e per un elenco completo
consultate il sito della cisco.
- Le righe successive normalmente verificano che l'utente abbia inserito un valore per
le variabili di ambiente:

if![info exists _email_server]} {

set result \
"Policy cannot be run: variable _email_server has not been set"
error $result $errorInfo
}

Figura 111 - TCL: variabili di ambiente

- Poi vanno importate le procedure di sistema, utilizzate in molti script:

namespace import ::cisco::eem::*

namespace import ::cisco::lib::*

Figura 112 - TCL: 'namespace'

- Segue il codice vero e proprio.
Ecco un esempio di un semplice script, lanciato manualmente, che non fa altro che
eseguire alcuni comandi:

:cisco::eem::event_register_none
#'event_register_none':

Pagina 63
 Configurazione dei router Cisco
# allora questa policy viene eseguita da cli quando si esegue il comando
'event manager run'
# - Si puo' anche usare 'event_register_timer'
# per indicare ogni quanto la policy dev'essere eseguita
# - Si puo' anche usare 'event_register_syslog'
# per fare eseguire la policy se nel syslog appare un
# certo messaggio per un certo numero di volte
# - Si puo' anche usare 'event_register_ipsla'
# per fare eseguire la policy in conseguenza ad un trigger 'ip sla'
# - Si puo' anche usare 'event_register_inteface'
# per far eseguire la policy se un contatore in una interfaccia
# supera una certa soglia
# - Si puo' anche usare 'event_register_rpc'
# per far eseguire la query da un sistema remoto tramite SSH.
# Vedi anche perl 'CISCO::EEM::RPC'
# Vedi anche nel sito Cisco cerca "Writing Embedded Event Manager Policies Using Tcl".
#
#
# This is a simple example of issuing an ios exec command and
# storing the output in a file
#
#
# Namespace imports
#
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*
#
#
# Local procedure for CLI interface
# Pass a list of cli commands and it returns a list of outputs
#
proc CLICmdProc {cmds} {
# 'cli_open' apre una vty, cioe' una shell, importante usare 'cli_close' alla fine del
codice.
# Fallisce se non ci sono almeno 3 vty libere
if [catch {cli_open} result]
{
error $result $errorInfo
} else
{
array set cli1 $result
}
# Il comando 'catch' esegue dei comandi e' cattura l'eventuale errore
# senza stoppare l'esecuzione del codice
if [catch {cli_exec $cli1(fd) "enable"} result]
{
error $result $errorInfo
}
# 'cli_exec' e' una procedura Cisco che esegue un comando di shell
if [catch {cli_exec $cli1(fd) "term len 0"} result]
{
error $result $errorInfo
}
foreach a_cmd $cmds
{
if [catch {cli_exec $cli1(fd) $a_cmd} result]
{
error $result $errorInfo
} else
{
lappend cmd_output $result
}
}
if [catch {cli_close $cli1(fd) $cli1(tty_id)} result]
{
error $result $errorInfo
}
return $cmd_output
}
#
# Put commands here
#

Pagina 64
 Configurazione dei router Cisco
# MAIN - INIZIO ESECUZIONE -
#
# 'lappend' aggiunge un elemento ad una lista
lappend clicmd "show ip int brief"
lappend clicmd "show tech"
lappend clicmd "show clock"
# Qui si chiama la funzione a cui si passa la lista di comandi da eseguire
set cliout [CLICmdProc $clicmd]
#
# write to a file
#
#
if [file exists $_ofilename]
{
puts "file $_ofilename being overwritten"
}
set myfileid [open $_ofilename w+]
foreach outs $cliout {
puts $myfileid $outs
}
close $myfileid

Figura 113 - Esempio di script in TCL

Per approfondire, nel sito Cisco cercate i documenti "Cisco IOS IP SLAs
CONFIGURATION GUIDE" e "Writing Embedded Event Manager Policies Using Tcl".

Indirizzi IP multipli sulle interfacce

Con IOS e' possibile assegnare piu' indirizzi IP ad una stessa interfaccia. Per gli ip
secondari va aggiunta l'appendice "secondary". Ecco un esempio di una interfaccia
Ethernet con tre indirizzi IP:

interface FastEthernet0/1
description --- network ---
ip address 192.168.70.1 255.255.255.0 secondary
ip address 192.168.80.1 255.255.255.0 secondary
ip address 192.168.60.1 255.255.255.0

Figura 114 - Ip secondari sulle interfacce

Come si comporta un router con piu' ip sulla stessa interfaccia? Semplicemente gestisce
gli indirizzi indipendentemente l'uno dall'altro. Ma questo per il traffico in transito. Quando
il router deve inviare pacchetti, ad esempio per un protocollo di routing dinamico, usa l'ip
primario, se non istruito diversamente. Cosi' ad esempio quando si effettua un ping l'ip
primario viene utilizzato come mittente e non i secondari. Se si vogliono utilizzare gli ip
secondari nel caso del comando "ping" la soluzione sta nell’uso del ping esteso dove si
puo’ specificare l’ip del mittente. Gli algoritmi di routing in genere supportano solo
parzialmente gli IP secondari e in modo differente. Piu' IP nella stessa interfaccia
indicano piu' reti IP sovrapposte di cui il router puo' esserne il gateway. Interessante e’
che come conseguenza in alcuni casi i pacchetti entreranno e riusciranno dalla stessa
interfaccia perche’ gli indirizzi multipli indicano reti distinte.

L' IP-redirect

I redirect sono dei pacchetti ICMP che avvisano un device che non sta utilizzando un
percorso ottimale per andare da un dispositivo A ad un dispositivo B. Questo puo'
accadere ad esempio se si prova a contattare un gateway per passare da un PC ad
un'altro nell'ambito di una stessa LAN. Se il router vede che un pacchetto entra ed esce
dalla stessa interfaccia prova ad inviare un ICMP redirect.

Pagina 65
 Configurazione dei router Cisco

I ‘redirect’ che giovano per indicare dei percorsi ottimali in molti casi sono indice di
cattiva configurazione di routing in qualche punto di una rete. I redirect non vengono
inviati se si entra ed esce dalla stessa interfaccia ma per due reti distinte cioe’ nel caso di
ip multiplo.
Normalmente l'ICMP redirect e' abilitato di default. Si puo' abilitare o disabilitare con il
comando "ip redirects". Con il comando "show ip redirects" e' possibile vedere la cache
dei messaggi ICMP redirect.

prova1800#show ip redirects
Default gateway is not set

Host Gateway Last Use Total Uses Interface

ICMP redirect cache is empty

Figura 115 - Comando "show ip redirect"

Per comprendere l'uso del comando "ip redirects" immaginiamo una LAN con piu'
gateway. I PC hanno come gateway un router R1 e lo contatteranno anche per le
destinazioni presenti in un router R2. Ma R1, se vede che c'e' una route verso R2,
mandera ai PC un redirect verso R2 e il traffico successivo evitera' il passaggio da R1.
loose source route per vedere il ritorno del traceroute se non disabilitato nei router
intermedi. Opzione -g nel traceroute linux
Aggiornamento del software IOS

I router memorizzano il sistema operativo IOS in una memoria di tipo flash. Al boot,
scompattano il software in memoria RAM e lo eseguono da li. In alcuni casi il software
viene eseguito direttamente su flash, ad esempio nel caso di Cisco IOS modulare. Il
dispositivo di memoria flash puo' avere nomi diversi a seconda dei modelli e a seconda
del tipo. Quando ci si riferisce alla flash interna, normalmente il dispositivo prende il nome
di "flash:". Nel caso di moduli Compact Flash il dispositivo puo' chiamarsi "disk0:" "disk1:"
"disk2:", oppure nel caso della serie 19xx, 29xx, 39xx "flash0:" "flash1". Nel caso di
supporto usb "usbflash0:" oppure "usbflash1:". Potete scoprirlo facilmente utilizzando il
comando "dir ?". Allora con i comandi "show flash:" oppure nei modelli piu' recenti "dir
flash:" e' possibile leggerne il contenuto e vedere il file di immagine del sistema operativo
che viene caricato in memoria RAM dopo il boot.
Essendo il sistema operativo in RAM durante l'esercizio del router e' possibile
intervenire sulla flash senza comprometterne il funzionamento. Possiamo cancellare e
aggiornare il file del sistema operativo senza in alcun modo alterare il normale
funzionamento del router. Solo al riavvio dell'apparato verra' caricata la nuova immagine
IOS. Questo significa anche che, in caso di errore, il router potrebbe non ripartire
correttamente. Pertanto tutti gli interventi sulla flash vanno effettuati con molta
attenzione. Qui non tratteremo il caso di IOS modulare.
Per effettuare l'aggiornamento dell'IOS bastera' utilizzare il comando "copy"
specificando come sorgente un server tftp e come destinatario il dispositivo di flash
presente nel router. Ad esempio con il comando "copy tftp: flash:" il sistema chiedera' i
dati del server tftp e procedera' con il trasferimento dell'immagine indicata in flash. Se
tutto procede correttamente, al successivo riavvio del router avremo l'IOS aggiornato.
Aggiornamento del software IOS con il comando 'archive'

In alcune casi le immagini IOS fornite da Cisco sono all'interno di file con estensione
".tar" ovvero contenenti un archivio. Si tratta dei casi dove vengono forniti, oltre che

Pagina 66
 Configurazione dei router Cisco

l'immagine IOS vera e propria, una serie di file aggiuntivi come i documenti html per
l'interfaccia WEB di configurazione e amministrazione del router.
In questi casi insieme al TFTP si utilizza il comando "archive" per trasferire il file
compresso e poi scompattarlo in flash. Ecco un esempio:

ap#archive tar /xtract tftp://IPSERVERTFTP/c1200-k9w6-tar.123-8.T.tar

flash:
Loading c1800-k9w6-tar.123-8.T.tar from IPSERVERTFTP (via BVI1): !
extracting info (274 bytes)
c1800-k9w6-mx.123-8.T/ (directory) 0 (bytes)
c1800-k9w6-mx.123-8.T/html/ (directory) 0 (bytes)
c1800-k9w6-mx.123-8.T/html/level/ (directory) 0 (bytes)
c1800-k9w6-mx.123-8.T/html/level/1/ (directory) 0 (bytes)
extracting c1800-k9w6-mx.123-8.T/html/level/1/appsui.js (577 bytes)
extracting c1800-k9w6-mx.123-8.T/html/level/1/back.shtml (998 bytes)!
...

Figura 116 - Comando 'archive' insieme a 'tftp'

Aggiornamento del firmware con rsh

Server testato: Linux Fedora Core 8

Router nel test: Cisco 7206VXR con IOS 12.4(20)T

Figura 117 - Piattaforma di test per l'uso di un server RSH

Il trasferimento di file tra router Cisco e sistemi esterni e' normalmente effettuato
utilizzando il protocollo TFTP. Utilizzi tipici sono il trasferimento di immagini IOS, per
l'aggiornamento del sistema operativo, e il trasferimento dei file di configurazione. Il
protocollo TFTP utilizza UDP e il meccanismo che utilizza per verificare la corretta
sequenza dei pacchetti e' un campo contatore di 16bit.
Una prima release del protocollo TFTP non permetteva il trasferimento di file superiori a
32megabyte. La specifica originale e' nell'RFC 1350. Le revisioni successive hanno tolto
questo limite indirettamente, con gli RFC 2347-48-49. Indirettamente perche' il limite a
32megabyte non e' esplicitamente mensionato nelle specifiche del TFTP ma e' una
conseguenza di esse. Infatti le specifiche originali impongono un blocksize di 512bytes, e il
campo contatore dei blocchi di 16bit. Da cui 512bytes * 65536=32megabyte.
L'RFC 2348 (1998) ridefinisce l'opzione per la negoziazione del blocksize tra 8 e 65464
bytes. Il problema allora potrebbe considerarsi risolto infatti i server TFTP normalmente
utilizzati oramai supportano questa opzione. Mi riferisco a tftp32 o pumpkin ad esempio.
Tuttavia un block size superiore all'MTU vuol dire frammentazione dei pacchetti IP, con la
conseguenza che invece di avere una velocita' di trasmissione superiore e piu' efficiente si
potrebbe avere in alcuni casi l'impossibilita' di trasmettere.
Per concludere in alcune circostanze, specialmente nel caso in cui tra il server TFTP e il
router ci sia una WAN, potrebbe essere impossibile o estremamente difficoltoso trasferire
file tramite TFTP. Alcuni sintomi potrebbero essere delle sequenze del tipo "!!..." oppure
"!!OOO!OOOO!!!!!" che appaiono sullo schermo durante il trasferimento dati dal router.
Cosa fare?
La risposta sta nel fatto che i router Cisco supportano metodi di trasferimento dati
alternativi al TFTP. Una soluzione consiste nell'utilizzo di RSH, molto diffuso in ambiente
Unix, che sta per "remote shell" e che permette di eseguire programmi non interattivi su
sistemi remoti. In ogni distribuzione Linux e' presente un daemon RSH, che pero'

Pagina 67
 Configurazione dei router Cisco

normalmente e' disabilitato. Dopo aver attivato un server RSH con il comando RCP
ovvero "remote copy" possiamo trasferire un file tra server RSH e client. Il client puo'
essere anche un router Cisco. Il vantaggio di RSH va ben oltre il problema della
dimensione dei file. Infatti RSH utilizza TCP e non UDP. Pertanto e' efficace anche in caso
di trasferimenti in reti congestionate o con errori di trasmissione.
Installazione del server RSH su un Fedora 8 Linux

Utilizzeremo un server linux al quale dobbiamo avere accesso con lo user "root". Per
l'installazione del server rsh basta seguire i seguenti passi dalla shell linux:

1. yum install rsh-server*;

2. yum install xinetd*;
3. Editare il file /etc/xinetd.d/rsh come in figura. In particolare "disable=no" per attivare il
daemon;

[root@SpamCop ~]# cat /etc/xinetd.d/rsh

# default: on
# description: The rshd server is the server for the rcmd(3) routine and, \
# consequently, for the rsh(1) program. The server provides \
# remote execution facilities with authentication based on \
# privileged port numbers from trusted hosts.
service shell
{
socket_type = stream
wait = no
user = root
log_on_success += USERID
log_on_failure += USERID
server = /usr/sbin/in.rshd
disable = no
}

Figura 118 - Fedora: attivazione daemon rsh, file 'xinetd.d/rsh'

4. Editare il file securetty come in figura;

[root@SpamCop ~]# cat /etc/securetty

console
...
rsh

Figura 119 - Fedora: attivazione daemon rsh, file 'securetty'

5. Editare il file pam.d/rsh come in figura;

[root@SpamCop ~]# cat /etc/pam.d/rsh

#%PAM-1.0
# For root login to succeed here with pam_securetty, "rsh" must be
# listed in /etc/securetty.
auth required pam_nologin.so
auth required pam_securetty.so
auth required pam_env.so
auth sufficient pam_rhosts_auth.so promiscuous
account include system-auth
session optional pam_keyinit.so force revoke
session include system-auth
[root@SpamCop ~]#

Pagina 68
 Configurazione dei router Cisco

Figura 120 - Fedora: attivazione daemon rsh, file 'pam.d/rsh'

6. In base al nome e IP con cui si presenta il router (se non lo sapete dovete vedere il
file di log di sistema mentre nel router si tenta il trasferimento rsh, ovvero il file
/log/messages oppure fare un semplice nslookup dell'IP) editare il file hosts. Fedora
infatti prova a fare il reverse lookup dell'ip del router e ne verifica la corrispondenza con
quanto indicato in hosts e .rhosts. Se non c'e' risoluzione di nome si puo' evitare di
editare questi file;

[root@SpamCop ~]# cat /etc/hosts

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 tftpserver.itesys.it localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
192.168.50.122 router24.itesys.it

Figura 121 - Fedora attivazione daemon rsh, file 'hosts'

7. In base all'IP e al nome con cui si presenta il router (in questo esempio il router ha
indirizzo IP 192.168.50.122);

[root@SpamCop ~]# cat /root/.rhosts

192.168.50.122
router24.itesys.it
gianrico

Figura 122 - Fedora attivazione daemon rsh, file 'rhosts'

8. Riavviare xinetd per rendere operative le modifiche con il comando 'service xinetd
restart';
9. Possiamo adesso tentare il trasferimento di file tra router e server. Per fare cio' nella
console del router inserire il seguente comando:

copy rcp://10.20.20.20//root/c7200-advipservicesk9-mz.124-24.T1.bin disk2:/

<-- IMPORTANTI I DUE '/'

Figura 123 - Copiare con rsh da server a router

alla richiesta di nome utente, inserite "root".

Troubleshooting RCP

Una errata configurazione del server Linux ha come conseguenza l'impossibilita' di

trasferire files. Esaminando i file di log di sistema si possono individuare la maggior parte
dei problemi.

[root@SpamCop ~]# cat /var/log/messages | grep rsh

Jul 6 23:04:38 smtp3 rshd[11295]: rsh command was 'rcp -f root/c7200-

advipservicesk9-mz.124-24.T1.bin'
Jul 6 23:05:00 smtp3 rshd[11475]: Couldn't look up address for
router24.itesys.it/192.168.50.122
Jul 6 23:05:00 smtp3 rshd[11475]: rsh denied to [email protected] as
root: Couldn't get address for your host (%s) <-- ERRATA CONFIGURAZIONE DEL FILE
HOSTS
Jul 6 23:08:40 smtp3 rshd[12995]: rsh command was 'rcp -f root/c7200-

Pagina 69
 Configurazione dei router Cisco

advipservicesk9-mz.124-24.T1.bin'
Jul 6 23:09:36 smtp3 rshd[13425]: rsh denied to [email protected] as
root: Permission denied.
Jul 6 23:09:36 smtp3 rshd[13425]: rsh command was 'rcp -f root/c7200-
advipservicesk9-mz.124-24.T1.bin'
Jul 6 23:09:57 smtp3 rshd[13556]: rsh denied to [email protected] as
gianrico: Permission denied.
Jul 6 23:12:42 smtp3 rshd[14718]: rsh denied to [email protected] as
root: Permission denied.

Figura 124 - Troubleshooting RSH: errata configurazione file 'hosts'

Jul 6 23:31:56 smtp3 rshd[22702]: [email protected] as root: cmd='rcp -

f root/c7200-advipservicesk9-mz.124-24.T1.bin' <--- PATH ERRATO NEL COMANDO RCP
('/' ASSENTE)
Jul 6 23:32:39 smtp3 rshd[22978]: [email protected] as root: cmd='rcp -
f root/c7200-advipservicesk9-mz.124-24.T1.bin'
Jul 6 23:33:34 smtp3 rshd[23411]: [email protected] as root: cmd='rcp -
f root/c7200-advipservicesk9-mz.124-24.T1.bin'

Figura 125 - Troubleshooting RSH: errata indicazione di path

Cisco ROMmon e recovery del sistema operativo

I router Cisco caricano l'immagine del sistema operativo IOS da una memoria flash che
puo' essere su chip, ad esempio DIMM nella scheda madre, oppure esterna, su Compact
Flash o pennino USB. E' anche possibile caricare IOS da un dispositivo remoto, con
protocolli come tftp. In caso di guasto e impossibilita' di caricare il sistema operativo il
router ne carica una versione di emergenza. Questa si trova nella memoria bootflash,
una memoria flash, e si chiama boot helper image. Si tratta di una versione di IOS con
un numero limitato di comandi e funzionalita'.

Ma non tutti i modelli di router Cisco dispongono della possibilita' di utilizzare una boot
helper image. Nei modelli di fascia piu' bassa non esiste una memoria bootflash, e
comunque in generale potrebbe fallire il boot anche da li, ad esempio nel caso di una
manutenzione errata. In questo caso estremo il sistema parte in ROMmon mode, un
sistema operativo minimale non IOS, gestibile solo tramite l'accesso console locale del
router e quindi non da remoto (a meno di utilizzo di un terminal server).

A seconda dei modelli di router il ROMmon si trova in una memoria di tipo ROM o
flash.Pertanto aggiornarno puo' significare la necessita' di sostituire un chip. Normalmente
pero' non c'e' nessuna necessita di effettuare un simile aggiornamento. In alcuni router di
fascia alta (ad es. schede NPE-G1/G2 Cisco 7200 o sup720 Catalyst 6500/7600) vi sono
due differenti ROMmon di cui una aggiornabile dall'utente, mentre la seconda no. In
modelli come NPE-200 o NPE-300 del Cisco 7200 non e' aggiornabile. Anche nella serie
2600, ad eccezione del modello 2691 a seguire, per aggiornare la ROMmon bisogna
fisicamente sostituire il chip. E' possibile invece aggiornare la ROMmon per la serie 2600
dal modello 2691 a seguire e per le serie 28xx, 29xx. In questi ultimi casi, esistendo una
sola ROMmon aggiornabile dall'utente un errore nell'aggiornamento rendera' inutilizzabile
il router perche' non c'e' la doppia ROMmon.
Per riepilogare in ogni caso un router incapace di caricare il sistema operativo entra in
ROMmon mode ovvero un sistema di comandi estremamente ridotto con puri scopi di
manutenzione che permette un aggiornamento dell'IOS e poco altro. Per forzare l'avvio di
un sistema in ROMmon ignorando IOS e' necessario collegarsi in console e inviare da
terminale la sequenza di break al boot del sistema. Quest'ultima si ottiene premendo il
tasto "break" o "interr" della tastiera. In ogni caso in alcune tastiere e' indicato in modo

Pagina 70
 Configurazione dei router Cisco

differente.

Aggiornamento di IOS da ROMmon

Ecco un esempio di aggiornamento dell'IOS su un router della classe 2800/3800 da

ROMmon. Il collegamento al router e' da console, quindi in locale. E' necessario collegare
il router in rete Ethernet e mettere a disposizione un server TFTP, da un qualsiasi
computer nella stessa LAN. Dopo aver avviato il router, e' necessario collegarsi da console
e inviare la sequenza di break. Con i comandi in figura si assegna un indirizzo IP
provvisorio al router e tutto quanto necessario per effettuare l'aggiornamento:

rommon 3 > IP_ADDRESS=192.168.1.99

rommon 4 > IP_SUBNET_MASK=255.255.255.0
rommon 5 > TFTP_SERVER=192.168.1.98
rommon 6 > TFTP_DESTINATION=flash:
rommon 7 > TFTP_FILE=c2800nm-ipvoicek9-mz.124-24.T1.bin
rommon 8 > DEFAULT_GATEWAY=...
rommon 9 > tftpdnld

Figura 126 - Aggiornamento di IOS da ROMmon

Copyright 2002-2010 Gianrico Fichera

Nessuna parte di questa pubblicazione puo' essere riprodotta o trasmessa, in qualsiasi

forma o con qualsiasi mezzo, elettronico, meccanico, fotocopie, registrazione, senza il
consenso dell'autore.

This material is not sponsored by, endorsed by, or affiliated with Cisco Systems, Inc.,
Cisco, Cisco Systems, and the Cisco Systems logo are trademarks or registered trade
marks of Cisco Systems, Inc. or its affiliates. All other trademarks are trademarks of their
respective owners.

Pagina 71