Re: Should the bridge learn from frames with link local destination MAC address?
> >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
Re: Should the bridge learn from frames with link local destination MAC address?
On 9 November 2018 18:24:18 EET, Roopa Prabhu wrote: >On Fri, Nov 9, 2018 at 8:00 AM Stephen Hemminger > wrote: >> >> On Fri, 9 Nov 2018 04:24:43 +0100 >> Andrew Lunn 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?
On Fri, Nov 9, 2018 at 8:00 AM Stephen Hemminger wrote: > > On Fri, 9 Nov 2018 04:24:43 +0100 > Andrew Lunn 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?
On Fri, 9 Nov 2018 04:24:43 +0100 Andrew Lunn 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.
