Cisco 300-415: Architettura e Piani della Fabric Cisco SD-WAN — Guida allo studio

By Laurynas Brazys · 13 August 2026 · #cisco #300-415 #certification #exam-prep #study-guide

Fa parte della Cisco SD-WAN 300-415 ENSDWI — Guida allo studio. Esercitati con risposte verificate nel centro esami Cisco, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Cisco SD-WAN è una fabric intent-based costruita da componenti e piani distinti che separano le funzioni di gestione, orchestrazione, controllo e dati. L’architettura si adatta da poche filiali a migliaia, indipendentemente dal trasporto underlay, mantenendo al contempo controllo deterministico e sicurezza. Questa sezione spiega i ruoli di vManage, vSmart, vBond e WAN Edge; i piani e i protocolli che li interconnettono; le scelte di piattaforma; l’indirizzamento e la segmentazione; i modelli di topologia dell’overlay; i concetti di multitenancy e raggruppamento; e i principali compromessi di progettazione e le modalità di guasto da considerare.

Componenti e Piani della Fabric

• WAN Edge: Il router del piano dati presso la filiale, il campus, la colocation o l’edge del cloud. Forma tunnel dati sicuri, esegue le policy, utilizza BFD per verificare l’attività dei percorsi, scambia le rotte OMP con i controller e inoltra il traffico utente.
• vSmart Controller: Il cervello del piano di controllo. Costruisce e mantiene la topologia dell’overlay, distribuisce informazioni su rotte e policy tramite OMP e orchestra la connettività dei WAN Edge e la distribuzione delle chiavi crittografiche per abilitare il peering IPsec sicuro tra gli edge.
• vBond Orchestrator: Il primo punto di contatto per i nuovi dispositivi. Autentica l’identità dei dispositivi, assiste nell’attraversamento del NAT e coordina la connessione di ogni WAN Edge a vSmart. Mantiene connessioni persistenti con i controller vSmart e tipicamente risiede in uno spazio di indirizzi IP pubblici raggiungibile per un onboarding universale.
• vManage: Il piano di gestione e orchestrazione (NMS). Fornisce l’input degli intent, i template di configurazione, la gestione delle immagini, la telemetria, l’automazione di Cloud OnRamp e le API. vManage non partecipa al piano di controllo dell’inoltro.

Piani e protocolli:

• Piano di gestione: vManage utilizza canali sicuri (NETCONF/gRPC su TLS) per monitorare e configurare dispositivi e controller.
• Piano di orchestrazione: vBond utilizza DTLS/TLS per autenticare i dispositivi, condividere la raggiungibilità dei controller e attraversare il NAT. Con i certificati dei controller e nessuna porta alternativa configurata, vBond rimane in ascolto su UDP/TCP 12346.
• Piano di controllo: vSmart utilizza OMP per scambiare prefissi, TLOC e policy con i dispositivi WAN Edge. Le connessioni di controllo utilizzano DTLS di default; anche TLS è supportato e comunemente richiesto in presenza di firewall restrittivi o regimi di conformità.
• Piano dati: I dispositivi WAN Edge costruiscono tunnel IPsec (o GRE, dove appropriato) tra i TLOC per il trasporto crittografato, con probing BFD per ogni tunnel per il rilevamento dei guasti in frazioni di secondo e il routing application-aware.

Ciclo di vita all’ingresso:

1. Il WAN Edge contatta vBond, si autentica e riceve le liste dei controller.
2. Il WAN Edge stabilisce sessioni di controllo DTLS/TLS verso vSmart (e verso vManage per la gestione).
3. vSmart distribuisce le informazioni sulle chiavi crittografiche; il WAN Edge forma quindi tunnel IPsec con altri WAN Edge come richiesto dalla policy e dalla topologia.

Implicazioni sulla resilienza:

• La perdita di vManage influisce solo sulla configurazione e sulla visibilità; l’inoltro dei dati continua.
• La perdita di vBond influisce sull’onboarding di nuovi dispositivi; i dispositivi esistenti non ne risentono.
• La perdita di tutti i controller vSmart isola il piano di controllo; i tunnel dati persistono ma le modifiche a rotte/policy si interrompono e uno stato di controllo obsoleto può degradare le operazioni nel tempo.
• Il failover dei percorsi guidato da BFD e i TLOC multipli forniscono continuità al piano dati durante le interruzioni dell’underlay o del trasporto.

Identità, Indirizzamento e Segmentazione

Identità e indirizzamento sono incentrati sull’overlay:

• Organization name: Una stringa a livello di fabric che deve corrispondere su tutti i dispositivi e controller; una mancata corrispondenza impedisce l’adiacenza del piano di controllo.
• System IP: Un identificatore univoco a 32 bit per dispositivo, simile a un’interfaccia di loopback, utilizzato nelle tuple TLOC e nell’indirizzamento del piano di controllo. Non è legato a nessuna interfaccia fisica.
• Site ID: Un identificatore numerico che raggruppa i dispositivi in una sede. Di default, i dispositivi che condividono lo stesso site ID non formano tunnel dati diretti per evitare hairpinning e loop all’interno di una sede.
• Certificati: Dispositivi e controller utilizzano identità X.509. I WAN Edge hardware sfruttano la secure device identity (SUDI) per il provisioning zero-touch; tutti i dispositivi devono essere registrati e autorizzati in vManage prima di unirsi alla fabric.

VPN chiave:

• VPN 0 (Transport): Trasporta la connettività di trasporto underlay e le interfacce TLOC verso MPLS, DIA, banda larga o LTE. NAT, DHCP, PPPoE e le rotte statiche/di default terminano qui. TLOC = {system IP, color, encapsulation} dove il ‘color’ caratterizza il trasporto (ad esempio, mpls, biz-internet, public-internet) e l’incapsulamento è IPsec o GRE.
• VPN 512 (Management): Gestione out-of-band dei dispositivi e raggiungibilità dei controller. Su IOS XE SD-WAN, questa corrisponde a una VRF di gestione; su vEdge è esplicitamente la VPN 512. Controller e WAN Edge stabiliscono sessioni di gestione utilizzando protocolli protetti da TLS.
• Service VPN (1–511 eccetto 512): Trasportano i servizi utente e possono eseguire OSPF, EIGRP, BGP, routing statico o bridging. Le policy (centralizzate e localizzate) indirizzano i flussi inter-VPN e intra-VPN, la QoS e la sicurezza.

Elementi di configurazione di base utili:

sdwan
 system-ip 10.255.0.11
 site-id 101
 organization-name ACME-Global

Modalità di guasto a cui prestare attenzione:

• System IP o site ID duplicati creano anomalie di controllo o una soppressione indesiderata dei tunnel.
• La mancata corrispondenza dell’organization-name impedisce le adiacenze OMP.
• La scadenza o la revoca di un certificato interrompe la fiducia (trust) del controller o del dispositivo.
• Una rotta di default di gestione mal posizionata nella VPN 512 isola un dispositivo dai controller; una rotta di default di trasporto mal posizionata nella VPN 0 isola i TLOC.

Piattaforme, modelli di deployment e progettazione dei controller

Piattaforme WAN Edge:

• Cisco IOS XE SD-WAN: Supportato sulle piattaforme ISR 4000 Series e ASR 1000 Series (e sulla famiglia Catalyst 8000). Preferire IOS XE SD-WAN per una velocità di sviluppo delle funzionalità a lungo termine e per servizi di filiale unificati.
• vEdge: Piattaforme hardware/virtuali precedenti basate su Viptela, ancora supportate in molte implementazioni; la pianificazione della migrazione dovrebbe considerare le lacune funzionali e le tempistiche del ciclo di vita.
• Virtual WAN Edge: Eseguito su hypervisor e server, inclusi Cisco UCS e Cisco ENCS 5000 Series, e nei cloud pubblici (AWS, Azure, GCP). Utilizzare Cloud OnRamp per automatizzare i deployment IaaS; i prerequisiti includono la sottoscrizione all’immagine del marketplace del cloud (ad esempio, AWS AMI) e la preparazione di un template di dispositivo in vManage.

Indipendenza dall’underlay e diversità di trasporto:

• Ogni TLOC si lega a un trasporto con un colore associato; la policy può preferire, bilanciare o escludere i trasporti in base all’applicazione, all’SLA o al ruolo del sito.
• IPsec è l’impostazione predefinita per gli underlay non attendibili; GRE può essere utilizzato su MPLS privato dove la crittografia non è necessaria o è soggetta a vincoli.
• BFD fornisce metriche di vitalità e SLA per tunnel (perdita, latenza, jitter) per guidare il routing basato sulle applicazioni (application-aware routing).

Clustering dei controller, scalabilità, alta disponibilità e posizionamento:

• vManage: Effettuare il deployment come un cluster di tre o più nodi per HA e resilienza; posizionarlo insieme a uno storage ad alto throughput per la telemetria e il repository delle immagini. Eseguire backup frequenti.
• vSmart: Effettuare il deployment di più controller attraverso domini di errore e aree geografiche; tutti i WAN Edge stabiliscono sessioni di controllo con più di un vSmart. Le istanze di vSmart scalano orizzontalmente; pianificare una capacità N+1 per sostenere la perdita di un controller.
• vBond: Effettuare il deployment di almeno due orchestrator in uno spazio di indirizzi pubblico (o con NAT statico e mappatura delle porte coerente). vBond mantiene sessioni permanenti con vSmart e sessioni transitorie con i WAN Edge durante l’onboarding.
• Posizionamento: I controller possono essere ospitati nei propri data center o nel cloud pubblico. Assicurare una raggiungibilità in entrata deterministica da Internet per vBond e un’uscita sufficiente per i WAN Edge. Se i middlebox richiedono eccezioni per l’ispezione TLS, preferire le sessioni di controllo TLS rispetto a DTLS.

Note operative:

• Il trasporto predefinito del control-plane è DTLS; passare a TLS quando si attraversano firewall restrittivi o domini di conformità che consentono solo il controllo crittografato basato su TCP. Assicurarsi che le porte appropriate siano permesse end-to-end.
• Quando un WAN Edge si unisce alla rete, stabilisce sessioni DTLS/TLS con vSmart e tunnel IPsec con gli edge peer in base alla raggiungibilità OMP e alla policy. Assicurare i keepalive NAT e i pinhole UDP sui circuiti a banda larga per evitare cadute silenziose dei tunnel.

Topologie Overlay, Multitenancy e Compromessi di Progettazione

I pattern di topologia sono realizzati tramite policy di controllo centralizzate (advertisement di rotte e TLOC) e policy dei dati localizzate:

• Full mesh: Latenza più bassa tra tutti i siti; resilienza eccellente; carico di scalabilità più elevato sul piano di controllo e sul piano dati a causa delle numerose sessioni IPsec/BFD.
• Hub-and-spoke: Scalabilità semplice con un minor numero di tunnel; l’hub diventa un collo di bottiglia per la larghezza di banda e la resilienza senza un design a doppio hub; latenza di percorso più elevata per il traffico spoke-to-spoke.
• Hub regionale: Bilancia latenza e scalabilità limitando i full mesh a livello regionale e utilizzando gli hub per il backhauling interregionale; richiede policy attente per prevenire il tromboning.
• Doppio hub (attivo/attivo o attivo/standby): Migliora la resilienza e può distribuire il carico; aumenta la complessità del controllo (ECMP, tie-breaking, prevenzione dei loop) e consuma più risorse degli hub.

Multitenancy e raggruppamento:

• Vera multitenancy: I service provider possono abilitare la modalità multi-tenant sui controller per ospitare più organizzazioni logiche con piani di controllo, amministratori e policy isolati sullo stesso cluster di controller.
• Segmentazione per tenant o business unit: Utilizzare le service VPN per imporre la separazione del traffico, il route-leaking dove necessario e policy/QoS per singola VPN.
• Raggruppamento dei dispositivi: Utilizzare gruppi di dispositivi, elenchi di siti, elenchi di VPN ed elenchi di prefissi/TLOC in vManage per applicare policy, aggiornamenti e template in base a funzione, regione o ruolo.

Compromessi di progettazione:

• Latenza vs controllo delle policy: Il full mesh minimizza la latenza ma complica l’applicazione e l’osservazione delle policy; l’hub-and-spoke semplifica il controllo ma aggiunge latenza per i flussi est-ovest.
• Resilienza vs scalabilità operativa: Un maggior numero di TLOC, trasporti e hub aumenta la disponibilità e la scelta dei percorsi, ma moltiplica le sessioni IPsec/BFD e la scala del controllo. Utilizzare la regionalizzazione e la sumarizzazione per tenere sotto controllo le dimensioni di OMP e FIB.
• Diversità dell’underlay vs costo: L’aggiunta di banda larga e LTE migliora la raggiungibilità e la resistenza ai brownout; i costi, il comportamento del NAT e il jitter variabile possono complicare gli SLA. Utilizzare classi di SLA derivate da BFD e routing application-aware per vincolare il traffico sensibile.
• Ricchezza delle policy centralizzate vs opacità nel troubleshooting: Catene complesse di match/action forniscono un controllo granulare ma possono oscurare la logica di inoltro. Mantenere le policy modulari, versionate e ben documentate; testarle in una fabric di staging.
• Sicurezza vs prestazioni: L’IPsec obbligatorio su tutti i trasporti rafforza la confidenzialità ma introduce overhead sulla CPU e considerazioni su MTU/frammentazione. Preferire l’accelerazione crittografica hardware e un tuning coerente di MSS/PMTUD.

Modalità di guasto comuni e mitigazioni:

• Policy asimmetrica che impedisce la formazione del tunnel: Validare simmetricamente le policy di TLOC e di controllo; confermare le rotte TLOC in OMP.
• Scadenza dei pinhole NAT su UDP: Preferire il controllo tramite TLS o configurare i keepalive NAT; considerare il NAT statico per i controller.
• Uso improprio dei Site ID che causa il collasso dei tunnel intra-sito: Assicurare Site ID univoci per ogni sede fisica; utilizzare policy BFD color-restrict per l’intento intra-campus invece di forzare l’unione dei siti.
• Hub con risorse insufficienti per gli spoke: Monitorare la CPU/crypto degli hub e il numero di sessioni BFD; scalare orizzontalmente gli hub o introdurre hub regionali; utilizzare QoS e policer per proteggere il traffico di controllo.

Scenario Pratico

Apex Manufacturing si sta espandendo in AWS e gestisce 600 filiali globali su doppi trasporti (MPLS e DIA). Ha la necessità di estendere l’SD-WAN in AWS con una latenza minima verso le applicazioni regionali, mantenere la conformità utilizzando TLS per il controllo e garantire l’alta disponibilità (HA) dei controller.

1. Posizionare due orchestrator vBond nello spazio di indirizzi IP pubblici e tre controller vSmart distribuiti su due cloud.

• Logica: vBond deve essere raggiungibile pubblicamente per assistere nel NAT traversal; più istanze di vSmart forniscono HA del piano di controllo e prossimità geografica. vBond mantiene sessioni permanenti con vSmart e sessioni transitorie con i WAN Edge, accelerando l’onboarding e il riaggancio.

2. Convertire tutte le connessioni di controllo a TLS e permettere il traffico TCP sulla porta 12346 attraverso i firewall aziendali.

• Logica: Il DTLS di default potrebbe essere bloccato da middlebox restrittivi. TLS assicura la raggiungibilità del piano di controllo attraverso proxy TCP e domini di ispezione senza sacrificare la crittografia o l’integrità.

3. Distribuire vManage come un cluster a tre nodi in una regione cloud centrale, con backup giornalieri.

• Logica: Il piano di gestione deve rimanere disponibile per le operazioni relative a policy, immagini e telemetria. Il clustering preserva lo stato e scala l’accesso via API/GUI; i backup proteggono dalla perdita di dati operativi.

4. Utilizzare Cloud OnRamp for IaaS per istanziare router WAN Edge virtuali in AWS, uno per VPC, in subnet collegate a un transit gateway.

• Logica: Cloud OnRamp automatizza la sottoscrizione dell’AMI, il deployment e la registrazione dei certificati. I dispositivi WAN Edge terminano i TLOC SD-WAN e pubblicizzano le rotte dei VPC tramite OMP, integrando i carichi di lavoro cloud nella fabric con lo stesso set di policy.

5. Assegnare IP di sistema da un blocco overlay riservato e Site ID univoci per ogni regione cloud (es. 9001–9010), e impostare un nome dell’organizzazione coerente in tutta la fabric.

• Logica: IP di sistema e Site ID univoci prevengono la soppressione dei tunnel e l’ambiguità nel piano di controllo. L’uniformità del nome dell’organizzazione è obbligatoria per le adiacenze OMP e la fiducia nei certificati.

6. Configurare la VPN 0 per i doppi trasporti negli edge AWS (internet pubblico e, quando disponibile, Direct Connect tramite un color privato) e abilitare BFD con classi di SLA per il routing application-aware.

• Logica: La diversità dei trasporti migliora la raggiungibilità e la resistenza ai brownout. BFD fornisce metriche di perdita/latenza/jitter per indirizzare il traffico applicativo verso il TLOC con le migliori prestazioni in base allo SLA.

7. Esporre la VPN 512 solo alle subnet di gestione e limitare il routing verso i controller tramite rotte statiche esplicite e ACL.

• Logica: Minimizza la superficie di attacco sul piano di gestione ed evita leak di rotte che potrebbero isolare i dispositivi o sovraesporre i servizi dei controller.

8. Implementare una topologia a hub regionali utilizzando gli edge AWS come hub per le rispettive regioni, con doppi hub on-premise per continente per il failover, e abilitare percorsi diretti internet spoke-to-spoke per il traffico sensibile alla latenza.

• Logica: Gli hub regionali localizzano i flussi per ridurre la latenza e contenere la scala del controllo; i doppi hub forniscono ridondanza. I tunnel diretti spoke-to-spoke controllati preservano la bassa latenza per le app in tempo reale senza sovraccaricare gli hub.

9. Applicare policy di controllo centralizzate per sumarizzare le rotte delle filiali presso gli hub regionali, limitare gli advertisement dei TLOC alle regioni previste e imporre la segmentazione con service VPN per il traffico di produzione, OT e guest.

• Logica: La sumarizzazione riduce il churn delle rotte OMP e l’utilizzo della memoria. Gli advertisement dei TLOC con ambito limitato prevengono la formazione involontaria di tunnel interregionali. La segmentazione basata su VPN mantiene i confini di conformità, con route-leaking esplicito solo dove richiesto.

10. Monitorare lo stato di salute di BFD e del piano di controllo; impostare allarmi per la perdita di un vSmart o vBond e pre-provisionare capacità N+1.

• Logica: Il rilevamento precoce del degrado del controllo previene un’instabilità diffusa. La capacità N+1 assicura che la fabric possa sostenere il guasto di un controller senza esaurimento delle sessioni, proteggendo sia la convergenza del piano di controllo sia la resilienza del piano dati.

Tutti i domini · Onboarding dei controller →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →