Net searches are not revealing the answer to the following question... is
the GRE tunelling spec published?
Question: What happens when a GRE tunnelled packet requires fragmentation
along the way?
The default MTU for tunnel interfaces (and indeed for most interfaces) is
1500, but if the tunnelled packets go out on, say, Ethernet, then the
MTU would more correctly be 1500-(size of GRE and IP header).
So when the tunnel finds that it needs to fragment packets along the way,
I see two options at its disposal:
(1) Behave as though the MTU of the tunnel interface was indeed lower
than it is configured and fragment the packet before it enters the
tunnel. Send back an error if the don't fragment bit is set (normal
fragmentation processing).
Advantages: Allows the sending host to perform path MTU discovery as normal.
Disadvantages:
- effective MTU may be lower than the interface's configured MTU, making
the configured value untrustworthy
- some passenger protocols may not support fragmentation or have higher
minimum MTU values than IP.
- Exposes the properties of the links used by the tunnel, which you
might be trying to "hide" by using a tunnel
To implement this: set IP_DF in the transport IP header
(2) Honor the tunnel interface's configured MTU value and fragment the
transport packets while leaving the passenger packets intact (the other
tunnel endpoing reassembles)
Advantages: Best transparency
Disadvantages: Path MTU discovery cannot work and every large packet
destined to the tunnel might be transmitted as two packets, nearly
doubling the load and adding ~40 bytes overhead.
To implement this: do not set IP_DF in the transport IP header
In light of the answer to thie question (I suspect it is (2)), should I
use a lower MTU on tunnel interfaces to prevent fragmentation, if the
minimum MTU of the tunnel transport links is known? And if so, what is
the exact size of the GRE/IP header to subtract from this minimum?
-Phil
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:14 EDT