Site icon bintorosoft.com

Routing Troubleshooting: IGP vs. BGP – wo zuerst schauen?

Red Snapper

A futuristic server room with multiple network switches and organized, vibrant Ethernet cables connected to each one. LED lights on the switches add a soft, ambient glow, giving a sense

Routing Troubleshooting ist eine der anspruchsvollsten Aufgaben im Netzbetrieb, weil Fehlerbilder selten „sauber“ auf eine Schicht zeigen. Nutzer melden „Service down“, Monitoring zeigt Paketverlust oder Latenzspitzen, und irgendwo im Hintergrund sind Routen verschwunden, falsch priorisiert oder auf einen unerwarteten Pfad ausgewichen. In diesem Moment hilft eine zentrale Frage: IGP vs. BGP – wo zuerst schauen? Wer planlos zwischen OSPF-States, BGP-Policies und Traceroutes springt, verliert wertvolle Zeit und erhöht das Risiko, durch hektische Änderungen neue Probleme zu erzeugen. Der professionelle Ansatz ist methodisch: Zuerst die Domäne eingrenzen (intra-domain vs. inter-domain), dann die Abhängigkeiten prüfen (Next-Hop Reachability, Recursive Lookup, RIB/FIB), und erst anschließend in Protokolldetails eintauchen. Dieser Artikel zeigt Ihnen ein praxiserprobtes Vorgehen für Routing Troubleshooting, das in Enterprise-, Provider- und Cloud-Hybrid-Netzen funktioniert: Welche Signale sprechen für ein IGP-Problem, welche für BGP, welche Checks liefern in Minuten die höchste Trennschärfe – und wie Sie anhand von Evidence entscheiden, ob Sie bei OSPF/IS-IS/Static zuerst suchen oder bei BGP-Session, Policy und Route-Selection.

IGP vs. BGP: Die saubere mentale Trennung im Incident

IGP (Interior Gateway Protocol) und BGP (Border Gateway Protocol) lösen unterschiedliche Probleme, auch wenn sie beide „Routing“ machen. IGPs wie OSPF oder IS-IS optimieren die Pfadwahl innerhalb einer administrativen Domäne: schnelle Konvergenz, Metriken, Topologieverteilung. BGP hingegen ist primär für Policy-basierte Pfadwahl zwischen Domänen gedacht (Internet, Provider, Multi-Homing, große WANs) und verbreitet Reachability, aber nicht notwendigerweise die interne Topologie.

Als zuverlässige Primärquellen eignen sich die Standards: für BGP RFC 4271, für OSPFv2 RFC 2328 und für OSPFv3 RFC 5340.

Der wichtigste Schnellcheck: Ist es ein Reachability- oder ein Policy-Problem?

Bevor Sie „IGP vs. BGP“ entscheiden, klären Sie, ob das Problem primär Reachability oder primär Policy ist. Das klingt banal, spart aber die meiste Zeit.

Praxisregel: Wenn ein Präfix „im BGP da ist“, aber im FIB nicht forwardet, ist der Next-Hop-/IGP-Pfad fast immer der erste Verdacht. Wenn ein Präfix gar nicht erst auftaucht oder plötzlich mit anderem AS-Pfad/Attributen kommt, ist BGP-Policy eher der Einstieg.

Die 5-Minuten-Methode: FIB, RIB, Next-Hop, Pfad, Scope

Routing Troubleshooting wird schnell, wenn Sie eine feste Reihenfolge nutzen. Die folgenden Checks sind bewusst technologieagnostisch und funktionieren unabhängig vom Hersteller.

Diese Reihenfolge verhindert, dass Sie sich in Protokolldetails verlieren, während der eigentliche Fehler in einer fehlenden rekursiven Route oder in einer VRF-Zuordnung steckt.

Wann zuerst ins IGP schauen: typische Indizien

IGP-Probleme zeigen sich häufig als „plötzlicher Pfadwechsel“ oder als Ausfall ganzer Teilbereiche innerhalb einer Domäne. Typisch ist auch, dass mehrere Services gleichzeitig betroffen sind, weil viele BGP-Next-Hops, Tunnel-Endpunkte oder zentrale Dienste (DNS, AAA, NAT) über denselben Underlay-Pfad laufen.

IGP-Root-Cause-Klassen, die Sie zuerst prüfen sollten

Wann zuerst in BGP schauen: typische Indizien

BGP-Probleme wirken häufig selektiv: bestimmte externe Ziele gehen nicht mehr, nur ein Providerpfad ist betroffen, oder nur bestimmte Communities/Policies ändern das Verhalten. Auch „Route ist weg, aber IGP ist gesund“ ist ein klassisches BGP-Signal.

BGP-Root-Cause-Klassen, die Sie zuerst prüfen sollten

Der häufigste „Graubereich“: BGP ist da, aber Forwarding ist kaputt

Viele Incidents sehen so aus: „BGP zeigt Route, aber Traffic kommt nicht durch.“ Hier entscheidet sich, ob Sie Zeit sparen oder verlieren. In der Praxis liegt die Ursache oft nicht in BGP selbst, sondern in der rekursiven Next-Hop-Auflösung. BGP kann ein Präfix kennen, aber wenn der Next Hop nicht erreichbar ist, wird die Route nicht installiert oder führt ins Blackhole (je nach Plattform und Policy).

Recursive Lookup als Prüfschritt

Ein praktikables mentales Modell: BGP liefert „Zielpräfix → Next Hop“. IGP liefert „Next Hop → Interface“. Wenn dieser zweite Schritt bricht, ist die BGP-Route operativ wertlos. Deshalb ist beim Verdacht „BGP da, aber keine Connectivity“ der IGP-/Underlay-Check meist der schnellste Einstieg.

IGP vs. BGP anhand von Traceroute und Path-Änderungen unterscheiden

Traceroute ist kein Routing-Orakel, aber als Mustererkennung sehr hilfreich. Ein IGP-Problem zeigt sich oft als „Sprung“ innerhalb Ihrer Domäne: andere Core-Router, andere Regionen, unerwartete Intra-Domain-Umwege. Ein BGP-Problem zeigt sich häufiger am Rand: anderer Provider, anderer Internet-Exit, anderes Peering. Wichtig ist, relative Beobachtungen in konkrete Pfade umzusetzen.

Redistribution und Route Leaks: Wenn IGP und BGP sich gegenseitig überraschen

Die gefährlichsten Routing-Incidents entstehen häufig nicht in IGP oder BGP isoliert, sondern an deren Schnittstelle: Redistribution, Route Leaks zwischen VRFs, oder „Default Route plötzlich im IGP“. Solche Fehler wirken oft wie „random“ Blackholes oder Schleifen, weil sie nur bestimmte Präfixklassen betreffen.

Indizien für Redistribution-Probleme

Latency und Routing: Wenn „Routing ok“ trotzdem Performance kaputt ist

Routing kann korrekt sein und dennoch Performance verschlechtern, wenn Pfadwahl auf einen längeren Weg kippt, wenn ECMP einen schlechten Member enthält oder wenn Convergence-Events kurzfristig Loss/Jitter erzeugen. Deshalb gehört zu Routing Troubleshooting immer auch die Performance-Sicht: Latenzspitzen, Retransmissions, Jitter – und deren zeitliche Korrelation zu Routing-Events.

Beweisführung: Welche Evidence Sie im Incident sichern sollten

Routing-Incidents werden in Postmortems und Provider-Tickets nur dann sauber gelöst, wenn die Evidence stimmt. Sammeln Sie nicht „alles“, sondern die Daten, die Entscheidungen begründen.

Runbook-Baustein: IGP vs. BGP – wo zuerst schauen in 15 Minuten

Outbound-Referenzen für Standards und vertiefende Lektüre

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:

Lieferumfang:

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.

 

Exit mobile version