DSCP-markering of QoS-belofte van de provider? Geen van beide is een contract

Er wordt iets gemarkeerd, een wachtrij wordt geconfigureerd en dan vraagt iemand welke kwaliteit het ontwerp werkelijk garandeert. Het eerlijke antwoord is dat u twee helften van een contract hebt beschreven die elkaar bij een grens ontmoeten. Totdat u de klasse kunt noemen die de provider accepteert en de behandeling die hij toepast, is de lokale configuratie een bedoeling en geen belofte. Beide helften doen ertoe, en geen van beide is uit de ander af te leiden.

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

Waar een correcte markering stilletjes kan sterven

Begin met het opschrijven, per werklast, van de lokale overeenkomstvoorwaarde, elke markering die in een tunnel plaatsvindt, de waarde die de provider accepteert en de serviceklasse die die waarde selecteert. Vier kolommen, en de fouten leven meestal tussen de tweede en de derde.

Het markeringsgedrag van binnen naar buiten is het klassieke probleem. Een pakket in een versleuteld of getunneld pad draagt een binnenheader die uw classificator kan zien en een buitenheader die de apparatuur van de provider kan zien, en het ene in het andere kopiëren is een configuratiebeslissing, geen automatische eigenschap. Markeer alleen de binnenheader en de provider classificeert de buitenheader, meestal als standaard, waardoor een correct gemarkeerde stroom in de verkeerde klasse kan aankomen zonder één verkeerd geconfigureerde regel aan uw kant.

Een lokaal benoemde klasse kan ook leeg blijven omdat de overeenkomstvoorwaarde nooit op echte pakketten afgaat. Poorten verschuiven, toepassingen gebruiken meerdere stromen, en een overeenkomst op een bekende poort die de leverancier twee releases geleden niet meer gebruikt, levert een wachtrij met tellers op nul en een beleid dat er in de draaiende configuratie perfect uitziet.

Bepaal expliciet waar markeringen worden vertrouwd. Alles promoveren wat een tunnel deelt, promoveert ook bulktransfers samen met de oproepen, en een provider die uw markering zonder validatie accepteert, biedt u een manier om uzelf pijn te doen. Als het contract de gateway toestaat om bij de overdracht opnieuw te markeren, schrijf dat op, want dat is precies het punt waar de aannames van twee teams meestal uiteenlopen.

Wat de scheduler werkelijk verdeelt

Lokaal beleid heeft zijn eigen semantiek, en degene die de meeste misverstanden veroorzaakt is het woord “remaining”. Op de platforms die de IOS XE-schedulinggids beschrijft, zet bandwidth remaining percent een overschotgewicht, geen stap in een reeks waarin elke klasse een deel neemt van wat de vorige klasse heeft achtergelaten. Niet-toegewezen percentages worden over geschikte niet-geconfigureerde wachtrijen verdeeld in plaats van gereserveerd te worden voor de laatste klasse in het bestand.

Dat onderscheid is belangrijk omdat het sequentiële denkmodel voorspellingen oplevert die nooit met de tellers kloppen. Ingenieurs herordenen klassen om een uitkomst te veranderen, zien geen verschil en concluderen dat het platform stuk is, terwijl de configuratie nooit betekende wat zij aannamen.

Een bovenliggende shaper is de andere veelvoorkomende verrassing. Een gecontroleerde wachtrij terugshapen naar de bruikbare servicesnelheid is vaak bewust, omdat het het knelpunt naar een apparaat verplaatst dat u beheert in plaats van naar een upstream wachtrij die u niet beheert. De shaper verwijderen omdat shapen vertraging toevoegt, kan het verlies verplaatsen in plaats van wegnemen, en overheadboekhouding of een provider-policer kunnen de effectieve snelheid lager maken dan de interface suggereert.

De tellers zeggen welke helft faalde

Vergelijk vier getallen in de getroffen richting: wat werd aangeboden, wat de klasse trof, wat in de wachtrij kwam of werd weggegooid, en wat de dienst werkelijk leverde. Houd de werklastbeschrijving en de beleidsversie naast de observatie, want een schermafbeelding van tellers zonder die is niet reproduceerbaar.

De takken zijn verschillende problemen met verschillende eigenaren. Een lokale klasse die niets treft, is een classificatiefout aan uw kant. Een klasse die treft, in de wachtrij gaat en weggooit terwijl de provider schone levering meldt, wijst op uw eigen scheduler of shaper. Een klasse die er lokaal correct uitziet terwijl verlies voorbij de overdracht verschijnt, wijst op de mapping van de carrier en de gemeten grens in het contract. Geen van de drie wordt opgelost door de andere te bewerken, daarom moeten de getallen samen worden verzameld.

RFC 2475 kadert classificatie en conditionering als werk binnen administratieve domeinen, en juist daarom kan een markering geen wachtrijen van begin tot eind reserveren. De IOS XE-schedulinggids is de referentie voor het hierboven beschreven overschotgewichtgedrag, en zijn platformvergelijkingen zijn de moeite waard voordat een berekende snelheid tussen modellen wordt verplaatst.

Schrijf het contract op één plek

Zet de lokale overeenkomst, de vertrouwensgrens, de providerklasse en het gemeten serviceniveau in één document dat beide partijen ondertekenen. Dan heeft een procentuele wijziging een context, en een kwaliteitsklacht een eigenaar.

Een lokaal percentage wijzigen kan de garantie van een andere wachtrij niet repareren, en geen markeringsschema overleeft een mapping die de provider niet naleeft. Vergelijk de helften, benoem de grens en citeer pas dan een getal.