HA Cluster Baseline: Active/Active vs. Active/Passive mit State Sync

Eine belastbare HA Cluster Baseline ist im Telco- und Provider-Umfeld essenziell, weil Firewalls, SBCs, CGNAT-nahe Policy-Knoten, VPN-Gateways, API Front Doors und viele weitere Security- und Network-Appliances als stateful Systeme betrieben werden. Das bedeutet: Sie halten Verbindungszustände, NAT-Übersetzungen, Session-Tabellen, TLS-States, IPS-Kontexte oder Benutzerzuordnungen. Fällt ein solches System aus oder wird falsch umgeschaltet, entstehen nicht nur kurze Unterbrechungen, sondern oft massive Störungen: Sessions reißen ab, Retries steigen, Signalisierung kippt, und in Telco-Lastprofilen können wenige Sekunden Instabilität schnell zu Kettenreaktionen führen. Eine professionelle Baseline beschreibt deshalb nicht nur „wir haben HA“, sondern definiert präzise, welches HA-Modell (Active/Active vs. Active/Passive), wie State Sync umgesetzt wird, welche Failure Domains gelten, welche Prechecks vor Changes Pflicht sind, welche Failover-SLOs erwartet werden und wie Split-Brain, Wartungsfenster und Rollbacks gehandhabt werden. Dieser Artikel zeigt, wie Telcos HA-Cluster für stateful Gateways standardisieren, welche Designentscheidungen die größte Wirkung haben und wie man HA so betreibt, dass Verfügbarkeit, Sicherheit und Performance gleichzeitig erfüllt werden.

Warum HA im Telco-Netz mehr ist als „zwei Geräte“

In Unternehmens-IT bedeutet HA oft: zweites Gerät, VRRP/HSRP, fertig. Im Carrier-Netz sind die Anforderungen strenger: hohe CPS (Connections per Second), große Session-Tabellen, sehr kurze Toleranzen für Paketverlust und oft komplexe Verkehrsverteilungen (mehrere Zonen, VRFs, Peering, Customer Segments). Daraus folgen besondere Anforderungen an eine HA Cluster Baseline:

• Stateful Continuity: Failover darf nicht bedeuten, dass alle Sessions „vergessen“ werden.
• Determinismus: Failover muss vorhersehbar sein (klare Trigger, klare Rollen, keine flapping loops).
• Upgrade-Fähigkeit: Wartungsfenster müssen rollierend funktionieren, ohne großflächige Störungen.
• Observability: HA-Health, State Sync und Failover Events müssen in Echtzeit sichtbar sein.
• Kompatibilität: Multi-Vendor- und Multi-Region-Designs brauchen standardisierte Prinzipien, nicht vendor-spezifische Rituale.

Eine Baseline setzt den Rahmen, damit HA nicht „irgendwie läuft“, sondern im Betrieb reproduzierbar und auditierbar ist.

Begriffe: Active/Active, Active/Passive, State Sync und Failure Domain

Eine saubere Baseline beginnt mit klaren Begriffen, weil Hersteller unterschiedliche Namen verwenden. Für den Betrieb zählen die Konzepte:

• Active/Passive: ein Knoten verarbeitet Traffic (active), der andere steht bereit (passive) und übernimmt bei Failover.
• Active/Active: beide Knoten verarbeiten Traffic gleichzeitig; Lastverteilung erfolgt über Hashing, ECMP, LAG oder Policy-Steuerung.
• State Sync: Synchronisation von Verbindungszuständen (Sessions), NAT-States, ggf. Security-States (z. B. IPS, Decryption-Kontexte).
• Failure Domain: der Bereich, der durch einen Fehler betroffen sein kann (ein Knoten, ein HA-Paar, ein Pod/PoP, eine Region).

Für Telcos ist der Failure-Domain-Gedanke zentral: HA darf den Blast Radius reduzieren, nicht vergrößern. Ein „Mega-Cluster“ kann operativ bequem wirken, aber im Fehlerfall katastrophal sein.

Active/Passive: Einfacher, oft robuster – aber nicht immer effizient

Active/Passive ist das klassische HA-Modell für stateful Appliances. Es ist häufig einfacher zu verstehen, zu testen und zu betreiben, weil es einen klaren Master gibt. Im Telco-Umfeld ist das ein Vorteil, solange Kapazität und Failover-SLOs passen.

Stärken von Active/Passive

• Deterministisches Failover: klare Rollen, weniger komplexe Traffic-Splits.
• State Sync fokussiert: der passive Knoten kann den State kontinuierlich spiegeln.
• Einfachere Troubleshooting-Pfade: „wo läuft der Traffic?“ ist klar beantwortbar.
• Wartungsfenster: rollierende Updates sind gut planbar, wenn Prechecks sauber sind.

Risiken und typische Fallstricke

• Kapazitätsheadroom: der passive Knoten muss im Failover die volle Last tragen können (N+1).
• Cold Failover: wenn State Sync unvollständig oder deaktiviert ist, reißen Sessions ab.
• Flapping: instabile Health Checks führen zu häufigen Umschaltungen, was Telco-Traffic stark destabilisieren kann.
• Asymmetrische Pfade: wenn Routing/ECMP den Rückweg über den falschen Knoten schickt, entstehen Drops.

Eine Baseline für Active/Passive muss daher Kapazitätsregeln, Health-Check-Design und strikte Pfadkontrolle definieren.

Active/Active: Bessere Ausnutzung, höhere Komplexität

Active/Active ist attraktiv, weil beide Knoten produktiv genutzt werden und Lastspitzen besser abgefedert werden können. In Telco-Netzen mit hohem Durchsatz und großen Session Tables kann das betriebswirtschaftlich sinnvoll sein. Gleichzeitig steigt die Komplexität deutlich.

Stärken von Active/Active

• Kapazitätsausnutzung: beide Knoten tragen Last; weniger „ungenutztes“ Backup.
• Skalierbarkeit: bessere Verteilung bei großen Traffic-Mengen, oft bessere Resilienz bei partiellen Störungen.
• Rolling Changes: in manchen Designs können Teile der Last weggesteuert werden, um Updates durchzuführen.

Risiken und typische Fallstricke

• Session Stickiness: stateful Systeme brauchen deterministische Zuordnung, damit Hin- und Rückweg beim gleichen Knoten landen.
• State Sync Overhead: wenn beide aktiv sind, steigt die Menge an zu synchronisierenden States; Latenz und Bandbreite werden kritisch.
• Split-Brain Gefahr: bei Link-Ausfällen oder falschem Quorum können beide Knoten „active“ bleiben.
• Uneinheitliches Verhalten: unterschiedliche Feature-States (IPS/Decryption) sind schwieriger konsistent zu halten.

Eine Telco-Baseline muss daher klar definieren, wann Active/Active zulässig ist (z. B. bei sauberem Traffic Steering und getesteter State-Synchronisation) und wann Active/Passive die bessere Wahl ist.

State Sync Baseline: Was synchronisiert werden muss – und was nicht

State Sync ist der Kern, der HA „carrier-grade“ macht. Gleichzeitig ist State Sync nicht gleich State Sync: Manche Plattformen synchronisieren nur Basis-Sessions, andere auch NAT, Security-Inspections oder Benutzerkontexte. Eine Baseline sollte hier Mindestanforderungen definieren:

• Session State: 5-Tuple/Flows, TCP-States, UDP „pseudo-states“ mit Timeouts.
• NAT State: Übersetzungen und Port-Mappings (besonders kritisch bei CGNAT-nahen Designs).
• Policy State: relevante Policy-/Rule-IDs für Logging und Session-Accounting.
• Optional, risikobasiert: IDS/IPS-Kontext, TLS Decryption State, App-ID Kontext – abhängig von Plattform und Performance.

Die Baseline sollte zusätzlich festlegen, dass State Sync als eigener, überwachten Dienst betrachtet wird: Bandbreite, Latenz, Drops und Queueing werden gemessen, weil sie direkt Failover-Qualität bestimmen.

Traffic Steering: Die unterschätzte Voraussetzung für stabile HA

Viele HA-Probleme entstehen nicht im Cluster selbst, sondern im Netzwerk davor: ECMP, LAG, asymmetrisches Routing, falsch konfigurierte Next-Hops oder inkonsistente VRF-Routen. Eine HA Cluster Baseline sollte daher Traffic-Steering als Pflichtkapitel enthalten.

• Symmetrie garantieren: Hin- und Rückweg müssen konsistent über denselben Knoten laufen (insbesondere bei Active/Active).
• Deterministisches Hashing: bei ECMP/LAG sollte der Hash stabil sein; Änderungen dürfen nicht massenhaft Re-Hashing auslösen.
• Failover Signaling: Routing oder L2-Mechanismen müssen Failover schnell reflektieren (ohne Flapping).
• VRF/Segment Konsistenz: gleiche Policy Domain muss in beiden HA-Knoten identisch geroutet sein.

Ein Baseline-Prinzip ist „HA endet nicht am Gerät“: Der Cluster ist nur stabil, wenn das Netzwerk die richtigen Pfade liefert.

Health Checks und Failover-Trigger: Stabilität vor Sensitivität

In Telco-Umgebungen ist ein „zu sensibles“ Failover oft schlechter als ein „leicht verzögertes“ Failover, weil Flapping massive Folgeschäden erzeugt. Eine Baseline sollte daher Health Checks in Klassen strukturieren:

• Hard Fail: Stromausfall, Interface Down, kritische Dataplane-Down – sofortiges Failover.
• Soft Degradation: CPU hoch, Packet Drops, Logging backpressure – oft kein sofortiges Failover, sondern Alarm und Traffic Dämpfung.
• Control Plane Issues: Management unreachable ist nicht automatisch dataplane down; Failover nur, wenn dataplane wirklich betroffen.

Zusätzlich sollte die Baseline Hysterese und Hold-Down-Timer vorschreiben, um Flapping zu verhindern, sowie klare Prioritäten, welche Checks Failover auslösen dürfen.

Wartungsfenster und Upgrades: Rolling, Canary und Rollback-by-Design

HA-Cluster sind nur dann ein Verfügbarkeitsgewinn, wenn Upgrades und Patches sicher durchführbar sind. Eine Baseline sollte Update-Prozesse standardisieren:

• Prechecks: State Sync Health, HA-Status, Session Table Headroom, Interface Errors, Routing Stabilität.
• Rolling Upgrade: erst passive Knoten aktualisieren, dann kontrollierter Failover, dann den anderen.
• Canary Maintenance: zuerst ein Cluster in einer kleinen Failure Domain, dann Wellenrollout.
• Rollback: definierter Rückweg auf Known Good Version, inklusive Konfig-Snapshots.
• Postchecks: Session Resets, CPS, Drops, State Sync Quality, Alarm-Trends über Beobachtungsfenster.

Im Provider-Umfeld muss die Baseline außerdem definieren, wann ein Upgrade abgebrochen wird: klare Stop-the-Line Kriterien, nicht „wir ziehen durch“.

Split-Brain Prevention: Quorum, Heartbeats und Isolation

Split-Brain ist eines der gefährlichsten HA-Szenarien: beide Knoten glauben, sie seien aktiv. Das kann zu doppelten NAT-Mappings, inkonsistenten Policies und Traffic Blackholing führen. Eine Baseline sollte daher Split-Brain-Prävention als Pflicht definieren:

• Mehrere Heartbeat-Pfade: nicht nur ein Link, sondern redundante Heartbeats (idealerweise unterschiedliche Pfade).
• Quorum/Arbitration: definierter Mechanismus, wer „gewinnt“, wenn Heartbeats fehlen.
• Fail-safe Policies: im Zweifel in einen sicheren Zustand gehen (z. B. Traffic stoppen oder nur minimal erlauben), statt doppelt aktiv zu sein.
• Monitoring: Split-Brain-Indikatoren als High-Severity Alerts, sofortige Eskalation.

Die Baseline sollte zudem testen lassen, wie sich der Cluster bei Teilnetz-Ausfällen verhält (Partition Tests), nicht nur bei „Gerät aus“.

Logging und Evidence: HA als auditierbarer Betriebszustand

HA-Mechanismen müssen nachvollziehbar sein, weil sie direkt Serviceverfügbarkeit und Security beeinflussen. Eine Baseline sollte definieren, welche Events zwingend erfasst werden:

• Failover Events: Zeitpunkt, Grund, beteiligte Knoten, Dauer, betroffene Interfaces/Zonen.
• State Sync Events: Sync Status, Drops, Backlog, Resyncs, Link-Errors.
• Health Check Changes: welche Checks waren kritisch, welche Schwellen wurden überschritten.
• Maintenance Actions: geplante Switchover, Upgrades, Rollbacks, Change-ID/Ticket-Link.

Diese Logs sollten in SIEM/Observability normalisiert werden (cluster_id, node_id, role, reason, change_id), damit NOC/SOC Korrelationen bauen können.

Auswahlkriterien: Wann Active/Passive, wann Active/Active?

Eine gute Baseline gibt Entscheidungshilfen, statt dogmatisch zu sein. In Telco-Umgebungen haben sich folgende Leitlinien bewährt:

• Active/Passive bevorzugt: wenn deterministisches Verhalten wichtiger ist als maximale Ausnutzung oder wenn State/Inspection sehr komplex ist.
• Active/Active sinnvoll: wenn Traffic Steering stabil beherrscht wird, ausreichend State-Sync-Kapazität existiert und der Nutzen (Kapazität/Resilienz) den Aufwand rechtfertigt.
• Hybrid-Ansätze: in großen Netzen oft „active/active über Pods“, aber „active/passive innerhalb eines Pods“ (Failure Domains klein halten).

Damit wird HA nicht nur eine technische Entscheidung, sondern eine risikobasierte Architekturentscheidung.

Typische Fehler bei HA-Clustern und wie die Baseline sie verhindert

• Kein Kapazitätsheadroom: Failover überlastet den Knoten; Baseline fordert N+1 und Session/CPS-Planung.
• Asymmetrische Pfade: Sessions brechen; Baseline erzwingt symmetrisches Routing und deterministisches Steering.
• State Sync nicht überwacht: Failover wird „kalt“; Baseline setzt Sync-Health als Pflichtmetrik.
• Zu sensitive Health Checks: Flapping; Baseline definiert Hysterese, Hold-Down und Hard/Soft-Klassen.
• Split-Brain ignoriert: schwerer Impact; Baseline verlangt Quorum/Arbitration und Partition Tests.
• Upgrades als Big Bang: Outage-Risiko; Baseline setzt Rolling Upgrades, Canary Maintenance und Rollback-by-Design.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.