QoS in virtualisierten Netzfunktionen ist ein entscheidender Erfolgsfaktor, sobald Firewalls, SBCs, Router, Load Balancer oder komplette Telco-NFVs (VNF/CNF) nicht mehr auf dedizierter Hardware laufen, sondern auf gemeinsamen x86-Hosts in Virtualisierungs- oder Containerplattformen. In solchen Umgebungen verschiebt sich die klassische QoS-Denke: Nicht nur Router-Queues und WAN-Shaper bestimmen Latenz und Paketverlust, sondern auch vSwitch Queues, virtuelle NICs, CPU Scheduling, NUMA-Topologie und das Zusammenspiel aus Hypervisor, Host-Kernel und Datenpfad-Acceleration (z. B. vSwitch-Offloads). Gerade Echtzeitdienste wie RTP/SRTP, WebRTC-Medien, Signalisierung und Low-Latency-Streams reagieren empfindlich auf Mikro-Jitter, der in einem rein physikalischen Netz kaum sichtbar wäre. Eine QoS-Policy, die im physischen Netz „korrekt“ aussieht, kann in der Virtualisierung trotzdem scheitern, wenn vCPUs nicht rechtzeitig laufen, wenn Interrupts ungünstig verteilt sind oder wenn der vSwitch Pakete in Software puffert, bevor sie überhaupt eine klassische QoS-Queue erreichen. Dieser Artikel erklärt, wie QoS in virtualisierten Netzfunktionen wirklich funktioniert, welche Rolle vSwitch Queues und CPU Schedulings spielen und wie Sie Design, Testing und Monitoring so aufbauen, dass Echtzeit-Performance auch in geteilten Compute-Umgebungen stabil bleibt.
Warum QoS in VNF/CNF-Umgebungen anders ist als auf klassischer Netzwerkhardware
Auf dedizierten Routern und Switches ist der Datenpfad weitgehend deterministisch: ASICs, Hardware-Queues, definierte Scheduler und klar messbare Per-Class Drops. In einer Virtualisierungsumgebung teilen sich viele Komponenten dieselben Ressourcen: CPU, Cache, Memory-Bandbreite, PCIe, NIC-Queues und oft auch Storage (indirekt relevant, wenn Logging/Encryption CPU bindet). QoS ist damit nicht nur eine Frage von DSCP und Queueing, sondern von „Compute-Determinismus“. Ein Paket, das im vSwitch wartet, weil die zuständige vCPU gerade nicht läuft, erfährt Latenz, ohne dass Ihr Router-Queueing darauf Einfluss hätte.
- Shared Compute: mehrere VNFs konkurrieren um CPU-Zeit, Cache und Memory.
- Software-Queues: vSwitch und vNICs puffern in Software, oft ohne klassisches QoS-Scheduling.
- CPU-Jitter: Scheduling-Latenz erzeugt Paket-Jitter, selbst bei niedriger Linkauslastung.
- Offloads: Hardware-Offload kann helfen oder schaden, wenn QoS-Markierung/Queue-Mapping nicht konsistent ist.
Der Datenpfad in der Virtualisierung: Wo Latenz und Jitter entstehen
Um QoS in virtualisierten Netzfunktionen zu beherrschen, müssen Sie den typischen Datenpfad verstehen. Ein Paket trifft an der physischen NIC ein, wird über RX-Queues und Interrupts verarbeitet, wandert in den Host-Kernel oder in einen beschleunigten Datenpfad, wird durch den vSwitch geleitet und schließlich an eine virtuelle NIC der VNF übergeben. Danach verarbeitet die VNF das Paket (ggf. Encryption, NAT, DPI, Signalisierung), und der Pfad geht zurück über vNIC, vSwitch und NIC-TX. Jeder dieser Schritte kann queueing-bedingte Wartezeiten verursachen.
- NIC RX/TX Queues: Hardware-Queues, die per RSS/Hashing verteilt werden.
- Interrupt-Handling: wann und auf welchem CPU-Core Pakete „abgeholt“ werden.
- vSwitch Forwarding: Software-Switching, ggf. mit Flow-Caches und eigenen Puffermechanismen.
- vNIC Queues: virtuelle Warteschlangen zwischen vSwitch und VM/Container.
- VNF Processing: Paketverarbeitung ist CPU-intensiv; Scheduling entscheidet über Timing.
vSwitch Queues: Der unterschätzte Engpass vor der eigentlichen QoS-Policy
vSwitch Queues sind in vielen Designs die erste Stelle, an der Echtzeitpakete „stehen bleiben“, obwohl das physische Netz noch entspannt ist. Ursache ist nicht Bandbreite, sondern Verarbeitungskapazität: Wenn der vSwitch oder die vNIC nicht schnell genug bedient werden, wächst die Queue. Das kann zu Jitter führen, bevor überhaupt ein klassischer WAN-Shaper oder eine Router-LLQ greift. Besonders gefährlich ist das bei kleinen, häufigen Paketen (RTP), weil die Paket-Rate hoch ist und Scheduling-Schwankungen schneller sichtbar werden.
Warum Paket-Rate oft wichtiger ist als Mbit/s
RTP mit 20-ms-Paketisierung erzeugt viele kleine Pakete. Selbst bei geringer Bandbreite steigt die Packets-per-Second-Last. Virtualisierte Datenpfade geraten dann eher an CPU/Interrupt-Limits als an Linklimits. Das erklärt, warum eine VNF „nur“ wenige Mbit/s verarbeitet, aber trotzdem Jitter produziert: Es ist ein PPS-Problem, kein Durchsatzproblem.
CPU Scheduling: Die eigentliche „Queue“ in VNF-Umgebungen
In VNFs ist CPU Scheduling die zentrale QoS-Determinante. Wenn eine vCPU nicht läuft, kann sie keine Pakete verarbeiten. Das führt zu Wartezeit in vorgelagerten Queues und damit zu Jitter. In Echtzeitkontexten ist nicht nur die durchschnittliche CPU-Auslastung relevant, sondern die Verfügbarkeit innerhalb kurzer Zeitfenster. Eine VNF kann im Mittel bei 30 % CPU liegen und trotzdem alle paar Sekunden Scheduling-Spikes haben, die Audioqualität ruinieren.
- CPU Ready/Steal: Indikator, dass vCPUs warten müssen, obwohl sie arbeiten wollen.
- Context Switches: häufige Wechsel erhöhen Overhead und Variabilität.
- Run-Queue Length: zu viele runnable Threads pro Core führen zu Scheduling-Latenz.
- Co-Scheduling: bei mehreren vCPUs pro VNF kann ungleichmäßiges Scheduling Timing stören.
NUMA, CPU-Pinning und Affinität: Für QoS oft wichtiger als DSCP
NUMA-Topologie beeinflusst Latenz und Durchsatz massiv. Wenn vCPUs auf einem NUMA-Knoten laufen, aber die NIC oder Memory-Zuweisung auf einem anderen Knoten liegt, entstehen zusätzliche Zugriffszeiten und Cache-Misses. Für Echtzeit sind diese Effekte relevant, weil sie Jitter erhöhen. CPU-Pinning und NUMA-Affinität sind daher klassische Maßnahmen, um VNFs deterministischer zu machen: vCPUs werden an physische Kerne gebunden, Memory wird möglichst lokal alloziert, und die NIC-Interrupts werden auf passende Kerne verteilt.
- CPU-Pinning: reduziert Scheduling-Variabilität, weil vCPUs nicht „wandern“.
- NUMA-Alignment: vCPU, Memory und NIC möglichst auf demselben NUMA-Knoten.
- Interrupt-Affinität: RX/TX-Interrupts auf Kerne legen, die zur VNF passen.
- Core-Isolation: reservierte Kerne für Echtzeitpfade, um „Noisy Neighbors“ zu vermeiden.
QoS-Markierung in der Virtualisierung: DSCP Preservation und Re-Marking
Damit QoS end-to-end funktioniert, müssen Markierungen in VNF/CNF-Pfaden erhalten bleiben. In der Praxis gehen DSCP-Werte verloren, wenn der vSwitch sie nicht preservt, wenn Tunnel/Encapsulation DSCP nicht korrekt auf den Outer Header kopiert, oder wenn Security-Funktionen innerhalb der VNF neu terminieren und dabei DSCP zurücksetzen. Deshalb sollte die Trust Boundary auch in der Virtualisierung klar sein: Wo werden Markierungen akzeptiert, wo werden sie gesetzt, und wo werden sie normalisiert?
- DSCP Preservation: vSwitch/vNIC dürfen DSCP nicht „glattbügeln“.
- Inner->Outer Copy: bei Overlays/Tunneln muss QoS im Underlay sichtbar bleiben.
- Re-Marking am Edge: bei untrusted Quellen Markierung kontrolliert setzen statt blind übernehmen.
- Consistency: gleiches Mapping in VM, vSwitch und physischem Netz verhindert Klassen-Drift.
vSwitch QoS-Mechanismen: Was möglich ist und was nicht
Viele vSwitches bieten zumindest grundlegende QoS-Funktionen: Traffic Shaping pro vNIC, Limitierung pro Port, Priorisierung bestimmter Klassen oder einfache Queue-Profile. Der Umfang variiert stark. Entscheidend ist, realistische Erwartungen zu haben: vSwitch-QoS ersetzt selten die robuste Per-Class-Scheduler-Logik eines WAN-Edges, kann aber helfen, lokale Overcommitment-Effekte zu glätten und „Noisy Neighbor“-Traffic zu begrenzen.
- Rate Limiting/Shaping: pro vNIC oder Port, um Spitzen zu glätten.
- Priority Handling: einfache Priorisierung kann existieren, ist aber nicht immer strikt deterministisch.
- Queue Separation: je nach Implementierung können mehrere Software-Queues existieren.
- Limitierung: vSwitch-QoS ist häufig eher „Schutz“ als „End-to-End-Garantie“.
CPU-Scheduling vs. Netzwerk-QoS: Wie beide Ebenen zusammenspielen
Ein häufiger Fehler ist, nur Netzwerk-QoS zu optimieren und CPU-Scheduling zu ignorieren. In VNF-Umgebungen müssen beide Ebenen zusammenpassen: Wenn Sie Voice strikt priorisieren, aber die VNF-Threads nicht rechtzeitig CPU erhalten, wird die Priorität im Netz wirkungslos. Umgekehrt kann perfektes CPU-Pinning wenig helfen, wenn die Markierung nicht stimmt und Voice im Best Effort landet. Ein robustes Design definiert daher eine doppelte Priorisierung: Netzwerkseitig (Queues, Shaping) und compute-seitig (CPU-Affinität, Ressourcenreservierung).
- Network-first: Voice/Media korrekt klassifizieren und in passende Queues bringen.
- Compute-first: kritische VNFs mit reservierten Ressourcen und geringer Scheduling-Variabilität betreiben.
- Cross-layer Monitoring: Queue Delay und CPU Ready zusammen betrachten, um echte Ursachen zu erkennen.
Containerisierte Netzfunktionen: CNF-QoS und Cgroup-Scheduling
Bei CNFs verschiebt sich das Thema weiter: Statt vCPU-Scheduling in einer VM spielen cgroups, CPU-Quotas und Kernel-Scheduler eine Rolle. CPU-Limits können zu Throttling führen, das sich wie sporadischer Paketverlust/Jitter anfühlt. Außerdem können Netzwerkpfade über virtuelle Interfaces und Software-Bridges laufen, in denen Queueing entsteht. Für QoS-Designs in CNFs ist deshalb wichtig, CPU- und Netzwerklimits konsistent zu planen: Eine Echtzeit-CNF sollte nicht in ein zu hartes CPU-Quota laufen, wenn sie Peak-PPS verarbeiten muss.
- CPU Quotas/Throttling: harte Limits erzeugen Timing-Spikes.
- Pod-to-Pod Networking: zusätzliche virtuelle Hops erhöhen Variabilität.
- Node Affinity: Platzierung auf geeigneten Nodes (NUMA, NIC-Nähe) ist entscheidend.
- Traffic Classes: Mapping von DSCP zu Host-Queues muss auch im Containerpfad erhalten bleiben.
Erfolgsmetriken: Wie Sie QoS in VNFs/CNFs objektiv messen
In virtualisierten Umgebungen müssen Sie Netzwerk- und Compute-Metriken gemeinsam interpretieren. Reine Interface-Auslastung ist noch weniger aussagekräftig als im physischen Netz. Sinnvoll ist ein Messset, das sowohl Servicequalität (RTP/WebRTC) als auch vSwitch/Host-Verhalten abdeckt.
- QoE-Metriken: RTP Loss (Sequenzlücken), Jitter, RTCP-Reports, MOS-Trends, WebRTC getStats.
- Queue-Metriken: Queue Depth/Delay auf WAN-Edge, plus vSwitch/vNIC Queue-Indikatoren.
- Per-Class Drops: Drops pro Klasse (Voice/Media) als harter Qualitätsindikator.
- CPU-Metriken: CPU Ready/Steal, Throttling (cgroups), Run-Queue, Context Switch Rate.
- NIC/Interrupt-Metriken: RX/TX Queue Drops, SoftIRQ-Last, Interrupt-Verteilung.
Typische Fehlerbilder und schnelle Root-Cause-Hinweise
Viele QoS-Probleme in VNFs wirken wie klassische Congestion, sind aber compute-getrieben. Ein systematischer Blick auf Muster spart Zeit.
- Jitter-Spikes ohne WAN-Queueing: häufig CPU Scheduling/Noisy Neighbor oder vSwitch Queueing.
- Loss-Spikes mit „Policer Drops“: Policers in virtuellen Pfaden oder zu harte Rate-Limits/Quotas.
- Voice in Best Effort: DSCP nicht preservt, Trust Boundary im vSwitch/Firewall-Pfad falsch.
- Nur bei Peak-Meetings: PPS-Spitzen überfordern vSwitch/CPU, nicht Bandbreite.
- Asymmetrische Qualität: RX-Interrupts/CPU-Affinität nur in einer Richtung ungünstig.
Lab- und Regression-Tests: QoS in Virtualisierung reproduzierbar validieren
Weil virtuelle Datenpfade stark von Hostzustand und Scheduling abhängen, sind Regression Tests besonders wertvoll. Ein guter Testmix kombiniert Voice-like und Media-like Profile mit Best-Effort-Störlast und beobachtet gleichzeitig Queue- und CPU-Metriken. Ziel ist nicht nur „keine Drops“, sondern „stabile Perzentile“: Jitter 95p/99p, Queue Delay 99p, CPU Ready Peaks. So erkennen Sie früh, ob ein Hypervisor-Update, ein neues Host-Image oder eine geänderte Placement-Policy QoS verschlechtert.
- Voice-like Probe: konstantes Intervall, kleine Pakete, DSCP Voice.
- Congestion-Proof: Bulk saturiert den Engpass, Voice bleibt stabil.
- Noisy-Neighbor Simulation: zusätzliche CPU-Last erzeugen und prüfen, ob Echtzeit kippt.
- Placement Test: VNF auf anderem NUMA-Node platzieren und Effekte vergleichen.
Praktische Designleitlinien: QoS in Virtualisierten Netzfunktionen stabil bauen
- Engpass kontrollieren: Shaping am WAN/Internet-Edge auf Realrate, damit Congestion nicht in unkontrollierten Puffern passiert.
- Compute-Determinismus: CPU-Pinning, NUMA-Alignment und Core-Isolation für kritische VNFs.
- vSwitch-Guardrails: vNIC/vSwitch-Rate-Limits für Bulk, um Echtzeitpfade vor lokalen Spitzen zu schützen.
- DSCP konsequent: Trust Boundary definieren, DSCP preserven oder deterministisch re-marken, Inner->Outer Copy für Overlays.
- Monitoring koppeln: Queue Delay/Depth und Per-Class Drops mit CPU Ready/Throttling korrelieren.
- Regression etablieren: standardisierte QoS-Tests nach Host-Updates, Template-Changes und Plattformmigrationen.
