It could be that too TBH I'm not sure :) On Fri, Sep 22, 2017 at 11:02 AM, Sławomir Kapłoński <sla...@kaplonski.pl> wrote:
> Isn't OVS setting MTU automatically MTU for bridge as lowest value from > ports connected to this bridge? > > > > Wiadomość napisana przez Miguel Angel Ajo Pelayo <majop...@redhat.com> > w dniu 22.09.2017, o godz. 10:32: > > > > I believe that one of the problems is that if you set a certain MTU in > an OVS switch, new connected ports will be automatically assigned to such > MTU the ovs-vswitchd daemon. > > > > > > > > On Wed, Sep 20, 2017 at 10:45 PM, Ian Wells <ijw.ubu...@cack.org.uk> > wrote: > > Since OVS is doing L2 forwarding, you should be fine setting the MTU to > as high as you choose, which would probably be the segment_mtu in the > config, since that's what it defines - the largest MTU that (from the > Neutron API perspective) is usable and (from the OVS perspective) will be > used in the system. A 1500MTU Neutron network will work fine over a > 9000MTU OVS switch. > > > > What won't work is sending a 1500MTU network to a 9000MTU router port. > So if you're doing any L3 (where the packet arrives at an interface, rather > than travels a segment) you need to consider those MTUs in light of the > Neutron network they're attached to. > > -- > > Ian. > > > > On 20 September 2017 at 09:58, Ihar Hrachyshka <ihrac...@redhat.com> > wrote: > > On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu) > > <akala...@cisco.com> 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: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > ____________________________________________________________ > ______________ > > 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 > > > > > > ____________________________________________________________ > ______________ > > 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 > > > > — > Best regards > Slawek Kaplonski > sla...@kaplonski.pl > > > > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
