What is the default MTU on the Linode network?
Linode
Linode Staff
Hi,
I'm running a wireguard vpn server on my linode and am experiencing very inconsistent speeds. Sometimes I can stream 1080p video and have download speeds of about what I would expect on my home internet connection, but other times (sometimes for days on end) I can barely load most web pages.
I appreciate that you guys aren't wireguard support, so I'm not asking help specifically for that configuration, but I have read that a common problem is the mtu being set too high. I've reduced the mtu for both the server and the client to 1300, which has helped a little for loading web pages and streaming video, but it doesn't seem to have significantly helped download speed. I'm still sitting at a max of about 400kb/s which is much lower than what I know I should be getting on this connection.
I'm wondering if you might be able to tell me what the default MTU is on the linode network so that I can match that if it is indeed the problem. If not I'll just keep troubleshooting.
Thanks!
4 Replies
All Linodes have a default MTU of 1500 bytes. The rest of our network is configured to support jumbo frames to the edge of our network, which is then scaled back to 1500 bytes—as that is the standard of the internet.
If adjusting your MTU does not help things, you may want to us our speed test page to make sure you're using the fastest data center for your location.
If you find you're already in the best data center for your location, you can try tracking down any routing problems with the following commands:
While logged into your Linode:
mtr -rwzbc100 <outside.ip.address></outside.ip.address>
While logged into an outside computer:
mtr -rwzbc100 <linode.ip.address>
Note that the above commands can take several minutes to complete. You can find more info on MTR reports in our guide here:</linode.ip.address>
https://www.linode.com/docs/networking/diagnostics/diagnosing-network-issues-with-mtr/
If that output does not show any routing problems, you probably want to use iPerf to do a little more testing of your network throughput.
The size of an MTU depends on what kind of inter-connect hardware the datacenter uses. I'm assuming Linode does not own the datacenter but pays for capacity only.
An Ethernet frame can be 72-1530 octets (plus a 12-octet inter-frame gap)…the MTU is 1500 octets. Most 1Gb Ethernet uses "jumbo frames" which can be up to 9038 octets with an MTU of 9000 octets. See:
https://en.wikipedia.org/wiki/Jumbo_frame
I would assume that machines in the same datacenter are connected with at least 1Gb Ethernet so I would assume jumbo frames…and 9000-octet MTUs.
Note that it is going to be impossible for you to measure server-to-server interconnections without 2 Linodes on two different physical servers…something that neither Linode nor the datacenter they contract with is going to give you control over. You are certainly not going to be able to measure this using a single Linode and a home PC.
-- sw
It's not just linode's network you have to worry about, it's yours and every network in between you and linode.
You can do some testing yourself.
root@hammer:~# ping -s 1472 -M do 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1480 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=464 ms
1480 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=462 ms
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1ms
rtt min/avg/max/mdev = 462.312/463.259/464.206/0.947 ms
-M do means don't fragment, -s 1472 means the echo payload is 1472 bytes, plus 8 bytes for the icmp header and 20 for the ip header is 1500 bytes. you can see in the first line of ping's output 1472(1500)
root@hammer:~# ping -s 1473 -M do 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 18ms
this is trying to send a 1501 byte packet and because the do not fragment bit is set it errors.
I wanted to mention an experience I have had with MTU recently. I ran into an issue whereby some (but not all) of the servers that Let's Encrypt uses (to serve their API) use an MTU of 1300.
That was causing issues for some users who were assuming a higher MTU… as most of the Let's Encrypt servers were reporting higher than 1300.