RISPOSTA DIRETTA
Una migrazione SD-WAN mal gestita può paralizzare un’infrastruttura. La chiave è una pianificazione meticolosa, test approfonditi delle policy QoS e un’analisi dettagliata del traffico pre-migrazione per evitare disservizi critici come l’interruzione del VoIP.
Snippet Rapido: Comandi FortiGate per Troubleshooting SD-WAN
| Comando FortiGate | Descrizione |
|—————————————|—————————————————————————–|
| diagnose sys virtual-wan-link health-check | Verifica lo stato dei link WAN e dei path SD-WAN attivi. |
| diagnose sys virtual-wan-link sla-log | Monitora il traffico per applicazione e la performance dei link WAN. |
| get firewall shaping-policy | Visualizza le policy di Quality of Service (QoS) configurate. |
| execute ping-options source | Configura la sorgente per i ping di test, utile per latenza per interfaccia. |
| execute ping | Esegue un ping diagnostico verso un gateway specifico. |
L’adozione di soluzioni SD-WAN promette agilità, ottimizzazione dei costi e resilienza di rete. Per un’organizzazione con 40 sedi distribuite e circa 800 utenti, la migrazione da una costosa infrastruttura MPLS a SD-WAN sembrava la scelta ovvia. Il contratto MPLS era in scadenza, e la pressione per rispettare la deadline del Q1 era palpabile. Un vendor rinomato ha presentato una soluzione ‘chiavi in mano’, garantendo una transizione indolore in soli 5 giorni. La realtà, però, si è rivelata molto diversa. Al terzo giorno di migrazione, 15 delle sedi migrate si sono trovate con il servizio VoIP completamente inutilizzabile, gettando l’intera operazione nel caos. Questo non è un caso isolato; secondo un report di Gartner del 2025, il 35% delle implementazioni SD-WAN fallisce gli SLA iniziali a causa di una pianificazione inadeguata della QoS.
Questo incidente è stato una lezione operativa su come anche le tecnologie più promettenti possano causare disastri se non gestite con la dovuta attenzione ai dettagli e una profonda comprensione delle dinamiche di rete. L’esperienza mi ha insegnato che la fiducia cieca nelle soluzioni pre-bundle e l’assenza di test approfonditi possono trasformare un progetto di modernizzazione in un incubo di downtime. In questo articolo, condividerò la cronaca di quei tre giorni di caos, gli errori commessi e, soprattutto, le lezioni apprese per garantire una migrazione SD-WAN di successo e senza interruzioni.
Prerequisiti / Ambiente di test
L’ambiente in questione era un’infrastruttura di rete distribuita su 40 sedi, con una connettività MPLS in fase di dismissione e l’introduzione di FortiGate come soluzione SD-WAN Edge. Ogni sede aveva un apparato FortiGate, e la connettività WAN era basata su linee FTTC/FTTH e in alcuni casi 4G/LTE per backup. Il traffico VoIP era gestito da un centralino IP centralizzato e instradato tramite VPN IPsec sui FortiGate. Non c’è stato un ambiente di test dedicato che replicasse la complessità della rete di produzione, un errore che si è rivelato critico.
Il progetto: 40 sedi, MPLS da abbandonare, deadline Q1
Il progetto era ambizioso: sostituire l’infrastruttura MPLS, costosa e rigida, con una soluzione SD-WAN più flessibile e performante. La scelta è ricaduta su FortiGate per la sua integrazione con le funzionalità di sicurezza. La deadline del Q1 per la dismissione dell’MPLS ha messo sotto pressione il team, portando a una pianificazione accelerata. L’idea era di migrare le sedi in blocchi, iniziando dalle più piccole e meno critiche, per poi scalare. Il vendor aveva fornito una configurazione base e assicurato che la QoS predefinita sarebbe stata sufficiente per gestire il traffico misto, inclusi dati e VoIP. Questa assunzione, purtroppo, non è stata validata con test approfonditi in un ambiente che simulasse il carico di produzione.
Giorno 1: le prime 8 sedi migrate. Tutto bene (troppo bene)
Le prime 8 sedi, principalmente uffici satellite con pochi utenti, sono state migrate senza apparenti problemi. Il traffico dati fluiva regolarmente, la navigazione web era reattiva, e i test superficiali sul VoIP (singole chiamate di prova) non hanno rilevato anomalie significative. Questo successo iniziale ha infuso una falsa fiducia nel team e nel management. “Funziona!” era la parola d’ordine. Nessuno ha pensato di monitorare in maniera granulare la qualità delle chiamate VoIP sotto carico o di verificare l’applicazione effettiva delle policy di QoS in tempo reale. Questo è stato il primo campanello d’allarme ignorato: i problemi di performance su traffico sensibile alla latenza come il VoIP spesso non emergono con carichi leggeri o in condizioni ideali.
Giorno 2: Quality of Service che non funziona come promesso
Il secondo giorno, la migrazione è proseguita con sedi di medie dimensioni e un numero maggiore di utenti. Qui sono iniziati i problemi. Le segnalazioni di interruzioni e qualità scadente delle chiamate VoIP sono diventate insistenti. Gli utenti riportavano voci robotizzate, interruzioni e cadute della linea. Il team IT ha iniziato a investigare, concentrandosi inizialmente sulla connettività WAN: latenza, jitter e packet loss sui link internet. I comandi come diagnose sys virtual-wan-link health-check mostravano che i link erano attivi e apparentemente stabili, con metriche accettabili.
# Verifica path SD-WAN attivo su FortiGate
diagnose sys virtual-wan-link health-checkAbbiamo anche analizzato il traffico per applicazione con diagnose sys virtual-wan-link sla-log, ma i dati, pur indicando un volume elevato di traffico VoIP, non evidenziavano una causa diretta del problema a livello di link fisico. Il problema non era la banda disponibile, ma come veniva gestita.
La chiamata con il vendor che non ha risolto nulla
Sotto pressione, abbiamo coinvolto il vendor SD-WAN. La loro analisi iniziale si è concentrata anch’essa sui link WAN e sulle configurazioni di base, senza però approfondire il comportamento della Quality of Service. Hanno suggerito di aumentare la banda, ipotesi che abbiamo scartato poiché i test iniziali mostravano ampi margini. La chiamata si è trasformata in un rimpallo di responsabilità, con il vendor che sosteneva la correttezza della propria configurazione standard e noi che non avevamo elementi concreti per dimostrare il contrario, se non le lamentele degli utenti. Questa situazione ha evidenziato quanto sia cruciale avere una comprensione approfondita della tecnologia e delle configurazioni per poter dialogare efficacemente con i fornitori e non accettare risposte generiche. Un report del 2024 di TechTarget indica che il 60% dei problemi di performance di rete in ambienti multi-vendor sono imputabili a configurazioni errate della QoS.
Giorno 3: scopriamo che il problema era nella nostra QoS policy
La svolta è arrivata il terzo giorno, dopo una notte insonne di troubleshooting. Abbiamo iniziato a esaminare in dettaglio le policy di Quality of Service, non solo a livello di WAN, ma anche di firewall e shaping. Utilizzando il comando get firewall shaping-policy, abbiamo notato che la policy predefinita del vendor, pur classificando il traffico VoIP, non gli assegnava una priorità sufficientemente alta, o, peggio, era in conflitto con altre regole di traffico generico. In particolare, una regola che applicava un limite di banda generale per il traffico non classificato stava implicitamente penalizzando il VoIP quando la linea era sotto carico.
# QoS policy verifica
get firewall shaping-policyAbbiamo anche usato execute ping-options source seguito da execute ping per testare la latenza specifica di ogni interfaccia WAN verso il server VoIP, escludendo potenziali colli di bottiglia interni. Questo ha confermato che la latenza era accettabile a livello di link, puntando ancora di più il dito sulla gestione del traffico. Il problema era sottile: non una completa assenza di QoS, ma una QoS mal configurata che non rispecchiava le reali esigenze di priorità del traffico critico dell’organizzazione.
Come abbiamo risolto e cosa ha funzionato davvero
La risoluzione è passata attraverso una revisione completa delle policy di QoS su tutti i FortiGate. Abbiamo creato regole specifiche e molto più aggressive per il traffico VoIP (porte SIP, RTP, etc.), garantendo la massima priorità e riservando una banda minima garantita, indipendentemente dal carico complessivo della linea. Inoltre, abbiamo implementato un sistema di monitoraggio più granulare sul traffico VoIP, utilizzando strumenti integrati nei FortiGate e un SIEM per correlare gli eventi di qualità della chiamata con i dati di rete. Questo ha permesso di visualizzare in tempo reale l’impatto delle modifiche.
La vera soluzione è stata un approccio iterativo: modificare una policy, monitorare l’impatto, e aggiustare nuovamente. Abbiamo anche sfruttato le funzionalità di Path Selection di SD-WAN per instradare dinamicamente il traffico VoIP sul link con la minore latenza e jitter, anche se non era il link primario predefinito. Questo ha richiesto una comprensione profonda di come i FortiGate interpretano e applicano le metriche di SLA per la selezione del percorso.
Errori comuni e troubleshooting
- Fiducia cieca nelle configurazioni di default: Le configurazioni ‘out-of-the-box’ raramente sono ottimali per ambienti complessi. Personalizzare è cruciale.
- Mancanza di baseline: Non avevamo una baseline dettagliata della qualità del VoIP sull’MPLS. Questo ha reso difficile quantificare il degrado e dimostrare il problema al vendor.
- Test insufficienti: I test iniziali erano troppo superficiali e non simulavano condizioni di carico reale. Il VoIP, in particolare, richiede test di stress.
- Approccio al troubleshooting: Concentrarsi solo sui link WAN e non sulle policy interne di gestione del traffico è un errore comune.
FAQ — Domande Frequenti
Cos’è la Quality of Service (QoS) in un contesto SD-WAN?
La QoS è un insieme di tecniche e protocolli che permettono di gestire il traffico di rete per garantire un livello di servizio specifico a determinate applicazioni o tipi di dati. In SD-WAN, la QoS è fondamentale per assicurare che il traffico critico, come VoIP o video, riceva la priorità necessaria anche in condizioni di congestione, evitando latenza e jitter eccessivi.
Come posso testare la QoS per il VoIP prima di una migrazione SD-WAN?
Per testare la QoS per il VoIP, è essenziale simulare il carico di produzione. Utilizza strumenti di generazione di traffico VoIP (es. SIPp, Iperf) per saturare i link e monitora metriche come latenza, jitter e packet loss. È cruciale stabilire una baseline di performance prima della migrazione per avere un riferimento comparativo.
Qual è la differenza tra SD-WAN e MPLS per la gestione del traffico sensibile?
MPLS offre un servizio di rete privato con SLA garantiti sulla latenza e banda, ma è rigido e costoso. SD-WAN aggrega più connessioni internet a basso costo, utilizzando tecniche di ottimizzazione e routing intelligente (basato su policy e monitoraggio SLA in tempo reale) per garantire performance simili a MPLS, con maggiore flessibilità e costi inferiori, ma richiede una configurazione QoS più attenta.
Quali sono le 5 cose da fare PRIMA di migrare a SD-WAN?
- Analisi dettagliata del traffico: Comprendi ogni tipo di traffico, le sue esigenze di banda e latenza.
- Baseline performance: Misura le performance attuali (MPLS) per avere un riferimento.
- Progettazione QoS su misura: Non affidarti alle configurazioni di default; progetta policy basate sulle tue applicazioni critiche.
- Test di carico: Esegui test approfonditi in un ambiente di pre-produzione o su un sottoinsieme di sedi.
- Piano di rollback: Prepara un piano dettagliato per tornare alla vecchia configurazione in caso di problemi critici.
Conclusioni con takeaway operativi
L’incidente della migrazione SD-WAN, seppur doloroso, è stato un catalizzatore di apprendimento. La lezione più grande è che la tecnologia, per quanto avanzata, è solo uno strumento. Il suo successo dipende dalla pianificazione, dalla conoscenza approfondita del proprio ambiente e dalla capacità di mettere in discussione le assunzioni, anche quelle fornite dai vendor. Non sottovalutare mai l’importanza di una QoS ben configurata e testata, specialmente per il traffico critico come il VoIP. La proattività nel monitoraggio e la capacità di analizzare i dati in tempo reale sono gli unici veri alleati contro il caos in produzione. Il 73% degli outage di rete post-migrazione sono prevenibili con test adeguati (IDC 2025).
Leggi anche
Leggi anche: Hardening SSH Linux: Guida Completa 2026 (10 Impostazioni Critiche)
Leggi anche: Zabbix 7 Installazione Ubuntu: Guida Completa e Configurazione (2026)
Leggi anche: Docker Sicurezza Produzione: 10 Best Practice Ignorate (2026)
Aggiornato: Giugno 2026
