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: <CAJieiUjcUGjab0RMz-+cMgrvPooUopX6PbB0wzzSviyqj1jjKg@mail.gmail.com>
Date:   Mon, 2 Apr 2018 08:08:45 -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 Fri, Mar 30, 2018 at 12:54 PM, Chas Williams <3chas3@...il.com> wrote:
> On Thu, Mar 29, 2018 at 9:02 PM, Toshiaki Makita
> <makita.toshiaki@....ntt.co.jp> wrote:
>> On 2018/03/30 1:49, Roopa Prabhu wrote:
>>> On Thu, Mar 22, 2018 at 9:53 PM, Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
>>>> On Thu, Mar 22, 2018 at 8:34 AM, Chas Williams <3chas3@...il.com> wrote:
>>>>> If the bridge is allowing multiple VLANs, some VLANs may have
>>>>> different MTUs.  Instead of choosing the minimum MTU for the
>>>>> bridge interface, choose the maximum MTU of the bridge members.
>>>>> With this the user only needs to set a larger MTU on the member
>>>>> ports that are participating in the large MTU VLANS.
>>>>>
>>>>> Signed-off-by: Chas Williams <3chas3@...il.com>
>>>>> ---
>>>>
>>>> Acked-by: Roopa Prabhu <roopa@...ulusnetworks.com>
>>>>
>>>> This or an equivalent fix is necessary: as stated above, today the
>>>> bridge mtu capped at min port mtu limits all
>>>> vlan devices on top of the vlan filtering bridge to min port mtu.
>>>
>>>
>>> On further thought, since this patch changes default behavior, it may
>>> upset people. ie with this patch, a vlan device
>>> on the bridge by default will now use the  bridge max mtu and that
>>> could cause unexpected drops in the bridge driver
>>> if the xmit port had a lower mtu. This may surprise users.
>
> It only changes the default behavior when you are using VLAN aware bridges.
> The behavior remains the same otherwise.  I don't know if VLAN aware bridges
> are that popular yet so there probably isn't any particular
> expectation from those
> bridges.

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 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.