BGP CNI (Calico): Failure Modes und Recovery-Checkliste

BGP CNI (Calico) ist eine leistungsfähige Architektur, weil sie Pod-Netze nicht „versteckt“, sondern per Routing in Ihr Underlay integriert. Statt Overlay-Tunneln (VXLAN/IPIP) werden Routen zu Pod-CIDRs oder einzelnen Pod-/Block-Routen via Border Gateway Protocol (BGP) verteilt. Das reduziert Overhead, vereinfacht oft die Path-Transparenz und kann Latenz sowie MTU-Probleme minimieren. Gleichzeitig verlagert es die Komplexität in ein Protokoll, das für große Netzwerke gebaut ist – und damit auch Failure Modes mitbringt, die sich in Kubernetes als „Service down“, „Pods unreachable“, „Intermittent Drops“ oder „Node isoliert“ äußern. Besonders tückisch ist: Ein BGP-Ausfall ist selten ein sauberer Totalausfall. Häufig sieht nur ein Teil des Clusters bestimmte Pod-Netze nicht mehr, oder einzelne Nodes verlieren selektiv Reachability, während DNS, Ingress oder einzelne Services scheinbar normal funktionieren. Wer BGP CNI (Calico) sicher betreiben will, braucht deshalb zwei Dinge: ein klares Verständnis der typischen Fehlerbilder (Failure Modes) und eine Recovery-Checkliste, die vom Symptom zur Ursache führt – schnell genug für On-Call und präzise genug für nachhaltige Fixes.

Wie BGP CNI (Calico) funktioniert – in einer Minute

Calico kann Routen auf unterschiedliche Weise verteilen. Im BGP-Modus sprechen Calico-Nodes (bzw. der Calico-Agent auf dem Node) BGP mit Peers. Diese Peers können andere Nodes sein (Node-to-Node Mesh) oder zentrale Router (Route Reflectors, Top-of-Rack, virtuelle Router). Typischerweise werden Pod-CIDRs oder IPAM-Blocks (z. B. /26 oder /24) angekündigt. Dadurch weiß das Underlay, über welchen Node ein bestimmtes Pod-Netz erreichbar ist.

• Node-to-Node Mesh: Jeder Node peert mit jedem Node (einfach, aber skaliert begrenzt).
• Route Reflectors: Nodes peeren nur mit RR(s), die Routen weiterverteilen (skalierbarer, mehr Komponenten).
• eBGP zum Underlay: Calico peert mit Routern außerhalb des Clusters (mehr Integration, mehr Abstimmung nötig).
• BIRD / GoBGP: Je nach Calico-Version und Setup wird ein Routing-Daemon genutzt, der BGP spricht.

Grundlagen zur Calico-Netzwerkarchitektur und BGP-Integration finden Sie in der offiziellen Dokumentation: Calico Networking – Überblick und Calico BGP – Konzepte und Konfiguration.

Die wichtigsten Failure Modes bei Calico BGP CNI

BGP Session Down: Peering bricht weg

Wenn BGP Sessions nicht etabliert werden oder flappen, fehlen Routen – und damit Reachability. In Kubernetes zeigt sich das oft als „Pods auf Node X sind nicht erreichbar“ oder „Cross-Node Traffic fällt aus“. Die Ursache kann in Netzwerk-Filtern, falschen Peer-IPs, Ports, Authentifizierung oder Timern liegen.

• TCP/179 blockiert: Security Groups, NACLs, Firewalls oder Host-Firewalls blocken BGP.
• Peer-IP falsch: Nodes peeren mit falscher Interface-IP (z. B. falsche NodeAddress, falsches IP-Autodetection-Method).
• ASN mismatch: Local/Remote ASN falsch konfiguriert (häufig bei eBGP zum Underlay).
• MD5 Auth mismatch: Passwort/Key unterscheidet sich zwischen Peers.
• Timer/Keepalive-Probleme: Aggressive Timer + Paketverlust → Flaps und Route-Churn.

Typische Symptome im Cluster

• Pod-to-Pod nur innerhalb desselben Nodes funktioniert, Cross-Node nicht.
• Ein einzelner Node wirkt „isoliert“: Pods dort sind aus anderen Nodes nicht erreichbar.
• Intermittierende Timeouts bei East-West-Traffic (Session flapped, Routen kurzfristig weg).

Route Blackholing: Routen existieren, aber zeigen ins Leere

Blackholing ist besonders gefährlich, weil es auf Monitoring-Ebene „alles sieht okay“ wirken kann: BGP Session ist up, Routen sind im Routing-Table vorhanden, aber Pakete kommen nicht an. Häufige Gründe sind Stale Routes, falsche Next-Hops, Race Conditions bei Node-Drain oder IPAM-Block-Moves.

• Stale Route nach Node-Ausfall: Router/Peers halten Route länger als der Cluster braucht, Traffic geht weiter an einen toten Node.
• PodCIDR/Block neu vergeben: IPAM verschiebt Blocks, aber Route-Propagation ist verzögert.
• Mehrdeutige Pfade: Mehrere Peers announcen dasselbe Präfix – falsche Best-Path-Auswahl.
• Asymmetrisches Routing: Hinweg über Underlay-Routing, Rückweg über andere Gateways/NAT → State-/Policy-Probleme.

Route Churn und Convergence: Zu viele Updates, zu langsame Erholung

In BGP-Setups sind viele Events normal: Nodes kommen und gehen, Pods skalieren, IPAM verteilt Blocks. Problematisch wird es, wenn Konvergenzzeiten steigen oder Updates „fluten“. Das kann CPU auf Routern oder auf Nodes erhöhen, BGP-Daemons belasten und zu zeitweisen Reachability-Lücken führen.

Warum Konvergenz im On-Call relevant ist

Ein einfacher, praxisnaher Blick auf „Wie lange kann ein Flap wehtun?“ ergibt sich aus Keepalive/Hold-Timern plus eventuellen Retries. Vereinfacht kann man eine Worst-Case-Zeit grob als Anteil aus Hold-Time und Wiederaufbau betrachten:

$T\approx \mathrm{HoldTime}+\mathrm{ReconnectBackoff}$

In der Realität hängen Konvergenz und Erholungszeit zusätzlich von Route-Reflector-Topologien, Router-CPU, MRAI/Update-Policies und der Anzahl der Präfixe ab. Trotzdem hilft diese Vereinfachung, um Erwartungen zu steuern: Ein Flap ist nicht „sofort“ weg, wenn Hold-Time groß ist.

Node-to-Node Mesh skaliert nicht: Peering-Explosion

Node-to-Node Mesh ist schnell eingerichtet, aber die Anzahl der BGP Sessions wächst quadratisch mit der Node-Anzahl. Das erhöht nicht nur State, sondern auch die Ausfallfläche: Ein einzelner instabiler Node kann durch häufiges Flapping viele Peers stören.

• Symptome: BGP flaps häufen sich bei größerem Cluster, Router/Nodes haben hohe CPU, Updates dauern länger.
• Risiko: Wartungsfenster (Rolling Updates) verursachen massiven Route-Churn.
• Gegenmittel: Route Reflectors, Hierarchien, klare Peering-Domänen.

IP Autodetection und falsche Node-IP: BGP spricht „die falsche Adresse“

Ein Klassiker in Multi-NIC-, Cloud- oder Hybrid-Umgebungen: Calico nimmt für BGP die falsche Node-IP (z. B. eine Management-Schnittstelle oder eine nicht routbare Adresse). Sessions kommen nicht hoch oder Routen zeigen auf Next-Hops, die nicht erreichbar sind.

• Symptome: BGP Session Down, oder Session Up aber Traffic blackholed.
• Trigger: Neue Node-Images, DHCP-Änderungen, neue Interfaces, Cloud-Agent-Updates.
• Fix-Ansatz: IP Autodetection sauber definieren (Interface-Filter, CIDR-Filter) und dokumentieren.

Policy-/Datapath-Konflikte: Routing stimmt, aber Firewall droppt

BGP löst nur das „Wo lang?“. Ob Pakete dann tatsächlich durchgehen, hängt von NetworkPolicies, Host-Firewalls (iptables/nftables), eBPF-Regeln und Cloud-Firewalls ab. Ein häufiger Failure Mode: BGP Sessions sind stabil, Routen sind korrekt, aber einzelne Ports/Protokolle werden gedroppt.

• NetworkPolicy-Fehler: Default deny aktiv, notwendige Allow-Regeln fehlen oder selektieren falsch.
• Host Firewall: Node-spezifische iptables/nftables-Regeln blocken Forwarding oder spezifische Interfaces.
• Cloud-Firewall-Asymmetrie: Ingress erlaubt, Egress blockiert (oder umgekehrt), je nach Richtung/Zone.

Zur NetworkPolicy-Semantik als Grundlage: Kubernetes Network Policies.

MTU und Fragmentation: BGP als „unschuldiger“ Auslöser

Auch wenn BGP selbst nicht die MTU bestimmt, treten MTU-Probleme in BGP-Setups oft sichtbarer auf, weil der Datenpfad direkter ist und Underlay/Overlay-Mischungen entstehen können (z. B. Teilcluster VXLAN, Teilcluster BGP, oder zusätzlich IPsec/WireGuard). Dann funktionieren kleine Pakete, größere Requests aber intermittierend nicht.

• Symptome: „Small works, large fails“, TLS-Handshakes hängen, gRPC bricht sporadisch ab.
• Trigger: Verschlüsselung, Jumbo Frames, Cloud-VPN, Cross-Zone Paths mit anderer MTU.
• Mitigation: MTU-End-to-End festlegen, ICMP korrekt erlauben, MSS-Clamping prüfen.

Recovery-Checkliste: Von Alert zu stabiler Route-Health

Die folgende Recovery-Checkliste ist so aufgebaut, dass Sie im Incident-Fall schnell entscheiden können: Ist es ein BGP-Problem, ein Routing-Problem oder ein Policy/Datapath-Problem? Ziel ist, zuerst den Blast Radius zu begrenzen und dann sauber zu reparieren.

Schritt 1: Impact eingrenzen (Scope & Blast Radius)

• Ist es Node-spezifisch? Betroffen sind Pods auf bestimmten Nodes → Fokus auf deren BGP/Datapath.
• Ist es Namespace-/Service-spezifisch? Nur bestimmte Workloads → Policy/Labels/Ports prüfen.
• Ist es Cross-Node oder auch Same-Node? Same-Node ok, Cross-Node kaputt → Routing/BGP sehr wahrscheinlich.
• Ist es ein flapping Pattern? Spikes/Intermittency → Session Flaps, Timer, Paketverlust, CPU.

Schritt 2: BGP Session Status prüfen

• Peering ist up/down? Prüfen Sie auf betroffenen Nodes die BGP Peer States (Established vs. Idle/Active).
• Flaps sichtbar? Häufige State-Wechsel deuten auf Netzinstabilität oder Timer/Auth/Port-Blocking hin.
• Port 179 erreichbar? Zwischen Peers muss TCP/179 bidirektional funktionieren (inkl. Rückweg).
• ASN/MD5 korrekt? Besonders bei eBGP zum Underlay oder bei zentralen Route Reflectors.

Wenn Sie BGP-Grundlagen zur Session-State-Maschine oder Timern nachschlagen möchten, bietet RFC 4271 eine solide Referenz: RFC 4271 – Border Gateway Protocol 4 (BGP-4).

Schritt 3: Routen-Verteilung validieren (Control Plane)

• Wird das erwartete Präfix announct? PodCIDR oder Block-Routen müssen im BGP RIB sichtbar sein.
• Kommt die Route beim Peer an? Route Reflector oder Underlay-Router muss die Route lernen.
• Next-Hop plausibel? Next-Hop muss routbar sein (korrekte Node-IP, richtige Interface-IP).
• Keine Doppelankündigungen? Konflikte bei IPAM/Block-Vergabe oder Mischbetrieb vermeiden.

Schritt 4: Datenpfad testen (Data Plane) – ohne „PCAP-first“

• Ping/ICMP nur als Indikator: ICMP kann geblockt sein; nutzen Sie applikationsnahe Tests (TCP connect, HTTP GET).
• Pod-to-Pod auf IP-Ebene: Direkt auf Pod-IP testen, nicht über Service, um kube-proxy als Variable auszuschließen.
• Cross-Node gezielt: Ein Pod auf Node A zu Pod auf Node B, dann A→C, um Muster zu erkennen.
• MTU/MSS prüfen: Bei „intermittent“ oder „nur große Payloads“ unbedingt mitdenken.

Schritt 5: Policy und Host-Firewall ausschließen

• NetworkPolicies prüfen: Default deny, Selector-Fehler, Ports/Protokolle korrekt?
• Host-Firewall: iptables/nftables-Forwarding, rp_filter, sysctl-Forwarding, spezielle Chains.
• Cloud-Firewalls: Security Group/NACL Regeln für Node-to-Node Traffic und BGP/179.

Schritt 6: Stabilisieren – kurzfristige Recovery-Maßnahmen

• Flapping Node isolieren: Wenn ein Node Flaps verursacht, Workloads drainen und Node aus dem Peering nehmen (kontrolliert).
• Route Reflector Failover: Prüfen, ob RR erreichbar ist; bei Multi-RR sicherstellen, dass alle Nodes redundant peeren.
• Timer temporär entschärfen: Zu aggressive Keepalive/Hold-Timer können Instabilität verstärken.
• Rollback letzter Changes: Calico-Konfig, IP autodetection, Policies, Cloud-Firewall-Änderungen.

Schritt 7: Nachhaltige Fixes – damit der Incident nicht wiederkommt

• Topologie skalieren: Ab einer gewissen Node-Anzahl Route Reflectors statt Full Mesh nutzen.
• IP Autodetection „hart“ definieren: Interface-/CIDR-Filter dokumentieren, Tests in CI/CD für Node-Images.
• Konfig-Drift verhindern: Calico Ressourcen (BGPPeer, BGPConfiguration) als IaC verwalten.
• BGP-Health observierbar machen: Peer States, Route Count, Flap Rate, RR CPU, Event Logs.
• Change-Management: Canary Nodes, gestaffelte Rollouts, klare Backout-Pläne für CNI/Network Changes.

Monitoring-Signale, die sich für BGP CNI wirklich lohnen

Viele Teams überwachen zu spät und zu wenig auf der Routing-Ebene. Für BGP CNI (Calico) sind einige wenige Signale jedoch extrem wirkungsvoll, weil sie frühzeitig Drift und Instabilität anzeigen.

• Peer State: Anzahl Established vs. Idle/Active, pro Node und aggregiert.
• Flap Rate: Wie oft Peer Sessions pro Stunde wechseln (starker Frühindikator).
• Route Count: Erwartete Anzahl Präfixe im RIB/FIB (Abweichungen = fehlende Reachability).
• RR/Node CPU: Router- oder Node-CPU-Spikes korrelieren mit Convergence-Problemen.
• Packet Drops: NIC Drops, conntrack drops, Forwarding drops – trennen von BGP.

Outbound-Links für vertiefende Informationen

• Calico BGP – Konzepte, Peering und Betrieb
• Calico BGPConfiguration – zentrale Parameter
• Calico BGPPeer – Peer-Definitionen und Topologien
• RFC 4271 – BGP-4 Standard
• Kubernetes Network Policies – Grundlagen für Policy-Drops

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.