Re: [openstack-dev] [neutron] MTU native ovs firewall driver

2017-09-22 Thread Miguel Angel Ajo Pelayo 
It could be that too TBH I'm not sure :)

On Fri, Sep 22, 2017 at 11:02 AM, Sławomir Kapłoński 
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 
> 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 
> 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 
> wrote:
> > On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
> >  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

Re: [openstack-dev] [neutron] MTU native ovs firewall driver

2017-09-22 Thread Sławomir Kapłoński 
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  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  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  wrote:
> On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
>  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

Re: [openstack-dev] [neutron] MTU native ovs firewall driver

2017-09-22 Thread Miguel Angel Ajo Pelayo 
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  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 
> wrote:
>
>> On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
>>  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:unsubscrib
>> e
>> 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

Re: [openstack-dev] [neutron] MTU native ovs firewall driver

2017-09-20 Thread Ian Wells 
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  wrote:

> On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
>  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

Re: [openstack-dev] [neutron] MTU native ovs firewall driver

2017-09-20 Thread Ihar Hrachyshka 
On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
 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

Re: [openstack-dev] [neutron] MTU native ovs firewall driver

2017-09-20 Thread Ajay Kalambur (akalambu) 
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?

Ajay




On 9/20/17, 7:28 AM, "Ajay Kalambur (akalambu)"  wrote:

>Hi
>i am using large mtu setting of 9000. with the hybrid firewall driver i see 
>large mtu set on both tap devices and the linuxbridges
>While i switch from ovs hybrid firewall driver to native ovs firewall driver i 
>now see the tap device gets the default 1500 mtu
>i have the right setting for mtu in global physnet mtu in neutron.conf and 
>path mtu in ml2 conf
>Do i need to do anything different to get large mtu working with native ovs 
>firewall driver
>Ajay
>
>
>
>__
>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