GRE tunnel bridging and MTU mismatch

Hi guys.

The past 2 weeks was a lot of fun (and headache) to me after I learned a lot about wireless operation modes and how to encapsulate 802.1q frames inside 802.11 packets using GRE tunnel. Putting a 1522 byte packet inside a packet which allows 2304 bytes of payload is straightforward. So far so good.

The problem arises when I try to do the same over a wired interface with 1500 byte MTU. The GRE itself takes 4 bytes, and the outer IPv4 header takes 20 bytes, or 40 bytes in case of IPv6, the MTU of the GRE should be reduced to 1476 and 1456 respectively. On both sides of the tunnel, I bridge the GRE interface to a physical network, to merge the 2 Layer-2 networks on both ends of the tunnel together.

Here comes the issue: all devices and interfaces on the 2 Layer-2 networks use default MTU of 1500 bytes. From the technical perspective, all Ethernet frames with payload exceeding the MTU won't go through the tunnel -- they will be dropped instead. From the end-user perspective, the problem is obvious and takes effect immediately as network services on the other side of the tunnel are reported as online but are not responding to requests.

Note that there is no Layer-3 involved, so no MSS clamping nor Path MTU Discovery here. Manually reducing the MTU of all hosts on the 2 networks is not an option. Is there any elegant solution for this?

P.S: I thought of setting the GRE tunnel MTU to 1500 bytes regardless of the physical interface MTU. Traffic over the physical interface is routed at Layer-3 (not switched at Layer-2), meaning it can be fragmented, but I do not know if it will work and at what kind of performance. I am also not sure about what will happen if the outer IPv4 packet header exceeds the default 20 bytes, or the outer IPv6 header exceeds the default 40 bytes.

Clients on a LAN can get MTU information with DHCP and with DHCPv6. Do You know that? Did you have tried it?

Before clients can get MTU information from DHCP server, the DHCP server itself needs to have that information first. How can it do that in the following simple diagram? Note that Switch 1 can have ~24 ports with different MTU values on each link. How can the DHCP get all MTU information from all possible path combinations on the L2 network?

DHCP server <--- MTU 1500 ---> Switch 1 <--- MTU 1456 ---> Host 1

The DHCP server is merely a host in the same L2 network. If it can detect the MTU of all links, then any host can, too. What is the purpose of getting such information from the DHCP?

Yeah in an ideal world path MTU discovery should be working but for some reason this seams not to be the case here. If you set the MTU option on DHCP and on RA (I have written DHCPv6 before the first cup of coffee, sorry) then you can enforce the MTU used by the client.