BGP in Hybrid Cloud: Was DevOps zwingend verstehen muss

BGP in Hybrid Cloud ist das unsichtbare Rückgrat vieler produktiver Plattformen – und gleichzeitig eine der häufigsten Ursachen für schwer erklärbare Netzwerk- und Applikationsprobleme, sobald On-Premises und Cloud wirklich „zusammenarbeiten“ sollen. In DevOps- und Plattformteams wird Routing oft als „Netzwerk-Thema“ abgestempelt. In der Realität entscheidet BGP (Border Gateway Protocol) darüber, ob Services erreichbar sind, ob Datenpfade stabil bleiben, ob Failover funktioniert und ob Security-Kontrollen wie Firewalls oder Proxies überhaupt im Pfad liegen. Gerade Hybrid-Architekturen – etwa Rechenzentrum plus Public Cloud, mehrere Clouds oder getrennte Accounts/Subscriptions – erzeugen dynamische Routenlandschaften: Präfixe werden angekündigt, zurückgezogen, bevorzugt oder aus Versehen geleakt. Wenn DevOps nicht versteht, wie BGP Pfade auswählt und welche Betriebsmechaniken (Konvergenz, Route Filtering, Communities, Route Reflection) dahinterstehen, entstehen Incidents, die sich wie „zufällige Timeouts“ oder „flaky DNS“ anfühlen, tatsächlich aber reine Layer-3-Probleme sind. Dieser Artikel erklärt praxisnah, was DevOps in Hybrid Cloud über BGP zwingend verstehen muss – von den Kernbegriffen über typische Fehlerbilder bis zu operativen Guardrails, mit denen sich Ausfälle und Risiko-Ballungen vermeiden lassen.

Warum BGP in Hybrid Cloud so zentral ist

Hybrid Cloud bedeutet: Es gibt mindestens zwei Routing-Domänen, die miteinander verbunden werden müssen. Das kann ein Rechenzentrum mit einer Cloud-VPC/VNet sein (klassisch), aber auch mehrere Cloud-Regionen oder ein Hub-and-Spoke-Netz über mehrere Accounts hinweg. BGP ist dabei häufig das Protokoll, das Präfixe dynamisch austauscht: Welche internen Netze sind wo erreichbar, und über welchen Pfad?

• Dynamik statt statischer Routen: BGP reagiert auf Änderungen (Link down, Wartung, Kapazitätswechsel) ohne manuelles Umkonfigurieren vieler Router.
• Policy-basiertes Routing: BGP wählt nicht „den kürzesten Weg“, sondern den durch Policies „besten“ Weg.
• Skalierung: In großen Umgebungen ist BGP das Werkzeug, um Tausende Präfixe kontrolliert zu verteilen.

Die normative Grundlage ist RFC 4271 (BGP-4). Für IP-Routing-Grundlagen lohnt sich zusätzlich RFC 791 (IPv4) bzw. RFC 8200 (IPv6).

Die wichtigsten BGP-Begriffe, die DevOps kennen sollte

Sie müssen kein Netzwerkingenieur werden, aber ohne ein paar Kernbegriffe ist Hybrid-Betrieb ein Blindflug. Die folgenden Konzepte sind in Postmortems und Incidents besonders relevant.

• AS (Autonomous System) und ASN: Eine Routing-Domäne mit eigener Policy. In Hybrid-Setups haben On-Prem und Cloud-Seite oft unterschiedliche ASNs.
• eBGP vs. iBGP: eBGP verbindet verschiedene AS (z. B. On-Prem ↔ Cloud Edge), iBGP verteilt Routen innerhalb eines AS (z. B. innerhalb des Datacenters).
• Präfix: Ein Netz, das angekündigt wird (z. B. 10.10.0.0/16 oder ein IPv6-/56). Präfixdesign ist Grundlage für Segmentierung und Blast Radius.
• Next Hop: Der nächste Router/Gateway, über den ein Präfix erreichbar ist.
• Attributes: Metadaten, die Pfadwahl steuern (z. B. Local Preference, AS_PATH, MED).
• Communities: Tags, mit denen Sie Routing-Policies skalieren (z. B. „dieses Präfix nur intern“, „dieser Pfad depräferieren“). Communities werden in RFC 1997 beschrieben.

Wie BGP Pfade auswählt: Das Minimum an „Best Path“-Logik

BGP hat eine definierte Entscheidungslogik, aber die exakte Reihenfolge kann je nach Router-Implementierung variieren. Für DevOps ist wichtig: BGP ist policygetrieben. Wenn Sie die Policies nicht kennen, wirken Traffic-Shifts wie Zufall. Typischerweise wird zuerst innerhalb eines AS die „lokale“ Präferenz (Local Preference) betrachtet, danach andere Attribute wie AS_PATH-Länge oder MED.

Eine hilfreiche Denkformel für die häufigste Praxis (stark vereinfacht) ist: „Policy schlägt Topologie“. Das kann man als Gewichtung ausdrücken: Ein höherer Policy-Score gewinnt, selbst wenn der Pfad objektiv länger ist.

$\mathrm{Score}=w{p}_{\mathrm{olicy}}\times P_{\mathrm{localpref}}+w{p}_{\mathrm{ath}}\times 1/1+L_{\mathrm{aspath}}$

Die Formel ist keine Spezifikation, sondern ein Betriebsmodell: Local Preference (Policy) dominiert häufig, während AS_PATH (Topologie) eher als sekundäres Signal wirkt.

Hybrid-Cloud-Szenarien: Wo BGP in DevOps-Alltag „auftaucht“

Viele Plattformprobleme sind Hybrid-Probleme, auch wenn sie zunächst wie Application Bugs aussehen. Hier sind die häufigsten Stellen, an denen BGP für DevOps relevant wird.

• Private Connectivity: On-Prem ↔ Cloud über Direct Connect/ExpressRoute/Interconnect – BGP tauscht Routen für private Netze aus.
• Shared Services: zentrale DNS-Resolver, Logging, Monitoring oder Artifact-Registries sind oft über Hybrid-Pfade erreichbar.
• Multi-VPC/VNet-Hubs: Transit-/Hub-Routing verteilt Präfixe an viele Spokes; BGP kann dabei der „Sprachkanal“ sein.
• DR und Failover: Region-Failover oder Datacenter-Failover basiert häufig auf Route Withdrawal oder Depräferenzierung.
• Security Inspection: Wenn Traffic über Firewalls/Proxies muss, hängt das von Routing-Policies ab – BGP macht oder bricht die Security-Architektur.

Provider-nahe Dokumentationen sind je nach Cloud sehr nützlich, weil sie konkrete BGP-Betriebsgrenzen und Empfehlungen nennen: AWS Direct Connect Routing und BGP, Azure ExpressRoute Routing und Google Cloud Interconnect Routing.

Typische Fehlerbilder: So sieht BGP-Problematik in SRE- und DevOps-Symptomen aus

In der Praxis kommt selten jemand mit „BGP ist kaputt“. Stattdessen sehen Teams Latenzspitzen, Timeouts oder Teil-Erreichbarkeit. Die folgenden Muster sind besonders häufig und lassen sich mit BGP-Denke schneller entwirren.

Teil-Ausfälle: Nur ein Teil der Subnetze oder Services ist betroffen

Wenn nur bestimmte Netze nicht erreichbar sind, obwohl „die Verbindung steht“, ist das ein Klassiker für fehlende oder gefilterte Präfixe. Beispiele:

• Neue Subnetze: Ein neues Pod-CIDR oder ein neues VPC-Präfix wurde nicht ins BGP exportiert.
• Zu striktes Route Filtering: Prefix-Lists oder Route-Maps blocken versehentlich ein Präfix.
• Max-Prefix-Limits: Ein Peer akzeptiert nur eine bestimmte Anzahl Präfixe; danach wird die Session gedrosselt oder geschlossen.

Asymmetrisches Routing: Hinweg und Rückweg sind unterschiedlich

Asymmetrisches Routing ist in Hybrid-Cloud besonders gefährlich, wenn stateful Firewalls, NAT oder Connection Tracking im Pfad liegen. Der Hinweg geht über Firewall A, der Rückweg über Firewall B – die Session wirkt „neu“, Pakete werden gedroppt, und Applikationen melden Timeouts. Typische Ursachen:

• Unterschiedliche Local Preference: ein Pfad wird outbound bevorzugt, inbound aber nicht.
• Ungleiche Route Propagation: nur ein Teil der Edge-Router lernt bestimmte Routen.
• Failover in einem Teilpfad: ein Link fällt um, aber nicht alle Router konvergieren gleich schnell.

„Flaky“ Connectivity: Kurze Unterbrechungen bei Changes oder Link-Events

BGP ist dynamisch, aber nicht instant. Konvergenz benötigt Zeit, und manche Mechanismen sind optional. Wenn Sie in Deployments oder Wartungen „kurze Netzstörungen“ sehen, liegt das oft an Re-Konvergenz oder an Session-Resets. Besonders relevant sind:

• BFD für schnelles Failure Detection: BFD erkennt Link-/Pfadausfälle schneller als reine BGP-Timer. Referenz: RFC 5880 (BFD).
• Graceful Restart: kann Routing stabiler halten, birgt aber Risiken, wenn „scheinbar lebende“ Routen weiter genutzt werden. Referenz: RFC 4724.

Route Leaks und unerwünschte Erreichbarkeit: Wenn Segmentierung „plötzlich“ nicht mehr stimmt

Ein Route Leak bedeutet: Präfixe werden weitergegeben, obwohl sie es nicht sollen. Das kann Security-Grenzen aufheben, Data Exfiltration vereinfachen oder ungewollte Pfade durch ungeprüfte Netze öffnen. In Hybrid-Setups passiert das häufig durch fehlerhafte Route-Maps, falsch gesetzte Communities oder unklare Ownership zwischen Teams.

• Signal: neue Erreichbarkeit zwischen Umgebungen (z. B. Dev ↔ Prod), ohne dass Security-Regeln geändert wurden.
• Ursache: Export-Policy erlaubt zu viel, oder Import-Policy filtert zu wenig.
• Mitigation: Default-Deny bei Route-Import/Export, explizite Prefix-Listen, Community-basierte Freigaben.

Was DevOps beim Design verstehen muss: Präfix- und Policy-Strategie

Viele BGP-Probleme entstehen nicht im Incident, sondern im Design: IP-Planung, Präfixgrößen, Export-Policies und die Frage, wie Segmentierung technisch erzwungen wird. DevOps sollte hier mindestens die Leitplanken kennen, sonst werden Plattformänderungen zu Netzrisiken.

Präfixdesign: Blast Radius und Wachstum steuern

Je größer ein angekündigtes Präfix, desto größer der Blast Radius. Wenn ein /16 „ausfällt“ oder falsch geroutet wird, betrifft es mehr Workloads als bei sauber geshardeten Präfixen. Gleichzeitig darf die Präfixanzahl nicht unkontrolliert wachsen (Max-Prefix, Operational Load). Die Kunst ist ein bewusstes Mittelmaß.

• Hierarchie: Präfixe nach Region/Umgebung/Domain strukturieren, damit Policies einfach bleiben.
• Zusammenfassungen (Aggregation): wo sinnvoll, Routen aggregieren, um die Präfixanzahl zu reduzieren.
• Keine Overlaps: Overlapping CIDRs sind der Schnellweg zu NAT-Workarounds und Debugging-Hölle.

CIDR-Grundlagen sind in RFC 4632 beschrieben; private IPv4-Bereiche in RFC 1918.

Policy-Design: Communities als skalierbares Steuerinstrument

Wenn Sie 5 VPCs haben, können Sie Policies „per Hand“ pflegen. Wenn Sie 50 oder 200 haben, brauchen Sie eine skalierbare Abstraktion. Communities sind dafür ein Standardwerkzeug: Präfixe werden mit Tags versehen, und Router-Policies entscheiden anhand dieser Tags, ob und wohin exportiert wird. Das reduziert manuelle Sonderregeln und verhindert, dass jede neue Verbindung ein neues Routing-Unikat wird.

• Tagging-Standard: definieren Sie Communities wie „prod“, „dev“, „shared-services“, „internet-egress“, „no-export“.
• Guardrails: ohne richtige Community wird nicht exportiert (Default-Deny).
• Dokumentation: Communities sind ein „Vertrag“ zwischen Teams – ohne klare Definition werden sie gefährlich.

Betrieb: Die wichtigsten Runbook-Fragen bei Hybrid-BGP-Problemen

Bei Incidents hilft eine wiederholbare Checkliste. DevOps muss nicht alle Routerkommandos kennen, aber die richtigen Fragen stellen und die richtigen Signale einfordern können.

• Ist die BGP-Session up? Wenn nicht: Auth, ACLs, Link, BFD, Provider-Status.
• Welche Präfixe werden importiert/exportiert? Vergleich „soll“ vs. „ist“, inklusive Filter/Policy.
• Hat sich der Best Path geändert? Localpref/AS_PATH/MED-Änderungen, Community-Änderungen, Route Reflection.
• Gibt es ein Max-Prefix-Event? Wurden zu viele Routen angekündigt (z. B. neue Pod-CIDRs)?
• Ist der Pfad symmetrisch? Hin- und Rückweg über gleiche Security-Domänen?
• Konvergenzzeit: Wie schnell wird bei Link-Events umgeroutet? Gibt es Graceful Restart-Effekte?

Observability: Welche Telemetrie BGP in Hybrid Cloud „beweisbar“ macht

Hybrid-BGP muss sichtbar sein, sonst ist jedes Problem ein Ratespiel. Gute Observability verbindet drei Ebenen: Routingzustand, Pfad-Performance und Applikationssymptome.

• Routingzustand: Session-Status, Anzahl empfangener/gesendeter Präfixe, Policy-Drops, Flaps, Konvergenzereignisse.
• Pfad-Performance: RTT, Paketverlust-Indikatoren, Retransmits, Jitter zwischen Domänen.
• Applikationssicht: Connect-Time, TLS-Handshake, Error Rates getrennt nach Zielnetz (On-Prem/Cloud/Partner).

Für die saubere Verknüpfung aus Sicht von Services sind standardisierte Telemetrie-Ansätze wie OpenTelemetry hilfreich, insbesondere wenn Sie Netzwerkdimensionen (Zielpräfix, Region, Path-Class) konsequent taggen.

Sicherer Change-Prozess: Warum BGP-Konfiguration wie Code behandelt werden sollte

Die meisten kritischen Routingvorfälle sind Change-getrieben: eine Route-Map, eine Prefix-List, ein Community-Tag, ein neues Subnetz. Deshalb sollten Plattformteams BGP-nahe Änderungen mit ähnlicher Strenge behandeln wie Production-Deployments.

• Versionierung: Routing-Policies als Code, mit Review, Tests und Rollback.
• Staging/Canary: Änderungen zuerst in einer begrenzten Domäne ausrollen (z. B. eine Region, ein Edge-Peer).
• Automatisierte Validierung: Prefix-Count-Checks, „no-overlap“-Regeln, erlaubte Community-Mengen.
• Change-Annotation: Routing-Changes als Events in Monitoring, damit Korrelation möglich ist.

Provider- und Hybrid-Besonderheiten: Was in der Cloud anders ist als On-Prem

In der Public Cloud ist BGP häufig „partly managed“: Sie steuern Parameter und Policies innerhalb definierter Grenzen, aber nicht die gesamte Underlay-Topologie. Außerdem sind manche Limits und Mechaniken providerabhängig.

• Limits sind real: Max-Prefix, BGP-Timer, Anzahl Sessions, unterstützte Communities und Route-Propagation unterscheiden sich.
• Multi-Link-Design: Redundanz über zwei physische/virtuelle Links ist Standard, aber nur wirksam mit sauberer Pfadpräferenz.
• Failover testen: Dokumente versprechen viel; operative Realität zeigt sich erst in geplanten Failure-Tests.

Für konkrete Betriebsdetails sind die offiziellen Provider-Dokumentationen die verlässlichste Quelle: AWS Direct Connect BGP, Azure ExpressRoute Routing, Google Cloud Interconnect Routing.

Weiterführende Ressourcen

• RFC 4271: BGP-4 – Spezifikation und Grundmechaniken
• RFC 1997: BGP Communities – skalierbares Policy-Tagging
• RFC 5880: BFD – schnelle Fehlererkennung für Routingpfade
• RFC 4724: Graceful Restart – Stabilität vs. Risiko bei Control-Plane-Events
• AWS Direct Connect: Routing und BGP in Hybrid-Setups
• Azure ExpressRoute: BGP-Routing und Pfadpräferenz
• Google Cloud Interconnect: Routingkonzepte und BGP
• OpenTelemetry: Observability-Standard für Pfad- und Latenzdiagnose

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.