Site icon bintorosoft.com

VPN Performance: MTU, Fragmentierung und Throughput verbessern

Red Snapper

VPN-Performance-Probleme wirken oft wie „langsam“ oder „instabil“, haben aber sehr konkrete Ursachen: zu große Pakete (MTU), Fragmentierung im Pfad, kaputtes Path MTU Discovery (PMTUD) oder CPU-Limits durch Verschlüsselung. Gerade bei IPsec, GRE over IPsec und DMVPN addiert sich Overhead, wodurch die effektive Nutzlast sinkt. Mit sauberem MTU/MSS-Tuning, gezielter Fragmentierungsstrategie und Throughput-Checks kannst du spürbar bessere Performance erreichen – ohne die Security zu schwächen.

Warum VPNs Performance kosten

Ein VPN fügt Header hinzu und verschlüsselt Daten. Das erhöht Paketgröße und CPU-Aufwand. Wenn der Underlay-Pfad keine großen Pakete akzeptiert oder ICMP blockiert ist, entstehen Retransmits und Timeouts – das kostet Throughput deutlich mehr als „ein bisschen Overhead“.

MTU, MSS und Fragmentierung: die drei Stellschrauben

MTU ist die maximale IP-Paketgröße, MSS ist die maximale TCP-Nutzdatenlänge. Fragmentierung passiert, wenn ein Paket größer ist als die MTU des nächsten Hops. Im VPN-Kontext ist MSS-Clamping oft der schnellste Praxisfix für HTTPS/Downloads.

MSS-Formel (IPv4, ohne Optionen)

MSS = MTU – 20 – 20

Typische Overhead-Szenarien (Praxisorientierung)

Je nach VPN-Design sinkt die effektive MTU. Du brauchst nicht jede Bytezahl perfekt zu kennen – aber du musst erkennen, wann du konservativer clampen solltest (z. B. GRE over IPsec oder DMVPN).

Diagnose Schritt 1: DF-Ping für Path MTU testen

Mit DF-Pings findest du die größte Paketgröße, die ohne Fragmentierung durch den Pfad kommt. Wenn DF-Pings ab einer Größe scheitern, ist der Path kleiner als gedacht oder ICMP wird gedroppt.

DF-Ping auf Cisco (Beispiel)

Router# ping 8.8.8.8 df-bit size 1472
Router# ping 8.8.8.8 df-bit size 1452
Router# ping 8.8.8.8 df-bit size 1400

Interpretation (IPv4)

Die Ping-„size“ ist Nutzlast. Rechne grob +28 Byte (IP+ICMP), um Richtung MTU zu denken.

MTU ≈ PingSize + 28

Diagnose Schritt 2: IPsec-Counters und Drops prüfen

Wenn VPN „langsam“ ist, prüfe, ob viele Drops/Errors auftreten. Besonders aussagekräftig sind „decrypt/verify failed“, „no sa“, Interface-Drops und steigende Retransmits auf Client-Seite.

Router# show crypto ipsec sa
Router# show interfaces tunnel0 | include MTU|drops|error
Router# show interfaces gigabitEthernet0/1 | include drops|error

Fix 1: MSS-Clamping setzen (TCP-Performance-Quickwin)

Für die meisten Web-/App-Probleme im VPN ist MSS-Clamping der schnellste Fix, weil er ohne globale MTU-Änderung wirkt. Setze ihn dort, wo der Overhead entsteht: Tunnel-Interface, Dialer (PPPoE) oder WAN-Edge.

Startwerte (praxisnah)

MSS-Clamp am Tunnel (GRE/IPsec/DMVPN)

Router# configure terminal
Router(config)# interface tunnel0
Router(config-if)# ip tcp adjust-mss 1360
Router(config-if)# end

MSS-Clamp am PPPoE-Dialer

Router# configure terminal
Router(config)# interface dialer0
Router(config-if)# ip tcp adjust-mss 1452
Router(config-if)# end

Fix 2: MTU auf Tunnel/Interface korrekt setzen

Wenn du die effektive MTU kennst (oder durch DF-Ping ermittelt hast), kannst du MTU am relevanten Interface setzen. Das wirkt auch für UDP, ist aber invasiver als MSS-Clamping.

MTU am Tunnel setzen (Beispiel)

Router# configure terminal
Router(config)# interface tunnel0
Router(config-if)# ip mtu 1400
Router(config-if)# end

MTU am Dialer (PPPoE)

Router# configure terminal
Router(config)# interface dialer0
Router(config-if)# mtu 1492
Router(config-if)# end

Fix 3: Fragmentierungsstrategie bewusst wählen

Im VPN-Design gibt es grundsätzlich zwei Ansätze: (1) Fragmentierung vermeiden (MTU/MSS reduzieren) oder (2) Fragmentierung kontrolliert zulassen. In den meisten Unternehmensnetzen ist „vermeiden“ besser, weil Fragmentierung störanfällig ist.

Fix 4: NAT-T und UDP/4500 berücksichtigen

Wenn NAT-T aktiv ist, läuft IPsec häufig über UDP/4500. Das kann die effektive MTU weiter reduzieren. Stelle sicher, dass UDP/4500 nicht gefiltert wird und dass MSS/MTU konservativ genug ist.

Router# show crypto isakmp sa
Router# show access-lists

Throughput verbessern: Crypto-Bottlenecks erkennen

Manchmal ist MTU nicht das Problem, sondern CPU/Hardware. IPsec-Verschlüsselung kann Router auslasten, besonders bei hohen Bandbreiten oder schwacher Hardwarebeschleunigung. Dann helfen MTU/MSS nur begrenzt.

CPU prüfen

Router# show processes cpu sorted
Router# show crypto engine accelerator statistic

Verifikation nach Änderungen

Nach MTU/MSS-Tuning verifizierst du erneut DF-Pings und die reale Anwendung (HTTPS/Downloads). Zusätzlich prüfst du IPsec-Counters und Interface-Drops, um sicherzustellen, dass du das Problem wirklich gelöst hast.

DF-Ping und Tunnel-Tests

Router# ping <remote-host> df-bit size 1400
Router# show crypto ipsec sa

Client-Tests (Beispiel)

Client$ curl https://example.com
Client$ iperf3 -c <remote-iperf-server>

Typische Fehler und Quick-Fixes

Diese Muster tauchen in der Praxis immer wieder auf. Wenn du sie erkennst, kannst du sehr zielgerichtet handeln.

Quick-Reference: Checkliste (Copy & Paste)

Diese Kommandos decken MTU, Tunnel, IPsec und Ressourcen ab.

show interfaces tunnel0 | include MTU|drops|error
show interfaces dialer0 | include MTU|drops|error
show crypto ipsec sa
show crypto isakmp sa
show processes cpu sorted
ping 8.8.8.8 df-bit size 1472
ping 8.8.8.8 df-bit size 1452
ping 8.8.8.8 df-bit size 1400

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

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