QoS-Design für Ausfälle: Wie Redundanz die Qualität beeinflusst

QoS-Design für Ausfälle ist eine Disziplin, die oft unterschätzt wird, weil Redundanz in vielen Projekten primär als Verfügbarkeitsfrage betrachtet wird: „Wenn ein Link ausfällt, geht es über den zweiten.“ Für Echtzeitdienste wie Voice und Video zählt jedoch nicht nur, dass Verkehr ankommt, sondern wie er ankommt. Failover verändert Pfade, Latenzprofile, Jitter, Paketverlustmuster, MTU, QoS-Mappings und sogar die Reihenfolge, in der Pakete eintreffen. Dadurch kann es passieren, dass ein Netz „hochverfügbar“ ist, aber im Fehlerfall hörbar schlechtere Sprachqualität liefert oder Videokonferenzen stärker ruckeln – obwohl technisch kein Totalausfall vorliegt. In Telco-Backbones, Mobile Backhaul, Metro-Umgebungen und Enterprise-WANs ist das besonders kritisch: Ein Ausfall erzeugt in Sekundenbruchteilen Traffic-Umschichtungen, Microbursts, Queue-Überläufe und Routing-Convergence-Phasen. Wenn QoS-Profile und Redundanzmechanismen nicht gemeinsam geplant werden, entstehen typische Nebenwirkungen: Premium-Inflation im Backup-Pfad, falsch gemappte Klassen an einer alternativen Übergabe, Policer-Drops durch geänderte Burst-Profile oder MTU-Blackholes durch andere Tunnel/Encapsulation. Ein professionelles QoS-Design für Ausfälle behandelt Redundanz daher als Qualitätsproblem: Pfade müssen nicht nur redundant, sondern qualitativ gleichwertig oder zumindest vorhersehbar degradierend sein. Dieser Artikel zeigt praxisnah, wie Redundanz die Qualität beeinflusst, welche Failover-Szenarien für Voice & Video besonders kritisch sind und wie Sie QoS, Routing und Kapazität so auslegen, dass die Nutzerqualität auch während und nach einem Ausfall stabil bleibt.

Warum Redundanz die QoS-Realität verändert

Im Normalbetrieb ist QoS meist auf stabile Pfade abgestimmt: Bandbreitenbudgets, Queue-Gewichte, Shaper-Raten, MPLS-TC-Mappings und DSCP-Trust Boundaries sind konsistent. Bei einem Ausfall passiert jedoch mehr als ein „Pfadwechsel“:

• Lastverschiebung: Traffic, der vorher auf zwei Links verteilt war, läuft plötzlich über einen.
• Routing-Convergence: IGP/BGP/TE berechnet neu; kurzzeitig entstehen Delay-Spitzen oder Drops.
• Pfadqualität ändert sich: andere Latenz, anderer Jitter, andere Engpässe, andere Queue-Topologien.
• QoS-Kette kann brechen: ein alternativer Pfad hat ein anderes Mapping oder verliert Markierungen in einem Tunnel/NNI.
• MTU/Encapsulation ändert sich: Backup-Pfade nutzen häufig andere Tunnel oder andere Underlay-MTUs.

Für Voice bedeutet das: Schon wenige Sekunden mit erhöhtem Jitter oder Drop-Clustern sind hörbar. Für Video bedeutet es: Qualitäts-Pendeln, Freezes oder Bitrate-Downshifts, insbesondere wenn Throughput-Fenster instabil werden.

Ausfalltypen: Nicht jeder Failover ist gleich

Um QoS für Ausfälle sauber zu designen, müssen Sie die typischen Failover-Arten unterscheiden. Sie erzeugen unterschiedliche Qualitätsrisiken.

• Link Failover: eine physische Verbindung fällt weg (Optik, Funkstrecke, Port). Typisch: plötzliche Lastverdichtung.
• Node Failover: Router/Switch/PE fällt aus. Typisch: größere Pfadänderung, mehr Konvergenzzeit, mehr Umwege.
• Path Failover (TE/SR-TE): Traffic wird auf einen anderen TE-Pfad umgelegt. Typisch: Latenzsprung, aber kontrollierter als reines IGP.
• Provider/NNI Failover: Interconnect ändert sich (Transit/Peering). Typisch: externe Unwägbarkeiten, DSCP-Neutralisierung.
• Overlay Failover: Tunnel/VRF/SD-WAN-Policy wechselt. Typisch: andere Encapsulation, andere Outer-DSCP, MTU-Risiko.

Best Practice: Für jeden Ausfalltyp definieren Sie ein erwartbares Qualitätsverhalten (z. B. „Voice darf während Convergence kurz degradiert sein, aber keine anhaltenden EF-Drops“).

Das zentrale Qualitätsproblem im Failover: Traffic verdichtet sich

Der häufigste Grund für Qualitätsverlust im Ausfallfall ist einfache Mathematik: Im Normalbetrieb nutzen Sie vielleicht zwei Links zu je 10 Gbit/s, im Failover bleibt nur einer mit 10 Gbit/s übrig. Wenn die Last vorher 12 Gbit/s betrug, ist im Failover Congestion garantiert.

• Kapazitäts-Reserven: N+1-Design bedeutet, dass ein verbleibender Pfad die Peak-Last tragen können muss.
• Klassenbudgets: Wenn Video/BE im Normalbetrieb okay sind, können sie im Failover den Premiumbereich indirekt belasten, wenn Gewichte falsch sind.
• Microbursts: Umschaltung erzeugt Burst-Spitzen, die Queues überlaufen lassen.

QoS-Design für Ausfälle beginnt daher mit Kapazitätsdesign: Welche Last muss im Failover getragen werden, und welche Klassen müssen dabei garantiert stabil bleiben?

LLQ und Premium-Inflation im Failover: Wenn „Voice“ plötzlich zu groß wird

Viele Netze schützen Voice über EF/LLQ. Im Failover entstehen zwei typische Risiken:

• LLQ-Limit passt nicht mehr: Durch Verdichtung steigt Premium-Last, das Limit wird erreicht, EF-Drops entstehen.
• Fehlmarkierung wird sichtbar: Im Normalbetrieb fällt Premium-Inflation nicht auf, im Failover kippt das System.

Deshalb ist ein Failover-Test oft der beste „Stresstest“ für Trust Boundaries: Wenn EF-Volumen unplausibel hoch ist, wird das im Failover zuerst hörbar. Ein robustes Design setzt EF-Limits konservativ, akzeptiert EF nur aus kontrollierten Quellen und nutzt Remarking/Profilierung an der Netzgrenze.

Routing und QoS: Convergence-Zeit ist ein QoE-Faktor

Routing-Konvergenz ist für Daten oft „kurz egal“, für Echtzeit aber kritisch. Während der Umschaltung können Pakete verloren gehen oder Umwege nehmen.

• IGP Convergence: hängt von Timern, Topologie und CPU-Last ab; in großen Netzen kann es spürbar sein.
• BFD: beschleunigt Failure Detection, reduziert „Blackholing“, aber kann mehr Control-Load erzeugen.
• ECMP: kann nach Umschaltung neu hashen; Flows verteilen sich anders, Burst-Spitzen entstehen.
• Fast Reroute (FRR): kann Umschaltung nahezu sofort machen, aber Pfadqualität muss passen.

Für QoS bedeutet das: Control-Plane-Traffic braucht eigene Schutzmechanismen (Control-Klasse), damit Convergence nicht durch Congestion verzögert wird. Und: Der Failover-Pfad muss QoS-semantisch identisch sein, sonst ist FRR zwar schnell, aber qualitativ schlecht.

Pfadgleichwertigkeit: „Redundant“ ist nicht automatisch „gleich gut“

Viele Redundanzdesigns sind topologisch redundant, aber qualitativ ungleich. Typische Unterschiede:

• Latenzsprung: Backup-Pfad ist länger, hat mehr Hops oder andere Optik-/Funkstrecken.
• Andere Engpässe: Backup läuft über stärker überbuchte Aggregation.
• Andere Queue-Implementierung: anderer Routertyp, andere Default-Buffer, andere WRED-Parameter.
• Mapping-Loch: DSCP→CoS→TC ist auf dem Backup-Pfad nicht identisch.

Ein gutes QoS-Design für Ausfälle definiert daher Zielwerte pro Pfad: nicht nur „Connectivity“, sondern „Delay/Jitter/Loss pro Klasse“ muss im Backup innerhalb akzeptabler Grenzen liegen.

MTU und Encapsulation im Failover: Kleine Unterschiede, große Wirkung

Failover verändert häufig die Kapselung: SD-WAN wählt einen anderen Tunnel, VPN terminiert anders, MPLS-Pfade nutzen andere Labelstacks. Dadurch kann die effektive MTU sinken oder PMTUD scheitern.

• Fragmentierung: erhöht Verlustwahrscheinlichkeit, weil Fragmentverlust Paketverlust bedeutet.
• PMTUD-Blackhole: wenn ICMP „Packet too big“ gefiltert wird, werden große Pakete einfach verworfen.
• Symptom: Einweg-Audio, Setup-Probleme, sporadische Aussetzer nur im Failover.

Best Practice: Backup-Pfade müssen die gleiche oder ausreichend große MTU haben, oder Sie planen Headroom und kontrollierte MSS/MTU-Anpassungen. Andernfalls kann Failover zu „mystischen“ Qualitätsproblemen führen.

Shaping im Failover: Warum Upstream-Profile plötzlich nicht mehr passen

Shaping ist der wichtigste Hebel gegen Bufferbloat und Burst-Drops. Im Failover ändert sich jedoch die Linkrate oder das aktive Medium:

• Andere Linkrate: Backup-Link ist langsamer; Shaper muss sich anpassen, sonst entstehen Drops im Providerpolicer oder in CPE-Puffern.
• Andere Burst-Charakteristik: anderer Access (Microwave statt Fiber) → andere Microburst-Muster.
• Shaper dauerhaft voll: wenn Failover-Pfad zu knapp ist, entsteht Dauerstau und Echtzeit leidet trotz LLQ.

Ein robustes Design berücksichtigt Failover-Raten: Shaping-Policies sollten pfadabhängig dimensioniert oder dynamisch anpassbar sein, damit die Echtzeitklasse auch im Backup nicht unter Bufferbloat leidet.

Multi-Domain QoS: Failover über Providergrenzen ist besonders riskant

Wenn Redundanz über Partnernetze, Transit oder Wholesale läuft, ist QoS-Semantik nicht automatisch garantiert. Typische Probleme:

• DSCP-Neutralisierung: an Übergängen wird DSCP auf 0 gesetzt; Premium wirkt nicht mehr.
• Unterschiedliche Klassenmodelle: „Video-AF“ bei Partner A ist nicht gleich „Video-AF“ bei Partner B.
• Kapazitätspeaks: Interconnect-Ports sind in Busy Hour überlastet, Failover verschärft das.

Für strenge SLAs ist daher häufig private Interconnect-Redundanz mit klarer QoS-Übergabe sinnvoller als „best-effort Redundanz“ über offene Pfade. Für weniger kritische Dienste kann man degradierende Profiles akzeptieren – aber bewusst und dokumentiert.

Teststrategie: Failover testen, ohne Produktion zu gefährden

QoS-Design für Ausfälle ist nur dann belastbar, wenn es getestet wird. Gute Tests sind reproduzierbar, kurz und klassenbewusst.

• Active Probes pro Klasse: EF/Voice, AF/Video, BE – vor, während und nach Failover messen (Delay/Jitter/Loss).
• Telemetrie-Korrelation: Queueing Delay/Drops, Policer/Shaper Events, DSCP-Verteilungen im Incident-Zeitfenster.
• Segmentierung: Access→Metro, Metro→Core, Core→NNI getrennt; so finden Sie den Drift-Ort.
• Time-Health: NTP/PTP stabilisieren, sonst sind One-Way-Analysen während Failover unzuverlässig.

Ein gutes Ergebnis ist nicht „keine Veränderung“, sondern „vorhersehbare, kontrollierte Degradation ohne kritische Drops in Voice“.

Designregeln: QoS und Redundanz gemeinsam planen

• N+1 Kapazitätsprinzip: Der verbleibende Pfad muss Peak-Last (oder definierte SLA-Last) tragen können.
• Pfadgleichwertigkeit: Backup-Pfade müssen QoS-semantisch identisch gemappt sein (DSCP↔CoS↔TC).
• LLQ strikt und limitiert: Voice in LLQ mit Limit; Trust Boundary verhindert Premium-Inflation im Failover.
• Video gewichtet, nicht priorisiert: Video bekommt garantierte Anteile, aber keine strict priority.
• Shaping an Engpässen: pfadabhängig dimensioniert, damit Bufferbloat im Failover nicht eskaliert.
• MTU Headroom sicherstellen: keine Fragmentierung und keine PMTUD-Blackholes durch alternative Tunnel.
• Control-Plane schützen: Routing/Signaling nicht in Best Effort verhungern lassen; Convergence ist QoE-relevant.

Typische Fehlersignaturen im Failover

• EF-Drops nur im Failover: Premium-Inflation oder LLQ-Limit zu eng, Kapazität im Backup zu knapp.
• MOS fällt ohne Drops: Bufferbloat/Queueing Delay Peaks im Backup-Pfad, fehlendes Shaping.
• Einweg-Audio nach Failover: MTU/PMTUD oder NAT/Firewall-State-Themen, häufig bei Tunnelwechsel.
• Video freeze häufiger: Drop-Cluster oder Throughput-Wellen durch neue Engpässe, Policer-Drops.
• Nur bestimmte Ziele betroffen: Interconnect/Peering-Pfadwechsel, DSCP-Neutralisierung außerhalb der Domäne.

Praxis-Blueprint: QoS-Design für Ausfälle in 8 Schritten

• Schritt 1: Failover-Szenarien definieren (Link, Node, TE, Provider, Overlay).
• Schritt 2: SLA-Ziele pro Service festlegen (Voice, Video, Signaling, BE) – auch im Failover.
• Schritt 3: N+1 Kapazität und Klassenbudgets berechnen (Peak-Last im Failover).
• Schritt 4: Mappings vereinheitlichen (DSCP↔CoS↔MPLS-TC, Inner↔Outer) über alle Pfade.
• Schritt 5: Scheduler-Design festlegen (LLQ für Voice mit Limit, Video gewichtet, Control robust, BE fair).
• Schritt 6: Shaping/Profilierung pfadabhängig dimensionieren, Burst-Handling prüfen.
• Schritt 7: MTU/Encapsulation für alle Pfade validieren, PMTUD ermöglichen.
• Schritt 8: Failover testen und messen (Probes pro Klasse, Queue-/Policer-Telemetrie, QoE-KPIs).

Häufige Fragen zu QoS und Redundanz

Kann Redundanz die Sprachqualität sogar verschlechtern, obwohl sie Ausfälle abfängt?

Ja, wenn Backup-Pfade qualitativ schlechter sind oder wenn im Failover Congestion entsteht. Redundanz erhöht Verfügbarkeit, aber ohne N+1-Kapazität, konsistentes Mapping und korrektes Shaping kann die QoE im Fehlerfall deutlich schlechter werden, obwohl die Verbindung technisch weiterläuft.

Was ist der wichtigste Schutzmechanismus für Voice im Failover?

Eine strikt limitierte LLQ für Voice plus eine harte Trust Boundary gegen Premium-Inflation, kombiniert mit Shaping an Engpässen. Damit verhindern Sie EF-Drops und Delay-Spitzen, die im Failover am schnellsten hörbar werden.

Wie messe ich, ob Backup-Pfade QoS-semantisch gleichwertig sind?

Mit aktiven Probes pro Klasse (EF/AF/BE) vor/während/nach Failover und mit Telemetrie (DSCP-Verteilungen, Classify-Hits, Queueing Delay/Drops, Policer/Shaper Events) an den Engpässen. Wenn Klassen und Mappings identisch wirken und die Perzentile innerhalb definierter Grenzen bleiben, ist der Backup-Pfad qualitativ verifiziert.