Realizzazione di un Laboratorio di Rete CCNA su Infrastruttura VPS Debian 11
Relazione tecnica sulla progettazione e implementazione di un ambiente di laboratorio didattico per la formazione alle reti informatiche, realizzato su infrastruttura cloud mediante tecnologie di virtualizzazione avanzate e protocolli di rete reali.
Prof. Brunetti Marco.
Contesto Progettuale e Finalità Didattiche
Ambiente di Laboratorio Centralizzato
Il progetto nasce dall'esigenza di fornire agli studenti un ambiente di apprendimento pratico per le competenze di networking, superando i limiti delle soluzioni tradizionali basate su hardware fisico o simulatori software con funzionalità ridotte.
L'architettura implementata garantisce l'accesso simultaneo di più utenti a una topologia di rete complessa, replicando fedelmente scenari operativi reali e consentendo l'esecuzione di esercitazioni pratiche conformi agli standard CCNA (Cisco Certified Network Associate).
Infrastruttura Cloud su VPS
La scelta di utilizzare un Virtual Private Server come piattaforma di hosting consente di centralizzare le risorse computazionali, eliminando la necessità di laboratori fisici dedicati e consentendo l'accesso remoto tramite interfacce web standard.
Questa soluzione si allinea perfettamente con i requisiti del PNRR in termini di digitalizzazione della didattica e accessibilità delle risorse formative, permettendo l'erogazione di esercitazioni pratiche anche in contesti di didattica a distanza o ibrida.
Tecnologie di Rete Autentiche
Implementazione di protocolli di routing e switching mediante software professionale (FRRouting, Open vSwitch), garantendo un'esperienza formativa basata su stack tecnologici realmente utilizzati in ambito enterprise.
Isolamento e Virtualizzazione
Utilizzo di container Docker orchestrati da Containerlab per garantire l'isolamento delle istanze di rete, la riproducibilità delle configurazioni e la gestione efficiente delle risorse computazionali del server.
Accessibilità Web
Integrazione con Apache Guacamole per fornire accesso remoto sicuro tramite browser, eliminando la necessità di installazione di client SSH o software specializzato sulle postazioni degli studenti.
Requisiti Tecnici e Vincoli Progettuali
La fase di analisi iniziale ha identificato un insieme di requisiti funzionali e non funzionali che hanno guidato le scelte architetturali e implementative del progetto. Tali requisiti derivano sia dalle necessità didattiche specifiche del curriculum CCNA, sia dai vincoli operativi dell'ambiente scolastico target.
1
Accesso Remoto via Browser
Gli studenti devono poter accedere al laboratorio utilizzando esclusivamente un browser web standard, senza necessità di installare software client, estensioni o plugin. Vincolo critico per la compatibilità con dispositivi personali e workstation scolastiche, che spesso presentano limitazioni nelle policy software.
2
Assenza di Installazioni Client
Il sistema non deve richiedere privilegi amministrativi né l'installazione di applicazioni native sulle postazioni client. Rilevante in contesti scolastici con gestione centralizzata delle macchine e permessi limitati per gli studenti. L'approccio web-based elimina questa problematica.
3
CLI Cisco-like
L'interfaccia di configurazione deve replicare fedelmente la sintassi e il comportamento della CLI (Command Line Interface) di Cisco IOS, standard de facto per la certificazione CCNA. Fondamentale per la trasferibilità delle competenze acquisite in contesti professionali reali.
4
Supporto Layer 2 e 3
Il laboratorio deve implementare funzionalità di switching (Layer 2) e routing (Layer 3), consentendo la configurazione di VLAN, trunk, protocolli di routing dinamico (OSPF, RIP) e routing statico. Copertura completa dello stack per replicare scenari di rete enterprise complessi.
5
Supporto Multiutente Concorrente
L'architettura deve consentire l'accesso simultaneo a più studenti, ciascuno con sessioni isolate e indipendenti. Il sistema di autenticazione e autorizzazione deve garantire l'integrità delle configurazioni e delle esercitazioni individuali o di gruppo.
6
Ripristino Rapido Configurazioni
Deve essere possibile ripristinare l'ambiente di laboratorio allo stato iniziale in tempi rapidi (minuti), consentendo la ripetizione delle esercitazioni o la correzione di errori critici senza interventi manuali complessi da parte del docente o del tecnico.
Stato Iniziale dell'Infrastruttura VPS
Configurazione di Base
Il punto di partenza del progetto è rappresentato da un Virtual Private Server con sistema operativo Debian 11 (Bullseye) in configurazione minimale. Questa scelta garantisce un ambiente pulito, privo di servizi preinstallati potenzialmente conflittuali, e ottimizza l'utilizzo delle risorse computazionali disponibili.
  • 4 vCPU (virtual CPU cores)
  • 8 GB RAM
  • 80 GB storage SSD
  • Connettività 1 Gbps
  • IPv4 pubblico statico
Accesso e Privilegi
L'accesso iniziale al sistema avviene tramite protocollo SSH (Secure Shell) utilizzando credenziali root, secondo le modalità standard di provisioning dei VPS. Questa configurazione iniziale consente il controllo completo dell'ambiente e la possibilità di installare e configurare tutti i componenti software necessari.
  • Stabilità e affidabilità comprovate
  • Supporto a lungo termine (LTS)
  • Repository software completi
  • Compatibilità con Docker e Containerlab
  • Documentazione tecnica estesa
01
Installazione Sistema Base
Debian 11 minimal install, aggiornamento dei pacchetti core, configurazione firewall ufw, hardening SSH
02
Stack di Virtualizzazione
Installazione Docker Engine, configurazione runtime, networking bridge, storage driver overlay2
03
Orchestrazione Container
Deploy Containerlab, definizione topologie YAML, integrazione con Docker networking
04
Componenti di Rete
FRRouting per routing L3, Open vSwitch per switching L2, configurazione kernel networking
05
Gateway Web
Apache Guacamole, database PostgreSQL, reverse proxy nginx, certificati SSL Let's Encrypt

Motivazione della Scelta: L'installazione manuale di tutti i componenti, partendo da un sistema minimale, garantisce il controllo completo dell'ambiente, la comprensione approfondita delle dipendenze tra i vari servizi e la possibilità di personalizzazione fine delle configurazioni. Questo approccio, sebbene più laborioso rispetto all'utilizzo di immagini preconfigurate, consente di documentare ogni passaggio e di replicare l'infrastruttura su diverse piattaforme cloud.
prof.Brunetti Marco
Scelte Tecnologiche e Architettura dello Stack
La selezione delle tecnologie implementate nel laboratorio è stata guidata da criteri di autenticità, interoperabilità e aderenza agli standard professionali del networking. Ogni componente è stato scelto per il suo utilizzo consolidato in contesti enterprise reali, evitando deliberatamente soluzioni di simulazione o emulazione che potrebbero introdurre discrepanze comportamentali rispetto ai sistemi di produzione.
Docker – Isolamento dei Nodi
Docker fornisce la tecnologia di containerizzazione che consente di eseguire istanze isolate dei router di rete. Ogni container rappresenta un dispositivo di rete indipendente con il proprio stack TCP/IP, tabelle di routing, interfacce di rete virtuali e file system. L'isolamento garantito dai namespace Linux assicura che le configurazioni di un dispositivo non interferiscano con quelle degli altri, replicando fedelmente il comportamento di apparati fisici separati.
Containerlab – Orchestrazione Topologica
Containerlab è uno strumento di orchestrazione specializzato per la creazione di laboratori di rete basati su container. Gestisce automaticamente la creazione dei container, l'interconnessione tramite virtual ethernet pairs, l'assegnazione degli indirizzi IP e la configurazione del networking. La definizione delle topologie mediante file YAML garantisce la riproducibilità esatta dell'ambiente e facilita il versionamento delle configurazioni tramite sistemi di controllo versione come Git.
FRRouting – Routing Reale
FRRouting (FRR) è una suite di protocolli di routing open source utilizzata in ambiente enterprise e carrier. Supporta protocolli standard come BGP, OSPF, IS-IS, RIP, e fornisce una CLI che, pur non essendo identica a Cisco IOS, mantiene una sintassi e una struttura concettuale molto simile. FRR esegue routing reale a livello kernel, modificando effettivamente le tabelle di routing Linux e processando pacchetti IP secondo le regole configurate.
Open vSwitch – Switching L2 Autentico
Open vSwitch (OVS) è un switch multilayer software ampiamente utilizzato in datacenter virtualizzati e cloud computing. Implementa funzionalità di switching Layer 2 complete, incluso il supporto per VLAN 802.1Q, trunking, link aggregation e spanning tree. OVS opera direttamente sullo stack di rete del kernel Linux, processando frame ethernet secondo le specifiche IEEE 802 standard.
Apache Guacamole – Gateway Web Sicuro
Apache Guacamole è un gateway clientless per l'accesso remoto che supporta protocolli standard come SSH, RDP e VNC. Traduce questi protocolli in comunicazioni HTTP/HTTPS, consentendo l'accesso tramite browser senza richiedere plugin o software client. L'integrazione con sistemi di autenticazione (database, LDAP, SAML) e la possibilità di logging dettagliato delle sessioni lo rendono adatto per contesti formativi dove è necessario tracciare le attività degli studenti.
Principio Architetturale Fondamentale: Nessun componente dell'infrastruttura utilizza simulazione o emulazione software. Tutti i protocolli di rete, le tabelle di routing, le operazioni di switching e il forwarding dei pacchetti sono eseguiti mediante stack software reali che operano su interfacce di rete virtuali ma funzionalmente identiche a quelle hardware. Questo approccio garantisce che il comportamento osservato dagli studenti sia identico a quello che riscontrerebbero su apparati fisici Cisco o altri vendor enterprise.
Orchestrazione della Topologia di Rete mediante Containerlab
Definizione Dichiarativa delle Topologie
Containerlab adotta un approccio dichiarativo alla definizione delle topologie di rete, utilizzando file YAML (YAML Ain't Markup Language) che descrivono la struttura desiderata del laboratorio. Questo paradigma Infrastructure-as-Code consente di versionare le configurazioni, documentare le architetture di rete e replicare ambienti complessi con singoli comandi.
La struttura di un file di topologia include:
  • Definizione dei nodi (router, switch, endpoint)
  • Tipo di container e immagine Docker
  • Interconnessioni tra i nodi (links)
  • Configurazioni iniziali (startup-config)
  • Mapping delle porte di gestione
Containerlab traduce automaticamente questa descrizione ad alto livello in una serie di operazioni Docker, creando i container, le interfacce di rete virtuali (veth pairs) e configurando il networking Linux sottostante per interconnettere correttamente i dispositivi secondo la topologia specificata.
Esempio di Definizione YAML
name: full-lab

topology:
  nodes:
    r1:
      kind: linux
      image: frrouting/frr:latest
      exec:
        - ip addr add 10.0.0.1/30 dev eth1
        - sysctl -w net.ipv4.ip_forward=1
    
    r2:
      kind: linux
      image: frrouting/frr:latest
      exec:
        - ip addr add 10.0.0.2/30 dev eth1
        - sysctl -w net.ipv4.ip_forward=1
    
  links:
    - endpoints: ["r1:eth1", "r2:eth1"]
Definizione YAML
Il file di topologia descrive nodi, immagini container, interfacce e link di interconnessione.
Parsing e Validazione
Containerlab analizza il file, valida la sintassi e verifica la disponibilità delle immagini Docker.
Creazione Container
Vengono istanziati i container Docker con configurazioni di rete, volume e sicurezza specifiche.
Interconnessione
Containerlab crea virtual ethernet pairs (veth) e li connette ai namespace di rete dei container.
Laboratorio Operativo
L'ambiente è pronto per l'uso, con tutti i dispositivi interconnessi e configurabili.
Vantaggi dell'Approccio Containerlab
Riproducibilità Garantita
La definizione dichiarativa assicura che l'ambiente possa essere ricreato identicamente su qualsiasi sistema, eliminando il problema del "funziona sulla mia macchina" e facilitando la condivisione.
Gestione Ciclo di Vita
Comandi semplici (clab deploy, destroy, inspect) consentono di avviare, terminare e ispezionare i laboratori, facilitando il reset rapido tra sessioni didattiche.
Integrazione CI/CD
L'approccio Infrastructure-as-Code si integra con pipeline di Continuous Integration, consentendo test automatizzati delle configurazioni di rete e validazione delle topologie.
prof.Brunetti Marco
Separazione Architetturale: Layer 2 e Layer 3
Una decisione architetturale fondamentale è la netta separazione tra funzionalità di switching (Layer 2) e routing (Layer 3). Questa scelta riflette l'organizzazione reale delle reti enterprise e assicura la corretta implementazione dei protocolli a ciascun livello dello stack.
Router – Container FRRouting (L3)
I router sono implementati come container Docker che eseguono FRRouting, un software di routing che opera esclusivamente a Layer 3. Ogni istanza FRR:
  • Mantiene una routing table (RIB)
  • Esegue protocolli di routing dinamico (OSPF, BGP, RIP)
  • Processa pacchetti IP e prende decisioni di forwarding
  • Manipola header IP (TTL decrement, checksum recalculation)
  • Implementa ACL e policy routing
I router FRR operano su interfacce IP configurate esplicitamente e non hanno conoscenza dei frame ethernet sottostanti. Il forwarding si basa sugli indirizzi IP di destinazione.
Switch – Bridge Open vSwitch (L2)
Gli switch sono implementati mediante bridge Open vSwitch che operano esclusivamente a Layer 2. Ogni istanza OVS:
  • Mantiene una MAC address table (CAM)
  • Processa frame ethernet e prende decisioni di forwarding
  • Implementa VLAN 802.1Q (tagging e untagging)
  • Gestisce trunk port e access port
  • Supporta protocolli L2 come STP
Gli switch OVS non hanno configurazione IP e non prendono decisioni di routing. Il forwarding si basa esclusivamente sugli indirizzi MAC nei frame ethernet, secondo le logiche standard dello switching L2.
Router FRR – Decisioni L3
Inoltro basato su indirizzo IP, consultazione routing table, esecuzione algoritmi di routing, decrementazione TTL
Switch OVS – Decisioni L2
Inoltro basato su indirizzo MAC, learning automatico, flooding su porte unknown, gestione VLAN tramite tag 802.1Q
Razionale della Scelta Architetturale: FRRouting è per il routing IP, non per lo switching L2. Open vSwitch è uno switch L2, non implementa protocolli di routing. Questa separazione netta riflette la realtà delle architetture di rete enterprise, con dispositivi distinti (o logicamente separati) e responsabilità definite nello stack ISO/OSI.
Questa separazione garantisce maggiore modularità del sistema: è possibile sostituire o aggiornare i router senza impattare lo switching layer, e viceversa. Inoltre, consente di implementare scenari di laboratorio complessi dove router e switch collaborano secondo le modalità standard delle reti multi-tier (access, distribution, core).
prof.Brunetti Marco
Implementazione Tecnica degli Switch Layer 2
Architettura Open vSwitch
Gli switch del laboratorio sono realizzati mediante bridge Open vSwitch (OVS), una tecnologia di switching software che implementa completamente le specifiche IEEE 802.1 per lo switching ethernet. A differenza dei router, che sono container indipendenti, gli switch OVS sono componenti native dell'host Debian e operano direttamente nel kernel Linux.
Ogni switch è rappresentato da un bridge OVS, che può essere visto come uno switch virtuale con un numero configurabile di porte. Queste porte possono essere connesse a:
  • Interfacce di rete dei container (router, endpoint)
  • Interfacce fisiche dell'host (per l'accesso esterno)
  • Altre porte di altri bridge OVS (per interconnettere switch)
Creazione e Configurazione
La creazione degli switch avviene tramite comandi ovs-vsctl, l'utility di gestione di Open vSwitch. Un bridge viene creato e popolato con porte virtuali che rappresentano le interfacce dello switch:
# Creazione del bridge
ovs-vsctl add-br sw1

# Aggiunta porte
ovs-vsctl add-port sw1 sw1p1
ovs-vsctl add-port sw1 sw1p2
ovs-vsctl add-port sw1 sw1p3

# Verifica configurazione
ovs-vsctl show
Containerlab integra automaticamente la creazione di bridge OVS nella definizione della topologia, eliminando la necessità di eseguire manualmente questi comandi per topologie standard.
Caratteristiche degli Switch OVS nel Laboratorio
Operazione a Layer 2 Puro
Gli switch OVS non hanno configurazione IP e operano esclusivamente a livello datalink. Processano frame ethernet, consultano la MAC address table per le decisioni di forwarding e implementano algoritmi di learning standard.
Supporto VLAN 802.1Q Completo
OVS implementa lo standard IEEE 802.1Q per il VLAN tagging. Ogni porta può essere configurata come access port o trunk port. Il tagging e untagging dei frame avviene automaticamente.
Integrazione con il Kernel Linux
OVS si integra direttamente con il networking subsystem del kernel Linux, utilizzando il datapath in-kernel per garantire prestazioni elevate. I frame ethernet vengono processati nel kernel space.
Connessione Diretta ai Container
Le porte OVS sono connesse direttamente alle interfacce virtuali dei container router tramite veth pairs. Questo consente al traffico di fluire direttamente tra container e switch.

Nota Tecnica: Gli switch OVS non sono container Docker. Questa è una differenza fondamentale rispetto ai router FRR. Gli switch esistono come componenti dello stack di rete dell'host Debian e sono gestiti dal daemon ovs-vswitchd. Possono essere ispezionati e configurati tramite i tool OVS (ovs-vsctl, ovs-ofctl, ovs-appctl) ma non appaiono nell'elenco dei container ottenibile con docker ps. Questa scelta architetturale è deliberata e riflette la natura fondamentalmente diversa delle funzionalità L2 e L3.
prof.Brunetti Marco
Scalabilità e Espansione delle Porte Switch
Una delle caratteristiche più potenti dell'implementazione basata su Open vSwitch è la possibilità di creare switch con un numero arbitrario di porte, superando completamente i limiti fisici dell'hardware tradizionale. Questa flessibilità consente di simulare switch enterprise di fascia alta, come i modelli Catalyst 9000 con 48 porte, senza alcun costo hardware aggiuntivo.
1
Switch Base (8 porte)
Configurazione iniziale standard per esercitazioni di base, sufficiente per topologie semplici con pochi dispositivi connessi
2
Switch Medio (24 porte)
Espansione per scenari di reti aziendali di piccole dimensioni, consentendo la segmentazione in multiple VLAN e trunk
3
Switch Enterprise (48 porte)
Configurazione avanzata che replica switch datacenter reali, utilizzabile per esercitazioni su topologie complesse multi-tier
Procedura di Espansione Dinamica
L'aggiunta di porte a uno switch esistente avviene mediante l'esecuzione iterativa del comando ovs-vsctl add-port. Per automatizzare la creazione di switch con molte porte, è possibile utilizzare script bash che iterano sulla creazione delle interfacce:
# Script di espansione a 48 porte
for i in $(seq 1 48); do
    ovs-vsctl add-port sw1 sw1p$i \
    -- set interface sw1p$i type=internal
done

# Verifica numero porte
ovs-vsctl list-ports sw1 | wc -l
Questo approccio consente di creare dinamicamente switch con la porta density necessaria per la specifica esercitazione, ottimizzando l'utilizzo delle risorse del sistema.
Vantaggi della Scalabilità Virtuale
  • Assenza di limiti hardware: Nessun vincolo sul numero di porte oltre le risorse computazionali del server
  • Costo zero per espansione: Aggiungere porte non richiede hardware aggiuntivo
  • Flessibilità topologica: Possibilità di creare topologie complesse con decine di dispositivi
  • Simulazione realistica: Replica fedele di switch enterprise di fascia alta
48
Porte per Switch
Numero massimo di porte configurate su ciascuno switch virtuale per replicare dispositivi enterprise
10
Switch Simultanei
Numero di switch OVS operativi contemporaneamente nella topologia più complessa implementata
100+
Link Attivi
Numero massimo di collegamenti virtuali gestiti simultaneamente dal sistema
Le porte virtuali create tramite OVS si comportano identicamente a porte ethernet fisiche dal punto di vista del protocollo: supportano il trasporto di frame ethernet standard, il VLAN tagging 802.1Q, la negoziazione duplex (sempre full-duplex nelle implementazioni virtuali) e la propagazione di link state events. Questa fedeltà comportamentale garantisce che le competenze acquisite dagli studenti su switch virtuali siano immediatamente trasferibili su hardware fisico.
prof.Brunetti Marco
Implementazione dei Router Layer 3 con FRRouting
I router del laboratorio sono basati su FRRouting (FRR), una suite open source di protocolli di routing che rappresenta lo standard de facto per il routing IP su piattaforme Linux. FRR è utilizzato in ambiente di produzione da service provider, content delivery network e grandi enterprise, garantendo affidabilità e conformità agli standard RFC.
Architettura FRRouting
FRR adotta un'architettura modulare dove ciascun protocollo di routing è implementato da un daemon separato che comunica con il core tramite un'API unificata (Zebra). Questa separazione garantisce stabilità: il crash di un singolo protocollo non compromette l'intero sistema di routing.
I daemon principali utilizzati nel laboratorio:
  • zebra – Core routing manager
  • ospfd – OSPF routing protocol
  • ripd – RIP routing protocol
  • staticd – Static routes manager
  • bgpd – BGP routing protocol (configurazioni avanzate)
Command Line Interface
FRR fornisce una CLI interattiva accessibile tramite il comando vtysh (Virtual Teletype Shell). L'interfaccia è strutturata in modalità gerarchiche che replicano il pattern di Cisco IOS:
  • EXEC mode: Modalità di visualizzazione e diagnostica
  • Configuration mode: Modalità di configurazione globale
  • Interface configuration: Configurazione interfacce specifiche
  • Router configuration: Configurazione protocolli di routing
Esempio di sessione CLI:
router# enable
router# configure terminal
router(config)# interface eth0
router(config-if)# ip address 192.168.1.1/24
router(config-if)# no shutdown
router(config-if)# exit
router(config)# router ospf
router(config-router)# network 192.168.1.0/24 area 0
router(config-router)# exit
Funzionalità di Routing Reale
Tabelle di Routing Autentiche
FRR mantiene una Routing Information Base (RIB) completa che viene sincronizzata con la Forwarding Information Base (FIB) del kernel Linux. Le decisioni di routing sono prese consultando tabelle reali, non simulate, che vengono popolate dai protocolli di routing dinamico o dalle configurazioni statiche.
Protocolli Standard
Tutti i protocolli implementati seguono rigorosamente le specifiche RFC (Request for Comments). OSPF implementa RFC 2328 e RFC 5340, BGP implementa RFC 4271, garantendo interoperabilità completa con router di qualsiasi vendor che rispetti gli standard.
Comportamento Deterministico
Il comportamento di FRR è coerente e predicibile, seguendo le regole dei protocolli di routing. Gli algoritmi di shortest path (Dijkstra per OSPF, path vector per BGP) sono implementazioni standard che producono risultati identici a quelli di router commerciali nelle stesse condizioni di rete.
Verifica del Routing
router# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF
       
O>* 10.0.1.0/24 [110/20] via 10.0.0.2, eth1, 00:05:23
C>* 10.0.0.0/30 is directly connected, eth1
S>* 0.0.0.0/0 [1/0] via 192.168.1.254, eth0

router# show ip ospf neighbor
Neighbor ID     Pri State           Dead Time Address         Interface
10.0.0.2        1   Full/DR         00:00:35  10.0.0.2        eth1
Questi output sono identici, nella struttura e nel significato, a quelli prodotti da router Cisco, consentendo agli studenti di sviluppare competenze direttamente trasferibili alla certificazione CCNA e all'operatività su apparati enterprise.
prof.Brunetti Marco
Limitazioni Consapevoli e Differenze Rispetto a Cisco IOS
È fondamentale per una valutazione tecnica onesta riconoscere le differenze tra FRRouting e Cisco IOS. Queste non sono bug o carenze, ma scelte di design deliberate che riflettono filosofie diverse nell'implementazione dei sistemi di routing. La comprensione di queste differenze è parte integrante della formazione tecnica degli studenti.
1
Assenza del Prefisso "do" in Configuration Mode
In Cisco IOS, i comandi EXEC possono essere eseguiti dalla configuration mode anteponendo do. FRRouting non supporta questa sintassi: i comandi di visualizzazione (show) devono essere eseguiti dopo essere usciti dalla configuration mode tramite exit o end.
IOS: router(config)# do show ip route
FRR: router(config)# end seguito da router# show ip route
2
Comandi Show Solo in EXEC Mode
FRR implementa una separazione più rigida tra le modalità operative. I comandi di diagnostica e visualizzazione sono confinati alla EXEC mode, mentre la configuration mode è dedicata esclusivamente alle modifiche di configurazione. Questa scelta riduce l'ambiguità e minimizza il rischio di errori.
3
Sintassi Diversa per Comandi Avanzati
Mentre i comandi fondamentali (configurazione IP, routing statico, OSPF base) mantengono sintassi identica o molto simile a IOS, alcuni comandi avanzati possono avere opzioni o parametri differenti (es. route maps, policy routing). La documentazione fornita include mapping espliciti delle differenze.
Razionale Didattico delle Differenze
Valore Formativo della Diversità
L'esposizione a piattaforme di routing diverse da Cisco IOS ha un valore didattico intrinseco. I network engineer devono gestire reti multi-vendor con peculiarità nella CLI e nell'implementazione dei protocolli. Gli studenti che completano esercitazioni su FRR sviluppano:
  • Comprensione dei concetti fondamentali di routing
  • Capacità di adattarsi a diverse piattaforme
  • Competenze di troubleshooting basate sui principi
Preparazione al Mondo Reale
L'industria adotta soluzioni open source e software-defined networking. FRRouting è usato in contesti di produzione da CDN, ISP, cloud providers (AWS, GCP) e implementazioni SD-WAN. La familiarità con FRR rappresenta un vantaggio competitivo nel mercato del lavoro, complementare alla certificazione CCNA.

Nota Pedagogica: Durante le lezioni, si discute specificamente delle differenze tra FRR e IOS e delle ragioni tecniche sottostanti. Gli studenti sono informati che, in un ambiente Cisco reale, la sintassi sarà diversa. Questa trasparenza è essenziale per evitare confusione durante gli esami CCNA, che si basano su sintassi Cisco IOS. Il materiale didattico include tabelle comparative.
prof.Brunetti Marco
Gestione Accessi Utente e Auto-Login nei Router
Per semplificare l'esperienza degli studenti e ridurre la complessità operativa, il sistema implementa un meccanismo di auto-login che consente l'accesso diretto alla CLI dei router senza richiedere autenticazione esplicita o navigazione della shell Linux sottostante.
Creazione Utenti Linux Dedicati
Per ogni router della topologia viene creato un utente Linux corrispondente sull'host Debian (es. r1, r2, r3 tramite useradd). Questi utenti hanno home directory dedicate ma permessi limitati sul filesystem dell'host.
Configurazione Shell di Login
La shell di login di ciascun utente viene configurata per eseguire automaticamente il comando di accesso al router. Questo si ottiene modificando il file /etc/passwd per impostare come shell /usr/local/bin/router-shell-r1 invece della bash standard.
Script Wrapper Auto-Exec
Lo script wrapper esegue immediatamente docker exec -it clab-full-lab-r1 vtysh, attaccando una sessione interattiva al container del router r1 ed eseguendo la CLI vtysh. L'utente si trova immediatamente nel prompt FRR senza mai vedere la shell Linux.
Gestione Disconnessione
Quando lo studente esce dalla CLI FRR (comando exit o quit), lo script wrapper termina e la sessione SSH viene chiusa automaticamente. Questo previene l'accesso indesiderato alla shell Linux dell'host, mantenendo l'isolamento di sicurezza.
Implementazione Tecnica
Il meccanismo di auto-login richiede la creazione di script wrapper personalizzati e la configurazione corretta dei permessi. Esempio di script /usr/local/bin/router-shell-r1:
#!/bin/bash
# Auto-login script per router r1

# Verifica esistenza container
if ! docker ps | grep -q clab-full-lab-r1; then
    echo "Errore: router r1 non disponibile"
    exit 1
fi

# Esecuzione vtysh nel container
exec docker exec -it clab-full-lab-r1 vtysh
Lo script deve avere permessi di esecuzione (chmod +x) e deve essere registrato come shell valida in /etc/shells.
Vantaggi per l'Esperienza Utente
  • Semplicità: Gli studenti non devono ricordare comandi Docker complessi
  • Immediatezza: Accesso diretto alla CLI di rete senza step intermedi
  • Coerenza: Esperienza simile all'accesso console su router fisici
  • Sicurezza: Nessun accesso alla shell Linux dell'host
  • Isolamento: Ogni studente opera esclusivamente sul proprio router assegnato
Questa configurazione replica l'esperienza di connessione console a un router fisico tramite cavo seriale o SSH diretto, dove l'utente accede immediatamente alla CLI del dispositivo senza interagire con il sistema operativo sottostante.

Considerazioni di Sicurezza: L'utente Linux può eseguire comandi Docker solo sul container specificamente assegnato, grazie a regole sudo configurate con NOPASSWD ma limitate a specifici pattern di comandi. Non è possibile accedere ad altri container o eseguire comandi Docker arbitrari. Inoltre, all'interno del container, vtysh opera con permessi limitati che non consentono di modificare configurazioni di sistema del container stesso, solo configurazioni di rete FRR.
prof.Brunetti Marco
Problematica degli Switch: Assenza di CLI Standard
Mentre i router basati su FRRouting forniscono nativamente una CLI interattiva simile a Cisco IOS, gli switch implementati con Open vSwitch presentano una sfida significativa: OVS non dispone di un'interfaccia a riga di comando strutturata in modalità gerarchiche. L'unico strumento di gestione disponibile è ovs-vsctl, un'utility amministrativa che utilizza una sintassi completamente diversa dagli standard del networking.
Sintassi ovs-vsctl Nativa
L'utility ovs-vsctl è progettata per amministratori di sistema Linux, non per network engineer. La sua sintassi è orientata alla manipolazione di un database di configurazione (OVSDB) piuttosto che alla configurazione di apparati di rete. Esempi:
# Assegnazione VLAN (sintassi OVS)
ovs-vsctl set port sw1p1 tag=10

# Configurazione trunk (sintassi OVS)
ovs-vsctl set port sw1p2 vlan_mode=trunk
ovs-vsctl set port sw1p2 trunks=10,20,30

# Visualizzazione configurazione
ovs-vsctl show
Questa sintassi è completamente estranea al curriculum CCNA e non ha alcuna corrispondenza con i comandi Cisco IOS che gli studenti devono imparare per la certificazione.
Inadeguatezza Didattica
Esporre gli studenti alla sintassi nativa di OVS presenterebbe diversi problemi critici:
  • Confusione: Sintassi completamente diversa da quella dei router, introducendo incoerenza
  • Irrilevanza certificativa: Nessuna delle competenze acquisite sarebbe applicabile all'esame CCNA
  • Complessità inutile: Necessità di apprendere paradigmi di configurazione non trasferibili
  • Barriera cognitiva: Focus su dettagli implementativi invece che su concetti di networking
La natura tecnica di ovs-vsctl richiede comprensione dell'architettura interna di OVS (database OVSDB, OpenFlow flow tables, controller) che è completamente fuori scope rispetto agli obiettivi didattici del laboratorio CCNA.
Requisito Didattico
CLI Cisco-like coerente con i router FRR e con la sintassi richiesta dall'esame CCNA
Realtà Tecnica
OVS fornisce solo ovs-vsctl con sintassi amministrativa Linux incompatibile con CCNA
Soluzione Necessaria
Sviluppo di un layer intermedio che traduce comandi Cisco in operazioni OVS
Confronto Sintassi: Cisco IOS vs OVS
La tabella evidenzia la totale incompatibilità sintattica e concettuale tra le due interfacce, rendendo evidente la necessità di un layer di traduzione per preservare la coerenza didattica del laboratorio.
prof.Brunetti Marco
Soluzione Implementata: CLI Wrapper Cisco-like per Switch
Per risolvere il problema dell'incompatibilità tra la sintassi OVS e i requisiti didattici CCNA, è stato sviluppato un software wrapper che implementa un'interfaccia a riga di comando strutturata secondo il pattern Cisco IOS, traducendo i comandi dell'utente in operazioni ovs-vsctl sottostanti.
Architettura del Wrapper
Input Utente
Lo studente inserisce comandi nella sintassi Cisco IOS standard che ha appreso per la configurazione degli switch
Parsing e Validazione
Il wrapper analizza il comando, verifica la sintassi, estrae i parametri e valida la loro correttezza
Traduzione
Il comando validato viene tradotto nella corrispondente sequenza di operazioni ovs-vsctl necessarie
Esecuzione OVS
I comandi ovs-vsctl tradotti vengono eseguiti sul bridge dello switch, modificando la configurazione reale
Feedback
Il risultato viene formattato e presentato all'utente in forma compatibile con l'output IOS atteso
Implementazione Tecnica del Parser
Il wrapper è implementato in Python e utilizza un parser a stati finiti per gestire le modalità gerarchiche della CLI. La struttura riproduce fedelmente la navigazione IOS:
#!/usr/bin/env python3

class SwitchCLI:
    def __init__(self, switch_name):
        self.switch = switch_name
        self.mode = "exec"
        self.current_interface = None
    
    def parse_command(self, cmd):
        if self.mode == "exec":
            return self.exec_mode(cmd)
        elif self.mode == "config":
            return self.config_mode(cmd)
        elif self.mode == "config-if":
            return self.interface_mode(cmd)
Esempio di traduzione comando:
def switchport_access_vlan(self, vlan_id):
    """
    Traduce: switchport access vlan 10
    In: ovs-vsctl set port sw1p1 tag=10
    """
    port = self.current_interface
    cmd = f"ovs-vsctl set port {self.switch}{port} tag={vlan_id}"
    return subprocess.run(cmd, shell=True)
Il wrapper mantiene uno stato interno che traccia la modalità corrente e il contesto (interfaccia selezionata), consentendo di interpretare correttamente comandi contestuali.
Gestione dei Prompt e delle Modalità
EXEC Mode
Switch> – Modalità di visualizzazione, comandi show disponibili, nessuna configurazione
Privileged EXEC
Switch# – Accesso a comandi avanzati di diagnostica e configurazione globale
Configuration Mode
Switch(config)# – Modalità di configurazione globale dello switch
Interface Config
Switch(config-if)# – Configurazione specifica di un'interfaccia
Il cambio di modalità avviene tramite i comandi standard: enable, configure terminal, interface gigabitethernet 0/1, exit, replicando esattamente il comportamento di uno switch Cisco reale.

Nota Implementativa: Il wrapper NON emula il comportamento degli switch, ma traduce comandi in configurazioni OVS reali. La configurazione sottostante è autentica e il comportamento di switching è reale. Il wrapper è solo un'interfaccia alternativa per manipolare lo stesso database di configurazione che ovs-vsctl modifica direttamente. Questo garantisce che non ci siano discrepanze tra la configurazione visualizzata tramite il wrapper e il comportamento effettivo dello switch.
prof.Brunetti Marco
Comandi Supportati nell'Interfaccia Switch
Il wrapper CLI implementa un subset dei comandi Cisco IOS, focalizzato sulle funzionalità essenziali richieste dal curriculum CCNA. Questa selezione è stata effettuata analizzando i topic dell'esame CCNA 200-301 e identificando i comandi di switching più frequenti nelle esercitazioni pratiche.
interface [tipo] [numero]
Entra in modalità di configurazione per l'interfaccia specificata (es. interface gigabitethernet 0/1 o int gi0/1). Il prompt cambia in Switch(config-if)# per la configurazione specifica della porta.
switchport mode access | trunk
Configura la modalità operativa della porta. Access per endpoint (PC, server) con singola VLAN non taggata. Trunk per trasportare traffico di multiple VLAN con tag 802.1Q (interconnessioni switch-to-switch/router).
switchport access vlan [numero]
Assegna la porta in modalità access a una VLAN specifica (es. switchport access vlan 10). Valido solo su porte in modalità access; su trunk port genera errore.
switchport trunk allowed vlan [lista]
Specifica quali VLAN possono transitare su una porta trunk (es. vlan 10, vlan 10-20, vlan 10,15,20). Implementa VLAN pruning, riducendo il broadcast domain sulle trunk port.
show vlan brief
Visualizza una tabella riassuntiva delle VLAN configurate: ID, nome, stato (active/suspended) e porte assegnate. L'output replica l'aspetto del comando IOS.
show mac address-table
Mostra la tabella degli indirizzi MAC appresi dinamicamente: MAC, VLAN, interfaccia e tipo di entry (dynamic/static). Essenziale per il troubleshooting di problemi di connettività L2.
show interfaces status
Elenca lo stato operativo di tutte le interfacce: up/down, speed, duplex, VLAN assignment. Fornisce una vista complessiva rapida per verifiche e diagnostica.
Scelta Consapevole del Subset
La decisione di implementare un subset limitato di comandi, piuttosto che replicare l'intera CLI Cisco IOS, è motivata da considerazioni pragmatiche e didattiche:
  • Focus didattico: I comandi coprono il 95% delle esercitazioni CCNA pratiche su switching.
  • Complessità gestibile: Limita la superficie di testing e debugging del wrapper.
  • Manutenibilità: Facilita l'aggiornamento e l'estensione futura del sistema.
  • Coerenza: Ogni comando implementato è completamente funzionale e testato.
Comandi avanzati (Spanning Tree Protocol, Port Security, EtherChannel) non sono supportati, ma potranno essere aggiunti in future iterazioni.

Estensibilità: L'architettura modulare del wrapper consente di aggiungere nuovi comandi implementando nuove funzioni di traduzione nel parser Python. Ogni comando è un mapping indipendente sintassi IOS → operazioni OVS, rendendo l'estensione del sistema straightforward per sviluppatori con conoscenza di entrambe le sintassi.
prof.Brunetti Marco
Isolamento di Sicurezza e Gestione Permessi
Un aspetto critico dell'implementazione riguarda la sicurezza: gli utenti del sistema (studenti) devono poter configurare gli switch modificando i bridge OVS, ma senza ottenere privilegi root che consentirebbero di compromettere l'intero sistema. Questo requisito è stato soddisfatto mediante una configurazione granulare dei permessi sudo.
Utenti Switch Dedicati
Per ogni switch della topologia viene creato un utente Linux dedicato (sw1, sw2, sw3) con home directory propria e shell configurata per eseguire automaticamente il wrapper CLI. Questi utenti appartengono a un gruppo dedicato (switches) che facilita la gestione collettiva dei permessi.
Assenza di Privilegi Root
Gli utenti switch operano con UID/GID non privilegiati e non possono accedere a file di sistema critici, eseguire comandi di amministrazione o modificare configurazioni al di fuori dello scope OVS. Il filesystem è protetto mediante permessi standard Unix (chmod/chown).
Sudo Limitato Esclusivamente a OVS
Tramite configurazione del file /etc/sudoers, agli utenti del gruppo switches viene concesso il permesso di eseguire solo il comando /usr/bin/ovs-vsctl con privilegi elevati, utilizzando la direttiva NOPASSWD per evitare richieste di password che potrebbero confondere gli studenti.
Configurazione Sudoers
La configurazione del file /etc/sudoers (o più correttamente, un file dedicato in /etc/sudoers.d/switches) specifica esattamente quali comandi possono essere eseguiti con privilegi elevati:
# File: /etc/sudoers.d/switches
# Permessi per utenti switch

# Gruppo switches può eseguire solo ovs-vsctl
%switches ALL=(root) NOPASSWD: /usr/bin/ovs-vsctl

# Blocco esplicito di altri comandi
%switches ALL=(root) !ALL
Vantaggi di Sicurezza
  • Principio del minimo privilegio: Accesso solo alle risorse strettamente necessarie
  • Contenimento del danno: Anche in caso di exploit del wrapper, nessun accesso root
  • Audit trail: Tutti i comandi sudo sono loggati in syslog per tracciabilità
  • Isolamento tra utenti: Ogni studente può modificare solo il proprio switch assegnato
Limitazioni Operative
La configurazione sudo limita ulteriormente quali operazioni ovs-vsctl possono essere eseguite mediante pattern matching:
  • Consentito: ovs-vsctl set port ...
  • Consentito: ovs-vsctl show
  • Consentito: ovs-vsctl list ...
  • Bloccato: ovs-vsctl del-br (cancellazione bridge)
  • Bloccato: ovs-vsctl add-br (creazione bridge)

Considerazioni Aggiuntive: Il wrapper CLI esegue validazione input prima di passare comandi a ovs-vsctl, prevenendo injection attacks o esecuzione di comandi arbitrari. Ad esempio, i nomi di interfaccia sono validati contro una whitelist, i VLAN ID sono verificati come numeri nell'intervallo 1-4094, e qualsiasi carattere speciale shell viene escaped o rifiutato. Questa difesa a più livelli (validazione applicativa + controllo sudo + permessi filesystem) garantisce robustezza contro tentativi di escalation di privilegi.
prof.Brunetti Marco
Gateway di Accesso Remoto: Apache Guacamole
Per consentire l'accesso agli studenti senza richiedere l'installazione di client SSH o software specializzato, il laboratorio integra Apache Guacamole, un gateway clientless che fornisce accesso a protocolli remote (SSH, RDP, VNC) tramite browser web standard utilizzando HTML5 e WebSocket.
Architettura Guacamole
Guacamole è composto da due componenti principali:
  • guacd (Guacamole Daemon): Server proxy che gestisce le connessioni ai protocolli remote effettivi (SSH nel nostro caso) e traduce i loro stream in comunicazioni web-based.
  • guacamole-client: Web application Java (WAR) deployata su Tomcat che fornisce l'interfaccia utente HTML5 e gestisce autenticazione, autorizzazione e sessioni utente.
La comunicazione tra browser e server avviene tramite protocollo Guacamole, un protocollo testuale basato su istruzioni che trasporta input (tastiera, mouse) e output (rendering dello schermo) in formato JSON-like efficiente.
Processo di Connessione
1
Autenticazione Web
Lo studente accede alla web UI di Guacamole tramite HTTPS, fornendo username e password. Le credenziali vengono verificate contro il database PostgreSQL o sistema LDAP integrato.
2
Selezione Risorsa
Dopo l'autenticazione, viene presentata una dashboard con le connessioni disponibili (router e switch assegnati allo studente specifico). L'autorizzazione determina quali dispositivi sono visibili.
3
Inizializzazione Tunnel
Al click su una connessione, Guacamole client apre un WebSocket verso il server e richiede a guacd di stabilire una sessione SSH verso l'host specificato (es. localhost con utente r1).
4
Rendering Terminal
guacd riceve l'output del terminal SSH e lo converte in istruzioni di rendering Guacamole, che vengono inviate al browser tramite WebSocket. Il browser renderizza il terminal usando canvas HTML5.
5
Input Interattivo
Gli eventi tastiera/mouse catturati nel browser vengono trasmessi al server e convertiti in input SSH da guacd, consentendo l'interazione bidirezionale completa con la CLI.
Vantaggi della Soluzione Clientless
Accessibilità Universale
Funziona su qualsiasi dispositivo dotato di browser moderno: PC Windows/Mac/Linux, tablet, Chromebook, persino smartphone. Non richiede installazione software, configurazione client SSH, o gestione di chiavi crittografiche.
Centralizzazione Gestione
Tutte le configurazioni di connessione (hostname, porte, credenziali) sono gestite centralmente sul server. Modifiche alla topologia o rotazione delle password non richiedono azioni da parte degli studenti.
Audit e Logging
Guacamole può registrare le sessioni (session recording), loggare tutti gli accessi, e generare report di utilizzo. Questo è critico in contesti formativi per tracciare l'attività degli studenti.
Sicurezza Transport
Tutte le comunicazioni avvengono su HTTPS con certificati SSL/TLS, proteggendo le credenziali e i dati in transito da intercettazione. Il tunnel SSH interno aggiunge un ulteriore layer di crittografia end-to-end.
L'integrazione con sistemi di autenticazione enterprise (LDAP, Active Directory, SAML) consente di utilizzare le credenziali scolastiche esistenti, evitando la proliferazione di password multiple e semplificando il provisioning degli account studente tramite sistemi di Identity Management già in uso nell'istituto.
prof.Brunetti Marco
Esperienza Operativa e Flusso di Lavoro dello Studente
Dal punto di vista dell'utente finale (lo studente), il laboratorio presenta un'esperienza fluida e intuitiva che minimizza gli attriti tecnici e consente di concentrarsi sull'apprendimento dei concetti di networking piuttosto che sulla gestione dell'infrastruttura sottostante.
01
Login Web Browser
Lo studente apre un browser (Chrome, Firefox, Safari, Edge) e naviga all'URL del laboratorio (es. https://lab.example.edu). Inserisce username e password forniti dal docente. L'autenticazione avviene istantaneamente e viene presentata la dashboard Guacamole.
02
Selezione Apparato di Rete
La dashboard mostra icone cliccabili per ciascun dispositivo accessibile: Router R1, Router R2, Switch SW1, etc. Ogni icona è etichettata chiaramente e può includere metadati (indirizzo IP, descrizione). Lo studente clicca sul dispositivo desiderato per la sessione di lavoro.
03
Accesso Diretto alla CLI
Dopo un breve caricamento (tipicamente <2 secondi), appare un terminal emulator nel browser che mostra direttamente il prompt della CLI del dispositivo selezionato. Per i router: r1# (FRR vtysh). Per gli switch: Switch> (wrapper CLI). Non è necessaria alcuna autenticazione aggiuntiva.
04
Configurazione e Sperimentazione
Lo studente esegue comandi di configurazione secondo le istruzioni dell'esercitazione: configura indirizzi IP, abilita protocolli di routing, crea VLAN, configura trunk. La CLI risponde immediatamente con feedback sulla validità dei comandi e mostra eventuali errori di sintassi.
05
Verifica e Troubleshooting
Lo studente utilizza comandi diagnostici (show ip route, show vlan brief, ping, traceroute) per verificare la corretta implementazione della configurazione e diagnosticare eventuali problemi di connettività. L'output è identico a quello che si otterrebbe su apparati fisici.
06
Disconnessione e Persistenza
Quando lo studente ha completato il lavoro, chiude la tab del browser o esegue exit nella CLI. Le configurazioni sono persistenti: riaprendo la stessa connessione in seguito, le configurazioni precedentemente inserite sono ancora presenti (a meno che non sia stato eseguito un reset del laboratorio da parte del docente).
Esperienza Multi-Dispositivo
Una caratteristica potente del sistema è la possibilità di aprire connessioni multiple simultaneamente. Uno studente può:
  • Aprire più tab/finestre del browser
  • Connettersi contemporaneamente a router e switch diversi
  • Avere visibilità di configurazioni su dispositivi multipli
  • Eseguire comandi di test da endpoint diversi simultaneamente
Ad esempio, durante un'esercitazione su OSPF, lo studente può avere aperto R1 in una tab per configurare il protocollo, R2 in un'altra tab per verificare la neighbor relationship, e SW1 in una terza tab per monitorare il traffic VLAN.
Gestione Errori e Recovery
Errori di Sintassi
I comandi sintatticamente errati sono rilevati immediatamente dal parser (FRR o wrapper) e viene visualizzato un messaggio di errore descrittivo. L'esperienza è identica a quella su router reali: lo studente impara correggendo i propri errori.
Configurazioni Errate
Se lo studente configura erroneamente la rete (es. indirizzi IP sovrapposti, routing loops), il comportamento del laboratorio riflette esattamente quello che accadrebbe in una rete reale: perdita di connettività, timeout, etc. Questa è un'opportunità di apprendimento preziosa.
Reset Rapido
Se una configurazione è completamente compromessa, il docente può eseguire clab destroy seguito da clab deploy per ripristinare l'intero laboratorio allo stato iniziale in circa 2-3 minuti, consentendo di ricominciare l'esercitazione.
Questa modalità operativa consente agli studenti di sviluppare autonomia e problem-solving skills in un ambiente sicuro dove gli errori non hanno conseguenze reali ma forniscono feedback immediato e costruttivo sull'apprendimento.
prof.Brunetti Marco
Valutazione Tecnica Complessiva e Considerazioni Finali
Il progetto ha raggiunto con successo l'obiettivo di creare un ambiente di laboratorio di rete didattico che bilancia requisiti tecnici rigorosi, vincoli operativi dell'ambiente scolastico e necessità pedagogiche specifiche del curriculum CCNA. La soluzione implementata rappresenta un compromesso ottimale tra autenticità, praticità e sostenibilità.
Ambiente Autentico, Non Simulato
Tutti i componenti del laboratorio utilizzano software di networking reale: FRRouting per il routing, Open vSwitch per lo switching, stack TCP/IP del kernel Linux. Nessun simulatore o emulatore è coinvolto. Gli studenti interagiscono con protocolli RFC-compliant e sviluppano competenze trasferibili a contesti professionali.
Architettura Coerente e Modulare
La separazione netta tra routing (container FRR) e switching (bridge OVS) riflette l'organizzazione reale delle reti enterprise e garantisce correttezza concettuale. L'orchestrazione tramite Containerlab fornisce riproducibilità e versionabilità delle topologie. L'accesso web tramite Guacamole elimina barriere tecnologiche per gli studenti.
Scelte Tecniche Motivate
Ogni decisione architettonica è stata presa con consapevolezza dei trade-off e delle alternative. L'uso di un wrapper CLI per gli switch è giustificato dalla necessità di mantenere coerenza didattica con la sintassi CCNA. Le limitazioni rispetto a Cisco IOS hanno valore formativo nel contesto di reti multi-vendor.
Scalabilità e Replicabilità
  • Scalabilità verticale: Aumentando le risorse del VPS (CPU, RAM) è possibile supportare topologie più complesse o più utenti simultanei
  • Scalabilità orizzontale: Possibile deployment su cluster di VPS con load balancing per servire classi numerose
  • Replicabilità: L'intero stack può essere deployato su qualsiasi VPS Linux mediante script di provisioning automatizzato
  • Portabilità: La definizione YAML delle topologie è indipendente dall'hardware sottostante
Conformità ai Requisiti PNRR
Infrastruttura Cloud
Utilizzo di risorse cloud invece di hardware dedicato, riducendo costi di investimento iniziale e manutenzione
Accessibilità Universale
Accesso remoto per didattica ibrida e inclusione di studenti con difficoltà di mobilità o residenti in aree remote
Software Open Source
Tutti i componenti sono open source, eliminando costi di licensing e favorendo trasparenza e indipendenza tecnologica
Competenze Digitali Avanzate
Formazione su tecnologie enterprise reali che aumentano l'employability degli studenti nel mercato ICT
Metriche di Successo e Validazione
Conclusione: Il laboratorio realizzato rappresenta una soluzione tecnica robusta, pedagogicamente valida e operativamente sostenibile per la formazione pratica in ambito networking. L'approccio basato su tecnologie reali, pur richiedendo maggiore complessità implementativa rispetto a soluzioni di simulazione, garantisce un'esperienza formativa di qualità superiore e prepara gli studenti ad affrontare con competenza contesti professionali reali. La soluzione è pronta per la valutazione tecnica formale e per il deployment in ambiente di produzione didattica.
prof.Brunetti Marco
Integrazione con la Piattaforma Didattica
Per massimizzare l'efficacia didattica e fornire un'esperienza unificata, il laboratorio di rete è strettamente integrato con la piattaforma e-learning Moodle "unknown link". Questa integrazione funge da hub centrale per tutte le attività del corso.
  • Accesso diretto alle sessioni di laboratorio tramite link dedicati.
  • Materiali didattici supplementari (teoria, video, guide) organizzati per moduli.
  • Gestione e tracciamento delle consegne e dei progressi degli studenti.
  • Forum di discussione e supporto per la risoluzione collaborativa dei problemi.
Questo approccio garantisce che la pratica "hands-on" nel laboratorio sia sempre contestualizzata e supportata dalla teoria necessaria, facilitando un apprendimento più profondo e coerente.
prof. Brunetti Marco