EVPN/VXLAN QoS ist in modernen Data-Center- und Provider-Fabrics ein zentrales Thema, weil Overlay-Encapsulation die klassische QoS-Logik leicht aushebelt: Markierungen werden zwar am Endpunkt gesetzt, aber im Underlay entscheidet oft der Outer Header über Queueing und Congestion – und genau dort gehen Markings häufig verloren oder werden falsch gemappt. Das Ergebnis sind typische „Overlay-QoS“-Probleme: Voice/Video oder latenzkritische Microservices sind sauber als DSCP EF/AF markiert, kommen aber im Underlay als Best Effort an; ECN/AQM wirkt nur auf einen Teil des Pfads; oder MTU/Fragmentierung erzeugt Drops, die wie „mysteriöse“ Echtzeitstörungen wirken. EVPN/VXLAN QoS bedeutet deshalb vor allem zwei Dinge: Marking Preservation (inneres Marking erhalten und sinnvoll auswerten) und Encapsulation-Awareness (Outer Header korrekt markieren und in Underlay-Queues mappen). Wer das professionell plant, definiert klare Trust Boundaries an den VTEPs (VXLAN Tunnel Endpoints), standardisiert DSCP↔PCP/CoS↔Queue-Mappings im Fabric-Underlay, berücksichtigt den Header-Overhead in Bandbreiten- und MTU-Modellen und misst QoS nicht nur „im Overlay“, sondern hop-by-hop im Underlay über Queue-Delay, Drops und ECN-Marks.
Warum Overlays QoS komplexer machen: Inner vs. Outer Header entscheidet
In einem klassischen L3-Netz ist DSCP im IP-Header das zentrale QoS-Signal. In EVPN/VXLAN kommt jedoch eine Encapsulation dazu: Ein inneres Ethernet/IP-Paket wird in VXLAN gekapselt und über ein Underlay (meist IP) transportiert. Die Underlay-Geräte sehen für die Forwarding- und QoS-Entscheidung primär den Outer IP-Header und dessen DSCP – nicht den inneren DSCP. Wenn der Outer DSCP nicht korrekt gesetzt ist, kann das Underlay Echtzeitverkehr nicht priorisieren, selbst wenn der innere Traffic perfekt markiert ist. Deshalb ist die wichtigste Designfrage: Welche Markings werden im Underlay verwendet, und wie werden sie vom Inner Header abgeleitet?
- Inner Marking: DSCP/PCP im „Nutzpaket“ – wichtig für End-to-End Semantik und Egress.
- Outer Marking: DSCP im Underlay-Transport – entscheidend für Queueing im Fabric.
- Policy-Entscheidung: Copy/Propagate (inner→outer) oder Rewrite/Normalize am VTEP.
- Fehlerbild: Inner korrekt, Outer falsch → Underlay behandelt alles als Best Effort.
EVPN/VXLAN Datenpfad in QoS-Sicht: Wo tatsächlich gequeued wird
QoS wirkt nur bei Congestion – und Congestion entsteht im Data Center häufig an Uplinks (Leaf→Spine oder Spine→Border), an Borders Richtung WAN/Interconnect, an East-West Hotspots und bei Microbursts durch Fan-in. In einer EVPN/VXLAN-Fabric ist es daher essenziell zu wissen, an welchen Interfaces Stau realistisch ist und welche Header dort ausgewertet werden. In der Regel sind das Underlay-Interfaces, die nur den Outer Header sehen. Das ist der Grund, warum Marking Preservation allein nicht reicht: Sie müssen Marking für das Underlay explizit korrekt setzen.
- Leaf-Uplinks: Fan-in aus Serverports erzeugt Mikrobursts Richtung Spine.
- Spine→Border: konzentrierter Traffic zu Internet/Cloud/WAN; häufige Congestion Domain.
- Inter-DC Links: begrenzte Kapazitäten, hohe RTT-Sensitivität für Apps.
- Storage/Backup: Bulk kann Queues aufblasen, wenn keine Scavenger-Klasse existiert.
Marking Preservation: Was „erhalten“ in EVPN/VXLAN wirklich bedeutet
Marking Preservation wird oft missverstanden als „inneres DSCP bleibt drin“. Das ist notwendig, aber nicht hinreichend. In EVPN/VXLAN gibt es drei relevante Preservation-Aspekte: Erstens muss das innere Marking beim Encapsulieren nicht verloren gehen (z. B. durch eine Default-Normalisierung am VTEP). Zweitens muss es beim Decapsulieren wieder korrekt an das ausgehende Paket gebunden werden. Drittens muss das Marking in Übergängen zu anderen Domänen (WAN, MPLS, Internet Edge) in deren Marking-/Klassensystem übersetzt werden. Ohne diese End-to-End Sicht endet Marking Preservation als „schönes inneres DSCP“, das operativ keine Wirkung hat.
- Preserve Inner DSCP: innerer DSCP bleibt unverändert (oder wird bewusst normalisiert) durch den Overlay-Tunnel.
- Propagate to Outer: outer DSCP wird aus inner DSCP abgeleitet, damit Underlay-QoS wirkt.
- Restore at Egress: beim Decap bleibt inneres Marking erhalten, damit der nächste Hop korrekt behandelt.
- Translate at Borders: Mapping zu MPLS-TC, PCP oder Partnerprofilen, wenn die Domain wechselt.
Outer-DSCP Strategie: Copy, Map oder Rewrite?
Die wichtigste praktische Entscheidung in EVPN/VXLAN QoS ist, wie der Outer DSCP gesetzt wird. Drei Ansätze sind üblich. „Copy“ übernimmt den inneren DSCP 1:1 in den Outer Header. Das ist einfach, kann aber in Multi-Tenant-Umgebungen riskant sein, weil Kunden/Workloads Markings missbrauchen können. „Map“ übersetzt inner DSCP-Werte auf ein Provider-/Fabric-internes Klassenmodell, typischerweise mit einer Allowlist und wenigen Klassen. „Rewrite“ ignoriert inner DSCP komplett und setzt Outer DSCP basierend auf Kontext (VRF/VNI, Port-Profil, Tenant-Policy). In großen Umgebungen ist „Map“ oft der pragmatische Kompromiss: Sie erhalten Semantik, verhindern aber Klassenexplosion und Missmarking.
- Copy: schnell und transparent, aber nur sinnvoll bei hoher Trust-Qualität (z. B. kontrollierte Serverlandschaft).
- Map: inner DSCP wird auf wenige Fabric-Klassen übersetzt (EF/AF/BE/Bulk), ideal für Governance.
- Rewrite: maximale Kontrolle, aber höhere Policy-Komplexität und weniger End-to-End Transparenz.
Trust Boundaries am VTEP: Warum der Tunnel-Endpunkt der neue „Provider Edge“ ist
In EVPN/VXLAN ist der VTEP funktional eine Trust Boundary. Er entscheidet, welche Markings von Endpunkten akzeptiert werden und wie sie im Underlay wirken. Ohne Trust Boundaries kann ein einzelner Tenant seinen kompletten Traffic als EF markieren und damit Premium-Queues im Underlay fluten. Deshalb sollte der VTEP (oder die Leaf-Switch-Rolle, die den VTEP stellt) Markings per Allowlist kontrollieren und pro Klasse Budgets enforce’n – besonders für strikt priorisierte Echtzeitklassen. Für Serverports in einer kontrollierten Umgebung kann Trust näher am Host liegen; für Multi-Tenant- oder Cloud-nahe Fabrics ist Trust am VTEP häufig zwingend.
- Allowlist: nur definierte DSCP-Werte dürfen in Premiumklassen gelangen.
- Remarking/Normalization: unerlaubte Markings werden auf Best Effort gesetzt.
- Class Budgets: Realtime/Voice strikt begrenzen, Video kontrollieren, Bulk nachrangig.
- Audit: Zähler für Remarking und Queue-Health zeigen, ob Trust-Regeln wirken.
QoS im Underlay: Queues, Scheduling und AQM in der Fabric
Viele Fabrics haben nur eine begrenzte Anzahl von Hardware-Queues pro Port. Das zwingt zu einem schlanken Klassenmodell. Ein bewährtes Underlay-Design nutzt wenige Klassen: Network Control, Realtime (Voice), Interactive (Video/Business), Best Effort und Bulk/Scavenger. Für Best Effort ist AQM/ECN oft der größte Hebel gegen Bufferbloat, weil TCP-lastige East-West Flows sonst Queues aufblasen und Latenzspitzen erzeugen. Für Echtzeit gilt: kurze Queues und klare Limits sind wichtiger als „keine Drops“. Eine zu große Echtzeitqueue erzeugt Jitter, auch wenn keine Drops sichtbar sind.
- Strict Priority: nur für sehr kleine Echtzeitklassen, immer mit Obergrenze.
- Weighted Queues: für Video/Business, um Stabilität und Fairness zu kombinieren.
- AQM/ECN: in Best Effort zur Latenzstabilisierung unter Last.
- Queue-Limits: bewusst so wählen, dass Bufferbloat vermieden wird.
Encapsulation-Overhead: MTU, Fragmentierung und warum QoS plötzlich „schlecht“ wird
VXLAN-Encapsulation erhöht die Paketgröße. Wenn die Underlay-MTU nicht passend dimensioniert ist oder wenn PMTUD fehlschlägt, entstehen Fragmentierung oder Drops. Für Echtzeit ist das fatal: einzelne Drops sind sofort hörbar, und Fragmentierung erhöht Jitter und CPU/ASIC-Last. Außerdem erhöht Overhead die effektive Bitrate: Ein Voice- oder Video-Stream belegt auf dem Underlay mehr Bandbreite als „im Overlay“ sichtbar ist. Deshalb müssen Bandbreitenmodelle und Shaper-Profile den Encapsulation-Overhead berücksichtigen, besonders an Border-Uplinks und Inter-DC Links.
- MTU-Disziplin: Underlay-MTU muss VXLAN-Overhead einkalkulieren, sonst entstehen Drops/Fragmentierung.
- MSS-Clamping: an Borders sinnvoll, um TCP-Fragmentierung zu vermeiden.
- Effektive Rate: Overhead erhöht die Belastung von Engpässen; QoS-Budgets müssen angepasst werden.
- Failure Pattern: „Nur in VXLAN“ schlechte QoE → oft MTU/Overhead, nicht Queueing.
ECN und VXLAN: Congestion-Signale über Encapsulation hinweg erhalten
Wenn Sie ECN/AQM nutzen, wird die Frage wichtig, wie Congestion-Markierungen über den Tunnel propagiert werden. In gemischten Umgebungen kann es passieren, dass ECN-Bits oder DSCP-Markierungen beim Encapsulieren/Decapsulieren nicht konsistent übernommen werden. Das führt zu paradoxen Effekten: AQM markiert zwar im Underlay, aber Endpunkte reagieren nicht, weil das Signal nicht ankommt; oder Best Effort wird zu aggressiv gedroppt, obwohl ECN verfügbar wäre. Ein robustes Design definiert daher, welche Bits im Outer Header gesetzt werden, wie ECN propagiert wird und wie Monitoring die Mark-Rate sichtbar macht.
- AQM im Underlay: markiert oder droppt, um Queue kurz zu halten.
- ECN-Propagation: sicherstellen, dass Congestion-Signale sinnvoll durch den Tunnel wirken.
- Messbarkeit: ECN-Mark-Rate und Queue-Delay gemeinsam betrachten.
EVPN-spezifische Praxis: Multi-Homing, Anycast Gateway und QoS-Auswirkungen
EVPN bringt Betriebsmechaniken wie Multi-Homing (z. B. All-Active), Anycast Gateway und schnelle Convergence. Diese Features sind hervorragend für Resilienz, können aber QoS beeinflussen: Traffic kann bei Events anders laufen, Hashing kann sich ändern, und dadurch verschieben sich Congestion Domains. Für QoS bedeutet das: Policies müssen auf allen relevanten Pfaden identisch wirken, und Failover muss unter Last getestet werden, nicht nur im Normalbetrieb.
- Multi-Homing: Link-/Node-Fail kann Flows neu verteilen; Hotspots möglich.
- Anycast Gateway: verändert East-West Pfade, kann Traffic näher an Workloads halten, aber auch konzentrieren.
- Fast Convergence: gut für Verfügbarkeit, aber QoS muss in Backup-Pfaden kompatibel sein.
Monitoring: QoS im Overlay sichtbar machen, Underlay als Quelle nutzen
Ein häufiger Fehler ist, QoS nur auf Overlay-Ebene zu beobachten (z. B. End-to-End Latenz zwischen VMs) und Underlay-Queues zu ignorieren. Für EVPN/VXLAN QoS brauchen Sie beide Ebenen: Overlay-KPIs zeigen Nutzerimpact, Underlay-KPIs zeigen Ursache. Besonders wichtig sind queuebezogene Telemetrie-Daten: Queue-Delay, Queue-Drops, Utilization-Perzentile und ECN/WRED-Marks pro Klasse an den kritischen Links (Leaf-Uplinks, Spine→Border, Inter-DC). Zusätzlich sollten Sie DSCP-Verteilungen am VTEP messen (inner vs. outer), um Marking Preservation und Trust Boundaries zu verifizieren.
- Outer DSCP Distribution: zeigt, ob Underlay-Klassen korrekt gesetzt werden.
- Queue-Delay p95/p99: Frühindikator für Jitter und bevorstehende QoE-Probleme.
- Class Drops: Drops in Realtime/Control sind kritisch; Best Effort Drops anders bewerten.
- Event-Korrelation: EVPN Convergence/Link-Events mit QoS-Abweichungen verknüpfen.
Typische Failure Patterns und praktische Grenzen
EVPN/VXLAN QoS scheitert in der Praxis selten an einem einzelnen Bug, sondern an wiederkehrenden Mustern: Outer DSCP wird nicht gesetzt, Underlay hat zu wenige Queues für zu viele Klassen, MTU ist zu klein, Trust Boundaries fehlen, oder AQM/ECN wird inkonsistent umgesetzt. Diese Grenzen lassen sich beherrschen, wenn Sie das Design schlank halten und End-to-End konsequent testen.
- „Alles ist Best Effort“: Outer DSCP bleibt 0; Underlay priorisiert nicht.
- Premium-Queues laufen voll: Copy ohne Trust führt zu Missmarking; Allowlist/Mapping nötig.
- Voice/Video ruckelt nur im DC: Mikrobursts und Bufferbloat an Uplinks; Queue-Delay/AQM prüfen.
- Unerklärliche Drops: MTU/Fragmentierung durch VXLAN-Overhead; MTU/MSS prüfen.
- Inkonsequente QoS nach Failover: Backup-Pfade ohne identische Queue-Profile.
Blueprint: EVPN/VXLAN QoS sauber planen und ausrollen
Ein praxiserprobtes Vorgehen beginnt mit einem schlanken Klassenmodell, das zur Queue-Anzahl Ihrer Fabric passt. Danach definieren Sie eine Outer-DSCP Strategie (Copy/Map/Rewrite) und setzen Trust Boundaries am VTEP um: Allowlist, Remarking, Class Budgets, insbesondere strikte Limits für Realtime. Anschließend implementieren Sie Underlay-QoS: konsistente Queue-Profile, AQM/ECN für Best Effort, kurze Echtzeitqueues gegen Jitter. Parallel wird MTU/Overhead end-to-end geplant und getestet (inklusive Inter-DC und Border). Abschließend bauen Sie Monitoring auf, das Outer/Inner Marking-Integrität, Queue-Delay/Drops und Event-Korrelation abdeckt. So bleibt Marking Preservation nicht ein theoretisches Ziel, sondern wird im Underlay wirksam – genau dort, wo Congestion tatsächlich entsteht.