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

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.

• Pod-CIDR-Routing: Jede Node announced ein Pod-CIDR (z. B. /26) an ihre Peers.
• HostRoutes (/32): Teilweise werden einzelne Pod-IPs als /32 geroutet (mehr Präzision, mehr Routen).
• Peering-Modelle: Full Mesh zwischen Nodes, Peering zu Router(n), oder Route Reflectors.
• Policy und Filters: BGP-Filter entscheiden, welche Präfixe überhaupt gelernt/annonciert werden.

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:

• Pod-to-Pod nur cross-node kaputt: Intra-node Traffic funktioniert, aber cross-node Timeouts steigen.
• Nur einzelne Namespaces/Services betroffen: weil nur bestimmte Präfixe fehlen oder falsch geroutet werden.
• „Flaky“ Verbindungen: asymmetrische Pfade, NAT/Conntrack, RPF oder intermittierende Peering-Resets.
• Fehler nach Node-Scale-out oder Rolling Updates: Route Churn, Peering-Flaps, Max-Prefix-Limits.

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:

• TCP/179 blockiert: Firewall, Security Groups, NACLs oder Host-Firewall blocken BGP.
• Falsche IP als Peer: Peering gegen falsches Interface (Node-IP vs. Management-IP).
• ASN-Mismatch: eBGP vs. iBGP falsch geplant, oder falsche ASNs konfiguriert.
• MD5/Auth-Key falsch: BGP MD5-Passwort mismatch führt zu stillen Verbindungsproblemen.
• TTL/Hops: eBGP Multihop/TTL Security (GTSM) falsch eingestellt.

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.

• Prefix-Filter zu strikt: Inbound/Outbound Filter droppen Pod-CIDRs oder Service-CIDRs.
• Max-Prefix-Limit triggert: Nach Scale-out werden zu viele Routen angekündigt, Peer drosselt oder reset.
• Community/Policy-Fehler: Routen bekommen falsche Communities und werden upstream nicht weiterverteilt.
• Aggregation falsch: zu aggressive Aggregation führt zu Blackholes, wenn nicht alle Subnetze tatsächlich erreichbar sind.

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.

• Pod-CIDR kollidiert mit Underlay: Pod-Netz überschneidet sich mit VPC/VNet oder On-Prem-Netzen.
• Default Route wird announced: durch falsche Redistribution oder Policy, mit katastrophalen Auswirkungen.
• Service CIDR nach außen geleakt: externe Systeme routen zu Service-IPs, die intern per kube-proxy/eBPF gehandhabt werden.
• Leak über Peering-Grenzen: iBGP/eBGP falsch getrennt, Route Reflector-Regeln fehlen.

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

• TCP-Verbindungen hängen beim Handshake oder brechen sporadisch ab.
• UDP wirkt „flaky“, DNS timeouts steigen, aber nicht konstant.
• Nur bestimmte Ziele oder bestimmte Nodes sind betroffen.

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:

• Flow-Hashing: Ein einzelner „heißer“ Flow kann auf einem Pfad bleiben, während andere Pfade frei sind.
• Stateful Middleboxes: Wenn ein Firewall-/NAT-Gerät nicht symmetrisch erreicht wird, entstehen Drops.
• Rehash bei Topologieänderung: Wenn Links/Peers flappen, werden Flows neu verteilt, was als „Sporadik“ wahrgenommen wird.

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.

• Session-Anzahl wächst quadratisch: mehr Nodes bedeuten überproportional mehr Peers.
• Flap-Radius wird größer: ein instabiler Node kann viele Sessions beeinflussen.
• Upgrade-Risiko: Rolling Updates erzeugen Route Churn über viele Sessions.

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:

• Agent läuft, aber programmiert keine Routen: Kernel-Route Table passt nicht zum erwarteten Zustand.
• High CPU durch Route Churn: zu viele Updates, zu kurze Timer, zu viele /32 Routen.
• Version-Mismatch nach Upgrade: Control-Plane und Node-Agent sind nicht kompatibel, BGP-Policy verhält sich anders.
• Node-spezifische Drift: ein Node hat andere sysctl-/iptables-/rp_filter-Settings als der Rest.

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.

• MTU-Mismatch zwischen Nodes: ein Teil der Nodes nutzt Encapsulation, ein Teil nicht.
• Overhead durch Verschlüsselung: IPsec/WireGuard plus Encapsulation senkt effektive MTU deutlich.
• PMTUD blockiert: ICMP wird gefiltert, große Pakete droppen still.

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:

• Blackholes: externe Router senden Traffic zu Service CIDRs, aber die Rückwege/NAT-Zustände passen nicht.
• Bypass von Ingress/Policies: unerwartete Traffic-Pfade umgehen Sicherheitslogik.
• Uneindeutige Observability: Flow Logs zeigen Service-IP-Ziele, aber die echte Endpoint-Verbindung ist anders.

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.

• Viele Updates pro Minute: BGP-Update-Stürme führen zu CPU-Spitzen und Instabilität.
• Konvergenzzeit: Während Konvergenz entstehen kurzzeitige Blackholes oder Asymmetrien.
• Interaktion mit Healthchecks: Healthchecks erzeugen zusätzlichen Traffic genau während Routing instabil ist.

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:

• Ist es node-spezifisch? Wenn nur ein Node betroffen ist, sind Peering, Kernel-Settings oder Agent-Drift wahrscheinlich.
• Ist es prefix-spezifisch? Wenn nur bestimmte Pod-CIDRs betroffen sind, sind Filter, Leaks oder fehlende Announcements wahrscheinlich.
• Ist es zeitlich korreliert? Wenn Fehler nach Deployments/Scale-out auftreten, sind Route Churn, Max-Prefix oder Peering-Flaps wahrscheinlich.
• Ist es „klein ok, groß kaputt“? Dann MTU/PMTUD und Mischbetrieb prüfen.

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

• Prefix-Listen strikt: Nur Pod-CIDRs/Netze erlauben, die wirklich geroutet werden sollen; alles andere deny.
• Max-Prefix setzen: Schutz vor Route Explosion und Fehlkonfigurationen.
• Route Reflectors nutzen: Full Mesh vermeiden, besonders ab mittleren Clustergrößen.
• Drift verhindern: sysctl-/Firewall-/rp_filter-Settings standardisieren und regelmäßig prüfen.
• MTU konsistent planen: Encapsulation und Verschlüsselung einrechnen, PMTUD nicht durch ICMP-Blocking sabotieren.
• Change Safety: BGP-Policy-Änderungen wie kritische Infrastruktur behandeln (Canary, stufenweiser Rollout, Rückfallplan).
• Observability etablieren: BGP Session State, Prefix Counts, Update-Rate, CPU der Routing-Daemons, und Konvergenzzeiten monitoren.

Outbound-Quellen für vertiefende Informationen

• Calico BGP Networking: Konzepte und Konfiguration
• Calico Route Reflectors: Skalierung ohne Full Mesh
• Calico Troubleshooting: Praxisnahe Diagnosepfade
• calicoctl: Status- und Diagnosewerkzeug
• BIRD Routing Daemon: Hintergrund zu BGP-Implementierung
• Kubernetes Networking Concepts: Einordnung von Routing und Datenpfaden
• Kubernetes Services: Service-Mechanik und Traffic-Verhalten
• RFC 1191: Path MTU Discovery (IPv4)
• RFC 8201: Path MTU Discovery (IPv6)

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.