RIP in Katharà
In questa pagina 6
Il laboratorio 5 (LAB5) si basa su due esperienze in Katharà: la prima insegna a usare FRRouting (FRR, un insieme di demoni di instradamento), la seconda configura il protocollo RIP (Routing Information Protocol) su una rete di cinque router. I router non hanno più tabelle scritte a mano come in Routing statico in KatharàLaboratorio 2 (LAB2). Due LAN (195.11.14.0/24 e 200.1.1.0/24) sono unite da due router r1 e r2 collegati da una rete 100.0.0.8/30. Una interfaccia attiva inserisce da sola nella tabella di instradamento solo la rete direttamente collegata: per le altre servono rotte inserite a mano. I PC usano una rotta predefinita (route add default gw 195.11.14.1), i router rotte statiche (route add -net 195.11.14.0/24 gw 100.0.0.9 dev eth1). Senza la rotta di ritorno su r2 le richieste di ping arrivano ma le risposte no: la raggiungibilità vale solo se c'è un percorso in entrambi i versi. A configurazione finita ping da pc1 a pc2 risponde con ttl=62 (64 meno 2 router).Routing statico in Katharà → e Routing avanzato in KatharàLaboratorio 3 (LAB3). Tre router r1, r2, r3 a triangolo con tre LAN (96.96.0.0/24, 192.192.192.0/20, 128.128.0.0/20) e tre collegamenti /30 (10.0.0.0/30, 20.0.0.0/30, 30.0.0.0/30). Obiettivo: ogni dispositivo deve poter fare ping a ogni interfaccia di ogni altro. Gli host usano una rotta predefinita; i router soltanto rotte statiche (vietato il default), tre per router, una per ogni rete non direttamente collegata. Con soli default in un triangolo i percorsi si allungano e i pacchetti per indirizzi sconosciuti girano in cerchio fino al TTL; un buon compromesso è un default più qualche rotta specifica. traceroute scopre i router incrementando il TTL: ogni router che lo porta a 0 risponde con ICMP time exceeded.Routing avanzato in Katharà →: se le costruiscono da soli. La teoria è in Protocolli di instradamento - RIP, OSPF e BGPIn Internet l'instradamento non si può fare con un solo protocollo, per scalabilità (tabelle troppo grandi) e per autonomia amministrativa: ogni ISP è un sistema autonomo (AS) con il proprio algoritmo. All'interno di un AS si usano i protocolli IGP: RIP (distance vector, numero di salti, massimo 15, aggiornamenti ogni circa 30 s, su UDP porta 520) e OSPF (link state con Dijkstra, aree collegate all'area 0, cinque tipi di LSA, messaggi direttamente in IP). Tra AS si usa BGP4 (path vector, su TCP porta 179, eBGP tra AS e iBGP dentro l'AS, scelta del percorso per politica: preferenza locale, AS-PATH più corto, origine; i cicli si evitano scartando i cammini che contengono già il proprio AS; quattro messaggi: Open, Keepalive, Notification, Update).Protocolli di instradamento - RIP, OSPF e BGP → e Algoritmi di instradamento - link state e distance vectorL'instradamento (routing) trova il percorso di costo minimo in un grafo pesato in cui i router sono nodi e le reti tra due router sono archi. Link state: ogni router diffonde con un flooding i pacchetti LSP sui propri collegamenti, ricostruisce tutto il grafo e applica Dijkstra (nodi con stato (distanza, permanente o temporaneo)). Distance vector: ogni router conosce solo i vicini e scambia con loro il proprio vettore delle distanze, aggiornato con Bellman-Ford $D_{A,w}=\min{D_{A,w},,D_{A,Y}+d_{Y,w}}$; converge in al più $n-1$ giri ma può soffrire del conteggio all'infinito (limite a 16, hold down, aggiornamenti immediati, split horizon con poison reverse). Path vector: ogni annuncio porta l'intero cammino, si sceglie per politica e non per costo, e i cicli si scoprono trovando sé stessi nel cammino. Dijkstra è corretto se i costi sono non negativi (invariante: un nodo permanente ha già la distanza vera); Bellman-Ford è corretto perché dopo $k$ giri conosce i cammini minimi con al più $k+1$ archi.Algoritmi di instradamento - link state e distance vector →.
Perché servono i protocolli di instradamento
Ogni host con una pila di rete fa già un po' di instradamento: decide se un pacchetto va alla scheda di rete o alla loopback. Un router (o gateway) ha più schede di rete e rimette in circolo i pacchetti ricevuti che non sono per lui (inoltro, forwarding). Per decidere usa la tabella di instradamento (destinazione, maschera, next hop, interfaccia). I protocolli di instradamento aggiornano questa tabella in automatico, liberando l'amministratore dal lavoro manuale. In Katharà un router è una macchina virtuale che esegue il software che implementa questi protocolli.
FRRouting
Definizione (FRR). FRRouting è una suite libera di protocolli di instradamento per Linux. Implementa RIP (v1 e v2), OSPF (v2 e v3), IS-IS, BGP e altri. Deriva dal progetto Quagga, a sua volta derivato da Zebra.
FRR è formato da più demoni (programmi che girano in background): zebra gestisce la tabella di instradamento del kernel e comunica con gli altri; ripd, ospfd, bgpd, ... implementano i singoli protocolli e scambiano gli aggiornamenti con i router vicini. Per usare FRR in Katharà serve l'immagine kathara/frr: o la si sceglie come predefinita (kathara settings, choose default image, kathara/frr) oppure la si indica nel lab.conf con r1[image]="kathara/frr" (come fanno i laboratori forniti).
I file di configurazione
/etc/frr/daemons dice a FRR quali demoni avviare:
zebra=yes # il demone di base: sempre attivo
bgpd=no
ospfd=no
ripd=yes # parte il demone RIP
ripngd=no # (RIP per IPv6) spento/etc/frr/vtysh.conf contiene service integrated-vtysh-config (una sola configurazione, il file frr.conf, per tutti i demoni: scelta consigliata) oppure no service integrated-vtysh-config (un file per demone).
/etc/frr/frr.conf è l'elenco dei comandi di configurazione. Esempio per un router RIP:
router rip # entra nella configurazione del protocollo RIP
network 100.1.0.0/16 # RIP lavora sulle interfacce con indirizzo in questo prefisso
log file /var/log/frr/frr.logLa configurazione di FRR è operativa, non descrittiva: il file è una lista di comandi che portano il router allo stato voluto. Per togliere un comando si dà lo stesso comando preceduto da no (per esempio no ipv6 forwarding).
Ogni cartella r1/etc/frr/ del laboratorio contiene questi file, che Katharà copia nella radice del router all'avvio (vedi Katharà - emulare una reteKatharà è un emulatore di rete: ogni dispositivo (host, router, server) è un container Docker, e i container sono collegati da "domini di collisione" virtuali (reti locali). Un laboratorio è una cartella con lab.conf (topologia), un file <dispositivo>.startup per ogni macchina (comandi eseguiti all'avvio) e, se serve, una cartella per dispositivo con i file da copiare nel suo filesystem. Si avvia con lstart, si ferma con lclean; le macchine si configurano con ifconfig, si provano con ping e si osservano con tcpdump (file .pcap da aprire con Wireshark).Katharà - emulare una rete →). Per far partire FRR all'avvio basta mettere nel file .startup la riga systemctl start frr.
La shell vtysh
Invece di collegarsi a ogni demone, si usa vtysh, una shell unica per tutti i demoni (compreso zebra), senza password:
root@r1:~$ vtysh # apre la shell di FRR
Hello, this is FRRouting (version 9.0.1).
r1# ? # elenca i comandi disponibili| Comando | Effetto |
|---|---|
enable / disable |
entra / esce dalla modalità privilegiata |
configure |
entra nella configurazione (modifiche persistenti del comportamento) |
show ip route |
tabella di instradamento di FRR |
show running-config |
configurazione attuale |
write |
salva la configurazione |
ping |
invia echo |
no <comando> |
annulla un comando |
exit / quit |
esce dalla modalità corrente |
Un utente non privilegiato vede solo informazioni non critiche; il configurator fa le modifiche persistenti.
show ip route mostra anche, per ogni rotta, un codice: K kernel, C collegata (connected), S statica, R RIP, O OSPF, B BGP. Il simbolo > indica la rotta scelta, * quella installata nel kernel (FIB).
Esperienza 1: tre router in fila (kathara-lab_frr)
A = 100.0.0.0/24 B = 150.0.0.0/30 C = 200.0.0.0/30 D = 220.0.0.0/24
(r1.eth0 .1) --- [r1] eth1 .1 ---- .2 eth0 [r2] eth1 .1 ---- .2 eth0 [r3] eth1 .1 --- (rete D)| Router | Interfaccia | Dominio | Indirizzo |
|---|---|---|---|
| r1 | eth0 | A | 100.0.0.1/24 |
| r1 | eth1 | B | 150.0.0.1/30 |
| r2 | eth0 | B | 150.0.0.2/30 |
| r2 | eth1 | C | 200.0.0.1/30 |
| r3 | eth0 | C | 200.0.0.2/30 |
| r3 | eth1 | D | 220.0.0.1/24 |
Gli indirizzi sono assegnati nei .startup con il comando ip (al posto di ifconfig):
ip address add 100.0.0.1/24 dev eth0 # r1: assegna l'indirizzo all'interfaccia eth0
ip address add 150.0.0.1/30 dev eth1
systemctl start frr # avvia FRR: parte zebra e il demone RIPip address add <ip>/<prefisso> dev <interfaccia> fa quel che faceva ifconfig. In Katharà basta questa riga: le interfacce sono già attive. Le altre equivalenze con i comandi usati finora:
ifconfig / route |
ip |
|---|---|
ifconfig eth0 10.0.0.1/24 up |
ip address add 10.0.0.1/24 dev eth0 e ip link set eth0 up |
route -n |
ip route |
route add -net 10.1.0.0/16 gw 10.0.0.2 |
ip route add 10.1.0.0/16 via 10.0.0.2 |
route add default gw 10.0.0.2 |
ip route add default via 10.0.0.2 |
Il frr.conf di r1 è
router rip
redistribute connected # annuncia anche le reti collegate
network 150.0.0.0/8 # RIP attivo sull'interfaccia con 150.0.0.1 (eth1)r2 ha network 150.0.0.0/8 e network 200.0.0.0/8 (entrambe le interfacce), r3 solo network 200.0.0.0/8. Significato:
network <prefisso>attiva RIP sulle interfacce il cui indirizzo cade nel prefisso (qui/8abbraccia tutti gli indirizzi150.x.x.x: la maschera/8è255.0.0.0, i primi bit sono il primo ottetto, e150.0.0.1AND255.0.0.0150.0.0.0, come il prefisso; Subnetting e supernettingIl subnetting divide un blocco di indirizzi in sottoblocchi più piccoli allungando la maschera ($n_{\text{sub}}=n_{\text{rete}}+s$, con $2^s$ sottoreti); il supernetting (aggregazione CIDR) fa l'opposto, accorciando il prefisso per unire blocchi contigui in uno più grande. Regole di progetto: ogni sottorete ha un numero di indirizzi potenza di 2 ($M=2^k\ge$ host richiesti $+2$), prefisso $n=32-k$, indirizzo iniziale multiplo di $M$; si assegnano prima le sottoreti più grandi. Per aggregare $2^j$ blocchi di prefisso $n$ servono blocchi contigui il cui primo indirizzo sia multiplo della dimensione dell'aggregato, e il nuovo prefisso è $n-j$.Subnetting e supernetting →): su quelle interfacce il router invia e riceve gli aggiornamenti RIP, e annuncia le reti collegate che vi rientrano;redistribute connectedforza l'annuncio di tutte le reti collegate, anche di quelle su interfacce dove RIP non è attivo: così100.0.0.0/24(sueth0di r1, senza vicini RIP) e220.0.0.0/24(sueth1di r3) entrano comunque nel protocollo.
Dopo kathara lstart, show ip route su r3 (nel giro di un minuto circa):
R>* 100.0.0.0/24 [120/3] via 200.0.0.1, eth0
R>* 150.0.0.0/30 [120/2] via 200.0.0.1, eth0
C>* 200.0.0.0/30 is directly connected, eth0
C>* 220.0.0.0/24 is directly connected, eth1Lettura: R è una rotta imparata con RIP; [120/3] è [distanza amministrativa / metrica]: è il valore predefinito di RIP (le rotte statiche e collegate hanno valore minore), è la metrica; > e * indicano la rotta scelta e installata nel kernel; C sono le reti collegate.
Perché e ? RIP conta i salti e parte da per le reti collegate. La rete 100.0.0.0/24 è collegata a r1 (metrica su r1), r2 la riceve con , r3 con ; 150.0.0.0/30 è collegata a r1 e r2: su r2 vale , su r3 . Il next hop è sempre (r2) perché r3 ha un solo vicino.
Formula (metrica RIP). La metrica di una rete è il numero di router che si attraversano per raggiungerla, contando per le reti collegate e aggiungendo a ogni router che inoltra l'annuncio; significa irraggiungibile.
Collegamento con i grafi: i router sono i nodi e i collegamenti gli archi di un grafo non pesato (Grafi - definizioni e proprietàGrafo G=(V,E) diretto e non diretto, grafo semplice e pesato; incidenza, adiacenza, grado; cammini, cicli, sottografi, grafi connessi e componenti connesse; alberi liberi, foreste, spanning tree e spanning forest; proprietà con dimostrazioni (somma dei gradi = 2m, m <= n(n-1)/2, alberi m = n-1, connessi m >= n-1, foreste m <= n-1).Grafi - definizioni e proprietà →); la metrica RIP è la lunghezza (numero di archi, più per la rete finale) del cammino più corto dal router alla rete, cioè quello che una visita in ampiezza trova (Visite di grafi - BFS e DFSVisite in ampiezza (BFS) e in profondità (DFS) come design pattern; etichette discovery, cross e back edge; BFS tree e distanze; complessità Theta(n+m) con liste di adiacenza; applicazioni (connettività, componenti, spanning tree, cammini minimi non pesati, cicli, vertici a distanza al più d); esempio svolto su un grafo di 7 vertici.Visite di grafi - BFS e DFS →). RIP lo calcola in modo distribuito con l'algoritmo di Bellman-Ford (Algoritmi di instradamento - link state e distance vectorL'instradamento (routing) trova il percorso di costo minimo in un grafo pesato in cui i router sono nodi e le reti tra due router sono archi. Link state: ogni router diffonde con un flooding i pacchetti LSP sui propri collegamenti, ricostruisce tutto il grafo e applica Dijkstra (nodi con stato (distanza, permanente o temporaneo)). Distance vector: ogni router conosce solo i vicini e scambia con loro il proprio vettore delle distanze, aggiornato con Bellman-Ford $D_{A,w}=\min{D_{A,w},,D_{A,Y}+d_{Y,w}}$; converge in al più $n-1$ giri ma può soffrire del conteggio all'infinito (limite a 16, hold down, aggiornamenti immediati, split horizon con poison reverse). Path vector: ogni annuncio porta l'intero cammino, si sceglie per politica e non per costo, e i cicli si scoprono trovando sé stessi nel cammino. Dijkstra è corretto se i costi sono non negativi (invariante: un nodo permanente ha già la distanza vera); Bellman-Ford è corretto perché dopo $k$ giri conosce i cammini minimi con al più $k+1$ archi.Algoritmi di instradamento - link state e distance vector →); con costi diversi da servirebbe Cammini minimi e algoritmo di DijkstraGrafi pesati, lunghezza di un cammino e distanza; sottocammini di un cammino minimo; problema SSSP; algoritmo di Dijkstra con cloud e priority queue, rilassamento degli archi, esempio svolto; correttezza (due lemmi) e complessità O(min(n^2, (n+m) log n)) con lista non ordinata o heap; pesi non negativi.Cammini minimi e algoritmo di Dijkstra →.
Esempio. r3 verso 100.0.0.0/24: (su r1) (su r2) (su r3) , come in [120/3].
Esperienza 2: la rete stub di cinque router (kathara-lab_rip)
Una rete interna di quattro router (r1-r4) connessi tra loro e a LAN, con un solo router di uscita r4 verso r5, che rappresenta «Internet».
A 100.1.1.0/24 B 100.1.2.0/24
| |
[ r1 ] ------ E 100.1.0.0/30 ------ [ r2 ] -------------+
/ \ |
H 100.1.0.12/30 G 100.1.0.8/30 F 100.1.0.4/30
/ \ |
[ r4 ] +---------------------- [ r3 ] ---- C 100.1.3.0/24
/ \ |
D 100.1.4.0/24 +------ I 100.1.0.16/30 -------+
|
L 100.2.0.0/30
|
[ r5 ]Lo schema è indicativo (r4 è collegato a r1 su H, a r3 su I, a r5 su L); la topologia esatta, da lab.conf e dai .startup, è:
| Router | eth0 | eth1 | eth2 | eth3 |
|---|---|---|---|---|
| r1 | H 100.1.0.13/30 | G 100.1.0.9/30 | E 100.1.0.1/30 | A 100.1.1.1/24 |
| r2 | E 100.1.0.2/30 | F 100.1.0.5/30 | B 100.1.2.1/24 | |
| r3 | F 100.1.0.6/30 | G 100.1.0.10/30 | I 100.1.0.17/30 | C 100.1.3.1/24 |
| r4 | L 100.2.0.1/30 | D 100.1.4.1/24 | I 100.1.0.18/30 | H 100.1.0.14/30 |
| r5 | L 100.2.0.2/30 |
Controllo (Python): ogni indirizzo appartiene al prefisso del suo dominio; le collegano due router (100.1.0.0/30 ha host .1, .2). Una /30 ha indirizzi (rete, due host, broadcast): per questo le reti dei collegamenti sono a passo (.0, .4, .8, .12, .16) e ogni router ha l'indirizzo di un lato e il vicino dell'altro (100.1.0.1 e 100.1.0.2, 100.1.0.5 e 100.1.0.6, ...). Tutte le reti elencate stanno in 100.1.0.0/16: con la maschera 255.255.0.0 basta che i primi due ottetti siano 100.1, e 100.2.0.1 (la rete L verso r5) ne è fuori.
I collegamenti tra router sono: r1-r2 su E, r2-r3 su F, r1-r3 su G, r3-r4 su I, r1-r4 su H. La rete L collega r4 a r5. Le reti A, B, C, D sono LAN foglia.
Tutti i router di 100.1.0.0/16 hanno network 100.1.0.0/16 nel proprio frr.conf; r4 ha in più redistribute connected (perché la rete 100.2.0.0/30 verso r5 non rientra nel prefisso e va annunciata a parte). Il laboratorio non avvia FRR da solo.
Passo 1: prima di RIP
root@r4:~$ ping 100.1.0.13 # r1 eth0, rete H collegata a r4
64 bytes from 100.1.0.13: icmp_seq=1 ttl=64 time=1.23 ms
root@r4:~$ ping 100.1.2.1 # r2 eth2: rete B lontana
connect: Network is unreachable
root@r4:~$ ip route
100.1.0.12/30 dev eth3 proto kernel scope link src 100.1.0.14
100.1.0.16/30 dev eth2 proto kernel scope link src 100.1.0.18
100.1.4.0/24 dev eth1 proto kernel scope link src 100.1.4.1
100.2.0.0/30 dev eth0 proto kernel scope link src 100.2.0.1Senza demoni di instradamento il kernel conosce solo le reti collegate (proto kernel), e verso la B non c'è alcuna rotta: Network is unreachable, esattamente come in LAB2.
Passo 2: avviare RIP
Su ogni router tranne r5:
root@r4:~$ systemctl start frr # avvia zebra e il demone ripdDopo un po' le rotte lontane compaiono:
root@r4:~$ ping 100.1.2.1
64 bytes from 100.1.2.1: icmp_seq=1 ttl=63 time=0.743 msttl=63: la risposta ha attraversato un solo router (r1), . Percorso r4 r1 r2. Tabella del kernel su r4 dopo la convergenza:
100.1.0.0/30 via 100.1.0.13 dev eth3 proto rip metric 20
100.1.0.4/30 via 100.1.0.17 dev eth2 proto rip metric 20
100.1.0.8/30 via 100.1.0.17 dev eth2 proto rip metric 20
100.1.0.12/30 dev eth3 proto kernel scope link src 100.1.0.14
100.1.0.16/30 dev eth2 proto kernel scope link src 100.1.0.18
100.1.1.0/24 via 100.1.0.13 dev eth3 proto rip metric 20
100.1.2.0/24 via 100.1.0.13 dev eth3 proto rip metric 20
100.1.3.0/24 via 100.1.0.17 dev eth2 proto rip metric 20
100.1.4.0/24 dev eth1 proto kernel scope link src 100.1.4.1
100.2.0.0/30 dev eth0 proto kernel scope link src 100.2.0.1Le rotte proto rip sono quelle imparate dal protocollo; proto kernel quelle collegate. Il valore metric 20 è la priorità con cui FRR scrive la rotta nel kernel: è uguale per tutte le rotte RIP, anche per quelle con metrica RIP diversa. La metrica RIP si legge in show ip rip.
Passo 3: i pacchetti RIPv2
root@r4:~$ tcpdump -tenni eth2 -v # -v: decodifica completa dei protocolli
100.1.0.17.520 > 224.0.0.9.520:
RIPv2, Response, length: 124, routes: 6 or less
AFI IPv4, 100.1.0.0/30, metric: 2, next-hop: self
AFI IPv4, 100.1.0.4/30, metric: 1, next-hop: self
AFI IPv4, 100.1.0.8/30, metric: 1, next-hop: self
AFI IPv4, 100.1.1.0/24, metric: 2, next-hop: self
AFI IPv4, 100.1.2.0/24, metric: 2, next-hop: self
AFI IPv4, 100.1.3.0/24, metric: 1, next-hop: selfChe cosa si legge:
- il mittente è
100.1.0.17(r3, interfacciaeth2) e il destinatario è224.0.0.9, l'indirizzo multicast dei router RIPv2: porta UDP 520 sia in origine sia in destinazione, conttl 1(il messaggio non esce dalla rete locale) e MAC di destinazione01:00:5e:00:00:09(per ogni indirizzo multicast IPv4 il MAC si ottiene mettendo i bit meno significativi dell'indirizzo dopo il prefisso01:00:5e:224.0.0.9termina con0.0.9, quindi00:00:09); length: 124è la lunghezza del messaggio RIP: byte di intestazione (comando, versione) più byte per ogni rotta, quindi con le sei rotte. Un messaggio contiene al massimo rotte ( byte); con più reti se ne mandano più messaggi (nell'uscita si leggeroutes: 6 or less);- è una Response (annuncio periodico, a intervalli regolari, di norma ogni s) con le rotte che r3 conosce, ognuna con la propria metrica (il vicino aggiunge ). Per la rete
100.1.3.0/24, collegata a r3, la metrica annunciata è ; per100.1.0.0/30(E, a due salti da r3) è ; ...; - mancano le reti che r3 ha imparato da r4 (H, D, L) e la rete I su cui sta inviando: è la regola dello split horizon, cioè un router non annuncia a un vicino le rotte che ha imparato da quel vicino. Le sei rotte sono esattamente quelle attese (calcolo con Python: E, F, G, A, B, C su r3).
La tabella RIP interna di r4 (da vtysh):
root@r4:~$ vtysh
r4# show ip rip
Network Next Hop Metric From Time
R 100.1.0.0/30 100.1.0.13 2 100.1.0.13 02:55
R 100.1.0.4/30 100.1.0.17 2 100.1.0.17 02:27
...| Rete di r4 | Prossimo salto | Metrica |
|---|---|---|
| 100.1.0.0/30 (E) | 100.1.0.13 (r1) | 2 |
| 100.1.0.4/30 (F) | 100.1.0.17 (r3) | 2 |
| 100.1.0.8/30 (G) | 100.1.0.17 (r3) | 2 |
| 100.1.0.12/30 (H) | collegata | 1 |
| 100.1.0.16/30 (I) | collegata | 1 |
| 100.1.1.0/24 (A) | 100.1.0.13 (r1) | 2 |
| 100.1.2.0/24 (B) | 100.1.0.13 (r1) | 3 |
| 100.1.3.0/24 (C) | 100.1.0.17 (r3) | 2 |
| 100.1.4.0/24 (D) | collegata | 1 |
| 100.2.0.0/30 (L) | collegata | 1 |
Ricalcolata con Python come numero minimo di router da attraversare ( per le reti collegate; per esempio verso B: r4 r1 r2, due router più la rete collegata a r2, ): coincide con l'uscita di show ip rip delle slide. Verso G e B ci sono due percorsi di pari costo (G: via r1 oppure via r3; B: via r1 oppure via r3, entrambi a ): RIP ne sceglie uno solo. La colonna Time è un conto alla rovescia che riparte a ogni annuncio ricevuto: se arriva a zero (timeout, s) la rotta sparisce.
Passo 4: collegare la rete stub a «Internet» con rotte statiche
La rete interna ha un'unica connessione verso l'esterno (r5): è una stub network, e per collegarla bastano rotte statiche.
- Traffico entrante (destinato a
100.1.0.0/16): r5 lo manda a r4. - Traffico uscente (destinato a
0.0.0.0/0): r4 lo manda a r5.
root@r5:~$ ip route add 100.1.0.0/16 via 100.2.0.1 # tutta la rete interna è dietro r4
root@r5:~$ ping 100.1.2.1 # ora risponde: ttl=62 (la risposta passa per r1 e r4)Una sola rotta aggregata per tutta la rete interna: 100.1.0.0/16 contiene le reti –, quindi anche le reti A, B, C, D e le (supernetting, vedi Subnetting e supernettingIl subnetting divide un blocco di indirizzi in sottoblocchi più piccoli allungando la maschera ($n_{\text{sub}}=n_{\text{rete}}+s$, con $2^s$ sottoreti); il supernetting (aggregazione CIDR) fa l'opposto, accorciando il prefisso per unire blocchi contigui in uno più grande. Regole di progetto: ogni sottorete ha un numero di indirizzi potenza di 2 ($M=2^k\ge$ host richiesti $+2$), prefisso $n=32-k$, indirizzo iniziale multiplo di $M$; si assegnano prima le sottoreti più grandi. Per aggregare $2^j$ blocchi di prefisso $n$ servono blocchi contigui il cui primo indirizzo sia multiplo della dimensione dell'aggregato, e il nuovo prefisso è $n-j$.Subnetting e supernetting →). Il ttl=62 della slide corrisponde a : r5 r4 r1 r2 attraversa due router prima di raggiungere l'indirizzo di r2.
Su r4, passo 1: rotta predefinita verso r5.
root@r4:~$ ip route add default via 100.2.0.2 # default dal kernel: tutto il resto va a r5Passo 2: bisogna far sapere agli altri router che r4 è la strada per l'esterno, cioè iniettare la rotta predefinita in RIP:
root@r4:~$ vtysh # shell FRR
r4# configure # inizia la configurazione
r4(config)# router rip # configura il protocollo RIP
r4(config-router)# route 0.0.0.0/0 # annuncia in RIP la rotta 0.0.0.0/0 (statica)
r4(config-router)# quit # fine della configurazione di RIP
r4(config)# quit # fine della configurazione
r4# exitDopo un po' la rotta predefinita è arrivata a tutti, per esempio su r1:
default via 100.1.0.14 dev eth0 proto rip metric 20
100.2.0.0/30 via 100.1.0.14 dev eth0 proto rip metric 20
...(100.1.0.14 è l'indirizzo di r4 sulla rete H). Anche la rete 100.2.0.0/30 è arrivata grazie al redistribute connected di r4.
Prova con un indirizzo qualunque, anche inesistente: da r1 ping 193.204.161.1 risponde Destination Net Unreachable da 100.2.0.2. Sniffando su r5 (tcpdump -tenni eth0) si vede che il pacchetto è arrivato: r5 riceve l'echo request, ma non avendo rotta verso 193.204.161.1 risponde con ICMP net unreachable (Protocollo ICMPIPv4 non ha meccanismi per segnalare o correggere gli errori né per interrogare host e router: li fornisce l'ICMP (Internet Control Message Protocol), un protocollo di rete i cui messaggi viaggiano dentro datagrammi IP con campo Protocol $=1$. I messaggi sono di errore (destination unreachable, tipo 3; time exceeded, tipo 11; redirect, tipo 5; parameter problem, tipo 12), sempre inviati alla sorgente originale e con l'intestazione IP più i primi 8 byte del datagramma che ha causato l'errore, oppure di interrogazione (echo request 8 e reply 0, timestamp 13-14). ICMP segnala ma non corregge. Con l'echo si fanno ping (RTT) e scoperta dell'MTU (bit D, codice 4, payload massimo $1500-20-8=1472$ byte); con time exceeded e port unreachable si fa traceroute ($n+1$ messaggi con TTL crescente). Attacchi: smurf e redirect.Protocollo ICMP →). Quindi la rotta predefinita funziona: l'errore viene dall'esterno, non dalla rete interna.
Passo 5: guasto di un'interfaccia
root@r1:~$ traceroute 100.1.0.10 # r3 eth1, rete G collegata a r1: un solo salto
1 100.1.0.10 24 ms 1 ms 1 ms
root@r1:~$ ip link set eth1 down # spegne eth1 di r1: cade il collegamento G
root@r1:~$ traceroute 100.1.0.10
1 100.1.0.14 1 ms 1 ms 1 ms # r1 prova la rotta predefinita, verso r4
2 * * * # ...ma i pacchetti si perdono
3 * * *Appena cade il collegamento, la rete 100.1.0.8/30 (G) sparisce da r1 e il traffico per 100.1.0.10 esce dalla rotta predefinita verso r4 (100.1.0.14): ma le tabelle degli altri router non sono ancora aggiornate, e i pacchetti non arrivano. Dopo un po' RIP ha propagato il cambiamento:
1 100.1.0.14 1 ms 1 ms 1 ms # r4
2 100.1.0.10 5 ms 2 ms 1 ms # r3, raggiunto da r4 attraverso IIl percorso si è riaggiustato da solo (due salti invece di uno): è il vantaggio di RIP rispetto alle rotte statiche, che avrebbero richiesto un intervento a mano. Il prezzo è il tempo di convergenza, durante il quale le tabelle sono incoerenti.
redistribute connected
Proprietà (annunci predefiniti di RIP). Senza altre istruzioni, RIP annuncia le reti collegate delle sole interfacce su cui è attivo (
network).redistribute connectedcostringe ad annunciare tutte le reti collegate. Il significato vale per qualunque protocollo, ma il comportamento predefinito no: alcuni protocolli (BGP, per esempio) non annunciano nulla se non lo si dice espressamente.
Esempio. Nel laboratorio RIP, r4 non ha RIP attivo su eth0 (100.2.0.1 non è in 100.1.0.0/16): con redistribute connected annuncia comunque 100.2.0.0/30, così r1 impara che dietro r4 c'è anche la rete verso r5.
Prove suggerite
- Sniffare su più interfacce (
tcpdump -tenni ethN -v) e osservare gli annunci ogni s circa. - Fare
show ip ripeip routesu un router lontano (r2) e verificare le metriche con il calcolo dei salti. - Spegnere
eth1di r1 e seguire contracerouteripetuti la convergenza.
Errori tipici
- Dimenticare
systemctl start frr(nel laboratorio RIP FRR non parte da solo) e quindi trovare solo le reti collegate. - Avviare FRR anche su r5: r5 usa solo rotte statiche.
- Mettere in
networkun prefisso che non contiene l'indirizzo dell'interfaccia: RIP non parte su quell'interfaccia. - Dimenticare la rotta predefinita anche in RIP (
route 0.0.0.0/0): r4 sa uscire, gli altri router no. - Confondere la metrica del kernel (
metric 20) con quella di RIP (numero di salti).
Versione ripasso
- Idea. Il router è una macchina che esegue un demone di instradamento: i protocolli aggiornano la tabella da soli, al posto delle rotte scritte a mano (Routing statico in KatharàLaboratorio 2 (LAB2). Due LAN (195.11.14.0/24 e 200.1.1.0/24) sono unite da due router r1 e r2 collegati da una rete 100.0.0.8/30. Una interfaccia attiva inserisce da sola nella tabella di instradamento solo la rete direttamente collegata: per le altre servono rotte inserite a mano. I PC usano una rotta predefinita (
route add default gw 195.11.14.1), i router rotte statiche (route add -net 195.11.14.0/24 gw 100.0.0.9 dev eth1). Senza la rotta di ritorno su r2 le richieste di ping arrivano ma le risposte no: la raggiungibilità vale solo se c'è un percorso in entrambi i versi. A configurazione finitapingda pc1 a pc2 risponde con ttl=62 (64 meno 2 router).Routing statico in Katharà →). Teoria: Protocolli di instradamento - RIP, OSPF e BGPIn Internet l'instradamento non si può fare con un solo protocollo, per scalabilità (tabelle troppo grandi) e per autonomia amministrativa: ogni ISP è un sistema autonomo (AS) con il proprio algoritmo. All'interno di un AS si usano i protocolli IGP: RIP (distance vector, numero di salti, massimo 15, aggiornamenti ogni circa 30 s, su UDP porta 520) e OSPF (link state con Dijkstra, aree collegate all'area 0, cinque tipi di LSA, messaggi direttamente in IP). Tra AS si usa BGP4 (path vector, su TCP porta 179, eBGP tra AS e iBGP dentro l'AS, scelta del percorso per politica: preferenza locale, AS-PATH più corto, origine; i cicli si evitano scartando i cammini che contengono già il proprio AS; quattro messaggi: Open, Keepalive, Notification, Update).Protocolli di instradamento - RIP, OSPF e BGP → e Algoritmi di instradamento - link state e distance vectorL'instradamento (routing) trova il percorso di costo minimo in un grafo pesato in cui i router sono nodi e le reti tra due router sono archi. Link state: ogni router diffonde con un flooding i pacchetti LSP sui propri collegamenti, ricostruisce tutto il grafo e applica Dijkstra (nodi con stato (distanza, permanente o temporaneo)). Distance vector: ogni router conosce solo i vicini e scambia con loro il proprio vettore delle distanze, aggiornato con Bellman-Ford $D_{A,w}=\min{D_{A,w},,D_{A,Y}+d_{Y,w}}$; converge in al più $n-1$ giri ma può soffrire del conteggio all'infinito (limite a 16, hold down, aggiornamenti immediati, split horizon con poison reverse). Path vector: ogni annuncio porta l'intero cammino, si sceglie per politica e non per costo, e i cicli si scoprono trovando sé stessi nel cammino. Dijkstra è corretto se i costi sono non negativi (invariante: un nodo permanente ha già la distanza vera); Bellman-Ford è corretto perché dopo $k$ giri conosce i cammini minimi con al più $k+1$ archi.Algoritmi di instradamento - link state e distance vector →. - FRRouting. Suite di demoni:
zebragestisce la tabella del kernel e parla con gli altri;ripd,ospfd,bgpdimplementano i protocolli. Immaginekathara/frr, scelta conkathara settingsoppure conr1[image]="kathara/frr"nellab.conf. - File.
/etc/frr/daemonsattiva i demoni (zebra=yes,ripd=yes, gli altrino)./etc/frr/vtysh.confconservice integrated-vtysh-configusa un solo file./etc/frr/frr.confè una lista di comandi operativi: per annullare un comando si ripete conno. Avvio:systemctl start frr, anche nel.startup. vtysh. Shell unica senza password per tutti i demoni:enable/disable,configure,show ip route,show ip rip,show running-config,write,ping,no,exit. Codici dishow ip route:Kkernel,Ccollegata,Sstatica,RRIP,OOSPF,BBGP. Simboli:>rotta scelta,*installata nel kernel.- Comandi
ip(al posto diifconfigeroute):
ip address add 100.0.0.1/24 dev eth0 # assegna l'indirizzo all'interfaccia
ip route add 10.1.0.0/16 via 10.0.0.2 # rotta statica verso una rete
ip route add default via 10.0.0.2 # rotta predefinita
systemctl start frr # avvia zebra e i demoni attivati in daemons- RIPv2.
router ripattiva il protocollo.network <prefisso>: RIP lavora sulle interfacce con indirizzo nel prefisso, dove invia e riceve.redistribute connected: annuncia tutte le reti collegate, anche su interfacce senza RIP. Metrica = numero di salti: rete collegata , per ogni router che inoltra l'annuncio, = irraggiungibile. Distanza amministrativa , che si legge in[120/3]. Messaggi UDP porta 520 verso il multicast224.0.0.9, ttl 1. Split horizon: un router non annuncia a un vicino le rotte imparate da quel vicino. - Esperimento 1 (
kathara-lab_frr, tre router in fila). Reti A100.0.0.0/24(r1.eth0), B150.0.0.0/30(r1-r2), C200.0.0.0/30(r2-r3), D220.0.0.0/24(r3.eth1). Configurazione: r1 hanetwork 150.0.0.0/8eredistribute connected; r2 hanetwork 150.0.0.0/8e200.0.0.0/8; r3 hanetwork 200.0.0.0/8.- Su r3
show ip routedàR>* 100.0.0.0/24 [120/3] via 200.0.0.1eR>* 150.0.0.0/30 [120/2]: la metrica di 100.0.0.0/24 è (r1) (r2) (r3) .
- Su r3
- Esperimento 2 (
kathara-lab_rip, rete stub). Rete100.1.0.0/16con r1-r4 e r5 «Internet». Collegamenti: E100.1.0.0/30(r1-r2), F100.1.0.4/30(r2-r3), G100.1.0.8/30(r1-r3), H100.1.0.12/30(r1-r4), I100.1.0.16/30(r3-r4), L100.2.0.0/30(r4-r5). LAN foglia A100.1.1.0/24, B100.1.2.0/24, C100.1.3.0/24, D100.1.4.0/24. Tutti i router di100.1.0.0/16hannonetwork 100.1.0.0/16; r4 ha ancheredistribute connectedper la rete L. r5 non avvia FRR.- Passo 1, prima di RIP. Da r4,
ping 100.1.0.13risponde,ping 100.1.2.1dàNetwork is unreachable: il kernel conosce solo le reti collegate (proto kernel). - Passo 2, avvio.
systemctl start frrsu r1-r4. Compaiono rotteproto ripconmetric 20(priorità nel kernel, non metrica RIP, che si legge inshow ip rip). Su r4 le metriche sono: E, F, G, A, C ; B ; H, I, D, L . Il ping verso100.1.2.1dàttl=63: un router attraversato (r1). - Passo 3, pacchetti.
tcpdump -tenni eth2 -vsu r4 mostra un Response da100.1.0.17(r3) verso224.0.0.9, con sei rotte: E , F , G , A , B , C . Mancano H, D, L e I per lo split horizon. - Passo 4, uscita verso l'esterno. Su r5:
ip route add 100.1.0.0/16 via 100.2.0.1(rotta aggregata, Subnetting e supernettingIl subnetting divide un blocco di indirizzi in sottoblocchi più piccoli allungando la maschera ($n_{\text{sub}}=n_{\text{rete}}+s$, con $2^s$ sottoreti); il supernetting (aggregazione CIDR) fa l'opposto, accorciando il prefisso per unire blocchi contigui in uno più grande. Regole di progetto: ogni sottorete ha un numero di indirizzi potenza di 2 ($M=2^k\ge$ host richiesti $+2$), prefisso $n=32-k$, indirizzo iniziale multiplo di $M$; si assegnano prima le sottoreti più grandi. Per aggregare $2^j$ blocchi di prefisso $n$ servono blocchi contigui il cui primo indirizzo sia multiplo della dimensione dell'aggregato, e il nuovo prefisso è $n-j$.Subnetting e supernetting →). Su r4:ip route add default via 100.2.0.2, poi invtysh,configure,router rip,route 0.0.0.0/0per iniettare il default in RIP. Dopo un po' r1 hadefault via 100.1.0.14 proto rip. Da r1ping 193.204.161.1riceveDestination Net Unreachableda100.2.0.2: l'errore viene da r5, quindi la rotta predefinita funziona (Protocollo ICMPIPv4 non ha meccanismi per segnalare o correggere gli errori né per interrogare host e router: li fornisce l'ICMP (Internet Control Message Protocol), un protocollo di rete i cui messaggi viaggiano dentro datagrammi IP con campo Protocol $=1$. I messaggi sono di errore (destination unreachable, tipo 3; time exceeded, tipo 11; redirect, tipo 5; parameter problem, tipo 12), sempre inviati alla sorgente originale e con l'intestazione IP più i primi 8 byte del datagramma che ha causato l'errore, oppure di interrogazione (echo request 8 e reply 0, timestamp 13-14). ICMP segnala ma non corregge. Con l'echo si fanno ping (RTT) e scoperta dell'MTU (bit D, codice 4, payload massimo $1500-20-8=1472$ byte); con time exceeded e port unreachable si fa traceroute ($n+1$ messaggi con TTL crescente). Attacchi: smurf e redirect.Protocollo ICMP →). - Passo 5, guasto.
traceroute 100.1.0.10da r1 fa un salto. Conip link set eth1 downsu r1 la rotta cade e il traffico va al default verso r4 (100.1.0.14), ma senza risposta (* * *) finché le tabelle non si aggiornano. Dopo la convergenza il percorso è100.1.0.14poi100.1.0.10, due salti: RIP si riadatta da solo, a costo di un periodo di incoerenza.
- Passo 1, prima di RIP. Da r4,
- Proprietà degli annunci. Senza istruzioni RIP annuncia le reti collegate delle sole interfacce su cui è attivo.
redistribute connectedle annuncia tutte. Il comportamento predefinito non è uguale per tutti i protocolli: BGP, per esempio, non annuncia nulla se non lo si dice espressamente. - Prove suggerite. Sniffare su più interfacce per vedere gli annunci ogni 30 s circa;
show ip ripeip routesu un router lontano, verificando le metriche con il conteggio dei salti; spegnereeth1di r1 e seguire la convergenza contracerouteripetuti. - Errori tipici: dimenticare
systemctl start frr(in LAB RIP non parte da solo); avviarlo anche su r5 (usa solo rotte statiche); mettere innetworkun prefisso che non contiene l'indirizzo dell'interfaccia (RIP non parte su quella interfaccia); dimenticareroute 0.0.0.0/0in RIP (r4 sa uscire, gli altri no); confonderemetric 20del kernel con la metrica RIP.