netdev - Re: bridge: HSR support

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

Date:	Wed, 12 Oct 2011 01:51:22 +0200
From:	Arvid Brodin <arvid.brodin@...a.com>
To:	<netdev@...r.kernel.org>
CC:	Stephen Hemminger <shemminger@...tta.com>,
	Lennert Buytenhek <kernel@...tstofly.org>
Subject: Re: bridge: HSR support

Stephen Hemminger wrote:
> On Tue, 11 Oct 2011 20:25:08 +0200
> Arvid Brodin <arvid.brodin@...a.com> wrote:
> 
>> Hi,
>>
>> I want to add support for HSR ("High-availability Seamless Redundancy",
>> IEC-62439-3) to the bridge code. With HSR, all connected units have two network
>> ports and are connected in a ring. All new Ethernet packets are sent on both
>> ports (or passed through if the current unit is not the originating unit). The
>> same packet is never passed twice. Non-HSR units are not allowed in the ring.
>>
>> This gives instant, reconfiguration-free failover.
>>
>> I'd like your input on how to design the user interface. To me it seems natural
>> to use bridge-utils, which of course today supports STP.
>>
>> One solution is to simply add an "hsr" command:
>>
>> # brctl hsr <bridge> on|off
>>
>> But HSR is mutually exclusive to other modes, and I think that STP and standard
>> bridge mode are mutually exclusive, too? Perhaps it would be better (more user-
>> friendly) to 
>>
>> # brctl type <bridge> standard|stp|hsr
>>
>> ?
>>
>> 'brctl stp <bridge> on|off' would have to be kept for compatibility, but could
>> be a simple wrapper for 'brctl type <bridge> stp|standard'
>>
>> What do you think about this?
>>
>>
> 
> Why is it a bridge thing and not a standalone or bonding (or the new team
> device feature? Wouldn't users want to use it without all the stuff
> related to bridging. The fact that it doesn't work with STP is a big
> red flag that it doesn't belong in the bridge.

Good question! I'm new to the more advanced networking possibilities in Linux, so 
I really don't know where HSR fits best.

HSR is a layer 2 only protocol, with the host acting as bridge for packets not 
destined for itself. It also sends all originating Ethernet packets on both ports,
adding a HSR sequence tag to the packet (using a dedicated EtherType of 0x88FB).
As described above, the HSR units are connected in a ring, in which only HSR units
are allowed.

Having looked now at bonding, it seems to act on several network layers, doing 
multiple things mainly centered around 802.3ad (link aggregation). I'm not sure
how HSR would fit there.

If I understand correctly, team device is an emerging userspace implementation of
the bonding driver?

I guess my take was that HSR seems like a special bridging mode, much like STP.


> Please discuss this on netdev mailing list, others may have different
> opinions.

Done! :)


-- 
Arvid Brodin
Enea Services Stockholm AB
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html