Fast Reroute und QoS: Umschalten ohne Sprachabbrüche

Fast Reroute und QoS sind in Provider- und Backbone-Netzen ein entscheidendes Duo, wenn Sie Sprachdienste (VoIP/IMS) und interaktives Video ohne hörbare Unterbrechungen betreiben wollen. Ein klassisches Routing-Failover kann je nach Topologie und Timern Sekunden dauern – für Datenverkehr oft tolerierbar, für Echtzeit jedoch nicht: Schon wenige hundert Millisekunden Paketverlust oder stark schwankende Laufzeiten reichen aus, damit Voice knackt, Silben fehlen oder der Jitter-Buffer leerläuft. Fast Reroute (FRR) zielt darauf ab, beim Ausfall eines Links oder Knotens den Verkehr innerhalb sehr kurzer Zeit auf einen vorberechneten Ersatzpfad umzuschalten. Damit ist FRR ein mächtiges Werkzeug gegen Sprachabbrüche. Gleichzeitig erzeugt ein Failover auch bei FRR typische Nebenwirkungen: Traffic verdichtet sich, Microbursts entstehen, Queueing Delay kann springen, und wenn QoS-Mappings im Backup-Pfad nicht identisch sind, landet Voice plötzlich in Best Effort. Deshalb muss FRR immer zusammen mit einem sauberen QoS-Design geplant werden: Voice in einer strikt limitierten Echtzeitklasse, Video gewichtet statt strikt priorisiert, Control-Traffic geschützt, Shaping an Engpässen sowie konsistente DSCP/CoS/MPLS-TC-Mappings über alle alternativen Pfade. Dieser Artikel erklärt verständlich, wie Fast Reroute funktioniert, warum Umschalten trotzdem zu Qualitätsproblemen führen kann und welche Designregeln sicherstellen, dass Voice auch während und nach einem FRR-Event stabil bleibt.

Warum Echtzeit so empfindlich auf Umschaltvorgänge reagiert

Bei Voice und interaktivem Video zählt nicht nur, ob Pakete ankommen, sondern ob sie in einem engen Zeitfenster ankommen. RTP/SRTP (typisch UDP) hat keine Retransmits. Was verloren oder zu spät ist, bleibt verloren. Beim Umschalten entstehen zwei Qualitätskiller:

• Paketverlust: kurze „Blackholing“-Phasen während der Routenumschaltung oder beim Link-Down-Event.
• Delay- und Jitter-Spitzen: Queueing an Engpässen, Microbursts und Scheduling-Effekte, wenn Traffic plötzlich anders verteilt wird.

Die meisten Nutzer nehmen bereits kurze Aussetzer als „Sprachabbruch“ wahr, insbesondere wenn sie am Satzanfang passieren. Ein FRR-Design muss daher nicht nur schnell sein, sondern auch die QoS-Semantik und das Burst-Verhalten im Ersatzpfad kontrollieren.

Was Fast Reroute ist und was nicht

Fast Reroute ist ein Mechanismus, der einen lokalen, vorberechneten Schutzpfad nutzt, um Verkehr beim Ausfall eines Links oder Knotens sofort umzuleiten, ohne auf die vollständige Netz-Konvergenz zu warten. Das unterscheidet FRR von klassischer IGP-Konvergenz.

• Klassische Konvergenz: Failure Detection (z. B. Link Down) → IGP/BGP berechnet neu → FIB wird aktualisiert → Verkehr läuft wieder. Dauer: häufig hunderte Millisekunden bis Sekunden, je nach Netz.
• FRR: Failure Detection → lokales Umschalten auf vorinstallierten Backup-Pfad → Verkehr läuft weiter, während die Steuerungsebene später „sauber“ nachzieht.

Wichtig: FRR ist kein Ersatz für Kapazitätsplanung und kein Garant für gleichbleibende QoE. Es reduziert primär die Unterbrechungszeit durch Umschaltlücken.

FRR-Varianten in IP/MPLS/SR-Netzen

Welche FRR-Variante Sie nutzen, beeinflusst, wie vorhersehbar die QoS-Wirkung im Backup-Pfad ist. Im Provider-Kontext sind typische Konzepte:

• IGP-FRR: lokale Repair-Mechanismen im IGP-Umfeld, oft mit Loop-Free Alternates (LFA) und deren Erweiterungen.
• MPLS-TE FRR: Schutz für TE-Tunnel, häufig als lokale Umleitung um den ausgefallenen Link/Node herum.
• Segment Routing (SR) FRR: Schutz auf Basis von SR-Pfaden und lokalen Alternativen, häufig sehr gut integrierbar mit Traffic Engineering.

Für QoS ist weniger wichtig, wie die Labels oder Segmente aussehen, sondern ob der Ersatzpfad Engpässe vermeidet, ob Mappings konsistent sind und ob der Scheduler im Backup-Pfad die gleichen Klassen garantiert.

Failure Detection: FRR ist nur so schnell wie die Fehlererkennung

Umschalten ohne Sprachabbrüche ist nicht nur eine Routingfrage, sondern auch eine Frage der Fehlererkennung. Wenn ein Linkausfall erst spät erkannt wird, hilft auch der beste Backup-Pfad nicht.

• Link Layer: physischer Link Down ist oft schnell, aber nicht jeder Fehler ist ein „harer Down“ (z. B. stiller Paketverlust).
• BFD: Bidirectional Forwarding Detection kann Ausfälle sehr schnell erkennen, muss aber sorgfältig dimensioniert werden, damit Control-Traffic nicht selbst zum Problem wird.
• Hold-/Debounce-Effekte: zu aggressive Timer können Flapping verstärken; zu konservative Timer verlängern Blackholing.

Für Voice bedeutet das: Ein paar hundert Millisekunden zusätzliche Detection-Zeit können bereits hörbar sein. Gleichzeitig darf die Control-Plane nicht unter QoS leiden, sonst wird die Detection in Lastsituationen unzuverlässig.

Warum Umschalten trotz FRR hörbar sein kann

Ein häufiges Missverständnis lautet: „Mit FRR gibt es keine Unterbrechung.“ In der Praxis gibt es mehrere Mechanismen, die trotzdem hörbare Effekte erzeugen:

• Microbursts: beim Umschalten werden Flows neu verteilt; Pakete treffen in kurzen Spitzen auf Queues.
• Pfad-Latenzsprung: Backup-Pfad ist länger; One-Way Delay steigt abrupt, Jitter-Buffer muss nachregeln.
• Kapazitätsverdichtung: ein Backup-Pfad trägt plötzlich mehr Verkehr; Best Effort und Video drängen in die gleichen Engpässe.
• QoS-Loch: eine Domäne im Backup-Pfad mappt DSCP/CoS/MPLS-TC anders; Voice landet falsch.
• Policer- und Shaper-Effekte: Profile sind auf Normalbetrieb dimensioniert; im Failover wird out-of-profile gedroppt.

Die Konsequenz ist klar: FRR muss gemeinsam mit QoS, Mapping und Kapazität getestet werden, nicht isoliert.

QoS-Grundregel im FRR-Kontext: Voice bekommt Low Latency, aber mit Limit

Wenn Sie Sprachabbrüche vermeiden wollen, braucht Voice eine echte Low-Latency-Behandlung. Gleichzeitig darf FRR nicht dazu führen, dass Premium-Queues „explodieren“ und andere Klassen verhungern.

• Voice Audio: in einer strict-priority Queue (LLQ) mit sauberem Bandbreitenlimit.
• Signaling/Control: hoch priorisiert, aber gewichtet (keine strict priority), damit Convergence und Session-Steuerung stabil bleiben.
• Video: gewichtete Klasse mit garantierten Anteilen, keine LLQ, um Premium-Inflation zu vermeiden.
• Best Effort: fair, kontrollierte Puffer, damit Bufferbloat nicht eskaliert.

Gerade im Failover ist das Limit in der LLQ entscheidend: Wenn Fehlmarkierungen oder unerwartete Last in EF landen, kann die LLQ sonst andere Klassen dauerhaft verdrängen.

Trust Boundary und Premium-Inflation: FRR macht Fehlmarkierung sichtbar

In vielen Netzen ist Fehlmarkierung im Normalbetrieb „noch okay“, weil genug Reserve vorhanden ist. Im Failover wird sie zum Incident. Deshalb ist eine klare Trust Boundary Pflicht:

• Nur kontrollierte Quellen dürfen EF setzen: z. B. SBC, Managed CPE, definierte UC-Gateways.
• Whitelist zulässiger DSCP-Werte: alles andere wird normalisiert oder in Best Effort gemappt.
• Conditional Trust: Markierungen werden akzeptiert, aber innerhalb profilierter Budgets pro Kunde/Service; Überschuss wird herabgestuft.

Wenn EF-Volumen im Failover stark steigt, ist das meist kein „Routingproblem“, sondern ein Governance-Problem, das FRR nur schneller sichtbar macht.

Shaping am Engpass: Der stille Schlüssel zu „umschalten ohne Knacken“

Viele hörbare Effekte beim Umschalten entstehen nicht durch fehlende Routen, sondern durch Queueing an rate-limitierten Links (Access, Backhaul, NNI). Shaping hilft, Bursts zu glätten und Drop-Cluster zu vermeiden.

• Egress-Shaping knapp unter Linkrate: verhindert, dass unkontrollierte Puffer (CPE/Modem/Providerpolicer) die Latenz aufblähen.
• Voice priorisiert im Shaper: LLQ sorgt dafür, dass Audio trotz Shaping minimal wartet.
• Video gewichtet: bekommt stabile Throughput-Fenster, ohne Voice zu gefährden.

Im FRR-Fall ist Shaping besonders wichtig, weil Umschalt-Microbursts ansonsten Tail Drops erzeugen können, die sofort hörbar sind.

Policing im Failover: Warum harte Drops Sprachabbrüche provozieren

Policer sind als Governance-Tool sinnvoll, aber sie sind im Echtzeitpfad riskant, weil sie Pakete hart verwerfen. Beim Umschalten verändern sich Burst-Profile, und Policers treffen plötzlich häufiger.

• Voice: Policer-Drops sind praktisch immer hörbar. Ein Voice-Profil muss so dimensioniert sein, dass es in normalen und Failover-Szenarien nicht dropt.
• Video: harte Policer erzeugen Drop-Cluster und Freezes; besser sind Shaping oder kontrolliertes Remarking für Überschuss.
• Best Effort: kann stärker policed werden, aber auch hier sind Burst-Toleranz und faire Behandlung wichtig.

Wenn nach FRR plötzlich EF-Drops auftreten, prüfen Sie zuerst LLQ-Limit und Policer-Hits, bevor Sie Routingparameter ändern.

Pfadgleichwertigkeit: Backup-Pfade müssen QoS-semantisch identisch sein

Eine der häufigsten Ursachen für „FRR schaltet schnell um, aber Qualität ist schlecht“ ist ein QoS-Loch im Ersatzpfad. Typische Bruchstellen:

• DSCP↔CoS Mapping: Metro/Access mappt PCP anders, Voice landet in falscher Queue.
• DSCP↔MPLS-TC: im Core wird TC anders interpretiert oder falsch zurückgemappt.
• Tunnel Outer-Header: inneres DSCP stimmt, Outer-DSCP fehlt; Underlay queued Best Effort.
• IPv6 Parität: IPv4 QoS ist sauber, IPv6 Traffic Class wird im Backup-Pfad nicht gemappt.

Best Practice: Definieren Sie eine eindeutige Mapping-Kette (DSCP → CoS → MPLS-TC) und verifizieren Sie sie aktiv pro Pfad, nicht nur pro Gerät.

Fast Reroute und Reihenfolge: Warum Reordering Voice und Video beeinflussen kann

Beim Umschalten können Pakete kurzfristig unterschiedliche Wege nehmen oder unterschiedlich schnell ankommen. Das führt zu Reordering. Für UDP-Echtzeit ist das weniger ein „Protokollproblem“ als ein Jitterproblem: Pakete kommen aus der erwarteten Reihenfolge und erzeugen Schwankungen, die der Jitter-Buffer kompensieren muss.

• Voice: Reordering kann als Jitter sichtbar werden; in extremen Fällen entsteht Late Loss, wenn Pakete zu spät eintreffen.
• Video: Reordering kann zu sichtbaren Artefakten führen, besonders bei burstigen Frames und niedrigen Puffern.

Ein FRR-Design sollte daher nicht nur „schnell“, sondern auch „stabil“ sein: Backup-Pfade sollten möglichst keine wilden Umwege erzwingen, die Latenzsprünge und Reordering verstärken.

Control-Plane schützen: Ohne stabile Steuerung keine stabile Umschaltung

FRR wirkt lokal, aber die anschließende Netzwerk-Konvergenz (IGP/BGP/TE) muss sauber ablaufen, sonst bleibt das Netz in einem „provisorischen“ Zustand oder flappt. Control-Plane-Traffic ist deshalb QoS-relevant:

• Control-Klasse: Routing- und Signaling-relevante Control-Flows dürfen nicht im Best Effort untergehen.
• CPU-Schutz: unter Congestion können Geräte in CPU-Jitter geraten; Control-Pakete werden verspätet, Convergence verlängert sich.
• Timer-Design: aggressive Detection ohne Control-Schutz kann Flapping verstärken.

Operativ bedeutet das: QoS für Ausfälle ist nicht nur Datenplane-QoS, sondern auch Control-Plane-Resilienz.

Testen und Verifizieren: FRR ist erst real, wenn es gemessen ist

Ein robustes Design braucht reproduzierbare Tests. Ziel ist nicht, „keine Veränderung“ zu sehen, sondern eine kontrollierte, vorhersehbare Degradation ohne Sprachabbrüche.

• Active Probes pro Klasse: EF/Voice, AF/Video, BE vor, während und nach Umschaltung messen (Loss/Jitter/Delay).
• Telemetrie-Korrelation: Queueing Delay/Depth, Drops pro Klasse, Policer/Shaper-Events im Umschaltzeitfenster.
• Markierungsintegrität: DSCP/CoS/TC-Verteilung an Übergängen prüfen, insbesondere im Backup-Pfad.
• Short Windows und Perzentile: Sekundenfenster und 95/99-Perzentile zeigen Umschaltspitzen besser als Mittelwerte.

Ein sehr praktischer Indikator ist: EF darf während FRR keine Drops zeigen. Wenn EF dropt, ist das ein Design- oder Governance-Problem.

Designmuster: So bauen Sie FRR-fähige QoS-Profile für Voice & Video

• Voice strikt, klein, limitiert: LLQ für Audio mit Limit, kleine Queue-Limits, Trust Boundary gegen Fehlmarkierung.
• Signaling robust, aber nicht LLQ: gewichtete Control-Klasse, um Setup und Convergence stabil zu halten.
• Video gewichtet: garantierte Anteile, moderates Queue-Limit, Shaping gegen Bursts.
• Best Effort fair: kontrollierte Puffer, Bufferbloat vermeiden, damit Delay nicht eskaliert.
• Shaping an Engpässen: besonders am Upstream und an rate-limitierten NNI/Backhaul-Links.
• Mappings end-to-end: DSCP↔CoS↔MPLS-TC konsistent, inklusive IPv6 und Tunnel Outer-Header.

Typische Fehlersignaturen bei FRR-Events

• Voice knackt nur beim Umschalten: kurzer Loss-Cluster oder Jitterspitze; oft Microburst ohne Shaping oder zu kleine Queue-Limits.
• Voice wird nach Umschaltung dauerhaft schlechter: Backup-Pfad hat QoS-Loch oder zu wenig Kapazität; LLQ-Limit oder Mapping prüfen.
• EF-Volumen steigt im Failover stark: Premium-Inflation/Fehlmarkierung wird durch Kapazitätsverdichtung sichtbar; Trust Boundary schärfen.
• Video friert häufiger ein: AF-Queue dropt clusterig oder Policer schneidet Bursts ab; Shaping/Remarking/Queue-Limits prüfen.
• Einweg-Audio nach Umschalten: MTU/PMTUD oder Tunnelwechsel; Fragmentierung und Outer-Header prüfen.

Praxis-Blueprint: Umschalten ohne Sprachabbrüche in 9 Schritten

• Schritt 1: Kritische Dienste definieren (Voice Audio, Signaling, interaktives Video) und deren QoS-Ziele festlegen.
• Schritt 2: Failure Detection designen (Link Events, BFD), Control-Plane per QoS schützen.
• Schritt 3: FRR-Mechanismus wählen (LFA/Remote-LFA, TE/SR-TE Schutz) und Pfadqualität bewerten.
• Schritt 4: N+1 Kapazität prüfen: Backup-Pfad muss Peak-Last oder definierte SLA-Last tragen.
• Schritt 5: QoS-Profile definieren (LLQ für Voice mit Limit, Video gewichtet, Control geschützt, BE fair).
• Schritt 6: Shaping an Engpässen pfadabhängig dimensionieren, Policer-Drops für Echtzeit vermeiden.
• Schritt 7: End-to-End Mapping verifizieren (DSCP↔CoS↔MPLS-TC, Inner↔Outer, IPv6-Parität).
• Schritt 8: FRR-Test mit Probes pro Klasse durchführen, Sekundenfenster und Perzentile auswerten.
• Schritt 9: Monitoring und Alarme definieren (EF-Drops = Incident, EF-Delay-Perzentile, Remarking-Drift, Policer-Hits).

Häufige Fragen zu Fast Reroute und QoS

Reicht FRR allein aus, um Sprachabbrüche zu verhindern?

Nein. FRR reduziert Umschaltlücken, aber es verhindert nicht automatisch Microbursts, Kapazitätsengpässe oder QoS-Mapping-Löcher im Backup-Pfad. Ohne konsistentes QoS, Shaping und Trust Boundary kann Voice trotz schneller Umschaltung knacken.

Was ist der wichtigste QoS-Hebel während FRR?

Eine strikt limitierte LLQ für Voice kombiniert mit Shaping an Engpässen. Damit vermeiden Sie Drop-Cluster und Delay-Spitzen, die beim Umschalten am häufigsten hörbar werden. Gleichzeitig verhindert das Limit Premium-Inflation.

Wie erkenne ich, ob der Backup-Pfad QoS-semantisch korrekt ist?

Indem Sie pro Klasse messen: EF-markierte UDP-Probes (voice-ähnlich) sowie Telemetrie (Classify-Hits, DSCP/CoS/TC-Verteilungen, Queueing Delay und Drops pro Klasse) im Backup-Pfad. Wenn EF die erwartete Behandlung erhält und keine EF-Drops auftreten, ist die QoS-Semantik im Failover belastbar verifiziert.