Site icon bintorosoft.com

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

Red Snapper

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.

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.

Typische Symptome im Cluster

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.

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 ≈ HoldTime + 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.

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.

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.

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.

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)

Schritt 2: BGP Session Status prüfen

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)

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

Schritt 5: Policy und Host-Firewall ausschließen

Schritt 6: Stabilisieren – kurzfristige Recovery-Maßnahmen

Schritt 7: Nachhaltige Fixes – damit der Incident nicht wiederkommt

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.

Outbound-Links 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