Skip to main content
  1. Blog/

Lab 01: Rotte Statiche e VLAN Tag

·11 mins
Alessio Barnini
Author
Alessio Barnini
Table of Contents
Lab Cisco Packet Tracer - This article is part of a series.
Part 1: This Article

TL;DR
  • 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 statica
  • show ip route - tabella di routing corrente
  • ping [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 --- 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.

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.

Topologia iniziale senza IP

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.

RouterInterfacciaIPVerso
Aldog0/0192.168.64.xKali
Aldog0/110.0.0.1Marco
Marcog0/010.0.0.2Aldo
Marcog0/1.1010.10.10.1Sofia
Sofiag0/0.1010.10.10.2Marco
Sofiag0/1.1010.20.20.1Luca
Lucag0/0.1010.20.20.2Sofia
Lucag0/1.1010.30.30.1Giulia
Giuliag0/0.1010.30.30.2Luca

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'IP 10.20.20.2/30
  • Sulla g0/1.10 (verso Giulia) ha l'IP 10.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".

Configurazione interfacce Router1

Da CLI:

interface GigabitEthernet0/1
 no shutdown

Attenzione: 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 shutdown

Tre righe, tre concetti:

  • interface GigabitEthernet0/1.10 - creo il canale logico .10 sull'interfaccia fisica g0/1
  • encapsulation dot1Q 10 - dico al router di taggare i frame in uscita con VLAN ID 10
  • ip 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  Giulia

Ogni 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

end

Marco (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

end

Sofia (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

end

Luca (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

end

Giulia (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

end

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 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
#

Esempio di configurazione 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.2

Marco - 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.2

Sofia - tutto 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 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

show ip route Marco

Il comando 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 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.1

Nota 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.


Codice

Script e file di configurazione del lab: github.com/Barno/u-random-dev

Lab Cisco Packet Tracer - This article is part of a series.
Part 1: This Article

Related