Cisco SD-WAN (oggi Catalyst SD-WAN) rivoluziona il design della WAN aziendale disaccoppiando la logica di rete dai singoli link di trasporto. In ENSLD questo tema si valuta soprattutto sul piano architetturale: quali componenti scegliere, come separano i tre piani funzionali e come OMP distribuisce le informazioni di raggiungibilità sull’overlay.
I componenti della fabric
L’architettura si fonda su quattro elementi, ciascuno legato a un piano funzionale ben preciso:
| Componente | Piano | Ruolo |
|---|---|---|
| vManage | Management | GUI/API centralizzata, provisioning, template di configurazione, monitoring e troubleshooting |
| vSmart | Control | Controller che parla OMP con i WAN Edge, applica policy centralizzate, distribuisce route/TLOC/service e chiavi crittografiche |
| vBond | Orchestration | Orchestratore che autentica i device, gestisce l’onboarding Zero Touch Provisioning (ZTP) e il NAT traversal (deve avere IP pubblico raggiungibile) |
| WAN Edge (cEdge/vEdge) | Data | Router perimetrale che costruisce i tunnel IPsec dell’overlay e inoltra il traffico applicativo |
Punto chiave: vBond è l’unico componente che deve essere pubblicamente raggiungibile, perché è il primo contatto per ogni Edge che si accende. vSmart non tocca mai il traffico dati degli utenti: gestisce solo il control plane.
Separazione dei piani
La forza del modello è la netta separazione tra:
- Management plane (vManage) — configurazione e visibilità end-to-end.
- Control plane (vSmart + OMP) — decisioni di routing e policy, centralizzate.
- Data plane (WAN Edge) — inoltro dei pacchetti su tunnel IPsec cifrati.
I controller comunicano con gli Edge tramite sessioni DTLS/TLS protette. Il traffico dati viaggia invece direttamente Edge-to-Edge (fabric a maglia), senza transitare dal vSmart: questo evita che il control plane diventi un collo di bottiglia e mantiene la latenza bassa.
OMP: il “BGP” dell’overlay
Overlay Management Protocol gira dentro le sessioni DTLS/TLS tra WAN Edge e vSmart, concettualmente simile a un iBGP con route reflector (il vSmart è il reflector). Un Edge non forma peering OMP diretto con gli altri Edge: annuncia tutto al vSmart, che ridistribuisce. OMP trasporta tre tipi di route:
- OMP routes (vRoutes) — i prefissi IP raggiungibili dietro ogni Edge, con attributi come origin, preference e la VPN/segment di appartenenza.
- TLOC routes — i Transport Locator, identità di un punto di aggancio al trasporto. Una TLOC è la tripla {system-IP, color, encapsulation}. Il color (es.
mpls,biz-internet,public-internet) identifica il tipo di trasporto e determina come si formano i tunnel e se serve il pubblico/privato. - Service routes — annunciano servizi di rete (firewall, IPS, load balancer) inseribili nel percorso tramite service insertion guidata da policy.
Le OMP route puntano a una o più TLOC come next-hop: separando cosa è raggiungibile (prefisso) da dove/come si esce (TLOC), OMP abilita nativamente il multipath e il bilanciamento su più trasporti.
Overlay vs WAN tradizionale
| Aspetto | WAN tradizionale | SD-WAN overlay |
|---|---|---|
| Dipendenza dal trasporto | Design legato a MPLS/L3VPN | Transport independence: MPLS, Internet, LTE/5G trattati alla pari |
| Policy | Configurate box-per-box (CLI) | Centralizzate su vSmart, applicate a livello di fabric |
| Path selection | Routing per-hop, failover lento | Application-aware, SLA per-app, failover sub-secondo |
| Sicurezza | Da progettare a parte | IPsec + segmentazione (VPN) integrati |
| Resilienza | Attivo/passivo tipico | Multi-transport attivo/attivo con TLOC multiple |
La transport independence è il valore di design centrale: aggiungere un secondo trasporto (es. biz-internet accanto a mpls) significa aggiungere TLOC, e la fabric usa entrambi in parallelo con policy che indirizzano ogni applicazione sul path che ne rispetta lo SLA (latenza, jitter, loss).
Trappole tipiche d’esame
- Scenario: il device non si registra alla fabric al primo avvio → la risposta corretta cita vBond (orchestrazione/ZTP e primo punto di contatto con IP pubblico), non vSmart né vManage.
- Scenario: “chi applica le control policy e distribuisce le route?” → vSmart via OMP. vManage è solo management/provisioning; distrattore classico è attribuirgli il control plane.
- Scenario: serve raggiungere una destinazione ma cambia solo il punto di uscita sul trasporto → è la TLOC {system-IP, color, encapsulation} a cambiare, mentre l’OMP route resta; non confondere i due tipi di annuncio.
- Scenario: design che deve usare MPLS e Internet contemporaneamente in attivo/attivo → invocare transport independence con TLOC multiple e app-aware routing, non un semplice failover statico.
- Scenario: inserire un firewall centralizzato nel percorso di certe VPN → si usano le service route con service insertion via policy centralizzata sul vSmart, non route statiche per-Edge.