Microloops vermeiden: Konvergenz-Optimierung bei IGP Changes

Microloops sind kurzzeitige Routing-Loops während der Konvergenz: Für Millisekunden bis wenige Sekunden zeigen Router unterschiedliche Next-Hops, weil sie Updates nicht gleichzeitig verarbeiten. Das Ergebnis sind Paketverluste, Latenzspikes und „mysteriöse“ Applikationsprobleme – obwohl das Netz nach der Konvergenz korrekt ist. Besonders häufig treten Microloops bei IGP-Änderungen auf (Link down, Kostenänderung, Redistribution, Maintenance), und sie werden durch schnelle Failure Detection (z. B. BFD) sogar sichtbarer. Ziel dieses Tutorials ist ein praxistaugliches Modell, um Microloops zu vermeiden oder zumindest so zu reduzieren, dass sie keinen Nutzer-Impact mehr erzeugen.

Warum Microloops entstehen: asynchrone Konvergenz

IGPs (OSPF/IS-IS) verteilen Topologie-Informationen per Flooding und berechnen Pfade per SPF. Router konvergieren aber nicht gleichzeitig: Unterschiedliche CPU-Last, Timer, LSDB-Größe und Pfadlängen führen zu unterschiedlichen Umschaltzeitpunkten.

  • Flooding braucht Zeit (LSA/LSP Propagation)
  • SPF braucht Zeit (CPU, Throttling)
  • FIB-Programmierung braucht Zeit (Hardware/Software)

Merker

Microloop  →  Router A schaltet schneller als Router B

Typische Trigger: Welche Changes Microloops begünstigen

Microloops entstehen vor allem bei Änderungen, die den „besten Pfad“ umschalten. Je größer das Netz und je stärker die SPF-Last, desto wahrscheinlicher ist ein kurzzeitiger Loop.

  • Link/Node Failure: Next-Hop wechselt abrupt
  • Metric Change: Kostenanpassung im IGP
  • Maintenance: Traffic-Shifts durch Overload/Cost-Changes
  • Redistribution Events: viele Prefixes ändern gleichzeitig

Erkennen: Wie Microloops in der Praxis aussehen

Weil Microloops kurz sind, findest du sie selten in klassischen Logs. Typisch sind Packet Loss/Latency Spikes während eines Changes, „unregelmäßige“ Traceroutes oder erhöhte Drops in Hardware-Queues.

  • Ping-Loss während eines Link-Events, danach wieder normal
  • Traceroute springt kurz zwischen Hops (oder zeigt Loops)
  • QFP/Interface Drops steigen in kurzen Fenstern

Messkommandos (Indizien)

ping <dst> repeat 200
traceroute <dst>
show platform hardware qfp active statistics drop
show interfaces | include drops|error|rate

Grundstrategie: Konvergenz planbar machen

Microloops reduzierst du nicht durch „noch schnellere Timer“, sondern durch planbare Umschaltlogik. Das bedeutet: (1) lokale Fast-Reroute statt globaler Umstellung, (2) geordnete Umschaltung bei geplanten Changes, (3) Dämpfung von SPF/FIB, ohne echte Ausfälle zu verschleppen.

  • Ungeplante Ausfälle: FRR (lokal) statt „SPF wartet“
  • Geplante Changes: geordnete Traffic-Drain-Mechanismen
  • Stabilität: SPF/LSA Throttling gegen Flap-Stürme

Technik 1: Fast Reroute (FRR) als Microloop-Bremse

FRR (Loop-Free Alternates, Remote LFA, TI-LFA je nach Plattform) schaltet lokal um, bevor alle Router global konvergieren. Das reduziert Paketverlust und senkt die Wahrscheinlichkeit von Microloops drastisch, weil der erste Hop bereits einen precomputeten Backup-Pfad nutzt.

  • LFA: lokaler Backup-Next-Hop, loop-free per Definition
  • Remote LFA: erweitert LFA, wenn kein lokaler Backup existiert
  • TI-LFA: segment-routing-basiert, sehr schnell und robust (wenn eingesetzt)

IS-IS FRR Beispiel (Prinzip)

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

Verifikation

show isis fast-reroute
show isis route

Technik 2: BFD richtig dimensionieren (nicht „zu schnell“)

BFD beschleunigt Failure Detection. Das ist gut – aber wenn die Umschaltung global nicht sauber abgefedert ist, werden Microloops sichtbarer. Dimensioniere BFD daher passend zur Topologie und aktiviere FRR, bevor du extrem aggressive BFD-Timer ausrollst.

  • Start konservativ: z. B. 300 ms / 3
  • Core selektiv schneller: 100 ms / 3 oder 50 ms / 3, wenn stabil
  • Always: FRR + saubere IGP-Optimierung als Begleitung

BFD Beispiel

interface gigabitEthernet0/0
 bfd interval 300 min_rx 300 multiplier 3

Technik 3: Ordered FIB / geordnete FIB-Programmierung

Eine zentrale Microloop-Ursache ist die Reihenfolge, in der Router ihre Forwarding-Tabelle (FIB) aktualisieren. „Ordered FIB“ ist ein Konzept, bei dem Router Updates in einer Reihenfolge installieren, die Microloops verhindert (typisch vom Rand zum Core oder umgekehrt, abhängig vom Modell). In der Praxis ist die Verfügbarkeit plattform-/featureabhängig, aber das Prinzip bleibt: FIB-Updates müssen koordiniert werden.

  • Ziel: keine temporären Next-Hop-Widersprüche zwischen Routern
  • Nutzen: weniger Loss bei IGP-Änderungen
  • Wichtig: abhängig von Plattform/IOS XE Feature-Set

Technik 4: Geplante Changes „drainen“ statt „abschießen“

Bei geplanten Arbeiten ist Microloop-Vermeidung am einfachsten: du lenkst Traffic vorab weg, bevor du Links/Nodes änderst. Das geht mit Kostenanhebung, Overload (IS-IS) oder anderen Traffic-Engineering-Mechanismen.

  • IS-IS: Overload Bit setzen (Router bleibt erreichbar, aber kein Transit)
  • IGP: Link Costs erhöhen (Traffic verschiebt sich kontrolliert)
  • Dann erst: Interface shutdown / Wartung / Upgrade

IS-IS Overload (Beispiel)

router isis CORE
 set-overload-bit

OSPF Cost anheben (Beispiel)

interface gigabitEthernet0/0
 ip ospf cost 10000

Technik 5: IGP Throttling: Stabilität statt „SPF-Sturm“

Microloops sind wahrscheinlicher, wenn SPF ständig neu läuft. Throttling reduziert die Anzahl schneller, aufeinanderfolgender SPF-Runs, indem Änderungen gesammelt werden. Das verbessert Stabilität, darf aber echte Ausfälle nicht zu stark verzögern.

OSPF SPF Throttle (Startpunkt)

router ospf 10
 timers throttle spf 50 200 5000

Design-Hebel: Topologie so bauen, dass LFAs existieren

FRR funktioniert am besten, wenn deine Topologie echte alternativen Pfade bietet. In „skinny“ Designs (ein einziger Nachbar, ein einziger Exit) gibt es keine loop-free alternates. Daher ist Microloop-Vermeidung auch eine Frage von Redundanz und Kostenmodell.

  • Mindestens zwei unabhängige Pfade im Core/Distribution
  • Kostenmodell konsistent (sonst Backup-Pfade unerwünscht)
  • Summarization/Area-Design stabil halten (weniger globale Shifts)

Troubleshooting: Microloop-Indizien sauber belegen

Wenn du Microloops vermutest, brauchst du kurze Messfenster: Ping/Traceroute parallel zu einem kontrollierten Event, plus Drops/Queueing-Metriken. So kannst du später im Post-Mortem klar zeigen: „Loss trat nur während Konvergenz auf“.

Evidence Pack (kurz)

show clock
ping <dst> repeat 500
traceroute <dst>
show ip route <dst>
show ip cef <dst> detail
show platform hardware qfp active statistics drop
show interfaces | include drops|error|rate

Quick-Runbook: Microloops bei IGP Changes minimieren

Diese Checkliste ist als operatives Vorgehensmodell gedacht – für geplante Changes und für Designverbesserungen.

  • FRR/LFA aktivieren und verifizieren (bevor BFD aggressiv wird)
  • BFD konservativ starten, dann selektiv optimieren
  • SPF/LSA Throttling gegen Flap-Stürme
  • Planned Maintenance: Traffic drain (Overload/Cost) vor Shutdown
  • Nachweis: Ping/Traceroute + Drops in Messfenstern

Command Pack

show processes cpu sorted
show ip ospf neighbor
show isis neighbors
show isis fast-reroute
show ip cef <dst> detail
show platform hardware qfp active statistics drop
show interfaces | include drops|error|rate

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.

Related Articles