netdev - Re: [PATCH net-next] bridge: Allow max MTU when multiple VLANs present

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJieiUg5PtpZKT6cwNiAgbE8BJGB5DqW4TcOoZcXD-x1TtUHJw@mail.gmail.com>
Date:   Mon, 2 Apr 2018 23:13:54 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     Chas Williams <3chas3@...il.com>
Cc:     Toshiaki Makita <makita.toshiaki@....ntt.co.jp>,
        David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Subject: Re: [PATCH net-next] bridge: Allow max MTU when multiple VLANs present

On Mon, Apr 2, 2018 at 8:26 AM, Chas Williams <3chas3@...il.com> wrote:
> On Mon, Apr 2, 2018 at 11:08 AM, Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
>>

[snip]

>> they are popular...in-fact they are the default bridge mode on our
>> network switches.
>> And they have been around for some time now to ignore its users.
>> Plus it is not right to change default mtu behavior for one mode of the bridge
>> and not the others (bridge mtu handling from user-space is complex enough today
>> due to dynamic mtu changes on port enslave/deslave).
>
> I don't see the issue with one mode of bridge behaving differently
> from another mode.
> The VLAN behavior between the two bridge modes is completely different so having
> a different MTU behavior doesn't seem that surprising.
>
> You are potentially mixing different sized VLAN on a same bridge.  The only sane
> choice is to pick the largest MTU for the bridge.  This lets you have
> whatever MTU
> is appropriate on the child VLAN interfaces of the bridge.  If you
> attempt to forward
> from a port with a larger MTU to a smaller MTU, you get the expected behavior.


you mean larger MTU on the vlan device on the bridge to a smaller MTU
on the bridge port ?.
this will result in dropping the packet. how is this supposed to be
expected default behavior ?.


>
> Forcing the end user to configure all the ports to the maximum MTU of
> all the VLANs
> on the bridge is wrong IMHO.
> You then risk attempting to forward
> oversize packets
> on a network that can't support that.

I am a bit confused: Are you trying to solve the config problem by
implicitly making it the default and there by creating the oversize
packet drop issue by default ?


>
>>
>>>
>>> I don't think those drops are unexpected.  If a user has misconfigured
>>> the bridge
>>> we can't be expected to fix that for them.  It is the user's
>>> responsbility to ensure
>>> that the ports on the VLAN have a size consistent with the traffic
>>> they expect to
>>> pass.
>>>
>>
>> By default they are not expected today. The problem is changing the bridge
>> to max mtu changes 'all' the vlan devices on top of the vlan aware bridge to
>> max mtu by default which makes drops at the bridge driver more common if the
>> user had mixed mtu on its ports.
>
> That's not been my experience.  The MTU on the vlan devices is only
> limited by the
> bridges's MTU.  Setting the bridge MTU doesn't change the children
> VLAN devices MTUs.

It does not, but it now allows vlan devices on the bridge to have a
larger MTU if they need to (some or all of them).
This is consistent with vxlan driver as well: picks default mtu to be
lower or equal to the default dst dev mtu and allows user to override
it with a larger MTU.