[c-nsp] Maximum spannig tree instances

[Ross Vandegrift]

On Fri, Jul 17, 2009 at 03:55:06PM +0100, Phil Mayers wrote:
> Personally I find the (lack of) graceful change control the big killer.  
> Our network is simply *NOT* capable of "defining the mappings ahead of  
> time and never changing them" because of inherited legacy. I cannot  
> tolerate the outages we'd need to incur every time a VLAN was added or  
> removed, and I'm certainly not prepared to spend the many man-months  
> re-numbering every vlan tag on campus into some arbitrary grouping just  
> so I can run MST, when PVST works *now*.

If you can't know your forwarding topologies ahead of time, or you
can't devise a scheme in which to map them, then MST isn't for you.
Itt could introduce an unacceptable amount of management overhead.

But I'm skeptical you really have that many active topologies in a
single switched ethernet - do people really run networks like the
example diagrams in 802.1Q?

> I probably *could* run MST, after a lot of work, but why would I want to?

The only reason would be to reduce CPU impact due to reconvergence.
Again, if you aren't running into issues here, then you absolutely
shouldn't touch it.

> In addition, I have serious concerns about the scope of instance 0,  
> particularly in the topology we run (a collapsed core/distribution  
> triangle).

What's the concern?  Instance 0 is just the usual RST domain.  Some
people I've talked to have been concerned becuase they've assumed that
instances are somehow isolated - which is not the case.

Typical wisdom is to never leave anything mapped to instance 0, but
this comes from a Cisco whitepaper [1] that not only fails to provide
adequate technical reasoning, but justifies the configuration on a
faulty description of instances.

("IST Instance is Active on All Ports" is a fundamental
misunderstanding of the protocol - it's an application of PVST logic
to MST.

Instances aren't the kind of thing that are active per-port.  They are
just the various topologies a bridge may compute best-path to root
for.  If a bridge has a VLAN mapped to instance x, then instance x
must have a computed topology.  Paths for instance 0 are always
computed by every bridge.)

[1] http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfc.shtml

> When I tried it on the bench, I could not come up with an MST setup that  
> worked.

We also run collapsed core/distribution switching triangles.  You may
have been bitten by certain IOS versions that look to support MST but
are actually pre-standard.  The correct name in feature navigator is
something charming like "MST standards compliance".

Our configuration has three instances - a management instance, an odd
instance, and an even instance.  All VLANs less than 100 are reserved
for management and mapped to instance 3.  All odd VLANs starting at
101 are mapped to instance 1.  All even VLANs starting at 100 are
mapped to instance 2.  Switch1 is root bridge for the odd VLANs (and
HSRP primary) and Switch2 is root bridge for the even VLANs (and HSRP
primary).

But don't get me wrong - if I had a working network that wasn't setup
in this fashion, I wouldn't touch it without a good reason - I had the
luxury of starting from scratch.

--
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