GNS3 Cloud to Interface is reassembling fragmented packets, violating MTU

[JDougherty]

I was directed to post here from https://www.gns3.com/community/support/gns3-cloud-to-interface-is-reassembling-fragmented-packets-breaking-mtu

Describe the bug

I am seeing strange behavior where GNS3/GNS3VM is reassembling packets that had been fragmented to not exceed MTU, and these packets are being discarded by my virtual router inside GNS3. I am linking the interface on the virtual router to a GNS3 Cloud, which is itself linked to an ethernet interface on the host VM. This host VM interface is in an ESXi port group on a virtual switch, which has one physical port uplink to the rest of my network.

If I packet capture inbound packets on my ESXi host, or the southbound side of my ESXi vSwitch, none exceed the 1500 bytes (1518 bytes at layer 2) MTU. However, when I packet capture via GNS3, I am seeing packets much larger than 1500 bytes. These packets are then discarded by the virtual router as "giants" which do not conform to the MTU. This leads to tremendously poor performance, as a majority of packets are discarded between the end host (behind the virtual router) and the Internet (northbound of the virtual router, through Cloud-to-interface, through vSwitch, out physical ESXi host NIC).

GNS3 Version: GNS3 v2.2.32 Operating System: GNS3VM on ESXi

To Reproduce

1. Deploy the GNS3VM
2. Create a project with a virtual router (IOU) and two GNS3 Clouds to VM's Ethernet interfaces in different portgroups/vSwitches
3. Run traffic through GNS3 and the virtual router
4. Observe packets exceeding 1500 byte MTU

Screenshots or videos

Additional context I believe I've narrowed this down to a GNS3 issue, as none of the other devices in my network experience this behavior -- it is only traffic passing through the GNS3 Cloud<->Ethernet interface which are being reassembled, as far as I can tell.

To the best of my ability, I have verified that every interface in the path has a configured MTU of 1500.

[cristian-ciobanu]

I think this is the same or similar issue to https://github.com/GNS3/gns3-gui/issues/1867 where uBridge is crashing or has very low performance due to MTU size exceeding 1500 bytes

[spikefishjohn]

a few questions and thoughts, it sounds like nothing in the path should be increasing the MTU above 1518 correct?

Are you using a trunk across the cloud? I don't think that would matter just asking as I think that is the only reason for the 18 bytes over 1500.

It would be helpful to see a packet capture to confirm the size issue.

A few options to throw out there for quick (ehem maybe?) relief.

1. I've seen bad performance from cloud object connected to a physical interface. The work around is to create linux bridge interface then bridge the physical interface to the bridge interface then connect the cloud to the bridge interface. I don't understand why this fixes anything but it sure makes a huge difference on my systems. I understand your running in ESX and technically the interface is a virtual interface going to a virtual switch in ESX but i think its worth a try.
2. If for sure there is a path generating packets bigger then 1518 AND the packets in question are TCP you could maybe use iptables on the interface coming into the cloud object to adjust the MSS value down to 1420 (or whatever the default is assuming MTU of 1500). I haven't tried this without using iptables as a firewall but it should prevent tcp packets larger then MTU as long as your adjusting MSS in both directions. EDIT: You might have to do this with nftables since its not a routed interface connected to the cloud object.

[cristian-ciobanu]

@JDougherty mentioned 1518 bytes for the layer 2 MTU which is normal since the additional 18 bytes come from the Ethernet header which is in fact the frame size. The default layer 3 MTU for a packet is 1500 bytes.