Introducing open source MSTP daemon

Introducing open source MSTP daemon

[Vitalii Demianets]

Good day!
I am happy to introduce open source MSTP daemon:
http://sourceforge.net/p/mstpd

Of course due to current limitations of the Linux bridge code, namely:
 - no integration with VLAN code
 - no support of different FIDs (independent learning)
 - no support of the per-MSTI port states
this daemon is not very useful for the bare Linux box. It can work only with 
support of specialized driver which talks to the MSTP-aware hardware (most of 
the today ethernet switching parts are MSTP-aware and support FIDs and 
per-MSTI port states).
Nevertheless I hope to find some interest in my work. Maybe it will stimulate 
in some way the integration of the Linux bridge and VLAN code, who knows? 
>From the IEEE point of view they are already merged, see 802.1Q-2005 which 
incorporates previous editions of 802.1q and 802.1d and 802.1w/s.

Once again, all interested are welcome. Please review, criticize, test, 
modify, patch, deploy and do other things :) Any kind of feedback is 
extremely welcome :)

-- 
Vitalii Demianets

Re: Introducing open source MSTP daemon

[David Lamparter]

On Thu, Sep 22, 2011 at 05:27:32PM +0300, Vitalii Demianets wrote:
> Good day!
> I am happy to introduce open source MSTP daemon:
> http://sourceforge.net/p/mstpd
> 
> Of course due to current limitations of the Linux bridge code, namely:
>  - no integration with VLAN code
>  - no support of different FIDs (independent learning)
>  - no support of the per-MSTI port states

Yes... Linux kernel bridging code only implements 802.1D, even the mac
table is one-for-all-VLANs.

> this daemon is not very useful for the bare Linux box. It can work only with 
> support of specialized driver which talks to the MSTP-aware hardware (most of 
> the today ethernet switching parts are MSTP-aware and support FIDs and 
> per-MSTI port states).
> Nevertheless I hope to find some interest in my work. Maybe it will stimulate 
> in some way the integration of the Linux bridge and VLAN code, who knows? 
> From the IEEE point of view they are already merged, see 802.1Q-2005 which 
> incorporates previous editions of 802.1q and 802.1d and 802.1w/s.
> 
> Once again, all interested are welcome. Please review, criticize, test, 
> modify, patch, deploy and do other things :) Any kind of feedback is 
> extremely welcome :)

Very cool!

The code looks quite good to me (i've only looked at 2 files though ;).
Minor nitpicks:
 - hmac_md5 & epoll could maybe come from an external library. you're
   the 3810583th person to have code for that... libevent?
   OpenSSL/gnutls?
 - libnetlink.c is a copy from iproute2? since it is a fresh clean SVN,
   it's not easy to know whether you made changes. Can you put a note
   which version this is? Or maybe you can link it externally?
 - the "assign" macro and "boolFalse" in mstp.c are weird. I understand
   you want stricter type checking, but this makes the code somewhat
   odd to read. Maybe external tools can be used to do this checking
   (sparse, cppcheck, llvm's static analysis, ...)
 - what coding style is it? it's neither Linux kernel nor GNU :) - maybe
   reformat to Linux kernel style while it is still new.

I assume it works with current Linux kernel bridge code on a RSTP level?
The code looks considerably more maintainable than rstpd :) - I will try
running it later!


-David

Re: Introducing open source MSTP daemon

[David Lamparter]

On Thu, Sep 22, 2011 at 06:39:40PM +0200, David Lamparter wrote:
>  - what coding style is it? it's neither Linux kernel nor GNU :) - maybe
>    reformat to Linux kernel style while it is still new.

Oh, it's GNU. I shouldn't look at source code in a web browser, stupid
me - Sorry, forget I asked.

-David

Re: Introducing open source MSTP daemon

[Vitalii Demianets]

On Thursday 22 September 2011 19:39:40 David Lamparter wrote:
> Very cool!
>
> The code looks quite good to me (i've only looked at 2 files though ;).
> Minor nitpicks:
>  - hmac_md5 & epoll could maybe come from an external library. you're
>    the 3810583th person to have code for that... libevent?
>    OpenSSL/gnutls?
>  - libnetlink.c is a copy from iproute2? since it is a fresh clean SVN,
>    it's not easy to know whether you made changes. Can you put a note
>    which version this is? Or maybe you can link it externally?
>  - the "assign" macro and "boolFalse" in mstp.c are weird. I understand
>    you want stricter type checking, but this makes the code somewhat
>    odd to read. Maybe external tools can be used to do this checking
>    (sparse, cppcheck, llvm's static analysis, ...)
>
Happy to hear you are interested )
I suppose these questions are not related to kernel development so I suggest 
to continue discussion on above topics at the project discussion board:
http://sourceforge.net/p/mstpd/discussion/

> I assume it works with current Linux kernel bridge code on a RSTP level?
> The code looks considerably more maintainable than rstpd :) - I will try
> running it later!
>
Sorry, at the moment function MSTP_OUT_set_state() does nothing except 
logging. But it is valueable thought: although MSTI states do not have 
meaning to the kernel bridge code, CIST states can be used to control bridge 
slave states, so mstpd can replace rstpd as more generic (and conforming to 
more recent standard).
Anyways, the code is basically untested. It compiles and runs in my setup, 
that's all for now. But I somehow have gut feeling that the code is mature 
enough to be put for the community consideration.

-- 
Vitalii Demianets

Re: Introducing open source MSTP daemon

[David Lamparter]

On Fri, Sep 23, 2011 at 10:36:04AM +0300, Vitalii Demianets wrote:
> I suppose these questions are not related to kernel development so I suggest 
> to continue discussion on above topics at the project discussion board:
> http://sourceforge.net/p/mstpd/discussion/

That's a forum - I'm afraid that's not quite a good communication
channel for software development feedback. A "normal" software developer
probably has 10, 20, 30... packages he follows around; if each of them
was using a separate discussion forum, the developer would have to check
30 forums regularly, in hir browser.

A mailing list delivers all of that discussion to the developer's
mailbox where it's very easy to sort, follow & respond. Considering the
probably rather low traffic, an existing list might even do it.

> > I assume it works with current Linux kernel bridge code on a RSTP level?
> > The code looks considerably more maintainable than rstpd :) - I will try
> > running it later!
> >
> Sorry, at the moment function MSTP_OUT_set_state() does nothing except 
> logging. But it is valueable thought: although MSTI states do not have 
> meaning to the kernel bridge code, CIST states can be used to control bridge 
> slave states, so mstpd can replace rstpd as more generic (and conforming to 
> more recent standard).

Well, with the current kernel code you can basically support MSTP setups
where all VLANs are mapped to one MSTI, since there's just one port
state for all VLANs. As far as I can tell, that doesn't need to be
the CIST/instance 0, as long as it's the same for all VLANs.

> Anyways, the code is basically untested. It compiles and runs in my setup, 
> that's all for now. But I somehow have gut feeling that the code is mature 
> enough to be put for the community consideration.

Well, "the community" is usually happy when you continually maintain and
improve your code - one-shot code publications ("fire & forget") happen
all too often and are forgotten quickly...


-David

Re: Introducing open source MSTP daemon

[Vitalii Demianets]

On Friday 23 September 2011 15:30:58 David Lamparter wrote:
> On Fri, Sep 23, 2011 at 10:36:04AM +0300, Vitalii Demianets wrote:
> > I suppose these questions are not related to kernel development so I
> > suggest to continue discussion on above topics at the project discussion
> > board: http://sourceforge.net/p/mstpd/discussion/
>
> That's a forum - I'm afraid that's not quite a good communication
> channel for software development feedback. A "normal" software developer
> probably has 10, 20, 30... packages he follows around; if each of them
> was using a separate discussion forum, the developer would have to check
> 30 forums regularly, in hir browser.
>
> A mailing list delivers all of that discussion to the developer's
> mailbox where it's very easy to sort, follow & respond. Considering the
> probably rather low traffic, an existing list might even do it.
>

Ok, as long as there is no objection from other list participants, let's 
continue in netdev list.

> > > I assume it works with current Linux kernel bridge code on a RSTP
> > > level? The code looks considerably more maintainable than rstpd :) - I
> > > will try running it later!
> >
> > Sorry, at the moment function MSTP_OUT_set_state() does nothing except
> > logging. But it is valueable thought: although MSTI states do not have
> > meaning to the kernel bridge code, CIST states can be used to control
> > bridge slave states, so mstpd can replace rstpd as more generic (and
> > conforming to more recent standard).
>
> Well, with the current kernel code you can basically support MSTP setups
> where all VLANs are mapped to one MSTI, since there's just one port
> state for all VLANs. As far as I can tell, that doesn't need to be
> the CIST/instance 0, as long as it's the same for all VLANs.
>
Theoretically, yes. But if the user have bothered to change default config and 
assign all the VLANs to some MSTI, he obviously wants to do something 
MST-related. Maybe she is just in the middle of the configuration process and 
in some time he'll add some  VLANs to another MSTI?
I'd prefer to keep it simple, and translating CIST states to the kernel bridge 
(and all MSTI states to another driver) seems simple enough to me. And this 
approach will also work in the cases when mstpd chooses (R)STP mode of 
operation instead of MSTP, e.g. auto-sensing STP-only neighbors.

> > Anyways, the code is basically untested. It compiles and runs in my
> > setup, that's all for now. But I somehow have gut feeling that the code
> > is mature enough to be put for the community consideration.
>
> Well, "the community" is usually happy when you continually maintain and
> improve your code - one-shot code publications ("fire & forget") happen
> all too often and are forgotten quickly...
>
Understandable enough :)
So for now I'll focus on the (R)STP case and add code which will translate 
CIST states to the kernel bridge. Then the code can be really evaluated (at 
least for the (R)STP cases), not only reviewed.

-- 
Vitalii Demianets

Re: Introducing open source MSTP daemon

[Vitalii Demianets]

On Thursday 22 September 2011 19:39:40 David Lamparter wrote:
>
> I assume it works with current Linux kernel bridge code on a RSTP level?
> The code looks considerably more maintainable than rstpd :) - I will try
> running it later!
>

Ok, now it works with kernel bridge code and you can evaluate it.

mstpd sends all the state changes in the CIST to the kernel bridge, so it 
works for the (R)STP cases as expected. Checked it by connecting two bridges: 
one running mstpd and another running rstpd and in-kernel stp. In both cases 
mstpd code behaves reasonably. Not checked in more complex setups though.

Also mstpd translates to the bridge code fdb flushing events and changes 
ageing time (for the rapid ageing case).

-- 
Vitalii Demianets

Re: Introducing open source MSTP daemon

[augusto]

Vitalii Demianets <vitas <at> nppfactor.kiev.ua> writes:

> 
> On Thursday 22 September 2011 19:39:40 David Lamparter wrote:
> >
> > I assume it works with current Linux kernel bridge code on a RSTP level?
> > The code looks considerably more maintainable than rstpd :) - I will try
> > running it later!
> >
> 
> Ok, now it works with kernel bridge code and you can evaluate it.
> 
> mstpd sends all the state changes in the CIST to the kernel bridge, so it 
> works for the (R)STP cases as expected. Checked it by connecting two bridges: 
> one running mstpd and another running rstpd and in-kernel stp. In both cases 
> mstpd code behaves reasonably. Not checked in more complex setups though.
> 
> Also mstpd translates to the bridge code fdb flushing events and changes 
> ageing time (for the rapid ageing case).
> 


Hi Vitalii,

Thanks for your work.

I am trying to implement your solution on an embedded system, but I dont have a 
clear idea of how to use it.

My scenario is like this:

eth0.2 and eth1.2 belong to br1
eth0.4 and eth3.4 belong to br2
eth1.5 and eth3.5 belong to br3

I added br1 br2 and br3 to bridge-stp.

What steps should I take now?

Thanks for your help

Augusto

Re: Introducing open source MSTP daemon

[David Lamparter]

On Tue, Jan 31, 2012 at 09:38:33AM +0000, augusto wrote:
> I am trying to implement your solution on an embedded system, but I dont have a 
> clear idea of how to use it.
> 
> My scenario is like this:
> 
> eth0.2 and eth1.2 belong to br1
> eth0.4 and eth3.4 belong to br2
> eth1.5 and eth3.5 belong to br3
> 
> I added br1 br2 and br3 to bridge-stp.
> 
> What steps should I take now?

None. The Linux kernel bridge only supports 802.1D bridging / [R]STP,
but not 802.1Q bridging / MSTP kernel part.

You can add eth0 & eth1 to a bridge and put the VLANs on the bridge
(br0.2 / br0.4 / br0.5). That would be a .1D bridge, then.

Or, you can take a look at OpenVSwitch, no idea if it does .1Q/MSTP.


-David

Re: Introducing open source MSTP daemon

[yao zhao]

nice job!

Will try! more work needed in kernel!

yao

On Thu, Sep 22, 2011 at 10:27 AM, Vitalii Demianets
<vitas@nppfactor.kiev.ua> wrote:
> Good day!
> I am happy to introduce open source MSTP daemon:
> http://sourceforge.net/p/mstpd
>
> Of course due to current limitations of the Linux bridge code, namely:
>  - no integration with VLAN code
>  - no support of different FIDs (independent learning)
>  - no support of the per-MSTI port states
> this daemon is not very useful for the bare Linux box. It can work only with
> support of specialized driver which talks to the MSTP-aware hardware (most of
> the today ethernet switching parts are MSTP-aware and support FIDs and
> per-MSTI port states).
> Nevertheless I hope to find some interest in my work. Maybe it will stimulate
> in some way the integration of the Linux bridge and VLAN code, who knows?
> From the IEEE point of view they are already merged, see 802.1Q-2005 which
> incorporates previous editions of 802.1q and 802.1d and 802.1w/s.
>
> Once again, all interested are welcome. Please review, criticize, test,
> modify, patch, deploy and do other things :) Any kind of feedback is
> extremely welcome :)
>
> --
> Vitalii Demianets
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html