Jumbo Frames mit Telekom DSL-Anschluss

P

pwp

Well-Known Member
Hallo zusammen,

betreibt hier jemand zufällig einen Telekom ADSL2+ Anschluss mit Jumbo Frames (MTU 1508) bzw. kann jemand eine genaue Aussage dazu treffen, ob RFC 4638 seitens der Telekom unterstützt wird?

Ich hatte es mal ausprobiert, da seit OpenBSD 5.8 Jumbo Frames für den Realtek-Chipsatz der APU1C unterstützt werden, allerdings wird immer wieder eine MTU von 1492 gesetzt. Könnte das vielleicht auch am vorgeschalteten Modem liegen, welches u.U. keine MTU > 1500 unterstützt?
 
bei mir das selbe. Das Modem unterstützt nur eine MTU von 1500, davon gehen noch mal 8 Bit für PPP weg. Allerdings ist mein Modem schon weit über 5 Jahre alt, vielleicht brauchts da einfach neuere Hardware für.
 
Auch mit dem Zyxel VMG1312-B30A und Telekom-Firmware ist mehr als MTU 1492 nicht über die Leitung zu bekommen. Ob es an der Hardware oder an der Telekom liegt, weiß ich natürlich auch nicht.
 
pwp schrieb:
Hallo zusammen,

betreibt hier jemand zufällig einen Telekom ADSL2+ Anschluss mit Jumbo Frames (MTU 1508) bzw. kann jemand eine genaue Aussage dazu treffen, ob RFC 4638 seitens der Telekom unterstützt wird?

Ich hatte es mal ausprobiert, da seit OpenBSD 5.8 Jumbo Frames für den Realtek-Chipsatz der APU1C unterstützt werden, allerdings wird immer wieder eine MTU von 1492 gesetzt. Könnte das vielleicht auch am vorgeschalteten Modem liegen, welches u.U. keine MTU > 1500 unterstützt?
Zum Vergrößern anklicken....

Ähh, Jumbo Frames & MTU 1500, hab ich was verpasst (802.3, RFC5180) ?
 
Danke für alle Antworten.

Hatte eben nochmal Zeit es erneut zu testen:
Code: 
PPPoE-Discovery
        code Initiation, version 1, type 1, id 0x0000, length 18
        tag Service-Name, length 0
        tag Host-Uniq, length 4 \XXX\XXX\XXXX
        tag PPP-Max-Payload, length 2 \005\334
PPPoE-Discovery
        code Offer, version 1, type 1, id 0x0000, length 52
        tag Service-Name, length 0
        tag Host-Uniq, length 4 \XXX\XXX\XXXX
        tag PPP-Max-Payload, length 2 \005\324
        tag AC-Name, length 10 XXXXXXXXXX
        tag AC-Cookie, length 16 \XXX\XXXXX\XXXXX\XXX\XXXX\XXX\XXXXXXXXXXXX

Auf die PPPoE-Initiation mit PPP-Max-Payload=1500 hin antwortet die Telekom mit PPP-Max-Payload=1492, wodurch in OpenBSD wieder die Default-MTU gesetzt wird. Infosfern wird von der Telekom zwar der Tag aus RFC 4638 unterstützt, aber nicht die eigentlich höhere MTU. Schade...
 
~8 Jahre später funktioniert es dann doch:

# ifconfig em2 ; ifconfig pppoe0 em2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1508 lladdr 00:00:11:22:33:44 index 3 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 index 6 priority 0 llprio 3 dev: em2 state: session sid: 0x33 PADI retries: 5 PADR retries: 0 time: 07:01:41 sppp: phase network authproto pap authname "xxx@t-online.de" dns: 217.237.149.205 217.237.151.51 groups: pppoe egress status: active inet6 fe80::1234:1234:1234:1234%pppoe0 --> prefixlen 64 scopeid 0x6 inet 217.xxx.xxx.xxx --> 62.xxx.xxx.xxx netmask 0xffffffff inet6 2003:e2:1234:1234:1234:1234:1234:1234 --> prefixlen 64 autoconf pltime 1225 vltime 13825
 
Ich hätte mal die Manpage zu Ende lesen müssen "If the path cannot pass the larger Ethernet frames, negotiation will succeed but the larger frames will be dropped. For this reason it is important to test the connection with large packets when enabling a higher MTU.", ein 1500 byte ping geht nämlich nicht raus ping: local error: message too long, mtu: 1500 :(

Baby Jumbo Frames (RFC 4638) with igb-based NICs on pfSense

pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500 Verification. Of course, we can't declare victory just yet until we've verified that we can successfully send 1500 byte frames without fragmentation. This is easily checked with a simple ping though; ping -f -l...
blog.kingj.net blog.kingj.net

Hab jetzt wieder max-mss in der pf.conf gesetzt...
 
Wenn du noch Lust zur Optimierung hast, ist deine Energie fürs Shaping mit fq-codel besser aufgehoben. Das Wissen zur max-mtu nützt dir dabei.

Linux Home Router Traffic Shaping With FQ_CoDel - b1c1l1 blog

CoDel (Controlled Delay) is an Active Queue Management algorithm that drops packets based on delay rather than queue length. FQ_CoDel (Fair Queueing Controlled Delay) combines CoDel with fair queueing to share bandwidth between flows.
www.b1c1l1.com

Best practices for benchmarking Codel and FQ Codel - Bufferbloat.net

www.bufferbloat.net www.bufferbloat.net
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben