MTU und TCP-MSS und Tunneltechniken
In der Praxis zeigen sich immer wieder Probleme mit der MTU (maximale Paketgröße auf einer Übertragungsstrecke), der davon abgeleiteten TCP-MSS (maximale Nutzdatengröße bei TCP-Paketen) in Verbindung mit Tunneltechniken (IPIP, IPv6IP, GRE, möglicherweise in Verbindung mit Verschlüsselung/ESP und Echtheitsbestätigung/AH).
Die aufgezeigten Tabellen sollen zeigen, welche Werte exakt passen, damit ein Paket gerade noch über einen entsprechend eingeschränkten Link passieren kann. Diese Links können auch kaskadiert sein, dementsprechend addiert sich der Overhead und verkleinert die transportierbaren Nutzdaten pro Paket.
Ganz allgemein gilt:
Protokoll | Overhead |
---|---|
IPv4 | 20 Bytes (min.) |
IPv6 | 40 Bytes (min.) |
GRE | 4 Bytes |
GRE mit Key (Cisco IOS) | 8 Bytes |
PPPoE | 8 Bytes |
802.1q VLAN Tag | 8 Bytes |
In den heutzutage üblichen Netzwerken auf Ethernetbasis ist die maximale Paketgröße für IP mit Ethernet-II-Framing auf 1500 Bytes festgelegt. Andere Übertragungstechniken ermöglichen größere Frames: Jumbo Frames (meist 9000 Bytes), Token Ring (bis zu 16 kBytes), FDDI, HSSI, usw. Da diese aber in der Praxis nur lokal eine Rolle spielen, kann man davon ausgehen, dass 1500 Bytes bei Übertragungen im Internet die größtmögliche Übertragungseinheit pro Paket darstellen (MTU).
PPPoE
Üblicherweise verkleinert PPPoE die MTU um 8 Bytes, es bleiben also 1492 Bytes als MTU übrig. Diese wird bei den meisten Providern auch in der PPP-Aushandlungsphase forciert.
Die Deutsche Telekom hat Anfang 2016 begonnen, eine neue Technik einzuführen (BNG). Durch das nun notwendige VLAN-Tag von 4 Bytes wird die Nutzdatengröße weiter eingeschränkt, auf 1488 Bytes.
Manche Provider setzen eine geringere MTU voraus, z. B. 1456 Bytes. Dies soll einer erhöhten CPU-Last auf dem providerseitig terminierenden Router durch Paketfragmentierung entgegen wirken.
GRE
GRE enkapsuliert beliebige Protokolle in IP(v6)-Pakete, damit diese über Strecken transportiert werden können, die nur IP(v6) unterstützen.
Der Standard-GRE-Header besitzt 4 Bytes ohne die (optionale) Prüfsumme oder Keys. Die Standardmethode für Cisco IOS für den tunnel key-Parameter ist OR-Sequencing und benötigt nochmals 4 Bytes, insgesamt also 8 Bytes.
Weblinks
- Englischsprachige Artikel in der Wikipedia:
- Encapsulation overhead calculator auf Baturin.org (en)
- Cisco IPSec Overhead Calculator Tool, benötigt einen CCO-Login (en)