DSCP marķējums vai pakalpojumu sniedzēja QoS solījums? Neviens no tiem nav līgums

Kaut kas tiek marķēts, rinda tiek konfigurēta, un tad kāds jautā, kādu kvalitāti dizains patiešām garantē. Godīgā atbilde ir tāda, ka jūs aprakstījāt divas līguma puses, kas satiekas pie robežas. Kamēr nevarat nosaukt klasi, ko pakalpojumu sniedzējs pieņem, un apstrādi, ko tas piemēro, vietējā konfigurācija ir nodoms, nevis solījums. Abas puses ir svarīgas, un nevienu nevar izsecināt no otras.

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

Kur pareizs marķējums var klusi nomirt

Sāciet ar to, ka katram darba slodzes gadījumam pierakstāt vietējo atbilstības nosacījumu, jebkuru marķējumu tuneļa iekšienē, vērtību, ko pieņem pakalpojumu sniedzējs, un pakalpojuma klasi, ko šī vērtība izvēlas. Četras kolonnas, un kļūmes parasti dzīvo starp otro un trešo.

Marķējuma uzvedība no iekšējās uz ārējo galveni ir klasiskā problēma. Pakete šifrētā vai tunelētā ceļā nes iekšējo galveni, ko redz jūsu klasifikators, un ārējo galveni, ko redz pakalpojumu sniedzēja aprīkojums, un vienas kopēšana otrā ir konfigurācijas lēmums, nevis automātiska īpašība. Marķējiet tikai iekšējo galveni, un pakalpojumu sniedzējs klasificēs ārējo, parasti kā noklusējuma, tāpēc pareizi marķēta plūsma var nonākt nepareizā klasē bez vienas nepareizi konfigurētas rindas jūsu pusē.

Vietēji nosaukta klase var arī palikt tukša, jo tās atbilstības nosacījums nekad neiedarbojas uz īstām paketēm. Porti pārvietojas, lietojumprogrammas izmanto vairākas plūsmas, un atbilstība labi zināmam portam, ko piegādātājs pārstāja izmantot divus laidienus atpakaļ, rada rindu ar nullēm skaitītājos un politiku, kas darbojošā konfigurācijā izskatās nevainojama.

Skaidri izlemiet, kur marķējumiem uzticas. Visa, kas dala tuneli, paaugstināšana paaugstina arī masveida pārraides kopā ar zvaniem, un pakalpojumu sniedzējs, kas pieņem jūsu marķējumu bez pārbaudes, piedāvā jums veidu, kā sev kaitēt. Ja līgums ļauj vārtejai pārmarķēt nodošanas brīdī, ierakstiet to, jo tieši tajā punktā parasti atšķiras divu komandu pieņēmumi.

Ko plānotājs patiešām sadala

Vietējai politikai ir sava semantika, un visvairāk pārpratumu rada vārds “remaining”. Platformās, ko apraksta IOS XE plānošanas rokasgrāmata, bandwidth remaining percent nosaka pārpalikuma svaru, nevis soli secībā, kur katra klase paņem daļu no tā, ko atstājusi iepriekšējā klase. Neiedalītie procenti tiek sadalīti pa atbilstošām nekonfigurētām rindām, nevis rezervēti pēdējai faila klasei.

Šī atšķirība ir svarīga, jo secīgais domāšanas modelis dod prognozes, kas nekad nesakrīt ar skaitītājiem. Inženieri pārkārto klases, lai mainītu rezultātu, neredz atšķirību un secina, ka platforma ir salauzta, lai gan konfigurācija nekad nav nozīmējusi to, ko viņi pieņēma.

Vecākformētājs ir otrs izplatītais pārsteigums. Kontrolētas rindas formēšana līdz izmantojamajam pakalpojuma ātrumam bieži ir apzināta, jo tā pārvieto sastrēguma punktu uz ierīci, kuru pārvaldāt jūs, nevis uz augšupēju rindu, kuru nepārvaldāt. Formētāja noņemšana tāpēc, ka formēšana pievieno aizturi, var pārvietot zudumus, nevis tos novērst, un pieskaitāmo izmaksu uzskaite vai pakalpojumu sniedzēja policer var padarīt faktisko ātrumu zemāku, nekā liecina saskarne.

Skaitītāji parāda, kura puse nokrita

Salīdziniet četrus skaitļus skartajā virzienā: kas tika piedāvāts, ko klase atbilda, kas tika ievietots rindā vai nomests un ko pakalpojums faktiski piegādāja. Turiet darba slodzes aprakstu un politikas versiju blakus novērojumam, jo skaitītāju ekrānuzņēmums bez tiem nav atkārtojams.

Zari ir dažādas problēmas ar dažādiem īpašniekiem. Vietēja klase, kas neatbilst nekam, ir klasifikācijas kļūda jūsu pusē. Klase, kas atbilst, ierindojas un nomeš, kamēr pakalpojumu sniedzējs ziņo par tīru piegādi, norāda uz jūsu pašu plānotāju vai formētāju. Klase, kas lokāli izskatās pareiza, kamēr zudumi parādās aiz nodošanas, norāda uz operatora kartējumu un līgumā izmērīto robežu. Neviens no trim netiek labots, rediģējot pārējos, tāpēc skaitļi ir jāvāc kopā.

RFC 2475 klasifikāciju un kondicionēšanu definē kā darbu administratīvo domēnu iekšienē, un tieši tāpēc marķējums nevar rezervēt rindas no gala līdz galam. IOS XE plānošanas rokasgrāmata ir atsauce uz iepriekš aprakstīto pārpalikuma svara uzvedību, un tās platformu salīdzinājumus ir vērts izlasīt pirms aprēķinātā ātruma pārvietošanas starp modeļiem.

Uzrakstiet līgumu vienā vietā

Ievietojiet vietējo atbilstību, uzticēšanās robežu, pakalpojumu sniedzēja klasi un izmērīto pakalpojuma līmeni vienā dokumentā, ko paraksta abas puses. Tad procentu izmaiņām ir konteksts, un kvalitātes sūdzībai ir īpašnieks.

Vietēja procenta maiņa nevar salabot citas rindas garantiju, un neviena marķējuma shēma neizdzīvo kartējumu, ko pakalpojumu sniedzējs neievēro. Salīdziniet puses, nosauciet robežu un tikai tad citējiet skaitli.