I've a few pcaps that contain packets larger than standard ethernet MTU size of 1500B. I searched about this and found refs pointing towards Jumbo Frames. I now understand that since I'm on a GBE network that supports sending Jumbo frames (upto 9k), the TCP/IP stack on my Debian derivative will auto tweak itself and use such huge frame sizes (PMTU Discovery). This is really awesome!

However, I want to have some control over auto-enabling of this feature. Specifically, I want to make sure that when I capture a pcap, it is temporarily disabled and as such all captured packets are under 1500B. I need to ensure this because a tcpreplay based pcap replay framework I've fails when it sees Jumbo frames. Tcpreplay has an enhancement request, Support fragment IP packets > MTU to enable sending Jumbo frames. But it is a low priority ticket and could possibly take time to get resolved.

I read about ways to manually tweak the PMTU discovery behavior and found that "ip_no_pmtu_disc" sysctl variable under the /proc filesystem could be handy. I enabled it on both my client and server systems (although I assume enabling it on any one of them would have been sufficient) and captured a few pcaps. But they still have packets larger than 1500B. The default MTU on my network interfaces is already set to 1500B and since PMTU discovery is disabled, I assumed things would work fine. But, there is something I'm missing. I would appreciate any refs/pointers.

NOTE: I didn't restart systems as the /proc tweaks I made won't persist. I also am not in position to restart systems everytime I need to replay pcaps.


What you're seeing is no indication for jumbo frames. Probably your NIC is segmenting the data into smaller packets after you've sniffed it. Are you perhaps testing on a VM? Linux will not use a bigger MTU for outgoing packets than the one that is configured on the interface. If you have an MTU of 1500 then that is the maximum.

  • Yes, I'm testing this on a VM network beacuse I use it for most of my work. Will there be any difference if physical Linux instances are used instead? I did not understand the NIC segmenting part. And also why do you think Linux won't change the MTU value configured on an interface? How would PMTU Discovery be of any help if that's the case? – 7h3rAm May 2 '13 at 17:14
  • I didn't write that it would not change the MTU, I said that it will not use a bigger MTU. Linux will only lower the MTU if it detects a lower MTU on a link somewhere on the path. It will never go over the maximum MTU. Regarding the VM: Yes there is a difference. The client doesn't handle the packet segmentation etc., instead it hands it off to the VM host. It's completely normal to see very big packets on a VM. You would be better off sniffing on the host or even better on the receiving side. – Sebastian Wiesinger May 3 '13 at 6:27
  • I did a few more tests and as you correctly pointed out, this wasn't due to the PMTU discovery feature. It was because my testbed systems have [sandilands.info/sgordon/… and Checksum Offloading) enabled and since I used Tcpdump to grab pcaps, I missed the segmentation/reassembly part completely. I used ethtool to temporarily disable generic-{segmentation,receive}-offload parameters and as expected captured packets complied with MTU restriction. Thanks for your time and help! – 7h3rAm May 8 '13 at 8:33

sounds like you might have TSO and GSO on. Normally MSS is determined by MTU - headers and its also advertised to both sides of the connection which allows the lowest of the two to be used for the connection buildup however, if you have tso and gso enabled, linux will ignore the mtu/mss and send large chunks of data which will get fragmented.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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