|
|
|
---|---|---|
|
||
|
RIP |
|
Aprile 2004 Ultimo aggiornamento - Aggiornamenti successivi vai a libro routing -
Il
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. 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 (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. 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. RIP utilizza la porta 520 dell'UDP. Configurazione
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# vedete come, ogni 30 secondi (con
piccole discrepanze dovute all'output del log) viene 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.
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.0.0/24. Il router A inviera’ e ricevera’ informazioni di routing da B secondo i seguenti criteri: In invio:
In ricezione:
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. Facciamo un esempio: Router#show ip route ecco cosa si propaga: 02:44:12: RIP: sending v1 update to 255.255.255.255 via ATM0 (116.30.40.1) Secondo le regole di cui sopra dall'interfaccia
ethernet viene inviato l'update relativo alla subnet, fermo
restando che la destinazione avra' netmask di classe B perche'
la netmask non viene inviata. Tempo di convergenza RIP e’ un algoritmo distance-vector ovvero propaga l’intera tabella di routing ai propri vicini. Per default ogni 30 secondi (broadcast time) un nodo RIP invia la propria tabella di routing ai suoi vicini. Supponiamo che il router R2 non riceva piu' aggiornamenti dal router R1. Invece di scartare subito le route, che R1 aveva inviato fino ai 30 secondi precedenti, R2 attende fino a 180 secondi conservando in tabella di routing le network di R1. Questo tempo si chiama "invalid time". Superati i 180 secondi si puo' affermare con sufficiente certezza che R1 e' nello stato di down e che le sue route quindi non vanno piu' utilizzate. A questo punto inizia il 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 180 secondi. In questi 180 secondi le router sono nello stato di "hold-down" e figurano ancora nella tabella di routing come "possibly-down". Anche in questo stato la network e' utilizzata per il forward dei pacchetti in quanto e' nella tabella di routing. Se un router R3 riceve questo aggiornamento da R2 mette la network direttamente nello stato di "hold-down". Superato il tempo per l'hold-down la route viene scartata dalla tabella di routing. Questo non avviene subito ma considerando il tempo indicato nel "flush-time" che vale 240 secondi di default. Durante l'hold-down le informazioni riguardanti nuovi percorsi per raggiungere la rete 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 oltre 7 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) Se abbiamo sufficiente banda possiamo ridurre tale tempo aumentando la frequenza degli aggiornamenti RIP. Tramite il comando "timers basic" e' possibile variare i timer RIP: timers basic update invalid holddown flush Split-horizont e 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, e
questo e' split-horizont. Questa
funzionalita’ e’ per default disabilitata nel caso di
collegamenti come 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
lo split-horizon col comando “ip split-horizont”.
RIP utilizza split-horizon con poison reverse ovvero invece di
non ripropagare verso il mittente di una route la invia con
metrica 16. La redistribuzione, ovvero l'iniezione di routes
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 specificare una metrica altrimenti questa
sara' 16. Vedi il paragrafo corrispondente relativo a EIGRP.
Col comando "show ip protocols" si possono vedere tutti i settaggi RIP: Router#show ip protocols Col comando "debug" e' possibile visualizzare in tempo reale i dati RIP in ingresso e uscita dalle interfacce: router#debug ip rip ? 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 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 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 02:53:04: RIP: sending v1 update to 255.255.255.255 via ATM0 (116.30.40.1)
Altre letture Consiglio di consultare l’enorme documentazione disponibile on-line nel sito della cisco http://www.cisco.com/ . E’ possibile trovare sempre tutto cio’ che si cerca.
|
||
Copyright 2002-2004 – gianrico fichera - ITESYS srl – Il
materiale di questa pagina 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 questa pagina 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. |
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. |