← Back to team overview

openstack team 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
modify MTUs...)

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 "interesting."

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."

rick jones
adde parvum parvo magnus acervus erit - Ovid quoted in The Mythical Man Month