Unitymedia Lustige MTU Werte

[Wechselbalg]

Hallo zusammen,

vorab zur Info. Auf meinem Server läuft ein Debian 5.0 (Linux) und es ist aktuell gehalten. Als Netzwerkkarte kommt eine Realtek 100 MBit Karte zum Einsatz (eth1), die an das Kabelmodem angeschlossen ist.

Jetzt hatte ich ja bereits so einige Probleme mit der Telefonie, die sich Teilweise gelegt haben, jedoch ist mir etwas aufgefallen. Ich weiss nicht genau, seit wann das so ist, allerdings denke ich, dass es sicherlich nicht normal ist.

eth1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:xxx.xxx.xxx.xxx Bcast:255.255.255.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:576 Metric:1 RX packets:21936179 errors:9 dropped:0 overruns:0 frame:9 TX packets:22641557 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11166520174 (10.3 GiB) TX bytes:13380183036 (12.4 GiB)

Man beachte hierbei bitte den Wert für die MTU: 576 (!!!) Laut Wikipedia ist dies eine Größe die für das X.25 Protokoll oder ISDN verwendet wird. In dieser Konstellation ist mir dann auch folgendes aufgefallen.

Bei größeren Downloads über BT (Debian DVD Images) wird nur ca. 1 MByte / Sekunde im Download erreicht, dafür aber 100-120 KByte Upload, was definitiv übertrieben viel ist und somit dieser auch dicht ist. Upload innerhalb des BT-Clients ist auf 20 K begrenzt, ansonsten gibt es keine weiteren Uploads / Traffic, was also nicht der Grund für so viel Upload sein kann. Telefonie funktioniert witziger Weise während dessen immer noch. Bei einzelnen Downloads komme ich auf über 2 MByte / Sekunde. Das ist also nicht das Problem. Was mich jedoch wundert ist der extrem hohe Upload, den ich mir nicht erklären kann.

Weiteres Phänomen. Wenn ich die MTU händisch ändere z.B. auf 1500, 1480 oder 1464 geht neben einem einzelnen Download so gut wie gar nichts mehr. Was mich daran stört ist, dass offensichtlich durch "relativ" wenig Traffic, viel Upload entsteht, da wahrscheinlich mehr Pakete als sonst übertragen werden müssen, richtig?

Jetzt ist die Frage, ob es überhaupt lohnt und Sinn macht, sich bei UnityMedia zu melden und das "Problem" zu melden oder nicht. Hat jemand eine Idee? Vielleicht bin ich ja auch total auf dem Holzweg und das ist alles "normal".


Gruß vom Wechselbalg

 

[hroc]

hier das gleiche, auch debian lenny.

eth1 Link encap:Ethernet Hardware Adresse 00:60:97:xx:xx:xx
inet Adresse:xx.xx.xx.xx Bcast:255.255.255.255 Maske:255.255.248.0
UP BROADCAST RUNNING MULTICAST MTU:576 Metrik:1
RX packets:837616612 errors:1 dropped:0 overruns:1 frame:1
TX packets:400561644 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:4123160226 (3.8 GiB) TX bytes:2389558551 (2.2 GiB)
Interrupt:9 Basisadresse:0x5000

eventuell kommt dieser debian bug infrage

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513616

?

dann sollte ein manuelles anpassen aber zum gewünschten ergebnis führen?

gruß
hroc

edit: werde von DHCP Client V3.1.1 mal auf die unstable version wechseln, vielleicht hat es sich dann ja erledigt

 

[yasar]

hier mein debian lenny 5.03
eth0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:1237033 errors:2 dropped:2 overruns:2 frame:0
TX packets:1202905 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:144595876 (137.8 MiB) TX bytes:102570630 (97.8 MiB)
Interrupt:17 Basisadresse:0xdc00


bei mir klappts... (hab das system gestern neu aufgesetzt!!)

 

[Wechselbalg]

Hallo zusammen,

hroc, ich habe folgende Versionen installiert:
dhcp3-client - Version: 3.1.1-6+lenny3
Könnte also durchaus damit zusammenhängen. Wenn du Ergebnisse hast, würden die mich wirklich interessieren.

yasar, das ist sehr interessant und du hast auch überhaupt keine Probleme bei vielen Connections, wie z.B. P2P oder mehreren Downloads gleichzeitig? Mich würde mal interessieren, was bei dir iptraf sagt, wenn du auf das Interface schaust, während auf der Leitung was los ist. Ich werde vielleicht heute Nacht nochmal auf 1500 umstellen und schauen, wie sich das über die Tage entwickelt.

Bin für weitere Informationen, Ideen, etc. dankbar.

Gruß vom Wechselbalg

 

[Wechselbalg]

So weitere Infos zu meinem Fall:

Netzwerkkarte ist entsprechend konfiguriert und manuell per $sudo ifconfig eth1 mtu 1500 entsprechend gesetzt.

eth1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:xxx.xxx.xxx.xxx Bcast:255.255.255.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:38344062 errors:17 dropped:0 overruns:0 frame:17 TX packets:37533698 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:22064194169 (20.5 GiB) TX bytes:21113664767 (19.6 GiB)

Ich habe Testweise mal einen größeren HTTP Download angeschmissen und folgendes herausgefunden. Während der Download läuft geht rein gar nichts mehr. Ich bekomme sogar bei dem Aufruf einer normalen HTTP Seite (z.B. Golem) einen Timeout! Das hatte ich bisher auch noch nie. Also das geht mal so gar nicht.

Sollte ich vielleicht doch mal bei UM anrufen und fragen, was das sein könnte?

Gruß vom Wechselbalg

 

[hroc]

hmm hab die mtu jetzt auf 1500, wenn ich nen download starte läuft der mit 2,40M/s (qsc 1GB Testfile, wget) durch, mein Ping steigt von ~13ms auf ~100ms normales Surfen etc kein Problem...

gruß
hroc

 

[FieserKiller]

hio, ich habe hier ein gentoo - mtu 1500

dhcpcd 4.0.13

Nagelt mich nicht drauf fest, aber wenn ich mich recht entsinne dann gibt der dhcp server den clients die MTU vor die sie setzen sollen - also könnte es sein dass eure router da irgendeinen qutsch machen?
Oder eure clients wenden die vom server übergebene mtu nicht an und überschreiben sie mit einem eigenen wert der in dem configfile fest vorgegeben ist.. checkt mal /etc/dhcpc.conf oder wie das bei euch auch eissen mag..

 

[Wechselbalg]

@hroc:
Genau so sollte es ja auch sein. Dass die Performance und der übrige Traffic ein wenig einbricht, ist ja vollkommen normal. Allerdings sollte das im "Rahmen bleiben". Deine Erfahrungswerte sind ja völlig in Ordnung.

@FieserKiller:
Ich habe es auch so verstanden, dass die MTU vom DHCP Server übermittelt wird. Da aber der DHCP Server in diesem Fall die Gegenstelle / das Kabelmodem ist, sollte die ja korrekte Werte liefern, was sie auch tut, wenn die DHCP Version aktualisiert wurde (siehe Beitrag von hroc). Die Rede ist hier ja von der Netzwerkschnittstelle, die direkt an das Modem angeschlossen ist. Ich zumindest nutze keinen weiteren "Router" dazwischen.

Mein DHCP Server, der für das interne Netz zuständig ist, der vergibt ganz normale IPs und MTU Werte.

Gruß vom Wechselbalg

 

[Tron]

Hallo Leute,

nachdem ich meinen Linux-Router hardwaremäßig aufgerüstet habe stelle ich auch fest, daß die MTU nur bei 576 liegt. Einhergegangen ist ein ziemlicher Einbruch der Übertragungsrate, ist ja auch kein Wunder. Ich bin mir ziemlich sicher, daß die MTU vorher bei 1500 (wie zu erwarten) lag, ein testweise an das Modem angeschlossener eeePC bekommt auch 1500. Nur mein Router nicht, selbst nach Wechsel der Netzwerkkarte. Das manuelle hochsetzen der MTU geht zwar, aber damit ist es noch langsamer und ja irgendwie nicht Sinn der Angelegenheit.

Hat da irgendjemand mal eine Erklärung gefunden?

Gruß,
Tron

 

[Tron]

Hallo Leute,

ich vergaß: Debian stable (Lenny), Kernel 2.6.26.

Gruß,
Tron

 

[Wechselbalg]

Hallo Tron,

ich habe leider auch keine Lösung zu dem Problem direkt gefunden. Ich habe mittlerweile eine Firewall vorgeschaltet, in Form eines ALIX Boards, welche 3x 100MBit NICs haben und die erhalten ebenfalls die vollen 1500 MTU.

Vielleicht liegt es am Netzwerkkartentreiber / -modul? Schon mal versucht den Hersteller eigenen Treiber / Kernelmodul einzubinden?

Gruß vom Wechselbalg

 

[Tron]

Vielleicht liegt es am Netzwerkkartentreiber / -modul? Schon mal versucht den Hersteller eigenen Treiber / Kernelmodul einzubinden?

Das ist unwahrscheinlich. Ich habe es mit dem Onboard-NIC (Marvell irgendwas, sky2-Kernelmodul) und mit verschiedenen "alten" 3Com 905 (der Klassiker, Kernelmodul 3c59x) probiert - immer dasselbe. Vor allem hat es mit den 3Com vorher funktioniert. Ich glaube eher, daß das Modem etwas buggy ist, mit einem anderen Linuxrechner (der am switch wunderbar läuft) wollte es überhaupt keine Verbindung aufbauen, das LINK-Lämpchen blieb dunkel. Komisch ist auch, daß der dhcp-Server des Modems immer nur eine MAC akzeptiert. Wechselt man das NIC des Rechners aus, muß man das Modem aus- und wiedereinschalten.

Vielleicht mache ich mal einen Reset des Modems auf Werkseinstellungen.

Gruß,
Tron

 

[sena]

Hallo

nachdem ich meinen Linux-Router hardwaremäßig aufgerüstet habe stelle ich auch fest, daß die MTU nur bei 576 liegt. Einhergegangen ist ein ziemlicher Einbruch der Übertragungsrate, ist ja auch kein Wunder. Ich bin mir ziemlich sicher, daß die MTU vorher bei 1500 (wie zu erwarten) lag, ein testweise an das Modem angeschlossener eeePC bekommt auch 1500. Nur mein Router nicht, selbst nach Wechsel der Netzwerkkarte. Das manuelle hochsetzen der MTU geht zwar, aber damit ist es noch langsamer und ja irgendwie nicht Sinn der Angelegenheit.

Ich habe gleiche Probleme hier. Das manuelle einsetzen der MTU hilft nichts. Ich habe auch Debian Lenny. Modem aus/einschalten hilft nichts. Das passiert erstes mal heute, nach dem ifup/ifdown. Ist das Debian-specific???

Gruß, Sergey

 

[Tron]

Ich habe gleiche Probleme hier. Das manuelle einsetzen der MTU hilft nichts. Ich habe auch Debian Lenny. Modem aus/einschalten hilft nichts. Das passiert erstes mal heute, nach dem ifup/ifdown. Ist das Debian-specific???

Gute Frage. Ich habe bisher auch keine befriedigende Lösung gefunden, ich habe erst einmal einen Router dazwischen geschaltet, damit geht es dann. Das ist aber natürlich auch nur ein "Würgaround". Komischerweise hat es mit dem "alten" System funktioniert, nur nach Hardware-Upgrade dann nicht mehr. Ob ich nach dem Umbau ein apt-get upgrade gemacht habe und damit Pakete aktualisiert habe, weiß ich nicht mehr, wahrscheinlich schon.

 

[antioxid]

Hallo.

Ihr müsst eure dhclient.conf editieren dann sollte es das auch gewesen sein.

Beispiel vorher :

request subnet-mask, broadcast-address, time-offset, routers,	domain-name, domain-name-servers, domain-search, host-name,	netbios-name-servers, netbios-scope, interface-mtu;

Beispiel nachher :

request subnet-mask, broadcast-address, time-offset, routers,	domain-name, domain-name-servers, domain-search, host-name,	netbios-name-servers, netbios-scope;

oder :

http://mathema.tician.de/node/409
http://ubuntuforums.org/showthread.php?t=972612
https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/61989

usw.

 

[Tron]

Ihr müsst eure dhclient.conf editieren dann sollte es das auch gewesen sein.

Hm. Ich werde es mal probieren, bezweifle aber, daß es hilft. Schließlich kann ich die MTU ja auch bei bestehender Verbindung auf 1500 erhöhen (ifconfig, ethtool, etc.). Das hilft aber nicht, die MTU ist dann zwar auf 1500 (zumindest sagt ifconfig das), die Verbindung ist aber genauso langsam. Eigentlich dürfte es egal sein, ob die MTU einfach nicht über die dhclient.conf gesetzt wird oder ob ich die nachträglich ändere.

Oder?

 

[antioxid]

Mir ging es erstmal nur um die MTU.

eine langsame Verbindung kann aus vielen Ursachen resultieren ,sehr wohl kann es auch ein Kernel-Problem sein in Kombination neuer Hardware. Möglicherweise kann eine Besserung eintreten durch nutzen des Kernel-2.6.30 aus den lenny-backports.

sicherzustellen gilt es auch ob die Karte mit 100MB läuft oder mit 10MB.

neue Hardware kann heissen Treiber-Staus experimental bzgl. Zusammenspiel von South und Northbridges, und somit noch nicht ausgereift genug um zufriedenstellend zu funktionieren.

bestes Beispiel ist das Wlan-Gedöns mal funktioniert es gut dann kommt ein Kernel-Update und es funktioniert dann auf einmal nicht mehr so gut, noch ein Kernel-Update es läuft auf einmal wieder.

das nennt man Regressions die sich hin und wieder einschleichen, Weiterentwicklung blablub.

ich würde es erstmal mit dem neueren Kernel probieren.

 

[Tron]

Mir ging es erstmal nur um die MTU.
ich würde es erstmal mit dem neueren Kernel probieren.

Äh, nein.

$Rechner --> Kabelmodem: MTU 576, Leitung zugewürgt (bei 20MBit-Leitung)
$Rechner --> Hardware-Router --> Kabelmodem: MTU 1500, angeblich auch auf Routerseite (der sich ja via dhcp die Einstellungen vom Modem holt), 20MBit, also volle Bandbreite.
$GanzAndererRechner, aber auch Linux --> Kabelmodem: MTU 1500

Alles very strange.

Da würde ich nicht sagen, daß ein anderer Kernel irgendwas ändert. Abgesehen davon ist das imho der aktuelle, bei stable gibt's nicht so oft einen neuen ;-)

Gruß,
Tron

 

[sena]

Ich habe folgende entdecken.

Nach

# ifdown eth0
# ifconfig eth0 mtu 1500
# ifup eth0

mtu bliebt 1500 (ifconfig zeigt mtu=1500) und alles ist in ordnung.

Nach

# ifdown eth0
# ifconfig eth0 mtu 576
# ifup eth0

mtu bliebt 576

Ich versuche "supersede interface-mtu 1500;" in /etc/dhcp3/dhclient.conf einsetzen. Dannach

# ifdown eth0
# ifconfig eth0 mtu 576
# ifup eth0

ifconfig zeigt mtu=1500, aber alles bleibt wie mit mtu=576 (sip Problems usw.)

Und endlich, nur mit folgende in /etc/network/interfaces

iface eth0 inet dhcp
pre-up /sbin/ifconfig eth2 mtu 1500

ich bekomme mtu=1500 und alles funktioniert.

 

[sena]

Tippfehler in letzte Zeile eth2->eth0

iface eth0 inet dhcp
pre-up /sbin/ifconfig eth0 mtu 1500