Open Stack

It could be that too TBH I'm not sure :)

On Fri, Sep 22, 2017 at 11:02 AM, Sławomir Kapłoński <slawek at 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 <majopela at 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.ubuntu at 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 <ihrachys at redhat.com>
> wrote:
> > On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
> > <akalambu at 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-request at 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-request at 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-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> —
> Best regards
> Slawek Kaplonski
> slawek at kaplonski.pl
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170922/d647a087/attachment.html>