Il ruolo del QoS nel design enterprise

In un design ENSLD il QoS non è “aggiungere banda”, ma allocare in modo deterministico una risorsa scarsa — la coda dell’interfaccia di uscita — quando il link è congestionato. I meccanismi di queuing e congestion management entrano in gioco solo in presenza di congestione: quando l’interfaccia è scarica, i pacchetti escono nell’ordine di arrivo (FIFO) e nessuna policy di priorità ha effetto. Il compito del progettista è decidere quali flussi proteggere e quanta banda riservare prima che la congestione si manifesti.

Classificazione, marcatura e trust boundary

Ogni design QoS parte dal trust boundary: il punto più vicino possibile alla sorgente dove la rete decide se fidarsi delle marcature DSCP/CoS in arrivo o se riclassificare. Un IP phone Cisco marca la voce come EF (DSCP 46) e può essere reso trusted allo switch di accesso via CDP; un PC collegato dietro il telefono resta invece untrusted, evitando che un’applicazione marchi arbitrariamente il proprio traffico come EF. Spostare la classificazione all’edge di accesso è la scelta di design corretta: nel core si applicano soltanto le policy di scheduling, senza rimarcare. Un design tipico usa EF per la voce, AF41/CS4 per il video real-time, le classi AF per il traffico transazionale e DF (default) per il best effort.

LLQ: priority queue per voce e video real-time

LLQ (Low Latency Queuing) è CBWFQ con l’aggiunta di una strict priority queue. Il traffico assegnato con il comando priority viene servito prima di ogni altra coda, garantendo bassa latenza e basso jitter — requisito imprescindibile per voce (budget one-way ≤150 ms, jitter ≤30 ms, loss <1%) e video real-time.

Il punto chiave d’esame: la priority queue è implicitamente policed. La banda dichiarata non è solo una garanzia minima ma anche un tetto in caso di congestione: se il traffico prioritario supera il valore configurato mentre il link è congesto, l’eccesso viene scartato, non bufferizzato. Questo protegge le code CBWFQ dallo starvation da parte della priority queue.

policy-map WAN-EDGE
 class VOICE
  priority percent 10
 class VIDEO-RT
  priority percent 23

CBWFQ: bandwidth reservation per il resto

CBWFQ assegna a ciascuna classe una banda minima garantita (bandwidth) servita con scheduling weighted-fair. A differenza della priority queue, la riserva CBWFQ è un minimo, non un massimo: una classe può usare banda inaccessibile alle altre quando queste sono inattive. La classe class-default raccoglie il best effort e dovrebbe sempre mantenere una quota di banda residua utilizzabile.

Shaping e policing: due modi opposti di trattare l’eccesso

Meccanismo Comportamento sull’eccesso Impatto Uso tipico
Shaping Bufferizza e ritarda Aggiunge latenza, no drop Egress verso circuiti a velocità inferiore, TCP-friendly
Policing Scarta o rimarca No delay, causa drop/retx Ingress, enforcement contrattuale, tetto LLQ

Nel design WAN lo shaping gerarchico è la scelta corretta quando un hub a 1 Gbps invia verso spoke con CIR inferiore (es. Metro Ethernet sub-rate): si effettua lo shape al CIR e si applica la policy QoS di scheduling come child policy dentro la coda dello shaper, perché il queuing agisce solo quando esiste una coda da gestire.

Congestion avoidance con WRED

WRED (Weighted Random Early Detection) previene la congestione scartando probabilisticamente i pacchetti prima che la coda si riempia, evitando il tail drop e la conseguente TCP global synchronization (tutti i flussi TCP che rallentano e ripartono insieme, sotto-utilizzando il link). WRED usa minimum threshold, maximum threshold e mark probability denominator, e con DSCP-based WRED scarta più aggressivamente i drop-precedence alti (AFx3 prima di AFx1). Regola di design cruciale: WRED non va mai applicato alla priority queue LLQ — il traffico voce/video è UDP, non risponde al drop rallentando, e introdurre scarti casuali degrada soltanto la qualità.

Dimensionamento: la trappola della priority queue

La riserva per la priority queue deve restare entro il circa 33% della banda del link (raccomandazione Cisco per voce + video real-time). Sovradimensionarla è l’errore di design classico: poiché in congestione l’LLQ è servito per primo fino al suo tetto, una priority queue troppo grande affama il best effort e il traffico transazionale, che collassano proprio quando il link è saturo. Il progettista bilancia la garanzia real-time con banda residua sufficiente per DF e classi AF.

Trappole tipiche d’esame

  • Scenario: il cliente vuole garantire voce e video ma anche throughput dati durante i picchi → Risposta: limitare l’aggregato della priority queue a circa 33% del link; il resto in CBWFQ, best effort mai a 0.
  • Scenario: traffico voce oltre la banda configurata durante congestione → Risposta: l’eccesso viene scartato dal policer implicito dell’LLQ, non ritardato.
  • Scenario: hub 1 Gbps verso spoke con CIR 100 Mbps, drop nel provider → Risposta: shaping gerarchico al CIR con child policy di queuing, non policing.
  • Scenario: tail drop e TCP global synchronization sul best effort → Risposta: abilitare WRED (DSCP-based) sulle code dati, mai sulla priority queue.
  • Scenario: dove fidarsi delle marcature → Risposta: stabilire il trust boundary all’access edge; IP phone trusted via CDP, PC a valle untrusted.