DSCP-merking eller leverandørens QoS-løfte? Ingen av delene er en kontrakt

Noe blir merket, en kø blir konfigurert, og så spør noen hvilken kvalitet designet egentlig garanterer. Det ærlige svaret er at du har beskrevet to halvdeler av en kontrakt som møtes ved en grense. Inntil du kan navngi klassen leverandøren godtar og behandlingen den bruker, er den lokale konfigurasjonen en intensjon og ikke et løfte. Begge halvdelene betyr noe, og ingen av dem kan utledes av den andre.

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

Hvor en korrekt merking kan dø stille

Begynn med å skrive ned, per arbeidsbelastning, den lokale matchbetingelsen, enhver merking som skjer inne i en tunnel, verdien leverandøren godtar, og tjenesteklassen som den verdien velger. Fire kolonner, og feilene bor som regel mellom den andre og den tredje.

Merkeadferd fra indre til ytre header er det klassiske problemet. En pakke inne i en kryptert eller tunnelert vei bærer en indre header som klassifisereren din kan se og en ytre header som leverandørens utstyr kan se, og å kopiere den ene til den andre er en konfigurasjonsbeslutning, ikke en automatisk egenskap. Merk bare den indre headeren, og leverandøren klassifiserer den ytre, vanligvis som standard, og derfor kan en korrekt merket flyt ankomme i feil klasse uten en eneste feilkonfigurert linje på din side.

En lokalt navngitt klasse kan også stå tom fordi matchbetingelsen aldri utløses på ekte pakker. Porter flytter seg, applikasjoner bruker flere flyter, og en match på en kjent port som leverandøren sluttet å bruke to utgivelser tidligere, gir en kø med tellere på null og en policy som ser perfekt ut i den kjørende konfigurasjonen.

Bestem eksplisitt hvor merking er betrodd. Å forfremme alt som deler en tunnel forfremmer også massetransport sammen med samtalene, og en leverandør som godtar merkingen din uten validering tilbyr deg en måte å skade deg selv på. Hvis kontrakten lar gatewayen merke på nytt ved overleveringen, skriv det, for det er nettopp der to lags antakelser vanligvis divergerer.

Hva planleggeren egentlig fordeler

Lokal policy har sin egen semantikk, og den som skaper mest misforståelse er ordet “remaining”. På plattformene som IOS XE-planleggingsveiledningen beskriver, setter bandwidth remaining percent en overskuddsvekt, ikke et trinn i en sekvens der hver klasse tar en del av det forrige klasse la igjen. Ikke-tildelte prosenter fordeles over egnede ukonfigurerte køer i stedet for å reserveres for den siste klassen i filen.

Den forskjellen betyr noe fordi den sekvensielle tankemodellen gir spådommer som aldri passer med tellerne. Ingeniører omorganiserer klasser for å endre et resultat, ser ingen forskjell og konkluderer med at plattformen er ødelagt, mens konfigurasjonen aldri betydde det de antok.

En overordnet shaper er den andre vanlige overraskelsen. Å shape en kontrollert kø ned til den brukbare tjenestefrekvensen er ofte bevisst, fordi det flytter overbelastningspunktet til en enhet du administrerer i stedet for en oppstrøms kø du ikke administrerer. Å fjerne shaperen fordi shaping legger til forsinkelse kan flytte tapet i stedet for å fjerne det, og overheadregnskap eller en leverandør-policer kan gjøre den effektive frekvensen lavere enn grensesnittet antyder.

Tellerne viser hvilken halvdel som sviktet

Sammenlign fire tall i den berørte retningen: hva som ble tilbudt, hva klassen matchet, hva som ble satt i kø eller droppet, og hva tjenesten faktisk leverte. Hold arbeidsbelastningsbeskrivelsen og policyversjonen ved siden av observasjonen, for et skjermbilde av tellere uten dem kan ikke gjenskapes.

Grenene er forskjellige problemer med forskjellige eiere. En lokal klasse som ikke matcher noe, er en klassifiseringsfeil på din side. En klasse som matcher, stiller i kø og dropper mens leverandøren rapporterer ren levering, peker på din egen planlegger eller shaper. En klasse som ser korrekt ut lokalt mens tap vises utenfor overleveringen, peker på operatørens kartlegging og den målte grensen i kontrakten. Ingen av de tre rettes ved å redigere de andre, og derfor må tallene samles inn sammen.

RFC 2475 rammer inn klassifisering og kondisjonering som arbeid utført inne i administrative domener, og nettopp derfor kan en merking ikke reservere køer ende-til-ende. IOS XE-planleggingsveiledningen er referansen for overskuddsvektadferden beskrevet ovenfor, og plattformsammenligningene er verdt å lese før en beregnet frekvens flyttes mellom modeller.

Skriv kontrakten på ett sted

Sett den lokale matchen, tillitsgrensen, leverandørklassen og det målte tjenestenivået i ett dokument som begge parter signerer. Da har en prosentendring en kontekst, og en kvalitetsklage har en eier.

Å endre en lokal prosent kan ikke reparere en annen køs garanti, og ingen merkingsordning overlever en kartlegging som leverandøren ikke respekterer. Sammenlign halvdelene, navngi grensen, og først da sitere et tall.