DSCP-Marking oder QoS-Versprechen des Providers? Keines von beiden ist ein Vertrag

Etwas wird markiert, eine Warteschlange wird konfiguriert, und dann fragt jemand, welche Qualität das Design tatsächlich garantiert. Die ehrliche Antwort ist, dass Sie zwei Hälften eines Vertrags beschrieben haben, die an einer Grenze zusammentreffen. Solange Sie nicht die Klasse nennen können, die der Provider akzeptiert, und die Behandlung, die er anwendet, ist die lokale Konfiguration eine Absicht und kein Versprechen. Beide Hälften sind wichtig, und keine lässt sich aus der anderen ableiten.

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

Wo eine korrekte Markierung still sterben kann

Beginnen Sie damit, pro Workload die lokale Übereinstimmungsbedingung, jede Markierung innerhalb eines Tunnels, den Wert, den der Provider akzeptiert, und die Dienstklasse, die dieser Wert auswählt, aufzuschreiben. Vier Spalten, und die Fehler leben meist zwischen der zweiten und der dritten.

Das Markierungsverhalten von innen nach außen ist das klassische Problem. Ein Paket in einem verschlüsselten oder getunnelten Pfad trägt einen inneren Header, den Ihr Klassifizierer sieht, und einen äußeren Header, den die Ausrüstung des Providers sieht, und das Kopieren des einen in den anderen ist eine Konfigurationsentscheidung und keine automatische Eigenschaft. Markieren Sie nur den inneren Header, und der Provider klassifiziert den äußeren, meist als Default, weshalb ein korrekt markierter Flow in der falschen Klasse ankommen kann, ohne eine einzige falsch konfigurierte Zeile auf Ihrer Seite.

Eine lokal benannte Klasse kann auch leer bleiben, weil ihre Übereinstimmungsbedingung bei echten Paketen nie auslöst. Ports verschieben sich, Anwendungen nutzen mehrere Flows, und eine Übereinstimmung auf einem bekannten Port, den der Hersteller vor zwei Releases nicht mehr verwendet hat, erzeugt eine Warteschlange mit Zählern auf null und eine Policy, die in der laufenden Konfiguration perfekt aussieht.

Entscheiden Sie ausdrücklich, wo Markierungen vertraut wird. Alles hochzustufen, was sich einen Tunnel teilt, stuft auch Massenübertragungen zusammen mit den Anrufen hoch, und ein Provider, der Ihre Markierung ohne Prüfung akzeptiert, bietet Ihnen einen Weg, sich selbst zu schaden. Wenn der Vertrag dem Gateway erlaubt, bei der Übergabe neu zu markieren, schreiben Sie es auf, denn genau dort gehen die Annahmen zweier Teams meist auseinander.

Was der Scheduler tatsächlich verteilt

Lokale Policy hat ihre eigene Semantik, und die meisten Missverständnisse verursacht das Wort “remaining”. Auf den Plattformen, die der IOS XE-Scheduling-Leitfaden beschreibt, setzt bandwidth remaining percent ein Überschussgewicht, nicht einen Schritt in einer Reihenfolge, in der jede Klasse einen Anteil von dem nimmt, was die vorherige Klasse übrig gelassen hat. Nicht zugewiesene Prozentwerte werden auf geeignete, nicht konfigurierte Warteschlangen verteilt, statt für die letzte Klasse in der Datei reserviert zu werden.

Diese Unterscheidung ist wichtig, weil das sequenzielle Denkmodell Vorhersagen liefert, die nie zu den Zählern passen. Ingenieure ordnen Klassen um, um ein Ergebnis zu ändern, sehen keinen Unterschied und schließen, die Plattform sei defekt, obwohl die Konfiguration nie das bedeutete, was sie annahmen.

Ein übergeordneter Shaper ist die andere häufige Überraschung. Eine kontrollierte Warteschlange auf die nutzbare Dienstrate herunterzushapen ist oft Absicht, weil er den Überlastungspunkt auf ein Gerät verlagert, das Sie verwalten, statt auf eine vorgelagerte Warteschlange, die Sie nicht verwalten. Den Shaper zu entfernen, weil Shaping Verzögerung hinzufügt, kann den Verlust verlagern statt ihn zu beseitigen, und Overhead-Abrechnung oder ein Provider-Policer können die effektive Rate niedriger machen, als die Schnittstelle vermuten lässt.

Die Zähler sagen, welche Hälfte versagt hat

Vergleichen Sie vier Zahlen in der betroffenen Richtung: was angeboten wurde, was die Klasse getroffen hat, was in die Warteschlange gestellt oder verworfen wurde und was der Dienst tatsächlich geliefert hat. Halten Sie die Workload-Beschreibung und die Policy-Version neben der Beobachtung, denn ein Screenshot der Zähler ohne sie ist nicht reproduzierbar.

Die Zweige sind verschiedene Probleme mit verschiedenen Eigentümern. Eine lokale Klasse, die nichts trifft, ist ein Klassifizierungsfehler auf Ihrer Seite. Eine Klasse, die trifft, einreiht und verwirft, während der Provider saubere Lieferung meldet, deutet auf Ihren eigenen Scheduler oder Shaper hin. Eine Klasse, die lokal korrekt aussieht, während Verlust jenseits der Übergabe auftritt, deutet auf das Mapping des Carriers und die gemessene Grenze im Vertrag hin. Keiner der drei wird durch Bearbeiten der anderen behoben, weshalb die Zahlen zusammen erhoben werden müssen.

RFC 2475 rahmt Klassifizierung und Konditionierung als Arbeit innerhalb administrativer Domänen, und genau deshalb kann eine Markierung keine Warteschlangen von Ende zu Ende reservieren. Der IOS XE-Scheduling-Leitfaden ist die Referenz für das oben beschriebene Überschussgewicht-Verhalten, und seine Plattformvergleiche lohnen sich, bevor eine berechnete Rate zwischen Modellen verschoben wird.

Schreiben Sie den Vertrag an einer Stelle

Legen Sie die lokale Übereinstimmung, die Vertrauensgrenze, die Provider-Klasse und das gemessene Servicelevel in ein einziges Dokument, das beide Seiten unterzeichnen. Dann hat eine Prozentänderung einen Kontext und eine Qualitätsbeschwerde einen Eigentümer.

Eine lokale Prozentänderung kann die Garantie einer anderen Warteschlange nicht reparieren, und kein Markierungsschema überlebt ein Mapping, das der Provider nicht einhält. Vergleichen Sie die Hälften, benennen Sie die Grenze, und erst dann zitieren Sie eine Zahl.