Pushing JUMBO Framers using VxLAN over a 1500 MTU Underlay Network

[Oleksandr Y.]

Hi all, I just wanted to ask if anyone has seen (or maybe heard or wondered) if VxLAN running on an underlay network with a maximum MTU Size of 1500 bytes, might be able to transmit JUMBO frames. In other words, is there an option in VxLAN that anyone might have heard of, that if a JUMBO Ethernet Frame enters a VTEP, VxLAN would try to chop the frame down into sizes that can be transmitted over the underlay.

I know it defeats the purpose of JUMBO frames altogether, but I am just researching a couple of things ... I am sure theoretically (even if this is not supported) it could be done ... but I am wondering if there is something in VxLAN that can support this particular scenario out of the box.

Cheers, and thank you in advance for the brainstorming

[Flavio Miranda]

Hello,

https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-sda-design-guide.html 

Increase default MTU—The VXLAN header adds 50 bytes of encapsulation overhead. Enabling a campus and branch wide MTU of 9100 ensures that Ethernet jumbo frames can be transported without fragmentation inside the fabric.

[Oleksandr Y.]

Hi Flavio thank you, I know that in traditional network design this is the optimal way to go, unfortunately I am working on a network (to be more specific a satellite network/DVB-RCS) which has Modulators and Demodulators that UNFORTUNATELY do not allow IP packets larger than 1500 bytes (historical design limitation of this equipment) so I am wondering if VxLAN would be able to fragment larger frames into VxLAN packets that are small enough to transition this 1500 byte size limited network and reassembled at he remote VTEP.

PS: I was not very clear about my limitation in the original post, sorry and thank you  

[Oleksandr Y. · Accepted solution]

Hello Community, so after doing a little bit more testing and research I just realized the answer was much simpler and it's a resounding NO - VxLAN as a protocol does not seem to have any fragment ID's in it's overhead fields - there is 1 byte that is reserved (possibly unused at the moment) but I could definitely use it as a fragment ID in a custom implementation ... but we are using CISCO and other Vendor equipment as VTEP's so this is not an out of the box functionality seems like.

I've calculated the overhead impact in using such an approach, which is a bout 2.4% more Overhead compared to native JUMBO Support, which is not that bad, but since I am working in the satellite industry where each byte counts the 2.4% overhead is a loss of 2.4Mbps on a 100Mbps link.

Anyhow, thank you for the responses and I hope that this post will be of use to someone in the future that might be doing R&D and facing similar question marks