Cisco 300-415: Policy centralizzate e Ingegneria del traffico — 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

La policy centralizzata in Cisco SD-WAN è il framework che consente di programmare il comportamento del traffico e gli intenti di routing dai controller vSmart attraverso l’intera fabric. vSmart, che gestisce il control plane dell’overlay tramite OMP, distribuisce la policy di controllo centralizzata (per le route OMP e i TLOC) e le policy del data plane come data policy, application-aware routing (app-route) e cflowd. Queste policy modellano la topologia (hub-and-spoke, restrizione della mesh), selezionano i percorsi in base alle prestazioni delle applicazioni, indirizzano i flussi verso i servizi e segmentano il traffico per VPN. Poiché le policy possono alterare sia la raggiungibilità del control plane sia l’inoltro del data plane, una progettazione attenta, l’anteprima e un’implementazione graduale sono essenziali per evitare interruzioni di servizio.

Tipi di Policy Centralizzate e Componenti Fondamentali

• Policy di controllo centralizzata

  • Ambito: Control plane (OMP) tra i dispositivi WAN Edge e vSmart.
  • Scopo: Filtrare/modificare le route OMP e gli advertisement dei TLOC, impostare attributi (preference, tag, origin, TLOC) e costruire topologie (hub-and-spoke, partial mesh).
  • Direzione: Inbound (verso vSmart dal WAN Edge) e outbound (da vSmart verso il WAN Edge).

• Policy dei dati centralizzata

  • Ambito: Classificazione del data plane (L3/L4, campi, app-ID) sul WAN Edge, installata da vSmart.
  • Scopo: Consentire/negare flussi, impostare VPN, impostare TLOC, impostare DSCP/marking, police, mirror e service insertion/chaining.
  • Direzione: Valutata sul WAN Edge rispetto al lato servizio (LAN) o al lato tunnel (WAN) a seconda di dove è programmata; i design tipicamente mirano all’ingress del lato servizio per i flussi utente-WAN e al lato tunnel per il ritorno se è richiesto un comportamento simmetrico.

• Policy di Application-aware routing (app-route)

  • Ambito: Selezione del percorso nel data plane basata su applicazione e SLA (loss, latency, jitter) misurati da BFD.
  • Scopo: Indirizzare il traffico verso TLOC/color preferiti, definire classi di SLA basate su probe, impostare fallback ed eseguire traffic engineering dinamico per applicazione/famiglia.
  • Comportamento chiave: Valuta continuamente le prestazioni del percorso; può cambiare percorso quando l’SLA si degrada.

• Policy cflowd

  • Ambito: Telemetria dei flussi (simile a IPFIX/NetFlow) generata dai WAN Edge.
  • Scopo: Abilitare/disabilitare gli exporter per VPN, definire tassi di campionamento, template e collector (vManage o esterni).
  • Nota di progettazione: Il campionamento deve bilanciare la visibilità con l’overhead di CPU/banda; l’abilitazione per-VPN supporta il reporting segmentato.

Le liste di policy sono oggetti di corrispondenza riutilizzabili:

• Site list: ID dei siti usati per selezionare dove applicare le policy e per far corrispondere i siti di origine/destinazione delle route.
• VPN list: VRF (VPN) usate per segmentare l’ambito della policy e costruire regole per segmento.
• Prefix list: Prefissi IP per far corrispondere le route OMP o il traffico dati.
• Data prefix list: Oggetto di prefisso specializzato per la classificazione della data policy.
• TLOC list: Tuple di system IP, color ed encapsulation usate per far corrispondere o impostare gli attributi dei TLOC.
• Color list: Uno o più colori di trasporto (es. biz-internet, mpls, public-internet) per il targeting/l’affinità dei link.
• Application list: Applicazioni/gruppi NBAR2 per classificare il traffico per le policy app-route o data.
• SLA class: Soglie di latenza, perdita e jitter collegate ad app-route per l’indirizzamento basato sulle prestazioni.

Struttura e valutazione delle sequenze di policy:

• Le sequenze sono ordinate, vige la regola del ‘first-match wins’. Ogni sequenza ha:
  • Condizioni di corrispondenza (Match): Liste/campi (site/VPN/prefix/TLOC/color/app, porte L4, DSCP, protocollo).
  • Azioni (Action): Accept/deny, impostazione di attributi (TLOC, VPN, DSCP, preference, tag), service insertion, police, mirror.
• Azione di default: Applicata se nessuna sequenza corrisponde. I default comuni sono ‘accept’ (controllo/dati) per evitare drop involontari; i default ‘deny’ espliciti sono usati deliberatamente e richiedono un’attenta validazione.
• Direzione:
  • La direzione della policy di controllo è a livello di vSmart (OMP inbound/outbound).
  • Le policy data e app-route operano sul traffico a livello del WAN Edge; scegliere il comportamento lato servizio (service-side) o lato tunnel (tunnel-side) per adattarsi al flusso che si intende influenzare e garantire la simmetria del traffico di ritorno quando sono presenti servizi stateful nel percorso.

Progettazione delle Policy del Control-Plane e Manipolazione di Route/TLOC

La policy di controllo è lo strumento autorevole per modellare la topologia dell’overlay, poiché determina quali route OMP e TLOC un sito può inviare o ricevere:

• Manipolazione delle route OMP

  • Utilizzare una policy di controllo inbound per filtrare, etichettare (tag) o impostare attributi sulle route apprese da un sito prima che entrino nella RIB dell’overlay su vSmart.
  • Utilizzare una policy di controllo outbound per limitare quali route vengono annunciate a siti specifici (ad esempio, non annunciare i prefissi appresi dagli spoke ad altri spoke).
  • Azioni comuni: impostare la preferenza (influenza il best-path di OMP), impostare il tag (per corrispondenze successive), impostare l’origine, impostare i vincoli del sito di origine (site-of-origin).

• Manipolazione dei TLOC

  • Effettuare il matching sugli attributi dei TLOC (system IP, color, encap) per filtrare o preferire trasporti specifici.
  • Le azioni includono la modifica degli attributi o delle preferenze dei TLOC preferiti, in modo che gli annunci delle route favoriscano un determinato color (ad esempio, preferire MPLS per le subnet critiche).
  • Compromesso: un filtraggio dei TLOC eccessivamente aggressivo può isolare i siti in caso di guasto del trasporto rimanente. Preferire la messa a punto degli attributi piuttosto che un ‘deny’ generalizzato, a meno che non si disponga di percorsi ridondanti.

• Pattern di topologia

  • Hub-and-spoke: una policy di controllo outbound da vSmart verso gli spoke nega l’annuncio delle route originate dagli spoke ad altri spoke; gli hub ricevono e annunciano tutte le route.
  • Restrizione della mesh: simile all’hub-and-spoke, ma permette coppie specifiche spoke-to-spoke (ad esempio, mesh regionali) tramite eccezioni nelle sequenze della policy.
  • Segmentazione: combinare le liste VPN con il filtraggio delle route per mantenere isolati gli overlay per-VPN; annunciare solo i prefissi di default o prefissi selezionati ai siti con restrizioni.

Modalità di guasto e compromessi:

• Una policy di controllo outbound applicata in modo errato con un ‘deny’ di default può ritirare route critiche, isolando i siti. Impostare sempre un ‘accept’ di default e aggiungere ‘deny’ mirati, a meno che l’anteprima non confermi esplicitamente la copertura.
• La modifica degli attributi OMP su larga scala può innescare un ‘route churn’; scaglionare l’implementazione per liste di siti per ridurre lo shock sul control-plane.
• La riscrittura degli attributi dei TLOC può portare a un forwarding asimmetrico se il percorso di ritorno non è influenzato in modo equivalente; validare entrambe le direzioni.

Application-Aware Routing, Inserimento di Servizi e Segmentazione

L’Application-Aware Routing (AAR) e la data policy, insieme, forniscono un traffic engineering granulare:

• AAR e traffic steering

  • Le classi di SLA definiscono valori accettabili di perdita/latenza/jitter; le probe BFD per coppia di TLOC forniscono misurazioni in tempo reale.
  • La policy di app-route effettua il matching di applicazioni o campi L3/L4 e seleziona le liste di color/TLOC preferite; se lo SLA viene violato, si verifica un failover secondo la policy.
  • Suggerimenti di progettazione:
    • Evitare soglie di SLA troppo restrittive che causano ‘flapping’; includere un’isteresi utilizzando moltiplicatori per le probe e soglie ragionevoli.
    • Per le applicazioni sensibili al riordino dei pacchetti, preferire lo spostamento ‘al prossimo nuovo flusso’ (‘move on next new flow’) invece di cambi a metà flusso, oppure ‘pinnare’ i flussi usando il consistent hashing dove supportato.
    • Quando sia l’AAR che la data policy impostano il TLOC, dare la precedenza all’AAR per la selezione del percorso e usare la data policy per l’inserimento/marcatura dei servizi; evitare azioni sovrapposte nella stessa classe di traffico.

• Service chaining e inserimento di servizi

  • L’azione ‘service’ della data policy inserisce il traffico attraverso servizi on-premise o in colocation (firewall, IDS/IPS, nodi di servizio SD-WAN).
  • Concatenare più servizi in ordine dove richiesto; garantire un inserimento simmetrico per i servizi stateful sia sul percorso di andata che su quello di ritorno.
  • Compromessi: ogni ‘hop’ di servizio aggiunge latenza e potenziali domini di guasto. Implementare health check e comportamenti di fail-open/closed coerenti con la postura di sicurezza.

• Segmentazione del traffico

  • Le VPN forniscono una segmentazione netta (‘hard segmentation’); la policy centralizzata si applica per-VPN utilizzando le liste VPN.
  • Il routing Inter-VPN (‘route leaking’) può essere realizzato con una data policy usando ‘set VPN’ per flussi specifici; vincolare rigorosamente con corrispondenze di prefisso/applicazione ed effettuare audit frequenti.
  • Per i servizi condivisi (ad es., DNS, identity), annunciare i prefissi dei servizi da una VPN di servizi alle VPN consumer con una policy di controllo, piuttosto che con ampi ’leak’ nel data-plane.

Esempio di snippet di app-route che illustra lo steering basato su SLA:

app-route-policy CRITICAL-APPS
  sequence 10
    match application-list BUS_APPS
    sla-class GOLD
    preferred-color mpls fallback biz-internet
  !
  sequence 20
    match application-list BEST_EFFORT
    sla-class BRONZE
    preferred-color biz-internet fallback public-internet
  !
  default-action accept
!

Operazioni: Collegamento, Convalida e Risoluzione dei Problemi

Collegamento delle policy tramite vSmart:

• Definire le policy centralizzate in vManage e collegarle a liste di siti e liste di VPN. vSmart compila la policy e la distribuisce ai WAN Edge tramite sessioni OMP sicure DTLS/TLS nella VPN 0.
• Valutare attentamente l’ambito delle modifiche; una singola istanza di policy può influenzare centinaia di siti. Utilizzare le liste di siti per effettuare deployment graduali per regione o funzione.

Simulazione, anteprima e deployment graduale delle policy:

• Anteprima: Prima dell’attivazione, utilizzare l’anteprima di vManage per ispezionare la policy compilata specifica per ogni dispositivo (ciò che ogni WAN Edge riceverà). Confermare la logica di match/action, le azioni di default e le direzioni.
• Simulazione: Utilizzare la simulazione delle policy per testare la corrispondenza dei flussi e le azioni previste (es. quale TLOC utilizzerà una data applicazione/5-tupla). Convalidare le mappature delle classi di SLA e la classificazione delle applicazioni.
• Deployment graduale:
  • 1. Collegare a una lista di siti “canary” (pochi siti).
  • 2. Monitorare i KPI del control plane e del data plane (conteggio rotte OMP, BFD, hit su app-route).
  • 3. Espandere la lista di siti in modo incrementale.
• Versioning e rollback: Mantenere le versioni precedenti delle policy; se viene rilevato un comportamento inatteso, disattivare la nuova policy o effettuare tempestivamente il rollback alla versione precedente.

Debug di risultati imprevisti e precedenza:

• Verifica del control plane

undefined

,

undefined

Confermare la presenza/assenza di rotte e TLOC in base all’intento della policy.

undefined

Verificare i contatori della control policy e quali sequenze hanno avuto una corrispondenza.

• Sintomo: Gli spoke non riescono a raggiungere gli altri dopo il deployment → controllare le righe di deny della control policy in uscita verso gli spoke e le azioni di default.

• Verifica del data plane e di AAR

undefined

e

undefined

Convalidare lo stato degli SLA e le decisioni sul percorso.

undefined

o equivalente: Confermare i contatori dell’inserimento di servizi e l’ordine di concatenamento (chaining).

undefined

e

undefined

Verificare il percorso di forwarding effettivo.

• Sintomo: Cambi di percorso imprevisti/flapping → rendere meno restrittivi gli SLA o regolare i moltiplicatori dei probe; assicurarsi che una data policy sovrapposta non stia anch’essa impostando il TLOC.

• Precedenza e conflitti delle policy

  • Le decisioni di AAR hanno tipicamente la precedenza per la selezione del percorso; utilizzare la data policy principalmente per l’inserimento di servizi, il marking e il controllo degli accessi.
  • Criteri di match sovrapposti tra diverse policy possono creare ambiguità. Mantenere i domini di match mutuamente esclusivi o introdurre un ordinamento e dei tag per eliminare l’ambiguità.
  • Un’azione di accept di default può mascherare sequenze mancanti; aggiungere contatori espliciti di sola osservazione (es. mirror/police basso) o logging temporaneo per convalidare le corrispondenze prima di applicare i deny.

• Convalida di cflowd

undefined

Assicurarsi che gli exporter per VPN siano attivi e che il campionamento avvenga come previsto.

• CPU elevata dopo aver abilitato cflowd → aumentare l’intervallo di campionamento o limitarlo alle VPN/applicazioni essenziali.

Scenario di un Problema Pratico

Northwind Traders sta migrando a Cisco SD-WAN e deve imporre una topologia hub-and-spoke per le VPN PCI, indirizzare Office 365 verso il miglior percorso Internet e inserire un servizio firewall regionale per il traffico guest senza impattare le applicazioni critiche.

Approccio:

1. Costruire le liste per le policy

   • Creare liste di siti: HUBS (data center), SPOKES (sedi periferiche).
   • Creare liste di VPN: PCI_VPN, GUEST_VPN, CORP_VPN.
   • Creare liste di applicazioni: O365, BEST_EFFORT.
   • Creare liste di color: PRIVATE (mpls), DIA (biz-internet, public-internet). Motivazione: Le liste riutilizzabili consentono di definire un ambito preciso e un rollout graduale sicuro; la separazione delle VPN supporta la segmentazione.

2. Definire le classi di SLA

   • GOLD: perdita 0,5%, latenza 100 ms, jitter 20 ms.
   • SILVER: perdita 1%, latenza 150 ms, jitter 30 ms. Motivazione: Allineare le soglie alle prestazioni realistiche del trasporto per prevenire il path flapping; soglie più restrittive per O365 rispetto al best-effort.

3. Implementare la control policy per la topologia hub-and-spoke PCI

   • In ingresso a vSmart: applicare un tag alle rotte apprese dagli SPOKES nella PCI_VPN.
   • In uscita da vSmart: verso gli SPOKES, annunciare le rotte degli HUB e le rotte di default; negare l’annuncio di rotte PCI originate dagli SPOKE verso altri SPOKE; verso gli HUB, annunciare tutto. Motivazione: La topologia viene imposta a livello di control plane, garantendo che gli spoke si vedano tra loro solo attraverso gli hub e preservando la segmentazione nella VPN PCI.

4. Creare una policy app-route per O365 e best-effort

   • Far corrispondere O365 nella CORP_VPN con lo SLA GOLD; color preferito DIA con fallback su PRIVATE.
   • Far corrispondere BEST_EFFORT con SILVER; color preferito PRIVATE con fallback su DIA. Motivazione: O365 offre le migliori prestazioni su Internet diretto quando lo SLA è rispettato; effettuare il failback su MPLS se necessario. Il traffico best-effort può preferire MPLS per motivi di costo/policy, pur consentendo il fallback su DIA.

5. Inserire un firewall regionale per il traffico guest

   • Data policy nella GUEST_VPN: inserimento del servizio (service insertion) nella catena di servizi del firewall regionale in entrambe le direzioni, di andata (lato servizio verso WAN) e di ritorno (dal tunnel al servizio).
   • Assicurarsi che lo stato di salute del servizio firewall sia monitorato; definire una politica di fail-open per il caso d’uso guest per preservare la disponibilità. Motivazione: L’ispezione stateful richiede un attraversamento simmetrico; l’inserimento bidirezionale evita la caduta delle sessioni. La tolleranza al rischio per il traffico guest consente il fail-open se il servizio non è disponibile.

6. Collegare le policy tramite vSmart con un rollout graduale

   • Collegare la control policy agli HUB e a un sottoinsieme “canary” di SPOKE nella PCI_VPN.
   • Collegare le policy app-route e data prima a una regione limitata. Motivazione: Limita il raggio d’impatto; convalida il comportamento della policy prima dell’espansione globale.

7. Convalidare e monitorare

   • Visualizzare in anteprima le policy compilate per ogni dispositivo; confermare le azioni di default.
   • Usare la simulazione per testare flussi di esempio (O365 da una sede periferica in CORP_VPN, traffico web guest dalla GUEST_VPN).
   • Monitorare

undefined

(raggiungibilità PCI),

undefined

(percorso O365),

undefined

(contatori firewall guest) e le sessioni BFD. Motivazione: Conferma che i risultati

← Tunnel del piano dati · Tutti i domini · Sicurezza →

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