netdev - Re: Introducing open source MSTP daemon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Jan 2012 09:38:33 +0000 (UTC)
From:	augusto <augusto@...scend.com>
To:	netdev@...r.kernel.org
Subject: Re: Introducing open source MSTP daemon

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html