[neutron] MTU native ovs firewall driver

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[neutron] MTU native ovs firewall driver

Ajay Kalambur (akalambu)
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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [neutron] MTU native ovs firewall driver

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)" <[hidden email]> 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: [hidden email]?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [neutron] MTU native ovs firewall driver

Ihar Hrachyshka
On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
<[hidden email]> 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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [neutron] MTU native ovs firewall driver

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 <[hidden email]> wrote:
On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
<[hidden email]> 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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [neutron] MTU native ovs firewall driver

Miguel Angel Ajo Pelayo-2
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 <[hidden email]> 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 <[hidden email]> wrote:
On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
<[hidden email]> 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@...enstack.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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [neutron] MTU native ovs firewall driver

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
> <[hidden email]> 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: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




Best regards
Slawek Kaplonski
[hidden email]




__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [neutron] MTU native ovs firewall driver

Miguel Angel Ajo Pelayo-2
It could be that too TBH I'm not sure :)

On Fri, Sep 22, 2017 at 11:02 AM, Sławomir Kapłoński <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
> <[hidden email]> 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@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@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@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




Best regards
Slawek Kaplonski
[hidden email]




__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev