4.2.6 Step 6: l’IVLR col “router-on-a-stick”

L’IOS degli apparati Cisco permette di utilizzare un’unica interfaccia LAN, almeno di tipo FastEtherenet (da 100Mbps in su) per fare routing per un numero anche elevato di subnet.
Sullo Switch, la configurazione la conosciamo già: è il trunk, che convoglia tutto il traffico su un’unica interfaccia, ripetiamolo, mantenendolo distinto grazie al Q-TAG.
E sul Router? La soluzione sono le subinterfaces (o subif, per gli amici) che permettono di definire varie subinterfacce logiche, ciascuna col suo IP, su un’unica interfaccia fisica. Vediamole.

  • Cominciamo eliminando il secondo link Switch-Router aggiunto all’inizio dello step 2, e tornando quindi alla topologia iniziale (ed ecco ricomparire – non l’avevamo notato prima – un Router su uno stecchino, ossia con una gamba sola, e non tante quante sono le subnet):


  • Trasformiamo la porta Gi0/1 dello Switch S1, da mode access (implicito) a mode trunk (come si vede, una volta in mode trunk, gli attributi di tale modo, visibili dall’help di: switchport trunk ? permettono solo di modificare le VLAN permesse sul trunk, e la nativa del trunk stesso, ma non ci interessa fare nessuna delle due cose:


E l’attributo VLAN 11 che avevamo dato al modo access, va anch’esso eliminato? Non serve farlo, perché gli attributi agiscono su una switchport solo quando essa è nel modo Se la porta è in access, usa degli attributi dell’access; se è in trunk, come in questo caso, indossa quelli del trunk (per noi, i 2 default: “permesse tutte le VLAN” e “nativa=1”). Qui, gli attributi dell’access restano solo delle... predisposizoni.

  • Togliamo dalle interfacce fisiche Gi0/0 e Gi1/0 gli indirizzi IP delle subnet, per non fare conflitto con gli stessi indirizzi, che dovremo riassegnare alle subif, e spegniamo la Gi1/0:


  • Creiamo sul Router DG due subif logiche, Gi0/0.11 e Gi0/0.12, e configuriamole:


Si noti che, apposta, abbiamo sbagliato l’ordine dei due comandi di configurazione della subif, dando prima l’indirizzo e poi l’encapsulation: ma il Router li vuole al contrario, e ce lo dice chiaro. Non rifaremo quindi lo stesso errore sulla subif Gi0/0.12:


Qui invece abbiamo usato il comando encapsulation in forma molto abbreviata.

Avremo notato che i comandi encapsulation recano, in fondo, il numero della VLAN associata alla subif, e quindi alla subnet. A qual fine? È importante, per il Router, sapere quali VLAN corrispondono alle subnet (i numeri 11 e 12 uguali nella VLAN e nell’IP sono solo un trucco mnemonico per l’operatore: al Router ciò va detto in modo esplicito, con i comandi indicati), per i seguenti motivi:

  • Primo, il Router verifica che il traffico in arrivo sulla subif corrisponda alla VLAN indicata, e in caso contrario scarta i pacchetti, perché frutto del presunto lavoro di qualche hacker (perché mai un pacchetto inviato al Default Gateway 10.0.11.254 dovrebbe arrivare con un VLAN-ID diverso da 11, ad esempio???)
  • Secondo, il Router deve reincapsulare i pacchetti in nuove trame, dopo aver ad esempio instradato un pacchetto della subnet 10.0.12.0 sulla 10.0.11.0, e non deve creare semplici trame Ethernet, ma trame DOT1Q che devono contenere il VLAN-ID della VLAN associata alla subnet del destinatario. Con il paragone usato più sopra, si dice che il Router “ricolora” le trame, e deve sapere il nuovo colore da usare in uscita.

Il risultato della configurazione delle subif si vede subito col comando:


che mostra le subif già accese (lo sono per default), mentre l’interfaccia fisica dev’essere accesa manualmente (ma lo era già da prima). La fisica è un po’ come l’interruttore generale della casa, mentre le subif solo le singole stanze: hanno un’interruttore, ma sono accese per default.

Prima di fare un ping finale di verifica, diamo un’occhiata alla tabella di routing di DG:

Adesso possiamo verificare che funziona tutto di nuovo, e che abbiamo fatto la cosa migliore che si può fare, usando Switch L2 e Router, per la gestione delle VLAN:


Esempio di un paio di ping significativi, dal PC0 degli studenti:


Il primo ping della serie fallisce (ma poi, se ripetuto, andrebbero tutti e 4) perché il Router non ha ancora nella sua ARP cache il MAC dell’host target e, mentre fa la ARP request, scarta il messaggio (Echo request) in coda. Questo è conforme a quanto indicato nella RFC 826 del 1993, sul protocollo ARP: mentre si fa una ARP request, si può “throw away” il pacchetto, assumendo che tanto sarà ritrasmesso da qualche “higher network layer”... mah!? I PC non fanno così, e tengono da parte il pacchetto, mentre attendono l’esito dell’ARP!

Ultime modifiche: mercoledì, 14 aprile 2021, 18:36