MTU Size im WAN optimieren

MTU SIZE IM WAN

Die Maximum Transmission Unit (MTU; deutsch maximale Übertragungseinheit) beschreibt die maximale Paketgröße eines Protokolls.

Mit WAN-Anschlüssen und insbesondere bei DSL-Anschlüssen kommt es bei bestimmten IPv4 und IPv6 basierten Datenübertragungen immer wieder zu Problemen.

Beispielsweise lassen sich SAP-Anwendungen nicht vollständig aufrufen, die RDP (Remote Desktop Protocol)-Session baut sich nicht auf oder die Active Directory Kopplung schlägt fehl.

Werden alle Paketgrößen übertragen?

Ein Test mit anschwellender Ping-Paketgröße zeigt, dass kleinere Daten problemlos übertragen werden. Größere Pakete (oft ab 1492 Byte), welche fragmentiert werden müssten, werden dagegen jedoch nicht übertragen.

Diese Pakete werden vom Carrier / ISP verworfen, da bspw. der bei DSL notwendige PPPoE-Paketheader die IPv4/IPv6-Pakete zu groß werden lässt.

Mit einem anschwellendem Ping kann man testen, ob alle Datenpaketgrößen erfolgreich übertragen werden können:

! Das „df-bit" ist nicht gesetzt (default), der Router fragmentiert, aber zu spät, die Pakete sind auch nach dem

! Fragmentieren zu groß:

R2#

R2#ping

Protocol [ip]:

Target IP address: 12.12.12.1

Repeat count [5]: 1

Datagram size [100]:

Timeout in seconds [2]: 1

Extended commands [n]:

Sweep range of sizes [n]: y

Sweep min size [36]: 1480

Sweep max size [18024]: 1520

Sweep interval [1]:

Type escape sequence to abort.

Sending 41, [1480..1520]-byte ICMP Echos to 12.12.12.1, timeout is 1 seconds:

!!!!!!!!!!!!!!!!!........................

Success rate is 41 percent (17/41), round-trip min/avg/max = 1/38/590 ms

R2#

Die Regel, dass bspw. für DSL-Anschlüsse am logischen Routerinterface (cisco = interface dialer) die MTU-Size 1492 Byte beträgt,

mag oft stimmen. Zumal diese Größe durch den Carrier auch beim PPP-Verbindungsaufbau vorgegeben werden kann:

-> RFC2516: „The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than 1492."

Die abweichenden 8 Byte zu der normalerweise 1500 Byte betragenden MTU-Size setzen sich wie folgt zusammen:

| 2 byte PPP protcol ID | 6 byte PPPoE header |

Damit ergibt sich am Beispiel eines cisco-Routers und eines Standard DSL-Anschlusses (DSL Business evtl. abweichend):

interface Dialer1

ip mtu 1492

! tcp adjustment regelt auch die TCP-Verbindungen herunter auf die MTU-size minus den IP- und TCP-Header von je

! 20 byte:

ip tcp adjust-mss 1452

Werden die Datenpakete optimal fragmentiert oder werden Leitungskapazitäten verschwendet?

Falls die Datenübertragung klappt, kann eine nicht abgestimmte MTU-Größe immer noch dazu führen,

dass ein Paket beim Carrier nur deswegen fragmentiert wird, weil es nur ein paar Byte zu groß ist.

Besser also, die Anzahl der Daten gleich so anzupassen, dass keine unnötige Fragmentierung erfolgen muss.

Oft ist jedoch nicht klar, welche Framegröße der Carrier am Übergabepunkt akzeptiert.

In den Fällen, in denen diese automatische Aushandlung versagt, aber auch zur Kontrolle und zum technischen Verständnis, kann man, um den optimalen MTU-Wert zu ermitteln, folgenden Test durchführen:

Am Dialer-Interface (im Beispiel hier Cisco, bei anderen Herstellern sinngemäß) die MTU-Size auf bspw. 1600 Byte heraufsetzen und

danach einen anschwellenden Ping mit gesetzten „don´t fragment bit" senden.

Dadurch sendet ein Gerät auf dem Weg zum Ziel, welches fragmentieren müsste, eine icmp- Fehlermeldung sinngemäß:

„the data must be fragmented but the 'don't fragment' flag is on" und zeigt damit die Paketgröße an, die nicht mehr funktioniert:

Durch Setzen des "dont fragment bit" (Set DF bit in IP header? [no]: yes) stellen wir genau fest, ab welcher Paketgröße der carrier die Pakete nicht mehr weiterleitet, ohne zu fragmentieren:

R2#ping

Protocol [ip]:

Target IP address: 12.12.12.1

Repeat count [5]: 1

Datagram size [100]:

Timeout in seconds [2]: 1

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]: yes

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]: y

Sweep min size [36]: 1480

Sweep max size [18024]: 1520

Sweep interval [1]:

Type escape sequence to abort.

Sending 41, [1480..1520]-byte ICMP Echos to 12.12.12.1, timeout is 1 seconds:

Packet sent with the DF bit set

!!!!!!!!!!!!!............................

Success rate is 31 percent (13/41), round-trip min/avg/max = 1/34/395 ms

R2#

Es ist zu erkennen, dass Datenpakete bis 1492 Byte ohne Fragmentierung weitergeleitet werden.

Also setzen wir die MTU-Size auf genau diesen ermittelten Wert: 1492 Byte.

(Bei anderen WAN-Übertragungen wird die MTU-Size am WAN-Interface zum Carrier/ISP gesetzt).

interface Dialer1

mtu 1492

Nun testen wir erneut die Datenübertragung mit Paketen, welche beispielhaft eine Größe zwischen 1480 und 1520 Byte haben:

R2#

R2#ping

Protocol [ip]:

Target IP address: 12.12.12.1

Repeat count [5]: 1

Datagram size [100]:

Timeout in seconds [2]: 1

Extended commands [n]:

Sweep range of sizes [n]: y

Sweep min size [36]: 1480

Sweep max size [18024]: 1520

Sweep interval [1]:

Type escape sequence to abort.

Sending 41, [1480..1520]-byte ICMP Echos to 12.12.12.1, timeout is 1 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (41/41), round-trip min/avg/max = 1/34/462 ms

R2#

Mit dieser korrekten MTU-Size fragmentiert der Router die Pakete rechtzeitig.

Dadurch werden die Daten nicht nur korrekt übertragen, sondern der Carrier muss nicht sofort wieder

fragmentieren, was die Datenübertragung verbessert.

Fazit:

Mit anschwellenden Pings und gesetzten „dont fragment bit" kann die maximale Paketgröße ermittelt werden.

Diese Paketgrößeneinstellung am logischen Routerinterface vermeidet Fehler und sorgt zudem für eine schnellere Datenübertragung.

Dieses Thema MTU Size ist sehr alt, führt aber immer wieder zu speziellen Fehlern.

IPv6 MTU path discovery mag Abhilfe schaffen, ist aber abhängig von durchgängig freigeschalteten ICMPv6-Paketen.

Beidseitig gleich sein muss die MTU-Size übrigens nicht, sie darf lediglich nirgends höher als die tatsächliche maximale physikalische Übertragsmöglichkeit sein.

Im Zweifelsfall kann man die MTU-Size verringern, damit riskiert man jedoch, dass bereits ankommenden Pakete auf diesen niedrigen Wert verringert, also fragmentiert, werden.

Unser passendes Programm dazu finden Sie hier: https://www.iternas.com/aicalc-de

In der IPv6-Datenübertragung sorgt ICMPv6 für eine Ermittlung der MTU.

Bitte beachten Sie daher, das bestimmte ICMPv6 Pakte unbedingt durchgängig erlaubt werden. Andernfalls kann IPv6 MTU Path Discovery keinen Wert ermitteln.

Mehr zum Thema IPv6 finden Sie hier: https://www.iternas.com/ipv6