Re: [openstack-dev] [neutron][ovs] The way we deal with MTU

2016-07-08 Thread Mooney, Sean K
From: Armando M. [mailto:arma...@gmail.com] Sent: Tuesday, June 14, 2016 12:50 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron][ovs] The way we deal with MTU On 13 June 2016 at 22:22, Terry

Re: [openstack-dev] [neutron][ovs] The way we deal with MTU

2016-06-20 Thread Ihar Hrachyshka
> On 15 Jun 2016, at 17:27, Ihar Hrachyshka wrote: > > First, some context: we talked it thru with Eugene on IRC, and Eugene > reported that he cannot reproduce the issue on his setup using Ubuntu > hypervisor with ovs 2.4: > >

Re: [openstack-dev] [neutron][ovs] The way we deal with MTU

2016-06-15 Thread Ihar Hrachyshka
First, some context: we talked it thru with Eugene on IRC, and Eugene reported that he cannot reproduce the issue on his setup using Ubuntu hypervisor with ovs 2.4: http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-06-13.log.html#t2016-06-13T19:45:22 So I

Re: [openstack-dev] [neutron][ovs] The way we deal with MTU

2016-06-14 Thread Armando M.
On 13 June 2016 at 22:22, Terry Wilson wrote: > > So basically, as long as we try to plug ports with different MTUs into > the same bridge, we are utilizing a bug in Open vSwitch, that may break us > any time. > > > > I guess our alternatives are: > > - either redesign bridge

Re: [openstack-dev] [neutron][ovs] The way we deal with MTU

2016-06-13 Thread Terry Wilson
> So basically, as long as we try to plug ports with different MTUs into the > same bridge, we are utilizing a bug in Open vSwitch, that may break us any > time. > > I guess our alternatives are: > - either redesign bridge setup for openvswitch to e.g. maintain a bridge per > network; > - or

Re: [openstack-dev] [neutron][ovs] The way we deal with MTU

2016-06-13 Thread Eugene Nikanorov
That's interesting. In our deployments we do something like br-ex (linux bridge, mtu 9000) - OVSIntPort (mtu 65000) - br-floating (ovs bridge, mtu 1500) - br-int (ovs bridge, mtu 1500). qgs then are getting created in br-int, traffic goes all the way and that altogether allows jumbo frames over

Re: [openstack-dev] [neutron][ovs] The way we deal with MTU

2016-06-13 Thread Peters, Rawlin
Hi Ihar, This reminds me of a mailing list thread from a while back about moving OVS ports between namespaces being considered harmful [1]. Do you know if that was ever resolved by the OVS folks? Or, is this MTU bug just further indication of this action being harmful? Another comment inline.

[openstack-dev] [neutron][ovs] The way we deal with MTU

2016-06-13 Thread Ihar Hrachyshka
Hi all, in Mitaka, we introduced a bunch of changes to the way we handle MTU in Neutron/Nova, making sure that the whole instance data path, starting from instance internal interface, thru hybrid bridge, into the br-int; as well as router data path (qr) have proper MTU value set on all