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@stack ~]# cat /etc/neutron/dnsmasq-neutron.conf > dhcp-option-force=26,1450 > [root@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/ _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack