Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a gigabit ethernet connection from my laptop to my router, and a working ipv6 connection to the internet. I can receive very large packets from sites on the internet, with sizes up to at least 10000 bytes (according to wireshark). (edit: turns out to be linux's 'generic receive offload') However, when trying to send anything, my local computer fragments at just below 1500 bytes for ipv6. (On ipv4, I can send tcp packets to the internet of at least 1514 bytes, I can ping with packets up to the configured mtu of 6128 but they are blackholed.)

I'm on ubuntu 12.04. I have configured an mtu for my eth0 of 6128 (the maximum it accepts), both using ip link set dev eth0 mtu 6128 and in the NetworkManager applet gui, and restarted the connection. ip link show eth0 shows the 6128 mtu is indeed set. ip -6 route shows that none of the paths the kernel knows about have an mtu set. I can ping over ipv4 with packets up to 6128 bytes (though I don't get responses), but when I do ping6 myrouter -c3 -s1500 -Mdo I get error replies from my own computer saying that the packets are too large and the mtu is 1480. I have confirmed with Wireshark that nothing is put on the wire, and the replies are indeed generated by my own computer.

So, how do I get my computer to use the larger mtu?

share|improve this question
    
The MTU must be changed on all devices on your network, not just your workstation. This means you have to configure your router, switches, and everything else. If one device doesn't support a larger MTU, then you either have to replace the device, or accept a lower mtu. –  Zoredache Sep 19 '12 at 16:19
add comment

3 Answers

The MTU is mostly used locally. Using Jumbo frames over multiple network hops (like router+internet) is tricky and will most likely not work. DSL, for example, will usually limit the Path MTU to 1492 bytes. As a general rule, the Path MTU is determined by the smallest link MTU between any of the participating routers. Unless you control the whole path and set large MTUs for each link, increasing the MTU on just your computer does nothing (except maybe improve your LAN speeds).

share|improve this answer
    
You don't answer my question. What I want to do first is get jumbo frames working over the local link to my router, and then see where to go from there. As I said in the question, I already have downstream support for jumbo frames over the DSL line. I want that mostly just because I can and to get to know how linux works. –  JanKanis Sep 19 '12 at 13:10
    
You are confusing two OSI layers. Jumbo frames are used at the link layer (Ethernet). Higher layers encapsulate larger packets in smaller frames if they are forced to. Also, your network card might just not support IPv6 jumbograms, or you router will set the MTU during the autoconfiguration, check for the MTU in rdisc6 eth0. –  Stefan Seidel Sep 19 '12 at 13:32
    
Jumbo frames were not being sent because the higher layers (ipv6 in this case) didn't allow larger packets. The last part in your comment turned out to be what I was looking for. Router Advertisements set the mtu lower. –  JanKanis Sep 19 '12 at 23:45
add comment

I found out how to do it based on Stefan Seidel's comment. Turns out there is another mtu setting that the ip command doesn't show. Setting a higher value in /proc/sys/net/ipv6/conf/eth0/mtu (command sudo sh -c "echo 0 > /proc/sys/net/ipv6/conf/eth0/mtu" did what I wanted. (Not that it helped a lot, the router really dropped larger frames.) This value gets updated/reset regularly through Router Advertisement. RA can be disabled by writing 0 to accept_ra in the same folder under /proc.

share|improve this answer
add comment

What you are seeing are most likely not jumbo frames. Something like 99.9% of the Internet runs on a 1500 byte and lower MTU after all. It is probably just your kernel or network card doing coalescing of packets.

It does this using a feature usually called Generic Recieve Offload (GRO) or Large Receieve Offload (LRO). The way this works is that packets within a single flow gets identified and merged, then fed to the TCP/IP stack. This can save an significant amount of CPU cycles as it reduces the amount of round trips into the stack.

Try this: ethtool -K $INTERFACE gro off

Which turns off this feature and makes wireshark happier (though not your CPU)

You could still use higher MTU's locally, but it doesnt buy you very much anymore precisely due to features like this and of course ever faster hardware. Also it can be a management nightmare. There are lots of buggy drivers and hardware, and varying degree of support setting MTU through DHCP or RA in operating systems. As you want all devices in a given broadcast domain to be running the same MTU this often makes jumbo frames impractical.

share|improve this answer
1  
Yes, this is correct. I already discovered this, but I forgot to update the question. –  JanKanis Oct 4 '12 at 9:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.