Hochverfügbarkeit von Firewalls: Active/Active vs. Active/Passive als Baseline

Hochverfügbarkeit von Firewalls ist in Telco- und Provider-Umgebungen kein „Luxusfeature“, sondern ein Baseline-Element für Servicequalität, Wartbarkeit und Risikoabsicherung. Firewalls sitzen häufig an kritischen Punkten: Gi-LAN/N6, Interconnect/Peering, Roaming-Edges, IMS/SBC-Perimeter, Telco Cloud North-South oder East-West-Segmentierung. Ein Ausfall oder ein unkontrolliertes Failover kann dort sofort zu Serviceabbrüchen, Paketverlust, Session-Resets oder massiven Latenzspitzen führen. Gleichzeitig ist die Wahl des HA-Modells nicht trivial: Active/Active verspricht bessere Ressourcennutzung und Skalierung, bringt aber Komplexität (State-Synchronisation, Asymmetrie, Hashing, Debuggability). Active/Passive ist konzeptionell einfacher und oft stabiler, kann aber Kapazitätsreserven erfordern und im Failover zu Lastspitzen führen. Eine praxistaugliche Baseline muss daher nicht nur „A/A vs. A/P“ vergleichen, sondern klare Entscheidungskriterien liefern: Welche Zonen profitieren von Active/Active? Wo ist Active/Passive die sichere Default-Option? Welche Mindestanforderungen gelten unabhängig vom Modus (N-1-Kapazität, State Sync, Failover-Trigger, Testzyklen, Logging)? Dieser Artikel zeigt, wie Sie Hochverfügbarkeit für Telco-Firewalls so designen, dass sie im Betrieb funktioniert – planbar, messbar und ohne versteckte Sicherheits- oder Performance-Fallen.

Warum HA bei Firewalls anders ist als HA bei Routern oder Servern

Firewalls sind in den meisten Telco-Architekturen stateful: Sie halten Session-States, NAT-Mappings, Threat-Engines, ggf. TLS-Inspection-Zustände und Policy-Caches. Das macht Failover anspruchsvoll. Ein Router kann oft stateless weiterleiten; eine Firewall muss wissen, welche Sessions „gültig“ sind. Wenn dieser Zustand beim Failover nicht korrekt übernommen wird, sehen Kunden „mysteriöse“ Probleme: TCP-Verbindungen resetten, VoIP-Sessions brechen ab, Apps laden neu, oder UDP-Streams verlieren Pakete. Deshalb ist eine HA-Baseline für Firewalls immer auch eine Baseline für State-Management und Traffic-Symmetrie.

• Statefulness: Sessions/NAT/Inspection erzeugen Zustand, der bei Failover relevant ist.
• Traffic-Symmetrie: Rückwege müssen konsistent durch dieselbe Instanz laufen oder State muss synchron sein.
• Performance unter Failover: Failover kann CPU/State/Queue-Spitzen erzeugen.
• Komplexe Trigger: Link down ist nicht der einzige Fehler; auch Policy-Engine, DP-Queueing oder State-Table-Exhaustion zählen.

Baseline-Ziele: Was Hochverfügbarkeit in Telco-Umgebungen leisten muss

Der HA-Modus ist Mittel zum Zweck. Eine Baseline sollte daher zuerst Ziele definieren, die messbar sind und im Betrieb geprüft werden können. In Telco-Netzen sind typische Ziele: minimale Unterbrechung (Session Preservation so weit sinnvoll), planbare Wartbarkeit, klare Fehlertoleranz (N-1) und vorhersagbares Verhalten bei Überlast.

• Service Continuity: Failover ohne unkontrollierte Outages; definierte Grenzen für Session-Impact.
• Wartungsfähigkeit: Upgrades/Restarts ohne große Traffic-Verluste, klarer „drain and shift“ Prozess.
• N-1 Betrieb: bei Ausfall einer Einheit bleibt die Plattform innerhalb definierter SLOs (Durchsatz, Latenz, Sessions).
• Deterministische Trigger: klare, getestete Failover-Entscheidungen statt „Random Failover“.
• Forensik und Audit: Failover-Ereignisse, State-Sync, Split-Brain-Indikatoren sind sichtbar und geloggt.

Active/Passive: Konzept, Vorteile und typische Telco-Einsatzfelder

Active/Passive (A/P) bedeutet: Eine Firewall ist aktiv und verarbeitet den Traffic, die zweite ist Standby und übernimmt bei Ausfall. Dieses Modell ist beliebt, weil es leichter zu verstehen, zu testen und zu betreiben ist. Gerade in Telco-Zonen, in denen Debuggability und deterministisches Verhalten wichtig sind (z. B. Partner-Edges, Roaming-Interconnects, kritische Management-Perimeter), ist A/P häufig die Baseline-Default-Option.

• Vorteil: Einfachheit: klare aktive Instanz, weniger Asymmetrieprobleme.
• Vorteil: Robustheit: weniger komplexe Lastverteilung und State-Konsistenzanforderungen.
• Vorteil: Predictable Troubleshooting: Pfad ist eindeutig, Packet Captures und Logs sind leichter interpretierbar.
• Nachteil: Kapazitätsreserve: Standby trägt im Normalbetrieb keine Last; N-1 muss trotzdem passen.
• Nachteil: Failover-Spike: plötzlicher Lastsprung kann Latenz erhöhen, wenn die aktive Box bereits hoch ausgelastet ist.

Active/Active: Konzept, Vorteile und typische Telco-Einsatzfelder

Active/Active (A/A) bedeutet: Beide Firewalls verarbeiten Traffic, typischerweise mit Lastverteilung (ECMP, LACP, Hashing oder Cluster-Mechanismen). Das kann Kapazität besser nutzen und Skalierung ermöglichen – besonders in Zonen mit sehr hoher Last oder hohem Session-Churn (z. B. Gi-LAN/N6, große Internet-Edges, Telco Cloud North-South). Der Preis ist höhere Komplexität: Sie müssen Traffic-Symmetrie sicherstellen oder State zuverlässig synchronisieren, und Sie müssen Split-Brain- und Asymmetrie-Fälle sauber beherrschen.

• Vorteil: bessere Ressourcennutzung: beide Einheiten tragen Last, Headroom kann effizienter genutzt werden.
• Vorteil: Skalierung: höhere Durchsatz- und Session-Kapazität möglich, je nach Cluster-Design.
• Vorteil: Wartung: Traffic kann in Teilen umgelegt werden, wenn „drain“ sauber funktioniert.
• Nachteil: Komplexität: Asymmetrie, Hashing, State-Sync, Debugging werden anspruchsvoller.
• Nachteil: Failure Modes: Split Brain oder inkonsistente States können schwer zu erkennen und zu beheben sein.

Baseline-Entscheidungsmatrix: Wann Active/Passive die bessere Default-Wahl ist

Eine praxistaugliche Baseline definiert klare Kriterien, wann A/P bevorzugt wird. Der Kern: Wenn Kontrollierbarkeit und deterministisches Verhalten wichtiger sind als maximale Ressourcennutzung, ist A/P meist die bessere Wahl. Das gilt häufig für Partner- und Signalisierungsdomänen, für Management-Perimeter und überall dort, wo ein falsches Verhalten im Failover einen großen Blast Radius hätte.

• Hohe Kritikalität, niedrige Fehlertoleranz: Roaming/Partner, zentrale Security Gateways, Signalisierung.
• Komplexe State-Use-Cases: umfangreiche Inspection, TLS-Decryption, spezielle ALG/SIP-Handling.
• Strenge Audit-/Forensik-Anforderungen: klare Pfade sind leichter nachvollziehbar.
• Begrenzte Betriebsreife: Teams ohne ausgeprägte HA-Operationalisierung fahren mit A/P sicherer.

Baseline-Entscheidungsmatrix: Wann Active/Active sinnvoll ist

A/A ist vor allem dann sinnvoll, wenn Kapazität und Skalierung im Vordergrund stehen und die Architektur Asymmetrie sauber kontrollieren kann. Typisch ist das in sehr großen Edge- oder Data-Plane-Zonen, in denen Trafficverteilung ohnehin über ECMP/LAG erfolgt und in denen die Plattform State-Sync oder Flow-Pinning zuverlässig bietet.

• Sehr hohe Last: Gi-LAN/N6, große Internet-Edges, Regionen mit starken Peaks.
• Viele kurzlebige Sessions: Web/App-Traffic, CDN-nahe Muster, hohe new sessions/s.
• Skalierbares Cluster-Design: bewährte Cluster-/Chassis-Mechanik oder verlässliche Flow-Pinning-Logik.
• Reife Observability: Teams können Asymmetrie- und Split-Brain-Signale schnell erkennen.

Traffic-Symmetrie als Baseline: Der wichtigste Erfolgsfaktor

Unabhängig vom HA-Modus ist eine zentrale Baseline-Regel: Traffic muss vorhersehbar durch die Firewall-Instanz(en) laufen. Bei A/P ist das meist einfach (eine aktive Instanz). Bei A/A muss die Lastverteilung so gestaltet sein, dass Rückwege konsistent sind (Flow-Pinning), oder dass State-Sync zuverlässig genug ist, um asymmetrische Pfade zu tolerieren. In Telco-Netzen mit ECMP, Multi-Homing und komplexem Routing ist diese Frage entscheidend.

• Flow-Pinning: ein Flow bleibt an einer Instanz, idealerweise bidirektional stabil.
• ECMP-Disziplin: Hashing-Parameter verstehen und so wählen, dass Asymmetrie minimiert wird.
• State-Sync Qualität: Latenz, Vollständigkeit und Limits der State-Synchronisation kennen und überwachen.
• Failover-Impact messen: welche Sessiontypen überleben, welche nicht; dokumentierte Erwartungen.

State-Synchronisation: Baseline für Session Preservation ohne Illusionen

State Sync ist kein „Zauber“, der alle Sessions rettet. Je nach Feature (NAT, IPS, TLS-Inspection, Proxying) kann State-Sync unterschiedlich vollständig sein. Eine Baseline sollte daher definieren: Welche Features sind HA-freundlich? Welche reduzieren Failover-Transparenz? Welche Sessionklassen sind kritisch (VoIP, Streaming, Steuerkanäle) und brauchen besondere Tests? Ohne diese Klarheit entsteht im Incident die falsche Erwartung, dass „HA = keine Unterbrechung“.

• State Scope: welche Zustände werden synchronisiert (Session, NAT, Threat Counters, SSL State)?
• Sync-Channel: dedizierte, performante Links für Sync (nicht über „irgendein VLAN“).
• Sync-Health: Metriken für Sync-Lag, Drops, Queueing und Replays.
• Feature-Baseline: definieren, wo TLS-Inspection/Proxying im HA-Verbund erlaubt ist.

Failover-Trigger und Split Brain: Baseline für sichere Entscheidungen

Viele HA-Designs scheitern nicht am eigentlichen Failover, sondern an falschen Triggern oder Split-Brain-Situationen: Beide Einheiten glauben, aktiv zu sein, oder Failover wird durch einen transienten Fehler ausgelöst, obwohl die Datenebene stabil ist. Eine Baseline sollte deshalb Failover-Trigger mehrstufig definieren: Link/Path Health, Data-Plane Health, Control-Plane Health, State-Sync Health. Zusätzlich sollten Mechanismen existieren, die Split Brain verhindern (z. B. Quorum/Witness, unabhängige Heartbeats, klare Prioritäten).

• Link Health: physische Links, LACP, Port-Channels, optische Fehler.
• Data-Plane Health: Drops, Queueing, PPS-Limits, Session Setup Failures.
• Control-Plane Health: CPU, Routing/Protokollflaps, Management-Services.
• Sync Health: Sync-Lag oder Sync-Failure als kritischer Zustand.
• Split-Brain Schutz: Quorum/Witness/priority und klare „tie-breaker“ Regeln.

N-1 Kapazität als Baseline: HA ohne Headroom ist nur Theorie

Der größte praktische Fehler ist ein HA-Design, das im Normalbetrieb „knapp“ läuft. Im Failover wird die verbleibende Einheit überlastet, und aus einem kontrollierten Failover wird ein Performance- oder Outage-Event. Eine Baseline muss daher N-1-Kapazität fordern, und zwar mit aktivierten Security-Features und realistischen Traffic-Profilen. Das gilt sowohl für A/P (weil Standby übernehmen muss) als auch für A/A (weil bei Ausfall die Lastverteilung kippt).

• Headroom-Regel: definierter Reservebereich unter Peak, angepasst an SLA und Failover-Ziele.
• Worst-Case Profile: kleine Paketgrößen, hohe new sessions/s, Spitzen durch Events.
• Feature Budgeting: IPS/TLS-Inspection reduziert Kapazität; N-1 muss das abbilden.
• Failover unter Last testen: nicht nur „Unit down“, sondern mit realen Verkehrsprofilen.

Wartung und Upgrades: Baseline für „Drain“, „Shift“ und kontrollierte Downtime

HA soll Wartung erleichtern, aber nur, wenn der Prozess sauber ist. Eine Baseline sollte Wartungsabläufe definieren: Traffic drainen, Policies synchron halten, Failover kontrolliert auslösen, Validierung durchführen und wieder zurückführen. Bei A/A ist „drain and shift“ oft komplexer, bei A/P klarer. In beiden Fällen braucht es Tests, Checklisten und Metriken, um unerwartete Effekte (z. B. Session Resets) zu erkennen.

• Drain-Prozess: Traffic kontrolliert von einer Einheit weglenken, ohne Asymmetrie zu erzeugen.
• Sync-Check: Konfig- und State-Sync vor Wartung validieren.
• Post-Change Verification: Latenz, Drops, Sessions, Policy-Hits, NAT Health prüfen.
• Rollback-Plan: klare Rückbaukriterien, falls nach Upgrade Anomalien auftreten.

Observability: Welche HA-Metriken in Telco-Baselines Pflicht sind

HA ist nur so gut wie die Sichtbarkeit auf ihre Zustände. Eine Baseline muss daher definieren, welche Telemetrie und Logs verpflichtend sind: HA-State (active/passive, cluster membership), Sync-Lag, Failover-Events, Split-Brain-Indikatoren, Session/State-Counts pro Member, und Performance-KPIs (P95/P99 Latenz) während Failover. Ohne diese Metriken wird HA zur Blackbox.

• HA Status: Rollen, Membership, Heartbeat Health.
• Sync Metriken: Lag, Drops, Retry Counts, Sync Channel Utilization.
• Failover Timeline: Trigger, Zeitpunkt, Dauer, Auswirkungen (Sessions, Drops, Latenz).
• Capacity KPIs: CPU, Dataplane Drops, Sessions, new sessions/s, NAT Ports.
• Policy Consistency: Config drift detection, Template-Versionen, last change ID.

Typische Anti-Patterns: Wie HA in der Praxis scheitert

• Active/Active ohne Symmetrie: ECMP/Hashing erzeugt asymmetrische Flows, State bricht, Kunden sehen Resets.
• HA ohne N-1: Failover führt in Überlast und damit zu sekundären Ausfällen.
• Zu aggressive Trigger: Failover bei transienten Spikes erzeugt Flapping und Instabilität.
• Split Brain ignoriert: fehlender Witness oder unklare Tie-breaker Regeln führen zu schwerwiegenden Events.
• Feature-Sprawl: TLS-Inspection/Proxying aktiv, ohne zu wissen, wie es sich im Failover verhält.
• Keine regelmäßigen Tests: HA funktioniert im Papierdesign, aber nicht unter realer Last.

Baseline-Checkliste: Active/Active vs. Active/Passive für Telco-Firewalls

• Zonenbasierte Entscheidung: A/P als Default für deterministische, hochkritische Domänen; A/A für Skalierung in High-Load Zonen.
• Traffic-Symmetrie: Flow-Pinning oder verlässlicher State-Sync; ECMP/Hashing bewusst designed.
• State-Sync Baseline: dedizierter Sync-Channel, Sync-Health Monitoring, Feature-Kompatibilität dokumentiert.
• Failover-Trigger: mehrstufig (Link/DP/CP/Sync), Split-Brain Schutz (Quorum/Witness).
• N-1 Kapazität: Headroom-Regeln und Failover-Tests unter realistischen Trafficprofilen und aktivierten Features.
• Wartungsprozesse: drain/shift, Post-Change Verification, Rollback-Runbooks.
• Observability: HA-States, Sync-Lag, Failover-Timeline, Session/NAT/Latency KPIs, Drift Detection.
• Übungen: regelmäßige HA-Tests (geplant und ungeplant) mit Messwerten und Lessons Learned.

Eine Baseline für Hochverfügbarkeit von Firewalls ist damit weniger eine Glaubensfrage zwischen Active/Active und Active/Passive, sondern ein strukturiertes Entscheidungs- und Betriebsmodell: Sie wählen den Modus passend zur Zone und zum Trafficprofil, sichern Symmetrie und State-Handling ab, planen N-1 Kapazität realistisch und machen Failover messbar. So wird HA nicht nur „eingeschaltet“, sondern zu einer verlässlichen Eigenschaft Ihrer Telco-Sicherheitsarchitektur.

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.