Cisco 300-415: Onboarding dei controller, Certificati e Connettività di controllo sicura — 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 utilizza un piano di controllo basato su certificati per integrare in modo sicuro i controller e i dispositivi WAN Edge, attraversare i confini NAT e mantenere connessioni di controllo crittografate. Una corretta progettazione del ruolo di orchestratore del vBond, del ciclo di vita dei certificati, dell’inventario dei dispositivi e della strategia NAT garantisce un’integrazione prevedibile e un controllo resiliente. I team operativi devono essere in grado di riconoscere gli stati delle connessioni di controllo e gli allarmi e disporre di un piano di ripristino per guasti ai certificati o alla connettività.

Orchestrazione e Connettività di Controllo Sicura

L’orchestratore vBond è il primo punto di contatto del piano di controllo per ogni WAN Edge. Svolge tre funzioni critiche:

• Ammissione e controllo dell’identità: valida l’identità del dispositivo (seriale/chassis rispetto all’elenco autorizzato) e impone la corrispondenza del nome dell’organizzazione (organization-name).
• Scoperta NAT e rendezvous: apprende la tupla indirizzo-porta pubblica/privata e il tipo di NAT di ciascun peer, quindi informa entrambe le parti affinché possano stabilire connessioni di controllo dirette.
• Scambio di connettività iniziale: fornisce al WAN Edge gli indirizzi raggiungibili dei controller vSmart e vManage in modo che possa costruire canali di controllo persistenti.

Proprietà e comportamenti chiave:

• Raggiungibilità tramite IP pubblico: il vBond deve risiedere su un IP pubblico (preferibile) o dietro un NAT statico 1:1 con mappature in entrata coerenti. Ciò garantisce che possa essere raggiunto da dispositivi in ambienti NAT sconosciuti o restrittivi.
• Peering persistente con i controller: il vBond mantiene connessioni permanenti con i controller vSmart in modo da avere sempre informazioni di rendezvous aggiornate.
• Non nel percorso dati (data path): Dopo aver facilitato lo scambio iniziale, il vBond esce dal flusso; il controllo continuo avviene direttamente tra i WAN Edge e vSmart/vManage.

Trasporto e porte DTLS/TLS:

• Il protocollo predefinito per le connessioni del piano di controllo è DTLS su UDP 12346. TLS su TCP 23456 è disponibile e spesso preferito nei data center dove l’ispezione/proxy TCP è standard.
• Il vBond utilizza la porta 12346 per impostazione predefinita quando vengono usati i certificati dei controller e non è configurata una porta alternativa.
• Consentire il traffico in uscita e di ritorno per:
  • UDP 12346 (piano di controllo DTLS)
  • TCP 23456 (piano di controllo TLS)
• Il NAT-T IPsec del piano dati (data-plane) utilizza UDP 4500 ed è indipendente dalle scelte del piano di controllo.

Considerazioni sul NAT:

• I NAT full-cone e restricted di solito funzionano con il DTLS hole punching; il NAT simmetrico è il più problematico. Se entrambe le estremità sono dietro NAT simmetrico, utilizzare TLS (TCP 23456), modificare la policy in uscita per preservare le mappature delle porte, o assicurarsi che una delle parti abbia un NAT pubblico/restricted.
• Il vBond dietro NAT richiede una mappatura statica 1:1 per la porta 12346/UDP (e 23456/TCP se si usa TLS). Il PAT dinamico sul vBond non è supportato.
• Binding NAT obsoleti possono causare la caduta dei tunnel di controllo. Ottimizzare i keepalive e garantire interfacce di uscita coerenti nella VPN 0.

Suggerimenti di progettazione:

• Posizionare almeno due istanze di vBond in regioni pubbliche distinte per la resilienza.
• Preferire TLS in ambienti con controlli di uscita rigidi o throttling UDP pervasivo; garantire una postura coerente tra controller e WAN Edge.

Identità, Certificati e Validazione dell’Organizzazione

Tutti i controller e i dispositivi WAN Edge devono presentare certificati che si concatenano alla stessa root attendibile (trusted root), e l’organization-name deve corrispondere in tutto l’overlay.

Ruoli e origini dei certificati:

• Controller (vManage, vSmart, vBond): Richiedere e installare i certificati dei controller firmati dalla root scelta (CA aziendale o CA pubblica). vManage ne orchestra il ciclo di vita.
• Identità del WAN Edge:
  • Hardware vEdge: viene fornito con un certificato installato di fabbrica.
  • IOS XE SD-WAN (cEdge): utilizza Cisco SUDI per l’identità PnP; ottiene quindi un certificato di controller firmato dalla stessa root utilizzata dai controller.
• Controller ospitati su cloud: Forniti con certificati firmati dal provider e una catena di fiducia (trust chain) nota. I WAN Edge devono avere fiducia in questa catena; ancore di fiducia (trust anchor) non corrispondenti richiedono la riemissione dei certificati di controllo dei dispositivi per allinearli con la CA del cloud.

Fasi del ciclo di vita:

• Registrazione (Enrollment): Le CSR dei controller vengono generate in vManage e firmate dalla CA selezionata; i WAN Edge si registrano automaticamente durante ZTP/PnP o tramite bootstrap manuale.
• Validazione: Durante l’handshake, i peer convalidano la catena di certificati, la scadenza, lo stato di revoca (se configurato) e l’organization-name.
• Rinnovo e revoca: vManage monitora la scadenza e può effettuare il rinnovo. I dispositivi compromessi o ritirati dovrebbero avere i certificati revocati; rimuoverli dall’elenco dei seriali autorizzati per impedirne il reinserimento.

Errori di validazione comuni:

• Mancata corrispondenza dell’organization-name: Le connessioni di controllo falliscono; lo stato indica una mancata corrispondenza dell’organizzazione o un certificato non verificato.
• Catene di fiducia miste: Controller e edge firmati da root diverse non possono stabilire sessioni di controllo.
• Disallineamento temporale (Time skew): I certificati risultano non ancora validi o scaduti; l’NTP nella VPN 0 è obbligatorio.
• Problemi di FQDN/SAN (TLS): Se TLS è imposto e la validazione FQDN è abilitata, le mancate corrispondenze di SAN/CN causeranno il fallimento della connessione.

Onboarding dei dispositivi, PnP/ZTP e controlli di inventario

L’onboarding è la combinazione di convalida dell’identità del dispositivo, provisioning zero-touch e connettività di controllo automatica basata su certificati.

Inventario e autorizzazione:

• Elenco seriali autorizzati: vManage memorizza l’elenco dei dispositivi WAN Edge autorizzati. Popolare tramite la sincronizzazione dello Smart Account o caricando manualmente il file dei numeri di serie autorizzati in vManage quando la sincronizzazione dello Smart Account non è utilizzata.
• Numero di serie vs. numero di telaio: Entrambi sono usati per identificare univocamente e prevenire lo spoofing. I token per vEdge potrebbero essere necessari durante l’onboarding manuale.

Flussi zero-touch:

• ZTP per vEdge: Il dispositivo utilizza un profilo di fabbrica per raggiungere il servizio ZTP, apprende l’orchestrator vBond e avvia una connessione DTLS/TLS verso vBond per il controllo dell’identità e il rendezvous. Successivamente, stabilisce connessioni di controllo abilitate per OMP con vSmart e connettività di gestione verso vManage.
• PnP per IOS XE SD-WAN (cEdge): Il dispositivo utilizza SUDI per autenticarsi con Cisco Plug and Play tramite HTTPS, che restituisce le informazioni di raggiungibilità del controller. In alternativa, è possibile utilizzare il PnP on-premise tramite l’opzione 43 del DHCP/DNS o un bootstrap USB day-0. Dopo l’ammissione da parte di vBond, il dispositivo viene reindirizzato a vManage per l’associazione del template.
• Una volta attive le connessioni di controllo, vManage invia i template e vSmart avvia il peering OMP per distribuire rotte, policy e chiavi crittografiche.

Checkpoint operativi:

• Assicurarsi che l’organization-name nella configurazione di sistema corrisponda esattamente a quello dell’overlay.
• Verificare il routing IP della VPN 0, il DNS (se si utilizzano FQDN) e l’NTP.
• Aprire le porte necessarie verso vBond/vSmart/vManage e consentire i flussi di ritorno.

Una designazione minima di vBond sull’orchestrator:

system
 vbond 203.0.113.10 local
 organization MyCompany

Operazioni: Stati, Allarmi, Verifica e Ripristino

Stati delle connessioni di controllo e allarmi:

• Stati tipici: down, connecting/handshake, authenticated, up. I fallimenti possono mostrare errori di certificato, discrepanza dell’organizzazione, nessuna risposta o fallimento del NAT.
• Gli allarmi comuni di vManage includono: Control Connection Down, OMP Peer Down, Certificate Expiring/Expired, Device Not in Authorized List e Organization Mismatch.

Comandi di verifica (IOS XE SD-WAN):

show sdwan control connections
show sdwan control local-properties
show sdwan omp peers
show sdwan certificate status
show sdwan software

Comandi di verifica (vEdge):

show control connections
show control local-properties
show omp peers
show certificate installed

Flusso di lavoro per troubleshooting e ripristino:

• Identità e org-name:
  • Confermare che il dispositivo appaia nell’inventario di vManage con il seriale/chassis corretto.
  • Verificare il system organization-name su tutti i nodi.
• Orario e trust:
  • Assicurare la raggiungibilità di NTP nella VPN 0; ricontrollare le date di validità dei certificati.
  • Validare la catena di certificati sui controller e sugli edge; riemettere se le root differiscono.
• Connettività e NAT:
  • Confermare la raggiungibilità di vBond su UDP 12346 e TCP 23456 dall’egress del WAN Edge.
  • Se il NAT simmetrico impedisce DTLS, forzare TLS o modificare la policy di egress per fissare i mapping in uscita.
• Re-enrollment e rinnovo:
  • Se il certificato di un dispositivo è corrotto/scaduto, revocarlo in vManage, rimuoverlo dalla lista autorizzata, riaggiungerlo e avviare il re-enrollment (PnP/ZTP o installazione manuale).
  • Per le migrazioni ospitate in cloud, allineare i trust anchor riemettendo i certificati dei controller e dei WAN Edge verso la CA del cloud, quindi riavviare le connessioni di controllo.
• Igiene operativa:
  • Mantenere i cluster di controller in buono stato (es. cluster vManage per la scalabilità).
  • Mantenere un DNS coerente per l’indirizzamento dei controller basato su FQDN; aggiornare i SAN in caso di ridenominazione o cambio IP dei controller.

Compromessi tra NAT e porte:

• DTLS (UDP) offre un overhead inferiore e spesso prestazioni migliori, ma è sensibile al rate-limiting su UDP e al NAT simmetrico. TLS (TCP) facilita l’attraversamento di firewall restrittivi a scapito di un potenziale head-of-line blocking.
• vBond deve rimanere altamente raggiungibile; compromettere la sua raggiungibilità pubblica o i mapping in ingresso è una causa frequente di fallimenti nell’onboarding.

Scenario Pratico

Acme Retail Corp. sta effettuando l’onboarding di 600 filiali, molte delle quali dietro NAT simmetrici gestiti dall’ISP, su una nuova fabric Cisco SD-WAN. I primi progetti pilota mostrano una creazione intermittente del control-plane e frequenti fallimenti di DTLS.

Approccio:

1. Distribuire orchestrator vBond pubblici ridondanti

   • Motivazione: Posizionare due istanze di vBond su IP pubblici distinti (in region/ISP separati) massimizza la raggiungibilità iniziale e accelera la scoperta del NAT. L’indirizzamento pubblico evita l’ambiguità introdotta dai NAT del provider e supporta un traffico di ritorno prevedibile.

2. Imporre TLS per il control-plane nelle regioni con forte presenza di NAT

   • Motivazione: Le filiali con NAT simmetrici hanno difficoltà con l’UDP hole punching. TLS su TCP 23456 fornisce un attraversamento stabile attraverso firewall stateful e CGN dell’ISP, riducendo i flap legati a DTLS senza impattare OMP o la distribuzione delle chiavi.

3. Standardizzare l’organization-name e i trust anchor dei controller

   • Motivazione: Allineare tutti i controller e i WAN Edge alla stessa root CA (la PKI aziendale scelta da Acme). Configurare il system organization-name in modo identico su vManage, vSmart, vBond e su tutti i template dei dispositivi per prevenire rifiuti dovuti a org-mismatch.

4. Precaricare la lista dei seriali autorizzati in vManage e automatizzare PnP/ZTP

   • Motivazione: Importare l’inventario completo dei dispositivi tramite la sincronizzazione dello Smart Account per garantire che ogni dispositivo superi i controlli di identità su vBond. Per i cEdge, usare Cisco PnP con SUDI; per l’hardware vEdge, assicurarsi che token e seriali siano presenti. Questo elimina gli errori manuali e accelera l’attivazione.

5. Rafforzare la raggiungibilità e la sincronizzazione dell’orario nella VPN 0

   • Motivazione: Definire route di default/DNS coerenti nella VPN 0 e puntare NTP a server pubblici o aziendali raggiungibili da ogni filiale. Un orario corretto previene errori di certificato “not yet valid/expired” che bloccano gli handshake TLS.

6. Normalizzare le regole del firewall e il comportamento del NAT

   • Motivazione: Pubblicare una policy di egress per le filiali che consenta il traffico in uscita su TCP 23456 e UDP 12346 verso gli IP di vBond/vSmart/vManage con mapping di lunga durata. Laddove l’ISP impone un NAT simmetrico, garantire che almeno un percorso verso i controller supporti l’attraversamento TCP.

7. Strumentare le operazioni con verifiche e allarmi mirati

   • Motivazione: Incorporare i controlli show sdwan control connections e show sdwan certificate status nello script del Day-1. In vManage, sottoscrivere gli allarmi Control Connection Down e Certificate Expiring. Questo fa emergere rapidamente i siti mal configurati e segnala i rinnovi prima della scadenza.

8. Stabilire un runbook di ripristino per guasti di certificato o connettività

   • Motivazione: Definire i passaggi per revocare/riemettere i certificati dei dispositivi in vManage, ricaricare i seriali se necessario e alternare tra DTLS/TLS come mitigazione. Includere procedure per la rotazione dei certificati dei controller senza impatto sul servizio e per il failover tra le istanze di vBond. Questo minimizza il MTTR durante i rollout di picco.

Combinando vBond raggiungibili pubblicamente, un control-plane TLS dove il NAT è restrittivo, una gestione rigorosa dell’identità e misure di protezione operative, Acme Retail ottiene un onboarding deterministico su larga scala, preservando al contempo la sicurezza e la resilienza del control-plane SD-WAN.

← Architettura e Piani della Fabric Cisco SD-WAN · Tutti i domini · OMP →

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