Linux Ethernet Bridging - Mar 2008 - [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

Hi List

I cloned the above RSTP imp. and cross-compiled it to powerpc and tried
in on my 2.6.23 kernel, but didn't get very far:

Created a bridge, br0, with brctl and added two interfaces.
started rstpd without args and ran rstpctl
  rstpctl showbridge br0
and all I get is
  CTL_get_bridge_state: Got return code 0, 1003
  Failed to get bridge state: Err_Bridge_is_down

The br0 i/f is UP amd RUNNING and so is the interfaces I added.
I probably forgot to do something I suppose, but what?

    Jocke

> -----Original Message-----
> From: Joakim Tjernlund [mailto:Joakim.Tjernlund at transmode.se]
> Sent: den 29 mars 2008 17:22
> To: 'Bridge at lists.linux-foundation.org'
> Subject: RSTP in
http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary problems
> 
> Hi List
> 
> I cloned the above RSTP imp. and cross-compiled it to powerpc and tried
> in on my 2.6.23 kernel, but didn't get very far:
> 
> Created a bridge, br0, with brctl and added two interfaces.
> started rstpd without args and ran rstpctl
>   rstpctl showbridge br0
> and all I get is
>   CTL_get_bridge_state: Got return code 0, 1003
>   Failed to get bridge state: Err_Bridge_is_down
> 
> The br0 i/f is UP amd RUNNING and so is the interfaces I added.
> I probably forgot to do something I suppose, but what?
> 
>     Jocke
Never mind, user error on my part.

I do wonder though if rstpd is production ready or still needs more
testing/fixes?

   Jocke

Hi Joakim,

  Would you be interested in testing out a newer implementation that
we now have? This is
much closer to the 802.1D-2004 standard and has passed the UNH RSTP
protocol tests.
My updates have not yet made it to Stephen Hemminger's git repo, but I
am attaching a
a patch set on top of that, as well as a tarball of my git-repo with
the additional commits.

I don't know how the mailing list handles attachments, let me see anyway.

I am interested in seeing this used more, and I will be happy to
assist with any issues. Please
let me know how things go.

This is fairly new code, but it has gone through some testing and use.
One limitation
is that there is no mechanism to automatically restart or fall back to
kernel STP if the RSTP
daemon crashes. But it hasn't crashed lately in our testing.

Thanks.
Srinivas.

P.S.: One note on bridge-stp and general bridge startup.

We started out with needing an explicit rstpctl command to indicate
to the daemon that it needs to run RSTP on a bridge, which is why there is the
"exec /sbin/rstpctl rstp $bridge on ;;" (as you corrected in your
patch.)

But now, the daemon is written to enable RSTP when it finds that the
kernel is treating the
bridge as RSTP (/sys/class/net/<bridge_name>/bridge/stp_state is 2),
so as long as you run
"brctl stp <bridge_name> on" before briding the bridge interface
up,
you can just have a
bridge-stp script that returns 0 (success) when you want rstpd to
handle the bridge, and
non-zero when you want kernel STP running on the bridge.

That startup sequence we use is:
0. Have a bridge-stp that returns 0 if you want RSTP for the
particular bridge name.
    Or returns 0 always if you intend to have only one bridge, and want RSTP.

1. Start rstpd
2. Configure the bridge (brctl addbr, brctl addif's ...)
3. brctl stp <bridge_name> on
4. ifconfig <bridge_name> up. (Or ifup <bridge_name>, which should
apply any IP config.)


On Sat, Mar 29, 2008 at 10:40 PM, Joakim Tjernlund
<Joakim.Tjernlund at transmode.se> wrote:
> > -----Original Message-----
>  > From: Joakim Tjernlund [mailto:Joakim.Tjernlund at transmode.se]
>  > Sent: den 29 mars 2008 17:22
>  > To: 'Bridge at lists.linux-foundation.org'
>  > Subject: RSTP in
http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary problems
>  >
>  > Hi List
>  >
>  > I cloned the above RSTP imp. and cross-compiled it to powerpc and
tried
>  > in on my 2.6.23 kernel, but didn't get very far:
>  >
>  > Created a bridge, br0, with brctl and added two interfaces.
>  > started rstpd without args and ran rstpctl
>  >   rstpctl showbridge br0
>  > and all I get is
>  >   CTL_get_bridge_state: Got return code 0, 1003
>  >   Failed to get bridge state: Err_Bridge_is_down
>  >
>  > The br0 i/f is UP amd RUNNING and so is the interfaces I added.
>  > I probably forgot to do something I suppose, but what?
>  >
>  >     Jocke
>
>  Never mind, user error on my part.
>
>  I do wonder though if rstpd is production ready or still needs more
>  testing/fixes?
>
>
>
>    Jocke
>
>  _______________________________________________
>  Bridge mailing list
>  Bridge at lists.linux-foundation.org
>  https://lists.linux-foundation.org/mailman/listinfo/bridge
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rstp_patch.gz
Type: application/x-gzip
Size: 113648 bytes
Desc: not available
Url :
http://lists.linux-foundation.org/pipermail/bridge/attachments/20080330/28d581c4/attachment-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rstp.tgz
Type: application/x-gzip
Size: 397900 bytes
Desc: not available
Url :
http://lists.linux-foundation.org/pipermail/bridge/attachments/20080330/28d581c4/attachment-0003.bin

>  > One limitation
>  > is that there is no mechanism to automatically restart or fall back
to
>  > kernel STP if the RSTP
>  > daemon crashes. But it hasn't crashed lately in our testing.
>
>  Should be fixable, just vfork and wait for an abnormal exit status,
>  reset state and vfork again.
Yes, doable, not yet done though.
>  hmm, how does stp_state become 2? Do I need a new kernel(on 2.6.23 now)?
>  Don't follow, why do I need a bridge-stp at all? Seem like I should
>  just start rstpd and config my bridge normally?
2.6.23 has all the kernel stuff needed.

The way things happen is this:

When you do "brctl stp <bridge_name> on", the kernel runs
"/sbin/bridge-stp <bridge_name> start" and waits for the exit
code. If
the exit code is 0, the kernel sets stp_state to 2, and assumes that
userspace will take care of STP and does not do any STP actions. (This
state is different from STP disabled, since during STP disabled, the
kernel still brings up ports from learning to forwarding using a
timeout, and also, the bridge forwards BPDUs too in that state.) If
the exit code is non-zero, stp_state is set to 1 and kernel STP is
activated.

So you need to:
1. Start rstpd
2. Have a bridge-stp script that returns success
3. Configure your bridge. (Here, because of the event mechanism
currently available, it is best to do "brctl stp <bridge_name>
on"
before doing "ifconfig <bridge_name> up")
> I do this
> ./rstpd
> brctl addbr br0
> brctl addif br0 eth0
> brctl stp br0 on
> ifconfig eth0 0.0.0.0 up
> ifconfig br0  0.0.0.0 up
> ./rstpctl showbridge
> It does not get enabled and
> #> cat /sys/class/net/br0/bridge/stp_state
> 1
This should have worked. Could you check that /sbin/bridge-stp has
execute bit set and is getting run? It doesn't have stdout, etc, so
you need to log messages to a file to see what is happening. e.g.
(date; echo $0 "$@") >>/tmp/bridge-stp.log

Also, rstp will log to syslog. To see lots more messages, you can do
"rstpctl debuglevel 4", but since we are doing
(main.c) vsyslog((level <= LOG_LEVEL_INFO) ? LOG_INFO : LOG_DEBUG, ....
you need to configure your syslog to log the LOG_DEBUG messages as
well to see them, or just fix the code to get all the messages at
LOG_INFO.
> Have this code been tested on a big endian CPU?
No, only ix86 and x86_64 at the moment. At least in the RSTP logic
itself (rstp.[ch]), I seem to have taken some care to use bytes
directly for the on-the-wire structures and convert to and from
numbers using arithmetic, which should be endian independent. I don't
see any obviously little endian specific code in the other parts
either. The rstpctl program relies on structures having the same
binary layout in it as well as in rstpd, but that should not be
affected by endianness.

In any case, see if you can get the bridge-stp thing working to the
point where you see stp_state as 2. If you see issues past that, like
received BPDU's not being recognized, or anything else seeming
endianness related, I will set up a qemu powerpc image and test.

Thanks.

>
>  I don't like the bridge-stp <bridge> start/stop interface. Why
>  would bridge-stp know what bridge to run RTSP on? A more natural
>  way, IMHO, would to extend brctl with a "rstp on" method. Why
>  is there one rstpctl tool and one brctl tool?
I wrote rstpctl to just control the rstp daemon. Should integrate it
with brctl, making it so that brctl checks whether kernel STP or RSTP
is being used and sets either kernel STP config or sends the config to
rstpd as appropriate. I haven't gotten around to that.

I don't like bridge-stp scheme too much either, especially after
realizing the RTNL lock limitation, but it is just enough to get
things working if we don't try to start rstpd from within it (though
the sample does that.) Given the amount of trouble bridge-stp seems to
cause, I should probably work on a different kernel interface for
indicating userspace stp.