DSCP märgistamine või teenusepakkuja QoS-lubadus? Kumbki ei ole leping

Midagi märgistatakse, järjekord konfigureeritakse ja siis küsib keegi, millist kvaliteeti disain tegelikult tagab. Aus vastus on, et kirjeldasite lepingu kahte poolt, mis kohtuvad piiril. Kuni te ei suuda nimetada klassi, mida teenusepakkuja aktsepteerib, ja töötlust, mida ta rakendab, on kohalik konfiguratsioon kavatsus, mitte lubadus. Mõlemad pooled on olulised ja kumbagi ei saa teisest tuletada.

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

Kus õige märgistus võib vaikselt surra

Alustage sellest, et kirjutate iga töökoormuse kohta üles kohaliku vastavustingimuse, tunnelis toimuva märgistuse, väärtuse, mida teenusepakkuja aktsepteerib, ja teenuseklassi, mille see väärtus valib. Neli veergu, ja tõrked elavad tavaliselt teise ja kolmanda vahel.

Märgistuskäitumine sisemisest välise päisesse on klassikaline probleem. Krüpteeritud või tunneliga teel olev pakett kannab sisemist päist, mida teie klassifitseerija näeb, ja välist päist, mida teenusepakkuja seade näeb, ning ühe kopeerimine teise on konfiguratsiooniotsus, mitte automaatne omadus. Märgistage ainult sisemine päis ja teenusepakkuja klassifitseerib välise, tavaliselt vaikimisi, mistõttu õigesti märgistatud voog võib jõuda valesse klassi ilma ühegi valesti konfigureeritud realt teie poolel.

Kohalikult nimetatud klass võib samuti tühjaks jääda, sest selle vastavustingimus ei käivitu kunagi päris pakettidel. Pordid liiguvad, rakendused kasutavad mitut voogu ja vastavus tuntud pordile, mille tarnija lõpetas kasutamise kaks väljaannet tagasi, loob nulli näitude ja null-loenduritega järjekorra ning poliitika, mis töötavas konfiguratsioonis paistab täiuslik.

Otsustage selgelt, kus märgistust usaldatakse. Kõige tõstmine, mis jagab tunnelit, tõstab ka hulgiedastused koos kõnedega, ja teenusepakkuja, kes aktsepteerib teie märgistust ilma valideerimiseta, pakub teile viisi endale kahju teha. Kui leping lubab lüüsil üleandmisel ümber märgistada, öelge seda kirjalikult, sest just selles punktis lahknevad kahe meeskonna eeldused tavaliselt.

Mida planeerija tegelikult jagab

Kohalikul poliitikal on oma semantika ja kõige rohkem arusaamatusi tekitab sõna “remaining”. Platvormidel, mida IOS XE planeerimisjuhend kirjeldab, seab bandwidth remaining percent ülejäägi kaalu, mitte sammu järjestuses, kus iga klass võtab osa sellest, mille eelmine klass jättis. Määramata protsendid jaotatakse sobivate konfigureerimata järjekordade vahel, mitte ei reserveerita faili viimasele klassile.

See erinevus on oluline, sest järjestikune mõtlemudel annab ennustusi, mis ei vasta kunagi loenduritele. Insenerid järjestavad klasse ümber, et tulemust muuta, ei näe erinevust ja järeldavad, et platvorm on katki, kuigi konfiguratsioon ei tähendanud kunagi seda, mida nad eeldasid.

Ülemkihi kujundaja on teine tavaline üllatus. Kontrollitud järjekorra kujundamine kasutatava teenuskiiruseni on sageli tahtlik, sest see viib ummikupunkti seadmesse, mida teie haldate, mitte ülesvoolu järjekorda, mida te ei halda. Kujundaja eemaldamine, sest kujundamine lisab viivitust, võib kaotuse ümber paigutada, mitte kõrvaldada, ja üldkulude arvestus või teenusepakkuja politseinik võivad muuta tegeliku kiiruse väiksemaks, kui liides vihjab.

Loendurid ütlevad, milline pool ebaõnnestus

Võrrelge nelja numbrit mõjutatud suunas: mida pakuti, mida klass vastas, mis läks järjekorda või visati ära, ja mida teenus tegelikult edastas. Hoidke töökoormuse kirjeldus ja poliitika versioon vaatluse kõrval, sest loendurite ekraanipilt ilma nendeta ei ole korratav.

Harud on erinevad probleemid erinevate omanikega. Kohalik klass, mis ei vasta millelegi, on teie poolel klassifitseerimise viga. Klass, mis vastab, läheb järjekorda ja visatakse ära, samal ajal kui teenusepakkuja teatab puhtast edastamisest, osutab teie enda planeerijale või kujundajale. Klass, mis tundub kohapeal õige, samal ajal kui kadu ilmneb pärast üleandmist, osutab operaatori kaardistamisele ja lepingus mõõdetud piirile. Ühtegi kolmest ei paranda teiste muutmine, mistõttu tuleb numbrid koguda koos.

RFC 2475 raamistab klassifitseerimise ja tingimise haldusdomeenide sees tehtava tööna ja just seetõttu ei saa märgistus järjekordi otsast otsani reserveerida. IOS XE planeerimisjuhend on ülalkirjeldatud ülejäägi kaalu käitumise viide ja selle platvormivõrdlusi tasub lugeda enne, kui arvutatud kiirus mudelite vahel liigub.

Kirjutage leping ühte kohta

Pange kohalik vastavus, usalduspiir, teenusepakkuja klass ja mõõdetud teenustase ühte dokumenti, mille mõlemad pooled allkirjastavad. Siis on protsendimuutusel kontekst ja kvaliteedikaebusel omanik.

Kohaliku protsendi muutmine ei saa parandada teise järjekorra garantiid ja ükski märgistusskeem ei ela üle kaardistust, mida teenusepakkuja ei järgi. Võrrelge pooli, nimetage piir ja alles siis tsiteerige numbrit.