VLAN e Trunk in Cisco Packet Tracer

Nel lab precedente ho usato le subinterface dot1Q per taggare i frame tra router. Il tag c'era, ma mancava qualcosa: senza uno switch in mezzo, le VLAN non separano nulla. Un frame taggato su un link diretto router-router e' solo un dettaglio di configurazione, non e' una vera VLAN.

In questo lab aggiungo tre switch alla catena esistente. Adesso il tag 802.1Q smette di essere cosmetic e diventa funzionale: e' lo switch che lo legge, lo interpreta, e decide cosa farne.

Cosa e' una VLAN (davvero)

#

Immagina uno switch con otto porte. Ci colleghi PC di due reparti diversi. Per default tutti i PC si vedono tra loro: stesso dominio broadcast, stessa rete L2. Chiunque puo' parlare con chiunque.

Con le VLAN dici allo switch:

• porte 1-4 → VLAN 10 (Reparto A)
• porte 5-8 → VLAN 20 (Reparto B)

Risultato: i PC della VLAN 10 non vedono quelli della VLAN 20. Sono due reti L2 separate sullo stesso switch fisico. Un solo apparato, due mondi distinti.

La VLAN e' una separazione logica a livello L2. Non e' routing, non e' firewall: e' isolamento del dominio broadcast.

graph LR
    subgraph SW["Switch fisico"]
        subgraph V10["VLAN 10 - Reparto A"]
            P1[Porta 1] --- PCA[PC-A]
            P2[Porta 2] --- PCB[PC-B]
        end
        subgraph V20["VLAN 20 - Reparto B"]
            P5[Porta 5] --- PCC[PC-C]
            P6[Porta 6] --- PCD[PC-D]
        end
    end

Cosa e' un trunk

#

Se hai due switch collegati tra loro, e su entrambi ci sono VLAN 10 e VLAN 20, come fai a portare il traffico di entrambe le VLAN sullo stesso cavo fisico tra i due switch?

Con un trunk: una porta configurata per trasportare frame di piu' VLAN contemporaneamente, distinguendole con il tag 802.1Q nell'header Ethernet.

graph LR
    SWA["Switch A\nVLAN 10 + 20"] -- "trunk 802.1Q\n(frame taggati)" --> SWB["Switch B\nVLAN 10 + 20"]

Sul trunk i frame viaggiano taggati. Quando arrivano dall'altra parte, lo switch legge il tag e sa in quale VLAN mettere il frame.

Le porte verso i PC invece sono access port: nessun tag, un solo VLAN ID configurato. Il PC non sa niente delle VLAN, ci pensa lo switch.

Trunk tra router e switch: il router-on-a-stick

#

Se vuoi che due VLAN diverse possano comunicare tra loro, devi passare per un router: le VLAN sono isolate a L2, ma il router lavora a L3.

Il pattern classico si chiama router-on-a-stick: un solo cavo fisico tra router e switch, configurato come trunk. Il router ha una subinterface per ogni VLAN.

graph TD
    R["Router\ng0/0.10 → VLAN 10\ng0/0.20 → VLAN 20"]
    SW["Switch\ntrunk verso router"]
    PCA["PC-A\nVLAN 10"]
    PCB["PC-B\nVLAN 20"]

    R -- "trunk dot1Q" --> SW
    SW -- "access VLAN 10" --> PCA
    SW -- "access VLAN 20" --> PCB

Il router riceve un frame taggato VLAN 10 dalla subinterface .10, lo processa a L3, e lo rimanda taggato VLAN 20 dalla subinterface .20. Lo switch desttagga e consegna al PC giusto.

La topologia del lab02

#

Partiamo dal lab01: stessa catena, stesse subinterface, stesse rotte statiche. Aggiungiamo tre switch 2960, uno per ogni link nella zona VLAN 10.

graph LR
    Kali["Kali\n192.168.64.200"] --> Aldo["Aldo\ng0/0·g0/1"]
    Aldo --> Marco["Marco\ng0/1.10"]
    Marco -- "trunk VLAN 10" --> SW0["SW0\n2960"]
    SW0 -- "trunk VLAN 10" --> Sofia["Sofia\ng0/0.10·g0/1.10"]
    Sofia -- "trunk VLAN 10" --> SW2["SW2\n2960"]
    SW2 -- "trunk VLAN 10" --> Luca["Luca\ng0/0.10·g0/1.10"]
    Luca -- "trunk VLAN 10" --> SW1["SW1\n2960"]
    SW1 -- "trunk VLAN 10" --> Giulia["Giulia\ng0/0.10"]

I router Marco, Sofia, Luca, Giulia mantengono le subinterface dot1Q del lab01. Gli switch fanno da ponte con porte trunk.

Il primo tratto (Kali → Aldo → Marco) rimane senza VLAN: link fisici diretti come nel lab01.

Schema IP

#

Invariato rispetto al lab01: gli switch operano a L2 e non hanno IP nel percorso dati.

Configurazione degli switch

#

Ogni switch 2960 ha due porte attive: una verso il router di sinistra, una verso il router di destra. Entrambe devono essere trunk con VLAN 10 permessa.

Per default un 2960 mette tutte le porte in access mode sulla VLAN 1. Bisogna cambiarle esplicitamente.

Su ogni switch (Switch0, Switch1, Switch2) la configurazione e' identica:

enable
configure terminal

vlan 10
 name RETE-INTERNA
exit

interface FastEthernet0/1
 switchport mode trunk
 switchport trunk allowed vlan 10

interface FastEthernet0/2
 switchport mode trunk
 switchport trunk allowed vlan 10

end

Tre comandi chiave:

• vlan 10 + name - crea la VLAN nel database dello switch. Senza questo la VLAN esiste solo "di passaggio" ma non e' attiva nel management domain.
• switchport mode trunk - la porta trasporta frame taggati di piu' VLAN
• switchport trunk allowed vlan 10 - filtra: solo VLAN 10 puo' passare su questo trunk

Verifica del trunk

#

Dopo la configurazione:

show interfaces trunk

L'output corretto mostra:

Port    Mode    Encapsulation  Status    Native vlan
Fa0/1   on      802.1q         trunking  1
Fa0/2   on      802.1q         trunking  1

Port    Vlans allowed on trunk
Fa0/1   10
Fa0/2   10

Port    Vlans allowed and active in management domain
Fa0/1   10
Fa0/2   10

La riga Vlans allowed and active in management domain deve mostrare 10. Se mostra none, la VLAN non e' stata creata con il comando vlan 10: aggiungila e ricontrolla.

Per vedere il dettaglio di una singola porta:

show interfaces FastEthernet0/1 switchport

I campi importanti:

Administrative Mode: trunk
Operational Mode: trunk
Operational Trunking Encapsulation: dot1q
Trunking VLANs Enabled: 10

Se Operational Mode e' access invece di trunk, il comando switchport mode trunk non e' stato applicato correttamente.

Il problema dello Spanning Tree Protocol

#

Quando ho collegato i router agli switch e ho provato il primo ping, il traffico si fermava. Marco non raggiungeva Sofia.

Il motivo non era la configurazione: era lo STP (Spanning Tree Protocol).

Quando una porta su un 2960 si accende, non diventa subito attiva per il traffico. Passa attraverso questi stati:

graph LR
    BL["Blocking"] --> LS["Listening\n15 sec"]
    LS --> LR["Learning\n15 sec"]
    LR --> FW["Forwarding"]

In totale circa 30-50 secondi. Durante questo tempo i frame vengono bloccati: il ping fallisce anche se tutto e' configurato correttamente.

La soluzione e' aspettare. Oppure, su porte che vanno verso router o host (non verso altri switch), abilitare PortFast:

interface FastEthernet0/1
 spanning-tree portfast

PortFast fa saltare gli stati intermedi e mette la porta direttamente in Forwarding. Va usato solo su porte access o trunk verso dispositivi finali: mai tra switch, altrimenti si creano loop.

Come il frame attraversa lo switch

#

Questo e' il punto che cambia rispetto al lab01.

Nel lab01, Marco mandava un frame taggato VLAN 10 direttamente a Sofia. Sofia lo riceveva e destaggera. Lo switch non c'era.

Nel lab02, il percorso e' questo:

sequenceDiagram
    participant Marco
    participant SW0
    participant Sofia

    Marco->>SW0: frame [tag VLAN 10] su Fa0/1
    Note over SW0: legge tag, cerca VLAN 10
forward su Fa0/2 (trunk)
    SW0->>Sofia: frame [tag VLAN 10] su g0/0.10
    Note over Sofia: subinterface .10 desttagga
processa a L3

Lo switch non rimuove il tag: lo mantiene sul trunk e lo consegna taggato al router. E' il router (attraverso la subinterface) che desttagga.

Se la porta dello switch verso il router fosse access invece di trunk, lo switch rimuoverebbe il tag prima di consegnarlo. Il router riceverebbe un frame non taggato sull'interfaccia fisica, non sulla subinterface, e non saprebbe cosa farne. Il frame verrebbe droppato silenziosamente.

Il viaggio del pacchetto nel lab02

#

Kali   → Aldo    192.168.64.200 → 10.0.0.1      (no tag, link diretto)
Aldo   → Marco   10.0.0.1       → 10.0.0.2      (no tag, link diretto)
Marco  → SW0     tag VLAN 10    → Fa0/1          (trunk, tag mantenuto)
SW0    → Sofia   tag VLAN 10    → g0/0.10        (trunk, tag mantenuto)
Sofia  → SW2     tag VLAN 10    → Fa0/1          (trunk, tag mantenuto)
SW2    → Luca    tag VLAN 10    → g0/0.10        (trunk, tag mantenuto)
Luca   → SW1     tag VLAN 10    → Fa0/1          (trunk, tag mantenuto)
SW1    → Giulia  tag VLAN 10    → g0/0.10        (trunk, tag mantenuto)

Giulia risponde: percorso inverso identico

Il tag nasce in Marco, viene mantenuto dagli switch, e viene destaggerato solo dai router sulle subinterface. Gli switch non toccano il tag: lo leggono e basta.

Differenza tra lab01 e lab02

#

Nel lab01 il tag era un dettaglio visibile in Simulation Mode. Nel lab02 il tag e' il meccanismo che permette allo switch di smistare il traffico correttamente.

Cosa ho imparato

#

Una VLAN e' separazione L2, non L3. I router non centrano niente nella definizione di VLAN: e' lo switch che isola i domini broadcast. Il router entra in gioco solo quando vuoi far comunicare due VLAN diverse tra loro.

Il trunk e' un contratto tra due dispositivi. Se un lato e' trunk e l'altro e' access, i frame taggati arrivano su una porta che non se li aspetta: vengono droppati silenziosamente, senza errori chiari.

Lo switch legge il tag ma non lo rimuove sul trunk. Il tag viene rimosso solo su porte access. Su un trunk il frame viaggia sempre taggato da un capo all'altro.

Lo STP protegge ma rallenta. Le 30-50 secondi di convergenza all'avvio non sono un bug: sono il protocollo che verifica l'assenza di loop prima di iniziare a forwardare. PortFast bypassa questa attesa sulle porte che non possono creare loop.

I router nel lab non cambiano. Le subinterface dot1Q configurate nel lab01 funzionano esattamente uguali con gli switch in mezzo. L'unica differenza e' che adesso il tag ha uno switch che lo interpreta attivamente invece di passare direttamente da router a router.

Il prossimo passo: stessa topologia, stesse VLAN, ma costruita con Linux network namespaces: ip link add link eth0 name eth0.10 type vlan id 10, bridge, ip netns.