BGP Troubleshooting: Session, Prefixes, Route-Maps und Soft Reconfig

BGP Troubleshooting ist in großen Cisco-Netzen eine Kernkompetenz, weil BGP nicht nur das Internet-Routing prägt, sondern auch in Enterprise-Backbones, MPLS L3VPN, EVPN/VXLAN oder WAN-Edge-Designs als Policy-Engine genutzt wird. Wenn eine BGP-Session nicht auf „Established“ kommt, wenn plötzlich Prefixes fehlen oder wenn Route-Maps scheinbar „nichts tun“, ist der Impact oft sofort spürbar: Standorte verlieren Connectivity, Traffic läuft über falsche Pfade, Redundanz bricht weg oder es entstehen asymmetrische Routen. Gleichzeitig ist BGP sehr gut zu diagnostizieren, wenn man strukturiert vorgeht. BGP ist zustandsbasiert (FSM), arbeitet über TCP und entscheidet streng nach Policies (Prefix-Lists, Route-Maps, Communities, AS-Path, Local Preference). Das bedeutet: Fast jedes Problem lässt sich auf eine klare Ursacheklasse zurückführen – Session/Transport, Capabilities/AFI-SAFI, Policy/Filter oder RIB/FIB-Installation. Dieser Artikel liefert einen praxiserprobten Cisco-Workflow für BGP Troubleshooting: Session, Prefixes, Route-Maps und Soft Reconfig, damit Sie Fehlerbilder schnell einordnen, belastbar nachweisen und sicher beheben können, ohne durch riskante Debugs oder hektische Clears zusätzliche Instabilität zu erzeugen.

Grundprinzip: Erst Session stabilisieren, dann Prefixes und Policies prüfen

Viele BGP-Probleme werden unnötig kompliziert, weil sofort an Route-Maps gearbeitet wird, obwohl die Session gar nicht stabil ist – oder weil Prefixes gesucht werden, obwohl ein Address-Family-Mismatch vorliegt. Eine robuste Reihenfolge sieht so aus:

• Session/Transport: TCP erreichbar, Neighbor kommt auf „Established“ und bleibt stabil.
• AFI/SAFI und Capabilities: IPv4/IPv6/EVPN/VRF-Kontext korrekt, Next-Hop und Route-Refresh ok.
• Prefixes: Werden Routen empfangen/gesendet? Werden sie verworfen? Warum?
• Policies: Prefix-Lists, Route-Maps, Communities, AS-Path-Filter, Maximum-Prefix, Dampening.
• Soft Reconfig/Route Refresh: Änderungen sicher aktivieren, ohne harte Session-Resets.

Wenn Sie diese Reihenfolge einhalten, finden Sie Root Causes deutlich schneller und mit weniger Kollateralschäden.

BGP-Session Troubleshooting: Zustände und typische Ursachen

Die BGP Finite State Machine (FSM) ist im Troubleshooting Ihr Kompass. Jeder State deutet auf eine bestimmte Fehlerklasse hin. In Cisco-Umgebungen sehen Sie diese Zustände typischerweise in den Neighbor-Outputs.

Idle

• Typisch: Neighbor ist administrativ deaktiviert, falsche Konfiguration, fehlende Route zum Peer, falsches Source-Interface, TTL/EBGP-Multihop fehlt.
• Check: Neighbor-Definition korrekt? Ist das Peer-IP erreichbar? Stimmt update-source bzw. das lokale Interface?

Connect / Active

• Typisch: TCP-Verbindung kommt nicht zustande. Ursache ist oft Routing/ACL/Firewall oder falscher TCP-Port-Flow.
• Check: TCP 179 in beide Richtungen erreichbar? Gibt es ACLs/CoPP, die TCP/179 droppen? Existiert eine Rückroute zum Source-IP?

OpenSent / OpenConfirm

• Typisch: TCP steht, aber BGP-Open scheitert oder Capabilities passen nicht. Häufige Ursachen: falsches remote-as, Auth (MD5/TCP-AO je nach Umgebung), AFI/SAFI-Mismatch, falsche TTL.
• Check: remote-as korrekt? Auth-Key identisch? Wurde EBGP-Multihop benötigt? Stimmen Address-Families?

Established

Die Session steht. Ab hier sind fehlende Prefixes meist Policy-, AFI/SAFI- oder RIB-Installationsprobleme. Wenn Established flapped, prüfen Sie Timer, Keepalive/hold, CPU/Control-Plane, Paketverlust und Policies wie Maximum-Prefix.

Session-Checks mit hoher Aussagekraft

Ein effizienter Cisco-Workflow nutzt wenige, aber klare Prüfungen:

• Erreichbarkeit: Ping/Trace zum Peer (aus dem richtigen VRF), optional TCP-Check auf Port 179.
• Routing zum Peer: Gibt es eine Route zum Peer und eine Rückroute (besonders bei update-source/Loopback)?
• Neighbor Details: remote-as, local-as, update-source, ebgp-multihop, TTL, Auth, BGP Router-ID.
• Logs/Reason: Cisco liefert häufig „last reset reason“ oder Hinweise auf Notification Codes.

Wenn Sie die „last reset reason“ konsequent auswerten, vermeiden Sie Rätselraten. Ein Maximum-Prefix-Event sieht anders aus als ein Hold Timer Expired oder ein Peer Deconfigured.

Häufige Session-Fallen in Cisco-Designs

• Falsches update-source: eBGP/iBGP über Loopbacks erfordert korrektes Source-Interface plus Routing (und bei eBGP meist ebgp-multihop).
• EBGP Multihop fehlt: Wenn Peer nicht direkt verbunden ist, bleibt die Session häufig in Active/Connect oder scheitert nach Open.
• ACL/Firewall/CoPP: TCP/179 oder BGP-Keepalives werden gedroppt. Besonders relevant auf WAN-Edges oder an Security-Zonen.
• Auth Mismatch: MD5-Key falsch oder inkonsistent rotiert; Ergebnis sind Open-Fehler oder häufige Resets.
• VRF-Kontext: Peer-IP existiert in VRF, aber Tests werden im Global Table gemacht – dann wirkt es wie „unreachable“.

Prefixes Troubleshooting: Werden Routen empfangen, aber nicht genutzt?

Wenn die Session Established ist, ist die nächste Frage: Kommt das Prefix überhaupt rein? und Wenn ja, warum landet es nicht in der Routing-Tabelle? Trennen Sie dafür drei Ebenen:

• Adj-RIB-In: Was der Router vom Nachbarn erhält (vor oder nach bestimmten Filtern, je Feature).
• Loc-RIB: BGP-Auswahlprozess (Best Path) – welche Route gewinnt und warum.
• RIB/FIB: Wird die gewinnende BGP-Route in die globale Routing-Tabelle installiert und in die Forwarding-Tabelle programmiert?

In der Praxis bedeutet das: Eine Route kann empfangen werden, aber durch Import-Policy abgewiesen werden. Oder sie gewinnt in BGP, wird aber wegen RIB-Failure (z. B. bessere Administrative Distance einer anderen Quelle) nicht installiert.

Die häufigsten Gründe für „Route empfangen, aber nicht installiert“

• Next-Hop unreachable: Besonders häufig bei iBGP oder bei Route-Reflector-Designs. Wenn der Next-Hop nicht auflösbar ist, wird die Route nicht genutzt.
• Administrative Distance: Eine andere Quelle (z. B. OSPF, Static) hat bessere Distance und verdrängt BGP.
• RIB-Failure: BGP markiert die Route als beste, aber Installation scheitert (z. B. wegen recursion/resolve issues).
• Maximum-Prefix: Der Nachbar überschreitet die Prefix-Grenze; je Einstellung kann die Session resetten oder Routen werden abgewiesen.
• VRF Import/Export: In VRF-/L3VPN-Kontexten fehlen Route Targets oder Import-Policies.

Ein Profi-Tipp: Bei Prefix-Problemen immer als Erstes Next-Hop und VRF-Kontext prüfen. In vielen Fällen ist „Policy“ nicht die Ursache, sondern fehlende Erreichbarkeit des Next-Hop.

Route-Maps und Prefix-Lists: Warum Filter oft „zu viel“ droppen

Route-Maps sind das Schweizer Taschenmesser für BGP-Policies – und gleichzeitig die häufigste Fehlerquelle. Typische Fehler entstehen durch zu breite deny-Statements, falsche Sequenzen, unvollständige Match-Kriterien oder falsche Anwendung (in/out, Address-Family). Ein sauberer Troubleshooting-Ansatz prüft zunächst die Struktur:

• Wird die Route-Map überhaupt angewendet? In der richtigen Address-Family? In die richtige Richtung (in/out)? Im richtigen Neighbor?
• Welche Sequence matcht? Bei Route-Maps zählt die Reihenfolge. Eine frühe deny-Sequence kann alles blocken.
• Gibt es ein „permit any“ am Ende? Ohne explizites Permit kann eine Route-Map implizit mehr droppen als beabsichtigt.
• Match-Logik korrekt? Prefix-List/ACL/Community/AS-Path-Match trifft wirklich auf die erwarteten Routen?

Prefix-Lists: Präzise, aber fehleranfällig

Prefix-Lists sind häufig der beste Filtermechanismus, aber kleine Fehler haben große Wirkung: ein falsches le/ge, ein falsches Sequenz-Ordering oder ein vergessenes permit am Ende kann komplette Routingdomänen abschneiden. Best Practice ist, Prefix-Lists deterministisch zu halten:

• Sequenzen bewusst setzen: Keine zufällige Reihenfolge.
• Explizite Defaults: Ein bewusstes „deny any“ ist ok – aber dann muss vorher klar sein, was erlaubt ist.
• Peer-spezifische Filter: Für eBGP Richtung Provider/Partner immer explizite In/Out Filter definieren.

Communities und Attribute: Wenn die Policy „richtig“ ist, aber die Wirkung fehlt

Ein häufiger Fall im BGP Troubleshooting: Route-Maps setzen Communities oder Local Preference, aber Traffic folgt nicht der Erwartung. Dann lohnt sich eine Attributprüfung:

• Local Preference: Wirkt nur innerhalb einer AS und ist oft der wichtigste Pfadsteuerungshebel für Outbound-Traffic.
• AS-Path: Wirkt auf Inbound-Auswahl bei externen Peers; kürzer ist meist besser, aber Provider-Policies spielen mit.
• MED: Wird oft nur zwischen bestimmten Nachbarn berücksichtigt; nicht überall relevant.
• Community Propagation: Wurde send-community gesetzt? Ohne das kommen Communities beim Peer oft nicht an.

Praxis-Tipp: Prüfen Sie nicht nur, ob ein Attribut gesetzt wurde, sondern ob es am richtigen Ort wirkt. Local Preference hilft nicht, wenn die Entscheidung im Provider-Netz getroffen wird. Communities helfen nicht, wenn sie nicht propagiert werden.

Soft Reconfig und Route Refresh: Änderungen aktivieren ohne harte Clears

Im Betrieb ist es entscheidend, Policy-Änderungen möglichst ohne Session-Reset zu aktivieren. Harte Clears (clear bgp) können Traffic umwerfen, Reconvergence auslösen und bei großen Tabellen Minuten dauern. Cisco bietet dafür Mechanismen wie Route Refresh und (historisch) Soft Reconfiguration inbound.

Route Refresh als bevorzugter Mechanismus

• Konzept: Der Router fordert vom Peer eine erneute Werbung der Routen an, ohne die Session zu resetten.
• Vorteil: Weniger disruptiv, schneller, besonders bei großen Tabellen.
• Voraussetzung: Peer muss Route Refresh Capability unterstützen (heute meist Standard).

Soft Reconfiguration inbound: Nützlich, aber mit Kosten

• Konzept: Der Router speichert eine Kopie der empfangenen Routen (Pre-Policy), um später Policies neu anwenden zu können.
• Nachteil: Speicherverbrauch kann erheblich sein, besonders bei vielen Prefixes.
• Praxisregel: Nur gezielt einsetzen, wenn Route Refresh nicht verfügbar oder nicht ausreichend ist, und Speicherbudget prüfen.

Im Troubleshooting ist Soft Reconfig häufig relevant, wenn Sie „was kam wirklich rein?“ sehen möchten oder wenn Sie inbound Policies ohne Reset neu evaluieren müssen. Professionell ist: zuerst Route Refresh nutzen, Soft Reconfig nur bewusst aktivieren.

Route-Map-Änderungen sicher ausrollen: „Diff-first“ und kleine Schritte

Route-Maps sind kritisch. Änderungen sollten so geplant werden, dass Risiko minimiert wird:

• Kleine Änderungen: Eine Regel anpassen, nicht fünf Dinge gleichzeitig.
• Vorher/Nachher prüfen: Welche Prefixes werden aktuell akzeptiert/abgewiesen? Welche Attribute werden gesetzt?
• Soft Update: Route Refresh oder Soft Reconfig nutzen, statt Session hart zu resetten.
• Rollback bereit: Alte Route-Map/Prefix-List-Version schnell wiederherstellen können (Git/Backup).

Damit vermeiden Sie, dass ein Policy-Fehler netzweit eskaliert.

Prefix-Limits, Dampening und Flaps: Stabilität gegen Route Leaks und Churn

In Enterprise- und ISP-nahen Designs sind Guardrails Pflicht. Zwei Themen sind häufige Ursachen für „plötzlich ist alles weg“:

• Maximum-Prefix: Wenn der Peer mehr Prefixes sendet als erwartet, kann die Session resetten oder Routen werden geblockt – je nach Konfiguration. Im Incident prüfen Sie Zähler und den Reset-Grund.
• Dampening: Route Dampening kann flappende Routen unterdrücken. Das stabilisiert, kann aber auch „warum kommt die Route nicht zurück?“ erklären.

Best Practice: Max-Prefix immer so setzen, dass er Schutz bietet, aber nicht zu knapp ist. Und Dampening nur dort einsetzen, wo es wirklich sinnvoll ist, weil es Troubleshooting erschweren kann.

Typische BGP-Fehlerbilder und schnelle Zuordnung

• Session bleibt Active: TCP/179 blockiert, kein Rückweg, falsche Peer-IP, falsches update-source.
• Session fällt regelmäßig: Hold Timer Expired (Paketverlust/CPU), Auth-Issues, CoPP/ACL, physische Flaps.
• Established, aber 0 Prefixes: Falsche Address-Family aktiviert, inbound Filter droppt alles, Max-Prefix greift, VRF falsch.
• Prefixes vorhanden, aber nicht im Routing: Next-Hop unreachable, Distance/RIB-Failure, VRF Import/Policy.
• Traffic folgt nicht Policy: Local Preference/Community nicht gesetzt oder nicht propagiert, Attribute wirken an falscher Stelle.

Debugging ohne Risiko: Wann Debug sinnvoll ist und wie Sie es begrenzen

BGP-Debugs können sehr laut sein und die Control Plane belasten, insbesondere in Netzen mit vielen Updates. In professionellen Workflows gilt:

• Debug nur mit Hypothese: z. B. „Auth mismatch“ oder „Open Notification“ nachweisen.
• Conditional Debug: Nur für den betroffenen Neighbor und nur kurz.
• Bevorzugt Logs/Neighbor Reason: Viele BGP-Probleme lassen sich ohne Debug klären, wenn Reset-Gründe und Counters sauber ausgewertet werden.

Runbook: Schneller BGP Troubleshooting Ablauf

• Session State prüfen: Idle/Active/Open*/Established und „last reset reason“ interpretieren.
• Transport prüfen: Routing zum Peer, TCP/179, ACL/Firewall/CoPP, update-source/ebgp-multihop.
• AFI/SAFI prüfen: IPv4/IPv6/VRF/EVPN-Kontext korrekt? Neighbor in der richtigen Address-Family?
• Prefixes prüfen: Empfangen/gesendet? Zähler plausibel? Max-Prefix-Events?
• Policy prüfen: Prefix-Lists, Route-Maps, Communities, send-community, Sequenzen, Permit/Deny-Logik.
• Next-Hop & RIB: Next-Hop reachable? RIB-Failure? Distance-Konflikte?
• Soft Update: Route Refresh oder Soft Reconfig nutzen, um Policies ohne Reset neu anzuwenden.
• Post-Checks: Stability (keine Flaps), Prefixcounts, Trafficpfade, Monitoring/Logs.

Outbound-Referenzen

• RFC 4271 (BGP-4) als normative Grundlage für Session-FSM, Open/Keepalive/Update und Protokollverhalten.
• Cisco: BGP Troubleshooting (Best Practices) für Cisco-spezifische Diagnosehinweise zu Sessionaufbau, Policies und typischen Ursachen.
• Cisco: BGP Route-Map und Policy Troubleshooting als Referenz für Filterlogik, Attribute und häufige Policy-Fallen.
• Cisco IOS XE Configuration Guides für plattformspezifische BGP-Konfiguration, VRF-Kontext und Soft-Reconfig/Route-Refresh-Optionen.
• Wireshark Dokumentation für BGP/TCP-Analyse bei Sessionproblemen (SYN/ACK, Retransmits, Notification Codes).

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.