BGP Best Path im Detail: Edge-Cases, die in der Praxis wirklich zählen

„BGP Best Path“ klingt nach einer festen Reihenfolge, aber in der Praxis entscheiden Edge-Cases: iBGP vs. eBGP, inkonsistente Local Preference, fehlendes Next-Hop-Tracking, MED-Interpretation, Multipath-Settings und die Frage, ob Routen überhaupt als „valid“ gelten. Viele „BGP routet falsch“-Tickets sind keine BGP-Bugs, sondern ein nicht verstandener Tie-Breaker oder ein Attribut, das unbemerkt überschrieben wurde. Dieses Tutorial erklärt die Best-Path-Logik auf Cisco mit Fokus auf die Fälle, die im Enterprise- und ISP-Edge wirklich zählen.

Best Path als Pipeline: Erst Validität, dann Attribute

Bevor Cisco überhaupt Attribute vergleicht, muss ein Pfad „usable“ sein: Next-Hop muss erreichbar sein, die Route darf nicht durch Policy ausgeschlossen sein und sie muss in der BGP-Tabelle korrekt stehen. Viele Edge-Cases sind genau hier.

• Next-Hop erreichbar? (IGP/Static Route vorhanden)
• Policy erlaubt? (Prefix-List/Route-Map, RPKI/Filter)
• Route ist nicht „stale“ oder suppressed/damped

Erste Checks

show ip bgp <prefix>
show ip route <next-hop>
show ip cef <next-hop> detail

Die Attribute, die in der Praxis am häufigsten entscheiden

In Enterprise-Edges sind es meist wenige Attribute, die wirklich zählen: Local Preference (Outbound), AS-Path (Inbound), Origin, MED (nur in bestimmten Szenarien), und anschließend IGP-Metrik zum Next-Hop.

• Local Preference: wichtigste interne Exit-Steuerung
• AS-Path: wichtigster Inbound-Hebel (Prepending) – wenn Provider es respektiert
• MED: nur zwischen Pfaden desselben Nachbar-AS wirklich sinnvoll
• IGP-Metrik zum Next-Hop: entscheidet häufig bei iBGP-Edges

Edge-Case 1: Local Preference wird „irgendwo“ überschrieben

Local Preference wird nur innerhalb deines AS ausgewertet. Der häufigste Fehler ist, dass ein Route-Map am falschen Neighbor oder in der falschen Richtung LocalPref setzt und damit den Exit unbemerkt umdreht.

Symptom

• Traffic geht plötzlich über den falschen ISP
• Best Path wechselt ohne erkennbare AS-Path-Änderung

Check

show ip bgp <prefix>
show route-map
show ip bgp neighbors <peer> received-routes

Edge-Case 2: Next-Hop unreachable – Route ist da, aber nicht nutzbar

Gerade bei iBGP ist Next-Hop Reachability entscheidend: Der Next-Hop wird oft nicht verändert, daher muss das IGP den Next-Hop erreichen können. Wenn nicht, wirkt es wie „BGP hat Route, aber kein Traffic“.

Check

show ip bgp <prefix>
show ip route <next-hop>
show ip cef <next-hop> detail

Typische Ursachen

• IGP/Static für Next-Hop fehlt
• VRF/Management-VRF verwechselt
• Policy blockt Next-Hop-Prefix (z. B. summarization/leak)

Edge-Case 3: iBGP vs. eBGP – warum eBGP fast immer gewinnt

Wenn mehrere Pfade ansonsten ähnlich sind, wird eBGP gegenüber iBGP bevorzugt. Das ist in Multi-Homing-Designs relevant, wenn du „lokale“ iBGP-Pfade gegen direkte eBGP-Pfade vergleichen willst.

Merker

$\text{eBGP} > \text{iBGP} \text{(bei sonst gleichen Kriterien)}$

Edge-Case 4: MED – oft missverstanden und falsch erwartet

MED ist ein Hinweis an den Nachbarn, welchen Eingang er bevorzugen soll. Cisco vergleicht MED standardmäßig nur zwischen Pfaden aus demselben Nachbar-AS. In der Praxis führt das zu Verwirrung: Man setzt MED bei zwei unterschiedlichen ISPs und erwartet Effekt – ohne Wirkung.

Symptom

• MED gesetzt, aber Best Path ändert sich nicht
• Inbound TE wirkt „random“

Check

show ip bgp <prefix>
show running-config | section router bgp

Edge-Case 5: IGP-Metrik zum Next-Hop dominiert in iBGP-Topologien

In iBGP-Designs mit mehreren Route Reflectors oder mehreren Edge-Routern ist die „nächste“ Entscheidung häufig nicht mehr ein BGP-Attribut, sondern die IGP-Metrik zum BGP Next-Hop. Damit wird BGP indirekt durch IGP-Kosten gesteuert.

Symptom

• Best Path hängt an OSPF/IS-IS Kosten
• Nach IGP-Cost-Change wechselt BGP-Ausgang

Check

show ip bgp <prefix>
show ip route <next-hop>
show ip ospf route <next-hop>
show isis route <next-hop>

Edge-Case 6: Multipath/ECMP – „Warum nutze ich nicht beide?“

Ohne Multipath nutzt BGP pro Prefix nur einen Best Path. Wenn du Lastverteilung willst, müssen Multipath-Settings passen, und die Pfade müssen ausreichend „gleich“ sein (je nach Policy). Sonst bleibt es bei einem Pfad.

Check

show ip bgp <prefix>
show running-config | section router bgp

Typische Stellschrauben

• maximum-paths (eBGP/iBGP je nach Design)
• AS-Path „gleich genug“ für Multipath (Policy abhängig)
• Next-Hop und IGP-Kosten dürfen nicht zu stark abweichen

Edge-Case 7: Route Flaps, Dampening und „stale“ Pfade

Wenn ein Prefix flapped, können Pfade zeitweise unterdrückt werden (Dampening) oder als „stale“ gelten (je nach Mechanismus). Das führt dazu, dass ein vermeintlich besserer Pfad nicht ausgewählt wird – obwohl Attribute eigentlich dafür sprechen.

Check

show ip bgp <prefix>
show logging | include BGP|DAMP|SUPPRESSED

Edge-Case 8: Policy schlägt Best-Path-Logik

Eine Route kann „best“ sein, aber durch Policy nicht installiert oder nicht exportiert werden. In der Praxis sind Route-Maps, Prefix-Lists und Communities der häufigste Grund für „BGP sieht Route, aber Routing-Tabelle nicht“.

Check

show ip bgp <prefix>
show ip route <prefix>
show route-map
show ip prefix-list

Best Path nachvollziehen: So liest du show ip bgp richtig

Du willst pro Prefix sehen: welche Pfade existieren, welcher ist „best“ und welche Attribute unterscheiden sich. Cisco markiert den Best Path typischerweise in der Ausgabe. Entscheidend ist, alle Kandidaten nebeneinander zu vergleichen.

Praktische Befehle

show ip bgp <prefix>
show ip bgp neighbors <peer> received-routes
show ip bgp neighbors <peer> advertised-routes

Operational Best Practices: Best-Path-Edge-Cases vermeiden

Viele Edge-Cases lassen sich durch saubere Standards verhindern: eindeutige LocalPref-Policy, konsistente Communities, klare Next-Hop-Strategie und Guardrails wie Prefix-Limits.

• LocalPref zentral definieren (keine „zufälligen“ Overrides)
• Next-Hop Reachability im IGP absichern (Summaries/Leaks bewusst)
• MED nur dort einsetzen, wo es wirkt (gleicher Nachbar-AS)
• Multipath nur aktivieren, wenn Pfade wirklich gleichwertig sind
• Prefix-Limits und Monitoring gegen Route-Leaks

Quick-Runbook: Best Path Edge-Case in 5 Minuten debuggen

Diese Sequenz führt dich vom Symptom zur Ursache: usable? Policy? Attribute? IGP Next-Hop? Danach weißt du, welcher Tie-Breaker wirklich entschieden hat.

show ip bgp <prefix>
show ip route <next-hop>
show ip cef <next-hop> detail
show route-map
show ip prefix-list
show ip bgp neighbors <peer> received-routes
show logging | include BGP|DAMP|SUPPRESSED

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.