On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu) <[email protected]> wrote: > So I was forced to explicitly set the MTU on br-int > ovs-vsctl set int br-int mtu_request=9000 > > > Without this the tap device added to br-int would get MTU 1500 > > Would this be something the ovs l2 agent can handle since it creates the > bridge?
Yes, I guess we could do that if it fixes your problem. The issue stems from the fact that we use a single bridge for different networks with different MTUs, and it does break some assumptions kernel folks make about a switch (that all attached ports steer traffic in the same l2 domain, which is not the case because of flows we set). You may want to report a bug against Neutron and we can then see how to handle that. I will probably not be as simple as setting the value to 9000 because different networks have different MTUs, and plugging those mixed ports in the same bridge may trigger MTU updates on unrelated tap devices. We will need to test how kernel behaves then. Also, you may be interested in reviewing an old openvswitch-dev@ thread that I once started here: https://mail.openvswitch.org/pipermail/ovs-dev/2016-June/316733.html Sadly, I never followed up with a test scenario that wouldn't involve OpenStack, for OVS folks to follow up on, so it never moved anywhere. Cheers, Ihar __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
