Open Stack

On 20-01-2015 11:37, Miguel Ángel Ajo wrote:
> Hi Eren,

Hello Miguel,

>     I had a couple of days debugging MTU + Juno, with openstack RDO, while I
> didn’t see the bridge packet reconstruction problem (I didn’t need to  
> disable bridge-nf-call-iptable) I saw all the other problems. That’s why I
> believe this spec [1] is important to this cycle.
> 
>     I managed to fix this by:
> 
> 1) Lowering the VMs MTU:
> [root at stack ~]# cat /etc/neutron/dnsmasq-neutron.conf
> dhcp-option-force=26,1450
> [root at stack ~]# grep dnsmasq-neutron /etc/neutron/dhcp_agent.ini
> dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf

This is the configuration file I use as well. I'm sure that correct MTU
value for VMs is set with DHCP.

> 
> 2) Lowering the internal leg (ONLY)  
> 
> Either manually:
> 
> ip netns exec qrouter-8f2f7e69-02c3-4b75-9b25-e23b64757935 ip link set dev qr-3414bb7e-f3 mtu 1450
> 
> or see [2] for a manual monkey patch I’m using on a personal openstack deployment
> I use for development.

Thank you for the patch. Although it will lower the MTU on the internal
leg automatically and fix the ICMP issue, I guess retransmission issue
with TCP connections will still persist.


> With this, you get traffic to be fragmented when going from the external
> network to the internal network, by the qrouter, making it’s way to
> the tenant network via GRE (it was VXLAN in my case).
> 
> 2.a) If you change both legs (internal + external) -and I understood that from your
> email- you will get a MTU mismatch in your external network (unless it’s 1450 too),
> and as soon as you try to receive any big packet, it will be discarded by receiver
> with lower MTU.

No, I did not change both legs, only the internal one (qr-xxxx). The
gateway leg has MTU of 1500 by default. To clear a possible
misunderstanding, I only lowered internal qr-xxx leg MTU to be matched
with VM, and I also needed to disable iptables on bridge (compute host)
so that fragmented packets in tap interface are not reconstructed in the
interfaces above (qbr).

> NOTES:
> 
>    just guessing, but: the unexpected packet reconstruction could be due?
> 
> a) Any difference from the GRE to VXLAN implementation?, can you try VXLAN?

Yes, I can try. I am currently installing Juno on different set of
physical hosts to try VXLAN setup. It will probably take 1-2 days. I
will let you know.

> a) A non backported bug in the ubuntu kernel?

Maybe. The reconstruction problem in bridges appears to have roots in
the kernel but I don't think I can debug it. My path will be installing
the same configuration (step-by-step Juno documentation) with the same
host OS (Ubuntu Server 14.04) but with VXLAN configuration. I will see
whether bridge problem persists.

If it is a bug in ubuntu kernel, I should be able to reproduce it on
this different setup. In this case, I believe the official documentation
will need to be updated, or I need to file a bugreport to Ubuntu, or
change the host OS.


> Miguel Ángel Ajo

- Eren

-- 
System Administrator
https://skyatlas.com/