[c-nsp] Maximum spannig tree instances

[Ross Vandegrift]

On Mon, Jul 20, 2009 at 02:34:41PM -0500, Matt Buford wrote:
> First, a quick search for SNMP support makes me think that we won't be doing
> any changes to this over SNMP.  You have to read the bitmask, edit it, and
> then rewrite it with your changes.  This means if 2 people attempt to edit
> the allowed VLANs on the same port at the same time, they'll overwrite each
> other's changes.  So now, our web based port-VLAN form (which is already a
> little slow due to lots of SNMP tables to walk) will also have to also SSH
> to the 2 upstream switches to issue the "add" commands.  We're already
> headed down a rough road here...

You can avoid these issues, and it's not too terrible.  BUT, I've
recently rewritten all of my software to merge config via TFTP instead
of using the VTP-MIB.  Write operations are very, very racy.  I've
uncovered dozens of crashes in SXF on our production gear.  I know of
one that affects up through SXI.  Having the switch merge config via
TFTP from SNMP is not bad at all for a web app.

If you're brave, here's two approaches to consistently managing VLAN
bitmasks:

1) Always blindly set the bitmask to the set of VLANs that are
required by the downstream device.  So long as you first add the VLAN
to the downstream device, you'll always come back with a set including
both VLANs set by two conflicting users.

2) CISCO-VTP-MIB::vlanTrunkPortSetSerialNo is an advisory lock that
apps can use to coordinate their changes:
	a) Read the vlanTrunkPortSetSerilNo.ifIndex, save the result.
	b) Compute whatever VLAN changes you need to make
	c) In one SNMP write, set the new bitmasks and set
vlanTrunkPortSetSerialNo to the value read in a.  If it doesn't match,
the switch will reject all writes.

> Second, there is the question of removing VLANs from this list.  When a tech
> goes to the web form to set the VLAN for a port, we need to go through all
> ports on the switch and see if anyone else is using the old VLAN that the
> port used to be on.  Don't forget to check for it being used on tagged
> ports!  If no one remains using that VLAN on the access switch, then it can
> be pruned from the uplinks.  Then there's the (unlikely, but possible) case
> where someone added a port to that VLAN in between the time you started
> walking the table and when you deleted the VLAN from the ACL.  Oops.

Having implemented this, it isn't as difficult as it sounds.  Just
takes a bit of care to record what your switching topology looks like.
I don't split the operation into add and remove - every update always
sets the trunks to their fully-pruned set of VLANs:

1) For each pair of connected switches, I store the interfaces that
are inter-connected.

2) Starting at the leaf device, I setup the required VLAN changes
locally.

3) Then, walking backwards from that device, collect the set of
required VLANs and change the trunks that connect that device.

4) Stop when you get to whatever the root of your switching domain is.
If you have a ring topology, you'll need some way to break the loop.

> Finally, there is cost associated with the development work and
> administrative hassle that this VLAN pruning requires.  I'd prefer to spend
> that money on hardware that Just Works, as opposed to having my own staff of
> software developers and network engineers maintain this system of ACLs.  One
> time fees for hardware to make my problems disappear forever and my network
> configuration less complex are appreciated.  :)

Fair enough - I'd love to provide you my software, but I'm not sure
that my employer would be okay with it.

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