Routing-Loop vermeiden: Typische Fehler in Cisco Konfigurationen

Ein Routing-Loop gehört zu den ärgerlichsten und zugleich gefährlichsten Fehlerbildern in IP-Netzwerken: Pakete kreisen zwischen Routern, die Latenz steigt, Bandbreite wird unnötig belegt, und im schlimmsten Fall sind ganze Teilnetze praktisch nicht mehr nutzbar. Wer in Cisco-Umgebungen Routing-Loops vermeiden möchte, braucht deshalb weniger „Spezialtricks“, sondern vor allem saubere Grundlagen: konsistente Routingdomänen, klare Default-Route-Strategien, kontrollierte Redistribution, eindeutige Pfadpräferenzen (Administrative Distance, Metriken) sowie durchdachte Filter- und Summarization-Konzepte. In der Praxis entstehen Routing-Loops selten durch das Routingprotokoll selbst, sondern fast immer durch typische Konfigurationsfehler: gegenseitige Default Routes ohne Rückweglogik, fehlerhafte Route Redistribution (OSPF ↔ EIGRP ↔ BGP), unkontrolliertes Announcen von Summaries, PBR-Regeln ohne Rückwegplanung oder NAT-/Firewall-Topologien, die den Return Path unbewusst umleiten. Dieser Artikel zeigt Ihnen die häufigsten Ursachen für Routing-Loops in Cisco-Konfigurationen, erklärt, wie Sie die Symptome sicher erkennen, und liefert praxistaugliche Gegenmaßnahmen, die sowohl Einsteiger verstehen als auch in produktiven Enterprise-Netzen funktionieren. Ziel ist, dass Sie Loops nicht nur „irgendwie“ beheben, sondern systematisch verhindern – durch Design, Standards und kontrolliertes Troubleshooting.

Routing-Loop vs. Layer-2-Loop: Wichtige Abgrenzung

Bevor Sie in die Diagnose einsteigen, sollten Sie klar unterscheiden: Ein Routing-Loop ist ein Layer-3-Problem, ein Switch-Loop ist ein Layer-2-Problem. Beide sehen für Nutzer ähnlich aus („Netz ist langsam oder tot“), die Ursachen und Fixes sind jedoch unterschiedlich.

• Layer-2-Loop: Ethernet-Schleife ohne TTL, häufig Broadcast-Sturm; Schutz primär durch STP, BPDU Guard, Storm Control.
• Routing-Loop: IP-Pakete kreisen zwischen Routern, TTL wird schrittweise reduziert; sichtbar in Traceroutes mit wiederkehrenden Hops.

Wenn Traceroute wiederholt die gleichen Router zeigt und irgendwann mit „TTL expired“ endet, deutet das stark auf einen Routing-Loop hin. Die TTL-Logik ist im IP-Standard beschrieben; als Hintergrund eignet sich der Anchor-Text RFC 791 (Internet Protocol).

Typische Symptome: So erkennen Sie einen Routing-Loop im Betrieb

Routing-Loops haben charakteristische Signaturen. Je früher Sie sie erkennen, desto schneller können Sie Schaden begrenzen.

• Traceroute zeigt Kreislauf: Router A → Router B → Router A → Router B …
• Hohe Latenz und Paketverlust: weil Traffic unnötig über mehrere Hops läuft, bis TTL endet.
• CPU- und Interface-Last: betroffene Router zeigen erhöhte Auslastung, besonders auf Transitlinks.
• Asymmetrische Pfade: Hinweg geht über einen Pfad, Rückweg über einen anderen, oft kombiniert mit PBR/NAT.
• Intermittierende Störungen: Loops können „flappen“, wenn Routingtabellen sich ändern oder Links instabil sind.

In Cisco-Umgebungen sind diese Befehle für die erste Einordnung besonders hilfreich:

• traceroute <ZIEL>
• show ip route <PREFIX>
• show ip cef <ZIEL> (Forwarding-Entscheidung, plattformabhängig)
• show interfaces (Fehlerzähler und Traffic-Raten)
• show logging (Routing-Events, Flaps, Redistribution-Änderungen)

Ursache 1: Gegenseitige Default Routes ohne klare Rückweglogik

Ein Klassiker: Router A hat eine Default Route zu Router B, Router B hat ebenfalls eine Default Route zu Router A. Solange alle Zielnetze spezifisch bekannt sind, fällt das nicht sofort auf. Sobald aber ein Paket ein Ziel trifft, das keiner der beiden spezifisch kennt, schicken beide es gegenseitig weiter – Loop.

Typisches Fehlerbild

• In beiden Routingtabellen existiert eine Default Route, die auf den jeweils anderen Router zeigt.
• Für das betroffene Ziel existiert keine spezifische Route.
• Traceroute pendelt zwischen zwei Hops.

Saubere Gegenmaßnahmen

• Default Route nur in Richtung „Upstream“: Default zeigt zum Core/Internet, nicht „im Kreis“.
• Rückrouten sicherstellen: Upstream muss interne Netze kennen (statisch, dynamisch oder per Summary).
• Blackhole vermeiden: bei Unsicherheit lieber spezifische Routen setzen oder Routingdomäne sauber erweitern.

Wenn Sie Default Routes verteilen (z. B. via OSPF default-information originate), dokumentieren Sie unbedingt, wer Default „autorisiert“ und warum.

Ursache 2: Falsche oder unvollständige Summarization

Summarization ist grundsätzlich sinnvoll: weniger Präfixe, kleinere Routingtabellen, stabilere Konvergenz. Ein Routing-Loop entsteht jedoch, wenn Summaries Netze abdecken, die nicht wirklich existieren, oder wenn Summaries in mehrere Richtungen beworben werden, ohne dass der tatsächliche Pfad konsistent ist.

Typische Fehler

• Summary zu groß: Das Summary umfasst Präfixbereiche, die an keinem Ort geroutet werden.
• Mehrere Summarizer: Zwei Router announcen das gleiche Summary, aber nur einer hat die spezifischen Routen.
• Fehlende Discard-Route: Traffic zu „nicht existierenden“ Teilen des Summary wird weitergeleitet statt verworfen.

Best Practices

• Summaries nur auf aggregierbare IP-Pläne: Standort-/Zonenblöcke sauber planen (z. B. pro Standort ein /16).
• Nullroute/Discard für Summaries: Auf dem Summarizer eine Null0-Route für das Summary setzen, um Blackholing zu kontrollieren.
• Eindeutige Zuständigkeit: Wer announced welches Summary? Nur dort announcen, wo die spezifischen Netze wirklich liegen.

Ursache 3: Route Redistribution ohne Tagging und Filter

Die häufigste Quelle für Routing-Loops in gemischten Netzen ist unkontrollierte Redistribution. Wenn OSPF und EIGRP (oder BGP) gegenseitig Routen importieren und exportieren, können Routen „zurückkehren“ und plötzlich eine andere Präferenz gewinnen. Das führt zu Pfadwechseln, Kreisverkehr und schwerer Diagnose.

Typische Fehler

• Bidirektional redistributen ohne Tagging: Importierte Routen werden wieder exportiert.
• „Redistribute all“ ohne Prefix-Filter: unnötige Präfixe fluten in die andere Domäne.
• Fehlende Seed-Metrik: EIGRP übernimmt extern nicht sauber, OSPF-Typen werden unbewusst gewählt.

Best Practices

• Nur benötigte Präfixe redistributen (Prefix-Lists/Route-Maps).
• Tagging einsetzen: importierte Routen markieren und Rückexport blockieren.
• OSPF E1/E2 bewusst wählen: bei mehreren Borders ist E1 oft stabiler, weil interne Kosten zur ASBR einfließen.

Für standardnahe Hintergründe sind diese Quellen hilfreich: RFC 2328 (OSPFv2) und RFC 7868 (EIGRP). Cisco-Konfigurationsdetails finden Sie über den Anchor-Text Cisco OSPF Dokumentation sowie Cisco EIGRP Dokumentation.

Ursache 4: Administrative Distance und Metriken widersprechen dem Design

Auch ohne Redistribution kann ein Loop entstehen, wenn Router unterschiedliche Pfade „bevorzugen“ – etwa weil Administrative Distance (AD) oder Metriken unbewusst manipuliert wurden. Besonders gefährlich ist das, wenn externe Routen plötzlich internen Routen vorgezogen werden oder wenn mehrere Protokolle gleichzeitig Routen zum gleichen Ziel anbieten.

Typische Fehler

• AD-Anpassungen ohne Standard: Ein Router bevorzugt OSPF extern, ein anderer EIGRP extern.
• Metrik-Drift: Bandwidth/Delay auf Interfaces sind nicht konsistent konfiguriert.
• Floating Statics falsch gesetzt: Backup-Route gewinnt unerwartet, obwohl der Primärpfad erreichbar wäre.

Best Practices

• AD nur strategisch ändern: sparsam, dokumentiert, konsistent im Domain.
• Interface-Bandwidth korrekt setzen: wenn EIGRP/OSPF Kosten davon abhängen.
• Pfadwahl testen: nicht nur im Normalbetrieb, sondern auch bei Link-Ausfällen.

Prüfen Sie im Zweifel gezielt pro Präfix: show ip route <PREFIX> und vergleichen Sie die Entscheidung auf mehreren Routern.

Ursache 5: Policy-Based Routing ohne Rückwegplanung

PBR ist ein häufiger Auslöser von „scheinbaren Routing-Loops“ oder asymmetrischen Pfaden, die sich wie Loop anfühlen: Der Hinweg wird umgeleitet, der Rückweg folgt der Routingtabelle und geht an einer stateful Firewall vorbei. Das Ergebnis sind Retransmits, Timeouts und Traceroutes, die unplausible Pfade zeigen.

Typische Fehler

• PBR auf zu breitem Traffic: „match ip any any“ oder zu generische Regeln.
• Next Hop nicht erreichbar: PBR setzt einen Next Hop, der in Teilstörungen nicht verfügbar ist.
• NAT/Firewall-State: Sessions brechen, weil Rückweg über eine andere Security-Kette geht.

Best Practices

• PBR restriktiv matchen: nur die nötigen Quellen/Ziele/Ports.
• Fallback planen: Next Hop nur setzen, wenn erreichbar (Tracking/Verify-Availability je nach Plattform).
• Return Path mitdenken: besonders bei Internetzugang und stateful Firewalls.

Für Cisco-spezifische PBR-Details eignet sich der Anchor-Text Cisco IOS XE PBR Konfigurationsguide.

Ursache 6: Mehrere Borders ohne klare Rollenverteilung

In Enterprise-Designs gibt es häufig mehr als einen „Border“-Punkt: mehrere Standorte, mehrere Provider, mehrere Redistributoren. Ohne klares Rollenmodell entsteht leicht ein Loop oder zumindest unvorhersehbare Pfadwahl: Router A lernt externe Routen über Border 1, Router B über Border 2, und beide senden Traffic gegeneinander, weil die jeweils „beste“ Route lokal anders bewertet wird.

Best Practices

• Border-Rollen definieren: Primary/Secondary, klare Default-Origination, konsistente Policies.
• Summaries und Tags konsequent: verhindert Rückkopplungen bei mehreren Borders.
• OSPF-Design beachten: bei mehreren ASBRs E1 bevorzugen, damit die Nähe zählt.
• BGP-Policies sauber filtern: Prefix-Listen in/out sind Mindeststandard.

Für BGP-Standardhintergrund eignet sich der Anchor-Text RFC 4271 (BGP-4). Cisco-BGP-Praxis finden Sie über den Anchor-Text Cisco BGP Dokumentation.

Diagnose-Workflow: Routing-Loop schnell eingrenzen

Wenn Sie einen Loop vermuten, hilft ein klarer Ablauf. Ziel ist, den Kreis zu identifizieren und dann die Route zu finden, die diesen Kreis verursacht.

• Traceroute: wiederkehrende Hops identifizieren (A↔B oder A↔B↔C).
• Route pro Hop prüfen: auf jedem beteiligten Router show ip route <ZIEL>.
• Forwarding prüfen: je nach Plattform show ip cef <ZIEL> für den tatsächlichen Next Hop.
• Quelle der Route klären: ist es connected, static, OSPF, EIGRP, BGP, redistributed?
• Rückweg prüfen: insbesondere bei NAT, PBR oder Firewalls.

Praktischer Hinweis für die Fehlersuche

Wenn Router A für das Ziel über Router B routet und Router B für das gleiche Ziel über Router A routet, ist der Loop sichtbar. Dann ist die entscheidende Frage: Warum glauben beide, dass der jeweils andere den Weg kennt? Häufig ist die Antwort: Default Route, falsche Summary oder Redistribution.

Prävention: Standards, die Routing-Loops sehr effektiv verhindern

Die beste Loop-Vermeidung ist ein sauberes Betriebsmodell. Diese Standards sind in Cisco-Netzen besonders wirksam:

• Default-Strategie klar definieren: nur definierte Router erzeugen Default, keine gegenseitigen Defaults.
• Redistribution minimieren: wenn möglich einseitig; sonst Tagging und Filter zwingend.
• Prefix-Filter als Pflicht: für Redistribution und BGP immer „allow-list“, nie „permit any“.
• Summarization nur mit IP-Plan: Summaries gehören zu sauberen Adressblöcken und benötigen Discard-Routen.
• Dokumentation: Border-Punkte, Redistributor, Tags, AD-Änderungen, Summaries, PBR-Regeln.
• Failover-Tests: Link down, Border down, Rückkehr; Pfadwahl verifizieren.

Für allgemeine Härtungs- und Standardisierungsprinzipien im Betrieb ist der Anchor-Text CIS Controls eine sinnvolle Ergänzung, besonders für Change-Management, Monitoring und sichere Basiskonfigurationen.

Konkrete Cisco-Checks: Was Sie regelmäßig überwachen sollten

Viele Routing-Loops werden durch Änderungen ausgelöst. Regelmäßige Checks und Monitoring reduzieren die Wahrscheinlichkeit, dass ein Fehler unbemerkt produktiv geht.

• Routingtable-Änderungen: Flapping von Default oder Summary-Prefixen beobachten.
• Redistribution-Policies: Route-Map Trefferzähler prüfen (show route-map).
• Prefix-Listen: Matches und Reihenfolge prüfen (show ip prefix-list).
• BGP Prefix Count: bei Peers Abweichungen alarmieren (show ip bgp summary).
• Interface-Fehler: Flaps und Errors können Konvergenz und Pfadwahl destabilisieren.

Praxis-Checkliste: Routing-Loop vermeiden vor dem Go-Live

• Existieren keine gegenseitigen Default Routes ohne klare Upstream-Rolle?
• Ist bei jeder bidirektionalen Redistribution Tagging aktiv und Rückexport geblockt?
• Sind Prefix-Filter überall „allow only what you need“?
• Sind Summaries korrekt, aggregierbar und durch Discard/Null0 abgesichert?
• Ist PBR restriktiv und mit Return Path/NAT/Firewall-State abgestimmt?
• Wurden Failover-Szenarien getestet (Link down, Border down, Recovery)?
• Sind alle Sonderparameter dokumentiert (AD, Cost/Delay, Route-Maps, Tags, Summaries)?

Konfiguration speichern und Änderungen nachvollziehbar halten

Wenn Sie Loop-Ursachen behoben oder Präventionsmaßnahmen umgesetzt haben, speichern Sie die Konfiguration, damit sie nach einem Neustart erhalten bleibt:

copy running-config startup-config

Im produktiven Betrieb lohnt es sich zusätzlich, Konfigurationsänderungen zu versionieren und klare Change-Prozesse einzuhalten. Gerade bei Redistribution, BGP-Policies und PBR sind kleine Abweichungen oft der Auslöser für große Effekte.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.