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

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.

• IGP: „Wie komme ich innerhalb meines Netzes zum Next Hop?“ (Topologie, Metriken, schnelle Reaktion)
• BGP: „Welche Präfixe nehme ich überhaupt an und über welchen Exit?“ (Policy, Pfad-Attribute, Skalierung)
• Gemeinsamer Kern: Beide enden in der Forwarding-Tabelle (FIB). Wenn FIB falsch ist, ist die Servicewirkung real – egal, ob die Ursache IGP oder BGP war.

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.

• Reachability: Next Hop nicht erreichbar, Link/Adjacency down, Rekursion bricht, FIB hat kein gültiges Out-Interface → oft IGP- oder Underlay-Thema.
• Policy: Route wird nicht importiert/exportiert, LocalPref/Communities/Filters greifen, falscher Pfad wird bevorzugt → häufig BGP-Policy oder Redistribution/Leak-Thema.

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.

• FIB-Check: Gibt es einen Forwarding-Eintrag für das Zielpräfix? Zeigt er auf ein plausibles Out-Interface?
• RIB-Check: Gibt es eine Route im Routing Table, und aus welcher Quelle (connected/static/IGP/BGP)?
• Next-Hop Reachability: Ist der Next Hop rekursiv auflösbar und via IGP/connected erreichbar?
• Pfad-Check: Weicht der tatsächliche Pfad (Traceroute/Flow) vom erwarteten Design ab?
• Scope-Check: Betrifft es nur ein Segment/VRF/Standort (IGP/Underlay) oder nur bestimmte externe Präfixe/Peers (BGP/Policy)?

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.

• Mehrere Ziele betroffen: nicht nur ein Präfix, sondern ganze Standort-/Subnetzbereiche
• Adjacency down/flapping: OSPF/IS-IS Nachbarschaften instabil, Konvergenz wiederholt
• ECMP/Member-Probleme: nur manche Flows betroffen, weil ein IGP-Next-Hop über fehlerhaften Member führt
• Next-Hop unreachable: BGP-Routen sind da, aber Next Hop ist nicht auflösbar oder nicht erreichbar
• Layer-1/2 Indizien: CRC/Errors/Flaps, die IGP-Sessions indirekt destabilisieren

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

• Interface/Adjacency: Link up? MTU konsistent? Hello/Dead Timer? Authentication?
• LSDB/Topology Drift: unterschiedliche Sicht auf Topologie, fehlende LSA/LSPs, area/level mismatch
• Metric-Überraschungen: unerwartete Kosten, falsche Reference Bandwidth, asymmetrische Metriken
• Redistribution: Route Leaks zwischen IGP und anderen Quellen (static/BGP) mit falschen Tags/Policies
• VRF/Underlay-Overlays: IGP läuft in einer VRF/Underlay, Overlay-Next-Hops hängen daran

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.

• Selektiver Ausfall: nur bestimmte Präfixe, ASNs oder Internetziele
• Session-/Peer-Themen: BGP Neighbor down/flapping, Hold Timer Expired, Policy rejects
• Route fehlt komplett: Präfix wird nicht gelernt oder nicht announced
• Route-Selection kippt: anderer Exit/Provider wird bevorzugt (LocalPref/AS-Path/MED)
• RPKI/DNSSEC/Filtering-Änderungen: Policies oder Validierung führen zu Drop/Depriorisierung

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

• Session Health: TCP/179 erreichbar? TTL/ebgp-multihop korrekt? Authentication?
• Import/Export Policy: Prefix-Lists/Route-Maps/Communities, max-prefix, inbound/outbound filters
• Next-Hop Handling: next-hop-self, route reflectors, iBGP Next-Hop reachability
• Attribute Changes: LocalPref, MED, AS-PATH, Communities – warum wurde Pfadwahl anders?
• Route Propagation: iBGP Full Mesh/Route Reflector, Cluster-IDs, RR-Policy, missing routes in bestimmten Regionen

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).

• Typisches Muster: Route ist im BGP-RIB sichtbar, aber nicht in der globalen RIB/FIB
• Ursachen: IGP-Route zum Next Hop fehlt, VRF mismatch, Interface down, falsch gesetzte Next-Hop-Attribute
• Nachweis: Next Hop pingbar? Gibt es eine IGP/connected route zum Next Hop? Ist das Out-Interface korrekt?

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.

• Pfadwechsel innerhalb des Unternehmens: eher IGP/Underlay, Metric Change, Adjacency Loss
• Pfadwechsel am Exit/Provider: eher BGP-Policy/Selection, Session-Change, Provider Event
• Asymmetrie: Rückweg anders als Hinweg (kritisch für stateful Firewalls) – kann IGP oder BGP sein, oft aber Policy-/Exit-getrieben

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.

• Leak IGP → BGP: interne Präfixe werden nach außen announced (Sicherheits- und Routing-Risiko)
• Leak BGP → IGP: externe Präfixe oder Default werden in IGP injiziert, erzeugen Umwege oder Overload
• VRF Leaks: falsche Import/Export Targets, route leaking zwischen Segmenten
• Tagging/Policy fehlt: ohne Tags lassen sich Leaks schwer kontrollieren und debuggen

Indizien für Redistribution-Probleme

• Viele neue Routen tauchen plötzlich im IGP auf (LSDB wächst, CPU steigt)
• Default Route erscheint/verschwindet unerwartet
• Routing Loops in Traceroute (Hinweis auf falsche Präfix-Injektion oder Policy)
• Unterschiedliche Sicht in verschiedenen Bereichen (ein Region-RR hat andere Policies)

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.

• Convergence: kurze Unterbrechungen oder Umwege während Neuberechnung
• ECMP Member Drift: ein Member mit Errors erzeugt selektive Performanceprobleme
• Policy-bedingte Umwege: BGP wählt „teuren“ Providerpfad, Latenz steigt dauerhaft

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.

• Timeline: wann begann es, welche Changes/Events gab es (Deployments, Provider Meldungen)?
• RIB/FIB Snapshots: betroffene Präfixe, Quelle der Route, Next Hop, install status
• IGP State: Neighbor States, LSDB/LSP Changes, area/level, metric anomalies
• BGP State: Neighbor state, received/advertised routes, policy decisions, attribute changes
• Pfadbelege: Traceroute/MTR Muster, bevorzugter Exit, Asymmetriehinweise
• Interface Health: Errors/Flaps/Drops auf relevanten Links und ECMP-Members

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

• Minute 0–3: Scope klären: Welche Ziele/Präfixe betroffen? Intern/extern? Ein Standort oder viele? VRF betroffen?
• Minute 3–6: FIB/RIB/Next-Hop prüfen: Route da? Quelle IGP/BGP? Next Hop erreichbar?
• Minute 6–9: Wenn Next Hop fehlt/unerreichbar: IGP zuerst (Adjacency, LSDB/LSP, Metrics, Interface Health). Wenn Route fehlt oder Pfadwahl kippt: BGP zuerst (Session, Policy, Attributes).
• Minute 9–12: Pfadbelege: Traceroute/Flows – Pfadwechsel intern (IGP) oder am Exit (BGP)? Asymmetrie mit stateful Geräten beachten.
• Minute 12–15: Low-Risk Mitigation: fehlerhaften ECMP-Member drainen, Policy temporär stabilisieren (z. B. LocalPref), Rollback bereit; danach Verifikation mit RIB/FIB und Servicechecks.

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

• RFC 4271 für BGP-4 Grundlagen, Sessions und Route Processing
• RFC 2328 für OSPFv2 und typische Neighbor/LSA-Mechaniken
• RFC 5340 für OSPFv3 (IPv6 und moderne Deployments)
• RFC Editor als zentrale Quelle für Protokollstandards und verlässliche Definitionen

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.