Unitymedia ConnectBox MTU

[shm0]

Hi!

Irgendwie hängt die connectbox bei einer mtu von 1460 fest?
Laut google sollte dass bei DSLite der Fall sein, es ist aber ein DualStack Anschluss.
Und vorher mit DSLite hatte ich einen MTU Wert von 1412 ermittelt.
Also irgendwie stimmt da was nicht.

 

[Andreas1969]

Und vorher mit DSLite hatte ich einen MTU Wert von 1412 ermittelt.

Wie hast Du das denn genau ermittelt :kratz:

 

[tq1199]

Wie hast Du das denn genau ermittelt :kratz:

Der Router kann das mitteilen:

From fritz.box (192.168.178.1) icmp_seq=1 Frag needed and DF set (mtu = 1500)

Z. B.:

<i>
</i>:~$ ping -c 1 -s $((1501-28)) -M do ubuntuusers.de
PING ubuntuusers.de (213.95.41.4) 1473(1501) bytes of data.
From fritz.box (192.168.178.1) icmp_seq=1 Frag needed and DF set (mtu = 1500)
--- ubuntuusers.de ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

 

[shm0]

Das komische ist, der ping do not fragment test liefert 1472 (+28 ip und icmp header = 1500 mtu)
Aber alle web basierenden Tools liefern 1460.
Auch dass MTU Discovery (RFC1191) = ON zurückgeben wird.
Hab jetzt verschiedene Geräte ausprobiert. Es wird immer 1460 angezeigt. Aber der ping test liefert immer 1472 bzw 1500.
Stell ich einen niedrigeren MTU Wert ein z.b. 1280 wird dieser korrekt angezeigt.
Leitet UM etwa bestimmten traffic über einen tunnel?
Google liefert auch ein paar Ergebnisse dazu. (connectbox + mtu 1460)
Aber meistens in verbindung mit DSLite (-40 für den IPv6 Header = 1460 ?)
Das komische als der Anschluss hier noch DSLite war wurde eine MTU von 1412 angezeigt.
Irgendwie ist da was komisch.

Und wie siehts aus mit dem Bridge Mode für die ConnectBox?
Und was ist das für ne Web-Oberfläche?
Ist ja fast so wie schlimm wie die FritzBox.
Wahnsinn.

 

[Andreas1969]

Und wie siehts aus mit dem Bridge Mode für die ConnectBox?

Abwarten :kafffee:

Und was ist das für ne Web-Oberfläche?
Ist ja fast so wie schlimm wie die FritzBox.
Wahnsinn.

Nö, viel schlimmer cfreak:

 

[tq1199]

Das komische ist, der ping do not fragment test liefert 1472 (+28 ip und icmp header = 1500 mtu)

Das verstehe ich nicht. Poste mal die Ausgaben von:

<i>
</i>ping -c 1 -s $((1500-28)) -M do ubuntuusers.de

<i>
</i>ping -c 1 -s $((1501-28)) -M do ubuntuusers.de

wenn auf deinem Gerät (NIC), _temporär_ ein MTU-Wert von 1600 konfiguriert ist.

EDIT:

... und danach die Ausgaben von:

<i>
</i>ping -c 1 -s $((1460-28)) -M do ubuntuusers.de

<i>
</i>ping -c 1 -s $((1461-28)) -M do ubuntuusers.de

wenn auf deinem Gerät (NIC), _temporär_ ein MTU-Wert von 1600 konfiguriert ist.

 

[shm0]

Das verstehe ich nicht. Poste mal die Ausgaben von:

Ich auch nicht :kratz:

ping -c 1 -s $((1500-28)) -M do ubuntuusers.de
PING ubuntuusers.de (213.95.41.4) 1472(1500) bytes of data.
1480 bytes from ha.ubuntu-eu.org (213.95.41.4): icmp_seq=1 ttl=54 time=20.3 ms
--- ubuntuusers.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 20.341/20.341/20.341/0.000 ms

ping -c 1 -s $((1501-28)) -M do ubuntuusers.de
PING ubuntuusers.de (213.95.41.4) 1473(1501) bytes of data.
From ip-95-222-170-123.hsi15.unitymediagroup.de (95.222.170.123) icmp_seq=1 Frag needed and DF set (mtu = 1500)
--- ubuntuusers.de ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

ping -c 1 -s $((1460-28)) -M do ubuntuusers.de
PING ubuntuusers.de (213.95.41.4) 1432(1460) bytes of data.
1440 bytes from ha.ubuntu-eu.org (213.95.41.4): icmp_seq=1 ttl=54 time=20.6 ms
--- ubuntuusers.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 20.645/20.645/20.645/0.000 ms

ping -c 1 -s $((1461-28)) -M do ubuntuusers.de
PING ubuntuusers.de (213.95.41.4) 1433(1461) bytes of data.
1441 bytes from ha.ubuntu-eu.org (213.95.41.4): icmp_seq=1 ttl=54 time=20.2 ms
--- ubuntuusers.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 20.215/20.215/20.215/0.000 ms

cfosspeed ermittelt auch eine mtu von 1460 als optimal.
Hmm

 

[tq1199]

ping -c 1 -s $((1500-28)) -M do ubuntuusers.de
PING ubuntuusers.de (213.95.41.4) 1472(1500) bytes of data.
1480 bytes from ha.ubuntu-eu.org (213.95.41.4): icmp_seq=1 ttl=54 time=20.3 ms
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 20.341/20.341/20.341/0.000 ms

ping -c 1 -s $((1501-28)) -M do ubuntuusers.de
PING ubuntuusers.de (213.95.41.4) 1473(1501) bytes of data.
From ip-95-222-170-123.hsi15.unitymediagroup.de (95.222.170.123) icmp_seq=1 Frag needed and DF set (mtu = 1500)
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Jetzt ist es klar, die MTU deines Routers (border device mit der IP 95.222.170.123) ist 1500. Oder ist das ein AFTR-Gateway?

EDIT:

Auf welchem Gerät hast Du den Ping ausgeführt?

 

[robert_s]

Aber alle web basierenden Tools liefern 1460.

Welche Tools? Poste doch mal Link + Screenshot von Deinem Ergebnis.

 

[shm0]

https://www.speedguide.net/analyzer.php

« SpeedGuide.net TCP Analyzer Results »
Tested on: 2018.11.28 18:22
IP address: x.x.xxx.xxx
Client OS/browser: Windows 7 (Chrome 70.0.3538.110)
TCP options string: 0204058c010303080402080a004fdf2300000000
MSS: 1420
MTU: 1460
TCP Window: 66048 (not multiple of MSS)
RWIN Scaling: 8 bits (2^8=256)
Unscaled RWIN : 258
Recommended RWINs: 65320, 130640, 261280, 522560, 1045120
BDP limit (200ms): 2642kbps (330KBytes/s)
BDP limit (500ms): 1057kbps (132KBytes/s)
MTU Discovery: ON -> ist ausgeschaltet
TTL: 49
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)

http://www.letmecheck.it/mtu-test.php

The maximum MTU size for x.x.x.x is: 1500

MSS Clamping funktioniert nur bei tcp.

Speedguide Analyzer läuft über http (tcp)
Ping Test liefert 1500.
Also läuft die ConnectBox mit einer MTU von 1500.
Aber es könnte sein, dass TCP Streams über einen Tunnel geleitet werden und der tcp analyzer test deshalb 1460 liefert ?
Welches Protokoll hat 40 bytes overhead? L2TP?

Jetzt ist es klar, die MTU deines Routers (border device mit der IP 95.222.170.123) ist 1500. Oder ist das ein AFTR-Gateway?

Ist ein DualStack Anschluss. Also wird kein DSLite AFTR Gateway benutzt?

Auf welchem Gerät hast Du den Ping ausgeführt?

Auf einem Gerät hinter der ConnectBox. (Debian Testing)

 

[shm0]

Kann ein mod die IP aus den Posts raus editieren bitte

Und kann jemand mit nativen ipv4 / dslite / dualstack Anschluss den Test hier durchführen?

https://www.speedguide.net/analyzer.php

Danke.

Und warum versendet UM eigentlich nur Kabel mit F Quick Steckern?

 

[tq1199]

Und kann jemand mit nativen ipv4 / dslite / dualstack Anschluss den Test hier durchführen?
https://www.speedguide.net/analyzer.php

Habe ich gemacht und wie nicht anders zu erwarten, zeigt der Test die MTU des Gerätes (NIC) mit dem der Test durchgeführt wird ... und nicht die MTU des Routers (border device).

 

[shm0]

Wenn ich die MTU des Routers auf z.B. 1280 setze, wird dieser korrekt angezeigt.
Nur MTU Werte über 1460 funktionieren nicht.
Und alle Geräte hier werden ja wohl kaum ein MTU Wert von 1460 benutzen.

Habe ich gemacht und wie nicht anders zu erwarten, zeigt der Test die MTU des Gerätes (NIC) mit dem der Test durchgeführt wird ... und nicht die MTU des Routers (border device).

Das mag sein, aber wenn jetzt der Router (oder ein Gateway danach) auf eine MTU von 1460 eingestellt ist und mss clamping durchführt.
Dann ist es egal ob die Clients 1500 benutzen, da die MTU bzw MSS auf 1460/1420 geändert wird.

Anschluss neben an: IPv4 Only + Fritzbox, da wird ein MTU Wert von 1500 angezeigt.

Entweder ConnectBox Bug oder UM tunnelt da irgendwas?

Welcher MTU wurde denn angezeigt? Und welcher Anschluss Typ?

 

[tq1199]

Welcher MTU wurde denn angezeigt? Und welcher Anschluss Typ?

Z. B.:

<i>
</i>« SpeedGuide.net TCP Analyzer Results »
Tested on: 2018.11.29 03:31
IP address: xx.xxx.xxx.xxx
TCP options string: 020405980402080a0005e32f0000000022020101
MSS: 1432
MTU: 1472
TCP Window: 28640 (multiple of MSS)
RWIN Scaling: 0 bits
Unscaled RWIN : 28640
Recommended RWINs: 63008, 126016, 252032, 504064, 1008128
BDP limit (200ms): 1146kbps (143KBytes/s)
BDP limit (500ms): 458kbps (57KBytes/s)
MTU Discovery: ON
TTL: 50
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)

mit nativem IPv4 (kein DS).

 

[shm0]

MTU auf Router 1500 und auf dem Client Gerät 1472?
Wie sehen die Werte aus wenn auf dem Router 1472 eingestellt ist und auf dem Client 1500?

 

[tq1199]

MTU auf Router 1500 und auf dem Client Gerät 1472?

Ja.

Wie sehen die Werte aus wenn auf dem Router 1472 eingestellt ist und auf dem Client 1500?

Ich kann die MTU für IPv4, auf dem Router nicht ändern.


BTW: Warum geht dann bei dir, ein Ping mit 1500 noch durch und ein Ping mit 1501 nicht mehr?


EDIT:

Hier die Werte wenn ich auf dem Gerät 1600 (d. h. > als die 1500 auf dem Router) konfiguriere:

<i>
</i>MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1448, which is less than MSS because of Timestamps, or other TCP/IP options used.

 

[shm0]

Hmm
Da der ping test eine mtu von 1500 liefert, gehe ich davon aus, dass die ConnectBox auch einen MTU von 1500 benutzt.
MSS Clamping funktioniert nur bei tcp.
Ich gehe davon aus, dass da tcp traffic umgeleitet (vllt über einen tunnel oder ein gateway der mit mtu 1460 konfiguriert ist und mss clamping macht) wird.
Die Frage ist warum? Ich hol schon mal meinen Aluhut raus

 

[tq1199]

Da der ping test eine mtu von 1500 liefert, gehe ich davon aus, dass die ConnectBox auch einen MTU von 1500 benutzt.

Ja.

Ich gehe davon aus, dass da tcp traffic umgeleitet (vllt über einen tunnel oder ein gateway der mit mtu 1460 konfiguriert ist und mss clamping macht) wird.
Die Frage ist warum?

Ich denke nicht, dass umgeleitet wird. Mach mal den Test (mit dem Webtool) bei einer MTU des Gerätes (NIC) von z. B. 1600 (d. h. > als die MTU des Routers), mit 1500 auf dem Gerät (d. h. = mit der MTU des Routers) und 1472 auf dem Gerät (d. h. < als die MTU des Routers).

 

[shm0]

Connectbox lässt nur Werte zwischen 1280 und 1500 zu.
Und wie gesagt alle Werte höher >= 1460 funktionieren nicht.

Auch das Path MTU Discovery immer als aktiviert angezeigt wird egal auf welchem Gerät ist auch ein Indiz.
Und wer benutzt schon Path MTU Discovery :kratz:

 

[boba]

Und wer benutzt schon Path MTU Discovery :kratz:

Jeder und alles natürlich. Es ist essentiell für tcp Verbindungen für optimal eingestellte MTU.

 

[tq1199]

Connectbox lässt nur Werte zwischen 1280 und 1500 zu.

Ich habe ja auch nicht geschrieben, dass Du die MTU der Connectbox ändern sollst (siehe oben). Denn es geht doch (lt. Threadtitel und 1. Beitrag) darum festtzustellen welche MTU deine Connectbox per Standard-Einstellung hat, ... oder?

Und wie gesagt alle Werte höher >= 1460 funktionieren nicht.

Wo funktionieren sie nicht? Wenn Du die Änderung auf deinem Gerät (und nicht auf der ConnectBox) machst, funktioniert der Test schon. Ich habe das doch auch so gemacht. Du bist mit dem Ergebnis des Tests evtl. nicht zufrieden oder verstehst das Ergebnis des Tests nicht?

EDIT:

... oder geht es jetzt gar nicht mehr um die MTU der CB, sondern um TCP-Optimierungen?

 

[shm0]

Jeder und alles natürlich. Es ist essentiell für tcp Verbindungen für optimal eingestellte MTU.

Funktioniert aber nur wenn icmp nicht gefiltert wird?

@tq1199
Die ConnectBox hat MTU 1500.
Ändert nichts an der Tatsache, dass aus irgendeinen Grund TCP Streams auf MTU/MSS 1460/1420 geändert werden.

Alle MTU Werte >= 1460 funktionieren auf Endgeräten nicht. (Für TCP zumindest)

 

[tq1199]

... aus irgendeinen Grund TCP Streams auf MTU/MSS 1460/1420 geändert werden.

Alle MTU Werte >= 1460 funktionieren auf Endgeräten nicht. (Für TCP zumindest)

Ja, das kann schon so sein. Da müsste man schauen welche MSS beim TCP-handshake (syn und syn+ack) für diese TCP-Streams ausgehandelt wird. Kann man z. B. mit tcpdump (oder gleichwertig) anzeigen lassen.

EDIT:

Schau mal mit:

<i>
</i>tcpdump -vvveni <Interface> host <IP-Adresse> and 'tcp[tcpflags] & (tcp-syn) != 0'

nach, welche MSS die Gegenstelle für den TCP-Stream (beim syn+ack) mitteilt.

 

[boba]

Jeder und alles natürlich. Es ist essentiell für tcp Verbindungen für optimal eingestellte MTU.

Funktioniert aber nur wenn icmp nicht gefiltert wird?

Ja, icmp ist dafür erforderlich. Aber man filtert icmp nicht. Das Protokoll hat einen Sinn.

 

[tq1199]

Ja, icmp ist dafür erforderlich. Aber man filtert icmp nicht. Das Protokoll hat einen Sinn.

Ja, das ist richtig, ... aber das kann man nicht verhindern und es gibt Konfigurationen (für MSS) mit denen man z. B. auch ein "ICMP black hole" _nur für TCP_ umgehen kann. Z. B.:

<i>
</i>net.ipv4.tcp_mtu_probing = 1 # Disabled by default, enabled when an ICMP black hole detected
#net.ipv4.tcp_mtu_probing = 2 # Always enabled, use initial MSS of tcp_base_mss.
net.ipv4.route.min_adv_mss = 256
net.ipv4.tcp_base_mss = 1024