openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #21814
Re: [QUANTUM] (Bug ?) L3 routing not correctly fragmenting packets ?
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
References