Interop QoS ist die Königsdisziplin, sobald ein Netzwerk nicht aus einem einzigen Hersteller-Ökosystem besteht. In der Realität sind Multi-Vendor-Topologien eher die Regel als die Ausnahme: Access-Switches von Vendor A, WLAN von Vendor B, Core von Vendor C, SD-WAN oder Router von Vendor D, dazu Firewalls, Load Balancer und Provider-Edges mit eigenen Policies. Genau hier entstehen die typischen QoS-Probleme: DSCP wird auf dem Weg umgemappt, eine Klasse heißt überall anders, eine „Voice“-Queue ist beim einen Hersteller strikt priorisiert, beim anderen nur gewichtet, und an irgendeinem Übergang landet Echtzeit plötzlich in Best Effort. Das Ergebnis ist nicht unbedingt sofort ein Totalausfall – oft sind es schleichende Qualitätsdegradationen, die nur zu Stoßzeiten auffallen. Interop QoS bedeutet deshalb: Sie definieren ein herstellerunabhängiges QoS-Modell (Klassen, Markierungen, Trust Boundary, Scheduling-Intent) und sorgen dann dafür, dass jede Plattform dieses Modell konsistent implementiert und messbar einhält. Dieser Artikel zeigt, wie Sie Multi-Vendor Policies konsistent halten, welche Interop-Fallen besonders häufig sind und wie Sie mit Templates, Mapping-Tabellen, Validierungstests und Telemetry eine echte End-to-End-Konsistenz erreichen.
Warum Multi-Vendor QoS so oft „fast richtig“ ist – und genau deshalb gefährlich
QoS bricht in Multi-Vendor-Umgebungen selten an einer einzelnen großen Fehlkonfiguration. Viel häufiger passiert „Death by a thousand cuts“: Kleine Abweichungen addieren sich. Ein Access-Switch vertraut DSCP nicht, ein WLAN mappt DSCP anders auf WMM, der Core nutzt ein anderes DSCP->Queue-Profil, die Firewall setzt DSCP zurück, und der SD-WAN-Tunnel kopiert Markierungen nicht auf den Outer Header. Jede Komponente für sich kann „irgendwie“ funktionieren, aber die End-to-End-Qualität ist nicht mehr planbar.
- Unterschiedliche Defaults: Hersteller liefern ab Werk unterschiedliche QoS-Profile und Queue-Mappings.
- Unterschiedliche Terminologie: „Priority“, „LLQ“, „Strict Priority“, „High Queue“ sind nicht immer gleich implementiert.
- Unterschiedliche Queue-Anzahlen: Nicht jedes Gerät kann Ihr Klassenmodell 1:1 abbilden.
- Übergangseffekte: Trunks (802.1p), Tunnels (IPsec/GRE/VXLAN) und Firewalls sind klassische Bruchstellen.
Das Zielbild: Ein herstellerunabhängiges QoS-Intent-Modell
Der wichtigste Schritt für Interop QoS ist ein „Common QoS Model“, das unabhängig vom Hersteller beschrieben werden kann. Dieses Modell definiert nicht nur DSCP-Werte, sondern auch den Intent: Welche Klassen existieren, welche Priorität haben sie relativ zueinander, welche Bandbreitenreserven sind geplant, wo wird geshaped, wo wird (wenn überhaupt) gepoliced, und wo liegt die Trust Boundary. Dieses Intent-Modell ist Ihre Source of Truth. Hersteller-spezifische Konfigurationen sind nur Übersetzungen.
- Klassenmodell: z. B. VOICE, MEDIA, SIGNAL, CRITICAL, BESTEFFORT, BULK.
- Markierungsmodell: DSCP/CoS/WMM-Matrix als zentrale Referenz.
- Scheduling-Intent: Voice strict-priority (begrenzt), Media hohe Priorität (limitiert), Bulk gedrosselt.
- Edge-Intent: Shaping auf Realrate am WAN/Internet-Edge, Congestion in kontrollierten Queues.
- Trust-Intent: welche Endpunkte dürfen markieren, wo wird normalisiert.
Interop-Grundlage 1: DSCP-, CoS- und WMM-Mapping konsistent halten
In Multi-Vendor-Umgebungen ist die Mapping-Kette das häufigste Problem: DSCP im IP-Header, CoS/802.1p im VLAN-Tag und WMM-Kategorien im WLAN müssen zueinander passen. Wenn ein Hersteller DSCP EF in WMM Voice mappt und ein anderer es in WMM Video schiebt, ist Roaming zwar möglich, aber die Luftschnittstelle behandelt den Verkehr anders. Ähnliches gilt für CoS an Trunks oder Metro-Ethernet-Übergaben. Ein Interop-Standard braucht daher eine explizite Mapping-Tabelle, die nicht „implizit“ in Konfigurationen steckt, sondern zentral dokumentiert und überprüfbar ist.
- DSCP->Queue: pro Vendor-Platform definieren und versionieren.
- DSCP->CoS: für Trunks/Provider-Übergaben festlegen und normalisieren.
- DSCP/CoS->WMM: WLAN-Profile so einstellen, dass Voice/Video korrekt priorisiert werden.
- Rewrite-Regeln: an Trust Boundaries klar definieren, wann DSCP überschrieben wird.
Interop-Grundlage 2: Trust Boundary und Re-Marking – die Stelle, an der Multi-Vendor auseinanderläuft
Viele QoS-Probleme entstehen nicht im Core, sondern am Rand: Access-Switch, WLAN-SSID, Security Gateway. In Multi-Vendor-Netzen kann jeder dieser Bereiche eine andere Default-Philosophie haben, wie Markierungen behandelt werden. Ein Interop-Ansatz muss daher die Trust Boundary sehr klar festlegen: Welche Geräte werden trusted (z. B. IP-Telefone, Konferenzsysteme), welche nicht (BYOD, Gäste), und wo wird Markierung erzwungen (z. B. am SBC oder am Access Edge). Ohne diesen Standard kann ein Vendor A in der Access-Schicht DSCP löschen, während Vendor B erwartet, dass DSCP erhalten bleibt.
- Trusted Endpoints: Markierung übernehmen, ggf. normalisieren.
- Conditional Trust: Trust nur bei gemanagten Geräten oder NAC-Rollen.
- Untrusted: Markierung ignorieren, Default-Class, ggf. separate SSID/VLAN.
- Edge Enforcement: finaler Re-Marking-Punkt vor WAN/Provider, um Übergaben konsistent zu halten.
Interop-Grundlage 3: Scheduling-Modelle übersetzen, nicht kopieren
„Strict Priority“ ist nicht immer dasselbe. Manche Plattformen implementieren eine echte Low-Latency-Queue (LLQ) mit harter Priorität und optionalem Policing, andere nutzen Weighted Fair Queuing mit Prioritätsgewichtung. Manche haben 4 Queues, andere 8 oder mehr; manche haben Shared Buffers mit dynamischen Pooling-Mechanismen. Interop QoS heißt deshalb: Sie übersetzen Intent in die Möglichkeiten der Plattform, statt 1:1 eine Konfiguration zu „portieren“. Das erfordert klare Regeln: Welche Klasse bekommt strict priority (meist Voice), wie groß ist sie, welche Klassen bekommen garantierte Bandbreite, und wie wird Bulk gezähmt.
- Voice: auf allen Plattformen als strengste Klasse abbilden, aber begrenzen, um Starvation zu vermeiden.
- Media: hohe Priorität, aber nicht unlimitierte Priority-Queue; klare Mindest-/Max-Anteile.
- Best Effort: fair, aber nicht dominierend; darf unter Congestion droppen.
- Bulk: niedrig priorisiert und/oder rate-limited.
Interop-Grundlage 4: Shaping an Engpässen – dort muss es überall gleich „wirken“
In Multi-Vendor-Topologien ist der WAN/Internet-Uplink der wichtigste Engpass. Wenn ein Vendor-Edge korrekt shapet und ein anderer nicht, sind QoS-Ergebnisse standortabhängig und schwer zu erklären. Ein Interop-Standard sollte daher Shaping als nicht verhandelbar definieren: Realrate-basiertes Shaping am Egress, inklusive Overhead (VLAN, PPPoE, Tunnel). So stellen Sie sicher, dass Congestion in kontrollierten Queues entsteht und nicht in einem Modem oder Provider-Buffer, wo kein Vendor-Template hilft.
- Realrate statt Vertragsrate: Shaper knapp unter gemessener Upstream-Kapazität.
- Overhead berücksichtigen: Encapsulation reduziert effektive Nutzrate.
- Per-Class Scheduling: Shaper muss Klassen berücksichtigen, sonst wird „alles nur langsamer“.
Die häufigsten Interop-Fallen und wie Sie sie systematisch vermeiden
Viele Multi-Vendor QoS-Probleme lassen sich auf wenige wiederkehrende Fallen reduzieren. Wenn Sie diese als Checkliste in Reviews und Regression Tests aufnehmen, sinkt die Fehlerquote drastisch.
- DSCP drift: gleiche Klasse, unterschiedliche DSCP-Werte je Plattform.
- Queue drift: DSCP ist gleich, landet aber in unterschiedlichen Hardware-Queues.
- WLAN mismatch: DSCP->WMM ist inkonsistent; Voice wird im Funk nicht als Voice behandelt.
- Tunnel mismatch: DSCP wird nicht inner->outer kopiert; Underlay sieht Best Effort.
- Firewall rewrite: Security setzt DSCP zurück; WAN-Edge kann nicht klassifizieren.
- Policer-Fehler: eine Plattform policet Voice hart; sporadische Loss-Spikes ohne Queue-Wachstum.
Templates pro Vendor, aber ein gemeinsames Naming und ein gemeinsames „Policy Contract“
Ein praxistauglicher Interop-Ansatz kapselt Vendor-spezifische Konfigurationen in Templates, die alle denselben „Policy Contract“ erfüllen: gleiche logische Klassen, gleiche DSCP-Matrix, gleiche Naming-Konvention und gleiche Telemetry-Exporte. Damit kann das NOC standortübergreifend arbeiten, und Engineering kann Regressionen vergleichen. Ohne gemeinsames Naming werden Per-Class Drops und Queue-Delay-Dashboards schnell unbrauchbar, weil jede Plattform andere Begriffe und Zähler liefert.
- Common Naming: QOS_CLASS_VOICE, QOS_CLASS_MEDIA, QOS_POLICY_WAN_EGRESS usw.
- Policy Contract: dokumentierte Regeln, welche Klassen existieren und wie sie sich verhalten müssen.
- Vendor Adapter Templates: Übersetzung des Contracts in Plattformsyntax.
- Versionierung: V1/V2-Vergleich über alle Vendoren möglich.
Interop-Validierung: Wie Sie Konsistenz messbar machen
Multi-Vendor QoS sollte nicht „geglaubt“, sondern gemessen werden. Eine gute Validierung kombiniert mechanische Checks (Mapping/Attachment/Classifier) mit verhaltensbasierten Tests (Congestion-Proof) und Telemetry im Betrieb (Queue Delay/Depth, Per-Class Drops, Drop Reasons). Besonders wertvoll sind standardisierte Regression Tests, die auf allen Plattformen vergleichbare Ergebnisse liefern. So erkennen Sie, ob Vendor A bei Microbursts Buffer Exhaustion zeigt, während Vendor B stabil bleibt, oder ob ein WLAN-Controller die WMM-Mappings anders behandelt.
- Mechanik: DSCP Preservation, Classifier-Hits, DSCP->Queue Mapping, Policy Attachment.
- Verhalten: kontrollierte Congestion, Voice stabil, Best Effort trägt Delay/Drops.
- Telemetry: Queue Delay/Depth, Per-Class Drops und Drop Reasons als Zeitreihe.
- QoE: RTP/WebRTC Jitter/Loss/MOS als End-to-End-Verifikation.
Monitoring- und Dashboard-Interop: NOC-Teams brauchen einheitliche Panels
Interop QoS ist auch ein Observability-Thema. Wenn jeder Vendor andere Counter-Namen und andere Queue-Modelle hat, braucht Ihr NOC eine normalisierte Sicht. Das erreichen Sie, indem Sie aus Vendor-spezifischen Telemetry-Daten auf ein gemeinsames KPI-Modell mappen: Voice Queue Delay, Media Queue Delay, Voice Drops, Media Drops, Default/Unmatched-Anteil, Shaper Headroom, Drop Reasons. Dann können Dashboards und Alerts herstellerübergreifend funktionieren.
- Normalized KPIs: gleiche Panelnamen, gleiche Semantik, gleiche Schwellen.
- Top-Offender: standortübergreifende Rankings nach Delay/Drops.
- Drilldown: von normalisiertem KPI in Vendor-spezifische Details.
- Alert Guardrails: Voice Drops oder Policer Drops in Echtzeitklassen als hochsignalige Alarme.
Change- und Review-Gates: Interop-Sicherheit durch verpflichtende Checks
Multi-Vendor QoS bleibt nur dann konsistent, wenn Änderungen kontrolliert werden. Ein Interop-Standard sollte Review Gates definieren, die vor jedem Rollout prüfen: Stimmen DSCP-Matrix und Mapping-Tabellen? Ist DSCP inner->outer in Overlays korrekt? Werden Markierungen an Firewalls preservt? Ist Shaping am WAN-Egress aktiv? Gibt es Policers auf Voice? Solche Gates können teilweise automatisiert werden und sind der effektivste Schutz gegen „silent regressions“.
- Pre-Deploy: Template-Konformität, Policy Attachment, Mapping-Checks.
- Safety Gate: keine unlimitierten Priority-Queues, keine Policers auf Voice, kein WRED auf Echtzeit.
- Post-Deploy: Classifier-Hits, Queue Delay/Depth, Per-Class Drops als Smoke Test.
- Rezertifizierung: regelmäßige Regression Suite pro Vendor-Version und nach Major Changes.
Pragmatische Interop-Checkliste: Multi-Vendor Policies konsistent halten
- Common QoS Model: ein Klassenmodell und eine DSCP/CoS/WMM-Matrix als Source of Truth.
- Trust Boundary Standard: klar definieren, wer markieren darf und wo normalisiert wird.
- Vendor Templates: pro Plattform ein Adapter-Template, aber gemeinsamer Policy Contract und Naming.
- Shaping Standard: Realrate-basiertes Shaping am WAN/Internet-Edge in allen Plattformen.
- Interop-Validation: mechanische Checks + Congestion-Proof + Telemetry- und QoE-Korrelation.
- Normalized Observability:
- Review Gates:
