Il QoS per tunnel non limita l’uplink totale del tuo hub

La convinzione suona come aritmetica: cinque spoke, ciascuno sagomato a 5 Mbit/s, quindi l’hub trasporta 25 Mbit/s al massimo. La prima metà è vera e la conclusione no. Una politica per tunnel si applica una volta per tunnel, non una volta per hub, e l’uplink condiviso che tutti e cinque i tunnel attraversano non compare mai in quel calcolo. La congestione sull’uplink sopravvive esattamente com’era.

Da dove viene la convinzione

La confusione è comprensibile, perché le informazioni di gruppo NHRP consentono a un’unica definizione di politica di valere per un intero insieme di spoke. Questo si legge come un budget condiviso in un file di configurazione. Ciò che significa davvero è che ogni spoke riceve la propria istanza di quella definizione.

Quindi 5 Mbit/s per spoke è un tetto per tunnel, e ci sono tanti tetti quanti sono i tunnel.

Cosa controlla una singola istanza di politica

La guida Cisco al QoS per tunnel in DMVPN su IOS XE descrive una politica di uscita dall’hub selezionata tramite informazioni di gruppo NHRP e applicata separatamente a ogni spoke. Da quella frase derivano due limiti, ed entrambi vengono ignorati. La velocità appartiene a un solo spoke e non a un secchio condiviso, e la funzione governa il traffico dall’hub verso lo spoke, non il contrario.

Pianifica la direzione di invio dello spoke in modo indipendente. Nulla in una politica di uscita dall’hub limita ciò che una sede carica.

Metti il limite aggregato al collo di bottiglia condiviso

L’aggregato deve essere sagomato dove compete davvero: sull’interfaccia fisica che tutti i tunnel condividono. Cisco documenta uno shaper class-default sull’interfaccia fisica come politica fisica concorrente supportata per questa funzione, che è un’affermazione più stretta di qualsiasi gerarchia tu possa digitare. Dai per scontato che la seconda politica fisica arbitraria che hai inventato non sia supportata finché qualcuno non dimostra il contrario.

Poi decidi cosa succede quando tutti gli spoke sono occupati insieme. Quale traffico viene ammesso, quale classe ha priorità e quale coda possiede la contesa. Un tetto per spoke non risponde a nessuna di queste domande, perché ogni spoke viene considerato da solo.

Allinea le unità di sagomatura e la contabilità dell’overhead alla consegna effettiva. L’overhead di incapsulamento che lasci fuori dal calcolo della velocità si manifesta come un collegamento che si satura prima del numero configurato.

I contatori mentono in un modo preciso

Leggi i contatori al livello che stai sagomando. La stessa guida Cisco avverte che i contatori delle politiche dell’interfaccia principale possono essere imprecisi in questa configurazione. È un’avvertenza sul contatore, non la prova che una classe corrisponda o scarti. Tienila separata dal risultato dell’applicazione, che è l’unica cosa che l’utente sperimenta.

Copiare un vecchio esempio di traffic-shape accanto a una policy-map non correlata non dimostra che le due velocità controllino gli stessi pacchetti.

Prova l’aggregato, non solo il tetto

Inizia con un solo spoke occupato e conferma che raggiunga il suo tetto. Poi offri traffico da tutti insieme secondo un piano approvato, e osserva l’interfaccia fisica accanto ai numeri per tunnel. Se ogni spoke resta al suo tetto mentre l’uplink è saturo e la latenza sale, la politica per spoke funziona esattamente come progettata e il budget è ancora sbagliato.

La correzione a quel punto è una decisione di capacità o di ammissione. Ritoccare i numeri per spoke cambia solo quale sede si lamenta per prima.