SDN, NFV e reti overlay - la rete programmabile
Dalla scatola nera al codice: come disaccoppiamo cervello e muscoli della rete, virtualizziamo firewall e router su server standard e creiamo reti virtuali sopra la rete fisica per campus, data center e filiali. Con lab pensati per il nostro istituto.
🎯 Obiettivi di apprendimento
1. Il problema delle reti tradizionali
Per 30 anni la rete è stata un insieme di scatole proprietarie: ogni switch, router, firewall con il suo ASIC, il suo sistema operativo chiuso (IOS, JunOS, FortiOS) e il suo cervello distribuito. Ogni dispositivo prende decisioni di forwarding in autonomia eseguendo protocolli distribuiti – STP, OSPF, BGP, VRRP – e tu configuri device uno ad uno in CLI.
Il risultato? Rigidità: aggiungere una VLAN in 4 palazzi del nostro istituto significa accedere a 12 switch e digitare manualmente. Lentezza: provisioning di un servizio nuovo richiede giorni. Vendor lock-in: la funzione firewall la compri solo da quel vendor, su quell'hardware, con licenza. Poca visibilità globale: nessun dispositivo vede tutta la topologia, ognuno ha una visione parziale.
SDN e NFV nascono esattamente per questo: estrarre l'intelligenza dalla scatola, metterla in software su server standard, e programmare la rete come si programma un'applicazione.
Configurazione per-device
120 switch campus = 120 SSH. Errori umani, drift configurazione, rollback manuale notturno. Tempo medio change: 3-4 ore.
Hardware proprietario
Firewall = appliance 8k€ che dopo 3 anni è lenta. Se vuoi NAT più veloce cambi scatola, non aggiungi CPU.
Nessuna API
L'applicativo didattico non può dire alla rete "riserva 100 Mbps per lab video". La rete non parla con le app.
Spiega così: rete tradizionale = orchestra senza direttore, ogni musicista segue lo spartito e ascolta i vicini per andare a tempo (OSPF). SDN = metti un direttore (controller) sul podio che vede tutti e dice a ciascuno quando suonare. NFV = invece di comprare uno xilofono da 5000€, simuli il suono con un laptop (VNF su server standard). Gli studenti capiscono subito il cambio di paradigma.
2. SDN – Separazione Control Plane / Data Plane, OpenFlow e Controller
Architettura dove il Control Plane (decisioni di routing, ACL, QoS) è disaccoppiato dal Data Plane (forwarding veloce dei pacchetti) ed è centralizzato in un controller programmabile. I dispositivi diventano semplici executor di regole (flow table) installate dal controller via protocollo southbound come OpenFlow.
In rete tradizionale i due piani convivono nella stessa scatola. In SDN li stacchiamo:
- Data Plane: switch whitebox + ASIC + Open vSwitch (OVS) che mantiene una Flow Table. "Se pacchetto matcha IP 10.0.5.0/24 e TCP 443 → azione forward porta 3, incapsula, drop, manda a controller". Fa solo quello, ma a 100 Gbps.
- Control Plane: applicazione software su server/cluster – OpenDaylight (ODL), ONOS, Ryu, Floodlight. Ha la mappa completa, calcola percorsi (topologia via LLDP), applica policy centrali, espone API northbound REST/RESTCONF verso le app aziendali.
- Southbound API: OpenFlow 1.3/1.5 è lo standard: dal controller al dispositivo. Alternativi: NETCONF, P4Runtime (per switch programmabili P4), OpFlex. OpenFlow: messaggi Hello, Features, Flow-Mod (aggiungi flow), Packet-In (switch "non so dove mandare questo → controller"), Packet-Out.
- Northbound API: REST, gNMI, Intent. Es. app di sicurezza: POST /network/policy {"isola host infetto"} → controller traduce in flow drop su tutti gli edge.
Google ha SDN in produzione dal 2012: B4 interconnette data center globali con controller centralizzato che ottimizza WAN al 95% di utilizzo vs 30% tradizionale. Andromeda è la rete virtualizzata che gira sotto GCP: ogni VPC che crei è gestita da controller SDN che programma OVS sugli host. Microsoft con Azure Virtual Network usa approccio simile.
OpenFlow nel dettaglio – come il controller programma lo switch
OpenFlow 1.3 definisce pipeline di tabelle. Un pacchetto entra, il parser estrae header (Ethernet, VLAN, IP, TCP), confronta con flow entry (priority più alta vince) → esegue istruzioni (apply actions, goto table, meter). Contatori per telemetria.
Messaggi chiave: OFPT_PACKET_IN – switch invia al controller pacchetto sconosciuto (es. ARP iniziale). OFPT_FLOW_MOD – controller installa/regola. OFPT_PACKET_OUT – controller inietta pacchetto. OFPT_STATS – statistiche.
1. Single point of failure logico: se il controller cade, i flow esistenti continuano a forwardare (fail-secure) ma non impari nuove destinazioni. Serve cluster HA Raft (3 nodi). 2. Packet-In storm: se lasci flow default "manda tutto a controller" su rete campus con broadcast, inondi il controller. Sempre filtrare. 3. Pensare che OpenFlow sia l'unica southbound: oggi si usa anche NETCONF/YANG per configurare VXLAN, e P4Runtime per switch programmabili dove riscrivi parser. 4. Latenza Packet-In: primo pacchetto di ogni flow va al controller → 2-5 ms extra. Soluzione: proactive flow install per traffico noto.
3. NFV e MANO – dal ferro proprietario alle funzioni virtuali su server standard
NFV (Network Functions Virtualization): paradigma ETSI per eseguire funzioni di rete (firewall, router, load balancer, EPC, BNG) come VNF – Virtual Network Functions su infrastruttura NFVI COTS (server x86 + hypervisor/K8s) invece di appliance. MANO (Management and Orchestration) è lo stack che gestisce il ciclo di vita: NFVO (orchestratore globale), VNFM (manager di singola VNF), VIM (Virtualized Infrastructure Manager = OpenStack / Kubernetes / VMware).
Perché interessa? Un firewall Fortinet da 10 Gbps costa 15k€ + licenza. Una vFirewall Palo Alto o pfSense su server Dell da 3k€ fa 20 Gbps se gli dai core. Se ti serve il secondo firewall, non compri ferro: openstack server create o kubectl scale deployment vfirewall --replicas=2.
Architettura ETSI MANO
NFV Orchestrator
Vede tutti i data center. Riceve NSD (Network Service Descriptor, TOSCA/YAML) e decide dove piazzare VNF per soddisfare SLA. Gestisce service chain: traffico → vFW → vIDS → vNAT.
VNF Manager
Gestisce vita di UNA VNF: deploy, config (day-0/1), scale-out, auto-healing. Se vFirewall crasha, lo riavvia o ne crea altro.
Infra Manager
OpenStack, K8s, VMware. Alloca CPU/RAM, reti virtuali, storage. Espone risorse a NFVO. Oggi più spesso container: CNF su Kubernetes.
Service Chaining (SFC): in data center, invece di cablare fisicamente PC→FW→LB→Server, crei una catena logica. Il controller (anche ODL con SFC) programma OVS per far passare il flow per NSP (Network Service Path): classifier → vFW → vLB → render. Tutto software.
Nel nostro istituto abbiamo 5 laboratori + WiFi studenti. Invece di 6 firewall fisici, installiamo 1 server Proxmox/KVM + OVS in armadio CED. Deploy 6 VNF pfSense (una per lab) isolate: lab meccanico può avere porte aperte per PLC Siemens, lab informatico DPI per bloccare torrent. Se un docente vuole regola nuova, VNFM applica via Ansible. Backup snapshot in 2 minuti. Costo: da 30k€ hardware a 4k€ server + licenze zero.
Gli studenti confondono: SDN = Come programmo la rete (separazione piani). NFV = Cosa virtualizzo (funzioni). Possono coesistere: controller SDN programma OVS che incatena VNF. Oppure NFV senza SDN (VNF configurate manualmente). Usa questa frase: "SDN è il sistema nervoso, NFV sono gli organi virtuali". Chiedi: un load balancer su EC2 è NFV? Sì. È SDN? Solo se c'è controller che programma flussi.
4. Reti overlay – VXLAN, NVGRE, GENEVE: la rete sopra la rete
Il data center moderno ha un problema: VLAN 802.1Q ha solo 4096 ID. In un DC multi-tenant cloud con 5000 clienti che vogliono 10 VLAN ciascuno servono milioni di reti isolate. Inoltre VLAN è L2 limitata, non attraversa router L3. Serve una overlay: incapsulo il frame L2 originale in pacchetto UDP/IP che viaggia sulla rete fisica (underlay). L'underlay vede solo IP, l'overlay vede solo tenant.
Underlay: rete fisica IP (spine-leaf) che trasporta pacchetti. Overlay: rete virtuale che incapsula il traffico tenant (MAC + IP) dentro UDP. VTEP (VXLAN Tunnel Endpoint): switch/software che fa encap/decap. VNI (VXLAN Network Identifier): 24 bit → 16 milioni di reti isolate vs 4096 VLAN.
Standard de facto
MAC-in-UDP, porta 4789, VNI 24 bit. Supportato ovunque: OVS, Cisco Nexus, Linux kernel, VMware NSX, AWS. Header 50 byte overhead.
Microsoft
MAC-in-GRE con VSID 24 bit. Usato da Hyper-V Network Virtualization. Meno adottato, ma concetto identico.
Evolutivo
Stessi concetti VXLAN ma TLV estensibili per metadati (SFC, telemetria). Usato da OVN, NSX-T, futuro degli overlay.
Come funziona VXLAN – passo passo
Host A in VLAN 20 per tenant Studenti (VNI 5001) vuole parlare con host B nello stesso tenant ma in leaf diverso. Switch VTEP1: prende frame Ethernet, aggiunge header VXLAN (VNI 5001) + UDP + IP underlay (src leaf1, dst leaf2) + invia su underlay. VTEP2 decapsula e consegna a host B. Gli switch core non sanno nulla di MAC tenant, vedono solo IP leaf.
| Feature | VLAN 802.1Q | VXLAN | GENEVE |
|---|---|---|---|
| Isolamento max | 4096 ID (12 bit) | 16M (24 bit VNI) | 16M + TLV estesi |
| Dominio L2 su L3 | No – solo L2 domain | Sì – L2 over L3 UDP | Sì – L2 over L3 + metadati |
| Overhead | 4 byte | 50 byte (IP+UDP+VXLAN+L2) | 50-100+ byte variabile TLV |
| Controllo MAC learning | Flood & learn | Multicast o EVPN BGP (moderno) | OVN / EVPN |
| Supporto HW | Tutti | Tutti (Nexus, OVS, Linux) | OVS 2.5+, NSX-T, Linux 5.6+ |
| Uso consigliato oggi | Accesso aula | Data center multi-tenant campus | Prossima gen SFC, telemetria |
Il nostro istituto ha sede centrale + succursale collegate da fibra GARR. Vuoi tenere stessa VLAN 20 Studenti in entrambe le sedi come se fossero stesso L2 per roaming Wi-Fi ed esami? Con fibra L2 pura usi 2 fiber dedicate e spanning-tree rischioso. Con VXLAN EVPN crei stesso VNI 5001 su entrambe le sedi, underlay OSPF L3 tra sede. VM Moodle in centrale raggiungibile in L2 da succursale senza loop. Se un domani aggiungi sede 3, aggiungi solo un VTEP, non ricabli VLAN.
5. SD-WAN – La WAN programmabile per istituti e filiali
SD-WAN (Software Defined WAN) applica principi SDN alla rete geografica: controller centralizzato gestisce decine/centinaia di CPE (customer premises equipment) nelle sedi, crea tunnel cifrati IPsec/DTLS su qualsiasi trasporto (FTTH, FTTC, 4G/5G, MPLS), sceglie percorso per-applicazione tramite policy (es. Teams va su link basso jitter, backup su 4G). Zero-touch provisioning: colleghi CPE, si auto-registra su controller cloud.
Prima: sede succursale collegata con MPLS costoso + router CLI + failover manuale. Se cadeva, 2 ore di intervento. Con SD-WAN: due link cheap (fibra + 4G router), controller vede latenza/packet-loss in tempo reale e sposta VoIP su fibra migliore, YouTube su link secondario. Cifratura nativa, segmentazione, firewall VNF nel CPE.
1000€/mese per 100Mbps, configurazione per-sede, failover statico, MPLS non vede app
Provider locked, aggiungi sede = 60 giorni, troubleshooting traceroute cieco.
2x FTTH 30€ + 4G → 200Mbps, controller cloud, policy app-aware, cifrato, ZTP
Aggiungi sede in 1 ora, vedi dashboard centralizzata, SLA applicativa.
Porta in classe bollette reali (anonimizzate) MPLS: 1 sede succursale 100 Mbps MPLS = circa 600-1200€/mese. SD-WAN con 2 linee consumer FTTC + 4G 80€ + licenza Fortinet 300€/anno = 100€/mese. Risparmio 80%. Ma spiega anche limite: MPLS ha SLA 99.95% e latenza garantita, Internet no – per VoIP critico serve comunque QoS. Fai fare business case: costo vs rischio. Gli studenti capiscono valore economico immediato, non solo tecnico.
| Criterio | MPLS tradizionale | SD-WAN |
|---|---|---|
| Trasporto | MPLS provider privato | Qualsiasi: FTTH, 4G/5G, MPLS, Internet |
| Controllo routing | Distribuito BGP per-sito CLI | Controller centralizzato + policy app-aware |
| Zero-touch | No, tecnico on-site | Sì, mail con codice, CPE si auto-provisiona |
| Sicurezza | MPLS non cifrato (privato ma non encrypt) | IPsec/DTLS nativo, microsegmentazione, NGFW VNF |
| Visibilità | SNMP ping | Dashboard real-time latency/loss per-app, DPI |
| Failover | 30-60 sec BFD | Sub-secondo per-flow, sessione VoIP non cade |
6. Casi d'uso reali + progetto istituto integrato
Ora mettiamo insieme tutto in un progetto campus intelligente – quello che potremmo realmente implementare nel nostro istituto e presentare all'esame di stato come tesina di quinta.
Scenario completo – 3 livelli
SDN edge con OVS + controller Ryu su Raspberry Pi
Ogni banco ha presa dot1x SDN: se autenticazione OK → flow che mette in VNI 5001 (studenti) o 5002 (docenti). Se rilevato malware, controller isola in quarantine VNI 99.
NFV server + VXLAN EVPN
Su Proxmox: VNF firewall per-lab, Moodle, server file. Overlay VXLAN stesso VNI tra centrale e succursale: live migration VM senza cambiare IP.
SD-WAN Fortinet con 4G failover
Succursale e PCTO mobile collegati con tunnel cifrati, controller cloud gestisce policy. Se cade fibra, VoIP va su 4G senza perdita chiamata.
Obiettivo: collegare sede centrale (CED + 5 lab + WiFi) e succursale (2 lab). Budget <5k€. Soluzione:
1. Controller SDN: VM OpenDaylight su server esistente + 2 switch whitebox Edgecore con OVS o Mikrotik con OpenFlow sperimentale. Costo 0-800€.
2. NFV: server refurbished Dell R620 32GB (400€) con Proxmox: deploy pfSense VNF per ogni lab (microsegmentazione), HAProxy per Moodle, Suricata IDS come CNF. Backup via NFS.
3. Overlay VXLAN: tra armadi centrali e succursale, VNI 5001 studenti, VNI 5002 docenti, VNI 5999 guest isolamento. EVPN con FRR per evitare flood.
4. SD-WAN: due CPE Fortigate 40F (licenza EDU gratuita) o open source FlexiWAN + 4G dongle. Tunnel IPsec con FEC per VoIP.
Benefici misurabili: isolamento sicurezza 100%, aggiunta lab in 15 min vs 4h, costo WAN -75%, visibilità dashboard Grafana + Prometheus che esporta metriche OVS.
1. Istituto Agrario Vezzani: ha usato VXLAN + EVPN su Mikrotik per unificare 3 serre IoT + uffici su stessa rete L2 nonostante underlay 4G. 2. Comune di Bologna Wifi: SSID guest isolato via VXLAN VNI 6000, firewall VNF centralizzato, SD-WAN su 40 punti. 3. Telco TIM: NFV per vEPC 5G – 60% funzioni mobili virtualizzate, orchestrazione ONAP. 4. Netflix Open Connect: usa overlay GENEVE per service chain transcoding.
MTU: VXLAN aggiunge 50 byte. Se non abbassi MTU overlay a 1450 o abiliti jumbo, video lezioni si frammentano e qualità crolla. Controller placement: non mettere controller su stessa VM host che controlla – loop. Flood EVPN: se usi multicast per BUM (Broadcast Unknown Multicast) in campus con 200 host, generi storm. Usa EVPN Route Type 2/3. Licensing VNF: pfSense CE gratis ma throughput limitato, serve tuning offload DPDK per >10Gbps.
Verifica / Esercizio guidato
🔬 Progetta rete programmabile per istituto con sede staccata
Sede centrale: 3 lab informatici (VLAN isolati), WiFi studenti, server Moodle interno. Succursale a 2km collegata prima con VPN obsoleta, cade spesso. Vuoi sicurezza, scalabilità, costo basso. Rispondi integrando SDN, NFV, overlay, SD-WAN.
- Disegna control/data plane SDN per centrale: dove metti controller? Quale southbound? Come blocchi host infetto 10.1.50.22 senza toccare switch CLI?
- Proponi 3 VNF su server COTS e spiega MANO: chi è NFVO/VNFM/VIM nel tuo progetto? Come scala VNF firewall se CPU 80%?
- Scegli overlay VXLAN vs VLAN: calcola quanti tenant con VLAN vs VXLAN, spiega VTEP, VNI, perché MTU 1450, EVPN vs multicast flood.
- SD-WAN: scegli 2 trasporti per succursale, policy per Moodle (alta priorità) vs YouTube (bassa), failover VoIP, stima costo vs MPLS e sicurezza tunnel.
1) SDN: Controller OpenDaylight cluster 2 nodi VM in CED (HA Raft). Southbound OpenFlow 1.3 verso OVS su switch whitebox Mikrotik CRS. Quando SIEM rileva 10.1.50.22 infetto → app northbound POST /quarantine → controller invia FLOW_MOD priority 600 match ip_src 10.1.50.22 action drop su tutti VTEP edge + flow redirect a VLAN honeypot 99. Nessun SSH, isolamento in <2 sec globale. Fail-secure: se controller down, flow esistenti restano, nuovi ARP vanno in cache locale OVS per 60 sec.
2) NFV MANO: NFVI = Proxmox cluster 2 nodi (VIM). VIM gestisce KVM + LXC. Su di esso: vFW pfSense per lab1 (2 vCPU), vFW lab2, HAProxy vLB per Moodle (CNF su K3s). NFVO = OSM lightweight o script Ansible AWX che legge NSD YAML service chain. VNFM = elemento che monitora pfSense via API: se CPU >80% 2 min → NFVO avvia replica 2 e aggiorna LB (scale-out) o aggiusta CPU (scale-up). Lifecycle: NSD → NFVO → VIM allocate → VNFM day-0 config → monitoraggio. Se crasha, auto-heal: VIM riavvia container.
3) Overlay: VLAN 4096 limite: 3 lab + WiFi + guest + mgmt = già 6, ma con isolamento per classe diventano 20 → quasi limite e non estensibile tra sedi senza QinQ. VXLAN VNI 5001 studenti, 5002 docenti, 5003 lab1, 5004 lab2, 5999 guest. 24 bit = 16M. VTEP leaf1 (10.255.1.1) e leaf2 succursale (10.255.1.2). Encapsula frame in UDP 4789. MTU: underlay 1500 - 50 overhead = 1450 su br-overlay, altrimenti frammentazione IP → calo 30% throughput. EVPN BGP (FRR) per MAC learning: Route Type 2 anuncia MAC/IP, Type 3 inclusive multicast per BUM, evita flood multicast che in WiFi creerebbe broadcast storm.
4) SD-WAN: Trasporti: FTTH TIM 300M (10ms jitter 1ms) + 4G Vodafone con router Teltonika RUT950 (30ms jitter 8ms). CPE SD-WAN Fortigate 40F EDU (o FlexiWAN open). Template centralizzato: policy1 = Moodle 10.0.0.10 DSCP EF → prefer FTTH, SLA loss <1%, latency <50ms, failover <1 sec a 4G. Policy2 = YouTube/Netflix → low prio, può usare 4G se FTTH pieno. VoIP: FEC + duplicazione pacchetto su entrambi link per zero loss. Tunnel IPsec AES256 + SHA256, chiavi rotate da controller. Costo: FTTH 30€ + 4G 15€ + lic 0 edu =45€/mese vs MPLS 600€/mese = -92%. Sicurezza: microsegmentazione – traffico guest VNI 5999 può andare solo a Internet, non a server interni, applicata da CPE via VRF.
Riepilogo e concetti chiave
📚 Prossimo passo — Zero Trust e SASE: identità e sicurezza oltre il perimetro
Ora che sai virtualizzare e programmare la rete, il passo successivo è non fidarsi più di nessuno: verifica ogni identità, microsegmenta, porta sicurezza nel cloud con ZTA e SASE.