DSCP-märkning eller leverantörens QoS-löfte? Ingen av dem är ett avtal

Något märks, en kö konfigureras och sedan frågar någon vilken kvalitet designen egentligen garanterar. Det ärliga svaret är att du har beskrivit två halvor av ett avtal som möts vid en gräns. Tills du kan namnge den klass som leverantören accepterar och den behandling som den tillämpar är den lokala konfigurationen en avsikt, inte ett löfte. Båda halvorna spelar roll, och ingen av dem kan härledas från den andra.

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

Där en korrekt märkning kan dö tyst

Börja med att skriva ned, per arbetsbelastning, det lokala matchningsvillkoret, all märkning som sker inuti en tunnel, det värde som leverantören accepterar och den serviceklass som värdet väljer. Fyra kolumner, och felen bor oftast mellan den andra och den tredje.

Märkningsbeteendet från inre till yttre header är det klassiska problemet. Ett paket i en krypterad eller tunnlad väg bär en inre header som din klassificerare kan se och en yttre header som leverantörens utrustning kan se, och att kopiera den ena till den andra är ett konfigurationsbeslut, inte en automatisk egenskap. Märk bara den inre headern och leverantören klassificerar den yttre, vanligtvis som standard, och därför kan ett korrekt märkt flöde anlända i fel klass utan en enda felkonfigurerad rad på din sida.

En lokalt namngiven klass kan också stå tom eftersom dess matchningsvillkor aldrig utlöses på riktiga paket. Portar flyttar sig, applikationer använder flera flöden, och en matchning på en känd port som leverantören slutade använda två utgåvor tidigare ger en kö med räknare på noll och en policy som ser perfekt ut i den körande konfigurationen.

Bestäm uttryckligen var märkning är betrodd. Att befordra allt som delar en tunnel befordrar också bulköverföringar tillsammans med samtalen, och en leverantör som accepterar din märkning utan validering erbjuder dig ett sätt att skada dig själv. Om avtalet tillåter gatewayen att märka om vid överlämningen, skriv det, för det är just där två teams antaganden brukar gå isär.

Vad schemaläggaren egentligen fördelar

Lokal policy har sin egen semantik, och den som orsakar mest missförstånd är ordet “remaining”. På de plattformar som IOS XE-schemaläggningsguiden beskriver sätter bandwidth remaining percent en överskottsvikt, inte ett steg i en sekvens där varje klass tar en del av det som föregående klass lämnade. Otilldelade procent fördelas över lämpliga okonfigurerade köer i stället för att reserveras för den sista klassen i filen.

Den skillnaden spelar roll eftersom den sekventiella tankemodellen ger förutsägelser som aldrig stämmer med räknarna. Ingenjörer ordnar om klasser för att ändra ett resultat, ser ingen skillnad och drar slutsatsen att plattformen är trasig, medan konfigurationen aldrig betydde det de antog.

En överordnad shaper är den andra vanliga överraskningen. Att shapa en kontrollerad kö ned till den användbara servicefrekvensen är ofta avsiktligt, eftersom det flyttar överbelastningspunkten till en enhet du administrerar i stället för till en uppströms kö du inte administrerar. Att ta bort shapern eftersom shapning lägger till fördröjning kan flytta förlusten i stället för att ta bort den, och overheadredovisning eller en leverantörspolicer kan göra den effektiva frekvensen lägre än gränssnittet antyder.

Räknarna visar vilken halva som misslyckades

Jämför fyra tal i den drabbade riktningen: vad som erbjöds, vad klassen matchade, vad som köades eller tappades, och vad tjänsten faktiskt levererade. Håll arbetsbelastningsbeskrivningen och policyversionen bredvid observationen, för en skärmbild av räknare utan dem kan inte återskapas.

Grenarna är olika problem med olika ägare. En lokal klass som inte matchar något är ett klassificeringsfel på din sida. En klass som matchar, köar och tappar medan leverantören rapporterar ren leverans pekar på din egen schemaläggare eller shaper. En klass som ser korrekt ut lokalt medan förlust uppträder bortom överlämningen pekar på operatörens mappning och den uppmätta gränsen i avtalet. Ingen av de tre åtgärdas genom att redigera de andra, och därför måste talen samlas in tillsammans.

RFC 2475 ramar in klassificering och konditionering som arbete som utförs inom administrativa domäner, och just därför kan en märkning inte reservera köer från ände till ände. IOS XE-schemaläggningsguiden är referensen för det överskottsviktsbeteende som beskrivs ovan, och dess plattformsjämförelser är värda att läsa innan en beräknad frekvens flyttas mellan modeller.

Skriv avtalet på ett ställe

Sätt den lokala matchningen, tillitsgränsen, leverantörsklassen och den uppmätta servicenivån i ett enda dokument som båda parter undertecknar. Då har en procentändring en kontext, och ett kvalitetsklagomål har en ägare.

Att ändra en lokal procent kan inte reparera en annan kös garanti, och inget märkningsschema överlever en mappning som leverantören inte respekterar. Jämför halvorna, namnge gränsen och citera först då ett tal.