[openstack-dev] [neutron] MTU native ovs firewall driver
Miguel Angel Ajo Pelayo
majopela at redhat.com
Fri Sep 22 08:32:00 UTC 2017
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.
> On 20 September 2017 at 09:58, Ihar Hrachyshka <ihrachys at redhat.com>
>> 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:
>> 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.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev