Home / server / Questions

Questions[mtu](server)

Martin Hope
bot47
Asked: 2014-05-20 15:01:56 +0800 CST
  • 10

I found various lists of MTUs for different links, but they never contain UMTS, LTE, EDGE, HSPA, GPRS.

What are the MTUs of the above mentioned technologies?

mtu
Martin Hope
morgant
Asked: 2012-06-26 09:45:53 +0800 CST
  • 14

Okay, I just finished resolving a jumbo frames issue between a few Xserves, a Netgear GSM7224, and a Drobo B800i. It turned out that the Xserves (Mac OS X 10.6.8 Server) and the Drobo B800i accept the MTU in bytes as normally expected (1500-9000), but the Netgear seems to have wanted it including the various ethernet headers/footers(trailers) and I ultimately ended up with the Xserves & Drobo configured with an MTU of 9000 and the Netgear ports set to an MTU of 9216.

I've used the following commands for testing & verifying the MTU between the two Xserves over the Netgear (Note: these are the Mac OS X commands, the Windows & Linux ones differ):

ping -D -s <mtu> <ip_address>

traceroute -F <ip_address> <mtu>

The former's usage is noted in the man page as, "Specify the number of data bytes to be sent. The default is 56, which translates into 64 ICMP data bytes when combined with the 8 bytes of ICMP header data." In testing, I found that to ping -D 1472 <ip_address> was the equivalent of MTU 1500 due to the 8 bytes of ICMP header data plus 20 bytes IP headers (see this and this). That all makes sense.

Now, why is the equivalent command for a 9000 MTU ping -D -s 8164 <ip_address>? I've verified this is the limit before I star getting "sendto: Message too long" errors, but also that 9000 MTU is working correctly as traceroute -F <ip_address> 9000 works and traceroute -F <ip_address> 9001 does not. So, why 8164? I would've expected 8972 (MTU - 28 bytes, just like for 1500 MTU).

Also, why 9216 MTU for the Netgear? I counted 42 bytes for the MAC & ethernet headers (inc. CRC), plus 20 for IP headers (which should eat into the MTU).

I'm really rusty on this math and know I'm just missing something.

tcp ethernet gigabit-ethernet tcpip mtu
Martin Hope
nikku
Asked: 2011-03-12 21:27:03 +0800 CST
  • 19

I am using a fast ethernet of 100 Mbps, whose frame size is less than 1500 bytes (1472 bytes for payload as per my textbook). In that, I was able to send and receive a UDP packet of message size 65507 bytes, which means the packet size was 65507 + 20 (IP Header) + 8 (UDP Header) = 65535.

If the frame's payload size itself is maximum of 1472 bytes (as per my textbook), how can the packet size of IP be greater than that which here is 65535?

I used sender code as

char buffer[100000];
for (int i = 1; i < 100000; i++)
{
    int len = send (socket_id, buffer, i);
    printf("%d\n", len);
}

Receiver code as

while (len = recv (socket_id, buffer, 100000))
{
     printf("%d\n". len);
}

I observed that send returns -1 on i > 65507 and recv prints or receives a packet of maximum of length 65507.

udp tcpip network-protocols mtu
Martin Hope
Stu Thompson
Asked: 2010-03-03 00:38:01 +0800 CST
  • 15

I've got an application that would benefit from larger Ethernet frames. (In theory, we could reduce the number of outbound packets by > 50%, maybe even 66%.)

I'm also in the process of specifying networking requirements with candidate hosting companies for a new installation of my application servers. It would be nice to, at a minimum, not restrict client connections from benefiting from Jumbo Frames.

But how realistic is this? Some general questions, assuming the segment of the network we can control is Jumbo Frame-friendly (switches are large MTUs capable, ICMP MTU path discovery allowed, etc.):

  • Is it realistic to send Jumbo Frames over the public Internet?
  • Is it inviting endless networking problems trying to support Jumbo Frames over the public Internet?
  • Are there any other concerns that I've not considered?
jumboframes networking mtu
Martin Hope
Xaisoft
Asked: 2009-10-01 10:23:03 +0800 CST
  • 16

I had this issue where I was only able to connect to websites like google.com and ibm.com when the mtu was set at 1500, but if I tried to connect to anything else, it would just show a blank page. When the mtu was lowered to 1499, it started working. I am curious as to why this works and if having the mtu set at 1499 could cause problems in the future? I actually don't know much about this, I just heard about it and am looking for a good explanation.

When I get an explanation of why the MTU was dropped by only 1 byte, I will update my question with the explanation.

mtu