openstack team mailing list archive
Mailing list archive
Re: [QUANTUM] (Bug ?) L3 routing not correctly fragmenting packets ?
On 03/11/2013 06:09 AM, Sylvain Bauza wrote:
Okay. I think I got the reason why it's not working with OVS/GRE
contrary to FlatDHCP nova-network.
So, as per
GRE encapsulation protocol can add up to 34 bytes to the IP datagram
(meaning the TCP segment is only 1456 bytes if MTU set to 1500).
When the packet is about 1500 bytes, then it should fragment to keep the
1500-byte size of the reply (including GRE encap then).
That sounds like the reason.
Unfortunaly, due to security purpose, the ICMP packet "type 3/code 4"
(frag. needed) can't be reached to the X.X.X.X backend as this backend
is denying any ICMP request (firewall).
As a consequence, PathMTU is failing and packets still retransmited with
1500-byte size again and again...
As said on my first post, the only workaround I found is to modify *all*
my VMs with MTU set to 1454 (don't know why there is a 2-bytes overhead
compared to the 1456-byte I told above), including my Windows VMs which
is not a cool stuff (modifying a registry key and reboot the VM. Yes,
you aren't dreaming. This is the way for Windows-based machines to
Do you know if any cool idea would prevent to modify VMs, and only do
things on the network node ?
Yes. Let the ICMP Destination Unreachable, Datagram Too Big messages
through. So the network can function the way it was intended.
Otherwise you have no recourse but alter the MTU in the VMs. Or add the
insult of tweaking the code to ignore the DF bit to the injury of
blocking the ICMP messages. (Assuming that is even possible)
If you are Very Lucky (tm) all your network infrastructure in the
broadcast domain (everything on the same side of a router - device
forwarding based on Layer3 (eg IP) addressing or put another way,
everything reachable via just switches - in the proper sense of the term
wherein a switch is a device making forwarding decisions based on
layer2, eg Ethernet addresses) then you can try to increase the MTU of
your physical interfaces so the GRE encapsulation overhead can be
"hidden" from the VMs. But *everything* in the broadcast domain must
have the same maximum frame size (MTU) or life becomes even more
My suggestion is let the ICMP Destination Unreachable, Datagram Too Big
messages through. It is perhaps my failing, but I fail to see how
blocking them improves "security."
adde parvum parvo magnus acervus erit - Ovid quoted in The Mythical Man