eBGP vs. iBGP: Design Patterns, Use Cases und Betrieb

BGP (Border Gateway Protocol) ist das zentrale Routingprotokoll für den Austausch von Routinginformationen zwischen autonomen Systemen (AS) und spielt sowohl im Internet als auch in großen Enterprise-Umgebungen eine wichtige Rolle. Dabei wird zwischen zwei grundlegenden BGP-Betriebsarten unterschieden: eBGP (External BGP) für den Austausch zwischen verschiedenen AS und iBGP (Internal BGP) innerhalb eines AS. Ein solides Verständnis der Unterschiede, Einsatzszenarien und operationalen Implikationen ist für Network Engineers essenziell, um stabile, skalierbare und sichere BGP-Architekturen zu planen und zu betreiben.

Grundlagen von eBGP

eBGP wird eingesetzt, wenn Routinginformationen zwischen zwei unterschiedlichen autonomen Systemen ausgetauscht werden. Typische Szenarien sind:

• Verbindung zu Internet Service Providern (ISP)
• Multi-Homing für Ausfallsicherheit und Lastverteilung
• Peering mit Partnerunternehmen oder Rechenzentren

Charakteristische Merkmale

• Standardmäßig werden eBGP-Sitzungen direkt zwischen Routern in unterschiedlichen AS aufgebaut.
• Next-Hop-Attribute werden beim eBGP-Update angepasst, um die Erreichbarkeit sicherzustellen.
• AS-Path-Attribute erlauben Loop-Prevention durch Überprüfung der durchlaufenen AS.

Beispiel CLI-Konfiguration

router bgp 65001
  neighbor 192.0.2.1 remote-as 65002
  neighbor 192.0.2.1 description ISP-Link
  network 10.1.0.0 mask 255.255.255.0

Grundlagen von iBGP

iBGP wird innerhalb eines autonomen Systems verwendet, um BGP-Routen, die von eBGP oder anderen iBGP-Peers empfangen wurden, an alle internen Router weiterzuleiten. Typische Einsatzszenarien sind:

• Verteilung externer Routen an alle Core- und Aggregations-Router
• Skalierbares Multi-Homed-Design innerhalb eines großen Campus oder Rechenzentrums
• Pfadsteuerung über Local Preference und andere iBGP-Attribute

Charakteristische Merkmale

• iBGP-Router müssen direkt oder über Route Reflectors verbunden sein, da Routen ohne Loop-Prevention nicht weiter propagiert werden.
• Next-Hop bleibt standardmäßig unverändert, da der Pfad innerhalb desselben AS verbleibt.
• Local Preference wird genutzt, um die Pfadpräferenz innerhalb des AS zu steuern.

Beispiel CLI-Konfiguration mit Route Reflector

router bgp 65001
  neighbor 10.1.1.2 remote-as 65001
  neighbor 10.1.1.2 route-reflector-client

eBGP vs. iBGP: Vergleich und Designentscheidungen

Die Entscheidung, ob eBGP oder iBGP verwendet wird, hängt vom Einsatzszenario ab. Wichtige Unterschiede:

• AS-Grenze: eBGP für zwischen AS, iBGP innerhalb AS
• Next-Hop-Handling: eBGP passt den Next-Hop, iBGP nicht
• Loop Prevention: eBGP prüft AS-Path, iBGP benötigt entweder Full Mesh oder Route Reflectors
• Policy-Kontrolle: eBGP häufig für ein-/ausgehende Filter, iBGP für interne Traffic-Steuerung

Design Patterns

• eBGP-Peering mit jedem Provider für Multi-Homing und Redundanz
• iBGP Full Mesh in kleinen AS (< 10 Router)
• Route Reflector Hierarchie in größeren AS zur Reduzierung der Mesh-Komplexität
• Policy-basierte Pfadsteuerung über Local Preference und MED

Operational Considerations

Beim Betrieb von BGP müssen folgende Punkte beachtet werden:

• Stabilität der Peers: Keepalive-Intervalle und Hold-Timer richtig setzen
• Monitoring: Überwachung von BGP-Session-Status, Update-Raten und Pfadänderungen
• Failover-Szenarien: eBGP-Sessions sollten redundante Pfade abbilden, iBGP-Pfade müssen konsistent verteilt sein
• Security: Prefix-Filters, AS-Path-Filters und ggf. RPKI zur Absicherung externer Routen

Fehlerquellen

• Fehlende Route Reflector-Konfiguration im iBGP führt zu Routing Loops
• Unpassende Next-Hop-Attribute bei eBGP verhindern die Erreichbarkeit von Prefixes
• Fehlerhafte Filter oder Policies blockieren gewünschte Routen

Best Practices für Enterprise

• eBGP für alle externen Verbindungen, iBGP für interne Distribution
• Skalierbare iBGP-Architektur mit Route Reflectors in großen Netzwerken
• Klare Policy-Definitionen für eingehenden und ausgehenden Traffic
• Regelmäßige Audits der BGP-Routen und Peering-States
• Monitoring und Alerts für Session-Down, Prefix-Veränderungen und anomalous AS-Paths

Fazit für IT-Manager und Architekten

Ein solides Verständnis der Unterschiede zwischen eBGP und iBGP ermöglicht es IT-Managern und Network Architects, die richtigen Designentscheidungen zu treffen, Redundanz sicherzustellen, Traffic effizient zu steuern und Risiken zu minimieren. Die operative Verantwortung kann dabei zwischen NOC/NetOps und strategischem Netzwerkdesign klar getrennt bleiben, während die Grundlagen für sichere, skalierbare BGP-Implementierungen gewährleistet sind.

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.