Cisco 300-415: Qualità del Servizio e Servizi Multicast — 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

I servizi di Quality of Service (QoS) e multicast in Cisco SD-WAN sono progettati per preservare l’esperienza applicativa su trasporti eterogenei, abilitando al contempo una distribuzione scalabile e basata su policy del traffico in tempo reale e di gruppo. La QoS assicura priorità, shaping e un uso equo della larghezza di banda per applicazione e per tunnel di overlay; il multicast permette una replica efficiente e controllata da policy dei flussi per i destinatari tra i vari siti. Insieme, traducono l’intento (il traffico voce/video deve essere protetto da perdita e jitter; le app business-critical devono rispettare gli SLA) in un comportamento coerente del data plane, coordinato dal control plane SD-WAN (vSmart) e applicato sui dispositivi WAN Edge.

Architettura QoS, Code, Scheduling, Shaping, Policing e Allocazione della Larghezza di Banda

La QoS in Cisco SD-WAN è gerarchica e consapevole del trasporto (transport-aware):

• Classificazione: Identifica i flussi in base a campi (L3/L4), DSCP, firme applicative (NBAR2 su IOS XE SD-WAN) o contesto di VPN e prefisso.
• Marcatura (Marking): Imposta o preserva il DSCP dal lato del servizio (service side), lo riscrive se necessario per i vincoli della WAN e lo mappa alle code di uscita (egress queue) tramite le QoS map.
• Accodamento e scheduling: Le interfacce di uscita implementano code hardware/software multiple con una coda a bassa latenza e priorità assoluta (low-latency queue, LLQ) per il traffico in tempo reale e scheduler pesati (WFQ/WRR/CBWFQ) per le altre classi.
• Shaping: Modella il traffico in uscita (egress) a una velocità configurata (per interfaccia, per sotto-interfaccia o per tunnel) per evitare i policer del provider e assorbire i picchi (burst).
• Policing: Limita la velocità (rate-limit) e, opzionalmente, rimarca o scarta il traffico non conforme in entrata (ingress) o in uscita (egress); usato con parsimonia per evitare i “brownout” applicativi.
• Allocazione della larghezza di banda: Riserva una larghezza di banda minima (garanzie) per classe e limita i massimi dove appropriato; assicura che la LLQ abbia un limite massimo (cap) stretto ed esplicito per prevenire la “starvation” (mancanza di risorse) delle altre code.

Linee guida di progettazione e compromessi:

• Effettuare lo shaping a una velocità sicura, inferiore al policer effettivo dell’ISP. Per i circuiti Internet a velocità variabile, il 90–95% della larghezza di banda nominale è un punto di partenza pratico; ottimizzare basandosi sui drop e sulla latenza osservati sotto carico.
• La profondità della coda (buffering) deve bilanciare ritardo e perdita (delay vs. loss). Dimensionarla a circa una frazione del prodotto banda-ritardo (bandwidth-delay product); troppo piccola induce “tail drop”, troppo grande gonfia la latenza per le classi inferiori.
• Usare la LLQ solo per flussi brevi a velocità costante di controllo voce/video; non inserire flussi video a bitrate elevato nella LLQ — assegnarli a una coda pesata ad alta priorità con un chiaro limite massimo di banda.
• Preferire lo shaping al policing in uscita. Applicare i policer per contratti di velocità espliciti o per traffico in entrata non attendibile (untrusted ingress).
• Su collegamenti fisici condivisi che trasportano più overlay, abilitare la QoS per-tunnel (PTQ) in modo che ogni tunnel sicuro basato su BFD riceva il proprio scheduler/shaper, impedendo a un singolo overlay congestionato di monopolizzare il link.
• Una policy specifica per il trasporto (consapevole del “color”/TLOC) permette di avere QoS map, shaper e garanzie di classe distinte per ogni underlay (ad esempio, shaping più restrittivo e un set di DSCP ridotto su Internet rispetto a classi più ricche su MPLS).

QoS per-tunnel e specificità del trasporto:

• La PTQ virtualizza lo scheduling in uscita per ogni tunnel IPsec/DTLS/TLS, in modo che garanzie e limiti massimi si applichino per percorso (per-path) e non solo per interfaccia. Ciò è essenziale quando un dispositivo Edge forma più tunnel sulla stessa interfaccia (es. regioni vSmart/vBond doppie o peer remoti multipli).
• Assegnare QoS map diverse per “color” (biz-internet, mpls, lte) per rispettare le whitelist DSCP del provider e prevenire rimarcature inattese (es. collassare le classi AF in quella di default sulla banda larga).

Classificazione e Marcatura con DSCP, QoS Map e Gestione della Congestione

La classificazione attendibile (trusted) inizia al bordo della VPN di servizio (service VPN edge):

• Confini di fiducia (Trust boundaries): Se il dominio di accesso LAN non è consapevole della QoS (QoS-unaware), classificare e marcare sul WAN Edge usando l’ID applicativo L7 o tuple L3/L4. Se la LAN è capace di gestire la QoS (QoS-capable), verificare e preservare il DSCP, normalizzandolo rispetto a una QoS map della WAN.
• Strategia DSCP: EF per la voce interattiva, AF41/42 per il video, AF31/AF21 per i dati critici, classi CS3/AF per la segnalazione, CS0/DF per il best effort e CS1 (o LE) per lo scavenger. Allinearsi con i valori accettati dal provider.
• QoS map: Mappa il DSCP a una coda (DSCP-to-queue) e opzionalmente lo riscrive in uscita; mantenere una mappatura uno-a-uno o molti-a-uno che rispetti i limiti dell’underlay.

Breve esempio di controlli operativamente utili:

show sdwan app-route stats sla-class VOICE
show policy qos-queue   (vEdge)
show policy-map interface <wan-intf>  (IOS XE SD-WAN)

Gestione della congestione e dimensionamento delle code:

• Iniziare con una LLQ piccola e con un limite massimo (capped) per EF (ad esempio, il 10% della velocità di shaping) e applicare il policing all’interno della LLQ per prevenire che venga saturata da flussi marcati erroneamente.
• Allocare la larghezza di banda rimanente usando pesi WRR/CBWFQ allineati con le priorità di business (es. 30% dati critici, 20% video, 35% best effort, 5% scavenger).
• Considerare l’abilitazione del drop anticipato (WRED) per le classi di traffico di massa (bulk) quando supportato dalla piattaforma per evitare la sincronizzazione globale; non abilitare il drop anticipato sulla LLQ o su piccole code di controllo.

Modalità di guasto da monitorare:

• La rimarcatura da parte del carrier collassa i valori DSCP, spostando il traffico in tempo reale nella classe best effort; il risultato è jitter e perdita di pacchetti durante i picchi. Verificare con catture di pacchetti e profili QoS del provider.
• Shaper dimensionati in modo errato portano a “tail drop” persistenti; si verifica la “starvation” della LLQ se questa non ha un limite massimo o se il traffico video la satura.
• L’assenza della PTQ su un’interfaccia condivisa causa il fenomeno del “noisy-neighbor”, in cui alcuni overlay consumano la larghezza di banda e degradano i tunnel critici.

Prioritizzazione delle Applicazioni, Intento di Business e Applicazione degli SLA

Cisco SD-WAN esprime l’intento applicativo tramite policy centralizzate sul controller vSmart, che gestisce il control plane dell’overlay e distribuisce le policy ai WAN Edge. L’Application-Aware Routing (AAR) instrada il traffico in base a perdita (loss), latenza e jitter misurati per ogni trasporto e per ogni tunnel utilizzando BFD. Per l’ottimizzazione SaaS, Cloud OnRamp può integrare la perdita e la latenza basate su HTTP verso l’applicazione, oltre alle metriche BFD verso un sito gateway.

Best practice:

• Definire liste di applicazioni e classi di SLA in base alla criticità di business:
  • VOICE: EF, target <150 ms solo andata (one-way), <30 ms di jitter, <1% di perdita (loss); instradare solo su percorsi che soddisfano queste soglie.
  • VIDEO: AF4x, jitter/perdita leggermente più tolleranti rispetto alla voce; preferire percorsi ad alta larghezza di banda e bassa perdita.
  • CRITICAL DATA: AF3x/AF2x; limitare perdita e latenza come richiesto dall’applicazione.
• Utilizzare policy centralizzate per l’application-aware routing (AAR) per preferire i percorsi che soddisfano gli SLA per classe; effettuare il fallback su percorsi secondari in caso di degrado.
• Combinare l’AAR con la QoS per-trasporto: un percorso selezionato deve avere risorse riservate per la classe; altrimenti, il traffico potrebbe rispettare lo SLA del percorso ma essere comunque accodato o scartato in uscita (egress).
• Per il SaaS tramite un sito gateway, convalidare entrambi:
  • Perdita/latenza HTTP verso l’endpoint SaaS.
  • Perdita/latenza BFD verso il sito gateway.
• Imporre la conservazione del DSCP end-to-end; in uscita, riscrivere i valori solo dove gli underlay lo richiedono e ripristinare le marcature se l’estremità remota (far end) le considera attendibili (trusts them).

Verifiche operative:

show sdwan app-route statistics
show sdwan bfd sessions
show application traffic-flow   (vManage analytics)

Errori comuni:

• Soglie di SLA troppo restrittive causano instabilità del percorso (path flapping); introdurre isteresi e hold timer.
• La mancanza di larghezza di banda per una classe sul percorso scelto porta a congestione auto-inflitta; allineare le scelte di AAR con la capacità della QoS per-trasporto.
• Classificazione errata (es. traffico voce rilevato come best effort) a causa di payload crittografati o firme NBAR mancanti; utilizzare il trust del DSCP o corrispondenze esplicite L4 come fallback.

Fondamenti del Multicast e Progettazione del Multicast Overlay

Il multicast su SD-WAN disaccoppia il piano di controllo multicast della LAN dai vincoli dell’underlay:

• Fondamenti:
  • I ricevitori segnalano il loro interesse con IGMPv2/v3 verso il router LAN di primo hop (il WAN Edge nella VPN di servizio).
  • Si raccomanda l’uso di PIM Sparse Mode nella VPN di servizio; i rendezvous point (RP) orchestrano le join iniziali.
• Piano di controllo dell’overlay:
  • I router WAN Edge originano route di servizio multicast verso il controller vSmart tramite OMP.
  • Il controller vSmart, agendo nel ruolo di replicatore multicast/advertisement dell’RP, propaga le informazioni sull’RP attraverso l’overlay e inoltra le join per i gruppi richiesti verso la sorgente o il PIM-RP, come specificato nel messaggio di join PIM originale.
  • vSmart seleziona uno o più WAN Edge come replicatori del piano dati. L’Edge lato sorgente invia una singola copia al replicatore, che a sua volta la replica verso gli Edge ricevitori, minimizzando l’uso di banda sui link con capacità limitata.
• Piano dati:
  • La replica avviene tramite pacchetti unicast cifrati attraverso i tunnel dell’overlay; i confini della VPN di servizio vengono preservati (il multicast è per-VPN/VRF).
  • Il multicast Inter-VPN non è automatico; se necessario, utilizzare esplicitamente service-chaining o gateway a livello applicativo.

Considerazioni di progettazione e compromessi:

• Posizionare l’RP logicamente vicino alle sorgenti o ai datacenter centrali. In un overlay SD-WAN, affidarsi a vSmart per pubblicizzare l’RP ai ricevitori, garantendo join coerenti.
• Abilitare il multicast solo nelle VPN dove è necessario; mantenere il traffico di controllo dei ricevitori (IGMP) limitato tramite rate-limiting per proteggere la CPU.
• Su link a bassa larghezza di banda, centralizzare la replica presso un hub/replicatore con capacità adeguata per evitare la replica N×stream sui circuiti di accesso.
• Validare l’MTU per evitare la frammentazione di stream ad alto bitrate; considerare di modellare (shaping) le classi video indipendentemente dalle code del piano di controllo.

Modalità di guasto:

• L’assenza di un IGMP querier sulla LAN porta all’invecchiamento del gruppo (group aging) e alla perdita dello stream; assicurarsi che il WAN Edge o uno switch LAN agisca da querier.
• Un mismatch dell’RP o un filtraggio in una policy centralizzata interrompe le join; confermare la raggiungibilità dell’RP attraverso l’overlay.
• Un traffico di controllo multicast eccessivo composto da piccoli pacchetti può essere scambiato per un attacco DDoS; applicare rate-limit e monitorare le code di controllo.
• Confini della VPN di servizio specificati in modo errato causano la mancata consegna; il multicast non attraversa le VPN a meno che non sia esplicitamente progettato.

Elementi essenziali per il troubleshooting:

show ip igmp groups
show ip pim neighbor / rp mapping
show sdwan omp services
show sdwan multicast status
show interface | include drops

Correlare le perdite (drop) nelle code con i KPI applicativi; per il multicast, assicurarsi che le join IGMP siano viste sull’Edge, che esistano le route di servizio OMP e che il replicatore scelto sia raggiungibile tramite un tunnel integro (healthy).

Scenario pratico

NorthRiver Health gestisce 120 cliniche con doppio trasporto (MPLS e Internet). Le lamentele riportano voce a scatti, video di telemedicina pixelati e multicast IPTV intermittente nelle sale d’attesa.

Approccio:

1. Stabilire i confini di fiducia (trust boundary) e classificare il traffico

• Motivazione: Una classificazione accurata è un prerequisito per la prioritizzazione. Preservare il DSCP dai domini LAN conformi; dove assente, classificare per applicazione (NBAR2) e tuple L4, mappando la voce su EF, il video su AF41 e l’EMR (cartella clinica elettronica) critico su AF31.

2. Creare mappe QoS e shaper specifici per il trasporto

• Motivazione: MPLS rispetta AF/EF, Internet spesso no. Configurare mappe QoS per-color: set completo di classi su MPLS; classi ridotte su Internet preservando EF e AF4. Modellare (shaping) MPLS al 95% del CIR e Internet al throughput sostenibile misurato per evitare i policer del provider.

3. Abilitare il QoS per-tunnel (PTQ) sulle interfacce WAN condivise

• Motivazione: Più overlay condividono lo stesso link fisico. Il PTQ impedisce che un tunnel site-to-cloud congestionato sottragga risorse (starving) ai tunnel voce/video site-to-datacenter, allocando scheduler e minimi per-tunnel.

4. Riservare e limitare (cap) la LLQ per la voce; pesare video e dati critici

• Motivazione: La voce richiede latenza/jitter limitati; limitare la LLQ al 10% per prevenire la carenza di risorse (starvation). Assegnare il 25–30% al video AF4 con un massimo rigido. Allocare il 25% al traffico EMR AF3, il resto a best effort e scavenger.

5. Implementare una policy AAR centralizzata su vSmart con classi di SLA

• Motivazione: vSmart distribuisce una policy centralizzata che instrada voce/video/EMR su percorsi che soddisfano gli obiettivi di SLA utilizzando i valori di perdita/latenza/jitter di BFD. Aggiungere isteresi per prevenire cambi di stato frequenti (flap). Per i moduli EHR SaaS tramite un gateway, includere perdita/latenza HTTP verso il SaaS e BFD verso il sito del gateway.

6. Distribuire il multicast overlay con selezione del replicatore da parte di vSmart

• Motivazione: Una distribuzione IPTV efficiente richiede una replica controllata. Abilitare il multicast nella VPN IPTV, configurare PIM-SM e l’RP, e lasciare che vSmart pubblicizzi l’RP e selezioni un Edge del datacenter come replicatore per proteggere i circuiti a bassa velocità delle cliniche dalla replica N-way.

7. Validare e iterare con la telemetria

• Motivazione: Confermare il comportamento sotto carico. Usare:
  • show sdwan app-route statistics per verificare la selezione del percorso SLA.
  • show policy qos-queue / show policy-map interface per valutare l’utilizzo delle code e i drop.
  • show ip igmp groups e show sdwan omp services per le join multicast e le route di servizio. Ottimizzare i rate degli shaper e i pesi delle code per eliminare i tail drop per voce/video, mantenendo una latenza accettabile per i dati critici.

8. Misure di salvaguardia (guardrail) e gestione delle anomalie

• Motivazione: Prevenire le recidive e rilevare le regressioni. Applicare policer in ingresso sui segmenti LAN non attendibili per limitare il traffico marcato in modo errato, applicare rate-limit all’IGMP per proteggere la CPU del piano di controllo e impostare alert sulle violazioni SLA dell’AAR e sui contatori di drop delle code per attivare una remediation proattiva.

Questa sequenza assicura che NorthRiver Health traduca l’intento di business in una QoS coerente, consapevole del trasporto, e in una consegna multicast affidabile. La voce ottiene un trattamento rigido e limitato; video ed EMR ricevono una larghezza di banda prioritizzata e pesata; i percorsi vengono selezionati tramite misurazioni SLA in tempo reale; e il multicast viene replicato in modo efficiente senza sovraccaricare i link delle filiali.

← Sicurezza · Tutti i domini · Integrazione Cloud →

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