Open Stack

Le 12/03/2013 13:12, Robert van Leeuwen a écrit :
>> I thought about it, but yet not tried. Which OVS port would you
>> recommend to increase MTU ?
>> On the network node (br-ex or qg-XXXX) , or on the compute node (br-int) ?
> You need to set it on the compute nodes ( int-br-ethX ) and possibly the an extra port on the routing node.
> (we use a bridge-mapped network to connect to the "outside" world and phy-br-eth1 needs to be set)
>
> Cheers,
> Robert
>


I got it : my issue was isolated on the backend > GRE tunnel TCP response.
I then only increased MTU up to 1546 to the physical ethernet device 
(here, eth0) to allow the 46-byte encap to be not fragmented.

Here is the TCPdump stack trace, we can see the GRE headers overhead :

15:01:34.322883 IP (tos 0x0, ttl 64, id 36074, offset 0, flags [DF], 
proto GRE (
47), length 1546)
     172.16.0.2 > 172.16.0.4: GREv0, Flags [key present], key=0x1, 
length 1526
         IP (tos 0x0, ttl 48, id 26871, offset 0, flags [DF], proto TCP 
(6), length 1500)
     X.X.X.X.80 > 10.0.0.4.41507: Flags [P.], cksum 0x6a90 (correct), 
seq 1420:2880, ack 412, win 3456, length 1460


Here, 172.16.0.2 is the Quantum network node and 172.16.0.4 is the 
compute node (internal IPs).
As the packet was fragmented due to GRE encap, I only changed eth0 on 
the network node to get things done :
ip link set eth0 mtu 1546

Now it works.
I assume it's not 100% perfect, being an ugly hack, but that allows to 
bypass GRE headers overhead in case of PathMTU failing.

Thanks all for your help,
-Sylvain