Cisco 300-415: Operatività, Monitoraggio e Risoluzione dei problemi — 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

Le operazioni, il monitoraggio e la risoluzione dei problemi in Cisco SD-WAN si concentrano su Cisco SD-WAN Manager (precedentemente vManage), il livello dei controller (l’orchestratore vBond e i controller vSmart), i router WAN Edge (ad es. le serie ISR 4000 e ASR 1000 con IOS XE SD-WAN) e gli overlay di dati e di controllo che essi formano. Il piano di controllo, gestito da vSmart, costruisce e mantiene la topologia e le policy tramite OMP e distribuisce le chiavi crittografiche tra gli edge. I dispositivi WAN Edge formano connessioni di controllo DTLS per impostazione predefinita (o TLS se richiesto), coordinano la connettività iniziale tramite vBond (che deve essere raggiungibile nello spazio di indirizzi IP pubblici per il NAT traversal) e stabiliscono tunnel IPsec per il piano dati. Una solida igiene operativa si avvale di telemetria avanzata, runbook definiti, controllo delle modifiche e API automatizzate per garantire il rispetto degli SLA e ridurre il tempo medio di riparazione (MTTR).

Monitoraggio, Dashboard e Stato di Salute

• Dashboard: Cisco SD-WAN Manager fornisce viste in tempo reale e storiche sullo stato di salute dei siti, lo stato dei dispositivi, le connessioni di controllo, gli SLA dei tunnel, l’esperienza applicativa e la conformità delle policy. I widget predefiniti evidenziano le connessioni di controllo (raggiungibilità di vBond/vSmart/vManage), l’aderenza agli SLA del routing application-aware e l’utilizzo delle interfacce. Le analisi di dettaglio (drill-down) correlano allarmi, eventi e statistiche per dispositivo o per sito.
• Allarmi ed eventi: La piattaforma genera allarmi in caso di modifiche alla raggiungibilità dei controller, stato della sessione OMP, errori dei certificati, riavvii dei dispositivi, mancate corrispondenze delle policy e degrado delle prestazioni (perdita/latenza/jitter oltre i limiti SLA). Gli eventi includono codici dettagliati come DCONFAIL per i fallimenti delle connessioni di controllo e mancate corrispondenze esplicite dell’organization-name durante l’onboarding. Gli allarmi supportano la presa in carico (acknowledgment), la risoluzione (clearance) e l’inoltro (email/SNMP/syslog) a sistemi operativi centralizzati.
• Stato di salute dei dispositivi: I punteggi di salute (health score) combinano indicatori del piano di controllo e del piano dati con l’utilizzo di CPU, memoria, log di crash ed errori delle interfacce. Lo stato di salute dei WAN Edge dovrebbe essere sottoposto a baselining; le soglie devono essere calibrate per evitare l’affaticamento da allarmi (alarm fatigue). La sincronizzazione dell’orario (NTP) è fondamentale; il disallineamento dell’orologio (clock skew) è una causa comune di fallimenti nella validazione dei certificati e di dati di trend fuorvianti.
• vAnalytics e pianificazione della capacità: vAnalytics aggiunge una visibilità approfondita delle applicazioni (classificazione basata su NBAR2 da cflowd), baseline sulla qualità dei percorsi e previsioni sulla capacità. Evidenzia i principali “top talker”, i contributi al tempo di risposta delle applicazioni (rete vs. server) e le finestre di saturazione previste per le interfacce. Per la pianificazione della capacità, utilizzare il throughput al 95° percentile su finestre mobili di 30 giorni e correlarlo con le violazioni degli SLA dei tunnel; valutare dove una larghezza di banda aggiuntiva o aggiustamenti delle policy (QoS/AAR) producano il miglior ritorno in termini di SLA.
• Esperienza applicativa: Le dashboard delle applicazioni collegano i flussi alle prestazioni dei tunnel e al trattamento QoS. Se un’applicazione critica ha prestazioni inferiori su un percorso con jitter in aumento, verificare che il routing application-aware rispetti gli SLA e che le policy di accodamento (queueing) siano allineate con i marcatori DSCP end-to-end.

Telemetria, Syslog, SNMP ed Esportazione cflowd

• Telemetria in streaming: Cisco SD-WAN Manager consuma la telemetria model-driven proveniente da controller ed edge per le metriche di controllo, di interfaccia e di piattaforma. Lo streaming riduce l’overhead del polling e aumenta la granularità rispetto al polling SNMP tradizionale. Per l’analisi esterna, IOS XE SD-WAN supporta la telemetria model-driven di tipo dial-out verso collettori gRPC; dimensionare attentamente i collettori e le frequenze di campionamento per evitare overhead sulle sedi periferiche (branch).
• Syslog: Gli edge e i controller possono esportare i log di sistema (syslog) verso collettori centralizzati. Inoltrare gli eventi significativi (es. riconvergenza del piano di controllo, aggiornamenti delle policy OMP, rinnovo delle chiavi IPsec, crash). Utilizzare syslog strutturati per un migliore parsing. Applicare rate-limiting e filtri per mantenere performanti i collettori.
• SNMP: Utilizzare SNMPv3 per il polling sicuro di interfacce, CPU, memoria e sensori ambientali. Le trap SNMP possono essere abilitate per allarmi chiave (control down, BFD down, CPU alta). SNMP da solo è insufficiente per la telemetria delle applicazioni moderne, ma rimane prezioso per l’integrazione con gli strumenti NMS esistenti.
• cflowd (esportazione di flussi application-aware): Cisco SD-WAN utilizza cflowd (simile a NetFlow/IPFIX) per esportare record per-flusso che includono l’ID dell’applicazione (NBAR2), DSCP, byte/pacchetti, flag TCP e metadati sulle prestazioni come tempo di andata e ritorno (round-trip time), perdita e jitter. L’esportazione può essere indirizzata a Cisco SD-WAN Manager/vAnalytics e a collettori esterni. Bilanciare visibilità e overhead regolando il campionamento, i timeout di attività/inattività e le destinazioni di esportazione. Un’esportazione eccessiva su piattaforme di fascia bassa può influire sulla CPU; preferire l’analisi lato controller quando possibile.

Risoluzione dei problemi di Controllo, OMP, BFD e Tunnel

Un flusso di lavoro coerente restringe rapidamente il dominio di guasto:

1. Stabilire l’ambito e il livello

• Riguarda solo il control-plane, il data-plane o il livello applicativo?
• Utilizzare le dashboard dei siti e dei dispositivi di SD-WAN Manager per vedere se sono interessati più dispositivi, siti o solo un percorso/colore.

2. Convalidare le connessioni di controllo

• vBond deve essere raggiungibile sul suo IP pubblico; per impostazione predefinita, i controller utilizzano la porta 12346 per DTLS/TLS.
• Il trasporto di controllo predefinito è DTLS; molte policy dei data center richiedono TLS verso i controller. Assicurarsi che i middlebox consentano il protocollo selezionato.
• Controllare la sincronizzazione dell’ora e i certificati (catena root, validità, raggiungibilità CRL/OCSP).
• Errori comuni:
  • DCONFAIL: Fallimento generico della connessione di controllo; le cause principali includono la porta 12346 bloccata, il fallimento del NAT traversal, il rifiuto del certificato o il routing verso i controller.
  • Mancata corrispondenza dell’organizzazione: L’org-name incorporato nelle credenziali/configurazione del dispositivo deve corrispondere a quello dei controller; altrimenti le sessioni OMP non verranno stabilite.

3. Verificare OMP e policy

• OMP trasporta route, TLOC e service-chain tra vSmart e gli edge. Confermare l’adiacenza OMP con tutti i nodi vSmart nel cluster per evitare uno stato di controllo asimmetrico.
• Convalidare le route ricevute/annunciate e l’accettazione delle policy. Una policy può inavvertitamente filtrare TLOC o prefissi, causando il blackholing del traffico.
• I TLOC sono definiti da system IP, colore e incapsulamento (GRE o IPsec). Discrepanze di colore o incapsulamento tra peer impediscono la formazione del tunnel su un dato trasporto.

4. Ispezionare BFD e SLA

• BFD monitora perdita, latenza e jitter per ogni tunnel e alimenta l’app-aware routing. Il flapping o un jitter elevato attivano lo steering. Confermare che i timer BFD/classi SLA corrispondano all’intento progettuale. Timer eccessivamente aggressivi su circuiti di bassa qualità portano a failover non necessari.

5. Controllare IPsec/data plane

• Ispezionare le statistiche del tunnel, le SA IPsec, encaps/decaps, replay-drop e PMTU. Problemi di NAT-T e black hole di PMTU sono comuni, specialmente su connessioni a banda larga.
• Convalidare che il QoS shaping sia allineato con la larghezza di banda contrattuale; la sovrascrizione gonfia le letture di perdita/jitter e inganna l’AAR.

Comandi show utili sugli edge IOS XE SD-WAN:

show sdwan control connections
show sdwan omp peers | routes | tlocs
show sdwan bfd sessions
show sdwan ipsec inbound-connections outbound-connections
show platform hardware qfp active datapath utilization
show interfaces counters errors
show clock detail

Compromessi e modalità di guasto:

• TLS vs DTLS: TLS può essere richiesto dalle policy di sicurezza e attraversa meglio i proxy restrittivi; DTLS offre un overhead di handshake inferiore. Scegliere in modo coerente in tutta la fabric.
• Sensibilità di BFD: Timer ridotti migliorano il tempo di reazione ma aumentano l’uso della CPU e i falsi positivi su link instabili.
• Complessità delle policy: Policy centralizzate e ricche possono deviare dall’intento originale; preferire oggetti di policy gerarchici e ben commentati, e simulare prima dell’implementazione.

Gestione del ciclo di vita, conformità e automazione

• Pianificazione dell’aggiornamento software:

  • Sequenza: Aggiornare il cluster SD-WAN Manager, poi vBond, poi vSmart e infine i WAN Edge. Mantenere la compatibilità delle versioni secondo le note di rilascio. I controller devono essere integri (healthy) e sincronizzati prima di intervenire sugli edge.
  • Repository delle immagini: Utilizzare il repository software di SD-WAN Manager per preparare (stage) le immagini. Le immagini dei controller utilizzano comunemente i formati .qcow2 o .ova; gli edge utilizzano pacchetti IOS XE SD-WAN specifici per la piattaforma.
  • Modalità di manutenzione: Mettere il WAN Edge in modalità di manutenzione per drenare il traffico in modo controllato. Il dispositivo ritira le rotte TLOCs/OMP in modo che le sessioni migrino verso percorsi/siti alternativi prima del riavvio, minimizzando l’impatto sull’utente.
  • Rollback: Mantenere pronta un’immagine precedente e collaudata. Se i controlli post-aggiornamento falliscono, effettuare il rollback all’ultima versione funzionante nota (last-known-good). IOS XE SD-WAN supporta installazioni dual-bank e il downgrade pilotato dal controller.
  • Pianificazione: Utilizzare finestre di manutenzione (change window) con controlli preliminari (stato di control/OMP/BFD, CPU/memoria) e controlli post-intervento (SLA delle applicazioni, numero di tunnel, tassi di errore).

• Conformità della configurazione e drift:

  • Lo stato desiderato è definito dai template dei dispositivi. SD-WAN Manager evidenzia il drift (scostamento) tra la configurazione in esecuzione e il template; rimediare con un’operazione di reattach o con flussi di lavoro di accettazione del drift quando giustificato (es. correzione di emergenza via CLI).
  • Gli audit trail registrano chi ha cambiato cosa e quando (con visibilità basata su RBAC). Abbinare a un SIEM esterno tramite syslog/webhook per una cronologia immutabile.
  • Set di regole di conformità: Validare che org-name, schema degli IP di sistema, uso dei color, cifrari IPsec, AAA e NTP siano conformi agli standard.

• Operazioni e reporting basati su API:

  • Le API REST /dataservice espongono endpoint di monitoraggio, configurazione e azione. Automatizzare la generazione di report (trend degli SLA, applicazioni principali), aggiornamenti di massa, onboarding di siti e controlli di conformità.
  • Utilizzare token e account con visibilità basata su RBAC. Implementare flussi di lavoro idempotenti e validazioni preliminari (pre-flight) prima di invocare modifiche su larga scala.

• Triage delle prestazioni:

  • Iniziare con lo SLA del tunnel (perdita, latenza, jitter), poi CPU/memoria del dispositivo, quindi drop/errori delle interfacce e profondità delle code. Correlare con i KPI delle applicazioni da cflowd.
  • Identificare se il degrado è dovuto alla qualità del link, a congestione/QoS o al lato server, confrontando l’esperienza di più siti per la stessa applicazione e percorso.
  • Segnali di capacità: Utilizzo al 95° percentile in aumento, drop di pacchetti nelle code prioritarie e frequenti cambi di percorso da parte di AAR indicano la necessità di modificare le policy o la larghezza di banda.

• Risposta agli incidenti, controllo delle modifiche e RCA:

  • I runbook definiscono le azioni di prima risposta: snapshot degli stati di control/OMP/BFD, raccolta dei log pertinenti/bundle di tech-support e blocco delle modifiche non essenziali.
  • Il controllo delle modifiche (change control) impone la revisione paritaria (peer review) per gli aggiornamenti delle policy e rollout graduali con canary.
  • L’analisi della causa radice (Root-cause analysis) combina eventi del controller (chi/quando), telemetria dei flussi (quale traffico) e metriche del percorso (dove si è verificato il degrado) per isolare il problema. Esempi: mismatch di ORG dopo una modifica di onboarding, un filtro di policy non intenzionale che rimuove un TLOC, un black hole PMTU sulla banda larga dopo una modifica del CPE dell’ISP.

Scenario pratico di un problema

Contoso Health gestisce 150 cliniche connesse tramite SD-WAN a doppio trasporto (color MPLS mpls e color banda larga biz-internet) utilizzando WAN Edge ISR 4000. Dopo una finestra di manutenzione per migrare i controller in un nuovo data center, diversi siti segnalano scarse prestazioni dell’EHR (cartella clinica elettronica) e interruzioni intermittenti.

1. Controllare lo stato del control-plane in SD-WAN Manager

• Motivazione: Se il control-plane è instabile, ne conseguono tutti i sintomi a livello di data-plane e policy. La dashboard mostra molteplici eventi DCONFAIL e mismatch di ORG durante la stessa finestra, indicando incongruenze di onboarding dopo lo spostamento del controller.

2. Validare la raggiungibilità e le porte dei controller

• Motivazione: Il nuovo data center impone TLS verso i controller. Confermare che i middlebox consentano il traffico TLS verso i controller sulla porta di controllo predefinita 12346 e che vBond sia raggiungibile su IP pubblico per il NAT traversal. Una porta bloccata su un firewall regionale spiega i guasti raggruppati per sito.

3. Correggere il disallineamento dell’organization-name

• Motivazione: Gli edge che falliscono l’autenticazione reciproca con i controller a causa di un mismatch dell’org-name non possono formare sessioni OMP. Confrontare l’org-name del template del dispositivo con i certificati del controller; aggiornare i template per farli corrispondere ed eseguire un reattach. Questo ripristina l’adiacenza OMP con vSmart per i siti interessati.

4. Riconciliare l’orario e i certificati

• Motivazione: Lo spostamento del DC ha modificato la raggiungibilità di NTP. Orologi non sincronizzati hanno causato il fallimento di alcune convalide di certificati. Indirizzare tutti gli edge e i controller a server NTP ridondati e verificare la convergenza degli orologi per stabilizzare l’autenticazione e le sessioni di controllo.

5. Verificare le rotte OMP, i TLOC e l’accettazione delle policy

• Motivazione: La migrazione dei controller includeva una ristrutturazione delle policy. Usare i comandi show sdwan omp routes/tlocs e la visualizzazione delle policy per confermare che i prefissi critici e tutti i TLOC siano appresi e non filtrati. Una data-policy con un ordine errato stava scartando il traffico del server EHR; riordinarla ed eseguire il commit per ripristinare la raggiungibilità.

6. Valutare il comportamento di BFD/SLA e AAR

• Motivazione: La lentezza dell’EHR potrebbe riflettere la qualità del percorso. BFD mostra un aumento del jitter sulla banda larga; AAR sta alternando continuamente i percorsi (flapping). Aumentare l’isteresi nella classe SLA e assicurarsi che la QoS dia priorità ai flussi EHR basati su DSCP. Questo riduce i cambi di percorso non necessari.

7. Eseguire un aggiornamento software mirato con la modalità di manutenzione

• Motivazione: Un bug noto nella versione corrente di IOS XE SD-WAN riporta in modo intermittente un jitter errato su biz-internet. Preparare (stage) la correzione raccomandata nel repository software. Mettere un sottoinsieme di edge in modalità di manutenzione, aggiornarli, validare i controlli post-intervento, quindi procedere con il rollout su larga scala. Mantenere pronta l’immagine per il rollback.

8. Automatizzare la verifica e il reporting tramite API

• Motivazione: Utilizzare le API /dataservice per esportare report post-incidente sull’aderenza agli SLA, sulle prestazioni delle applicazioni e sulla stabilità del controllo in tutte le cliniche. L’automazione garantisce una verifica coerente e genera una registrazione verificabile per il controllo delle modifiche.

9. Documentare la RCA e rafforzare i controlli

• Motivazione: Le cause principali erano l’omissione di una regola firewall sulla porta di controllo 12346, un drift dell’org-name nei template e una configurazione errata di NTP, aggravate da un problema di ordinamento delle policy. Aggiornare i runbook di onboarding, imporre una validazione pre-modifica basata su API (raggiungibilità del controller, controlli dell’org-name, stato di NTP) e richiedere simulazioni delle policy prima del commit per prevenire il ripetersi del problema.

← Integrazione Cloud · Tutti i domini

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