On Wed, Feb 10, 2016, at 09:52 AM, Sean M. Collins wrote: > Ihar Hrachyshka wrote: > > Also, I added some interface state dump for worlddump, and here is how the > > main node networking setup looks like: > > > > http://logs.openstack.org/59/265759/20/experimental/gate-grenade-dsvm-neutron-multinode/d64a6e6/logs/worlddump-2016-01-30-164508.txt.gz > > > > br-ex: mtu = 1450 > > inside router: qg mtu = 1450, qr = 1450 > > > > So should be fine in this regard. I also set devstack locally enforcing > > network_device_mtu, and it seems to pass packets of 1450 size through. So > > it’s probably something tunneling packets to the subnode that fails for us, > > not local router-to-tap bits. > > Yeah! That's right. So is it the case that we need to do 1500 less the > GRE overhead less the VXLAN overhead? So 1446? Since the traffic gets > enacpsulated in VXLAN then encapsulated in GRE (yo dawg, I heard u like > tunneling).
Looks like you made progress further debugging the problems here and metadata service is the culprit. But I want to point out that we shouldn't be nesting tunnels here (at least not in a way that is exposed to us, the underlying cloud could be doing whatever). br-int is the neutron managed tunnel using vxlan and that is the only layer of tunneling for br-int. br-ex is part of the devstack-gate managed VXLAN tunnel (formerly GRE until new clouds started rejecting GRE packets) on the DVR jobs but not the normal multinode or grenade jobs because the DVR job is the only one with more than one router. All that to say 1450 should be a sufficiently small MTU. Clark __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
