DSCP-markering eller udbyderens QoS-løfte? Ingen af delene er en kontrakt

Noget bliver markeret, en kø bliver konfigureret, og så spørger nogen, hvilken kvalitet designet egentlig garanterer. Det ærlige svar er, at du har beskrevet to halvdele af en kontrakt, der mødes ved en grænse. Indtil du kan navngive den klasse, udbyderen accepterer, og den behandling, den anvender, er den lokale konfiguration en hensigt snarere end et løfte. Begge halvdele betyder noget, og ingen af dem kan udledes af den anden.

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

Hvor en korrekt markering kan dø stille

Begynd med at skrive ned, for hver arbejdsbyrde, den lokale matchbetingelse, enhver markering der sker inde i en tunnel, den værdi udbyderen accepterer, og den serviceklasse som den værdi vælger. Fire kolonner, og fejlene bor som regel mellem den anden og den tredje.

Adfærd for markering fra indre til ydre header er det klassiske problem. En pakke inde i en krypteret eller tunelleret vej bærer en indre header, som din klassifikator kan se, og en ydre header, som udbyderens udstyr kan se, og at kopiere den ene til den anden er en konfigurationsbeslutning snarere end en automatisk egenskab. Markér kun den indre header, og udbyderen klassificerer den ydre, normalt som standard, og derfor kan et korrekt markeret flow ankomme i den forkerte klasse uden en eneste fejlkonfigureret linje på din side.

En lokalt navngivet klasse kan også stå tom, fordi dens matchbetingelse aldrig udløses på rigtige pakker. Porte flytter sig, applikationer bruger flere flows, og et match på en velkendt port, som leverandøren holdt op med at bruge to udgivelser tidligere, giver en kø med tællere på nul og en politik, der ser perfekt ud i den kørende konfiguration.

Beslut udtrykkeligt, hvor markeringer er betroet. At forfremme alt, der deler en tunnel, forfremmer bulkoverførsler sammen med opkaldene, og en udbyder, der accepterer din markering uden validering, tilbyder dig en måde at skade dig selv på. Hvis kontrakten tillader gatewayen at ommarkere ved overdragelsen, så skriv det, for det er præcis det punkt, hvor to teams antagelser normalt divergerer.

Hvad planlæggeren egentlig fordeler

Lokal politik har sin egen semantik, og den, der skaber mest misforståelse, er ordet “remaining”. På de platforme, som IOS XE-planlægningsvejledningen beskriver, sætter bandwidth remaining percent en overskydende vægt, ikke et trin i en sekvens, hvor hver klasse tager en del af det, den foregående klasse efterlod. Ikke-tildelte procenter fordeles over egnede ukonfigurerede køer i stedet for at blive reserveret til den sidste klasse i filen.

Den forskel betyder noget, fordi den sekventielle tankemodel giver forudsigelser, der aldrig passer med tællerne. Ingeniører omarrangerer klasser for at ændre et resultat, ser ingen forskel og konkluderer, at platformen er i stykker, mens konfigurationen aldrig betød det, de antog.

En overordnet shaper er den anden almindelige overraskelse. At shape en kontrolleret kø ned til den brugbare servicerate er ofte bevidst, fordi det flytter overbelastningspunktet til en enhed, du administrerer i stedet for en opstrøms kø, du ikke administrerer. At fjerne shaperen, fordi shaping tilføjer forsinkelse, kan flytte tabet i stedet for at fjerne det, og overheadregnskab eller en udbyder-policer kan gøre den effektive rate lavere, end interfacet antyder.

Tællerne fortæller, hvilken halvdel der fejlede

Sammenlign fire tal i den berørte retning: hvad der blev tilbudt, hvad klassen matchede, hvad der blev sat i kø eller droppet, og hvad tjenesten faktisk leverede. Hold arbejdsbyrdebeskrivelsen og politikversionen ved siden af observationen, for et skærmbillede af tællere uden dem kan ikke gengives.

Grenene er forskellige problemer med forskellige ejere. En lokal klasse, der ikke matcher noget, er en klassificeringsfejl på din side. En klasse, der matcher, stiller i kø og dropper, mens udbyderen rapporterer ren levering, peger på din egen planlægger eller shaper. En klasse, der ser korrekt ud lokalt, mens tab vises ud over overdragelsen, peger på operatørens mapping og den målte grænse i kontrakten. Ingen af de tre rettes ved at redigere de andre, og derfor skal tallene indsamles sammen.

RFC 2475 beskriver klassificering og konditionering som arbejde, der udføres inde i administrative domæner, og netop derfor kan en markering ikke reservere køer end-to-end. IOS XE-planlægningsvejledningen er reference for den overskydende vægt-adfærd beskrevet ovenfor, og dens platformsammenligninger er værd at læse, før en beregnet rate flyttes mellem modeller.

Skriv kontrakten ét sted

Sæt det lokale match, tillidsgrænsen, udbyderklassen og det målte serviceniveau i ét dokument, som begge parter underskriver. Så har en procentændring en kontekst, og en kvalitetsklage har en ejer.

At ændre en lokal procent kan ikke reparere en anden køs garanti, og ingen markeringsordning overlever en mapping, som udbyderen ikke overholder. Sammenlign halvdelene, navngiv grænsen, og først derefter citer et tal.