Performance Troubleshooting: Throughput, CPU, Crypto-Offload und Bottlenecks

Beim Performance Troubleshooting von VPNs und verschlüsselten Overlays scheitern viele Teams nicht an fehlenden Tools, sondern an falschen Annahmen: „Der Tunnel ist up, also ist das Netzwerk ok“, „Mehr Bandbreite löst das Problem“ oder „CPU ist niedrig, also kann es kein Krypto-Bottleneck sein“. In der Realität ist VPN-Performance ein Zusammenspiel aus Throughput, Latenz, Paketverlust, MTU/MSS, Session-Mechanik, CPU- und Memory-Pfaden, Crypto-Offload sowie der Frage, wo im Datenpfad tatsächlich verschlüsselt, entkapselt, gefiltert und geroutet wird. Hinzu kommen Underlay-Effekte (ISP, Carrier NAT, Peering) und Architekturentscheidungen (Full Tunnel vs. Split Tunnel, Hub-and-Spoke vs. Mesh, Cloud Egress/SASE). Dieser Artikel zeigt ein systematisches Vorgehen, um Engpässe zuverlässig zu finden: von Messmethoden über typische Bottlenecks bis hin zu konkreten Hypothesen, die Sie anhand von Metriken, Countern und Traces verifizieren können. Ziel ist nicht „ein paar Tipps“, sondern ein reproduzierbarer Troubleshooting-Workflow, der in Incident-Situationen schnell zu belastbaren Ergebnissen führt.

Warum VPN-Performance schwieriger ist als „Speedtest“

VPNs verändern die Transportbedingungen: Pakete werden größer (Encapsulation Overhead), Pfade werden stateful (SAs, Sessions, NAT-Mappings), Kryptografie wird rechenintensiv (Handshake, Rekey, Datenkanal), und Sicherheitsfunktionen greifen (MFA, Posture, Policy, Inspection). Das führt zu typischen Fallstricken:

• Single Flow vs. Multi Flow: Ein einzelner TCP-Stream liefert oft deutlich weniger Durchsatz als viele parallele Streams, auch wenn die Leitung „eigentlich“ schnell ist.
• TCP über VPN: Paketverlust und Jitter wirken stärker, weil TCP Congestion Control aggressiv reduziert.
• Encapsulation Overhead: MTU-Probleme führen zu Fragmentierung oder PMTUD-Blackholes; das sieht aus wie „langsam“ oder „bricht ab“.
• Krypto-CPU ist nicht linear: Ein Gateway kann „nur“ 30% CPU anzeigen, obwohl ein einzelner Thread, ein Crypto-Worker oder ein Interrupt-Core am Limit ist.

Erst klären: Was bedeutet „Performance-Problem“ genau?

Bevor Sie messen, definieren Sie das Symptom. „Langsam“ kann verschiedene Ursachen haben, die völlig unterschiedliche Messpunkte benötigen.

• Niedriger Throughput: Dateiübertragungen dauern zu lange, Speedtests zeigen geringe Mbit/s.
• Hohe Latenz: Anwendungen fühlen sich „zäh“ an, RDP/SSH stockt, VoIP leidet.
• Stottern/Timeouts: Sessions reißen ab, Webapps laden sporadisch nicht, VPN flappt.
• Skalierungsproblem: Einzelne Nutzer sind ok, aber bei Peak-Last bricht alles ein.

Notieren Sie immer: betroffene Profile (User/Vendor/Admin), Region/ISP, Uhrzeit, Client-OS, Protokoll (IPsec/IKEv2, TLS-VPN, WireGuard), Full vs. Split Tunnel und ob das Problem bei einem einzelnen Ziel oder generell auftritt.

Messstrategie: Von End-to-End zu Layer-by-Layer

Ein robustes Troubleshooting startet mit End-to-End-Messungen (Symptome) und ergänzt dann Ursachenmetriken (CPU, Drops, Crypto Engine). Ohne End-to-End riskieren Sie „Optimierung am falschen Ende“.

• End-to-End: RTT, Loss, Jitter, Throughput zwischen Client und definiertem Ziel (z. B. Intranet, Bastion, Testserver).
• Gateway-Health: Session-Counts, Handshake-Rate, Rekey-Events, SA-Tabellen, Drops, Queue Depth.
• Host/OS-Health (bei Software-Gateways): CPU per Core, Softirq/Interrupt-Last, NIC-Ring-Overruns, Crypto-Libraries.
• Underlay: ISP-Loss, peering-bedingte Latenz, Paketgrößenlimits, NAT-Timeouts.

Für reproduzierbare Throughput-Messungen ist iPerf ein gängiges Werkzeug, weil Sie Streams, Fenstergrößen und Dauer kontrollieren können.

Throughput richtig messen: Single Stream, Parallel Streams, UDP vs. TCP

Ein häufiger Fehler ist, einen einzelnen TCP-Stream als „Bandbreite“ zu interpretieren. Gerade über WAN/VPN begrenzen RTT und Loss den Durchsatz. Faustregel: Mehr RTT und mehr Loss → weniger TCP-Throughput, selbst bei hoher Linkrate.

Praktische Messvarianten

• TCP Single Stream: Gut, um „User Experience“ für einzelne Transfers zu approximieren, aber oft nicht repräsentativ für die Linkkapazität.
• TCP Multi Stream: Zeigt, ob der Pfad insgesamt Bandbreite liefern kann (Aggregation). Wenn Multi Stream gut, Single Stream schlecht: TCP-Tuning/Windowing/RTT-Limit wahrscheinlich.
• UDP Test: Hilft, maximale Rate und Loss/Jitter zu sehen, unabhängig von TCP Congestion Control. Vorsicht: UDP kann das Netz überfahren.

Wenn Sie TCP-Throughput grob abschätzen wollen, ist das Bandwidth-Delay-Product (BDP) ein hilfreiches Konzept: $\mathrm{BDP}=\mathrm{Bandwidth}\times \mathrm{RTT}$. Ein zu kleines TCP-Fenster (oder zu konservative OS-Defaults) kann den Durchsatz stark begrenzen, auch wenn der Tunnel technisch ok ist.

CPU-Bottlenecks: Warum „CPU 40%“ trotzdem „CPU-Limit“ sein kann

VPN-Durchsatz ist häufig CPU-limitiert – besonders bei softwarebasierten Gateways, virtuellen Appliances oder wenn Inspection/Firewalling im selben Pfad hängt. CPU-Probleme zeigen sich jedoch nicht immer als „CPU 100%“ im Mittel.

• Single-Core Saturation: Ein Crypto-Worker oder ein Interrupt-Core ist am Limit, während andere Cores idle sind.
• Softirq/Interrupt Bottleneck: Paketverarbeitung hängt an Kernelpfaden (NIC, IRQ Affinity, NAPI), nicht an Userland.
• Context Switch/Lock Contention: Multithreading skaliert nicht linear; Locks und Queues bremsen.
• Per-Packet Cost: Kleine Pakete (pps) sind teurer als große Pakete (bps). Ein pps-Limit sieht aus wie „Bandbreite fehlt“.

Indikatoren für CPU-Limit im VPN-Pfad

• Durchsatz skaliert nicht mit Link: Mehr Bandbreite oder schnellerer ISP bringt nichts.
• Performance fällt bei kleinen Paketen: VoIP/Interactive ok oder schlecht? Oft pps-abhängig.
• CPU-Spikes bei Rekey/Handshake: Viele neue Sessions oder kurze Lifetimes führen zu CPU-Lastspitzen.
• Queue Drops: Output Drops am Interface oder in Software-Queues bei gleichzeitig moderater Durchschnitts-CPU.

Crypto-Offload: Wann Hardware hilft und wann nicht

Crypto-Offload bedeutet, dass kryptografische Operationen (z. B. AES-GCM, ChaCha20-Poly1305, DH/ECDHE) durch Hardware beschleunigt werden: dedizierte ASICs, NPUs, SmartNICs oder CPU-Instruktionen (AES-NI). Das kann Durchsatz und CPU-Effizienz dramatisch verbessern – aber nur, wenn der gesamte Datenpfad offload-fähig ist.

• Instruktions-Offload: Moderne CPUs mit AES-NI beschleunigen AES erheblich; ohne AES-NI wird AES-GCM schnell zum Bottleneck.
• Appliance-Offload: Einige Gateways offloaden nur den Datenkanal (ESP), aber nicht Handshake/Policy/Inspection.
• Cloud-Offload: In virtuellen Umgebungen hängt Offload von VM-Typen, vCPU-Pinning und NIC-Features ab.

Typische Offload-Fallen

• Offload aktiv, aber nicht genutzt: Bestimmte Cipher Suites oder Paketpfade triggern Software-Fallback.
• Inspection bricht Offload: Wenn Traffic durch IDS/Proxy/DLP geht, wird oft in Software dekapselt/rekapselt.
• Small Packet pps: Offload hilft bei Crypto, aber pps-Limits (NIC/CPU/IRQ) bleiben bestehen.

Für TLS- und Krypto-Policy-Orientierung (indirekt relevant für Performance, weil bestimmte Suites unterschiedlich teuer sind) sind TLS 1.3 (RFC 8446) und die NIST SP 800-52r2 als Leitlinien nützlich.

Bottleneck-Klassen: Wo VPN-Throughput typischerweise hängen bleibt

In der Praxis lassen sich die meisten Performance-Probleme auf wenige Bottleneck-Klassen zurückführen. Wenn Sie diese Klassen systematisch prüfen, sparen Sie Zeit.

• Underlay Bandbreite: ISP/Transit-Limit, Peering-Engpass, Policers/Shaping.
• Underlay Qualität: Loss/Jitter/RTT, die TCP ausbremsen (besonders über lange Strecken).
• MTU/MSS: Fragmentierung oder PMTUD-Blackholes – typisch bei IPsec/TLS über NAT/Firewalls.
• Gateway CPU/Crypto: Datenkanal- oder Handshake-Last, pps-Limit, Offload-Fallback.
• State/Session Limits: SA-Tabellen, conntrack, NAT tables, Memory.
• Backends: AAA/IdP/MFA-Timeouts erhöhen Connect-Zeit, wirken wie „Performanceproblem“.
• Policy/Inspection: Firewall/Proxy/DLP im Pfad begrenzen Throughput oder erhöhen Latenz.

MTU/MSS und Fragmentierung: Der Klassiker, der „wie langsam“ aussieht

Encapsulation (IPsec, GRE, WireGuard, TLS) erhöht Paketgröße. Wenn der Underlay-Pfad die resultierende MTU nicht zulässt und ICMP/PMTUD nicht sauber funktioniert, entstehen Blackholes oder Fragmentierung, die TCP massiv verlangsamt.

• Symptome: Kleine Requests ok, große Downloads hängen; bestimmte Websites gehen nicht; SMB/RDP stockt.
• Indikatoren: Fragment Counters, ICMP „Fragmentation Needed“ fehlt, MSS/MTU-Mismatch.
• Fixes: MSS-Clamping für TCP, konservative Tunnel-MTU, ICMP gezielt erlauben für PMTUD.

Für PMTUD sind RFC 1191 (IPv4) und RFC 8201 (IPv6) die Protokollgrundlagen.

Handshake, Rekey und Lifetime: Performanceeinbrüche im Zeitmuster erkennen

Viele Performanceprobleme sind periodisch: alle 30 oder 60 Minuten gibt es kurze Unterbrechungen oder Throughput-Drops. Häufig steckt Rekey dahinter (IKE/Child SA, TLS Sessions), insbesondere wenn Lifetimes oder Rekey-Overlap schlecht abgestimmt sind.

• Symptome: Kurze Interrupts, TCP Retransmits, RDP Freeze, VoIP Dropouts.
• Messung: Rekey-Events in Logs, DPD/Keepalive Fails, SA-Rollover Counters.
• Fixes: Rekey-Parameter harmonisieren (beide Seiten), Rekey-Overlap zulassen, nicht zu aggressive Lifetimes.

Für IKEv2 ist RFC 7296 eine grundlegende Referenz, auch wenn konkrete Timer vendor-spezifisch sind.

Queueing und Drops: Wenn die Datenebene überläuft

Throughput-Probleme entstehen oft durch Drops – und Drops müssen nicht „im Internet“ passieren. Sie können auf dem Gateway selbst passieren: Interface Output Drops, Software-Queue Drops, NIC Ring Overruns. Kleine Drops reichen, um TCP massiv zu bremsen.

• Wo prüfen: Ingress/egress Interface Counters, Queue Drops, discards, overruns, errors.
• Typische Ursachen: CPU/interrupt overload, zu kleine Queue, Shaping/Policing, Burst-Last, Microbursts.
• Fixes: Kapazität (Scale-out), Queue-Tuning, Traffic Shaping/QoS, pps reduzieren (z. B. Aggregation), Offload verbessern.

QoS und Traffic Classes: Performance ist nicht für alle gleich

Ohne QoS kann ein Backup-Job oder ein großer Download interaktive Anwendungen über den Tunnel „erdrücken“. Gerade Full-Tunnel-Designs und zentrale Hubs profitieren von klaren Traffic-Klassen.

• Interaktiv: VoIP, RDP, SSH → priorisieren (Low Latency).
• Standard: Web/Business Apps → stabile Bandbreite.
• Bulk: Backups, große Transfers → begrenzen oder in Off-Peak verschieben.

Wichtig ist, QoS-End-to-End zu denken: Markierung am Client oder Edge, Durchsetzung am Gateway, und Unterstützung im Underlay (oder zumindest lokale Queues).

Cloud und virtuelle Appliances: Spezielle Performance-Fallen

In Cloud- oder virtualisierten Umgebungen entstehen zusätzliche Bottlenecks, die bei Hardware-Appliances nicht existieren.

• vCPU-Limits: Zu wenige vCPUs, falscher Instanztyp, fehlende CPU-Pinning-Strategie.
• NIC-Performance: Virtuelle NICs, ENA/virtio-Treiber, PPS-Limits, fehlende Offload-Features.
• Shared Tenancy: Noisy Neighbors beeinflussen I/O und CPU.
• East-West vs. North-South: Trafficpfade in der Cloud können unerwartet über zusätzliche Hops laufen.

Ein zuverlässiger Ansatz ist, Testpfade innerhalb der Cloud (gleiche Region) und über Regionsgrenzen zu messen, um Underlay- und Plattformlimits zu trennen.

Troubleshooting-Workflow: Hypothesengetrieben statt „wildes Herumprobieren“

Ein effektiver Workflow stellt Hypothesen auf und falsifiziert sie mit Messungen. So vermeiden Sie, dass Sie „Fixes“ implementieren, die das Problem nur zufällig kaschieren.

• Schritt 1: Symptom präzisieren (Throughput vs. Latenz vs. Flaps) und Scope eingrenzen (Region, Profil, Zielsystem).
• Schritt 2: End-to-End messen (RTT/Loss/Throughput), idealerweise mit reproduzierbaren Tools (z. B. iPerf).
• Schritt 3: Kontroll- vs. Datenpfad trennen: Tunnel up? Rekey/DPD ok? Data-plane Probes ok?
• Schritt 4: Bottleneck-Klasse identifizieren: Underlay, MTU, CPU/Crypto, Drops, Policy/Inspection, Backend.
• Schritt 5: Fix implementieren und erneut messen (vorher/nachher), inklusive Peak-Last-Szenario.

Evidence sammeln: Welche Daten Sie in Incidents immer brauchen

Für schnelle Root-Cause-Analysen ist eine Mindestmenge an Evidenz hilfreich. Wenn Sie diese Daten standardisiert haben, sinkt die Mean Time to Repair erheblich.

• VPN-Session-Metadaten: Profil, Gateway-Node, Start/Stop, zugewiesene IP, Rekey-Events, Failure Reasons.
• Gateway-Metriken: CPU pro Core, Crypto utilization, SA table utilization, handshake rate, drops/errors.
• Underlay-Metriken: RTT/Loss/Jitter (idealerweise per Probe), ISP/Uplink Status, interface counters.
• Client-Kontext: OS, Client-Version, Netztyp (WLAN/Mobilfunk), MTU-Tests, ob andere Ziele betroffen sind.
• Change-Kontext: Wurden Cipher Suites, Lifetimes, Policies, NAT-Regeln, SASE-Egress oder Routen geändert?

Alert Engineering für Performance: Alarme, die echte Bottlenecks anzeigen

Performance-Alarme sollten symptomorientiert sein (User Experience) und durch Ursachenmetriken ergänzt werden. Das vermeidet Alarmflut durch „CPU hoch“ ohne echten Impact. Für Alert-Grundlagen ist das Google SRE Book ein guter Referenzpunkt, weil es zwischen Symptom- und Cause-Alerts unterscheidet.

• Symptom-Alerts: Throughput p95 sinkt, RTT p95 steigt, Loss steigt, Connect Time p95 steigt, Session Flap Rate steigt.
• Cause-Alerts: SA table near full, crypto engine saturation, per-core CPU saturation, interface drops spike, AAA timeout rate.
• Multi-signal gating: Alarm nur, wenn Symptom und passende Ursache gleichzeitig auftreten (z. B. Throughput drop + crypto saturation).

Typische Fixes nach Root Cause: Was wirklich hilft

Wenn Sie den Bottleneck sauber identifiziert haben, sind die Fixes meist klar. Wichtig ist, nicht „blind“ an allen Schrauben zu drehen, sondern gezielt.

• CPU/Crypto-Limit: Scale-out (mehr Knoten), stärkere Plattform, Offload aktivieren/validieren, Cipher-Sets optimieren, PPS reduzieren.
• MTU/MSS: MSS-Clamping, Tunnel-MTU, PMTUD-freundliche ICMP-Policies, Fragmentation vermeiden.
• Underlay-Degradation: Multi-ISP, bessere Peering-Pfade, SD-WAN/Path Steering, SLA-basiertes Failover.
• Backend-Timeouts (AAA/IdP): Redundanz, Caching, Timeouts/Backoff, Monitoring, Degraded-Mode-Policies.
• Policy/Inspection Bottleneck: Split Tunnel für unkritische Ziele, per-App Access (ZTNA), Skalierung von Proxy/DLP, klare Traffic-Klassen.

Checkliste: Performance Troubleshooting für VPNs und verschlüsselte Overlays

• Symptom präzisieren: Throughput vs. Latenz vs. Flaps vs. Skalierung, Scope (Region/Profil/Ziel).
• Richtig messen: TCP Single vs. Multi Stream, UDP Loss/Jitter, p95/p99 statt Mittelwert.
• MTU/MSS prüfen: Encapsulation Overhead, Fragmentation Counters, PMTUD, MSS-Clamping.
• CPU richtig interpretieren: Per-Core, Softirq/IRQ, pps-Limits, Queue Drops, nicht nur Durchschnitt.
• Offload validieren: Wird Hardware/Instruktion wirklich genutzt oder gibt es Fallback?
• Rekey/Handshake analysieren: Periodische Einbrüche, Lifetimes, Overlap, DPD/Keepalive.
• Drops & Queues: Interface drops, discards, overruns; Shaping/QoS und Microbursts.
• Backends einbeziehen: AAA/IdP/MFA Latenz und Errors als Teil des Servicepfads.
• Fix verifizieren: Vorher/Nachher-Messung, Peak-Last-Szenario, Regressionstests.
• Monitoring verbessern: Symptom- und Cause-Alerts, SLI/SLO, Runbooks, Change-Markers.

• iPerf: Reproduzierbare Throughput- und Loss-Tests
• RFC 8446: TLS 1.3 (Handshake- und Krypto-Grundlagen)
• RFC 7296: IKEv2 (SA-Handling, Rekey-Grundlagen)
• RFC 1191: Path MTU Discovery (IPv4)
• RFC 8201: Path MTU Discovery (IPv6)
• Google SRE Book: SLIs/SLOs und Alerting für zuverlässige Performance

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.