BGP Troubleshooting: Peering, Prefixes und Route-Maps verstehen

BGP Troubleshooting ist für viele Netzwerk-Teams der Moment, in dem Routing nicht mehr nur „ein paar interne Netze“ bedeutet, sondern echte Steuerung von Pfaden, Präfixen und Policies: Peering-Sessions müssen stabil stehen, Prefixes müssen korrekt angekündigt und empfangen werden, und Route-Maps bzw. Routing-Policies entscheiden darüber, was am Ende wirklich in der Routing-Tabelle landet. Wenn hier etwas schiefgeht, sind die Symptome oft dramatisch – oder tückisch selektiv: Ein Standort erreicht „das Internet“, aber bestimmte Ziele nicht; ein Cloud-Interconnect ist aktiv, aber nur ein Teil der Netze ist erreichbar; ein Provider meldet „wir sehen Ihre Prefixes nicht“; oder plötzlich wird zu viel (oder zu wenig) geroutet. Gleichzeitig ist BGP bewusst flexibel und policy-getrieben. Das ist seine Stärke – und genau deshalb sind Fehlkonfigurationen oder Missverständnisse so häufig. In diesem Artikel lernen Sie praxisnah, wie Sie BGP-Probleme systematisch eingrenzen: erst das Peering (Session und TCP/179), dann die Prefixes (Advertisements, Best Path, RIB/FIB), und schließlich die Route-Maps/Policies (Prefix-Lists, AS-Path, Communities, Local Preference, MED). Ziel ist ein klarer Standardablauf, mit dem Sie Fehler schneller finden, sauber belegen und Änderungen kontrolliert verifizieren können.

BGP in der Praxis: Was Sie fürs Troubleshooting wirklich verstehen müssen

Für effektives Troubleshooting reicht ein fokussiertes Modell: BGP ist ein Path-Vector-Protokoll, das über TCP (Port 179) Nachbarschaften aufbaut, Updates (NLRI + Attribute) austauscht und daraus pro Prefix den „besten“ Pfad auswählt. Wichtig ist die Trennung der Datenebenen:

• Session-Ebene: TCP-Verbindung und BGP-FSM (Idle → Connect → Active → OpenSent → OpenConfirm → Established).
• Control Plane: Empfangene/gesendete Updates, BGP-RIB (Adj-RIB-In/Loc-RIB/Adj-RIB-Out).
• Forwarding Plane: Installierte Routen in der globalen Routing-Tabelle (RIB) und im Forwarding (FIB).
• Policy-Ebene: Route-Maps/Policies entscheiden, was akzeptiert, verändert, bevorzugt oder verworfen wird.

Normative Grundlagen liefert RFC 4271 (Border Gateway Protocol 4). Für Operation und Best Practices sind ergänzend RFC 7454 (BGP Operations and Security) und für Route Flap Damping RFC 7196 hilfreich.

Typische Symptome: Wie sich BGP-Probleme äußern

BGP-Probleme sind selten „alles ist komplett down“. Häufiger sind es selektive Ausfälle oder unerwartete Pfadwechsel. Die wichtigsten Muster:

• Peering down: Session kommt nicht auf Established, BGP bleibt in Active/Connect oder flappt.
• Peering up, aber keine Prefixes: Establishment ok, aber Updates fehlen (Filter, max-prefix, policy deny).
• Prefix wird nicht angekündigt: Provider sieht das Netz nicht, oder nur ein Teil der Präfixe erscheint.
• Prefix wird empfangen, aber nicht geroutet: Route ist in BGP sichtbar, aber nicht in der Routing-Tabelle (RIB/FIB) – häufig wegen Next-Hop, Admin Distance, VRF oder Policy.
• Unerwartete Pfade: Traffic nimmt „falschen“ Provider, Latenz steigt, oder Return Path läuft anders (Local Pref/AS-Path/Communities).
• Flapping/Instabilität: häufige Updates, CPU hoch, Konvergenz langsam, ggf. Damping oder Keepalive/holdtime-Probleme.

Peering Troubleshooting: Wenn die BGP-Session nicht hochkommt

Wenn das Peering nicht hochkommt, ist BGP oft nicht „das Problem“, sondern TCP/179, Reachability oder Parameter-Mismatches. Arbeiten Sie strikt in dieser Reihenfolge: L3-Erreichbarkeit → TCP → BGP-Parameter → Policies/Security.

L3-Erreichbarkeit und TCP/179

• Kann ich die Peer-IP erreichen? Ping ist hilfreich, aber nicht ausreichend (ICMP kann erlaubt sein, TCP blockiert).
• Ist TCP/179 in beide Richtungen erlaubt? Firewalls/ACLs müssen TCP/179 zulassen.
• Ist die Source-IP korrekt? Bei eBGP Multihop oder iBGP mit Loopbacks muss die Source (update-source) stimmen.
• Gibt es asymmetrisches Routing? TCP-Handshake kann scheitern, wenn Rückweg über ein anderes Gerät läuft, das den State nicht kennt.

Die häufigsten Parameter-Mismatches

• Remote AS falsch: Sehr häufige Ursache – die AS-Nummer passt nicht zum Peer.
• MD5/TCP-AO Auth falsch: Einseitig aktiviert oder Key falsch → Session bleibt down oder flappt.
• TTL/Hops: eBGP Standard ist TTL 1; bei Multihop muss explizit erhöht werden.
• Router-ID/Cluster-ID Konflikte (iBGP-RR): In Route-Reflector-Designs können falsche IDs zu unerwartetem Verhalten führen.

Für BGP-Sicherheit und Authentifizierung/Operational Guidance ist RFC 7454 eine gute Quelle.

BGP-FSM schnell interpretieren

• Idle: Konfiguration fehlt oder administrativ down.
• Connect/Active: TCP-Verbindung kommt nicht zustande (Firewall, Routing, TTL, Source-IP).
• OpenSent/OpenConfirm: TCP steht, aber BGP-Parameter/Capabilities passen nicht (AS, Auth, AFI/SAFI, Timer, Negotiation).
• Established, dann Reset: häufig Hold Timer, Policy-Fehler, Max-Prefix, oder BFD/Link-Instabilität.

Prefixes Troubleshooting: Wenn Peering steht, aber Routen fehlen

Ein Established-Peering ist nur der Anfang. Der nächste Schritt ist immer: Werden Updates ausgetauscht? Danach: Werden sie akzeptiert? Und schließlich: Werden sie installiert und genutzt?

Inbound: Empfange ich Prefixes vom Peer?

• Adj-RIB-In prüfen: Kommen Updates an oder ist es „0 prefixes received“?
• AFI/SAFI prüfen: IPv4 Unicast, IPv6 Unicast, VPNv4/EVPN – falsches Address Family Setup führt zu „Session up, aber nichts drin“.
• Max-Prefix: Viele Provider setzen Limits; Überschreitung kann zu Session-Reset oder zu Drop führen.
• Route Filters: Prefix-Lists/AS-Path-Lists/Route-Maps inbound können alles verwerfen.

Outbound: Werden meine Prefixes überhaupt angekündigt?

Wenn der Provider Ihr Netz nicht sieht, liegt es oft nicht am Provider, sondern am lokalen Export: BGP announct nur Prefixes, die in der lokalen RIB vorhanden sind (je nach Plattform und Policy). Typische Ursachen:

• Prefix nicht in der Routing-Tabelle: Kein connected/static/IGP-Route vorhanden, daher nichts zu announcen.
• Aggregate/Null Route fehlt: Sie announcen ein Summary (z. B. /23), aber intern existiert keine passende Route oder Discard-Route.
• Outbound Filter blockt: Route-Map/Prefix-List outbound lässt das Prefix nicht durch.
• RPKI/IRR/Policy Reject beim Upstream: Provider kann Prefixes verwerfen, wenn sie nicht autorisiert wirken (auf Ihrer Seite ist alles „gesendet“, aber upstream nicht akzeptiert).

Als Hintergrund zu RPKI-Mechanismen kann RFC 6811 (BGP Prefix Origin Validation) dienen.

Route in BGP sichtbar, aber nicht im Forwarding

Das ist ein sehr häufiger Fall in Enterprise- und Multi-VRF-Setups: Sie sehen die Route im BGP, aber sie erscheint nicht in der globalen Routing-Tabelle oder nicht in der FIB. Typische Gründe:

• Next-Hop nicht erreichbar: BGP-Route ist da, aber der Next-Hop kann nicht rekursiv aufgelöst werden (fehlende IGP-Route, falsches VRF).
• Admin Distance gewinnt nicht: Eine statische Route oder IGP-Route hat geringere Distance und verdrängt BGP.
• VRF/Route Leaking: Route sitzt in VRF A, aber Traffic läuft in VRF B; Import/Export-Policy fehlt.
• Policy verhindert Installation: Some platforms erlauben „receive but not install“ oder tag-based drop in RIB.

Best Path Selection: Warum BGP „den falschen Weg“ nimmt

BGP ist policy-getrieben. Der „beste Pfad“ ist nicht zwingend der kürzeste oder schnellste Pfad, sondern der Pfad, der nach Attributreihenfolge gewinnt. Die genaue Reihenfolge variiert je Hersteller, aber diese Attribute sind in der Praxis die wichtigsten Hebel:

• Local Preference: Primärer Inbound-Steuerhebel im eigenen AS (höher ist besser).
• AS-PATH Länge: Kürzer wird oft bevorzugt (aber Local Pref schlägt meist AS-PATH).
• MED: Hinweis für Inbound-Pfadwahl beim Nachbarn (niedriger ist besser), meist nur innerhalb des gleichen Nachbar-AS relevant.
• Origin: IGP/EGP/Incomplete (selten bewusst genutzt, aber kann Auswirkungen haben).
• Next-Hop/IGP Cost zum Next-Hop: kann bei iBGP-Designs die Pfadwahl beeinflussen.
• Communities: Metadaten, die Policies triggern (Blackhole, LocalPref-Set, No-Export, etc.).

Wenn „der falsche Provider“ genutzt wird, ist das oft kein Routingprotokoll-Fehler, sondern ein Policy-Fehler: LocalPref falsch gesetzt, Communities fehlen, oder eine Route-Map matcht nicht wie gedacht.

Route-Maps verstehen: Match und Set als Ursache für 80% der BGP-Probleme

Route-Maps (oder Policy Statements) bestehen vereinfacht aus zwei Teilen: match (auf welche Routen trifft die Regel?) und set (welche Attribute werden verändert?). Fehler passieren meist in drei Kategorien: die Regel matcht nie, sie matcht zu viel, oder sie setzt das falsche Attribut.

Match-Fallen

• Prefix-List matcht nicht: falsche Maskenlänge, fehlendes „le/ge“-Verhalten, falsche Reihenfolge.
• AS-Path Regex zu breit/zu eng: matcht unerwartete Pfade oder keinen einzigen.
• Community matcht nicht: Community fehlt, ist anders formatiert, oder wird vorher entfernt.
• Route-Map Reihenfolge: First match wins; eine frühe deny-Sequenz kann alles killen.

Set-Fallen

• Local Pref falsch: führt zu unerwarteter Egress-Wahl und Traffic-Shift.
• MED falsch gesetzt: beeinflusst Inbound-Pfadwahl beim Provider nicht wie erwartet (oder wird ignoriert).
• Next-Hop Manipulation: falsches next-hop-self oder next-hop set führt zu nicht installierbaren Routen.
• Community Handling: Communities werden überschrieben statt additiv gesetzt; wichtige Signale gehen verloren.

Hit Counters und Policy-Debug

Viele Plattformen bieten Trefferzähler für Policy-Sequenzen oder zumindest Logs/Route-Map-Debug. Nutzen Sie das konsequent: Wenn eine Route-Map-Sequenz 0 Treffer hat, matcht sie nicht – dann ist das Problem meist im match-Teil oder in der Reihenfolge.

Peering steht, aber Updates flappen: Keepalive, Holdtime, BFD und Instabilität

Wenn Sessions flappen, ist das nicht immer ein „BGP-Konfigfehler“. Häufig ist es ein Stabilitätsproblem im Underlay: Paketverlust, Interface Flapping, MTU, CPU-Spikes, oder aggressive Timer. BGP selbst ist vergleichsweise tolerant, aber wenn Holdtime zu klein ist oder Keepalives durch Queueing verzögert werden, fallen Sessions.

• Keepalive/Holdtime: Zu aggressiv eingestellt kann bei kurzzeitigem Paketverlust zum Down führen.
• BFD: Schnellere Failure Detection, aber empfindlicher gegenüber Mikroaussetzern; kann Flaps verstärken, wenn Underlay instabil ist.
• Control Plane Load: Hohe CPU/CoPP/Policing kann BGP-Pakete verzögern oder droppen.
• Route Flap Damping: Kann dazu führen, dass Prefixes trotz „Session up“ nicht propagiert werden.

Das praxiserprobte Runbook: BGP Troubleshooting in klaren Schritten

Der folgende Ablauf ist so gebaut, dass er unabhängig vom Hersteller funktioniert und schnell zu einem belastbaren Befund führt.

Schritt: Problem präzisieren

• Geht es um Session down, fehlende Prefixes oder falsche Pfadwahl?
• Ist es IPv4, IPv6 oder eine spezielle Address Family (VPNv4, EVPN)?
• Seit wann? Nach welchem Change (Policy, Filter, Provider, Key-Rollover)?

Schritt: Peering prüfen

• Session-State: Established oder hängt es in Connect/Active/Open?
• TCP/179 Reachability, TTL/Source-IP, Remote-AS, Auth.
• Flaps: Zeitmuster (Holdtime) und Underlay-Instabilität prüfen.

Schritt: Prefix Flow prüfen

• Received Routes: kommen Prefixes an (Adj-RIB-In)?
• Accepted/Installed: werden sie in Loc-RIB gewählt und in die Routing-Tabelle installiert?
• Advertised Routes: werden die gewünschten Prefixes outbound tatsächlich angekündigt?

Schritt: Policies/Route-Maps prüfen

• Inbound Filter: Prefix-List/AS-Path/Community matcht korrekt?
• Outbound Filter: genau die Prefixes werden exportiert, die exportiert werden sollen.
• Attribute: LocalPref, MED, Communities, Next-Hop – stimmen sie mit dem Design überein?

Schritt: Next-Hop und Underlay verifizieren

• Kann das Gerät den Next-Hop rekursiv erreichen (IGP/Static/VRF)?
• Gibt es MTU/Fragmentierungsprobleme oder Paketverlust?
• Bei iBGP: next-hop-self und IGP Reachability der Loopbacks prüfen.

Schritt: Verifikation und Dokumentation

• Vorher/Nachher: gleiche Tests, gleiche Prefix-Checks, gleiche Zeitfenster.
• Belege sammeln: Session-State, Anzahl Prefixes, Policy-Hit-Counter, Beispielroute (Attributes).
• Änderung dokumentieren: warum, was, Risiko, Rollback.

Typische Praxisfälle und die schnellste Diagnose

Fall: Session bleibt in Active/Connect

• Wahrscheinlich: TCP/179 geblockt, falsche Source-IP, TTL nicht passend (Multihop), Routing zum Peer fehlt.
• Beweis: Kein TCP Handshake, keine Open Messages, Logs zeigen „connection refused/timeout“.
• Fix: ACL/Firewall öffnen für TCP/179, Source/TTL korrigieren, Route zum Peer sicherstellen.

Fall: Session Established, aber 0 Prefixes

• Wahrscheinlich: Address Family nicht aktiviert, inbound policy deny, max-prefix, oder peer sendet nichts (falsches peer-group).
• Beweis: Adj-RIB-In leer, Policy-Hits auf deny steigen, max-prefix Event im Log.
• Fix: AFI/SAFI aktivieren, Policies korrigieren, max-prefix passend setzen, peer config prüfen.

Fall: Provider sieht mein Prefix nicht

• Wahrscheinlich: Prefix nicht in lokaler RIB, outbound filter blockt, oder upstream reject (RPKI/IRR/Policy).
• Beweis: „Advertised routes“ zeigt Prefix nicht, oder shows „sent“ aber upstream bestätigt nicht.
• Fix: Route/Null-Route/aggregate korrekt, outbound prefix-list anpassen, RPKI/IRR prüfen.

Fall: Traffic nimmt falschen Provider

• Wahrscheinlich: LocalPref/Communities falsch, Route-Map matcht nicht, oder IGP cost zum Next-Hop beeinflusst iBGP.
• Beweis: Best Path Attribute zeigen unerwartete Werte, Policy-Hit-Counter 0, Community fehlt.
• Fix: Policy präzisieren, Communities korrekt setzen/erhalten, LocalPref-Design konsistent umsetzen.

Outbound-Links zur Vertiefung

• RFC 4271: Border Gateway Protocol 4 (BGP4)
• RFC 7454: BGP Operations and Security
• RFC 6811: BGP Prefix Origin Validation (RPKI-OV)
• RFC 7196: Route Flap Damping in BGP

Checkliste: BGP Troubleshooting bei Peering, Prefixes und Route-Maps

• Problemklasse bestimmen: Session down, Prefixes fehlen, falscher Pfad, Flapping.
• Peering prüfen: TCP/179, Remote-AS, Source-IP, TTL (Multihop), Auth.
• FSM-Zustand interpretieren: Connect/Active vs. OpenSent vs. Established mit Resets.
• Prefixes inbound prüfen: AFI/SAFI, received/accepted, max-prefix, inbound filters.
• Prefixes outbound prüfen: Prefix muss in lokaler RIB existieren, outbound filters/aggregates/Null routes.
• Best Path prüfen: LocalPref, AS-PATH, MED, Communities, Next-Hop, IGP Cost.
• Route-Maps prüfen: match (prefix/as-path/community) und set (localpref/med/nh/community); Reihenfolge und Hit Counters.
• Next-Hop/Underlay prüfen: rekursive Erreichbarkeit, VRF-Kontext, MTU/Packetloss, iBGP next-hop-self.
• Flapping prüfen: Holdtime/Keepalive, BFD, Control-Plane-Last, Underlay-Instabilität, Damping.
• Vorher/Nachher verifizieren und dokumentieren: Beispielroute mit Attributen, Policy-Hits, Session- und Prefix-Zahlen.

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.