IS-IS Overload Bit & Fast Reroute: Wann und wie sauber einsetzen

Im IS-IS Enterprise-Betrieb sind Overload Bit und Fast Reroute (FRR) zwei Werkzeuge mit sehr unterschiedlichem Ziel: Overload Bit steuert Pfadwahl, um Router temporär aus dem Transit zu nehmen (ohne Adjacencies zu verlieren), während FRR die Konvergenz im Fehlerfall massiv beschleunigt, indem lokale Backup-Pfade vorab berechnet werden. Richtig eingesetzt erhöhen beide die Betriebssicherheit. Falsch eingesetzt erzeugen sie Blackholes, unerwartete Traffic-Shifts oder „Flap-Stürme“. Dieser Artikel zeigt, wann du Overload und FRR sinnvoll nutzt und wie du sie sauber implementierst.

IS-IS Overload Bit: Was es ist und was es bewirkt

Das Overload Bit signalisiert im IS-IS-LSP: „Bitte nutze mich nicht als Transit.“ Der Router bleibt erreichbar (seine eigenen Präfixe sind weiterhin bekannt), aber andere Router bevorzugen Wege, die nicht über ihn führen. Das ist ideal, wenn ein Router zwar noch läuft, aber nicht „Last tragen“ soll – etwa nach einem Reload, bei Wartung oder bei Resource-Problemen.

• Overload Bit gesetzt: Router nicht als Transit nutzen
• Adjacencies bleiben bestehen (wichtig für Stabilität)
• Typische Nutzung: Graceful re-introduction nach Boot

Merker

$\text{Overload} \ne \text{Router down}, \text{Overload}=\text{kein Transit}$

Wann Overload Bit sinnvoll ist

Overload Bit ist ein Betriebswerkzeug. Es verhindert, dass Traffic über einen Router läuft, der (noch) nicht „bereit“ ist. Das reduziert Risiken nach Änderungen und schützt vor instabiler Weiterleitung bei Resource-Druck.

• Nach Boot/Upgrade: Router ist up, aber Routing/Services müssen „warm werden“
• Bei CPU/Memory-Problemen: Router soll erreichbar bleiben, aber keine Transitlast tragen
• Bei Wartung: Traffic vorab weglenken, ohne Neighborship zu reißen

Overload Bit konfigurieren: dauerhaft vs. zeitlich begrenzt

In Enterprise-Netzen ist eine zeitlich begrenzte Variante oft die beste Praxis: Overload nach Reload automatisch für X Sekunden setzen, bis alle Interfaces/Services stabil sind. Das vermeidet „vergessene“ Overload-Konfigurationen.

Overload Bit setzen (Prinzip)

router isis CORE
 set-overload-bit

Overload nach Reload für ein Zeitfenster (typisches Pattern)

router isis CORE
 set-overload-bit on-startup wait-for-bgp 300

Interpretationshinweis

• „on-startup“ verhindert Transit direkt nach Boot
• Das Zeitfenster muss zu deiner Umgebung passen (Interfaces, BGP, VPN, etc.)

Overload Pitfalls: Wie du Blackholes vermeidest

Overload kann Traffic weglenken – aber nur, wenn es alternative Pfade gibt. In Single-Path-Topologien kann Overload dazu führen, dass entfernte Netze nicht mehr erreichbar sind oder suboptimal geroutet werden. Deshalb musst du Overload immer im Kontext der Topologie denken.

• Keine Redundanz: Overload kann Erreichbarkeit verschlechtern
• Vergessene Overload-Flags: Router bleibt dauerhaft „non-transit“
• Abhängige Services: wenn ein Router einziger Exit ist, ist Overload gefährlich

Verifikation: Overload Status prüfen

show isis database detail
show isis protocol

IS-IS Fast Reroute (FRR): Ziel und Grundprinzip

FRR reduziert die Konvergenzzeit bei Link-/Node-Failures, indem der Router lokale Backup-Pfade vorab berechnet. Im Fehlerfall wird Traffic sofort umgeleitet, bevor das Netzwerk global konvergiert. Das ist besonders für Voice/Video und kritische Standortkopplungen wichtig.

• FRR ist lokal: der erste Hop reagiert sofort
• Globales SPF folgt später (normale Konvergenz)
• Ziel: Sub-Second Failover, weniger Paketverlust

FRR-Varianten: Link Protection vs. Node Protection

Link Protection schützt gegen Ausfall eines Links. Node Protection schützt zusätzlich gegen Ausfall des Nachbarrouters (Next-Hop). Node Protection ist stärker, kann aber mehr Constraints haben (Topology/Backup Next-Hop muss existieren).

• Link Protection: Backup für Link-Failure
• Node Protection: Backup, der den Nachbar umgeht
• Praxis: Node Protection wo möglich, sonst Link Protection

FRR konfigurieren: Sauber und standardisiert

FRR wird in der Regel unter IS-IS und/oder pro Interface aktiviert. Wichtig ist, die Aktivierung konsistent über die relevanten Links zu verteilen und anschließend die FRR-States zu verifizieren.

FRR aktivieren (Prinzip)

router isis CORE
 fast-reroute per-prefix level-2

Interface-Pattern (wenn platformabhängig erforderlich)

interface gigabitEthernet0/0
 ip router isis CORE
 isis network point-to-point

FRR messen: Du brauchst Beweise (nicht nur „konfiguriert“)

FRR ist erst wertvoll, wenn du belegst, dass Backup-Pfade tatsächlich berechnet wurden. Prüfe daher die FRR-Outputs und simuliere Failover kontrolliert in einem Wartungsfenster.

FRR Status prüfen

show isis fast-reroute
show isis route
show isis database

Failover kontrolliert testen

show clock
! Interface kurz down/up im Wartungsfenster
show isis neighbors
show isis fast-reroute

Wann FRR in Enterprise-Netzen wirklich Sinn ergibt

FRR lohnt sich dort, wo ein Failover spürbaren User-Impact reduziert: Voice/Video, Echtzeitsteuerung, zentrale Auth-Services, oder WAN-Edges mit kritischem Transit. In kleinen Netzen mit wenigen Links bringt FRR weniger, weil ohnehin schnell konvergiert wird.

• Core/Distribution: hohe Traffic-Last, viele Services → FRR sehr sinnvoll
• WAN-Core: Echtzeit und SLA → FRR häufig Pflicht
• Edge/Branch: selektiv, wenn Topologie es hergibt

FRR Pitfalls: Häufige Fehler im Betrieb

FRR ist kein „Free Lunch“. Wenn Topologie oder Kostenmodell nicht sauber ist, kann FRR suboptimalen Traffic ziehen oder bei bestimmten Prefixes gar nicht aktiv werden. Außerdem kann FRR bei instabilen Links Flap-Effekte verstärken, wenn die Ursache nicht behoben wird.

• Keine echten Backup-Pfade: FRR kann nicht greifen
• Kostenmodell falsch: Backup-Pfad führt über unerwünschte Links
• Asymmetrie: Failover erzeugt State-/Firewall-Probleme
• Instabile Links: FRR maskiert Root Cause, bis es eskaliert

Gemeinsam denken: Overload Bit und FRR im Betriebsprozess

Overload und FRR ergänzen sich: Overload steuert geplante Zustände (Maintenance, Boot), FRR schützt ungeplante Ausfälle. In Enterprise-Prozessen ist das ein starkes Muster: Router nach Boot erst „non-transit“, danach normal; bei Link-Failure sofort FRR, danach reguläre Konvergenz.

• Maintenance: Overload setzen → Traffic weglenken → Arbeiten → Overload entfernen
• Stabilität: FRR für ungeplante Link-/Node-Failures
• Verifikation: stets über Show-Befehle und Testfälle beweisen

Quick-Runbook: Overload/FRR in 5 Minuten prüfen

Diese Kommandos liefern dir schnell den Status: ist Overload gesetzt, sind FRR-Backups vorhanden, sind Neighbors stabil?

show isis neighbors
show isis protocol
show isis database detail
show isis fast-reroute
show isis route

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.