Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

migrated from Mar 12 '11 at 5:44

This question came from our site for professional and enthusiast programmers.

The IP layer will fragment your packet on the sending end, and then reassemble it back on the receiving end, before passing it up to UDP. From the UDP layer, you can't really tell that the packet has been fragmented. If you use a packet capture tool like Wireshark, you should be able to see that your computer is receiving IP packets limited to the MTU.

share|improve this answer

UDP datagrams have little to do with the MTU size you can make them as big as you like up to the 64K is maximum mentioned above. You can even send one of them in an entire packet as long as you are using jumbo frames with a size larger the large datagram.

However jumbo frames have to be supported by all the equipment the frame will pass over and this a problem. For practical purposes Ethernet frames are the most common tranport size, the MTU for these is circa 1500 bytes, I will say 1500 going forward, but it isn't always. When you create a UDP datagram larger than the underlying MTU (which as indicated is most often be ethernet) then it will be quietly be broken up into a number of 1500 byte frames. If you tcpdump this traffic you will see a number of packets broken at MTU boundary which will have the more fragments flag set along with a fragment number. The first packet will have a fragment number of 0 and the more fragments set and the last one will have a non-zero fragment number and more fragments not set.

So why care? The implementation detail actually matters. Fragmentation can hurt performance in the network not a big issue anymore but one to be aware of. If a huge datagram size it used then should any fragment be lost the whole datagrams will need to be resent. Equally at high volumes and today these are perfectly achievable volumes then mis-association of frames at reassembly is possible. There can also be problems getting fragmented UDP packets to traverse enterprise firewall configurations where load balancers spread the packets out, if one fragment is on one firewall and the other on a different one then the traffic will get dropped as incomplete.

So don't create UDP datagrams bigger than the MTU size fragmentation unless you have to and if you have to specify that the infrastructure being communicated between is close (same subnet close) at which point jumbo frames would likely be a good option.

share|improve this answer
Good information about the 'more fragments flag'. Is that a flag in the UDP header or in the IP header? – John Jesus Nov 3 '15 at 21:44

Turns out that allowing the TCP/IP stack to fragment packets as needed is a lot lower overhead than sending individual packets.

share|improve this answer
Do you mean that TCP/IP is fragmenting and reassembling itself ? If yes, then why do people say all the time that your code should take care of reassembly at the receiver end. I did not observed fragmentation as of now, but had seen many forums which are saying this and even people accepting it. – nikku Mar 12 '11 at 5:36
For those of us that are OSI model challenged, could you add a bit more detail to your answer please? – Robert Harvey Mar 12 '11 at 5:41
I was being a bit cagey because I can't tell if this is homework or not. It's a tradeoff: since UDP makes no delivery guarantees, if any packet fragment is dropped the whole packet is lost. If you want a reliable transport atop UDP, you need to handle all of this yourself; but if you're doing (say) streaming protocols (or NFS over UDP, which took the streaming-like path) it's lower overhead to either simply drop those packets or retransmit the larger packet after a longish delay if needed. You need to balance your needs against protocol features and protocol overhead. – geekosaur Mar 12 '11 at 5:49

To answer your question, "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?"

It is due to an offloading feature called UFO.(UDP Fragmentation Offload). Please refer to this link.

You can verify and toggle offloading features via ethtool -k ethX and ethtool -K ethX respectively.

share|improve this answer

If you're monitoring outgoing frames, it's possible that your network adaptor supports segmentation offloading, and it is enabled. With segmentation offloading enabled, the network card itself handles segmenting the packet/frame into the appropriate size, rather than the network stack. This frees the CPU in the computer to perform other tasks, improving performance. On linux, "ethtool -k [device]" will show the offload flags.

share|improve this answer

Your Answer


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