La Quality of Service (QoS) serve a gestire in modo differenziato il traffico quando la banda è limitata e la congestione inevitabile. Su piattaforme IOS/IOS-XE il framework di riferimento è la Modular QoS CLI (MQC), che struttura ogni policy in tre blocchi: cosa selezionare, cosa farci, dove applicarla.

Il modello DiffServ: DSCP e PHB

L’approccio moderno è DiffServ (Differentiated Services), che marca ogni pacchetto e delega ai nodi il trattamento hop-by-hop, senza mantenere stato per flusso (a differenza di IntServ/RSVP).

  • Il campo DSCP occupa i 6 bit più significativi del byte ToS/Traffic Class (IPv4 e IPv6): 64 valori possibili.
  • Ogni valore determina un PHB (Per-Hop Behavior), cioè il comportamento locale del router.
PHB DSCP tipico Uso
EF (Expedited Forwarding) 46 Voce RTP, bassa latenza/jitter
AF (Assured Forwarding) AFxy (es. AF41=34) Video, dati critici, con drop probability
CS (Class Selector) CS0-CS7 Retrocompatibilità con IP Precedence
Default (BE) 0 Best effort

Nota chiave: negli AFxy, la prima cifra (x) indica la classe/coda, la seconda (y) la drop precedence (più alta = scartato prima in congestione).

Classification e marking

  • Classification: identificare il traffico (ACL, DSCP in ingresso, NBAR2, protocollo, interfaccia).
  • Marking: scrivere il valore DSCP/CoS così che i nodi successivi si fidino della marcatura (trust boundary). Va posizionato il più vicino possibile alla sorgente, tipicamente sull’access switch o sul telefono IP.

Policing vs Shaping

Distinzione centrale e fonte classica di errori:

Aspetto Policing Shaping
Traffico in eccesso scartato o rimarcato bufferizzato e ritardato
Effetto sul rate picchi tagliati subito rate “livellato” nel tempo
Direzione tipica inbound o outbound solo outbound
Buffer/coda no sì
Impatto latenza nullo aumenta (introduce ritardo)
Uso tipico enforcement contrattuale, anti-abuso adattarsi a un CIR del provider

Il policing usa un token bucket con CIR, Bc, Be: conforme → transmit, in eccesso → può fare drop oppure set-dscp-transmit (rimarca, es. da AF41 ad AF43). Lo shaping trattiene i pacchetti in coda e li rilascia gradualmente: ideale quando l’access rate fisico supera il rate acquistato e si vuole evitare che il provider faccia policing scartando i tuoi pacchetti.

Congestion management: CBWFQ e LLQ

  • CBWFQ (Class-Based Weighted Fair Queuing) assegna a ciascuna class una banda garantita (bandwidth) durante la congestione. Ottimo per dati e video, ma non garantisce bassa latenza: le code vengono servite in modo weighted, non prioritario.
  • LLQ (Low Latency Queuing) = CBWFQ + una priority queue. Il comando priority crea una coda servita per prima, indispensabile per voce EF e real-time.

Punto d’esame cruciale: la priority queue di LLQ ha un policer implicito. La banda dichiarata con priority è anche un tetto massimo: in congestione il traffico oltre quel valore viene scartato. Questo protegge le altre code dalla starvation. Fuori congestione, invece, la priority queue può eccedere il valore configurato.

policy-map WAN-QOS
 class VOICE
  priority percent 10        ! coda prioritaria + policer implicito
 class VIDEO
  bandwidth percent 30       ! banda garantita, non prioritaria
 class class-default
  fair-queue

I tre pilastri MQC:

  1. class-map → definisce il match (con match-all o match-any).
  2. policy-map → associa azioni (marking, policing, shaping, queuing) alle class.
  3. service-policy input|output → applica la policy all’interfaccia.

QoS wireless

Nelle reti wireless il piano dati usa 802.11e / WMM con quattro access category (Voice, Video, Best Effort, Background). La mappatura DSCP ↔ UP (User Priority) avviene sul WLC/access point. Con l’architettura CAPWAP, la QoS deve essere mantenuta anche sull’header esterno del tunnel tra AP e WLC, altrimenti la marcatura del pacchetto interno resta invisibile ai nodi wired intermedi.

Trappole tipiche d’esame

  • Scenario: il provider scarta traffico oltre il CIR e vuoi evitare le perdite → risposta: applica shaping in uscita (bufferizza), non policing (che scarterebbe anche lui).
  • Scenario: serve tagliare subito il traffico oltre una soglia senza introdurre ritardo → risposta: policing (drop o remark), perché shaping aggiungerebbe latenza.
  • Scenario: la voce EF ha jitter alto nonostante CBWFQ con bandwidth → risposta: usa LLQ con priority; bandwidth garantisce banda ma non priorità/latenza.
  • Scenario: durante congestione la voce in priority queue viene scartata inaspettatamente → risposta: è il policer implicito di LLQ; il valore priority è anche un limite massimo, va dimensionato correttamente.
  • Scenario: pacchetto AF41 conforme deve restare AF41, l’eccesso va “declassato” non scartato → risposta: policing con azione set-dscp-transmit (remark), non drop.