DSCP-merking eller QoS-løftet til leverandøren? Ingen av delane er ein kontrakt

Noko blir merkt, ein kø blir konfigurert, og så spør nokon kva kvalitet designet eigentleg garanterer. Det ærlege svaret er at du har skildra to halvdelar av ein kontrakt som møtest ved ei grense. Inntil du kan namngje klassen leverandøren godtek og handsaminga han nyttar, er den lokale konfigurasjonen ein intensjon og ikkje eit løfte. Begge halvdelane betyr noko, og ingen av dei kan utleiast av den andre.

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

Kor ei korrekt merking kan døy stille

Byrja med å skrive ned, per arbeidsbelastning, den lokale matchbetingelsen, kvar merking som skjer inne i ein tunnel, verdien leverandøren godtek, og tenesteklassen som den verdien vel. Fire kolonnar, og feila bur som regel mellom den andre og den tredje.

Merkeåtferd frå indre til ytre header er det klassiske problemet. Ein pakke inne i ein kryptert eller tunellert veg ber ein indre header som klassifiseraren din kan sjå og ein ytre header som utstyret til leverandøren kan sjå, og å kopiere den eine til den andre er eit konfigurasjonsval, ikkje ein automatisk eigenskap. Merk berre den indre headeren, og leverandøren klassifiserer den ytre, vanlegvis som standard, og difor kan ein korrekt merkt flyt kome i feil klasse utan ein einaste feilkonfigurert linje på di side.

Ein lokalt namngjeven klasse kan også stå tom fordi matchbetingelsen aldri blir utløyst på ekte pakkar. Portar flyttar seg, applikasjonar brukar fleire flytar, og ein match på ein kjend port som leverandøren slutta å bruke to utgjevingar tidlegare, gjev ein kø med teljarar på null og ein policy som ser perfekt ut i den køyrande konfigurasjonen.

Avgjer eksplisitt kvar merking er trudd. Å fremje alt som deler ein tunnel fremjar også massetransport saman med samtalane, og ein leverandør som godtek merkinga di utan validering tilbyr deg ein måte å skade deg sjølv på. Viss kontrakten lèt gatewayen merke på nytt ved overleveringa, skriv det, for det er nettopp der antakingane til to lag vanlegvis går frå kvarandre.

Kva planleggjaren eigentleg fordeler

Lokal policy har si eiga semantikk, og den som skapar mest mistyding er ordet “remaining”. På plattformene som IOS XE-planleggingsrettleiinga skildrar, set bandwidth remaining percent ei overskotsvekt, ikkje eit steg i ein sekvens der kvar klasse tek ein del av det den førre klassen lét etter seg. Ikkje-tildelte prosent blir fordelte over eigna ukonfigurerte køar i staden for å bli reserverte for den siste klassen i fila.

Den skilnaden betyr noko fordi den sekvensielle tankemodellen gjev spådommar som aldri passar med teljarane. Ingeniørar omorganiserer klassar for å endre eit resultat, ser ingen skilnad og konkluderer med at plattforma er øydelagd, medan konfigurasjonen aldri meinte det dei antok.

Ein overordna shaper er den andre vanlege overraskinga. Å shape ein kontrollert kø ned til den brukbare tenestefrekvensen er ofte medvite, fordi det flyttar overbelastningspunktet til eininga du administrerer i staden for ein oppstraums kø du ikkje administrerer. Å fjerne shaperen fordi shaping legg til forseinking kan flytte tapet i staden for å fjerne det, og overheadrekneskap eller ein leverandør-policer kan gjere den effektive frekvensen lågare enn grensesnittet antydar.

Teljarane viser kva halvdel som svikta

Samanlikn fire tal i den råka retninga: kva som vart tilbode, kva klassen matcha, kva som vart sett i kø eller sleppt, og kva tenesta faktisk leverte. Hald arbeidsbelastningsskildringa og policyversjonen ved sida av observasjonen, for eit skjermbilete av teljarar utan dei kan ikkje gjerast om att.

Greinene er ulike problem med ulike eigarar. Ein lokal klasse som ikkje matchar noko, er ein klassifiseringsfeil på di side. Ein klasse som matchar, stiller i kø og slepp medan leverandøren rapporterer rein levering, peikar på din eigen planleggjar eller shaper. Ein klasse som ser korrekt ut lokalt medan tap viser seg utanfor overleveringa, peikar på kartlegginga til operatøren og den målte grensa i kontrakten. Ingen av dei tre blir retta ved å endre dei andre, og difor må tala samlast inn saman.

RFC 2475 rammar inn klassifisering og kondisjonering som arbeid utført inne i administrative domene, og nettopp difor kan ei merking ikkje reservere køar ende-til-ende. IOS XE-planleggingsrettleiinga er referansen for overskotsvektåtferda skildra ovanfor, og plattformsamanlikningane er verdt å lese før ein berekna frekvens blir flytta mellom modellar.

Skriv kontrakten på éin stad

Set den lokale matchen, tillitsgrensa, leverandørklassen og det målte tenestenivået i eitt dokument som begge partar signerer. Då har ei prosentendring ein kontekst, og ei kvalitetsklage har ein eigar.

Å endre ein lokal prosent kan ikkje reparere garantien til ein annan kø, og ingen merkingsordning overlever ei kartlegging som leverandøren ikkje respekterer. Samanlikn halvdelane, namngje grensa, og først då sitere eit tal.