- Un router conosce solo le reti a cui e' direttamente collegato. Tutto il resto va detto esplicitamente con rotte statiche
- Ogni router ha piu' IP - uno per ogni interfaccia. "Marco e' 10.0.0.2" e' incompleto: Marco e' anche 10.10.10.1
- Le rotte statiche funzionano come indicazioni stradali: "se vuoi andare la', chiedi a lui"
- Se un lato usa dot1Q, l'altro deve essere identico altrimenti il traffico viene droppato silenziosamente
- Se manca una rotta il pacchetto si ferma - il TTL serve per evitare loop
▶ $ history
ip route [rete] [maschera] [next-hop]- aggiunta rotta staticashow ip route- tabella di routing correnteping [ip]- test connettivita' end-to-end
Prima di replicare il routing in Linux, l'ho costruito in Cisco Packet Tracer. Questa e' la storia di come ho capito le rotte statiche, le subinterface e il tagging 802.1Q facendo finta di essere un pacchetto.
La topologia#
Cinque router in catena lineare. Kali fuori, Giulia come destinazione finale.
Kali --- Aldo --- Marco --- Sofia --- Luca --- GiuliaI 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.
I router sono collegati direttamente tra loro con cavi crossover - nessuno switch in mezzo. Ogni link 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, scrivi la tabella degli IP. Senza questa sotto mano ti perdi.
| Router | Interfaccia | IP | Verso |
|---|---|---|---|
| Aldo | g0/0 | 192.168.64.x | Kali |
| Aldo | g0/1 | 10.0.0.1 | Marco |
| Marco | g0/0 | 10.0.0.2 | Aldo |
| Marco | g0/1.10 | 10.10.10.1 | Sofia |
| Sofia | g0/0.10 | 10.10.10.2 | Marco |
| Sofia | g0/1.10 | 10.20.20.1 | Luca |
| Luca | g0/0.10 | 10.20.20.2 | Sofia |
| Luca | g0/1.10 | 10.30.30.1 | Giulia |
| Giulia | g0/0.10 | 10.30.30.2 | Luca |
Nota la colonna Interfaccia: da Marco in poi non si usano le interfacce fisiche (g0/1) ma le subinterface (g0/1.10). Questo e' il punto dove molti si bloccano - ci torno tra poco.
"Che IP ha questo router?"#
Una delle cose che all'inizio confonde e' questa domanda. "Che IP ha Luca?"
Luca e' un router, quindi ha piu' interfacce di livello 3 (L3), ognuna con il suo IP nella sua specifica subnet:
- Sulla
g0/0.10(verso Sofia) ha l'IP10.20.20.2/30 - Sulla
g0/1.10(verso Giulia) ha l'IP10.30.30.1/30
Quindi "che IP ha Luca?" non ha una sola risposta. Dipende da chi lo sta guardando:
- Dal lato di Sofia, Luca e' il
10.20.20.2 - Dal lato di Giulia, Luca e' il
10.30.30.1
Dire "Marco e' 10.0.0.2" e' incompleto: Marco e' anche 10.10.10.1. E' come chiedere "qual e' il tuo numero di telefono?" a qualcuno che ne ha due.
Il router, per definizione, e' il nodo che unisce reti diverse. Per farlo:
- Ha un'interfaccia per ogni rete a cui e' collegato
- Ogni interfaccia ha la propria coppia IP/mask
- Il forwarding avviene tra queste interfacce, consultando la tabella di routing
Accendere le interfacce fisiche#
Con la GUI di Packet Tracer: click sul router, tab Config, seleziono l'interfaccia fisica, spunto "On".

Da CLI:
interface GigabitEthernet0/1
no shutdownAttenzione: l'interfaccia fisica non deve avere un IP assegnato se si usano subinterface. L'IP va sulla subinterface, non sul parent. Lasciala accesa ma vuota.
Cosa e' una subinterface (e perche' esiste)#
Un'interfaccia fisica e' un cavo. Una subinterface e' un canale logico dentro quel cavo, identificato da un numero (es. g0/1.10).
Perche' usarla? Per fare trunk 802.1Q: mandare traffico di piu' VLAN sullo stesso cavo fisico, distinguendole con un tag nell'header Ethernet.
In questo lab uso una sola VLAN (la 10) da Marco in poi. Avrei potuto usare interfacce fisiche, ma con le subinterface il frame porta un tag che si vede in Simulation Mode - utile per capire cosa succede dentro il pacchetto.
La sintassi per creare una subinterface:
interface GigabitEthernet0/1.10
encapsulation dot1Q 10
ip address 10.10.10.1 255.255.255.252
no shutdownTre righe, tre concetti:
interface GigabitEthernet0/1.10- creo il canale logico.10sull'interfaccia fisicag0/1encapsulation dot1Q 10- dico al router di taggare i frame in uscita con VLAN ID 10ip address- assegno l'IP a questo canale logico, non all'interfaccia fisica
La regola della simmetria#
Questo e' il punto critico che l'articolo precedente non spiegava abbastanza chiaramente:
Se un lato usa una subinterface dot1Q, anche l'altro lato deve usare una subinterface dot1Q con lo stesso VLAN ID.
Marco ha g0/1.10 con encapsulation dot1Q 10. Questo significa che ogni frame in uscita verso Sofia porta un tag 0x8100 con VLAN ID 10. Se Sofia riceve su g0/0 fisica (senza subinterface), non sa come interpretare quel tag - e droppa il frame.
La simmetria e' obbligatoria:
Marco g0/1.10 dot1Q 10 →→→ g0/0.10 dot1Q 10 Sofia
Sofia g0/1.10 dot1Q 10 →→→ g0/0.10 dot1Q 10 Luca
Luca g0/1.10 dot1Q 10 →→→ g0/0.10 dot1Q 10 GiuliaOgni link ha due "bocche" - entrambe devono parlare lo stesso dialetto.
Configurazione completa#
Aldo (Router0)#
Il link verso Kali e' normale (nessuna VLAN), il link verso Marco anche - Aldo usa interfacce fisiche su entrambi i lati.
enable
configure terminal
interface GigabitEthernet0/0
ip address 192.168.64.1 255.255.255.0
no shutdown
interface GigabitEthernet0/1
ip address 10.0.0.1 255.255.255.252
no shutdown
endMarco (Router1)#
Il link verso Aldo e' fisico. Il link verso Sofia usa subinterface dot1Q - qui inizia la VLAN 10.
enable
configure terminal
interface GigabitEthernet0/0
ip address 10.0.0.2 255.255.255.252
no shutdown
interface GigabitEthernet0/1
no ip address
no shutdown
interface GigabitEthernet0/1.10
encapsulation dot1Q 10
ip address 10.10.10.1 255.255.255.252
no shutdown
endSofia (Router2)#
Entrambi i link usano subinterface dot1Q - Sofia sta nel mezzo della zona VLAN 10.
enable
configure terminal
interface GigabitEthernet0/0
no ip address
no shutdown
interface GigabitEthernet0/0.10
encapsulation dot1Q 10
ip address 10.10.10.2 255.255.255.252
no shutdown
interface GigabitEthernet0/1
no ip address
no shutdown
interface GigabitEthernet0/1.10
encapsulation dot1Q 10
ip address 10.20.20.1 255.255.255.252
no shutdown
endLuca (Router3)#
Stesso schema di Sofia.
enable
configure terminal
interface GigabitEthernet0/0
no ip address
no shutdown
interface GigabitEthernet0/0.10
encapsulation dot1Q 10
ip address 10.20.20.2 255.255.255.252
no shutdown
interface GigabitEthernet0/1
no ip address
no shutdown
interface GigabitEthernet0/1.10
encapsulation dot1Q 10
ip address 10.30.30.1 255.255.255.252
no shutdown
endGiulia (Router4)#
Capolinea - solo un'interfaccia verso Luca.
enable
configure terminal
interface GigabitEthernet0/0
no ip address
no shutdown
interface GigabitEthernet0/0.10
encapsulation dot1Q 10
ip address 10.30.30.2 255.255.255.252
no shutdown
endIl 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 si capisce la prima cosa importante: Aldo non sa dove si trova Marco. Aldo conosce solo le reti a cui ha un'interfaccia direttamente collegata. Tutto il resto non esiste per lui.
Ma aspetta - Aldo ha un'interfaccia su 10.0.0.0/30, quindi quella la conosce. Il problema e' che il pacchetto di ritorno da Marco non sa come tornare a 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)#
Ogni router deve sapere come rimandare le risposte al mittente, cioe' verso Kali (192.168.64.0/24).
Marco:
ip route 192.168.64.0 255.255.255.0 10.0.0.1"Per tornare a Kali, chiedi 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 - 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.2Marco - tutto 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.2Sofia - tutto cio' che sta oltre Luca:
ip route 10.30.30.0 255.255.255.252 10.20.20.2Luca e Giulia non hanno bisogno di rotte di andata - Luca e' direttamente collegato a Giulia, e Giulia e' il capolinea.
La trappola delle rotte mancanti#
Ho provato a pingare 10.20.20.1 (Sofia) da Kali. 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.
La regola: ogni subnet che esiste nella topologia deve comparire nella routing table di ogni router che non la conosce direttamente.
Cosa dice la tabella di routing#
show ip route
Il comando mostra tutto quello che un router conosce:
C- Connected, la rete e' direttamente collegata a un'interfacciaS- Static, rotta configurata manualmenteL- 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 una subinterface) o e' Static (me lo hanno detto).
La routing table corretta di Marco dovrebbe essere:
C 10.0.0.0/30 directly connected, GigabitEthernet0/0
L 10.0.0.2/32 directly connected, GigabitEthernet0/0
C 10.10.10.0/30 directly connected, GigabitEthernet0/1.10
L 10.10.10.1/32 directly connected, GigabitEthernet0/1.10
S 10.20.20.0/30 [1/0] via 10.10.10.2
S 10.30.30.0/30 [1/0] via 10.10.10.2
S 192.168.64.0/24 [1/0] via 10.0.0.1Nota GigabitEthernet0/1.10 nella colonna Connected - la subinterface VLAN 10 compare nella tabella di routing esattamente come un'interfaccia fisica. Per il router e' la stessa cosa.
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 tag viene aggiunto automaticamente dalla subinterface g0/1.10 di Marco quando spedisce un frame verso Sofia. Sofia lo riceve sulla sua g0/0.10 e lo desttagga.
Cosa succede se la simmetria manca?
Se Sofia avesse g0/0 fisica invece di g0/0.10, riceverebbe il frame taggato ma non saprebbe cosa farne - lo dropperebbe silenziosamente. Il ping fallirebbe senza nessun messaggio di errore chiaro. Questo e' esattamente il problema che ho incontrato durante il lab e che mi ha fatto perdere piu' tempo.
Questo tag e' l'equivalente Cisco di veth-fw1-raw.10 in Linux: stessa struttura, stesso concetto, stesso numero nel frame.
Il TTL e i loop#
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 128 nei router Cisco. 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 consumando banda.
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 (no tag)
Aldo → Marco 10.0.0.1 → 10.0.0.2 (no tag)
Marco → Sofia 10.0.0.2 → 10.10.10.2 (tag VLAN 10)
Sofia → Luca 10.10.10.2 → 10.20.20.2 (tag VLAN 10)
Luca → Giulia 10.20.20.2 → 10.30.30.2 (tag VLAN 10)
Giulia risponde:
Giulia → Luca 10.30.30.2 → 10.30.30.1 (tag VLAN 10)
Luca → Sofia 10.30.30.1 → 10.20.20.1 (tag VLAN 10)
Sofia → Marco 10.20.20.1 → 10.10.10.1 (tag VLAN 10)
Marco → Aldo 10.10.10.1 → 10.0.0.1 (no tag)
Aldo → Kali 10.0.0.1 → 192.168.64.200 (no tag)Dieci hop. Tutti e dieci devono funzionare. Il tag 802.1Q compare solo nei link da Marco in poi - il primo tratto Kali→Aldo→Marco e' traffico normale senza VLAN.
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.
Le subinterface dot1Q devono essere simmetriche. Se un lato tagga con VLAN 10, l'altro lato deve desttaggare con VLAN 10. Un'interfaccia fisica non capisce i frame taggati. Questa asimmetria non genera errori visibili - il pacchetto viene droppato silenziosamente.
La GUI di Packet Tracer non mostra le subinterface. Nel tab Config vedi solo le interfacce fisiche. Le subinterface esistono solo in CLI. Se cerchi l'IP nella GUI e non lo trovi, non significa che non esiste.
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.
Script e file di configurazione del lab: github.com/Barno/u-random-dev





