|
|
| (30 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| '''Maximum Transmission Unit''' (MTU) - Maximale [[Datagramm]]-Größe ([[OSI-Schicht 3]]), das ohne Zerlegung in einen Frame auf OSI-Schicht 2 passt | | '''Maximum Transmission Unit''' - Maximale [[Datagramm]]-Größe ([[OSI-Schicht 3]]) |
| '''topic''' - Beschreibung
| |
|
| |
|
| == Beschreibung == | | == Beschreibung == |
| | '''Maximum Transmission Unit''' - Maximale [[Datagramm]]-Größe ([[OSI-Schicht 3]]), das ohne Zerlegung in einen Frame auf OSI-Schicht 2 passt (MTU) |
|
| |
|
| == Installation ==
| | ''MTU'' (Maximum Transmission Unit) beschreibt die maximale Paketgröße eines Protokolls der Vermittlungsschicht (Schicht 3) des OSI-Modells in Byte, die ohne Zerlegung in den Rahmen (engl. "Frame") eines Netzes der Sicherungsschicht (Schicht 2) passt |
| <syntaxhighlight lang="bash" highlight="1" line>
| | * Das Paket passt in die Nutzlast (Payload) des Protokolls der Sicherungsschicht |
| </syntaxhighlight>
| | * Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der Sicherungsschicht (engl. 'link MTU') bezeichnet |
|
| |
|
| == Aufruf ==
| | Die '''Maximum Transmission Unit''' ('''MTU'''; deutsch ''maximale Übertragungseinheit'') beschreibt die maximale [[Datenpaket|Paketgröße]] eines [[Netzwerkprotokoll|Protokolls]] der [[Vermittlungsschicht]] (Schicht 3) des [[OSI-Modell]]s, gemessen in [[Oktett (Informatik)|Oktetten]] ([[Byte]]s), welche ohne [[IP-Fragmentierung|Fragmentierung]] in den Rahmen (engl. "[[Datenframe|Frame]]") eines Netzes der [[Sicherungsschicht]] (Schicht 2) übertragen werden kann |
| <syntaxhighlight lang="bash" highlight="1" line>
| | * Diese Paketgröße passt also in die Nutzlast ([[Nutzdaten|Payload]]) des Protokolls der Sicherungsschicht |
| </syntaxhighlight>
| | * Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der Sicherungsschicht (engl. 'link MTU') bezeichnet |
|
| |
|
| === Optionen ===
| | Die maximale Größe eines Rahmens der Sicherungsschicht lässt sich so berechnen |
| {| class="wikitable sortable options gnu" | | {| class="wikitable options big" |
| |-
| |
| ! Unix !! GNU !! Parameter !! Beschreibung
| |
| |-
| |
| | || || ||
| |
| |- | | |- |
| | || Maximale Rahmengröße ='' || ''Größte MTU aller benutzten Protokolle der Vermittlungsschicht + Größe der Sicherungsschichtheader'' |
| |} | | |} |
|
| |
|
| === Parameter ===
| | Die MTU wird durch Einstellungen im Rahmen der Möglichkeiten der verwendeten Hardware und Technik bestimmt |
| | * Sie kann auf derselben [[Schnittstelle]] unterschiedliche Werte für unterschiedliche Protokolle der Vermittlungsschicht (beispielsweise [[IPv4]] oder [[IPv6]]) annehmen |
| | * Alle an einem Schicht-2-Netz beteiligten Schnittstellen, welche Protokolle höherer Schichten verarbeiten, müssen auf denselben Wert für die jeweiligen Schicht-3-Protokolle eingestellt werden |
|
| |
|
| === Umgebungsvariablen ===
| | Im OSI-Modell spricht man auf der Vermittlungsschicht von einem Paket (engl. 'packet'), während man auf der Sicherungsschicht von einem Rahmen (engl. 'frame') spricht |
| | * Die Terminologie, welche das OSI-Modell für die Einheiten auf den verschiedenen OSI-Modellschichten verwendet, hat zu einiger Verwirrung um den Begriff der MTU geführt (siehe [[#Abweichende Verwendung des Begriffs bei wichtigen Herstellern|abweichende Verwendung bei wichtigen Herstellern]]) |
| | * Unter der ''"packet size"'' (Paketgröße) wird fälschlicherweise teils die ''"frame size"'' (Rahmengröße) verstanden, jedoch stellt die obige Definition (siehe RFC 1122 und RFC 791) dies eindeutig klar |
|
| |
|
| === Exit-Status ===
| | Ein Spezialfall liegt vor, wenn ein Schicht-2-Protokoll über ein anderes Schicht-2-Protokoll [[Tunnel (Rechnernetz)|getunnelt]] wird, denn dann nennt man auch die Nutzlast selbst "Rahmen" (engl. 'frame') |
| {| class="wikitable options col1center"
| |
| |-
| |
| ! Wert !! Beschreibung
| |
| |-
| |
| | 0 || Erfolg
| |
| |-
| |
| | >0 || Fehler | |
| |}
| |
|
| |
|
| == Anwendung == | | === Path MTU (PMTU) === |
| <syntaxhighlight lang="bash" highlight="1" line>
| | Die ''Path MTU (PMTU)'' beschreibt die maximale Paketgröße, die entlang der gesamten Wegstrecke übertragen werden kann, ohne einer [[IP-Fragmentierung|Fragmentierung]] zu unterliegen |
| </syntaxhighlight>
| | * Sie ist damit gleich der kleinsten MTU aller Schicht-2-Teilstücke im Pfad |
| | * Die PMTU kann automatisch durch ''[[Path MTU Discovery|PMTU Discovery (PMTUD)]]'' ermittelt werden |
|
| |
|
| === Problembehebung === | | === Beispiel Brief === |
| | ; Das Konzept der MTU kann auf den Briefverkehr adaptiert werden |
| | * Ein Kompaktbrief darf maximal 50 g wiegen |
| | * Zum Transport benötigt der Brief einen Briefumschlag beispielsweise 4 g und eine Briefmarke 0,3 g |
| | * Diese 4,3 g entsprechen der Größe der Sicherungsschichtheader |
| | * Daraus ergibt sich, dass die MTU (der maximale Inhalt für einen Kompaktbrief oder ''Packet Size'') 50 g - 4,3 g = 45,7 g beträgt |
| | Will man mehr Gewicht verschicken, muss man auf ein anderes Protokoll (einen Großbrief mit mehr Porto) ausweichen oder den Inhalt auf mehrere Briefe aufteilen, also ''fragmentieren'' |
|
| |
|
| == Konfiguration ==
| |
|
| |
|
| === Dateien ===
| | ; Typische MTU-Größen |
| {| class="wikitable options" | | {| class="wikitable" |
| | ! Medium !! MTU in Bytes |
| |- | | |- |
| ! Datei !! Beschreibung
| | | Hyperchannel || 65535 |
| |- | | |- |
| | || | | | [[Token Ring]](4)(802.5) || 4464 |
| |-
| |
| | ||
| |
| |}
| |
| <noinclude>
| |
| | |
| == Anhang ==
| |
| === Siehe auch ===
| |
| {{Special:PrefixIndex/{{BASEPAGENAME}}/}}
| |
| | |
| === Dokumentation ===
| |
| | |
| ; Man-Page
| |
| # [https://manpages.debian.org/testing/procps/pgrep.1.de.html prep(1)]
| |
| | |
| ; Info-Pages
| |
| | |
| === Links ===
| |
| ==== Projekt ====
| |
| | |
| ==== Weblinks ====
| |
| | |
| | |
| {{DEFAULTSORT:new}}
| |
| {{DISPLAYTITLE:new}}
| |
| | |
| [[Kategorie:new]]
| |
| | |
| </noinclude>
| |
| | |
| | |
| = TMP =
| |
| == Beispiel Ethernet ==
| |
| ; Ein Ethernet Frame besteht aus zwei Teilen: dem ''"Header"'', in dem Quell- und Zieladressen und andere wichtige Parameter für den Versand kodiert sind, und der Nutzlast, deren Größe durch die MTU bestimmt ist
| |
| | |
| ; In diesem Versuch ist die Größe der MTU mit 1500 Byte vorgegeben
| |
| * Mit Hilfe des [[Ping (Datenübertragung)|ping]]-Programmes wird ein ''"Frame"'' erzeugt, der dann im Netzwerk über das Ethernet-Protokoll versendet wird
| |
| * Die Verwendung des Begriffes Nutzlast ist hier mehrdeutig, da im OSI-Modell die verschiedenen Protokolle ineinander eingepackt ([[Datenkapselung (Netzwerktechnik)|gekapselt]]) werden
| |
| * Der im Versuch verwendete [[Linux]]-Befehl <span style="font-family:monospace;">ping -s 1472 10.0.0.1</span> ([[Windows]]-Befehl <span style="font-family:monospace;">ping -l 1472 10.0.0.1</span>) sendet dann ein [[Internet Control Message Protocol|ICMP]]-Paket mit der Nutzlast von 1472 Bytes an die [[IP-Adresse]] 10.0.0.1
| |
| | |
| # ping -f -s 1472 10.0.0.1
| |
| 1472 bytes Nutzlast des ICMP-Protokolles (Vermittlungsschicht)
| |
| + 8 bytes ICMP-Header (Vermittlungsschicht)
| |
| + 20 bytes IPv4-Header (Vermittlungsschicht)
| |
| -------------
| |
| = 1500 bytes (Nutzlast von Ethernet)
| |
| + 14 bytes (Header der Sicherungsschicht)
| |
| + 4 bytes (Frame Check Sequence)
| |
| -------------
| |
| = 1518 bytes (kompletter Ethernet Frame)
| |
| | |
| ; Mit einem Sniffer wie z. B. [[Wireshark]] wird als Ethernet Header nur die Größe von 14 Byte angezeigt
| |
| * Hierzu kommt noch die 4 Byte große [[Frame Check Sequence]] am Ende des Frames
| |
| * Falls [[Virtual Local Area Network|VLANs]] verwendet werden, besteht der Header der Sicherungsschicht aus 18 Byte und der gesamte Ethernet Frame kann eine Größe von bis zu 1522 Byte annehmen
| |
| * Würde IPv6 verwendet, änderte sich obige Berechnung dahingehend, dass der IPv6-Header der Vermittlungsschicht 40 statt 20 Byte beträgt und damit statt 1472 Byte ICMP-Nutzlast nur 1452 Byte möglich wären
| |
| | |
| ; Zum Prüfen der MTU eines Pfades ist es hilfreich, dem ping-Programm vorzugeben, das ''"don’t fragment (DF) bit"'' für die Testpakete im IPv4-Header zu setzen (für Linux z. B. <span style="font-family:monospace;">ping -M do -s 1472 10.0.0.1</span>, für Windows: <span style="font-family:monospace;">ping -l 1472 -f 10.0.0.1</span> ), denn dann erhält man eine Nachricht, falls die MTU überschritten wird
| |
| * Leicht sichtbar machen lässt sich die ''Path MTU'' mit dem Programm ''tracepath'' für IPv4 bzw. ''tracepath6'' für IPv6
| |
| | |
| === Beispiel Ethernet ===
| |
| ; Ethernetrahmen bestehen aus zwei Teilen
| |
| * dem "Header", in dem Quell- und Zieladressen und andere wichtige Parameter für den Versand kodiert sind, und der Nutzlast, deren Größe durch die MTU bestimmt ist
| |
| * In diesem Versuch ist die Größe der MTU mit 1500 Byte vorgegeben
| |
| * Mit Hilfe des ping-Programmes wird ein "Frame" erzeugt, der dann im Netzwerk über das Ethernet-Protokoll versendet wird
| |
| * Die Verwendung des Begriffes Nutzlast ist hier mehrdeutig, da im OSI-Modell die verschiedenen Protokolle ineinander eingepackt (gekapselt) werden
| |
| | |
| ping -s 1472 10.0.0.1 (Windows-Befehl ping -l 1472 10.0.0.1)
| |
| * sendet ein ICMP-Paket mit der Nutzlast von 1472 Bytes an die IP-Adresse 10.0.0.1
| |
| | |
| ping -f -l 1472 10.0.0.1
| |
| 1472 bytes Nutzlast des ICMP-Protokolles (Transportschicht)
| |
| + 8 bytes ICMP-Header (Transportschicht)
| |
| + 20 bytes IPv4-Header (der Vermittlungsschicht)
| |
| -------------
| |
| = 1500 bytes (Nutzlast von Ethernet)
| |
| + 14 bytes (Header der Sicherungsschicht)
| |
| + 4 bytes (Frame Check Sequence)
| |
| -------------
| |
| = 1518 bytes (kompletter Ethernetrahmen)
| |
| | |
| ; Mit einem Sniffer (wie [[Wireshark]])
| |
| * wird als Ethernet Header nur die Größe von 14 Byte angezeigt
| |
| * Hierzu kommt noch die 4 Byte große Frame Check Sequence am Ende des Frames
| |
| | |
| ; Falls VLANs verwendet werden
| |
| * besteht der Header der Sicherungsschicht aus 18 Byte
| |
| * der gesamte Ethernetrahmen kann eine Größe von bis zu 1522 Byte annehmen
| |
| | |
| ; Würde IPv6 verwendet
| |
| * änderte sich obige Berechnung dahingehend, dass der IPv6-Header der Vermittlungsschicht 40 statt 20 Byte beträgt und damit statt 1472 Byte ICMP-Nutzlast nur 1452 Byte möglich wären
| |
| * Oft ist es hilfreich dem ping-Programm vorzugeben das "don’t fragment (DF) bit" für die Testpakete im IPv4-Header zu setzen
| |
| | |
| für Linux z. B ping -M do -s 1472 10.0.0.1
| |
| | |
| für Windows
| |
| ping -l 1472 -f 10.0.0.1
| |
| * denn dann erhält man eine Nachricht, falls die MTU überschritten wird
| |
| * Leicht sichtbar machen lässt sich die Path MTU mit dem Programm tracepath für IPv4 bzw. tracepath6 für IPv6
| |
| | |
| === Jumbo Frames für Gigabit Ethernet ===
| |
| ; Jumbo Frames können deutlich mehr als 1518 Oktette beinhalten
| |
| * und damit ist es möglich, größere Pakete unfragmentiert zu übertragen
| |
| | |
| ; Positiv
| |
| * wiegt, dass der Protokoll-Overhead bei der Verwendung von Jumbo Frames reduziert werden kann und Router weniger Pakete behandeln müssen
| |
| | |
| ; Allerdings
| |
| * ist die Terminologie bzgl. MTU derart uneinheitlich unter den Herstellern, dass es in der Praxis schwierig ist, von den Standardeinstellungen abzuweichen
| |
| | |
| ; Jumbo Frames sind nicht im IEEE-802.3-Standard spezifiziert
| |
| * trotzdem unterstützen die meisten Hersteller von Gigabit Ethernet Switches und Routern MTUs bis 9000 Oktette
| |
| | |
| ; Quasistandard eine Path MTU um ca. 1500 Byte
| |
| * So hat sich als Quasistandard eine Path MTU um ca. 1500 Byte im Internet eingebürgert, die durch das weit verbreitete Fast Ethernet sowieso meist nicht überschritten werden kann
| |
| | |
| ; Tunnelprotokolle
| |
| * Mit dem Aufkommen von Internetzugängen, die auf Tunnelprotokollen basieren, zum Beispiel beim Verbindungsaufbau über das PPPoE-Protokoll hat die MTU an Bedeutung gewonnen
| |
| * Obwohl die PMTUD in diesem Fall dafür sorgen soll, dass die Kommunikation trotz der durch den Tunnel abgesenkten MTU möglich ist, gibt es immer wieder fehlkonfigurierte Firewalls, die durch Verwerfen von ICMP-Steuerpaketen die PMTUD stören
| |
| * Auch große Websites sind oft von diesem Konfigurationsfehler betroffen, sodass die Nutzer von getunnelten Zugängen die MTU ihrer Geräte verkleinern müssen, um auch mit diesen Sites kommunizieren zu können
| |
| | |
| === Optimale MTU ===
| |
| ; Diskussionen über die optimale MTU
| |
| ; Einfache Optimierung
| |
| * So groß wie möglich, ohne dass Probleme auftreten
| |
| | |
| ; Komplexe Optimierung
| |
| * so viel kleiner als o. g. Maximum, dass der Verschnitt der Transportzellen der unter der DSL-Schicht liegenden ATM-Transportschicht möglichst klein wird
| |
| | |
| ; Oder: Einfach probieren
| |
| * Die MTU bei ATM (4500) ist nicht zu verwechseln mit der Zellengröße (53 Bytes, 48 davon Nutzlast)
| |
| * Bei der Übertragung über einen ATM-Link werden IP-Pakete in Stücke zu je 48 Bytes zerlegt und für die Übertragung auf mehrere ATM-Zellen verteilt
| |
| * Der Router am anderen Ende des ATM-Links sammelt diese Zellen und setzt das ursprüngliche IP-Paket wieder zusammen
| |
| * Im Gegensatz dazu wird bei der IP-Fragmentierung das Paket nicht vom Router reassembliert, sondern erst von dem Host, für den das Paket bestimmt war
| |
| * Probleme, die durch einen falschen MTU-Wert auftreten können, sind Webseiten, die gar nicht oder nur teilweise angezeigt werden
| |
| | |
| === Paketgrößen ===
| |
| ; MTU und PMTU
| |
| * Die Maximum Transmission Unit (MTU) darf in einem IPv6-Netzwerk 1280 Byte nicht unterschreiten
| |
| * Somit unterschreitet auch die Path MTU (PMTU) diesen Wert nicht und es können Pakete bis zu dieser Größe garantiert ohne Fragmentierung übertragen werden
| |
| * Minimale IPv6-Implementierungen verlassen sich auf diesen Fall
| |
| * Ein IPv6-fähiger Rechner muss in der Lage sein, aus Fragmenten wieder zusammengesetzte Pakete mit einer Größe von mindestens 1500 Byte zu empfangen
| |
| * Für IPv4 beträgt dieser Wert nur 576 Byte
| |
| * Im anderen Extrem darf ein IPv6-Paket auch fragmentiert laut Payload-Length-Feld im IPv6-Header die Größe von 65.575 Byte einschließlich Kopfdaten nicht überschreiten, da dieses Feld 16 Bit lang ist (216 − 1 Byte zzgl. 40 Byte Kopfdaten)
| |
| | |
| ; Jumbograms
| |
| * RFC 2675 stellt aber über eine Option des Hop-by-Hop Extension Headers die Möglichkeit zur Verfügung, Pakete mit Größen bis zu 4.294.967.335 Byte, sogenannte Jumbograms zu erzeugen
| |
| * Dies erfordert allerdings Anpassungen in Protokollen höherer Schichten, wie z. B. TCP oder UDP, da diese oft auch nur 16 Bit für Größenfelder definieren, außerdem muss bei jedem Paket, welches einen Jumbogram beinhaltet, im IPv6-Header die Payload-Length auf 0 gesetzt werden
| |
| | |
| <noinclude>
| |
| | |
| == MTU/Fragmentierung ==
| |
| ; Maximum Transmission Unit (MTU) und Fragmentierung
| |
| Die maximale Größe eines Pakets zur Übertragung ist in einem paketvermittelten Netzwerk beschränkt
| |
| * Allerdings gibt es hier keinen allgemeinen Wert, sondern je nach Konfiguration und vor allem Übertragungsmedium sind die Werte unterschiedliche und wirken sich auf Performance und Erreichbarkeit aus
| |
| | |
| Fragmentierung findet bei IPv6 nicht statt
| |
| * Hier müssen sich die beiden Endpunkte auf die Paketgröße abstimmen, die auf der engsten Stelle möglich ist
| |
| * Siehe dazu auch [https://www.msxfaq.de/netzwerk/ipv6/ds-lite.htm DS-Lite]
| |
| | |
| == Wo gibt es die MTU? ==
| |
| Damit der TCP-Stack erkennen kann, wie groß ein Paket maximal werden darf, befragt er die Schnittstelle, über die das Paket versendet werden soll bzw
| |
| * die Einstellungen im Betriebssystem
| |
| | |
| Unter Windows können Sie die Information einfach per NETSH ermitteln
| |
| <syntaxhighlight lang="powershell" highlight="1" line>
| |
| netsh interface ipv4 show interfaces
| |
| | |
| Idx Met MTU State Name
| |
| --- <nowiki>---------- </nowiki> <nowiki>---------- </nowiki> <nowiki>------------ </nowiki> <nowiki>---------------------------</nowiki>
| |
| 1 75 4294967295 connected Loopback Pseudo-Interface 1
| |
| 38 35 1500 connected WLAN
| |
| 32 25 1500 disconnected Mobilfunk
| |
| 43 5 1500 disconnected Ethernet
| |
| 47 25 1500 connected LAN-Verbindung* 1
| |
| 42 65 1500 disconnected Bluetooth-Netzwerkverbindung
| |
| 21 25 1500 disconnected LAN-Verbindung* 3
| |
| 62 5000 1500 connected vEthernet (Default Switch)
| |
| 23 25 1500 connected Npcap Loopback Adapter
| |
| 39 15 1500 connected vEthernet (Intern Switch)
| |
| </syntaxhighlight>
| |
| | |
| In meinem Beispiel haben alle Netzwerkkarten eine MTA-Size von 1500 Bytes
| |
| | |
| Sie können mit NetSH auf die MTU-Size manuell ändern, z. B.. unter Angabe des Index oder Namens
| |
| <syntaxhighlight lang="powershell" highlight="1" line>
| |
| netsh interface ipv4 set subinterface "WLAN" mtu=1458 store=persistent
| |
| </syntaxhighlight>
| |
| | |
| Allerdings sollten Sie die Auswirkungen gut kennen
| |
| * Damit zwingen Sie ihren Client keine Paket größer als dieser Wert zu senden
| |
| * Auf bestimmten Verbindungen (z. B. ISCSI mit Jumbo-Frames) verlieren Sie damit Bandbreite
| |
| | |
| ; Übliche Werte
| |
| {| class="wikitable sortable options gnu"
| |
| |- | | |- |
| ! Medium !! MTU in Byte !! Quelle
| | | [[Token Ring]](16) || 17914 |
| |- | | |- |
| || Offizielles Maximum | | | [[FDDI]] || 4352 |
| || 65535 | |
| || RFC 791
| |
| |- | | |- |
| || Token Ring 16Mbit | | | [[Ethernet]] || 1500 |
| || 17914 | |
| ||
| |
| |- | | |- |
| || Gigabit mit Jumboframes | | | [[Ethernet#Gigabit-Ethernet|Gigabit Ethernet]]<br />mit Jumboframes || 9000 |
| || 9000 | |
| ||
| |
| |- | | |- |
| || Token Ring 4Mbit (802.5) | | | [[PPP over Ethernet|PPPoE]] (beispielsweise DSL) || ≤ 1492 |
| || 4464 | |
| || RFC 1042
| |
| |- | | |- |
| || FDDI | | | [[Serial Line Internet Protocol|SLIP]]/[[Point-to-Point Protocol|PPP]] (low delay) || 296 |
| || 4352 | |
| || RFC 1188 | |
| |- | | |- |
| || WiFi | | | [[X.25]] || 576 |
| || 2304 | |
| ||
| |
| |- | | |- |
| || Ethernet | | | [[FibreChannel]] || theoretisch unbegrenzt |
| || 1500 | |
| || RFC 894
| |
| |- | | |- |
| || 802.3 | | | [[Integrated Services Digital Network|ISDN]] || 576 |
| || 1492 | |
| || RFC 1042
| |
| |- | | |- |
| || DSL (wegen PPPoE Framing) | | | [[DQDB]] || |
| || max. 1492 | |
| ||
| |
| |- | | |- |
| || DSLite (1&1) | | | HIPPI || |
| || 1424 | |
| ||
| |
| |- | | |- |
| || ISDN X.25 | | | [[Asynchronous Transfer Mode|ATM]] || 4500, s. u |
| || 576
| |
| || | |
| |- | | |- |
| || Netbios | | | [[ARCNET]] || |
| || 512 | |
| || RFC 1088
| |
| |- | | |- |
| || ICE ([https://www.bahn.de/service/zug/wlan-im-zug wlan-im-zug]) | | | [[802.11]] || 2312 (WiFi) |
| || 1440 | |
| ||
| |
| |} | | |} |
|
| |
|
| [[Image:Bild1.png|top]]
| | ; Maximale Paketgröße eines Protokolls der Vermittlungsschicht |
| | | * Schicht 3 des OSI-Modells |
| Sie sehen also schon, dass die MTU-Größe auch von der Geschwindigkeit des Mediums abhängig ist
| | * gemessen in Oktetten |
| * Allerdings ist das ja nur die Einstellung meines Clients, der Pakete sendet | | * welche ohne Fragmentierung in den Rahmen (engl. "Frames") eines Netzes der Sicherungsschicht (Schicht 2) übertragen werden kann |
| * Auf dem Weg zum Ziel gibt es ja noch mindestens zwei weitere Schnittstellen, die eine MTU-Size begrenzen könnten, z.B.
| | * Diese Paketgröße passt also in die Nutzlast (Payload) des Protokolls der Sicherungsschicht |
| * MTU auf dem Adapter der RouterWenn ein Router ein Paket auf einem Interface empfängt und auf einem anderen Interface weitersendet muss unterschiedliche Übertragungstechniken berücksichtigen | | * Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der Sicherungsschicht (engl. 'link MTU') bezeichnet |
| * MTU auf dem ZielsystemWenn das Paket am Ziel angekommen ist, dann erwarten wir natürlich auch eine Rückantwort | |
| * Damit wird der Empfänger zum Sender und das Spiel beginnt von vorne
| |
| | |
| Mein Paket läuft ja über mehrere Stationen zum Ziel und insbesondere mit DSL-Verbindungen der VPNs oder auch IPv6 und Tunnel ist es sehr wahrscheinlich, dass mein Paket größer wird oder schon vom Anfang an zu groß war
| |
| | |
| == Welche Größe ist gemeint? ==
| |
| MTU bedeutet zwar "Maximum Transmission Unit" aber was ist die Unit? So ein Ethernet-Paket hat ja mehrere Schichten und jede hat eine Größe, wie sie hier an einem "PING -F-L 1472" sehen
| |
| | |
| [[Image:Bild2.png|top]]
| |
| | |
| Die Größe beim Ping bezieht sich auf die Payload der Daten und nicht die Größe des Pakets auf dem Kabel
| |
| * Für die MTU-Size ist die Größe des IP-Pakets maßgeblich | |
| * Für IP-Pakete gibt es daher vom Protokoll abhängig zwei anderen MTU-Größen;
| |
| | |
| IPv4 maximum MTU = 1452
| |
| IPv6 maximum MTU = 1392
| |
| | |
| Beachten Sie, dass Wireshark aber auch Netzwerkkarten mit Offloading-Funktionen mehrere Pakete automatisch zu größeren Paketen zusammen setzen und die Anzeige verfälschen können.* IP-Fragmentierung[https://de.wikipedia.org/wiki/IP-Fragmentierung https://de.wikipedia.org/wiki/IP-Fragmentierung]
| |
| * Maximum Transmission Unit[https://de.wikipedia.org/wiki/Maximum_Transmission_Unit https://de.wikipedia.org/wiki/Maximum_Transmission_Unit]
| |
| * RFC 879 – The TCP Maximum Segment Size and Related Topics[https://tools.ietf.org/html/rfc879 https://tools.ietf.org/html/rfc879]
| |
| * MTU - Maximum Transfer Unit[https://www.elektronik-kompendium.de/sites/net/0812211.htm https://www.elektronik-kompendium.de/sites/net/0812211.htm]
| |
|
| |
|
| == Fragmentierung ==
| | ; Die maximale Größe eines Rahmens der Sicherungsschicht lässt sich so berechnen |
| Das System, welches auf einer Seite ein großes Paket empfängt und dieses nicht über die nächste Teilstrecke übertragen kann, hat drei Optionen damit umzugehen:* Paket einfach verwerfenWenn der Absender eine Flusskontrolle wie z.B
| |
| * bei TCP nutzt, dann wird der Verlust erkannt
| |
| * Meist sendet der Absender das Paket aber erneut und eine Lösung ist das nicht
| |
| * Dieser Weg ist also eine Sackgasse
| |
| * Paket fragmentierenDie Zwischenstation kann das Paket natürlich eigenständig in kleinere Pakete aufteilen und die Gegenseite muss diese Pakete dann wieder zusammensetzen und weiter leiten
| |
| * Die Funktion ist möglich und wird von verschiedenen Routern auch unterstützt
| |
| * Sie ist aber ineffektiv
| |
| * Stellen Sie sich vor, sie senden ein 1500 Byte Paket und der Router mit einer MTU-Size von 1492 Bytes (DSL) muss jedes Paket in eine 1492-Bytes und 8 Byte-Paket zzgl. Overhead umpacken
| |
| * ICMP "Size Exceeded" Message"Da ist es wohl besser, wenn der Router dem Absender einen Hinweis gibt, dass sein Paket zu groß ist
| |
| * Das ist per ICMP-Steuermeldung standardisiert
| |
| * Der Sender kann dann schon auf seiner Seite die Pakte kleiner machen und passend senden
| |
| * Ganz problemlos ist das aber auch nicht, da zum einen die "kleinste" Teilstecke die Paketgröße über alle Teilstecken bestimmt
| |
| * Zudem gibt es zwischen zwei Systemen im Internet oft mehrere Wege
| |
| * Wenn diese dann eine unterschiedliche MTU-Size haben, verschenken Sie entweder Bandbreite oder bekommen erst im Laufe der Verbindung ein "ICMP Size Exceeded"
| |
|
| |
|
| Die aktuelle maximale Größe für ein Paket zu einem Ziel können Sie per PING sehr einfach ermitteln
| | {| |
| * Sie senden ein ICMP-Ping an die Gegenstelle und geben sowohl die Größe vor un setzen das "Don't Fragment (DF)"-Flag
| | | style="vertical-align:top" | ''Maximale Rahmengröße ='' || ''Größte MTU aller benutzten Protokolle der Vermittlungsschicht + Größe der Sicherungsschichtheader'' |
| | |
| ping www.msxfaq.de -f -l 1500
| |
| | |
| In den meisten Fällen sollte dieser Ping nicht durchgehen und sie folgende Ausgabe sehen
| |
| | |
| [[Image:Bild3.png|top]]
| |
| | |
| Wenn Sie mit Wireshark die Pakete anschauen, dann sehen Sie in dem Beispiel aber gar kein Paket
| |
| * Wenn ich ein 1,5kByte "Nutzdaten" über meinem PC senden möchte, der eine 1500byte MTU auf der Netzwerkkarte hat, dann passt das schon deshalb nicht, weil der Header noch dazu gerechnet werden muss
| |
| * Ich muss ein etwas kleineres Paket senden
| |
| * Bei mir gelingt es mit
| |
| | |
| ping www.msxfaq.de -f -l 1465
| |
| | |
| 1465 Bytes ist so groß, dass das Ethernet-Paket auf dem Kabel dann 1507 Bytes groß ist
| |
| * Die 8 Bytes der Ziel-MAC-Adresse können Sie hier abziehen
| |
| | |
| [[Image:Bild4.png|top]]
| |
| | |
| Das Paket wird von meinem Client als zum "Next Hop" gesendet, der aber, DSL sei Dank, ein kleineres Paket benötigt
| |
| * Hier ist es der Router mit der IP-Adresse 46.91.217.151, der mit eine MaxMTU von 1492-Bytes vorschlägt
| |
| | |
| [[Image:Bild5.png|top]]
| |
| | |
| Mein Client, bzw
| |
| * dessen IP-Stack muss dafür sorgen, dass das IP-Paket also nicht größer wird, um erfolgreich diesen Weg zu nehmen
| |
| * Mit folgendem Wireshark-Capture-Filter können Sie gezielt diese Antworten einfangen
| |
| | |
| icmp[icmptype]==3
| |
| | |
| [[Image:Bild6.png|top]]
| |
| | |
| ; Wireshark
| |
| : [https://wiki.wireshark.org/CaptureFilters https://wiki.wireshark.org/CaptureFilters CaptureFilters]
| |
| | |
| Wenn Sie nun mit Wireshark aber länger solche ICMP-Antworten suchen, dann werden sie kaum Pakete finden
| |
| * Das kann daran liegen, dass Sie keine Teilstecke in der Übertragung haben, die eine kleinere MTU nutzt
| |
| * Es kann aber auch einfach daran liegen, dass die Zwischenstationen mittels Fragmentierung das Paket weiter übertragen
| |
| | |
| == MSS Clamping ==
| |
| IP-Router sollten laut OSI-Schichtenmodell sich nur um die IP-Pakete kümmern
| |
| * Wenn ein Router aber nun mit einer unterschiedlichen MTU-Size auf zwei Schnittstellen agieren muss, dann sollte er zu große Pakete selbst fragmentieren und übertragen
| |
| * Das kostet natürlich Rechenleistung und ist der Performance auch nicht gerade förderlich, wenn das zweite Paket sehr klein ist
| |
| * Wenn ein Router nun statt der Fragmentierung ein "ICMP Size Exceeded" an den Absender sendet
| |
| * dann wird der Absender dazu gezwungen, die Pakete selbst kleiner zu machen
| |
| * Technisch funktioniert dies und wird auch genutzt
| |
| | |
| Die Fritz!Box bietet keine Möglichkeit, die MTU-Size manuell anzupassen
| |
| * Dies ist auch nicht erforderlich, da die Fritz!Box das MSS Clamping-Verfahren (Maximum Segment Size) unterstützt, über das die Größe der Datenpakete automatisch an die jeweils kleinere MTU der miteinander verbundenen Netzwerke angepasst wird
| |
| * Somit kommt es zu keinen Performance-Einbußen durch das Fragmentieren oder Verwerfen von Datenpaketen.Quelle: [https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publication/show/432_MTU-Size-fur-DSL-Verbindungen-manuell-anpassen/ https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publication/show/432_MTU-Size-fur-DSL-Verbindungen-manuell-anpassen/]
| |
| | |
| Allerdings verletzt dieses vorgehen natürlich das OSI Modell
| |
| * Ein Router auf OSI-Schicht 3 sollte nicht in die OSI-Schicht 2 (Ethernet) eingreifen und dort an den ausgehandelten Paketgrößen Einfluss nehmen.* Maximum Segment Size[https://de.wikipedia.org/wiki/Maximum_Segment_Size https://de.wikipedia.org/wiki/Maximum_Segment_Size]
| |
| * RFC 879 The TCP Maximum Segment Size and Related Topics[https://tools.ietf.org/html/rfc879 https://tools.ietf.org/html/rfc879]
| |
| * RFC 4459 – MTU and Fragmentation Issues with In-the-Network Tunneling[https://tools.ietf.org/html/rfc4459 https://tools.ietf.org/html/rfc4459]
| |
| * Telekom VDSL MTU und MSS Clamping für IPv4 und IPv6[https://webcodr.io/2018/02/telekom-vdsl-mtu-und-mss-clamping-für-ipv4-und-ipv6/ https://webcodr.io/2018/02/telekom-vdsl-mtu-und-mss-clamping-f%C3%BCr-ipv4-und-ipv6/]
| |
| | |
| == Fehlerbilder == | |
| Ein typisches Fehlerszenario bei MTU Problemen sind Verbindungen mit großen Datenmenge
| |
| * So kann die Anmeldung an einen Service noch funktionieren aber der Betrieb bricht dann
| |
| * Klassisches Beispiel sind hier TELNET oder SMTP
| |
| * Am Anfang (rot) sind die Pakete alle noch sehr klein und unkritisch für Verbindungen mit MTU-Beschränkungen
| |
| | |
| [[Image:Bild7.png|top]]
| |
| | |
| Sobald aber Daten übertragen werden müssen, wird die MTU-Size (hier 1514 Bytes), auch ausgenutzt
| |
| * hier ist es nun eine Verbindung im "LAN" er Ethernet, wo eine MTU-Size von 1500 problemlos möglich ist
| |
| * Wenn die Verbindung über WAN oder VPN geht, und ein System in der Mitte kein "ICMP Size Exceeded" sendet aber auch nicht fragmentiert, dann kommt die Verbindung einfach nicht zustande
| |
| | |
| Der Sender hat ja keine Idee, warum die Pakete nicht ankommen und von sich aus versucht er nicht eine geeignete MTU heraus zu finden
| |
| | |
| Diese Probleme tauchen oft auf, wenn Firewall-Administratoren z.B
| |
| * ICMP komplett blockieren, weil Sie von einem PING und TRACEROUTE eine Gefahr sehen
| |
| * ICMP ist aber mehr als nur PING sondern auch ein wichtiges Steuerungsprotokoll, welches zumindest im internen Netzwerk erlaubt sein sollte und selbst eingehende ICMP-Steuerungsmeldungen sollten nicht pauschal verworfen werden
| |
| | |
| == MTU Discovery ==
| |
| Die Fragmentierung durch einen Router auf dem Übertragungsweg macht die Übertragung aufgrund mehrerer Pakete langsam und es kostet vor allem Speicher und CPU auf den Routern
| |
| * Heute sollten Sie davon ausgehen, dass kein Provider mehr Fragmentation durchführt
| |
| * Sie müssen also sicherstellen, dass die Endpunkte die Funktion "MTU Discovery" unterstützen
| |
| * Dazu sendet der Absender ein Paket in der gewünschten Größe aber ein Router, der das nicht mehr übertragen kann, sendet ihnen dann ein ICMP Exceeded zurück
| |
| * Dieses Paket enthält nicht nur den Fehlercode, dass ihr Paket zu groß war sondern auch die Größe, die dieser Router maximal weiter leiten kann
| |
| | |
| Ihr Client sendet nun also ein "kleineres Paket" und hofft, dass dieses durch geht
| |
| * Es wird den Router passieren, der eben die Übertragung gestoppt hat aber auf dem weiteren Weg kann es noch weitere Router geben, die vielleicht noch kleinere Frame-Größen benötigen
| |
| * Dann wiederholt sich das Spiel bis Sie letztlich ein Paket zum Ziel bekommen
| |
| * Das Ziel antwortet dann und auch in die Richtung können unterschiedliche Paketgrößen die Übertragung behindern
| |
| * Das Spiel beginnt von vorne
| |
| | |
| Damit nicht genug
| |
| * Auch nach der erfolgreichen Aushandlung einer möglichen Paketgröße ist nicht sichergestellt, dass ihr IP-Paket immer den gleichen Weg geht
| |
| * Einmal einen Umweg über einen anderen Kanal mit kleinerer Frame-Size ergibt wieder ein ICMP-Paket
| |
| | |
| Das ganze System funktioniert nur, wenn Sie ICMP auch zulassen
| |
| * Immer wieder höre ich, dass aus "Sicherheitsgründen" das Protokoll ICMP geblockt wird, weil damit Hacker ihr Subnetz per PING durchgehen können und so eine Liste der Rechner ermitteln könnten
| |
| * Das kann ich aber auch mit anderen "gängigen Ports" die mir dann sogar gleich die Antwort liefern, welcher Service dort läuft
| |
| | |
| Bitte hören sie auf, die Basisfunktion von MTU Discovery aber auch Traceroute und Ping durch das Blocken von ICMP zu stören
| |
| * Sie können die lokale MTU-Größe beschränken, um dem Client zu verbieten größere Pakete zu senden
| |
| * Dies kann für einen Fehlersuche nützlich sein aber ist natürlich keine dauerhafte Lösung
| |
| | |
| REM Anzeige der aktuellen MTU Size
| |
| netsh interface ipv4 show interfaces
| |
|
| |
| REM MTU eines Interface ueber Name setzen
| |
| netsh interface ipv4 set subinterface "Local Area Connection" mtu=1400 store=persistent
| |
|
| |
| REM MTU eines Interface ueber Nummer setzen
| |
| netsh interface ipv4 set subinterface "2" mtu=1400 store=persistent
| |
| | |
| Die Einstellungen sind damit aber permanent
| |
| * Vergessen Sie also nicht, diese nach der Fehlersuche wieder zurückzustellen.* Windowes10: Setzen der MTU aller netzwerkkarten außer Loopback[https://krausens-online.de/windows-10-setzen-der-mtu-aller-netzwerkkarten-ausser-loopback/ https://krausens-online.de/windows-10-setzen-der-mtu-aller-netzwerkkarten-ausser-loopback/]
| |
| * Path MTU Discovery[https://de.wikipedia.org/wiki/Path_MTU_Discovery https://de.wikipedia.org/wiki/Path_MTU_Discovery]
| |
| | |
| == Ursache ICMP und Firewall ==
| |
| Das Protokoll ICMP wird landläufig mit "PING" gleichgesetzt, obwohl ICMP viel mehr ist
| |
| * Es ist ein "Internet Control Message Protocol", welches noch viele andere Informationen an den Absender zurück melden kann
| |
| * Im ICMP Header gibt es einen 8-Bit Wert, der unterschiedliche Bedeutungen hat
| |
| * Hier ein Auszug
| |
| | |
| {| class="wikitable sortable options gnu"
| |
| |-
| |
| ! Typ !! Code !! Bedeutung
| |
| |-
| |
| || 0
| |
| || 0
| |
| || Antwort auf Ping, (Echo Reply)
| |
| |-
| |
| || 3
| |
| || 0
| |
| || ICMP not Reachable: Netzwerk nicht erreichbar
| |
| |-
| |
| || 1
| |
| || ICMP not Reachable: Host nicht erreichbar
| |
| |-
| |
| || 2
| |
| || ICMP not Reachable: Protokoll nicht erreichbar
| |
| |-
| |
| || 3
| |
| || ICMP not Reachable: Port nicht erreichbar
| |
| |-
| |
| || 4
| |
| || ICMP not Reachable: Fragmentierung nötig aber nicht erlaubt (DF Header)
| |
| |-
| |
| || 5
| |
| || ICMP not Reachable: Route nicht möglich
| |
| |-
| |
| || 13
| |
| || ICMP not Reachable: Durch Admin (Firewall) geblockt
| |
| |-
| |
| || 8
| |
| || 0
| |
| || PING Anfrage
| |
| * Echo Request
| |
| |-
| |
| || 11
| |
| || 0
| |
| || Zeitüberschreitung bei der Übertragung, TTL Abgelaufen
| |
| |-
| |
| || 1
| |
| || Zeitüberschreitung während der Defragmentierung überschritten
| |
| |-
| |
| |} | | |} |
|
| |
|
| Für MTU ist hier der Code 3 ("Not Reachable") interessant, da es dann noch einen Untercode gibt und hier ist z.B
| | ; Hardware und Technik |
| * Code 4 ("Fragmentierung nötig aber nicht erlaubt (DF Header)" interessant | | * Die MTU wird durch Einstellungen im Rahmen der Möglichkeiten der verwendeten Hardware und Technik bestimmt |
| * Sie sehen aber auch die Gruppierung, dass die PING und Traceroute-Anfrage andere Typ-Codes verwenden | | * Sie kann auf derselben Schnittstelle unterschiedliche Werte für unterschiedliche Protokolle der Vermittlungsschicht (beispielsweise IPv4 oder IPv6) annehmen |
| * Der Versand von ICMP-Paketen vom Typ=3 an entfernte Stellen als Fehlermeldung ist genauso sinnvoll wie auch der Empfang von diesen Meldungen bei ausgehenden Verbindungen
| | * Alle an einem Schicht-2-Netz beteiligten Schnittstellen, welche Protokolle höherer Schichten verarbeiten, müssen auf denselben Wert für die jeweiligen Schicht-3-Protokolle eingestellt werden |
|
| |
|
| Natürlich können solche Meldungen auch gefälscht sein, das es bei ICMP ja keinen Handshake wie bei TCP gibt
| | === Terminologie === |
| * Aber da auf eine ICMP-Antwort in der Regel keine weitere Reaktion des Zielsystems erfolgt, ist das Risiko eher überschaubar | | * Im OSI-Modell spricht man auf der Vermittlungsschicht von einem Paket (engl. 'packet'), während man auf der Sicherungsschicht von einem Rahmen (engl. 'frame') spricht |
| * Das Unterdrücken von "Unerreichbar-Meldungen" hilft kaum gegen Angreifer, da diese meist genug Ressourcen haben, um einfach Ports und Adressen durchzuprobieren und nicht auf eine "nicht erreichbar" Antwort warten
| | * Die Terminologie, welche das OSI-Modell für die Einheiten auf den verschiedenen OSI-Modellschichten verwendet, hat zu einiger Verwirrung um den Begriff der MTU geführt |
| * Verbindungsprobleme bei guten Prozessen können Sie aber so viel einfacher analysieren, wenn der ICMP-Code ihnen verrät, warum die Verbindung nicht zustande gekommen ist | |
|
| |
|
| In der Windows Firewall ist auch zu sehen, dass die Regeln solche ICMP Pakete erlauben
| | ==== Abweichende Verwendung ==== |
| | Abweichende Verwendung des Begriffs |
| | ; Cisco und Juniper |
| | Verwenden den Begriff MTU in ihrer Konfigurationssyntax als maximale Rahmen- bzw. Paketgröße der zu konfigurierenden Netzwerkschicht |
|
| |
|
| [[Image:Bild8.png|top]]
| | ; Folgende Einstellungen entsprechen einander |
| | * Bei beiden Herstellern bedeutet das erste Auftauchen des Begriffes die maximale Ethernet Rahmengröße und nicht die maximale Größe der Nutzlast (Maximum Segment Size) |
| | * diese muss folglich einige Byte größer gewählt werden als die dann folgenden Einstellungen für die verschiedenen Schicht-3 Protokolle |
|
| |
|
| * [https://www.msxfaq.de/netzwerk/grundlagen/icmp.htm ICMP]
| | ; Paket- und Rahmengröße |
| * Internet Control Message Protocol[https://de.wikipedia.org/wiki/Internet_Control_Message_Protocol https://de.wikipedia.org/wiki/Internet_Control_Message_Protocol] | | * Unter der "packet size" (Paketgröße) wird fälschlicherweise teils die "frame size" (Rahmengröße) verstanden, jedoch stellt die obige Definition (siehe RFC 1122 und RFC 791) dies eindeutig klar |
| * [http://de.wikipedia.org/wiki/Ping_of_Death http://de.wikipedia.org/wiki/Ping_of_Death Ping of Death] | | * Ein Spezialfall liegt vor, wenn ein Schicht-2-Protokoll über ein anderes Schicht-2-Protokoll getunnelt wird, denn dann nennt man auch die Nutzlast selbst "Rahmen" (engl. 'frame') |
|
| |
|
| == Messen mit PING == | | === Path MTU === |
| ; Messen mit PING -f -l nnnn | | ; Path MTU (PMTU) |
| Welche MTU zwischen zwei Endgeräten maximal möglich ist, können Sie am einfachsten mit einem ICMP-PING ausmessen
| | Maximale Paketgröße, die entlang der gesamten Wegstrecke übertragen werden kann, ohne einer Fragmentierung zu unterliegen |
| * Sie können hier die Größe des Pakets vorgeben aber insbesondere das Flag "Don't Fragment" setzen | | * Sie ist die kleinsten MTU aller Schicht-2-Teilstücke im Pfad |
| * Allerdings benötigen sie dann schon einige Versuche, da Sie sich dem Wert nähern müssen
| | * Die PMTU kann automatisch durch PMTU Discovery (PMTUD) ermittelt werden |
| C:\>ping www.google.de -f -l 1400
| |
|
| |
| Ping wird ausgeführt für www.google.de [172.217.18.99] mit 1400 Bytes Daten
| |
| Antwort von 172.217.18.99: Bytes=68 (gesendet 1400) Zeit=11ms TTL=57
| |
|
| |
| Ping-Statistik für 172.217.18.99
| |
| Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0
| |
| (0% Verlust),
| |
| Ca
| |
| * Zeitangaben in Millisek.
| |
| Minimum = 11ms, Maximum = 11ms, Mittelwert = 11ms
| |
| STRG-C
| |
| ^C
| |
| C:\>ping www.google.de -f -l 1500
| |
|
| |
|
| Ping wird ausgeführt für www.google.de [172.217.18.99] mit 1500 Bytes Daten
| | ; Beispiel Brief |
| Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt
| | Das Konzept der MTU auf die Post adaptiert |
| | * Eine MTU 50 g heißt, dass man max. 50 g Inhalt (entspricht der Packet Size) in den Brief einpacken kann |
| | * Der Brief insgesamt kann selbst aber schwerer als 50 g sein, da im Normalfall noch ein Briefumschlag beispielsweise 4 g und eine Briefmarke 0,3 g hinzukommt |
| | * Bezahlt und verschickt wird der ganze Brief von 54,3 g Masse entsprechend der Frame Size |
|
| |
|
| Ping-Statistik für 172.217.18.99
| | == Anwendung == |
| Pakete: Gesendet = 1, Empfangen = 0, Verloren = 1
| | * [[Maximum Transmission Unit/Anwendung]] |
| (100% Verlust),
| |
|
| |
|
| Hier habe ich einmal ein paar meiner Messungen ausgeführt
| | == Konfiguration == |
|
| |
|
| {| class="wikitable sortable options gnu" | | === Dateien === |
| | {| class="wikitable options" |
| |- | | |- |
| ! Standort !! Gegenstelle !! Gemessener MTA | | ! Datei !! Beschreibung |
| |- | | |- |
| || DSL 100.000 Hövelhof | | | || |
| || www.google.dewww.netatwork.de www.msxfaq.de | |
| || 1464
| |
| |-
| |
| || Net at Work DSL (Telekom DSL) (PPPoE)
| |
| || www.google.dewww.netatwork.dewww.msxfaq.de
| |
| || 1464
| |
| |-
| |
| || Kundennetz
| |
| || www.google.dewww.netatwork.dewww.msxfaq.de
| |
| || 1448
| |
| |-
| |
| || Kabelnetz (Unity Media) (mit IPv4)
| |
| || www.google.dewww.netatwork.dewww.msxfaq.de
| |
| || 1472
| |
| |-
| |
| || VPN-Verbindung via Net at Work
| |
| || 192.168.x.x (Internes System(
| |
| || 1372
| |
| |-
| |
| || Freifunk über WLAN und Router mit VPN
| |
| || www.google.dewww.netatwork.dewww.msxfaq.de
| |
| || 1372
| |
| |- | | |- |
| | | || |
| |} | | |} |
| | | <noinclude> |
| Eine MTU von 1500bytes, wie diese von der Schnittstelle angeboten wird, wird nie erreicht, was aber auch nicht zu erwarten war
| |
| * Bei DSL scheint deine Obergrenze von 1464 Bytes erreichbar zu sein, während Firewalls bei einem Kunden schon bei 1448 Bytes abriegelt
| |
| * Bei Internet über Kabelfernsehen hingegen ist die gemessene MTU-Size 1472 sogar etwas größer als bei DSL
| |
| * Der Kabelanschluss hatte aber IPv4
| |
| * Die neueren Anschlüsse mit IPv6 und DS-Lite werden vermutlich eine kleinere MTU haben
| |
| | |
| Wenn ich aber ein VPN über DSL aufbaue, dann sehen Sie den "Verlust" durch die VPN-Ummantelung
| |
| * Das übertragene Paket ist zwar weiter 1464 Bytes groß aber bei meinem VPN sind 92 Bytes als "VPN Overhead" zu verzeichnen
| |
| * Der VPN-Overhead ist aber auch bei Freifunk zu sehen
| |
| * Hier verbinde ich mich per WLAN mit einem Freifunk-Router, der dann die Daten über einen VPN-Tunnel sendet und beim Ausgang ins Internet angeblich nichts protokoliert wird
| |
| * [https://www.msxfaq.de/sonst/meinung/freifunk_warum_nicht.htm Freifunk - warum nicht?]
| |
| | |
| Da es also nicht genau eine optimale MTU gibt, macht es auch wenig Sinn auf dem Client eine MTU vorzugeben
| |
| * Wenn Sie diese manuell zu groß wählen, dann wird weiter fragmentiert oder die Verbindung kommt nicht an
| |
| * Wenn Sie dies zur Sicherheit aber gleich oder kleiner der minimalen MTU all ihrer Verbindungen wählen, dann lassen Sie Bandbreite liegen
| |
| * Die MTU beschränkt sich bei ihnen eh nur auf die Senderichtung
| |
| * Beim Empfang können Sie nicht direkt eingreifen
| |
| | |
| Also vergessen Sie erst einmal die meisten Tricks zur "Optimierung" der MTU
| |
| | |
| == Automatisiert messen ==
| |
| Eine zu kleine MTU-Size hat mir schon häufiger Probleme bereitet
| |
| | |
| ; Beispiele
| |
| * bei der Replikation zwischen zwei Domain Controllern
| |
| * Natürlich kann ich einfach per "PING" mit Angabe der Option "-f" für nicht fragmentieren und einer Paketgröße den Weg prüfen
| |
| * Technisch würde ein XXL-großes Paket reichen, um den ersten Router zu finden, der dagegen ist und ein ICMP Size Exceeded sendet
| |
| * Genau das habe erst erst einmal per PowerShell versucht aber ich kann zwar per PING und Test-Connection ein Ping mit bestimmter Größe und ohne Fragmentierung senden aber die ICMP-Antwort mit der blockierenden Gegenstelle und der gemeldeten MTZ-Größe konnte ich nicht erhalten
| |
| * Auch in direktes lesen mit RAW-Sockets scheint nicht mehr möglich zu sein* [https://www.msxfaq.de/powershell/psping.htm Ping mit PowerShell]
| |
| * TCP Raw Sockets: Limitations on Raw Sockets[https://docs.microsoft.com/en-us/windows/win32/winsock/tcp-ip-raw-sockets-2?WT.mc_id=M365-MVP-6771&limitations-on-raw-sockets https://docs.microsoft.com/en-us/windows/win32/winsock/tcp-ip-raw-sockets-2#limitations-on-raw-sockets]
| |
| * Powershell-ICMP/Powershell-ICMP-Listener.ps1[https://github.com/api0cradle/Powershell-ICMP/blob/master/Powershell-ICMP-Listener.ps1 https://GitHub.com/api0cradle/Powershell-ICMP/blob/master/Powershell-ICMP-Listener.ps1]
| |
| * How to write a basic sniffer in PowerShell[http://www.drowningintechnicaldebt.com/RoyAshbrook/archive/2013/03/08/how-to-write-a-basic-sniffer-in-powershell.aspx http://www.drowningintechnicaldebt.com/RoyAshbrook/archive/2013/03/08/how-to-write-a-basic-sniffer-in-powershell.aspx]
| |
| * Test-Connection[https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection?WT.mc_id=M365-MVP-6771&view=powershell-6#outputs https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection?view=powershell-6#outputs]
| |
| | |
| Erst die genauer Betrachtung der Parameter von "Test-Connection" und insbesondere des Bereichs "Output" sagt, dass normalerweise nur ein "True/False" zurück kommt, wenn keine anderen Parameter etwas anderes vorgeben
| |
| | |
| [[Image:Bild9.png|top]]
| |
| | |
| Über den Parameter "-MTUSizeDetect" kommen Sie ganz schnell zum Ergebnis
| |
| * Ich habe zuerst einmal meine interne Fritz!Box ausgemessen
| |
| * Da sollte jeder auf 1514 Bytes auf dem Kabel kommen, auch wenn Test-Connection hier irrtümlich 1472 ausliefert
| |
| * Das ist aber die ICMP-Payload-Size
| |
| * Das IP-Paket ist 1500 Bytes und die 14 Bytes kommen für das Ethernet-Frame dazu, die aber nicht zu MTU dazu zählen
| |
| | |
| <syntaxhighlight lang="powershell" highlight="1" line> | |
| C:\> Test-Connection 192.168.178.1 -MTUSizeDetect
| |
| Source : FC-T480S
| |
| Destination : www.msxfaq.de
| |
| MTUSize : 1472
| |
| Status : Success
| |
| Address : 217.160.0.234
| |
| RoundtripTime : 17
| |
| Options : System.Net.NetworkInformation.PingOptions
| |
| Buffer : {97, 98, 99, 100_}
| |
| </syntaxhighlight>
| |
| | |
| Dabei ist schön zu sehen, wie Test-Connection sich von kleineren Paketen zu größeren Paketen hocharbeitet
| |
| | |
| [[Image:Bild10.png|top]]
| |
| | |
| Das PowerShell Commandlet startet mit 770 Bytes und geht dann über 1121, 1297, 1385, 1429, 1451,1462 auf 1464
| |
| * Anscheinend sind das gängige Sprünge
| |
| * Das Skript nutzt also nicht die "ICMP Size Exceeded" Meldung, um die MTU-Size zu ermitteln
| |
| | |
| == IPv6 und MTU ==
| |
| Bei IPv6 ist es nicht mehr erlaubt, dass ein System auf dem Übertragungsweg die Pakete fragmentiert
| |
| * Das, was bei IPv4 noch als Verletzung des OSI-Modells geschimpft wurde, wenn ein IP-Router (OSI-Schicht 3) in den Übertragungsweg (OSI Schicht 2) eingreift, ist bei IPv6 nun empfohlen
| |
| | |
| IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [[https://tools.ietf.org/html/rfc1981#ref-IPv6-SPEC IPv6-SPEC]] section "Fragment Header")
| |
| * However, packetization layers are encouraged to avoid sending messages that will require fragmentationQuelle: RFC 1981 – Path MTU Discovery for IP version 6 - [https://tools.ietf.org/html/rfc1981 https://tools.ietf.org/html/rfc1981]
| |
| | |
| The Fragment header is used by an IPv6 source to send packets larger than would fit in the path MTU to their destinations. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery pathIPv6 requires that every link in the internet have an MTU of 576 octets or greater
| |
| * On any link that cannot convey a 576-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.Links that have a configurable MTU (for example, PPP links) must be configured to have an MTU of at least 576 octets; it is recommended that a larger MTU be configured, to accommodate possible encapsulations (i.e., tunneling) without incurring fragmentation.Quelle: RFC 1883 Internet Protocol, Version 6 (IPv6) Specification" - [https://tools.ietf.org/html/rfc1883 https://tools.ietf.org/html/rfc1883]
| |
| | |
| Auch ohne Fragmentierung gibt es dennoch die MTU ermitteln
| |
| * Daher ist das Blockieren von "ICMP Fragmentation needed" einfach nicht mehr supportet und damit fällt auch das "Do not fragment" weg
| |
| | |
| C:> ping fritz.box -6 -f
| |
| | |
| Die Option "-f" wird nur für IPv4 unterstützt.* RFC 1981 – Path MTU Discovery for IP version 6[https://tools.ietf.org/html/rfc1981 https://tools.ietf.org/html/rfc1981]
| |
| * RFC 1883 Internet Protocol, Version 6 (IPv6) Specification"[https://tools.ietf.org/html/rfc1883 https://tools.ietf.org/html/rfc1883]
| |
|
| |
|
| == Anhang == | | == Anhang == |
| === Siehe auch === | | === Siehe auch === |
| | <div style="column-count:3"> |
| | <categorytree hideroot=on mode="categories">OSI/2 Data Link</categorytree> |
| | </div> |
| | ---- |
| {{Special:PrefixIndex/{{BASEPAGENAME}}/}} | | {{Special:PrefixIndex/{{BASEPAGENAME}}/}} |
| === Links === | | |
| | === Dokumentation === |
| ===== RFC ===== | | ===== RFC ===== |
| {| class="wikitable sortable options" | | {| class="wikitable options big col1center" |
| |- | | |- |
| ! RFC !! Titel | | ! RFC !! Titel !! Jahr |
| |- | | |- |
| | [https://www.rfc-editor.org/rfc/791 791] || INTERNET PROTOCOL | | | [https://www.rfc-editor.org/info/rfc791 791] || INTERNET PROTOCOL || |
| |- | | |- |
| | [https://www.rfc-editor.org/rfc/879 879] || The TCP Maximum Segment Size and Related Topics | | | [https://www.rfc-editor.org/info/rfc879 879] || TCP Maximum Segment Size and Related Topics || |
| |- | | |- |
| | [https://www.rfc-editor.org/rfc/1191 1191] || Path MTU Discovery | | | [https://www.rfc-editor.org/info/rfc1191 1191] || Path MTU Discovery || |
| |- | | |- |
| | [https://www.rfc-editor.org/rfc/1981 1981] || Path MTU Discovery for IP version 6 | | | [https://www.rfc-editor.org/info/rfc1981 1981] || Path MTU Discovery for IP version 6 || |
| |- | | |- |
| | [https://www.rfc-editor.org/rfc/2923 2923] || TCP Problems with Path MTU Discovery | | | [https://www.rfc-editor.org/info/rfc2923 2923] || TCP Problems with Path MTU Discovery || |
| |} | | |} |
|
| |
|
| Zeile 690: |
Zeile 171: |
| # [https://www.dslreports.com/drtcp Dr. TCP], eine Software zum Einstellen der MTU unter Windows, ursprünglich für DSL-Nutzer geschrieben | | # [https://www.dslreports.com/drtcp Dr. TCP], eine Software zum Einstellen der MTU unter Windows, ursprünglich für DSL-Nutzer geschrieben |
| # [https://www.trullowitsch.de/index.php?id=tools MTU], eine weitere Software (Freeware) zum Einstellen der MTU unter Windows | | # [https://www.trullowitsch.de/index.php?id=tools MTU], eine weitere Software (Freeware) zum Einstellen der MTU unter Windows |
| # [https://www.firewall.cx/tcp-analysis-section-6.php Analysing TCP Header Options – Section 6] – Ausführliche Erklärung der MTU und MSS | | # [https://www.firewall.cx/tcp-analysis-section-6.php Analysing TCP Header Options - Section 6] - Ausführliche Erklärung der MTU und MSS |
|
| |
|
| | === Links === |
| | ==== Projekt ==== |
| | |
| | ==== Weblinks ==== |
|
| |
|
| [[Kategorie:OSI/2 Data Link]] | | [[Kategorie:OSI/2 Data Link]] |
| <noinclude> | | <noinclude> |