QoS in EVPN/VXLAN-Netzen ist der Schlüssel, um in modernen Data-Center- und Provider-Fabric-Architekturen stabile Serviceklassen durchzusetzen – trotz Overlay-Tunneln, hohem East-West-Traffic und burstigem Workload-Verhalten. Viele Teams führen EVPN/VXLAN ein, um Skalierung, Multi-Tenancy und Mobilität zu verbessern, und stellen erst später fest, dass „klassisches QoS“ nicht mehr automatisch wie in reinen Layer-2/Layer-3-Netzen wirkt: Markierungen gehen an Tunnelgrenzen verloren, Policer greifen an der falschen Stelle, oder eine einzelne „laute“ Tenant-Instanz drückt den gesamten Fabric-Uplink in Congestion. Das Ergebnis sind Latenzspitzen, Jitter und Drops – besonders kritisch für Voice- und Video-Workloads, UC-Plattformen, VDI, Storage-Replikation oder zeitkritische Steuerdaten. Ein professionelles QoS in EVPN/VXLAN-Netzen muss deshalb zwei Ebenen sauber zusammendenken: das Underlay (IP-Fabric) und das Overlay (VXLAN-Tunnel). Dazu gehören ein konsistentes Klassenmodell (DSCP/CoS), klare Trust Boundaries an den Leaf-Ports, eine definierte Strategie für DSCP-Propagation zwischen innerem und äußerem Header sowie Policer und Shaper, die fair, skalierbar und overlay-aware arbeiten. Dieser Artikel erklärt praxisnah, wie Sie Klassen und Policer in EVPN/VXLAN richtig umsetzen, typische Stolperfallen vermeiden und QoS so gestalten, dass es auch unter Last vorhersehbar bleibt.
Warum QoS in EVPN/VXLAN komplexer ist als im klassischen LAN
In EVPN/VXLAN wird Kunden- oder Tenant-Verkehr in einen VXLAN-Tunnel gekapselt. Der eigentliche Traffic (innerer Header) wird in UDP/VXLAN verpackt und über ein IP-Underlay transportiert (äußerer Header). Genau diese Kapselung ist der Hauptgrund, warum QoS-Design angepasst werden muss:
- Zwei Header-Ebenen: Innerer IP-Header (Tenant) und äußerer IP-Header (Underlay). QoS kann auf beiden Ebenen stattfinden.
- Hardware-Pipelines: Switches/Routers entscheiden Queueing oft anhand des äußeren Headers – wenn der nicht korrekt markiert ist, greift QoS nicht wie erwartet.
- Multi-Tenancy: Unterschiedliche Kundendomänen teilen sich dieselbe Fabric; ohne Profilierung kann ein Tenant andere verdrängen.
- East-West-Microbursts: VM-zu-VM- und Pod-zu-Pod-Verkehr erzeugt kurze Peaks, die Queues füllen, auch bei moderaten Durchschnittslasten.
- Gateway-Hotspots: Anycast Gateways, Border Leafs und Service Nodes (Firewall/LB) sind häufige Engpasspunkte.
Die zentrale Frage lautet daher: Wie bringen Sie die „Bedeutung“ einer QoS-Klasse zuverlässig vom Tenant-Verkehr durch den VXLAN-Tunnel bis in die Underlay-Queues – und wie begrenzen Sie Traffic fair, ohne Echtzeit und kritische Services zu beschädigen?
Underlay vs. Overlay: Wo QoS tatsächlich wirkt
In EVPN/VXLAN-Architekturen ist QoS nicht „entweder oder“, sondern „beides, aber richtig“:
- Overlay-QoS: bezieht sich auf die Klassifizierung und Markierung des Tenant-Traffics (innerer Header), z. B. DSCP für Voice/Video/Business.
- Underlay-QoS: bezieht sich auf die Behandlung des gekapselten VXLAN-Verkehrs (äußerer Header), z. B. welche Queue ein UDP/VXLAN-Paket bekommt.
Wichtig: QoS-Wirkung entsteht an Engpässen (Egress-Interfaces). In der Fabric sind das häufig Uplinks, Border Leafs, Interconnects und Service-Edges. Wenn diese Geräte das Underlay-Paket anhand des äußeren Headers queuen, muss der äußere Header die richtige Klasse tragen – sonst verpufft jede Overlay-Markierung.
DSCP-Propagation: Das Kernkonzept für VXLAN-QoS
Damit Klassen durch ein Overlay sauber funktionieren, brauchen Sie eine klare Strategie, wie DSCP (oder CoS) vom inneren in den äußeren Header übernommen wird. In der Praxis gibt es drei Grundvarianten:
- Copy (Propagation): DSCP des inneren IP-Headers wird in den äußeren IP-Header kopiert (typisch für konsistentes End-to-End-QoS).
- Set/Rewrite: Der äußere Header erhält eine feste DSCP-Klasse, unabhängig vom inneren (z. B. wenn Underlay nur wenige Klassen unterstützt oder Tenant-Markierungen nicht vertraut werden).
- Policy-based Mapping: Inneres DSCP wird über Regeln auf ein Underlay-DSCP-Mapping abgebildet (z. B. mehrere Tenant-Werte werden auf wenige Underlay-Klassen reduziert).
Für Telco-nahe oder Enterprise-UC-Workloads ist Copy oder policy-basiertes Mapping meist sinnvoll, weil Echtzeitklassen (Audio/Voice) zuverlässig in Low-Latency-Queues landen müssen. Set/Rewrite ist sinnvoll, wenn Sie Tenant-Markierungen nicht vertrauen oder wenn das Underlay bewusst „vereinheitlicht“ wird.
Ein praxistaugliches Klassenmodell für EVPN/VXLAN-Fabrics
Ein häufiger Fehler ist, zu viele Klassen durch das Underlay schleusen zu wollen. In Fabrics bewährt sich ein kleines, klares Klassenmodell, das hardwarefreundlich ist. Ein sinnvolles Basismodell umfasst:
- Real-Time Audio/Voice: höchste Echtzeitklasse, Low Latency, strict priority mit Limit.
- Interaktives Video: bevorzugt, gewichtete Klasse mit Garantien, keine strict priority.
- Business Critical: wichtige Apps/VDI/Steuerdaten, gewichtete Mindestanteile.
- Best Effort: Standardverkehr.
- Background/Scavenger: Backups/Updates, niedrig.
In Multi-Tenant-Umgebungen kann zusätzlich eine Klasse für Storage/Replication sinnvoll sein – aber nur, wenn das Underlay genug Hardware-Queues und klare Betriebsregeln dafür hat.
Trust Boundary in VXLAN: Wer darf markieren?
In EVPN/VXLAN ist Trust besonders kritisch, weil Markierungen über das Underlay die Queue-Wahl in der gesamten Fabric beeinflussen können. Ohne Trust Boundary kann eine einzelne VM durch falsches DSCP den Fabric-Betrieb stören.
- Untrusted Host/VM: Tenant-DSCP wird am Leaf-Access-Port überschrieben oder auf ein internes Profil gemappt.
- Trusted Domain: Markierungen werden akzeptiert, wenn sie aus kontrollierten Quellen kommen (z. B. UC-Server, SBC, managed Workloads).
- Conditional Trust: Markierungen werden akzeptiert, aber über Policer/Profiles begrenzt; Überschuss wird remarkt oder gedroppt.
Best Practice ist, Trust am Leaf-Edge zu definieren: Dort ist die beste Stelle, um Markierungen zu validieren, zu normalisieren und auf ein Underlay-fähiges Klassenmodell zu reduzieren.
Policer in EVPN/VXLAN: Wo sie hingehören und wie sie nicht schaden
Policer sind in Fabrics wichtig für Fairness und Schutz. Falsch platziert sind sie jedoch eine häufige Ursache für Voice- und Video-Probleme, weil Policing Drops erzeugt – und Drops sind für Echtzeit sehr schädlich. In EVPN/VXLAN sollten Sie Policers vor allem für zwei Zwecke einsetzen:
- Tenant-Fairness: Ein Tenant oder eine Portgruppe darf nicht unendlich viel Premium-Traffic erzeugen.
- Schutz von Low-Latency-Klassen: Strict Priority muss begrenzt und gegen Missmarkierung abgesichert sein.
Ingress-Policing am Leaf: der typische Einsatzpunkt
Am Leaf, dort wo Traffic in die Fabric gelangt, lässt sich pro Port, pro Tenant (VRF) oder pro Segment (z. B. VLAN/VNI) profilieren. Das ist skalierbar und verhindert, dass Premium-Klassen „aufblähen“.
- Pro Klasse policen: Voice, Video und Best Effort getrennt budgetieren.
- Remarking statt Drop: Überschuss aus Premium kann als Best Effort weiterlaufen, statt sofort zu droppen (serviceabhängig).
- Voice möglichst nicht droppen: Voice-Budgets realistisch dimensionieren, damit Policer selten greifen.
Egress-Policing: vorsichtig einsetzen
Policing am Egress kann Drops in Clustern erzeugen, insbesondere bei Microbursts. Wenn Sie Egress-Limits brauchen (z. B. auf einem Interconnect), ist Shaping oft die bessere Alternative, weil es glättet statt zu verwerfen.
Shaping und Queue-Limits: Microbursts und Bufferbloat in der Fabric kontrollieren
EVPN/VXLAN-Fabrics sind bursty. Microbursts entstehen durch Synchronität vieler Sender und durch schnelle Server-NICs, die auf langsamer dimensionierte Uplinks treffen. Ohne Kontrolle können Queues kurzfristig überlaufen oder stark anwachsen.
- Queue-Limits bewusst wählen: Zu große Puffer erzeugen Latenzspitzen (Bufferbloat), zu kleine Puffer erzeugen Drops. Für Echtzeit gilt: eher klein und schnell.
- Shaping an echten Engpässen: Interconnects, Border Leafs, Service Edges und Rate-Limits profitieren von Shaping, um Drop-Cluster zu vermeiden.
- Priorität mit Limit: Strict Priority für Audio nur begrenzt, damit das Underlay stabil bleibt.
Ein praktischer Hinweis: Viele „VXLAN-QoS-Probleme“ sind in Wirklichkeit Microburst-Probleme. Wenn Sie nur auf Durchschnittsauslastung schauen, sehen Sie das nicht. Queue-Depth und Drops pro Klasse sind die aussagekräftigeren Indikatoren.
EVPN/VXLAN-Engpasspunkte: Wo QoS besonders sauber sein muss
In Fabrics sind bestimmte Rollen besonders anfällig für Congestion und daher QoS-kritisch:
- Border Leafs: Übergang zu WAN/Internet/Metro/Cloud; hier treffen viele Flows zusammen.
- Service Leafs: Firewalls, Load Balancer, NAT, SBCs; oft CPU- und Interface-lastig, hohe Burstigkeit.
- Anycast Gateway Leafs: Gateway-Funktionen können Hotspots erzeugen, wenn Traffic ungünstig verteilt ist.
- Inter-Fabric Links: DCI oder Spine-Interconnects; bei Failover können Lastsprünge auftreten.
Für diese Punkte sollten Sie standardisierte QoS-Templates haben, die Underlay-Queues sauber definieren und gleichzeitig Tenant-Fairness über Policer/Profiles absichern.
Klassenübergreifende Designregeln: Audio vor Video, Video kontrolliert
In EVPN/VXLAN gilt die gleiche Echtzeitlogik wie im Telco-Backbone – mit dem Unterschied, dass Fabrics sehr schnell und sehr bursty sind:
- Audio/Voice: höchste Priorität, Low Latency, strict priority mit Limit.
- Video: bevorzugt, aber gewichtet; keine strict priority, sonst verdrängt es andere Klassen.
- Best Effort: fair, aber mit kontrollierten Puffern.
- Background: bewusst niedrig, damit Echtzeit nicht leidet.
Wenn Sie diese Reihenfolge verletzen, sehen Sie typischerweise genau die Klassiker: Audioaussetzer bei gleichzeitigem Screen Sharing, Video-Freeze bei Storage-Bursts oder instabile Latenz bei Backups.
Monitoring und Validierung: QoS in EVPN/VXLAN nachweisen
QoS in einer Fabric ist nur dann vertrauenswürdig, wenn Sie es messen können. Gerade weil Overlay/Underlay getrennt sind, braucht Monitoring zwei Blickwinkel: die Markierung und die tatsächliche Queue-Behandlung.
- Markierungs-Checks: DSCP inner/outer prüfen, insbesondere an Tunnel-Ingress und -Egress.
- Queue-KPIs: Drops pro Klasse, Queue-Depth, Queueing Delay, Scheduler-Auslastung.
- Policer-KPIs: Policer-Hits, Remarking-Events, Drop-Cluster, Profilüberschreitungen pro Tenant/Port.
- Service-KPIs: MOS/R-Faktor für Voice (wo verfügbar), QoE-Indikatoren für Video/UC (Freeze-Events, Bitrate-Switches).
Ein operativer Leitsatz ist: Drops in der Echtzeitklasse sind ein Incident. In Fabrics sollten Voice/Audio-Pakete praktisch nie gedroppt werden; falls doch, sind Queue-Limits, Policer oder Microbursts die wahrscheinlichsten Ursachen.
Häufige Fehler bei QoS in EVPN/VXLAN
- DSCP nur im inneren Header: Underlay queuet nach äußerem Header, Echtzeit landet im Best Effort.
- Unklare Trust Boundary: VMs markieren alles als Premium, Strict Priority läuft über, Fabric wird instabil.
- Policing auf Echtzeit: harte Drops auf Voice/Audio führen zu Aussetzern; Budgets sind zu eng oder am falschen Punkt.
- Zu viele Klassen im Underlay: Hardware-Queues reichen nicht, Mapping wird inkonsistent.
- Keine Queue-Limits: Bufferbloat erzeugt Latenzspitzen, UC-Qualität sinkt trotz „wenig Loss“.
- Keine Hotspot-Betrachtung: Border/Service Leafs werden überlastet, obwohl der Rest der Fabric „grün“ ist.
Praxis-Blueprint: So setzen Sie Klassen und Policer in EVPN/VXLAN sinnvoll um
- Klassenmodell festlegen: wenige Klassen, klare Bedeutungen (Audio, Video, Business, Best Effort, Background).
- Trust Boundary am Leaf definieren: Untrusted Hosts remarken, Trusted Domains akzeptieren, conditional trust profilieren.
- DSCP-Propagation entscheiden: Copy oder policy-basiertes Mapping inner->outer; Underlay muss die Klassen queuen können.
- Underlay-Queues standardisieren: identische Templates für Leaf/Spine/Border, inklusive Queue-Limits.
- Policer am Ingress: pro Tenant/Port/Segment Budgetierung, Remarking bevorzugen, Voice-Budget realistisch dimensionieren.
- Shaping an Engpässen: Border Leafs, Interconnects, Service Edges – Drop-Cluster vermeiden.
- Monitoring etablieren: DSCP inner/outer, Drops/Queue-Depth/Policer-Hits pro Klasse als Standard-Dashboards.
Häufige Fragen zu VXLAN-QoS
Muss ich QoS im Overlay oder im Underlay machen?
Beides, aber mit klarer Rollenverteilung. Overlay-QoS definiert die Serviceklasse des Tenant-Traffics. Underlay-QoS entscheidet, in welcher Queue der gekapselte VXLAN-Verkehr landet. Ohne DSCP-Propagation oder Mapping wird Underlay-QoS die Overlay-Absicht nicht sehen.
Warum sind Policers in Fabrics so riskant für Voice?
Weil Policing Drop-Spitzen erzeugen kann. Voice ist gegen Drops sehr empfindlich. Deshalb sollten Voice-Budgets so dimensioniert sein, dass Policers selten greifen, und Überschuss sollte – wenn möglich – remarkt statt gedroppt werden.
Was ist der schnellste Hebel, wenn UC-Qualität in der VXLAN-Fabric schlecht ist?
Prüfen Sie zuerst, ob der äußere Header korrekt markiert ist und ob die Underlay-Queues diese Markierung tatsächlich auf Low-Latency/gewichtete Klassen abbilden. Danach prüfen Sie Drops und Queue-Depth pro Klasse sowie Policer-Hits an Border/Service Leafs. In vielen Fällen liegt die Ursache in fehlender DSCP-Propagation, zu großen Puffern oder Microburst-bedingten Drop-Clustern.