Home

!! THE PROJECT HAS MOVED: https://github.com/mstpd/mstpd !!
!! THIS REPOSITORY HAS HISTORICAL VALUE ONLY !!

MSTPD Wiki Home Page

MSTPD is open source user-space daemon licensed under GPLv2.

At the moment the latest version 0.03 is reported to be compliant with IXIA ANVL RSTP test suite, with the notable exception of looped-back BPDUs (see discussion on the matter on the Implementation Features wiki page).

Important note! MSTP part of the code (as opposed to STP/RSTP part) is mainly untested, so I believe it will behave unexpectedly in many situations. Don't use it in production!

Implementation Features

Also MSTPD includes a number of useful features which are not defined in 802.1Q-2005 standard, but are found on many commercial switches. Namely:

• BPDU Guard. Added in revision [r42]. Thanks to Satish Ashok;
• Bridge Assurance. Added in revision [r46]. Thanks to Satish Ashok;
  (WARNING: it might be dropped in the future and replaced by the AutoIsolate feature of 802.1Q-2011, see this ticket )
• Enhanced statistics: TX/RX BPDU/TCN counters, Forwarding/Blocking transitions counters, last 2 ports which caused topology change. Added in revision [r51]. Thanks to Satish Ashok.

Goals of the project

Create reliable and well-tested MSTP code.
Get some user base - the more users of this code, the more test coverage is.
Replace rstpd.

Crying for help

I'm in a great despair: the project seriously lacks testing. There are two excellent test suits out there: UNH MSTP Interoperability and UNH MSTP Operational Test Suites. But I can't imagine how I can get test frames used in these suites. It seems like those frame tables are covered by some sort of non-disclosure agreement. And in the same time UNH test suites are considered as industry standard. So, the mstpd should pass those tests. But I can not get frames used in the tests :(
Does anybody have any thoughts how can I get those frames? Maybe somebody already have test setup and can help me by testing and reporting results?

Current state

The mstpd is reported to be successfully integrated in the following distributions:

• Cumulus Linux. Here is a quotation from Satish Ashok of Cumulus Networks: "Cumulus Networks™ was founded to provide fast, easy, and affordable networks to everyone. We began this revolution by disaggregating networking hardware from network operating systems, and bringing an open and extensible true Linux® operating system to networking, Cumulus Linux™. This open approach fosters collaboration and brings together the best of breed software, technologies and innovations. MSTPD is part of Cumulus Linux and the STP/RSTP capability is currently supported."
  Thanks, Satish, for pushing your bug fixes and new features back to MSTPD project!
• IPFire 3.x. Many thanks to Michael Tremer, the maintainer of the IPFire distribution, for the help and support during first baby steps in mstpd life :) It was priceless.
• DD-WRT. It seems that DD-WRT people had included mstpd in their experimental branch.

Note: above distributions use only STP/RSTP protocols and are not using multiple tree instances.

The mstpd is reported to be successfully integrated in the product on the following arches:

• Broadcom Xstrata [MIPS CPU] (committed by Vladimir Cotfas <unix_router ? yahoo DOT com>) - only in STP/RSTP mode, not using multiple tree instances

The daemon depends on the bridge Linux kernel code to gather basic info about bridge, such as bridge state (up/down, STP on/off), slave interfaces for the bridge and their state (up/down). Also daemon translates CIST states to the kernel bridge slaves, so mstpd in (r)stp mode can be used as replacement for the current rstpd (and even for the in-kernel stp!).

MSTP standard (802.1Q-2005) requires from the bridge to be heavily interconnected with the VLANs infrastructure, namely:

• Support several (2 .. 65) independent FIDs (Forwarding Information Databases). Each VLAN belongs to the one of FIDs, and learning of the MAC addresses is done independently in the each FID (independent learning as opposed to shared learning in the current Linux bridges);
• Support several (2 .. 65) Multiple Spanning Tree Instances. Each FID belongs to the one of MSTIs;
• Support per-MSTI port states (Discarding / Learning / Forwarding) so that each bridge port can have different states for different MSTIs.

This is a big flaw in Linux. Actually, in Linux bridge code is totally independent from VLAN code and given wide deployment of the 802.1Q-2005 compatible bridges this is wrong approach. Bridge and VLAN code should be merged together.

Anyway, this is not true for now, so MSTP daemon is not as useful for the bare Linux box (except for the (R)STP case - as stated above it works with the kernel bridge well enough in this case). But there are plenty embedded cases where bridging functions are implemented by specialized hardware with support of custom drivers. For such cases MSTP daemon can be successfully utilized. The daemon code has a few hooks where driver-specific code should be inserted to control the bridge hardware.

ACKNOWLEDGEMENTS

Initial code was written by looking at (and shamelessly stealing some parts from):

• rstpd by Srinivas Aji <Aji_Srinivas ? emc DOT com>
• rstplib by Alex Rozin <alexr ? nbase DOT co DOT il> and Michael Rozhavsky <mike ? nbase DOT co DOT il>