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
From: David Lamparter <hidden> Date: 2011-09-22 16:39:50
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
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
From: David Lamparter <hidden> Date: 2011-09-23 12:31:30
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.
quoted
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
On Friday 23 September 2011 15:30:58 David Lamparter wrote:
On Fri, Sep 23, 2011 at 10:36:04AM +0300, Vitalii Demianets wrote:
quoted
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.
quoted
quoted
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.
quoted
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
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
On Thursday 22 September 2011 19:39:40 David Lamparter wrote:
quoted
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
From: David Lamparter <hidden> Date: 2012-02-01 05:56:29
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
nice job!
Will try! more work needed in kernel!
yao
On Thu, Sep 22, 2011 at 10:27 AM, Vitalii Demianets
[off-list ref] 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