Should the bridge learn from frames with link local destination MAC address?

Should the bridge learn from frames with link local destination MAC address?

[Andrew Lunn]

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

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

[Stephen Hemminger]

On Fri, 9 Nov 2018 04:24:43 +0100
Andrew Lunn <andrew@lunn.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.

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

[Roopa Prabhu]

On Fri, Nov 9, 2018 at 8:00 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Fri, 9 Nov 2018 04:24:43 +0100
> Andrew Lunn <andrew@lunn.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.
>

Andrew, I agree with your analysis also. We have hit this problem too
(and we have an internal bug tracking it).
We have not acted on this so far because of the fear of breaking
existing deployments. I am all for fixing this if there is a
clean way.

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

[nikolay]

On 9 November 2018 18:24:18 EET, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>On Fri, Nov 9, 2018 at 8:00 AM Stephen Hemminger
><stephen@networkplumber.org> wrote:
>>
>> On Fri, 9 Nov 2018 04:24:43 +0100
>> Andrew Lunn <andrew@lunn.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.
>>
>
>Andrew, I agree with your analysis also. We have hit this problem too
>(and we have an internal bug tracking it).
>We have not acted on this so far because of the fear of breaking
>existing deployments. I am all for fixing this if there is a
>clean way.

+1 and since this would be a new bridge boolean option I'd like to add one new
64 bit option with mask for new boolean bridge options so we can avoid
increasing the max rtnl attr id for such options. Please let me know
if you plan to work on the new option or I can cook something.


Thanks,
    Nik

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

[Andrew Lunn]

> >Andrew, I agree with your analysis also. We have hit this problem too
> >(and we have an internal bug tracking it).
> >We have not acted on this so far because of the fear of breaking
> >existing deployments. I am all for fixing this if there is a
> >clean way.
> 
> +1 and since this would be a new bridge boolean option I'd like to add one new
> 64 bit option with mask for new boolean bridge options so we can avoid
> increasing the max rtnl attr id for such options. Please let me know
> if you plan to work on the new option or I can cook something.

Hi Nik

For the moment i made a hack, which is enough for my own personal use.

I'm not too familiar with the bridge code and its netlink interface. I
suspect you can implement this properly much quicker than i could. So
i would prefer leaving it to you. But we can talk about this during
LPC.

  Andrew