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
