(Classe 5a) - Sistemi e Reti

Il link tra i due Switch, dovendo trasportare trame delle VLAN 11 e 12 (ignorando per il momento la 1), deve funzionare come trunk, capace di trasportare trame di varie VLAN (per default, tutte) mantenendole distinte, e non come link di accesso, associato a una VLAN sola.
Che cosa significa, per gli Switch e per i messaggi in transito, che una porta funziona come trunk e non come porta di accesso? Vediamo prima il problema dal punto di vista degli Switch.
Lo Switch determina il ruolo access/trunk delle porte “switched” (funzionanti cioè a livello 2) in due possibili modi:

• Mediante negoziazione col partner, tramite il protocollo DTP-Dynamic Trunking Protocol
• Mediante configurazione manuale.

Il primo modo, attivo per default sugli apparati Cisco, prevede che ogni Switch emetta ciclicamente sulle sue porte attive dei messaggi DTP, e ascolti le analoghe proposte di un eventuale partner.
Se all’altro capo del filo non c’è uno Switch, ma un qualunque host (che presumibilmente non parla DTP – Attenzione! Se invece lo fa, può tentare un possibile attacco alla rete... su cui sorvoliamo) lo Switch, non ricevendo messaggi DTP, conclude che la porta deve restare di accesso.
Questo, a ben vedere, è quanto abbiamo tacitamente supposto fin qui, per le porte dei Client e dei Server, a cui non abbiamo dato il comando: switchport mode access che le forzasse in access. Anzi, abbiamo giustamente ipotizzato che le porte sarebbero andate da sole in “access mode”, e ci siamo limitati a dire la VLAN associata a tale porta. Il comando: switchport access vlan N, infatti, assegna un attributo (la VLAN, appunto) delle porte di accesso, ma non ne forza il modo.
Se lo Switch è collegato a un Router, il caso è analogo a quello degli host: i Router “non parlano DTP”, e quindi le porte degli Switch restano di accesso.
Se invece all’altro capo del filo c’è uno Switch, le due porte in dialogo andranno in trunk, no?
Ahimè, non è detto, perché ci sono ancora due o tre casi:

• Se uno dei due partner propone o impone il modo trunk, e l’altro ci sta, si va in trunk
• Se nessuno propone, oppure uno propone o impone, ma l’altro non ci sta, si può restare in modo access, o finire addirittura in modi opposti, compromettendo la comunicazione.

Esiste una tabella di tutte le possibilità, un po’ troppo complessa da spiegare qui compiutamente, perché chiede di introdurre i modi dynamic desirable, dynamic auto, nonegotiate, ecc... :(
In pratica, come facciamo a capire in se la porta è finita in access o in trunk, ed eventualmente a configurarla in trunk? Semplice: basta guardare ancora l’output dello show vlan brief, che mostra la porta Fa0/24 nell’elenco delle porte associate alla sola VLAN 1, quindi ancora in accesso.

Se la porta fosse in trunk, non sarebbe in elenco, perché la lista delle porte di trunk si vede solo con un altro comando, che presentiamo qui sotto.
Possiamo forzare la porta Fa0/24 in trunk, imponendolo anche a S1 (se ci sta), o almeno dire a S2 di proporglielo? Sì, coi due comandi di interfaccia: switchport mode trunk o: switchport mode dynamic desirable. Per maggiore sicurezza scegliamo il primo, e vediamone gli effetti:

Abbiamo forzato la porta Fa0/24 in trunk, perdendola nell’elenco delle porte di accesso associate allo rispettive VLAN, visibili col comando: show vlan brief. In compenso la porta è comparsa, solitaria, tra le porte di trunk, visibili quasi solo col comando: show interfaces trunk (si noti che, in figura, interface è una legittima abbreviazione di interfaces...!).
Nell’output di questo comando, è interessante notare che il Modo “trunk” della porta è “on”, che vuol dire forzato (dal comando dato) e non negoziato col partner. Della Encapsulation “1q” ne parliamo tra poco; lo Status è “trunking”, come è ovvio, e la VLAN nativa è la 1. Su quest’ultimo elemento ci rifiutiamo pervicacemente di dare spiegazioni, dato che la natura e lo scopo della “native VLAN” sui trunk è uno degli argomenti più ostici, ma anche abbastanza esoterici, dei corsi di reti.
Le VLAN “allowed” (permesse) sul trunk sono quelle dalla 1 alla 1005, cioè tutte, mentre quelle “allowed and active” sono quelle veramente esistenti: 1, 11 e 12.
Prima di passare a spiegare come sono fatte le trame che circolano sui link di trunk, con quella strana Encapsulation 802.1q, vediamo l’output del comando: show interfaces trunk su S1, che invece è passato in trunk non per configurazione (si poteva anche dargliela, ma insomma...) ma per aver ricevuto i messaggi DTP da S2 che glielo imponevano:

Come si vede, l’output è del tutto analogo a quello di S2, con la sola differenza che l’Encapsulation non è diventata una 802.1q “secca”, ma una “n-802.1q”, che è una 1q negoziata. Chiaro, no?
Se non lo fosse abbastanza, aggiungiamo l’output del comando seguente:

che mostra la porta fa0/24 di S1 dal punto di vista “switchport”. Come si vede, il suo modo di access/trunk è “dynamic auto”, e la negoziazione (del DTP) è “On”: ciò significa che lo Switch S1 parla DTP con S2, ed è disposto ad andare in trunk, ma solo se l’altro lo propone (con mode dynamic desirable) o lo impone (con mode trunk forzato). In classe spesso chiamiamo questo, il modo “timido”, che non si fa avanti per primo, del DTP!

Interessante il termine inglese desirable, che perde una sillaba rispetto al corrispondente italiano desiderabile. Succede! Un altro esempio abbastanza noto è: lubricant oil = olio lubrificante...