Tunnel Overhead: CAPWAP/Cloud Tunnels und MTU/Fragmentierung

Tunnel Overhead ist einer der häufigsten „unsichtbaren“ Gründe für instabile WLAN-Erlebnisse in Enterprise-Umgebungen – besonders dann, wenn Access Points ihren Traffic nicht lokal ins LAN ausleiten, sondern über CAPWAP zum Controller oder über Cloud Tunnels zu einer Management- oder Security-Plattform schicken. In solchen Designs sind Funk und Switchport oft völlig unauffällig, aber Nutzer klagen über sporadische Timeouts, langsame Webseiten, abreißende VPN-Verbindungen, schlechte Videokonferenzen oder „mysteriöse“ Performanceeinbrüche, die sich nicht mit RF-Kennzahlen erklären lassen. Die Ursache liegt häufig im Zusammenspiel aus zusätzlichem Header-Overhead, falscher MTU, fehlender Path MTU Discovery (PMTUD) oder ungünstiger Fragmentierung. Sobald Pakete zu groß werden, werden sie fragmentiert oder verworfen – und genau das ist für Echtzeit- und TCP-basierte Anwendungen extrem schädlich. Dieser Artikel erklärt praxisnah, wie Tunnel Overhead bei CAPWAP und Cloud Tunneln entsteht, welche MTU-Fallen in WAN, Internet und Overlay-Netzen typisch sind, wie Fragmentierung wirklich wirkt und wie Sie Ihr WLAN-Design so planen, dass zentrale oder cloudbasierte Datenpfade zuverlässig funktionieren.

Warum Tunnel Overhead in WLAN-Architekturen immer relevanter wird

WLAN-Architekturen haben sich in den letzten Jahren stark diversifiziert: Controller-basiert mit zentralem Switching, Cloud-managed mit optionaler Tunnelung, SD-WAN-Integration, Security-Edges, Remote-Workforce-Standorte. Allen gemeinsam ist: Traffic wird häufiger „verpackt“ und über ein Underlay transportiert, das nicht immer unter Ihrer Kontrolle steht (MPLS, Internet, Provider-Ethernet, VPN). Dadurch wird MTU plötzlich zu einem Designparameter, nicht zu einem Detail.

• Central Switching: Clienttraffic wird über CAPWAP oder ähnliche Mechanismen zum Controller getunnelt.
• Cloud Tunnels: APs oder Gateways bauen verschlüsselte Tunnel zur Cloud auf (Policy Enforcement, Monitoring, ZTNA, Secure Web Gateway).
• Overlay über WAN: SD-WAN/IPsec/Gre und weitere Overlays addieren zusätzlichen Overhead.

Je mehr Overlays Sie stapeln, desto kleiner wird die effektive Nutzlast pro Paket. Ohne bewusstes MTU-Design ist Fragmentierung oder Drop früher oder später vorprogrammiert.

Grundlagen: MTU, MSS und warum „passt schon“ gefährlich ist

MTU (Maximum Transmission Unit) ist die maximale Paketgröße, die ein Link ohne Fragmentierung transportieren kann. In Ethernet-Umgebungen wird häufig mit 1500 Byte gerechnet (Standard Ethernet MTU). Sobald Sie tunneln, sinkt die effektive MTU für das innere Paket, weil das äußere Paket zusätzliche Header trägt.

Für TCP ist neben MTU besonders wichtig: MSS (Maximum Segment Size). MSS ist die maximale TCP-Nutzlast, die ein Endgerät ohne Fragmentierung senden sollte. MSS wird beim TCP-Handshake ausgehandelt. Ein sauberes Design sorgt dafür, dass MSS so gesetzt ist, dass TCP-Segmente auch durch Tunnelpfade passen.

Path MTU Discovery: Der Mechanismus, der oft „kaputt“ ist

PMTUD (Path MTU Discovery) soll automatisch die kleinste MTU entlang des Pfads finden. In der Praxis scheitert PMTUD jedoch häufig, weil ICMP-Meldungen („Fragmentation Needed“) durch Firewalls oder Providerfilter geblockt werden. Dann passiert Folgendes:

• Ein Sender schickt große Pakete (weil er 1500 annimmt).
• Unterwegs ist die reale Path MTU kleiner (durch Tunnel/Provider).
• Pakete werden verworfen oder fragmentiert, aber der Sender erfährt es nicht sauber.
• TCP bricht ein: Retransmits, Timeouts, schlechte Goodput-Werte.

Deshalb ist „PMTUD macht das schon“ in Tunnelumgebungen keine verlässliche Designannahme. MSS-Clamping und bewusstes MTU-Design sind oft zwingend.

Was ist Tunnel Overhead konkret?

Tunnel Overhead ist die Summe aller zusätzlichen Header, die ein inneres Paket erhält, damit es durch einen Tunnel transportiert werden kann. Je nach Tunneltyp kommt z. B. hinzu:

• Äußeres IP-Header: IPv4 oder IPv6
• UDP/TCP-Header: häufig bei Cloud-Tunneln oder CAPWAP (UDP-basiert)
• Tunnel-spezifische Header: CAPWAP, GRE, VXLAN, Geneve, etc.
• Verschlüsselungs-Overhead: IPsec/DTLS/TLS (inkl. Auth-Tags, Padding)

Aus Sicht der effektiven MTU gilt vereinfacht:

$\mathrm{EffectiveMTU}=\mathrm{UnderlayMTU}–\mathrm{TunnelOverhead}$

Wenn UnderlayMTU = 1500 und TunnelOverhead = 60, bleiben effektiv nur 1440 Byte für das innere Paket. Bei mehreren Overlays kann das deutlich weiter sinken.

CAPWAP im Überblick: Warum Controller-Tunnel MTU-sensitiv sind

CAPWAP (Control And Provisioning of Wireless Access Points) wird in vielen controllerbasierten WLAN-Designs genutzt. Es existieren typischerweise zwei CAPWAP-Kanäle:

• Control: Management/Steuerung (AP ↔ Controller)
• Data (optional): Clienttraffic wird getunnelt (Central Switching) oder lokal gebridged (Local Switching)

Wenn Central Switching aktiv ist, wird Clienttraffic in CAPWAP-Datenkanälen verpackt. Dadurch steigt die Paketgröße. In lokalen Netzen mit echter 1500er MTU ist das oft unkritisch. Sobald CAPWAP über ein WAN, ein MPLS mit kleiner MTU oder über zusätzliche Security-Tunnel läuft, wird es kritisch.

Central vs. Local Switching: Overhead-Entscheidung im Design

• Central Switching: mehr Kontrolle zentral, aber Tunnel Overhead, zusätzliche Latenz, MTU-Risiko.
• Local Switching: Traffic lokal ins LAN, weniger Tunnel Overhead im Datapfad, aber Policies/Visibility müssen anders gelöst werden.

Eine saubere Planung bewertet deshalb nicht nur Security-Features, sondern auch MTU, Latenz und WAN-Resilienz.

Cloud Tunnels: Wenn der Datenpfad durch Internet und Security-Edges läuft

Cloud-managed WLANs nutzen häufig verschlüsselte Tunnel zwischen AP/Gateway und Cloud. Je nach Hersteller und Feature kann darüber nicht nur Management laufen, sondern auch Nutztraffic (Secure Web Gateway, Cloud Firewall, ZTNA, SD-WAN Integration). Damit entstehen zwei typische MTU-Fallen:

• Unbekannte Underlay-MTU: Internetpfade und Provider können effektiv kleinere MTUs haben als erwartet.
• Mehrfach-Encapsulation: z. B. AP→Cloud Tunnel + zusätzlich IPsec zwischen Site und Internet Edge.

In solchen Designs wird Fragmentierung wahrscheinlicher, und PMTUD ist häufig unzuverlässig, weil ICMP unterwegs gefiltert wird.

Fragmentierung: Warum sie im WLAN-Tunnelpfad so weh tut

Fragmentierung bedeutet, dass ein IP-Paket in mehrere kleinere IP-Fragmente zerlegt wird, um durch einen Link mit kleinerer MTU zu passen. Das klingt zunächst harmlos, hat aber erhebliche Nachteile:

• Mehr Overhead: jedes Fragment trägt eigene Header → mehr Traffic, mehr Airtime, mehr WAN-Last.
• Mehr Verlustwahrscheinlichkeit: wenn ein Fragment verloren geht, ist das gesamte Paket unbrauchbar.
• Mehr Reassembly-Last: Empfänger muss Fragmente puffern und zusammensetzen → kann bei Last problematisch sein.
• Schlecht für Realtime: Voice/Video leidet bei Burst-Loss und zusätzlicher Latenz.

Gerade in WLAN-Umgebungen ist Fragmentierung doppelt schädlich, weil sie nicht nur das WAN belastet, sondern auch zusätzliche Airtime im Funk verursacht, wenn Fragmente über das WLAN gehen.

Symptome von MTU/Fragmentierungsproblemen in WLAN-Tunneln

MTU-Probleme sind tückisch, weil sie nicht immer „alles kaputt“ machen. Häufig funktionieren kleine Pakete (DNS, Ping), aber große TLS-Sessions oder Downloads brechen ein. Typische Symptome:

• Webseiten laden teilweise: HTML kommt, aber Bilder/CSS/JS hängen.
• VPN/SSL-Apps flappen: Handshakes instabil, Timeouts bei größeren Transfers.
• Videokonferenzen instabil: besonders bei Screen Sharing oder wenn MTU im Uplink knapp ist.
• TCP Goodput schlecht: viele Retransmits, hohe RTT-Varianz.
• „Ping geht, aber …“: klassische MTU-Falle, weil Ping typischerweise klein ist.

Für Troubleshooting ist deshalb wichtig, nicht nur „Ping“ zu nutzen, sondern gezielt Path-MTU-Tests und MSS/MTU-Checks zu machen.

Designhebel 1: MTU bewusst festlegen statt hoffen

Ein robustes Tunnel-Design beginnt mit einer klaren MTU-Strategie:

• Underlay-MTU verifizieren: nicht annehmen, sondern messen und dokumentieren (WAN, Provider, Internet Edge).
• Encapsulation-Kette auflisten: CAPWAP + IPsec + VLAN tags + weitere Overlays addieren.
• Effective MTU ableiten: UnderlayMTU minus Overhead; daraus folgt MSS.
• Jumbo Frames nur gezielt: Jumbo im LAN hilft nicht, wenn WAN/Internet 1500 oder weniger ist.

Das Ziel ist nicht maximale MTU, sondern eine MTU, die entlang des realen Pfads konsistent funktioniert.

Designhebel 2: MSS Clamping an der richtigen Stelle

Da PMTUD oft unzuverlässig ist, ist MSS Clamping ein praxistaugliches Werkzeug: Netzwerkgeräte passen die TCP-MSS im Handshake an, damit Endgeräte kleinere Segmente senden, die garantiert durch den Tunnel passen. Das ist besonders relevant bei:

• IPsec/SD-WAN Overlays: häufige MTU-Reduktion
• Cloud-Tunneln: unbekannte Pfade und ICMP-Filterung
• Central Switching über WAN: CAPWAP plus WAN-Overlays

Wichtig ist die Platzierung: MSS Clamping muss dort greifen, wo der Engpass entsteht (häufig am Edge/WAN-Gateway oder an dem Gerät, das den Tunnel terminiert).

Designhebel 3: Local Breakout vs. zentraler Tunnel

Viele MTU-Probleme entstehen, weil Datenpfade unnötig zentralisiert werden. Ein wichtiger Architekturhebel ist deshalb Local Breakout (lokale Internet-/Traffic-Ausleitung) für bestimmte Traffic-Klassen:

• Gast-WLAN: häufig ideal für lokalen Internet-Breakout, statt CAPWAP bis zum Controller
• SaaS/Cloud Traffic: kann lokal besser performen als „Hairpin“ durch zentrale Security, wenn Policies es erlauben
• Voice/Video: kann stark von kürzeren Pfaden profitieren

Das ist keine reine Performance-Entscheidung, sondern ein Policy-Design-Thema: Wenn Sie zentrale Security wollen, müssen Sie MTU/Latency/HA mitplanen. Wenn Sie lokale Breakouts nutzen, müssen Sie Security konsistent verteilen.

Designhebel 4: ICMP nicht blind blocken

Viele Organisationen blocken ICMP „aus Prinzip“. In Tunnelumgebungen ist das riskant, weil PMTUD auf ICMP-Meldungen angewiesen ist. Ein pragmatischer Ansatz ist, ICMP kontrolliert zu erlauben, zumindest innerhalb definierter Pfade oder zwischen Tunnelendpunkten. Wenn das politisch nicht möglich ist, wird MSS Clamping umso wichtiger.

Stacking von Overlays: Wenn CAPWAP auf IPsec trifft

Eine typische Praxisfalle ist die Kombination mehrerer Overlays:

• AP nutzt CAPWAP zum Controller
• Site nutzt zusätzlich IPsec/SD-WAN zum HQ
• Security-Edge nutzt erneut einen Tunnel zu einer Cloud

Jeder Layer reduziert die effektive MTU. Ohne Gesamtsicht entstehen Fragmentierung und Drops an Stellen, die nicht offensichtlich sind. Best Practice ist, die Encapsulation-Kette in der Planung wie ein Link Budget zu behandeln: Jeder Header kostet „Nutzlast“. Wenn Sie das nicht explizit berechnen, werden Sie es später als Incident „messen“.

Validierung: So testen Sie MTU und Tunnelpfade praxisnah

Für eine belastbare Validierung sollten Sie nicht nur „Ping“ nutzen, sondern systematisch testen:

• Path-MTU-Tests: schrittweise Paketgrößen testen, um die echte maximale Größe ohne Fragmentierung zu finden.
• TCP-MSS-Checks: beobachten, welche MSS tatsächlich ausgehandelt wird (vor und nach MSS Clamping).
• Application-Tests: HTTPS-Downloads, Videocalls, VPN-Transfers unter Last, um reale Symptome zu erkennen.
• Monitoring: Fragmentierungszähler, Drops, Retransmits, RTT-Perzentile, CPU/NAT/Firewall-Stats.

Wichtig ist, Tests in realistischen Pfaden zu machen: nicht nur „im LAN“, sondern über den tatsächlichen WAN/Internetpfad, den der Tunnel nutzt.

Troubleshooting-Checkliste: Wenn MTU verdächtig ist

• Symptomprofil prüfen: kleine Pakete ok, große Transfers schlecht → MTU/PMTUD-Verdacht.
• Encapsulation-Kette auflisten: welche Tunnel liegen im Pfad, wer terminiert sie?
• Underlay-MTU verifizieren: Provider/WAN tatsächlich 1500? Oder kleiner?
• ICMP/PMTUD prüfen: werden „Fragmentation Needed“-Meldungen geblockt?
• MSS Clamping testen: reduziert sich Goodput-Problem nach Clamping?
• Fragmentierung messen: Fragment Counters, Drops, Reassembly-Probleme.

Damit vermeiden Sie die klassische Falle, wo Teams wochenlang Funkparameter tunen, obwohl das Problem im Tunnelpfad liegt.

Typische Fehler bei CAPWAP/Cloud Tunnels und MTU

• MTU wird angenommen statt gemessen: „Ethernet ist 1500“ ist im WAN/Overlay nicht garantiert.
• ICMP wird komplett geblockt: PMTUD bricht, große Pakete hängen.
• Mehrfach-Encapsulation ohne Budget: CAPWAP + IPsec + weitere Tunnels, ohne effektive MTU zu berechnen.
• Keine MSS-Strategie: TCP-Segmente sind zu groß, Retransmits explodieren.
• Central Switching überall: unnötige Hairpins erhöhen Latenz und MTU-Risiko.
• Fehlende Observability: Fragment/Drops werden nicht überwacht, Probleme werden erst durch Nutzer wahrgenommen.

Praxisleitfaden: Tunnel Overhead sauber planen

• Datenpfade definieren: Welche SSIDs/Traffic-Klassen gehen durch CAPWAP/Cloud Tunnel, welche lokal?
• Encapsulation-Kette dokumentieren: alle Tunnel- und Verschlüsselungslayer erfassen.
• Effective MTU ableiten: UnderlayMTU minus Overhead; daraus MSS-Zielwerte bestimmen.
• MSS Clamping implementieren: am Engpass, dort wo Tunnel terminiert oder wo WAN/Internet restriktiv ist.
• ICMP/PMTUD bewusst entscheiden: kontrolliert erlauben oder MSS/MTU konsequent managen.
• Validieren: Path-MTU, MSS, realistische Applikationstests, Lasttests.
• Monitoring etablieren: Fragmentierung, Drops, Retransmits, RTT-Perzentile, CPU/Session-Stats.

Checkliste: CAPWAP/Cloud Tunnels, MTU und Fragmentierung

• Tunnel Overhead ist eingeplant: effektive MTU ergibt sich aus UnderlayMTU minus Encapsulation- und Crypto-Header.
• PMTUD ist nicht blind vorausgesetzt: ICMP-Filterung ist häufig; MSS Clamping ist oft notwendig.
• Fragmentierung wird vermieden: sie erhöht Overhead, Verlustwahrscheinlichkeit und schadet Realtime und TCP Goodput.
• Central vs. Local Switching ist bewusst entschieden: zentrale Datenpfade bringen Kontrolle, aber MTU/Latenz-Risiko.
• Overlay-Stacking ist dokumentiert: CAPWAP + IPsec/SD-WAN + Cloud Tunnel nicht ohne „MTU-Budget“ betreiben.
• Validierung ist praxisnah: Path-MTU-Tests, MSS-Checks und echte Applikationstests über den realen Pfad.
• Monitoring ist aktiv: Fragment/Drops/ Retransmits und Latenz-Perzentile machen MTU-Probleme früh sichtbar.

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.