Site icon bintorosoft.com

BGP-CNI (Calico etc.): Häufige Failure Modes

Red Snapper

Young man engineer making program analyses

BGP-CNI (Calico etc.): Häufige Failure Modes ist ein Thema, das in Kubernetes-Umgebungen oft erst dann Aufmerksamkeit bekommt, wenn „plötzlich“ Pod-to-Pod-Verbindungen abbrechen, einzelne Nodes isoliert wirken oder externe Systeme nur noch sporadisch Pod-Netze erreichen. Der Grund: Ein BGP-basiertes CNI ersetzt klassische Overlay-Mechanismen (oder ergänzt sie) durch dynamisches Routing. Statt Pakete über VXLAN/IP-in-IP zu kapseln, werden Pod- und Service-Präfixe als Routen angekündigt. Das kann Latenz reduzieren, Debugging vereinfachen und die Netzwerktopologie „ehrlicher“ machen – aber es bringt auch typische Routing-Risiken mit sich: Peering-Probleme, Policy-Fehlkonfigurationen, Route Leaks, asymmetrische Pfade, RPF-Filter, ECMP-Effekte, Skalierungsgrenzen von Full-Mesh-Topologien und eine Fehlerklasse, die sich in Kubernetes-Symptomen tarnt (Timeouts, sporadische Retries, DNS-„Flakiness“, unerklärliche 5xx). Wer BGP im CNI einsetzt, sollte deshalb die häufigsten Failure Modes kennen und so gestalten, dass einzelne Störungen nicht den gesamten Cluster destabilisieren. Dieser Artikel erklärt praxisnah, wie BGP-CNIs typischerweise arbeiten, welche Fehlerbilder am häufigsten sind, wie Sie sie strukturiert eingrenzen und welche Mitigation-Muster sich in Produktion bewährt haben.

Was „BGP-CNI“ in Kubernetes konkret bedeutet

Ein BGP-basiertes CNI nutzt Border Gateway Protocol (BGP), um Netzwerkreichweiten dynamisch zu verteilen. In der Praxis kündigt der Node (oder ein Routing-Agent auf dem Node) Routen an, die zu Pods oder Pod-CIDRs führen. Upstream-Router oder andere Nodes lernen diese Routen und können Traffic direkt zum richtigen Node schicken. Das kann als reines Node-to-Node-Routing funktionieren (Node-Mesh), als Peering zu Top-of-Rack/Leaf-Spine, oder über Route Reflectors, um Skalierung zu verbessern.

Als Orientierung zu Calico und BGP-Konzepten sind die Projekt-Dokumentationen nützlich: Calico BGP Networking sowie für BIRD (häufiger Routing-Daemon im Umfeld) BIRD Routing Daemon.

Warum BGP-Failure Modes in Kubernetes so schwer zu erkennen sind

Viele BGP-Probleme sind nicht „hart“ (alles down), sondern „weich“: Einige Routen fehlen, nur ein Teil der Nodes lernt Updates, oder ECMP verteilt Traffic ungünstig. Kubernetes zeigt dann oft Sekundärsymptome:

Das zentrale Muster: BGP ist Routing-Truth. Wenn die Route fehlt oder falsch ist, kann die Anwendung noch so korrekt sein – Pakete gehen trotzdem ins Leere.

Failure Mode: BGP-Session kommt nicht hoch (Peering Down)

Der Klassiker: Die BGP-Nachbarschaft ist nicht etabliert. In Calico-Setups mit BIRD oder GoBGP bedeutet das, dass keine Routen ausgetauscht werden. Häufige Ursachen sind banal, aber in Kubernetes schnell übersehen:

Wichtig ist hier die Unterscheidung: In einem Node-to-Node-Mesh kann ein einziges Firewall-Change auf einem Node nur diesen Node isolieren, während der Rest „gesund“ wirkt. Das erzeugt besonders verwirrende Teil-Ausfälle.

Failure Mode: Routen werden nicht (oder nicht vollständig) propagiert

Eine BGP-Session kann „Established“ sein und dennoch falsche oder fehlende Routen haben. Diese Klasse ist in Produktion häufiger als ein kompletter Peer-Down, weil sie wie ein sporadischer Applikationsfehler aussieht.

Gerade bei HostRoutes (/32) steigt die Route-Anzahl stark. Das ist technisch möglich, aber Sie müssen Max-Prefix und Control-Plane-Kapazität bewusst dimensionieren – sonst sind Peering-Flaps vorprogrammiert.

Failure Mode: Route Leak oder „falsche“ Präfixe werden announced

Route Leaks sind im CNI-Kontext besonders gefährlich, weil sie nicht nur den Cluster, sondern potenziell das gesamte Underlay beeinflussen können. Ein falsch angekündigtes Präfix kann Traffic umleiten oder Blackholes erzeugen.

Mitigation besteht fast immer aus strikt definierten Prefix-Listen und „deny by default“ für alle Präfixe, die nicht explizit erlaubt sind. Zusätzlich sind Max-Prefix-Limits eine Sicherheitsleine gegen unkontrollierte Route-Explosion.

Failure Mode: Asymmetrisches Routing und Reverse Path Filtering (RPF)

Asymmetrie ist eine der häufigsten Ursachen für „verrückte“ Timeouts in BGP-CNI-Setups. Der Hinweg geht über einen Pfad, der Rückweg über einen anderen. Das ist bei ECMP, mehreren Uplinks, NAT oder Firewall-Designs nicht ungewöhnlich. Problematisch wird es, wenn Zwischenkomponenten stateful sind oder RPF aktiv ist.

Typische Symptome

Warum RPF im Kubernetes-Kontext zuschlägt

Reverse Path Filtering prüft vereinfacht: „Würde ich die Quell-IP über dasselbe Interface zurückrouten?“ Wenn nicht, kann das Paket gedroppt werden. In Multi-Homing- oder ECMP-Umgebungen, in denen Pods über BGP dynamisch geroutet werden, ist die Wahrscheinlichkeit für RPF-Drops höher. Das ist weniger ein „Bug“ als ein Designkonflikt zwischen dynamischem Routing und strikten Anti-Spoofing-Checks.

Failure Mode: ECMP und ungleichmäßige Lastverteilung

BGP und moderne Underlays nutzen häufig ECMP (Equal-Cost Multi-Path). Das ist grundsätzlich gut, kann aber in Kubernetes unerwartete Effekte erzeugen:

In Verbindung mit Connection Pools und langen TCP-Verbindungen wirkt ECMP manchmal wie ein Applikationsproblem, ist aber ein Routing-Verteilungsproblem.

Failure Mode: Node-to-Node Full Mesh skaliert nicht sauber

Ein Full Mesh zwischen Nodes bedeutet, dass jede Node mit jeder anderen Node peert. Das kann bei kleinen Clustern funktionieren, wird aber bei wachsender Node-Anzahl schnell zum Risiko: mehr Sessions, mehr Updates, mehr Flap-Domänen, höhere Control-Plane-Last.

Die typische Mitigation sind Route Reflectors (iBGP) oder Peering zu wenigen Underlay-Routern (eBGP) mit klaren Policies. In Calico ist das RR-Muster ein etablierter Ansatz: Calico Route Reflectors.

Failure Mode: BIRD/Agent-Probleme auf dem Node

BGP-CNI ist nicht nur „Routing“, sondern auch Software auf dem Node: BIRD/GoBGP, ein CNI-Agent, Controller, Felix (bei Calico) und das Zusammenspiel mit dem Kernel-Routing. Failure Modes sind daher auch klassische „Daemon“-Probleme:

Gerade Drift ist in Kubernetes häufig: Ein einzelner Nodepool oder ein „vergessener“ Node kann andere Kernel-Settings haben und dadurch Routing anders behandeln. Das äußert sich dann als „nur dieser Node ist kaputt“.

Failure Mode: MTU- und Encapsulation-Mischbetrieb

Viele BGP-CNI-Setups sind nicht „rein BGP“. Häufig gibt es Mischbetrieb: bestimmte Pfade sind routed, andere sind getunnelt (VXLAN/IP-in-IP), etwa als Fallback oder für bestimmte Netzsegmente. Wenn MTU nicht konsistent ist, entsteht das bekannte Muster „Small works, large fails“ – besonders bei großen Antworten, TLS oder gRPC.

Für PMTUD-Grundlagen sind die RFCs eine belastbare Referenz: RFC 1191 (IPv4 PMTUD) und RFC 8201 (IPv6 PMTUD).

Failure Mode: Service-Traffic und Advertisements werden verwechselt

Ein häufiger Denkfehler ist, Service-IPs (ClusterIP) wie „normale“ routbare Netze zu behandeln. In Kubernetes werden Services intern per kube-proxy (iptables/ipvs) oder eBPF implementiert. Wenn Sie Service CIDRs nach außen announcen oder externe Systeme direkt zu ClusterIPs routen lassen, erzeugen Sie schwer debuggbare Effekte:

Das ist kein generelles Verbot, aber es erfordert ein klares Design: Wenn Sie Services nach außen exponieren wollen, ist ein bewusstes Modell (LoadBalancer, Ingress, Gateway) meist robuster. Grundlagen zu Services: Kubernetes Services.

Failure Mode: Route Churn durch Pod-Lebenszyklen und Autoscaling

BGP ist dynamisch, aber nicht grenzenlos. In Clustern mit hoher Churn-Rate (Autoscaling, viele kurzlebige Pods, häufige Deployments) kann die Menge an Route Updates die Control Plane belasten – besonders bei /32 HostRoutes oder wenn jede Pod-IP als einzelne Route annonciert wird.

Hier helfen Design-Entscheidungen: Pod-CIDR statt HostRoutes, Route Reflectors, längere Timer, Dämpfung, und realistische Max-Prefix-Grenzen.

Diagnose-Ansatz: Vom Symptom zur BGP-Ursache

Eine praxisnahe Diagnose beginnt nicht mit „BGP ist kompliziert“, sondern mit klaren Trennfragen:

Auf Werkzeugebene gilt: Prüfen Sie BGP-Session-Status (Established?), empfangene/gesendete Prefixes, und vergleichen Sie Node A (gesund) vs. Node B (krank). In Calico-Kontext sind die offiziellen Diagnosewege relevant, z. B. über Calico Troubleshooting und die CLI-Tools wie calicoctl.

Mitigation-Muster, die sich in Produktion bewährt haben

Outbound-Quellen für vertiefende Informationen

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:

Lieferumfang:

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.

 

Exit mobile version