netdev - Re: Should the bridge learn from frames with link local destination MAC address?

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: <20181109080008.022b93cb@xeon-e3>
Date:   Fri, 9 Nov 2018 08:00:08 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Roopa Prabhu <roopa@...ulusnetworks.com>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        netdev <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: Should the bridge learn from frames with link local destination
 MAC address?

On Fri, 9 Nov 2018 04:24:43 +0100
Andrew Lunn <andrew@...n.ch> wrote:

> Hi Roopa, Nikolay
> 
> br_handle_frame() looks out for frames with a destination MAC
> addresses with is Ethernet link local, those which fit
> 01-80-C2-00-00-XX. It does not normally forward these, but it will
> deliver them locally.
> 
> Should the bridge perform learning on such frames?
> 
> I've got a setup with two bridges connected together with multiple
> links between them. STP has done its thing, and blocked one of the
> ports to solve the loop.
> 
> host0                   host1
> +-----------------+     +-----------------+
> | lan0 forwarding |-----| lan0 forwarding |
> |                 |	|                 |
> | lan1 forwarding |-----| lan1 blocked    |
> +-----------------+	+-----------------+
> 
> I have LLDP running on both system, and they are sending out periodic
> frames on each port.
> 
> Now, lan0 and lan1 on host1 use the same MAC address.  So i see the
> MAC address bouncing between ports because of the LLDP packets.
> 
> # bridge monitor
> 00:26:55:d2:27:a8 dev lan1 master br0 
> 00:26:55:d2:27:a8 dev lan0 master br0 
> 00:26:55:d2:27:a8 dev lan1 master br0 
> 00:26:55:d2:27:a8 dev lan0 master br0 
> 00:26:55:d2:27:a8 dev lan1 master br0 
> 
> This then results in normal traffic from host0 to host1 being sent to
> the blocked port for some of the time.
> 
> LLDP is using 01-80-C2-00-00-0E, a link local MAC address. If the
> bridge did not learn on such frames, i think this setup would
> work. The bridge would learn from ARP, IP etc, coming from the
> forwarding port of host1, and the blocked port would be ignored.
> 
> I've tried a similar setup with a hardware switch, Marvell 6352. It
> never seems to learn from such frames.
> 
> Thanks
> 	Andrew

I agree with your analysis. A properly operating 802 compliant bridge
should not learn link local addresses.  But changing that in Linux bridge
would probably break some users. There is already a hack to forward link
local frames. There are many usages of Linux vswitch where this behavior
might be a problem:
	1. a container or VM hub
	2. bump in the wire filter
	3. L2 nat etc.

So what ever you decide it has to be optional and unfortunately default
to off.