settingsLogin | Registersettings

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

0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Sep 22, 2017 in openstack-dev by Ajay_Kalambur_(akala (2,680 points)   3 9

6 Responses

0 votes

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)" akalambu@cisco.com 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-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
responded Sep 20, 2017 by Ajay_Kalambur_(akala (2,680 points)   3 9
0 votes

On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
akalambu@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 20, 2017 by Ihar_Hrachyshka (35,300 points)   3 9 10
0 votes

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@redhat.com wrote:

On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
akalambu@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@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
responded Sep 20, 2017 by Ian_Wells (5,300 points)   1 2 3
0 votes

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@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@redhat.com
wrote:

On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
akalambu@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@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-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
responded Sep 22, 2017 by Miguel_Ángel_Ajo (6,980 points)   1 3 6
0 votes

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@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@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@redhat.com wrote:
On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
akalambu@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@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
slawek@kaplonski.pl


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
responded Sep 22, 2017 by Sławek_Kapłoński (5,420 points)   2 10 14
0 votes

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@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@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@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@redhat.com
wrote:
On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
akalambu@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@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
slawek@kaplonski.pl


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
responded Sep 22, 2017 by Miguel_Ángel_Ajo (6,980 points)   1 3 6
...