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] [day] [month] [year] [list]

Message-ID: <CAG2-Gkn7Cr2Xk2UHPph3PEQTogSqYRiTGQz5-b7qSARe2Zo0bA@mail.gmail.com>
Date:   Tue, 3 Apr 2018 06:14:23 -0400
From:   Chas Williams <3chas3@...il.com>
To:     Roopa Prabhu <roopa@...ulusnetworks.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 Tue, Apr 3, 2018 at 2:13 AM, Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
> 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 ?.

If a user configures the VLAN device to be a larger than MTU than the port,
then yes, I expect the packet to be dropped.  That's a msconfiguration of either
the VLAN's or port's MTU.  We can't protect the user from that by simply making
sure they can't mismatch the MTUs because you can still get packets dropped
during ingress from the large MTU VLAN.

>> 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 am attempting to allow a configuration that lets me choose the appropriate
MTU size for each port.  With the previous code to configure a VLAN device
with an MTU of 9000, I would need to configure all the ports
on the bridge with an MTU of 9000 regardless of whether those ports should
be passing large MTU traffic.  I am creating a potential packet drop issue
by forwarding traffic between ports that have an artificially inflated MTUs.


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

The VLAN device MTU can't be larger than the parent MTU.  The end user
is just going to set the parent bridge MTU to be larger anyway, so why not
just make that the default?