STP

[Mark]

Hello

I have already asked this question in comp.dcom.lans.ethernet, but that
group seems to have gone dormant forever, so I'd like to try my luck in
here.

Linux kernel has its own implementation of the spanning tree, it comes along
with the 802.1d bridge functionallity. Many switch chip vendors ship their
SDK (full sources, inlcuding Linux kernel), implementing VLAN, ACL etc.
functions as well as their own implementation of spanning tree protocol.

What is the point of thadt, why not use Linux's one? Is Linux' STP not
entirely 802.1d compliant, or its architecture not enough scalable?

Thanks.

--
Mark

[David Schwartz]

On Oct 14, 5:42 pm, "Mark" <mark_cruzNOTFORS...@hotmail.com> wrote:

> Linux kernel has its own implementation of the spanning tree, it comes along
> with the 802.1d bridge functionallity. Many switch chip vendors ship their
> SDK (full sources, inlcuding Linux kernel), implementing VLAN, ACL etc.
> functions as well as their own implementation of spanning tree protocol.

> What is the point of thadt, why not use Linux's one? Is Linux' STP not
> entirely 802.1d compliant, or its architecture not enough scalable?

The difference is that the switch chip vendors STP build normally
interacts with the specifics of their switch chip. There should be, in
practice, no difference between using the vendors sources and using
the Linux implementation if the Linux driver supports that switch chip
fully.

Typically, the Linux STP implementation is used together with software
forwarding. Software forwarding doesn't yet scale to 48 GE ports and 2
10GE ports. However, there's no reason Linux's STP implementation
can't be used to configure a switch chip that does hardware
forwarding.

If that didn't answer your question, you should try clarifying what it
is you really want to know.

DS

[Mark]

David Schwartz wrote:
> The difference is that the switch chip vendors STP build normally
> interacts with the specifics of their switch chip.

In other words, adjusting/modifying Linux's STP to a chip's specifics would
be a substantial amount of work to do and likely less effective, then
implementing from scratch.

> There should be, in
> practice, no difference between using the vendors sources and using
> the Linux implementation if the Linux driver supports that switch chip
> fully.

I think so, as long as both implementations are 802.1d compliant.

> Typically, the Linux STP implementation is used together with software
> forwarding. Software forwarding doesn't yet scale to 48 GE ports and 2
> 10GE ports. However, there's no reason Linux's STP implementation
> can't be used to configure a switch chip that does hardware
> forwarding.

Thanks, it basically answers my question.

--
Mark

[David Schwartz]

On Oct 15, 11:11 pm, "Mark" <mark_cruzNOTFORS...@hotmail.com> wrote:

> David Schwartz wrote:

> > The difference is that the switch chip vendors STP build normally
> > interacts with the specifics of their switch chip.

> In other words, adjusting/modifying Linux's STP to a chip's specifics would
> be a substantial amount of work to do and likely less effective, then
> implementing from scratch.

Maybe not. I think the STP logic could probably stay 95% the same. The
only difference would be how you get the STP packets (since you need
to know which port you received them on, which you normally don't) and
what you do with the STP decisions (you need to switch ports between
blocking and forwarding modes and still get STP packets).

I've noticed that most (at least in my experience) switch chip vendors
use VxWorks in their development kits. I wonder if this is for
technical, legal, or marketing reasons.

DS