iBGP vs. eBGP: Unterschiede verständlich erklärt

iBGP und eBGP sind zwei Betriebsarten desselben Protokolls (BGP), unterscheiden sich aber fundamental im Einsatz: eBGP verbindet unterschiedliche autonome Systeme (z. B. Unternehmen ↔ Provider), iBGP verteilt BGP-Routen innerhalb eines autonomen Systems (z. B. Edge ↔ Core). Wer die Unterschiede kennt, versteht typische BGP-Designs, vermeidet Next-Hop-Fallen und kann Internetanbindungen sicherer betreiben.

Grunddefinition: Was bedeutet iBGP und eBGP?

Der Unterschied wird allein über die ASNs definiert: Sind lokale ASN und Neighbor-ASN verschieden, ist es eBGP. Sind sie gleich, ist es iBGP.

$\text{eBGP:} \mathrm{ASN} \ne \mathrm{ASN} \text{iBGP:} \mathrm{ASN} = \mathrm{ASN}$

Typische Einsatzszenarien in der Praxis

eBGP ist fast immer am Edge zum Provider oder zu Partnernetzen. iBGP nutzt du im eigenen Netz, um externe (oder interne) Präfixe zwischen mehreren Routern zu verteilen, ohne alles in ein IGP zu drücken.

• eBGP: Internet-Transit, Peering, Cloud-Provider, Partner/Extranet
• iBGP: Verteilung von Internet-Routen im eigenen AS (Edge ↔ Core)
• iBGP: Data Center/Backbone-Designs (z. B. Route Reflectors)

Session-Aufbau: Was ist gleich, was ist anders?

Beide nutzen TCP/179 und ähnliche States (Idle, Active, Established). Unterschiede entstehen durch Standardverhalten: eBGP erwartet oft direkte Nachbarn, iBGP läuft häufig über mehrere Hops im eigenen Netz.

• Beide: TCP/179, Keepalives, Updates, Best-Path-Selection
• eBGP: häufig direkt benachbart (1 Hop), Provider-Edge
• iBGP: häufig multi-hop (Edge ↔ RR/Core über IGP)

BGP-Session prüfen

Router# show ip bgp summary
Router# show ip bgp neighbors

TTL und eBGP Multihop: warum eBGP oft „direkt“ ist

In vielen Designs ist eBGP standardmäßig für direkt verbundene Nachbarn gedacht. Wenn dein eBGP-Neighbor nicht direkt am Interface hängt, musst du eBGP Multihop konfigurieren.

eBGP Multihop konfigurieren (Beispielprinzip)

Router# configure terminal
Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.1 remote-as 64500
Router(config-router)# neighbor 203.0.113.1 ebgp-multihop 2
Router(config-router)# end

Next-Hop Verhalten: der wichtigste Stolperstein

Das Next-Hop-Attribut ist in iBGP-Designs der häufigste Grund für „BGP-Routen da, aber Traffic geht nicht“. eBGP setzt Next-Hop typischerweise auf den eBGP-Nachbarn. iBGP verändert Next-Hop standardmäßig nicht – dadurch muss der Next-Hop im IGP erreichbar sein.

• eBGP: Next-Hop wird typischerweise auf den eBGP-Nachbarn gesetzt
• iBGP: Next-Hop bleibt oft unverändert (muss intern erreichbar sein)
• Lösung im iBGP-Core: IGP/Static zum Next-Hop oder next-hop-self

Next-Hop in der Praxis prüfen

Router# show ip bgp 203.0.113.0
Router# show ip route <next-hop-ip>

Fix: next-hop-self im iBGP (typisch am Edge/RR)

Router# configure terminal
Router(config)# router bgp 65001
Router(config-router)# neighbor 10.255.255.2 remote-as 65001
Router(config-router)# neighbor 10.255.255.2 next-hop-self
Router(config-router)# end

Route Propagation: iBGP ist nicht wie ein IGP

iBGP hat eine zentrale Regel: Ein iBGP-gelerntes Präfix wird nicht automatisch an andere iBGP-Nachbarn weitergegeben. Ohne Design (Full Mesh oder Route Reflector) „stoppen“ Routen im AS.

• iBGP-to-iBGP Weitergabe: standardmäßig nein
• Skalierung: Full Mesh oder Route Reflector (RR)
• eBGP Routen können innerhalb des AS über iBGP verteilt werden

Full Mesh vs. Route Reflector (Merker)

• Klein (wenige Router): iBGP Full Mesh möglich
• Größer: Route Reflector einsetzen, sonst explodiert die Sessionzahl

Administrative Distance: Priorität im Routing

Die Standard-AD unterscheidet sich: eBGP ist meist „vertrauenswürdiger“ als iBGP und wird daher eher in die Routing-Tabelle installiert, wenn beide denselben Präfix anbieten.

• eBGP: typischerweise AD 20
• iBGP: typischerweise AD 200

AD/Metric in der Routing-Tabelle erkennen

Router# show ip route bgp
Router# show ip route 203.0.113.0

Best-Path-Policy: Local Preference vs. AS-PATH (praxisnah)

Im eigenen AS steuerst du Outbound-Pfade bevorzugt mit LOCAL_PREFERENCE (iBGP-relevant). Gegenüber Providern/Peers beeinflusst du Inbound-Pfade häufig über AS-PATH Prepending oder Communities (eBGP-relevant).

• Outbound (dein AS): LOCAL_PREF (höher gewinnt)
• Inbound (von außen zu dir): AS-PATH Prepend/Communities (designabhängig)
• MED: oft zwischen gleichen Provider-AS relevant

Local Preference setzen (Prinzip via Route-Map)

Router# configure terminal
Router(config)# route-map SET-LP permit 10
Router(config-route-map)# set local-preference 200
Router(config-route-map)# end

Typische Fehlerbilder und schnelle Diagnosen

Die Unterschiede zeigen sich vor allem im Troubleshooting: Bei eBGP scheitert es oft an TCP/179, Routing zum Neighbor oder TTL. Bei iBGP ist es häufig Next-Hop oder fehlende Route-Propagation.

eBGP typische Ursachen

• Neighbor nicht direkt erreichbar, aber kein ebgp-multihop
• ACL/Firewall blockiert TCP/179
• Falsche ASN am Neighbor

iBGP typische Ursachen

• Kein Full Mesh/kein RR → Routen werden nicht weitergegeben
• Next-Hop unreachable → Routen nicht nutzbar
• IGP fehlt (Loopback/Router-ID nicht erreichbar)

Quick-Checks in Befehlen

Router# show ip bgp summary
Router# show ip bgp neighbors
Router# show ip bgp
Router# show ip route
Router# show ip route bgp

Mini-Beispiele: eBGP und iBGP Konfigurationsmuster

Diese Blöcke zeigen die typische Grundform. In produktiven Netzen gehören Filter (Prefix-Lists, Max-Prefix) immer dazu.

eBGP zum Provider (Minimalprinzip)

router bgp 65001
 neighbor 203.0.113.1 remote-as 64500
 network 198.51.100.0 mask 255.255.255.0

iBGP im eigenen AS (Minimalprinzip)

router bgp 65001
 neighbor 10.255.255.2 remote-as 65001
 neighbor 10.255.255.2 update-source loopback0
 neighbor 10.255.255.2 next-hop-self

Best Practices: stabile iBGP/eBGP Designs

Mit wenigen Standards vermeidest du die typischen Fallstricke und bekommst ein robustes Internet-Edge-Design.

• eBGP: Prefix-Filter + maximum-prefix immer setzen
• iBGP: Loopbacks als Neighbor-Endpunkte + IGP-Erreichbarkeit sicherstellen
• iBGP: Skalierung über Route Reflectors statt Full Mesh (ab mittlerer Größe)
• Next-Hop-Design bewusst planen (next-hop-self wo nötig)
• Verifikation nach Changes: Summary, Best-Path, Routing-Table prüfen

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.