Marcatura DSCP o promessa QoS del provider? Nessuna delle due è un contratto

Qualcosa viene marcato, una coda viene configurata, e poi qualcuno chiede quale qualità il progetto garantisca davvero. La risposta onesta è che avete descritto due metà di un contratto che si incontrano a un confine. Finché non potete nominare la classe che il provider accetta e il trattamento che applica, la configurazione locale è un'intenzione, non una promessa. Entrambe le metà contano, e nessuna può essere dedotta dall'altra.

local match → queue and marking → provider classifier
  → provider treatment → destination

Dove una marcatura corretta può morire in silenzio

Iniziate annotando, per ogni carico di lavoro, la condizione di corrispondenza locale, qualsiasi marcatura che avvenga dentro un tunnel, il valore che il provider accetta e la classe di servizio che quel valore seleziona. Quattro colonne, e i guasti di solito vivono tra la seconda e la terza.

Il comportamento di marcatura dall'interno all'esterno è il problema classico. Un pacchetto dentro un percorso cifrato o incapsulato porta un'intestazione interna che il vostro classificatore vede e un'intestazione esterna che l'apparecchiatura del provider vede, e copiare l'una nell'altra è una decisione di configurazione, non una proprietà automatica. Marcate solo l'intestazione interna e il provider classifica quella esterna, di solito come predefinita, per cui un flusso marcato correttamente può arrivare nella classe sbagliata senza una sola riga mal configurata dalla vostra parte.

Una classe denominata localmente può anche restare vuota perché la sua condizione di corrispondenza non scatta mai sui pacchetti reali. Le porte si spostano, le applicazioni usano più flussi, e una corrispondenza su una porta nota che il fornitore ha smesso di usare due release fa produce una coda con contatori a zero e una policy che nella configurazione in esecuzione sembra perfetta.

Decidete esplicitamente dove si fidano le marcature. Promuovere tutto ciò che condivide un tunnel promuove anche i trasferimenti di massa insieme alle chiamate, e un provider che accetta la vostra marcatura senza validazione vi offre un modo per farvi male. Se il contratto consente al gateway di rimarcare alla consegna, ditelo per iscritto, perché è proprio il punto in cui le ipotesi di due team di solito divergono.

Che cosa divide realmente lo scheduler

La policy locale ha la sua semantica, e quella che causa più fraintendimenti è la parola “remaining”. Sulle piattaforme descritte dalla guida alla schedulazione di IOS XE, bandwidth remaining percent imposta un peso in eccesso, non un passo di una sequenza in cui ogni classe prende una porzione di ciò che la classe precedente ha lasciato. Le percentuali non assegnate vengono distribuite tra le code idonee non configurate invece di essere riservate all'ultima classe del file.

Questa distinzione conta perché il modello mentale sequenziale produce previsioni che non corrispondono mai ai contatori. Gli ingegneri riordinano le classi per cambiare un risultato, non vedono differenze e concludono che la piattaforma è rotta, quando la configurazione non ha mai significato ciò che supponevano.

Il modellatore padre è l'altra sorpresa comune. Modellare una coda controllata fino alla velocità di servizio utilizzabile è spesso deliberato, perché sposta il punto di congestione su un dispositivo che amministrate voi invece che su una coda a monte che non amministrate. Rimuovere il modellatore perché la modellazione aggiunge ritardo può spostare la perdita invece di eliminarla, e la contabilizzazione dell'overhead o un policer del provider possono rendere la velocità effettiva inferiore a quella suggerita dall'interfaccia.

I contatori dicono quale metà ha fallito

Confrontate quattro numeri nella direzione interessata: cosa è stato offerto, cosa ha intercettato la classe, cosa è stato messo in coda o scartato e cosa il servizio ha effettivamente consegnato. Tenete la descrizione del carico di lavoro e la versione della policy accanto all'osservazione, perché uno screenshot dei contatori senza di esse non è riproducibile.

I rami sono problemi diversi con proprietari diversi. Una classe locale che non corrisponde a nulla è un difetto di classificazione dalla vostra parte. Una classe che corrisponde, si accoda e scarta mentre il provider segnala una consegna pulita indica il vostro scheduler o modellatore. Una classe che sembra corretta localmente mentre la perdita appare oltre la consegna indica la mappatura dell'operatore e il confine misurato nel contratto. Nessuna delle tre si risolve modificando le altre, per questo i numeri vanno raccolti insieme.

RFC 2475 inquadra classificazione e condizionamento come lavoro svolto all'interno di domini amministrativi, ed è proprio per questo che una marcatura non può riservare code da un capo all'altro. La guida alla schedulazione di IOS XE è il riferimento per il comportamento di peso in eccesso descritto sopra, e vale la pena leggere i suoi confronti tra piattaforme prima di spostare una velocità calcolata tra modelli.

Scrivete il contratto in un solo posto

Mettete la corrispondenza locale, il confine di fiducia, la classe del provider e il livello di servizio misurato in un unico documento firmato da entrambe le parti. Allora un cambio di percentuale ha un contesto, e un reclamo sulla qualità ha un proprietario.

Cambiare una percentuale locale non può riparare la garanzia di un'altra coda, e nessuno schema di marcatura sopravvive a una mappatura che il provider non rispetta. Confrontate le metà, nominate il confine, e solo allora citate un numero.