NGFW Performance Engineering: CPS, Throughput und Session Tables richtig planen

NGFW Performance Engineering ist die Disziplin, Next-Generation Firewalls so zu dimensionieren und zu betreiben, dass sie unter realen Telco-Lastprofilen stabil bleiben – insbesondere bei CPS (Connections per Second), Throughput (Durchsatz) und Session Tables (gleichzeitige Sessions). In Provider- und Carrier-Netzen reicht es nicht, sich auf Marketingzahlen zu verlassen: Datenpfade sind verteilt, Traffic ist heterogen (UDP, TCP, kurzlebige Sessions, lange Flows), und Security-Features wie IPS, App-ID, TLS-Inspection, URL-Filtering oder Logging können die Performance massiv beeinflussen. Ein schlechtes Performance-Design zeigt sich selten sofort, sondern in kritischen Momenten: DDoS-Lagen, Failover, Rekonvergenz, Release-Rollouts oder bei Traffic-Spitzen durch Events und Produktlaunches. Deshalb muss eine Telco-taugliche Planung von NGFW-Kapazität immer risikobasiert und messgetrieben sein: Welche pps- und CPS-Spitzen treten real auf? Wie groß werden Session-Tabellen in Normalbetrieb und im N+1-Failover? Welche Regeln und Features liegen im Hot Path? Dieser Beitrag zeigt, wie man CPS, Durchsatz und Session Tables richtig plant, wie man typische Performance-Fallen vermeidet und wie man Kapazität so auslegt, dass Security-by-Design nicht zur Availability-Falle wird.

Warum Durchsatz allein keine gute Dimensionierungskennzahl ist

Viele kaufen Firewalls nach „Gbps“. Für Telcos ist das gefährlich, weil Throughput nur einen Teil der Wahrheit beschreibt. Zwei Szenarien können denselben Durchsatz erzeugen, aber völlig unterschiedliche Belastung:

• Wenige große Flows: z. B. große TCP-Streams, relativ niedrige CPS und moderate Session-Anzahl.
• Sehr viele kleine Flows: z. B. DNS, NTP, API-Traffic, Web-Kleinsttransaktionen – hoher CPS, hoher pps, viele gleichzeitige Sessions.

NGFWs können bei gleichem Throughput in Szenario zwei deutlich früher „kippen“, weil Session-Tracking, Logging, IPS-Inspection und Policy-Matching pro Verbindung CPU/ASIC-Ressourcen verbrauchen. Telco-Performance-Engineering betrachtet deshalb immer Throughput, CPS und Concurrent Sessions zusammen – plus die realen Feature-Profile.

Die Kernmetriken: CPS, Throughput, Sessions und pps

Damit Performance planbar wird, brauchen Telcos eine gemeinsame Metrik-Sprache. Neben CPS, Throughput und Session Tables ist pps (packets per second) oft der versteckte Engpass.

• Throughput (Gbps): Datenmenge pro Zeit; wichtig, aber allein nicht ausreichend.
• CPS: neue Verbindungen pro Sekunde; zentral für Web/API, DNS, NAT-lastige Szenarien.
• Concurrent Sessions: Anzahl gleichzeitig aktiver Sessions; entscheidend für State Tables und Memory.
• pps: Paketfrequenz; relevant bei kleinen Paketen, DDoS, UDP und Control-ähnlichem Traffic.
• Session Setup Latency: Zeit, bis eine neue Session im Datenpfad sauber verarbeitet wird; kritisch für Echtzeitservices.
• Drop Reasons: warum wird gedroppt (Resource Exhaustion, policy deny, TCP state mismatch)?

Eine Baseline sollte definieren, welche dieser Metriken kontinuierlich überwacht werden, weil Kapazitätsprobleme oft als „kleine Drops“ beginnen, bevor es zu Outages kommt.

Telco-Trafficprofile: Warum CPS und Sessions oft explodieren

Provider-Traffic ist häufig „bursty“. Es gibt Peaks durch Mobilitätsereignisse, Kundenportale, DNS-Last, DDoS-Lagen, Wartungsfenster oder Routingrekonvergenz. Besonders CPS kann stark ansteigen, wenn viele Clients gleichzeitig neue Verbindungen aufbauen, etwa nach einem Failover oder einem regionalen Re-Routing.

Typische Treiber für hohe CPS im Provider-Netz

• DNS- und NTP-Traffic: viele kurze UDP-Transaktionen mit hoher pps-Last.
• Portal/API-Traffic: viele kurze HTTPS-Sessions, besonders bei Mobile Apps.
• NAT/CGNAT-Nähe: hohe Verbindungsdynamik, viele kurzlebige Sessions.
• Failover und Rebalancing: neue Sessions nach Umschaltung, „thundering herd“ Effekte.
• DDoS/Abuse: nicht nur Bandbreite, sondern extreme pps/CPS, z. B. SYN-Floods.

Ein Performance-Plan muss diese Spitzen explizit berücksichtigen. Eine Firewall, die „im Normalbetrieb“ stabil ist, kann im Failover instabil werden, wenn N+1 nicht dimensioniert wurde.

Statefulness und Session Tables: Das Herz jeder NGFW

NGFWs sind in den meisten Telco-Szenarien stateful. Das bedeutet: Jede Session belegt Ressourcen in einer Session Table (Memory und ggf. Hardware-State). Wenn diese Ressourcen knapp werden, drohen Drops, Retries, Latenzspitzen und im Worst Case instabile Failover-Verhalten.

Was Session Tables typischerweise beeinflusst

• Session Timeout: lange Timeouts erhöhen Concurrent Sessions; zu kurze Timeouts erzeugen mehr CPS.
• UDP vs. TCP: UDP kann viele kurzlebige States erzeugen; TCP hat State-Maschinen und Retransmits.
• App-ID/Inspection: zusätzliche Metadaten je Session erhöhen Speicherbedarf und CPU.
• NAT: pro Session zusätzliche State-Einträge (Original/Translated), Port-Pools als Engpass.
• Logging: pro Session zusätzliche Verarbeitung, insbesondere bei „log at session start/close“.

Eine Telco-Baseline sollte daher nicht nur maximale Session-Anzahl aus dem Datenblatt kennen, sondern auch den effektiven Session-Footprint unter den aktivierten Features. Eine Plattform, die „X Millionen Sessions“ kann, schafft unter vollem NGFW-Feature-Set oft deutlich weniger.

Dimensionierungsmethodik: Von Messwerten zu Kapazitätszielen

Solides NGFW Performance Engineering startet mit realen Messwerten und übersetzt sie in Kapazitätsziele. Ein pragmatischer Ansatz folgt drei Schritten: Baseline messen, Peaks modellieren, N+1 planen.

Schritt 1: Baseline messen

• Durchsatz: Average, P95/P99, Peak.
• CPS: Average, Burst Peaks, Peak in Failover-Fenstern.
• Concurrent Sessions: Peak und Dauer der Peaks (nicht nur Momentaufnahme).
• pps: besonders bei kleinen Paketen und UDP.
• Feature-Profile: welche Regeln triggern IPS/DPI/TLS, welche sind „fast path“?

Schritt 2: Peaks modellieren

• Failover-Peaks: wie viele neue Sessions entstehen nach Umschaltung (CPS Spike)?
• DDoS-Szenarien: pps/CPS Spitzen, SYN-Flood-Verhalten, Rate-Limit-Trigger.
• Maintenance-Rekonvergenz: Traffic-Shift zwischen Pods/Regionen, Hotspot-Risiko.
• Wachstum: realistische Growth-Faktoren für 12–24 Monate (Traffic, Sessions, Kunden).

Schritt 3: N+1 und Reserven planen

• N+1 Kapazität: ein Knoten fällt aus, die verbleibenden müssen stabil bleiben.
• Headroom: Reserven für Peaks und unvorhergesehene Ereignisse, nicht nur Durchschnittslast.
• Failure Domains: lieber mehrere kleinere Pods statt eine zentrale Mega-Firewall, um Blast Radius zu reduzieren.

Der zentrale Punkt: Telco-Designs dimensionieren nicht auf „Normalbetrieb“, sondern auf „Normalbetrieb plus Störung plus Wachstum“.

Feature-Kosten: IPS, App-ID, TLS-Inspection und Logging

NGFW-Features sind nicht kostenlos. Jede zusätzliche Inspektion kann den Datenpfad verlangsamen, CPS reduzieren oder Session Footprint erhöhen. Performance Engineering bedeutet daher, Features risikobasiert zu platzieren: nicht überall maximal, sondern dort, wo der Sicherheitsgewinn den Aufwand rechtfertigt.

Typische Performance-Kosten im Überblick

• IPS/Threat Prevention: erhöht CPU/ASIC-Last, kann bei False Positives Serviceausfälle verursachen.
• App-ID: nützlich für Policy-Granularität, erfordert jedoch Traffic-Klassifizierung und ggf. mehr State.
• TLS-Inspection: besonders teuer; zusätzlich komplex wegen Zertifikaten, Latenz und Datenschutz.
• URL Filtering: kann zusätzliche Lookups erfordern, abhängig von Implementierung.
• Detailliertes Logging: kann Logpipeline und Gerätequeues belasten; im Telco-Kontext oft ein versteckter Engpass.

Ein bewährtes Muster ist „Feature Staffelung“: In DMZ und an exponierten Edges mehr Security-Features (aber mit Kapazitätsreserve), in Core-Paths eher minimal und stabil, ergänzt durch Detection/Telemetry statt Inline-Inspection.

Policy-Design als Performance-Hebel: Regelwerke und Objektmodelle

Performance hängt auch vom Policy-Design ab. Unsaubere Regelwerke erzeugen mehr Matching-Aufwand, mehr Logs und mehr Fehler. Telcos sollten daher Policy-Baselines etablieren, die auch Performance berücksichtigen:

• Klare Zonenbeziehungen: Zone-to-Zone-Matrix reduziert „Suchraum“ und unklare Matches.
• Keine überbreiten Objekte: große Gruppen führen zu unnötigen Matches und schwerer Analyse.
• Shadow Rule Hygiene: überdeckte Regeln erzeugen Komplexität, ohne Nutzen.
• Logging gezielt: Logging dort, wo es Signal liefert (DMZ/OAM/Interconnect), nicht pauschal überall.

In GitOps-/Policy-as-Code-Ansätzen lassen sich diese Standards automatisiert prüfen, bevor sie die Performance im Betrieb beeinträchtigen.

HA, Failover und Session Synchronisation: Der unterschätzte Faktor

Carrier-Grade Firewalls laufen selten standalone. HA-Cluster, Active/Active-Designs oder Active/Passive-Failover sind Standard. Performance Engineering muss deshalb das Failover-Verhalten testen, nicht nur den Normalbetrieb.

Was in HA-Designs häufig schiefgeht

• State Sync Bottlenecks: Synchronisation kommt nicht hinterher, Sessions gehen verloren oder werden inkonsistent.
• N+1 Overload: nach Ausfall eines Knotens steigt CPS/Sessions auf den verbleibenden Knoten über das Limit.
• Asymmetrie: Hin- und Rückweg laufen über unterschiedliche Knoten, stateful Matching bricht.
• Failover Storm: mehrere Umschaltungen durch Instabilität (flapping), verstärken CPS-Peaks.

Eine Baseline sollte daher Failover-Tests als Pflicht definieren: nicht nur „es failt over“, sondern „es bleibt stabil unter realer Last und mit aktivierten Features“.

Kapazitätsplanung mit einfachen Modellen: Von CPS zu Sessions

Auch ohne perfekte Tools kann man grob modellieren, wie CPS und Session Timeouts die Session Table beeinflussen. Ein vereinfachtes Modell lautet:

$S\approx \mathrm{CPS}\times T$

Hier steht $S$ für gleichzeitige Sessions, $\mathrm{CPS}$ für neue Sessions pro Sekunde und $T$ für die mittlere Lebensdauer einer Session in Sekunden. Das Modell ist vereinfacht, aber hilfreich, um den Effekt von Timeouts zu verstehen: Wenn $T$ steigt, wächst $S$ linear. Wenn $T$ zu stark gesenkt wird, sinkt $S$, aber $\mathrm{CPS}$ kann steigen (mehr Reconnects). Performance Engineering bedeutet, diese Parameter bewusst zu wählen und anhand realer Trafficprofile zu kalibrieren.

Monitoring-Baseline: Frühwarnsignale für Capacity Exhaustion

Telcos sollten NGFW-Performance nicht erst dann sehen, wenn Kunden anrufen. Eine Monitoring-Baseline definiert Metriken und Alarme, die Kapazitätsprobleme früh anzeigen.

• CPU/Memory: sustained high CPU, Memory Pressure, Garbage Collection/Queueing (plattformabhängig).
• Session Table: Auslastung, Wachstumsgeschwindigkeit, Drops wegen State Limits.
• CPS und pps: Peaks, insbesondere nach Failover oder Traffic Shifts.
• Drop Reasons: Ressourcendrops vs. Policy-Drops unterscheiden.
• HA Health: Sync-Status, Failover-Events, Split-Brain Indikatoren.
• Logging Pipeline: Event Rate, Queue Backpressure, Collector Errors.

Ein praktisches Muster ist „Performance SLOs“: definierte Grenzwerte, ab denen Changes gestoppt oder Rollouts pausiert werden (Stop-the-Line), bevor ein Incident eskaliert.

Teststrategie: Realistische Lasttests statt Lab-Illusionen

Telco-Performance-Engineering braucht Tests, die reale Profile abbilden. Ein reiner iPerf-Durchsatztest ist selten aussagekräftig. Gute Tests berücksichtigen:

• Mix aus UDP/TCP: DNS-like UDP, Web-like TCP/HTTPS, längere Streams.
• CPS Peaks: Burst-Tests, die „thundering herd“ nach Failover simulieren.
• Feature-Profile: IPS/App-ID/TLS/Logging aktiv wie in Produktion (oder bewusst gestaffelt).
• HA/Failover unter Last: Umschaltung bei hoher Session-Last testen, nicht im Idle.
• Policy-Änderungen: Deployments unter Last (Change Risk Assessment), inklusive Rollback.

Tests sollten zudem in kleinen Failure Domains (Pods/Regionen) wiederholbar sein, damit neue Releases nicht jedes Mal neu erfunden werden müssen.

Design-Patterns für skalierbare NGFW-Architektur

Performance ist nicht nur eine Gerätefrage, sondern auch Architektur. Telcos können durch Design-Patterns die Anforderungen an einzelne Kontrollpunkte reduzieren.

• Pods statt Zentralisierung: regionale oder servicebasierte Pods reduzieren Blast Radius und verteilen Last.
• Service-Klassen trennen: DNS/NTP getrennt von Portal/API, weil CPS/pps Profile unterschiedlich sind.
• Fast Path vs. Deep Inspection: kritische High-Throughput-Pfade mit minimaler Inline-Inspection, ergänzt durch Detection.
• Upstream Mitigation: volumetrische DDoS-Last vor der NGFW abfangen, damit CPS/pps nicht die Control Plane zerstören.

Typische Performance-Fallen und wie man sie vermeidet

• Dimensionierung nur nach Gbps: CPS/pps unterschätzt; Baseline fordert CPS und Session Peak-Modelle.
• Kein N+1: Failover führt zu Overload; Baseline verlangt N+1 und Failover-Tests unter Last.
• Feature-Big-Bang: IPS/TLS/Logging überall aktiv; Baseline staffelt Features risikobasiert und testet gezielt.
• Logging als Engpass: Logpipeline überlastet Geräte; Baseline nutzt selektives Logging und überwacht Backpressure.
• Timeouts „nach Gefühl“: Session Tables explodieren oder CPS steigt; Baseline kalibriert Timeouts mit Messdaten.
• Asymmetrie ignoriert: stateful Matching bricht; Baseline fordert Pfad-Disziplin und Architekturchecks.

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.