[nsp] MSTP provisioning queries
afort at choqolat.org
Wed Nov 19 04:11:30 EST 2003
Excuse the rambling..
Hands up who uses the cisco implementation of 802.1s, multiple instance
spanning tree, with more than about 2 bridges in a region?
Now, hands up those who're comfortable changing your 'spanning-tree mst
configuration' on a live network?
Do boundary ports give you gas?
If you raised your hand and it's still raised, please speak up!
From this rather green viewpoint, it appears to boil down to making the
changes (doing moves/adds/changes on vlan->instance mappings) on all
switches in the given MSTP region at the same time (i.e., having lots of
vty sessions open), then (preferably) verifying all pending configs
match ('show pending') and then sending 'exit'/^z/^c/etc to all devices
at close enough to the same time so that you hopefully don't change your
L2 forwarding paths away from the desired for too long.
Alternatively you could load all the new configs via 'copy ftp run' or
similar (triggered via the RW MIB or in our case via a vty interactive
script), and hope they go in without one mussing up and leaving your
network in a somewhat inconsistent state.
To make matters more complex, if you've tied any VLANs up for say, OSPF
sessions between just two multilayer switches, you have to be extra
careful since a topology change caused by the boundary ports going up
will tear down at least one OSPF session (hopefully not the redundant
The configuration (on switch IOS) and the .1s spec refer to a Revision
number combined with the MSTP vlan to instance mapping hashtable, but
this doesn't appear to be implemented (or the .1s spec cover the concept
in much detail). What would be nice is if it behaved like the OSPF MD5
key, i.e., once configured, bridges agree on the lowest common
denominator of revision number and only make a change when they all
agree there's a new revision configured. This doesn't appear to be the
case. Is this the intent of this revision value?
So, is anyone here using MSTP on a largish scale and has a better answer
to the mechanics of building such a network than "pre-provision large
numbers of VLANs" and/or "Perl Net::Telnet/Expect to multiple bridges at
(Oh, and please leave the "large spanning tree domains are evil"
arguments at the door, since I dont argue with you there :).
More information about the cisco-nsp