Cisco Packet Tracer: Cinque Router, Una Catena, Nessun GPS

Prima di toccare Linux voglio vedere il routing con gli occhi. In Linux i namespace sono invisibili - sono processi, non oggetti fisici. In Cisco Packet Tracer posso vedere i router come scatole, i cavi come linee, e guardare i pacchetti muoversi.

Ho deciso di costruire qui la stessa topologia del lab Linux. Cinque router in fila, Kali fuori, un ping come obiettivo finale.

La topologia

#

Cinque router, una catena lineare. Non un ring, non una stella - una catena. Ogni router parla solo con i due vicini.

Kali --- Aldo --- Marco --- Sofia --- Luca --- Giulia

I nomi li ho scelti io durante il lab Linux - piu' facile ricordare "vai da Sofia" che "vai in ns-dmz". In Packet Tracer li chiamo Router0, Router1... ma nella mia testa rimangono Aldo, Marco, Sofia, Luca, Giulia.

Ogni link tra due router e' una subnet /30. Quattro indirizzi, due host, zero sprechi.

Appena posizionati i router e tracciati i cavi, tutte le interfacce sono rosse. Spente. Un router in Packet Tracer nasce con le interfacce amministrativamente chiuse - bisogna attivarle a mano.

Schema IP

#

Prima di configurare qualsiasi cosa, mi sono scritto la tabella degli IP. Senza questa sotto mano mi perdo.

Ogni router ha due IP perche' ha due interfacce. Chiedere "qual e' l'IP di Marco?" e' come chiedere "qual e' il tuo numero di telefono?" a qualcuno che ne ha due - uno di casa e uno del lavoro. Dipende da chi lo chiama.

Accendere le interfacce

#

Con la GUI di Packet Tracer si fa cosi': click sul router, tab Config, seleziono l'interfaccia, spunto "On". Le linee passano da rosse a verdi.

Da CLI sarebbe:

interface GigabitEthernet0/1
 ip address 10.0.0.1 255.255.255.252
 no shutdown

Il no shutdown e' l'equivalente di accendere il walkie-talkie. Finche' non lo fai, il router ha l'interfaccia ma non la usa.

Il problema del routing

#

Interfacce accese, IP assegnati. Provo a pingare da Kali verso Aldo.

Funziona. Aldo risponde.

Provo a pingare 10.0.0.2 (Marco). Non risponde.

Qui ho capito la prima cosa importante: Aldo non sa dove si trova Marco. Aldo conosce solo la sua rete verso Kali (192.168.64.0/24). Non sa che esiste 10.0.0.0/30 - anche se ci ha un'interfaccia.

Aspetta. Ha un'interfaccia su 10.0.0.0/30, quindi la conosce direttamente. Il problema e' che il pacchetto di ritorno da Marco non sa come tornare da Kali. Marco non ha una rotta verso 192.168.64.0/24.

Questo e' il routing: non basta che il pacchetto arrivi - deve anche tornare.

Le rotte statiche

#

Una rotta statica dice a un router: "se vuoi raggiungere questa rete, chiedi a questo vicino".

Come chiedere indicazioni stradali: "per andare a Milano, vai sull'autostrada A1 e chiedi a Modena".

La sintassi in Cisco:

ip route [rete-destinazione] [maschera] [next-hop]

Le rotte di ritorno (return routes)

#

La prima cosa che ho configurato su ogni router e' la rotta di ritorno verso Kali (192.168.64.0/24). Ogni router deve sapere come rimandare le risposte al mittente.

Marco:

ip route 192.168.64.0 255.255.255.0 10.0.0.1

"Se qualcuno ti chiede di tornare a Kali, manda tutto ad Aldo (10.0.0.1)."

Sofia:

ip route 192.168.64.0 255.255.255.0 10.10.10.1

"Per tornare a Kali, chiedi a Marco (10.10.10.1)."

Luca:

ip route 192.168.64.0 255.255.255.0 10.20.20.1

"Per tornare a Kali, chiedi a Sofia (10.20.20.1)."

Giulia:

ip route 192.168.64.0 255.255.255.0 10.30.30.1

"Per tornare a Kali, chiedi a Luca (10.30.30.1)."

Le rotte di andata (forward routes)

#

Le return routes non bastano. Aldo deve sapere come raggiungere Sofia, Luca, Giulia. Marco deve sapere come raggiungere Luca e Giulia. E cosi' via.

Aldo - rotte verso tutto cio' che sta oltre Marco:

ip route 10.10.10.0 255.255.255.252 10.0.0.2
ip route 10.20.20.0 255.255.255.252 10.0.0.2
ip route 10.30.30.0 255.255.255.252 10.0.0.2

Marco - rotte verso cio' che sta oltre Sofia:

ip route 10.20.20.0 255.255.255.252 10.10.10.2
ip route 10.30.30.0 255.255.255.252 10.10.10.2

Sofia - rotta verso cio' che sta oltre Luca:

ip route 10.30.30.0 255.255.255.252 10.20.20.2

Luca e Giulia non hanno bisogno di rotte di andata - Luca e' direttamente collegato a Giulia, e Giulia e' il capolinea.

La domanda giusta: perche' si ferma a Sofia?

#

Ho provato a pingare 10.20.20.1 (Sofia) da Kali. Errore. Ho provato 10.30.30.2 (Giulia). Errore.

Il ping arrivava a Sofia e si bloccava.

Il motivo: Marco non aveva la rotta verso 10.20.20.0/30. Avevo aggiunto solo 10.30.30.0 come forward route su Marco, dimenticando che per arrivare a Giulia il pacchetto passa fisicamente attraverso il link 10.20.20.0/30. Marco riceveva il pacchetto destinato a 10.20.20.1 e non sapeva dove mandarlo.

Aggiunta la rotta mancante su Marco, il ping a Sofia ha funzionato.

Cosa dice la tabella di routing

#

Il comando show ip route mostra tutto quello che un router conosce:

• C - Connected, la rete e' direttamente collegata a un'interfaccia
• S - Static, rotta configurata manualmente
• L - Local, l'IP esatto dell'interfaccia del router stesso

Un router non conosce mai le reti lontane da solo. O e' Connected (ci ho un cavo) o e' Static (me lo hanno detto).

Nota GigabitEthernet0/1.10 nella colonna Connected - la subinterface VLAN 10 compare nella tabella di routing esattamente come un'interfaccia fisica.

Il tag 802.1Q nel pacchetto

#

In modalita' Simulation, cliccando sul pacchetto mentre attraversa Marco si vede l'header Ethernet in uscita verso Sofia:

• Ethernet 802.1q - il frame ha il tag VLAN
• TPID: 0x8100 - magic number del protocollo 802.1Q
• TCI: 0x000a - in decimale e' 10. VLAN 10.
• TTL: 126 - partito da 128, decrementato due volte (Aldo e Marco)

Questo e' l'equivalente Cisco di veth-fw1-raw.10 in Linux: stessa struttura, stesso tag nel frame.

Il TTL e i loop

#

Mi sono chiesto: cosa succede se le rotte sono configurate male e il pacchetto gira in loop tra due router?

Risposta: il TTL (Time To Live). Ogni pacchetto nasce con un valore - tipicamente 64. Ogni router che lo attraversa decrementa il TTL di 1. Quando arriva a 0, il router scarta il pacchetto e manda un messaggio "TTL exceeded" al mittente.

Senza TTL, un pacchetto perso in un loop girerebbe per sempre.

Il ping finale

#

Kali pinga 10.30.30.2 (Giulia). Il pacchetto attraversa Aldo, Marco, Sofia, Luca e arriva a Giulia. La risposta torna per la stessa strada.

Il viaggio di un singolo pacchetto ICMP:

Kali              → Aldo    (192.168.64.200 -> 10.0.0.1)
Aldo              → Marco   (10.0.0.1 -> 10.0.0.2)
Marco             → Sofia   (10.0.0.2 -> 10.10.10.2)
Sofia             → Luca    (10.10.10.2 -> 10.20.20.2)
Luca              → Giulia  (10.20.20.2 -> 10.30.30.2)

Giulia risponde:
Giulia            → Luca    (10.30.30.2 -> 10.30.30.1)
Luca              → Sofia   (10.30.30.1 -> 10.20.20.1)
Sofia             → Marco   (10.20.20.1 -> 10.10.10.1)
Marco             → Aldo    (10.10.10.1 -> 10.0.0.1)
Aldo              → Kali    (10.0.0.1 -> 192.168.64.200)

Dieci hop. Tutti e dieci devono funzionare. Se uno solo non sa dove andare, il ping fallisce.

Cosa ho imparato

#

Le rotte statiche si configurano per differenza. Un router conosce gia' le reti a cui e' direttamente collegato (Connected). Aggiungo le statiche solo per quelle che non vede direttamente.

Ogni router ha piu' IP. Non esiste "l'IP di Marco" - esiste l'IP di Marco visto da Aldo e l'IP di Marco visto da Sofia. Sono due interfacce diverse, due indirizzi diversi.

Le rotte devono funzionare in entrambe le direzioni. Non basta che il pacchetto arrivi - deve anche tornare. Per ogni router intermedio devo configurare sia la rotta di andata che quella di ritorno.

Packet Tracer prima di Linux. Questo esercizio lo replico ora nei namespace Linux. Ma averlo visto qui, con le scatole fisiche e i cavi visibili, mi ha dato un modello mentale chiaro. In Linux non si vede niente - si devono immaginare le interfacce, i namespace, i link. Averli visti prima rende tutto piu' concreto.

Il prossimo passo: stessa topologia, stesse rotte, ma con ip netns, ip route add, e ip_forward=1.