IPsec Performance Tuning: AES-GCM, Offload, Rekey Timer, Throughput

IPsec-Performance ist selten nur „mehr Bandbreite kaufen“. In der Praxis bremsen vier Faktoren: Wahl der Crypto-Suite (AES-GCM vs. AES-CBC+HMAC), Hardware-Offload/Dataplane-Path (QFP/ASIC vs. CPU), Rekey- und DPD-Timer (Mikrospikes, Flaps) sowie MTU/Fragmentierung (Goodput-Verlust, Retransmits). Wer IPsec im Gigabit-Bereich stabil betreiben will, muss deshalb bewusst tunen: starke, aber effiziente Algorithmen wählen, Offload sicherstellen, Rekey-Events entschärfen und Throughput richtig messen (nicht nur „Interface up“). Dieser Artikel zeigt praxisnahe Tuning-Strategien für Cisco IOS XE.

Performance-Grundlage: Throughput vs. Goodput

Viele Messungen betrachten nur „Bits auf dem Interface“. Für Anwendungen zählt aber Goodput: Nutzdaten ohne Overhead und Retransmits. IPsec erhöht Overhead und kann bei MTU-Problemen Retransmits stark erhöhen.

Goodput-Modell (vereinfacht)

$\text{Goodput}\approx \text{Throughput}\times \text{(1 – Overhead)}\times \text{(1 – RetransmitRate)}$

• Overhead: ESP/IKE/Encapsulation + ggf. GRE
• Retransmits: meist MTU/PMTUD, Drops oder Queueing

AES-GCM: Warum es oft schneller (und einfacher) ist

AES-GCM ist AEAD: Verschlüsselung und Integrität in einem Algorithmus. Das reduziert Rechenarbeit gegenüber AES-CBC + HMAC und ist auf vielen Plattformen besser hardwarebeschleunigt. Operativ ist es auch „sauberer“, weil du weniger Kombinationsfehler (Cipher/Hash-Mismatch) hast.

• AEAD: Encryption + Integrity in einem Schritt
• Weniger CPU-Work als CBC+HMAC (typisch)
• Gute Offload-Unterstützung auf modernen Plattformen
• Einfachere Policy-Standards (weniger Variationen)

IPsec Transform Set mit AES-GCM (Pattern)

crypto ipsec transform-set TS-ESP-AESGCM esp-gcm 256
 mode tunnel

Offload entscheiden: CPU-Path vs. Hardware-Path

Der größte Performance-Sprung kommt oft nicht von „anderer Cipher“, sondern von Offload. Wenn Crypto im CPU-Path landet, bekommst du früh CPU-Spikes und Drops. Wenn Crypto sauber in der Hardware-Dataplane (z. B. QFP/ASIC) läuft, sind deutlich höhere Throughputs stabil möglich.

• Hardware-Path: höherer Durchsatz, weniger Jitter
• CPU-Path: früher Bottleneck, empfindlicher bei kleinen Paketen
• Wichtig: Nicht jede Feature-Kombination ist offloadfähig

Indizien für Bottleneck (Praxis)

show processes cpu sorted
show platform hardware qfp active statistics drop
show interfaces | include drops|error

Rekey Timer: Warum „kurze Lifetimes“ Performance kosten

Rekeys erzeugen Lastspitzen: neue SAs werden aufgebaut, Keys berechnet, eventuell kurze Unterbrechungen. Wenn Lifetimes zu kurz sind, wird das zum periodischen Micro-Outage – besonders bei vielen Tunneln oder bei asymmetrischem Traffic. Ziel ist ein stabiler Rekey-Rhythmus ohne Synchronisation aller Peers.

• Zu kurze Lifetimes: häufige Rekeys, mehr CPU/Control Plane
• Synchronisierte Rekeys: viele Tunnels rekeyen gleichzeitig
• Asymmetrischer Traffic: Rekey-Timeouts wirken „random“

Rekey-Last (vereinfacht)

$\text{RekeyEvents/h}\approx \frac{\text{NumberOfTunnels}}{\text{LifetimeHours}}$

Timer-Tuning: DPD, Keepalives, BFD – Stabilität ohne Flapping

Zu aggressive DPD/Keepalive-Timer verursachen Flaps bei kurzzeitigen Loss/Queueing-Ereignissen. Zu langsame Timer verlängern Failover. Ein stabiler Kompromiss ist wichtig, besonders auf Internet-Underlays.

• DPD zu aggressiv: Tunnels flappen bei transientem Loss
• DPD zu langsam: Failover träge
• BFD (bei VTI/BGP): schnelle Erkennung ohne „Crypto Flaps“

DPD Pattern (IKEv2)

crypto ikev2 profile IKEV2-PROF
 dpd 10 3 on-demand

MTU/PMTUD: Der häufigste Goodput-Killer

Wenn PMTUD kaputt ist, leidet Goodput massiv durch Retransmits. IPsec erhöht Overhead, und in Kombination mit PPPoE, GRE oder MPLS entstehen schnell Blackholes. MSS Clamping ist ein pragmatischer Fix für TCP.

• Symptom: kleine Pakete ok, große Transfers brechen
• Ursache: ICMP blockiert oder Pfad-MTU kleiner als erwartet
• Fix: MSS Clamping am Tunnel/Edge

MSS Clamping (Pattern)

interface Tunnel100
 ip tcp adjust-mss 1360

Packet Size Matters: Kleine Pakete sind „teurer“ als große

IPsec-Performance hängt stark von Paketgrößen ab. Viele kleine Pakete (VoIP, ACKs, DNS) erzeugen deutlich mehr Crypto-Operationen pro Sekunde als wenige große Pakete. Deshalb wirken Speedtests manchmal „gut“, während Voice/Jitter schlecht ist.

• Viele kleine Pakete → pps-Bottleneck (CPU/Dataplane)
• Große Pakete → throughput-lastig, oft leichter zu beschleunigen
• QoS/LLQ für Voice über IPsec oft notwendig

QoS und Crypto: Marking vor Verschlüsselung planen

Wenn du QoS über IPsec willst, musst du wissen, wo klassifiziert wird: vor oder nach Verschlüsselung. Best Practice ist: Traffic am Ingress markieren (DSCP), dann so konfigurieren, dass Marking erhalten bleibt oder sinnvoll gemappt wird (je nach Underlay/MPLS).

• Marking am LAN-Ingress (DSCP) ist stabil
• Queueing am WAN-Egress schützt Voice/Control Traffic
• Bei MPLS: DSCP→TC Mapping konsistent designen

Messung: Wie du IPsec-Throughput korrekt überprüfst

Für belastbare Messungen brauchst du: (1) definierte Testflows, (2) gleichzeitige CPU/QFP- und Drop-Checks, (3) Trennung von Underlay- und Overlay-Limitierungen. „Speedtest im Browser“ ist als Diagnose oft zu unpräzise.

On-Box Checks während Last

show crypto ipsec sa
show processes cpu sorted
show interfaces | include rate|drops|error
show platform hardware qfp active statistics drop

IPsec SA Counters interpretieren

• encaps/decaps steigen symmetrisch → Traffic fließt
• decaps fehlen → Rückweg/Asymmetry/ACL/State
• Replay drops → Jitter/Out-of-order, ggf. ECMP/Path Issues

Konfigurationsmuster: Moderne Standard-Suites (Pattern)

Das folgende Muster zeigt ein praxistaugliches Baseline-Set: IKEv2 mit AES-GCM und SHA-256 PRF, IPsec mit AES-GCM und PFS. Passe DH-Gruppen und Keylength an deine Security-Policy und Plattformleistung an.

IKEv2 Proposal/Policy

crypto ikev2 proposal IKEV2-PROP
 encryption aes-gcm-256
 prf sha256
 group 14
crypto ikev2 policy IKEV2-POL

proposal IKEV2-PROP

IPsec Transform/Profile

crypto ipsec transform-set TS-ESP-AESGCM esp-gcm 256
 mode tunnel
crypto ipsec profile IPSEC-PROF

set transform-set TS-ESP-AESGCM

set pfs group14

Edge-Cases: Rekey-Spikes, Out-of-Order und Replay Drops

Bei hohen Throughputs oder bei ECMP/Unequal Paths können Pakete out-of-order ankommen. IPsec Replay Protection kann dann Drops erzeugen. Gleichzeitig können Rekeys kurzzeitig CPU/Control Plane belasten. In solchen Fällen ist saubere Pfadsymmetrie und ein Blick auf Replay-Counter wichtig.

Replay/Drop Hinweise

show crypto ipsec sa | include replay|drop
show ip cef exact-route <src> <dst>

Best Practices: Stabiler High-Throughput IPsec Betrieb

Diese Punkte liefern in der Praxis den größten Nutzen: starke, effiziente Cipher, Offload sicherstellen, MTU/PMTUD stabilisieren und Rekey-Last kontrollieren.

• AES-GCM bevorzugen (wenn kompatibel)
• Hardware-Offload prüfen und Feature-Kombinationen vermeiden, die Offload brechen
• MSS Clamping standardisieren bei heterogenen WANs
• Rekey-Lifetimes nicht zu kurz, Rekeys nicht synchronisieren
• Monitoring: CPU, Drops, SA Counters, Replay Drops

Quick-Runbook: IPsec Performance Incident unter Zeitdruck

Diese Sequenz hilft, schnell zu entscheiden: Crypto-Bottleneck, Underlay-Drops oder MTU/PMTUD?

show crypto ikev2 sa
show crypto ipsec sa
show crypto ipsec sa | include replay|drop
show processes cpu sorted
show interfaces | include rate|drops|error
show platform hardware qfp active statistics drop
ping <dst> df-bit size 1400 repeat 5

Konfiguration speichern

Router# copy running-config startup-config

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.