Perché SD-WAN per la connettività cloud
Quando le applicazioni migrano verso IaaS e SaaS, il traffico non è più diretto solo verso il data center: esce da ogni branch verso destinazioni multiple e distribuite. Una WAN tradizionale, costruita attorno al backhauling verso un hub centrale, introduce latenza e spreca banda. Cisco Catalyst SD-WAN (ex Viptela) risponde costruendo un fabric overlay che disaccoppia il piano di controllo dal piano dati e permette di applicare policy centralizzate, application-aware, fino ai gateway cloud.
I piani dell’architettura Catalyst SD-WAN
L’architettura separa quattro funzioni logiche, principio cardine per l’esame:
| Piano | Componente | Ruolo |
|---|---|---|
| Management | SD-WAN Manager (vManage) | GUI, provisioning, template, monitoring, REST API |
| Control | SD-WAN Controller (vSmart) | Distribuisce routing e policy via OMP; non instrada dati |
| Orchestration | SD-WAN Validator (vBond) | Autenticazione iniziale, NAT traversal, presenta i peer |
| Data | WAN Edge (cEdge IOS-XE / vEdge) | Costruisce i tunnel IPsec e inoltra il traffico |
Il cuore del controllo è OMP (Overlay Management Protocol), che gira dentro sessioni DTLS/TLS tra WAN Edge e Controller e annuncia tre tipi di route: prefissi di servizio, TLOC (Transport Locator, l’ancoraggio del tunnel identificato da system-IP, color ed encapsulation) e service route. I color (es. mpls, biz-internet, public-internet) classificano i transport e determinano quali TLOC possono formare tunnel tra loro. Il data plane usa tunnel IPsec full-mesh potenziali, ma la topologia effettiva è decisa dalle policy sul Controller.
Topologie hub-and-spoke per il cloud
Di default il fabric tende al full-mesh, ma per la connettività cloud si impone spesso una control policy hub-and-spoke sul vSmart: i branch (spoke) ricevono solo i TLOC dell’hub, non quelli degli altri spoke. L’hub può essere un data center regionale o, più modernamente, un cloud gateway dentro AWS/Azure/GCP.
- Cloud OnRamp for SaaS: misura la qualità dei path verso applicazioni SaaS e sceglie dinamicamente l’uscita migliore (DIA locale o via gateway), evitando il backhaul.
- Cloud OnRamp for Multicloud: automatizza il deploy di Cloud Gateway (Catalyst 8000V) nelle transit VPC/VNet, estendendo il fabric dentro l’infrastruttura del cloud provider e integrandosi con i costrutti nativi (Transit Gateway, vHub).
In questo modo l’hub logico vive nel cloud e gli spoke raggiungono i workload IaaS con lo stesso overlay che usano per il resto della WAN.
Estendere policy e segmentazione fino al cloud
La segmentazione nel fabric si realizza con le VPN (VRF), identificate da un VPN ID trasportato in OMP end-to-end. Un segmento “produzione” e uno “guest” restano isolati dal branch fino al gateway cloud senza ACL manuali su ogni hop: la separazione viaggia nell’overlay. Le centralized policy (control, data e app-route policy) sono definite una volta sul Manager e spinte al Controller, che le applica influenzando l’annuncio delle route o marcando il traffico. Le localized policy (ACL, QoS) restano sul singolo WAN Edge.
SD-WAN non è “una VPN”
È la distinzione che l’esame ama verificare:
- Una VPN IPsec/DMVPN crea tunnel cifrati, ma il routing è per-prefisso e statico rispetto alle condizioni di rete: se un path degrada, il traffico non si sposta finché il tunnel non cade.
- SD-WAN aggiunge Application-Aware Routing (AAR): SLA class definite su loss, latency e jitter misurati in tempo reale via BFD dentro ogni tunnel. Un’app critica (es. voce) viene spostata su un transport conforme allo SLA prima che l’utente percepisca il problema.
- Aggiunge visibilità end-to-end centralizzata (per applicazione, per tunnel, per SLA) impossibile con VPN puntuali gestite CLI-per-device.
- Aggiunge provisioning zero-touch e policy centralizzate, contro la configurazione hop-by-hop di una VPN classica.
In sintesi: la VPN dà il tunnel; SD-WAN aggiunge il cervello (controllo, policy, telemetria) che decide come usare quei tunnel.
Trappole tipiche d’esame
- Scenario: ti chiedono quale componente distribuisce le route e le policy nel fabric. → Risposta giusta: il SD-WAN Controller (vSmart) via OMP; il Validator (vBond) fa solo orchestrazione/NAT traversal e non instrada nulla.
- Scenario: due WAN Edge non formano tunnel nonostante il full-mesh atteso. → Verifica i color e le restrizioni
restrict/private-vs-public: TLOC con color incompatibili o una control policy hub-and-spoke impediscono i tunnel spoke-to-spoke. - Scenario: serve isolare traffico produzione e guest fino ai workload IaaS senza ACL per-hop. → Usa la segmentazione tramite VPN/VRF, trasportata end-to-end in OMP, non ACL localizzate.
- Scenario: un’app SaaS soffre latenza per il backhaul verso il data center. → Attiva Cloud OnRamp for SaaS, non una semplice route statica DIA: serve la misura dinamica dei path.
- Scenario: distinguono SD-WAN da VPN. → La discriminante è Application-Aware Routing basato su SLA (loss/latency/jitter) e visibilità centralizzata, non la sola cifratura IPsec (presente in entrambe).