Site icon bintorosoft.com

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

Red Snapper

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:

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.

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

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

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

Schritt 2: Peaks modellieren

Schritt 3: N+1 und Reserven planen

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

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:

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

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≈CPS×T

Hier steht S für gleichzeitige Sessions, 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 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.

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:

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.

Typische Performance-Fallen und wie man sie vermeidet

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

Sie erhalten

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.

Exit mobile version