[c-nsp] Maximum spannig tree instances

Ross Vandegrift ross at kallisti.us
Fri Jul 17 18:23:58 EDT 2009


On Fri, Jul 17, 2009 at 11:20:31PM +0200, Gert Doering wrote:
> See my e-mail with the description of our topology.  VLAN usage doesn't
> mean "trivial topology".

Yes, you're absolutely correct, and I didn't mean to indicate that
VLAN usage and topology decisions were linked in any manner.

> > I'll go a step further - I doubt that there's a substantially more
> > optimal way to compute only the valid topologies.
> 
> Computers in the year 2009 shouldn't require humans to bow for them to
> make life easy for the computer.

I agree with you, in principle - even five years ago.  Unfortunately,
my 6500s feel every ounce of everything that gets asked of them.

> MST with automatic vlan->instance assignment, auto-creating a new instance
> for every distinct VLAN topology encountered, would be a *good* protocol.
> Save redundant computing effort, while providing maximum flexibility.

Part of the issue is that no bridge ever can have a view on what the
complete forwrding topology is, and so no bridge could know when to
create a new topology.  Which is why I like MST - it lets me tell my
gear "hey - you send this stuff here, because it turns out, I can
promise this will be your active forwarding topology".

The idea of a protocol that could build what VLAN forwarding
topologies existed based on what various trunk links carried is
interesting, but requires far more complete cooperation between
bridges than STP assumes.
 
> (Another nuisance of MST is that if you are forced to interoperate PVSTP
> and MST boxes, there seems to be no way to tell the MST cloud "no, you are 
> not the root of the STP", which brings great pain if all you want to do 
> is "hook a management link from one of your switches into a customer setup 
> that needs to run MST".

I'm not familiar with the MST-PVST interaction, but if it's MST-RST,
you should be able to acheive this.  Make sure all of your MST bridges
have non-minimal priority and have one (or more) RST bridges, outside
of the MST region, have minimal priority.  All of your MST bridges
should compute instance, internal, and common root paths.  The common
spanning-tree roots should appear as the RST bridges.

This is undoubtedly complicated by having customer-facing ports speak
spanning-tree, and that very well may limit your flexability.  We have
the luxury of running bpdu-guard on all customer-facing switchports
because no one is permitted to have a downstream topology that we
don't manage.

-- 
Ross Vandegrift
ross at kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie


More information about the cisco-nsp mailing list