Laboratorio

Modulo 10 - Pratica sulle reti

Definizione piano di indirizzamento per tre LAN

Per la realizzazione di questo modulo useremo Netkit4TIC.

L'esercitazione che andremo a sviluppare è presa da un esercizio proposto nel modulo 10 dei materiali ministeriali dei corsi UMTS/TIC C2 descritta nella mappa (copia locale della mappa).

Definire un piano di indirizzamento ottimizzato per tre reti pubbliche S1, S2, S3 (LAN) connesse attraverso i rispettivi router a formare una MAN. La rete S1 è formata da 50 host, la rete S2 da 48 host e la rete S3 da 20 host. I router sono collegati tra di loro in modo che ogni router ha due collegamenti con reti minimali (parte rete di 30 bit) con gli altri due.

Soluzione

Riportiamo di seguito la tabella di una possibile assegnazione:

La tabella del range degli indirizzi è la seguente:

Assegniamo gli indirizzi alle interfacce:

Tutti gli host delle reti sono stati preconfigurati con il default gateway verso il corrispondente router:

pc1# route add default gw 192.200.96.62
pc2# route add default gw 192.200.96.126
pc3# route add default gw 192.200.96.158

Per costruire la rete virtuale così come è stata descritta con 3 host, 3 router e 6 hub basta dare il comando:

realHost$ lstart -d exercise-01

Routing statico

Ora è possibile completare l'esperienza configurando staticamente le tabelle di routing. I comandi sono:

r1# route add -net 192.200.96.128 netmask 255.255.255.224 \
          gw 192.200.96.166; \
    route add -net 192.200.96.64 netmask 255.255.255.192 \
          gw 192.200.96.162

r2# route add -net 192.200.96.128 netmask 255.255.255.224 \
          gw 192.200.96.170; \
    route add -net 192.200.96.0 netmask 255.255.255.192 \
          gw 192.200.96.161

r3# route add -net 192.200.96.0 netmask 255.255.255.192 \
          gw 192.200.96.165; \
    route add -net 192.200.96.64 netmask 255.255.255.192 \
          gw 192.200.96.169

Per testare la raggiungibilità possiamo usare il comando ping e per verificare il percorso fatto dai pacchetti il comando traceroute. Per semplicità è configurato la risoluzione dei nomi pc1, pc2, pc3 a livello di file /etc/hosts.

pc1# ping -c 1 pc3
PING pc3 (192.200.96.129): 56 data bytes
64 bytes from 192.200.96.129: icmp_seq=0 ttl=62 time=7.7 ms
[...]

pc1# ping -c 1 pc2
PING pc2 (192.200.96.65): 56 data bytes
64 bytes from 192.200.96.65: icmp_seq=0 ttl=62 time=7.3 ms
[...]

pc1# traceroute pc2
traceroute to pc2 (192.200.96.65), 64 hops max, 40 byte packets
 1  r1-eth0 (192.200.96.62)  6 ms  8 ms  2 ms
 2  r2-eth1 (192.200.96.162)  15 ms  5 ms  3 ms
 3  pc2 (192.200.96.65)  12 ms  6 ms  4 ms

pc1# traceroute pc3
traceroute to pc3 (192.200.96.129), 64 hops max, 40 byte packets
 1  r1-eth0 (192.200.96.62)  3 ms  2 ms  2 ms
 2  r3-eth1 (192.200.96.166)  12 ms  5 ms  7 ms
 3  pc3 (192.200.96.129)  12 ms  4 ms  6 ms

Routing dinamico

Per attivare invece il protocollo di routing RIP non occorre impostare alcuna regola di routing che invece sarà determinata da zebra che implementa il protocollo RIP (e altri) in ogni router rX:

rX# /etc/init.d/zebra start

Vediamo se ha calcolato le stesse route che avevamo impostato staticamente in precedenza:

r3# telnet localhost zebra
Password: root
[...]
zebrad> show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       B - BGP, > - selected route, * - FIB route

C> 127.0.0.0/8 is directly connected, lo
R> 192.200.96.0/26 [120/2] via 192.200.96.165, eth1, 00:00:21
R> 192.200.96.64/26 [120/2] via 192.200.96.169, eth2, 00:00:17
C> 192.200.96.128/27 is directly connected, eth0
R> 192.200.96.160/30 [120/2] via 192.200.96.165, eth1, 00:00:21
C> 192.200.96.164/30 is directly connected, eth1
C> 192.200.96.168/30 is directly connected, eth2
zebrad> quit

Possiamo notare che il RIP determina, almeno per il router r3, tre regole di routing contro le nostre due poichè individua la presenza della rete 192.200.96.160 che per la verità esiste ma è completamente controllata dai router r1 ed r2.

Sandro Doro (email me)
Ultima modifica: $Date: 2006-10-10 15:01:03 $