Cisco 300-410: Qualità del Servizio e Protezione del Control-Plane — Guida allo studio

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Fa parte della Cisco CCNP Enterprise 300-410 ENARSI — Guida allo studio. Esercitati con risposte verificate nel centro esami Cisco, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Quality of Service (QoS) e Control-Plane Protection (CoPP/CPPr) assicurano insieme che le applicazioni business-critical e la rete stessa rimangano stabili sotto carico e in caso di attacco. La QoS differenzia il traffico, dà priorità ai flussi sensibili al ritardo e gestisce la congestione sui link con risorse scarse. CoPP/CPPr protegge la CPU del router e lo stack di gestione da sovraccarichi accidentali ed eventi malevoli. Una progettazione corretta dipende da una marcatura end-to-end coerente, confini di trust disciplinati, condizionamento appropriato (policing/shaping), code ben dimensionate, prevenzione proattiva della congestione, un trattamento attento di tunnel/crittografia e una validazione continua tramite contatori correlati al comportamento delle applicazioni.

Classificazione, Trust e Marcatura End-to-End

La classificazione e la marcatura del traffico determinano come i pacchetti verranno accodati e potenzialmente scartati a ogni hop.

• Classificazione e corrispondenza (matching)

  • Corrispondenza basata su access-list, DSCP/IP precedence, CoS (802.1p), firme delle applicazioni NBAR o header interni dei tunnel (con qos pre-classify).
  • Mantenere il determinismo: effettuare il matching su campi di Livello 3/4 quando possibile; usare NBAR solo dove necessario a causa delle implicazioni sulla CPU su alcune piattaforme.

• Confini di trust

  • Definire dove la rete accetta le marcature esistenti. Tipicamente: non fidarsi degli host finali; fidarsi dei telefoni aziendali e degli uplink verso domini QoS noti.
  • Sul perimetro (edge), rimarcare il traffico non attendibile con i valori DSCP definiti dalla policy; fidarsi solo dei dispositivi gestiti e autenticati.
  • Sulle porte dello switch verso gli endpoint, rimuovere il trust (no trust dscp/cos) a meno che non si verifichi esplicitamente il tipo di dispositivo.

• Marcatura

  • DSCP (6 bit) è la marcatura end-to-end primaria nelle reti IP. IP precedence (3 bit) è un meccanismo legacy e si mappa sui bit più significativi di DSCP.
  • CoS (802.1p, 3 bit) marca i frame di Livello 2 attraverso i trunk VLAN; mappare DSCP↔CoS in modo coerente ai confini L2/L3.
  • Nei core MPLS, la Traffic Class (TC, precedentemente EXP) a 3 bit trasporta la QoS; mappare DSCP su TC in ingresso (ingress) e TC di nuovo su DSCP in uscita (egress) per preservare la semantica attraverso il core VPN o TE.

• Coerenza della marcatura

  • Riservare EF per il bearer voce (a basso jitter), CS3/AF31/AF32 per la segnalazione di chiamata, AF4x per il video interattivo, AF2x/AF1x per i dati critici, CS0/BE per il best effort e CS1 per lo scavenger.
  • Documentare una singola policy QoS aziendale; assicurarsi che i provider WAN la rispettino ed eseguano le mappature come da contratto.
  • Evitare la rimarcatura a metà percorso (mid-path) a meno che non si stia traducendo tra domini; altrimenti si rischia l’inversione di priorità e si aumenta la complessità del troubleshooting.

Esempio (marcatura sull’edge di ingresso):

undefined

!

undefined

!

undefined

Modalità di fallimento e compromessi:

• Fidarsi dell’edge sbagliato porta all’abuso delle priorità; flussi di basso valore possono sottrarre risorse alle code critiche.
• Mappature DSCP↔CoS incoerenti interrompono la QoS nelle transizioni L2/L3.
• Un uso eccessivo di NBAR su piattaforme software può aumentare l’utilizzo della CPU; preferire corrispondenze statiche.

Condizionamento, Accodamento e Prevenzione della Congestione

Il condizionamento del traffico modella (shaping) il traffico a velocità che la rete può sostenere e applica il policing dove sono richiesti limiti rigidi.

• Policing vs. shaping

  • Il policing impone una velocità utilizzando i token bucket; l’eccesso viene scartato o, opzionalmente, rimarcato. Preserva la capacità del link ma aumenta la perdita e può innescare il backoff di TCP e i ritentativi dell’applicazione.
  • Lo shaping mette in buffer e rilascia il traffico a una velocità target (tipicamente un CIR del carrier), livellando i picchi (burst) e riducendo gli scarti a valle; aggiunge ritardo e jitter proporzionali alla profondità della coda.

• Parametri di burst

  • I policer single-rate a due parametri usano un committed information rate (CIR) con un committed burst (Bc) e, opzionalmente, un Be (excess burst).
  • Un Bc troppo piccolo rispetto a RTT e MTU causa scarti a livello di frammentazione e un throughput inefficace; dimensionare Bc ad almeno 1–2 volte il prodotto banda-ritardo per lo shaping, e a diversi MTU per il policing.

• CBWFQ e LLQ

  • Il Class-Based Weighted Fair Queuing garantisce una larghezza di banda minima alle classi. Configurare la banda in kbps o in percentuale sotto lo shape.
  • La Low-Latency Queue (LLQ) aggiunge un servizio a priorità stretta a una classe (priority), sottoposto a policing alla velocità configurata per prevenire la starvation. Solo il bearer voce/video in tempo reale dovrebbe trovarsi nella LLQ.
  • I limiti di coda (queue-limit) impostano il numero massimo di pacchetti messi in buffer per classe; un valore troppo alto aumenta la latenza, uno troppo basso aumenta gli scarti. Bilanciare con la tolleranza dell’applicazione.

• WRED vs. tail drop

  • Il tail drop scarta i pacchetti solo quando le code sono piene; ciò può causare una sincronizzazione globale di TCP e ampie oscillazioni.
  • Il Weighted Random Early Detection (WRED) inizia a effettuare scarti probabilistici prima che la coda sia piena; il WRED basato su DSCP permette alle classi a priorità più alta di tollerare code più profonde con una probabilità di scarto anticipato più bassa.
  • WRED avvantaggia i flussi TCP; per il traffico prevalentemente UDP (voce), aggiunge perdita senza indurre un backoff. Non abilitare WRED nella LLQ.

Esempio (shaping padre con CBWFQ/LLQ e WRED figli):

undefined

!

undefined

!

undefined

Punti chiave di progettazione:

• Applicare sempre lo shaping alla velocità del più basso collo di bottiglia a valle che si controlla; lasciare che sia il proprio sistema di accodamento a decidere, non il meccanismo di scarto del provider.
• Dimensionare la LLQ in base al codec e al volume di chiamate; includere un 5–10% di overhead per gli header e la variabilità del VAD.
• Abilitare WRED solo dove dominano i flussi TCP multiplati; regolare i pesi in modo conservativo per prevenire scarti prematuri.

QoS su tunnel e link WAN

I tunnel e la crittografia oscurano gli header interni e modificano l’MTU, influenzando la classificazione e la frammentazione.

• GRE/DMVPN e IPsec

  • Senza una gestione speciale, la classificazione vede solo gli header esterni. Utilizzare qos pre-classify sulle interfacce tunnel in modo che il dispositivo classifichi sulla 5-tupla interna e sul DSCP prima dell’incapsulamento/crittografia.
  • Preservare o copiare il DSCP nell’header esterno per mantenere il comportamento QoS della rete durante il transito.
  • Regolare MTU e MSS per evitare la frammentazione e i fallimenti del PMTUD; per IPsec, su alcune piattaforme e carrier potrebbe essere richiesta la frammentazione post-crittografia (fragmentation after-encryption).

• QoS per-tunnel e design gerarchico

  • Su mGRE/DMVPN, applicare un QoS gerarchico (shaping per-tunnel, poi LLQ/CBWFQ per classe) per garantire una condivisione equa tra gli spoke.
  • Quando i circuiti del provider impongono un CIR con policer rigidi, effettuare lo shaping al valore del CIR o leggermente al di sotto per evitare i tail drop del provider.

Esempio (QoS hub/spoke DMVPN su tunnel): interface Tunnel30 ip address 10.0.30.1 255.255.255.0 tunnel mode gre multipoint qos pre-classify ip mtu 1400 ip tcp adjust-mss 1360 service-policy output PM-WAN-PARENT ! crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac crypto ipsec profile DMVPN-PROFILE set transform-set TS ! ! Dipendente dalla piattaforma: crypto ipsec fragmentation after-encryption

Errori comuni e mitigazioni:

• La mancanza di qos pre-classify fa sì che tutto il traffico, dopo la crittografia, ricada nella class-default, penalizzando i flussi in tempo reale.
• Un MTU/MSS errato causa il blackholing di segmenti di grandi dimensioni e prestazioni applicative irregolari; validare il path MTU end-to-end.
• L’applicazione di policy complesse a line rate su tunnel software può sovraccaricare la CPU; preferire l’offload hardware dove disponibile.

Protezione del Control-Plane (CoPP/CPPr) e Convalida Operativa

CoPP protegge la CPU del router classificando e limitando la velocità (rate-limiting) del traffico di controllo e gestione nel percorso del control-plane. CPPr aggiunge una granularità più fine utilizzando le sottointerfacce host, transit e CEF-exception.

• Fondamenti di CoPP

  • Associare le policy al control-plane, non alle interfacce dati.
  • I tipi di corrispondenza (match) comunemente supportati sono ip dscp, ip precedence e access-group. Non usare la parola chiave log nelle voci ACL referenziate da CoPP.
  • Separare i protocolli di routing critici (BGP, OSPF, RSVP/LDP ove applicabile) dal traffico di gestione best-effort (HTTP) e dal traffico di controllo massivo (esportazioni NetFlow verso la CPU in casi eccezionali). Fornire CIR generosi per i protocolli critici.

• Dettagli di CPPr

  • control-plane host governa il traffico che termina sul router (es. SSH, SNMP, sessioni di routing).
  • control-plane transit gestisce il traffico di eccezione deviato dall’hardware (punted) (es. TTL-exceeded, MTU exceeded).
  • control-plane cef-exception gestisce le deviazioni (punt) relative a CEF.
  • Applicare policy diverse per ogni sottointerfaccia per evitare danni collaterali quando una classe si comporta in modo anomalo.

• Esempio di CoPP con esclusioni e associazione corretta: ip access-list extended ACL-TELNET-EXEMPT deny tcp host 10.1.1.1 any eq 23 deny tcp host 172.16.1.1 any eq 23 permit ip any any ip access-list extended ACL-BGP permit tcp any any eq 179 permit tcp any eq 179 any ip access-list extended ACL-HTTP permit tcp any any eq 80 permit tcp any any eq 443 ! class-map match-any CM-BGP match access-group name ACL-BGP class-map match-any CM-HTTP match access-group name ACL-HTTP class-map match-any CM-TELNET match access-group name ACL-TELNET-EXEMPT ! policy-map PM-COPP class CM-BGP police cir 256000 conform-action transmit exceed-action transmit class CM-HTTP police cir 64000 conform-action transmit exceed-action drop class CM-TELNET police cir 100000 conform-action transmit exceed-action drop class class-default police cir 32000 conform-action transmit exceed-action drop ! ! Assicurarsi che la policy sia sul control-plane e non sulle interfacce dati: no interface GigabitEthernet0/0 service-policy input PM-COPP control-plane service-policy input PM-COPP

Note:

• Limitare la velocità di BGP in modo troppo aggressivo può causare la perdita di keepalive, reset delle sessioni e churn delle rotte. Se è necessario applicare il policing, impostare un CIR sufficiente e considerare exceed-action transmit per evitare scarti durante i picchi di traffico.

• Esentare specifiche sorgenti di gestione attendibili usando deny nelle ACL prima del permit; applicare l’ACL come match all’interno della classe pertinente.

• Complementi al management-plane

  • IPv6 RA Guard blocca i Router Advertisement malevoli (rogue) sulle porte L2 ma non può proteggere quando l’RA è incapsulato in un tunnel; applicare la protezione agli endpoint del tunnel o usare l’autenticazione dove possibile.
  • IPv6 Source Guard utilizza la binding table per permettere solo indirizzi sorgente validi; scarta il traffico da sorgenti IPv6 sconosciute/non allocate sulle porte di accesso, riducendo il traffico di eccezione destinato alla CPU.
  • L’hardening del dispositivo (disabilitare i servizi non utilizzati, usare ACL sulle vty, limitare le community SNMP) riduce l’esposizione del control-plane.

• Convalida e contatori

  • Usare show policy-map interface <int> e show policy-map control-plane per verificare i conteggi dei pacchetti, gli scarti (drop) e le azioni di policing. Eseguire prima show policy-map control-plane quando compaiono sintomi di CPU sovraccarica (es. SSH lento, SNMP intermittente).
  • Sulle piattaforme con forwarding hardware, correlare con show platform hardware qfp active statistics drop o contatori ASIC equivalenti per gli scarti WRED/tail drop.
  • Per le code, controllare la profondità delle code (queue depth), gli scarti tail/WRED e il policing della coda prioritaria usando show policy-map interface e show queueing interface.
  • Cercare sintomi a livello applicativo:
    • Jitter, perdita di pacchetti o audio a scatti nella voce suggeriscono che la LLQ è troppo piccola o il trust boundary è errato.
    • SSH lento o che si disconnette, ma con ping normali, può indicare che CoPP sta applicando il policing al traffico di gestione.
    • SNMP intermittente è correlato a scarti nella classe di gestione o a deviazioni (punt) di eccezioni CEF che superano i limiti.
    • Il collasso del throughput TCP sotto carico con un aumento degli scarti WRED è un comportamento atteso; con solo tail drop, cercare flussi a dente di sega sincronizzati.

Scenario Pratico

Acme Engineering gestisce una rete DMVPN single-hub su banda larga Internet con IPsec+mGRE. Gli utenti segnalano VoIP a scatti verso la sede centrale (HQ), polling SNMP intermittente dei router delle filiali e connessioni SSH lente o che si disconnettono verso l’hub durante le ore di punta.

1. Stabilire i trust boundary e rimarcare il traffico all’edge

• Motivazione: Solo i telefoni e gli uplink attendibili possono impostare EF/CS3; tutto il resto del traffico di accesso viene rimarcato a BE. Questo previene l’abuso di priorità che potrebbe penalizzare le classi real-time.

2. Implementare QoS gerarchico sul tunnel DMVPN

• Motivazione: Applicare uno shaper padre (parent) al tunnel alla velocità misurata del provider (es. 20 Mbps) per evitare il policing a monte. Sotto il parent, usare LLQ per la voce (EF), classi di banda per video e dati critici, WRED per le classi dominate da TCP e fair-queue per il traffico di default. Questo localizza la gestione della congestione prima che il carrier scarti i pacchetti.

3. Abilitare qos pre-classify e regolare MTU/MSS

• Motivazione: qos pre-classify assicura che la policy corrisponda all’IP/porta/DSCP interno prima dell’incapsulamento GRE/IPsec. ip mtu 1400 e ip tcp adjust-mss 1360 prevengono la frammentazione/blackholing dovuti all’overhead di incapsulamento. La frammentazione post-cifratura (after-encryption) è impostata per adattarsi al comportamento del provider.

4. Rimuovere la CoPP applicata all’interfaccia e associarla al control-plane

• Motivazione: CoPP deve proteggere la CPU indipendentemente dall’interfaccia di ingresso. Rimuovere qualsiasi service-policy input dalle interfacce fisiche e applicare PM-COPP al control-plane per governare centralmente il traffico deviato (punted) e quello che termina sull’host.

5. Creare classi CoPP distinte con CIR sicuri; esentare le sorgenti attendibili

• Motivazione: Inserire BGP in una classe separata con un CIR sufficiente per keepalive e picchi di traffico; configurare conform/exceed transmit per evitare reset di sessione. Applicare un policing a basso rate per HTTP/HTTPS per limitare la gestione web verso la CPU. Per le eccezioni Telnet/SSH, negare gli IP di gestione attendibili nell’ACL in modo che la policy non li limiti, pur controllando tutte le altre sorgenti.

6. Convalidare e iterare basandosi su contatori e sintomi

• Motivazione: Usare show policy-map control-plane per confermare che gli scarti del traffico di gestione corrispondano ai problemi osservati su SSH/SNMP; regolare i CIR finché gli scarti non cessano. Usare show policy-map interface Tunnel30 per verificare l’utilizzo della LLQ e assicurarsi che non si verifichi un policing per overflow della priorità durante un volume di chiamate normale. Monitorare gli scarti WRED e tail drop nelle classi critiche; se la qualità della voce rimane scarsa senza scarti nella LLQ, aumentare leggermente la percentuale della LLQ; se si verificano scarti, dimensionare più accuratamente la LLQ e lo shaper padre in base al codec e alla larghezza di banda.

Applicando un trust boundary corretto, modellando il traffico prima del collo di bottiglia, classificando prima dell’incapsulamento e proteggendo il control-plane con policy CoPP/CPPr adeguatamente dimensionate, Acme Engineering ripristina la qualità della voce e stabilizza l’accesso di gestione senza sacrificare il throughput complessivo.

← Routing e Distribuzione Multicast · Tutti i domini · VPN →

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