All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arvid Brodin <arvid.brodin@enea.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: <netdev@vger.kernel.org>
Subject: Re: bridge: HSR support
Date: Mon, 24 Oct 2011 16:17:47 +0200	[thread overview]
Message-ID: <4EA5738B.8080008@enea.com> (raw)
In-Reply-To: <4E94D67A.9060207@enea.com>

Stephen Hemminger wrote:
> On Tue, 11 Oct 2011 20:25:08 +0200
> Arvid Brodin <arvid.brodin@enea.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.

Ok, having read up some more on this it looks like STP is a standardised part of
bridging, so I guess you're right. 


I need to do two things:

1) Bind two network interfaces into one (say, eth0 & eth1 => hsr0). Frames sent on
   hsr0 should get an HSR tag (including the correct EtherType) and go out on both
   eth0 and eth1.

2) Ingress frames on eth0 & eth1, with EtherType 0x88fb, should be captured and 
   handled specially (either received on hsr0 or forwarded to the other bound 
   physical interface).

Any ideas on the best way to implement this -- what's the nicest place to "hook
into" for this?


-- 
Arvid Brodin
Enea Services Stockholm AB

  parent reply	other threads:[~2011-10-24 14:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4E948A04.8060400@enea.com>
     [not found] ` <20111011112821.28cd3e51@nehalam.linuxnetplumber.net>
2011-10-11 23:51   ` bridge: HSR support Arvid Brodin
2011-10-12 13:28     ` David Lamparter
2011-10-12 14:24       ` Arvid Brodin
2011-10-24 14:17     ` Arvid Brodin [this message]
2011-10-28 15:34       ` Arvid Brodin
2011-10-28 15:54         ` Stephen Hemminger
2011-10-28 16:36           ` Arvid Brodin
2011-12-06 23:23           ` Arvid Brodin
2011-12-06 23:27             ` Stephen Hemminger
2011-12-07 18:30               ` Arvid Brodin
2011-12-07 19:59                 ` Jay Vosburgh
2011-12-08 14:45                   ` Arvid Brodin
2011-11-21 16:52         ` Arvid Brodin
2012-01-06 18:11       ` Arvid Brodin
2012-01-12 18:02         ` bridge: HSR support - possible recursive locking? Arvid Brodin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EA5738B.8080008@enea.com \
    --to=arvid.brodin@enea.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.