Cisco 300-415: Tunnel del piano dati, BFD e Routing consapevole delle applicazioni — 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 separa il piano di controllo dal piano dati e costruisce un overlay crittografato e guidato da policy su trasporti eterogenei. Il controller vSmart gestisce il piano di controllo dell’overlay e la connettività dei WAN Edge, distribuendo rotte, chiavi di sicurezza e intenti tramite OMP. I router WAN Edge formano tunnel sicuri IPsec sul piano dati verso altri WAN Edge, mentre le connessioni di controllo verso vSmart, vBond e vManage utilizzano DTLS di default (o TLS). L’attività e la qualità del percorso sono misurate continuamente con BFD, che alimenta le policy di Application-Aware Routing (AAR) per instradare le applicazioni lungo i tunnel con le migliori prestazioni in base a classi di SLA basate su perdita, latenza, jitter o MOS.

Fondamenti dell’Overlay e del Piano Dati

• Piano di controllo e piano dati a confronto

  • Piano di controllo: i WAN Edge stabiliscono connessioni di controllo sicure DTLS/TLS verso vBond (per l’attraversamento del NAT e l’orchestrazione), vSmart (scambio di policy e rotte tramite OMP) e vManage (gestione, configurazione dei dispositivi e archiviazione dei certificati). Nello stato di staging, i dispositivi formano connessioni di controllo ma non stabiliscono tunnel dati.
  • Piano dati: i WAN Edge formano tunnel IPsec direttamente verso altri WAN Edge per il traffico utente. Il piano dati è responsabile dell’inoltro e applica le decisioni di ingegneria del traffico comunicate tramite le policy del piano di controllo.

• Tunnel IPsec del piano dati e TLOC

  • Un Transport Locator (TLOC) identifica in modo univoco un collegamento a un trasporto WAN ed è definito dalla tupla {system-IP, color, encapsulation}. L’incapsulamento è IPsec o GRE; nella maggior parte delle implementazioni e su IOS XE SD-WAN (cEdge), viene utilizzato IPsec.
  • I “color” sono etichette semantiche per i tipi di underlay e le proprietà NAT (ad esempio, mpls, biz-internet, public-internet, lte, private1–private6). I “color” pubblici implicano tipicamente l’attraversamento del NAT con l’assistenza di vBond.
  • I tunnel si formano tra ogni coppia di TLOC raggiungibili, a meno che non siano limitati. Con due siti, ciascuno con un WAN Edge e due TLOC pubblici, e senza attributi restrict, si formano quattro tunnel IPsec (full mesh tra le coppie di “color”).
  • L’estensione TLOC (TLOC extension) consente a due WAN Edge ridondanti in un sito di condividere i trasporti tramite un collegamento incrociato (cross-link), abilitando la ridondanza del trasporto senza duplicare i circuiti fisici per ogni chassis.

• Etichette di trasporto e di servizio

  • vSmart utilizza OMP per annunciare rotte e TLOC e per allocare etichette trasportate nell’header dell’overlay. Le etichette di trasporto (transport label) identificano i TLOC remoti per il demultiplexing del traffico attraverso l’overlay. Le etichette di servizio (service label) identificano la VPN di servizio di destinazione o un servizio concatenato (chained service). Queste etichette sono interne all’overlay SD-WAN e non sono etichette dell’underlay MPLS.

• Compromessi operativi e modalità di guasto

  • Trasporti con “color” errato (ad esempio, contrassegnare un trasporto MPLS come public-internet) possono causare la formazione di tunnel non ottimali o fallimenti nell’attraversamento del NAT.
  • L’attributo restrict previene una crescita indesiderata della topologia full-mesh; ometterlo sui “color” internet può portare a una scalabilità eccessiva dei tunnel e a un overhead di probing non necessario.
  • Problemi con i certificati o con l’orologio impediscono la connettività del piano di controllo (DTLS/TLS). Senza la convergenza del piano di controllo con vSmart, non vengono scambiate chiavi per il piano dati e i tunnel IPsec non si formano.

Misurazione dell’Attività e della Qualità del Percorso con BFD

• Funzionamento di BFD

  • Cisco SD-WAN esegue BFD su ogni tunnel del piano dati per fornire un rilevamento dell’attività e una misurazione della qualità quasi in tempo reale. BFD utilizza leggeri messaggi “hello” periodici per rilevare lo stato up/down (blackout) e sonde attive (active probe) per misurare latenza, jitter e perdita (brownout).
  • Timer e intervalli chiave
    • Intervallo Hello: comunemente 1000 ms (configurabile per “color” o globalmente).
    • Moltiplicatore: comunemente 6 (configurabile), risultando in un tempo di rilevamento di intervallo-hello × moltiplicatore (ad esempio, ~6 secondi).
    • Intervallo App-probe per il campionamento delle prestazioni AAR: tipicamente 1 secondo (configurabile), con medie mobili calcolate su una breve finestra per smussare i picchi transitori.
  • Misure di BFD
    • Latenza: tempo di andata e ritorno (round-trip time) delle sonde su ogni tunnel.
    • Jitter: variazione nella latenza tra le sonde.
    • Perdita: percentuale di sonde non restituite.
    • MOS: derivato da latenza, jitter e perdita per valutare l’idoneità al traffico voce.

• Gestione di brownout e blackout a confronto

  • Blackout: una sessione BFD down (nessuna connettività) causa la rimozione immediata del percorso dall’inoltro. Il traffico viene spostato secondo la preferenza del successivo tunnel disponibile, senza attendere la valutazione di AAR.
  • Brownout: la sessione BFD rimane attiva, ma le metriche misurate violano le soglie SLA. AAR può instradare flussi di applicazioni specifiche verso tunnel alternativi che soddisfano gli SLA, anche mentre il tunnel originale continua a trasportare altro traffico.

• Linee guida di progettazione e compromessi

  • Timer aggressivi accelerano il failover ma aumentano l’overhead di CPU e banda, specialmente in topologie mesh di grandi dimensioni. Bilanciare gli intervalli di hello e delle sonde in base alla scalabilità e alla stabilità del trasporto.
  • Caratteristiche di percorso asimmetriche (ad esempio, satellitare o cellulare) richiedono soglie SLA meno restrittive e moltiplicatori potenzialmente più alti per evitare il “flapping”.
  • Per applicazioni voce e interattive, preferire intervalli di app-probe più rapidi e abilitare l’isteresi/hold-down per ridurre le oscillazioni durante congestioni transitorie.

Routing Application-Aware: Progettazione di Policy e SLA

• Identificazione e classificazione delle applicazioni

  • I WAN Edge utilizzano la DPI (NBAR2 su IOS XE SD-WAN) per classificare le applicazioni tramite firme, euristiche di protocollo e, dove disponibili, metadati come TLS SNI e QUIC ALPN. Per il traffico crittografato senza metadati identificabili, il motore ripiega sugli attributi del flusso (5-tuple) e sulle mappature configurate (porte, DSCP).
  • La classificazione avviene tipicamente sui primi pacchetti e viene messa in cache per la coerenza della sessione. Mantenere le firme aggiornate per preservare l’accuratezza.

• Classi di SLA e policy di misurazione

  • Definire classi di SLA con soglie per perdita (loss), latenza (latency), jitter e, opzionalmente, MOS. Ogni classe di SLA fa riferimento a un profilo di probe delle prestazioni (app-probe) che determina l’intervallo di campionamento e il comportamento di smorzamento (smoothing) di BFD.
  • Esempi tipici di SLA:
    • Voce (Voice): latenza ≤ 150 ms, jitter ≤ 30 ms, perdita ≤ 1%, MOS ≥ 4.0.
    • Transazionale (Transactional): latenza ≤ 200 ms, perdita ≤ 1%.
    • Massivo (Bulk): nessuno SLA restrittivo; preferire percorsi a banda più larga e costo inferiore.

• Comportamento della preferenza di percorso

  • La policy AAR lega le liste di applicazioni alle classi di SLA e specifica un “preferred-color” e un “backup-color” (o liste di TLOC). La logica decisionale è la seguente:
    1. Se il percorso preferito rispetta lo SLA, inviare il traffico su tale percorso.
    2. Se il percorso preferito viola lo SLA ma quello di backup lo rispetta, indirizzare il traffico verso il backup.
    3. Se nessun percorso rispetta lo SLA, usare il miglior percorso disponibile per preferenza o costo (degrado controllato).
  • L’indirizzamento in condizioni di brownout è per-flusso; i flussi esistenti possono essere spostati a seconda della policy (l’indirizzamento dei nuovi flussi è il comportamento predefinito; lo spostamento a metà flusso può essere limitato per il TCP a meno che non sia progettata una resilienza di sessione).

• Elementi di costruzione della policy

  • Costruire liste di app (gruppi DPI), classi di SLA (perdita/latenza/jitter/MOS) e liste di TLOC (color) in vManage. Quindi, creare una sequenza di policy AAR che mappa lista-app → classe-SLA → color preferiti/di backup.
  • Combinare con le data policy sul traffico se è necessario impostare DSCP, imporre l’uso di zone o inserire il service chaining prima delle decisioni AAR.
  • Usare la control-policy separatamente per influenzare l’accettazione/annuncio delle route; non confondere l’AAR (data-policy) con la control-policy. Le liste di siti (Site list) definiscono l’ambito in cui si applica l’AAR.

• Compromessi di progettazione

  • SLA eccessivamente restrittivi possono causare oscillazioni. Introdurre isteresi o timer di penalità per evitare frequenti cambi di percorso.
  • Considerare i costi: posizionare i percorsi cellulari a consumo solo come backup di ultima istanza; abilitare i limiti di dati (data cap) dove disponibili.
  • Coordinare con la QoS: l’AAR sceglie il percorso; la QoS e l’accodamento (queueing) per singolo percorso devono comunque proteggere le classi critiche durante la congestione.

Verifica e risoluzione dei problemi

• Controlli rapidi dello stato di salute

  • Piano di controllo:
    • cEdge: show sdwan control connections
    • vEdge: show control connections
  • Tunnel del piano dati:
    • cEdge: show sdwan tunnels
    • vEdge: show ipsec outbound-connections / show ipsec inbound-connections
  • Sessioni BFD e qualità:
    • cEdge: show sdwan bfd sessions; show sdwan app-route stats
    • vEdge: show bfd sessions; show app-route stats

• Esempi di comandi

  show sdwan tunnels
  show sdwan bfd sessions
  show sdwan app-route stats sla-class <name>
  show sdwan app-route statistics flows
  show sdwan omp tlocs

  show control connections
  show omp routes | include <prefix>
  show ipsec sa detail

• Cosa cercare

  • Lo stato del tunnel è ‘up’, ma i valori di perdita/latenza/jitter BFD superano l’SLA: degrado delle prestazioni (brownout)—aspettarsi un reindirizzamento da parte di AAR. Verificare che il percorso di backup rispetti l’SLA e che la policy sia associata alla lista di applicazioni corretta.
  • Fluttuazione della sessione BFD: ridurre l’aggressività dei timer o indagare su perdite/accodamenti nell’underlay; verificare MTU e frammentazione (gestione del DF-bit) per evitare la perdita dei probe.
  • Nessun tunnel formato su un colore: verificare la semantica del colore (NAT/pubblico/privato), la configurazione NAT dell’interfaccia e che vBond sia raggiungibile per il NAT traversal. Confermare l’orario e i certificati se le connessioni di controllo sono assenti.
  • Full-mesh e scalabilità dei probe inattesi: applicare ‘restrict’ sui colori internet o usare liste TLOC per limitare la connettività.
  • Classificazione errata da parte di DPI: aggiornare le firme NBAR2 e confermare che non ci siano override di porte L4 in conflitto. Per le applicazioni crittografate, considerare una classificazione basata su SNI/ALPN o il marking DSCP a monte.

• Logica operativa

  • Validare sempre prima la connettività del piano di controllo (vBond per orchestrazione/NAT, vSmart per OMP/policy, vManage per configurazione/certificati). Senza vSmart, le chiavi del piano dati non vengono distribuite e non si forma alcuna IPsec SA.
  • Correlare le decisioni di AAR con le misurazioni BFD e le classi di SLA. Se un percorso viene selezionato in modo contrario alle aspettative, ispezionare lo stato di conformità all’SLA al momento della decisione, non solo le medie attuali.
  • Per design con doppio DC, evitare route LAN duplicate armonizzando l’AS dell’overlay sui WAN Edge dei DC durante la redistribuzione OMP↔BGP attraverso un’interconnessione tra DC.

Scenario pratico di un problema

Contoso Health gestisce 300 cliniche con doppio trasporto per ogni sito: MPLS (colore mpls) e banda larga (colore biz-internet). Gli utenti segnalano una qualità vocale intermittente scarsa, mentre le applicazioni dati funzionano correttamente. L’obiettivo è preferire MPLS per il traffico voce, effettuare il failover sulla banda larga durante i degradi di prestazione (brownout) e garantire un rapido failover in caso di interruzione completa (blackout) senza oscillazioni.

1. Validare lo stato di salute dell’overlay e la formazione del piano dati

• Logica: Confermare i prerequisiti. Usare show sdwan control connections per assicurarsi che la connessione DTLS/TLS verso vSmart/vBond/vManage sia stabile e show sdwan tunnels per verificare il full mesh dei tunnel MPLS e a banda larga. Se mancano i tunnel sul colore biz-internet, controllare l’assegnazione del colore e il NAT; vBond deve essere raggiungibile nello spazio pubblico per assistere il NAT traversal.

2. Calibrare i timer di BFD e dei probe

• Logica: Impostare l’hello di BFD a 1000 ms e il moltiplicatore a 6 per un rilevamento di ’liveness’ bilanciato (~6 s) e una scalabilità ragionevole. Configurare l’intervallo dell’app-probe a 1 s per un rilevamento tempestivo dei degradi. Timer eccessivamente aggressivi possono causare sovraccarico della CPU e fluttuazioni; timer troppo rilassati compromettono la reattività per il traffico voce.

3. Definire le classi di SLA

• Logica: Creare una classe di SLA Voice-SLA con latenza ≤ 150 ms, jitter ≤ 30 ms, perdita ≤ 1%, MOS ≥ 4.0. Creare una Data-SLA con latenza ≤ 200 ms, perdita ≤ 1%. Queste soglie riflettono la sensibilità del traffico voce e le prestazioni WAN tipiche; il MOS consolida l’esperienza utente attraverso diverse metriche.

4. Costruire le liste di applicazioni

• Logica: Usare DPI (NBAR2) per definire una App-List-Voice per il traffico multimediale di SIP/RTP/Teams/Zoom e una App-List-Data per le applicazioni transazionali. Includere pattern TLS SNI/QUIC ALPN per le moderne piattaforme voce/video. Dove la classificazione è incerta, ricorrere ai marking DSCP EF/AF41 applicati sul LAN edge.

5. Costruire la policy AAR

• Logica: Associare App-List-Voice a Voice-SLA con preferred-color mpls e backup-color biz-internet. Associare App-List-Data a Data-SLA con preferred-color biz-internet e backup-color mpls per preservare la banda MPLS. Questo assicura che il traffico voce utilizzi MPLS quando è in buono stato e si sposti sulla banda larga solo durante i degradi o le interruzioni, mentre il traffico dati preferisce la connessione internet più economica.

6. Aggiungere isteresi e hold-down

• Logica: Configurare un revert timer in modo che il traffico voce torni su MPLS solo dopo una conformità SLA prolungata (ad esempio, 30–60 s). Questo evita oscillazioni durante picchi di jitter transitori. Allo stesso modo, applicare una penalità o un ‘dampening’ sulla banda larga se viola ripetutamente l’SLA in un breve lasso di tempo.

7. Coordinare QoS e MTU

• Logica: Su entrambi i trasporti, assicurarsi che il ‘queueing’ EF e lo ‘shaping’ siano allineati con le velocità dei circuiti. Un disallineamento può aumentare il jitter/perdita rilevati dai probe BFD e dal traffico RTP voce. Validare il path MTU e disabilitare il bit DF dove la frammentazione è inevitabile, prevenendo la perdita di probe che potrebbe essere erroneamente interpretata come perdita di pacchetti.

8. Verificare e iterare

• Logica: Usare show sdwan app-route stats sla-class Voice-SLA per confermare il superamento/fallimento dell’SLA per ogni tunnel. Osservare i flussi attivi con show sdwan app-route statistics flows per assicurarsi che il traffico voce sia indirizzato su MPLS e si sposti sulla banda larga solo quando MPLS viola l’SLA. Durante i test, congestionare intenzionalmente la linea MPLS per validare il comportamento in caso di degrado, quindi misurare il tempo di ripristino.

Seguendo questi passaggi, Contoso Health si assicura che BFD fornisca un rapido rilevamento delle interruzioni complete, che AAR reagisca ai degradi utilizzando classi di SLA precise e che DPI classifichi accuratamente le applicazioni voce. Questa combinazione produce una qualità vocale prevedibile, un uso efficiente dei trasporti e un comportamento di failover controllabile attraverso tutta la fabric SD-WAN.

← Configurazione dei WAN Edge e Gestione dei template · Tutti i domini · Policy centralizzate e Ingegneria del traffico →

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