[c-nsp] Maximum spannig tree instances

[Saku Ytti]

On (2009-07-17 11:03 -0400), Jon Lewis wrote:
 
> What about a setup where you have a dual router/switch (6500s) core
> and lots of redundantly uplinked smaller switches with customer
> servers connected.  This seems like a perfect case for MST.  But,
> suppose you add a few trunks (perhaps even redundant) to the core
> switches from metro ethernet providers who bring you metro ethernet
> customer connections, each as their own vlan.  Now you have switches
> participating in STP that you don't control.

Well I wouldn't talk STP to my customers, but would use pseudowire
with STP tunneling. Even if you have PVST it is big risk to talk
STP to customers, as they can make your STPd so busy, it stop
sending BPDU's, and neighbour will open link, forming loop
and wonderful broadcast storm.
Having said that, how would it be different to PVST, if you'd
have MST with core instance and customer instances? 

> In cisco's PVST -> MST migration document, they say MST can interact
> with PVST, but that you should make sure the MST bridge is the root
> for all VLANs allowed on the trunk to a PVST bridge.  They don't say
> what happens if the PVST bridge becomes the root for the CST, but
> they make it sound like you don't want to find out.
> 
> http://l.pr/a4183/PVST-MST-Migration

I guess I have to explain the situation I mentioned in the previous 
email, hopefully I can explain it, without pen and paper somewhat
coherently

Assume MPLS network, where you have various PE boxes and several
separate L2 access rings connected to those PE boxes.
Assume EoMPLS services, what is mostly sold from several PE to couple few
PE's (so few PE's have NNI, to which EoMPLS are terminated from majority of
the PE's).

Now you configure one more EoMPLS tunnel, business as usual.  Via this
EoMPLS tunnel inferior PVST BPDU is send to one of the the 'EoMPLS HUB PE',
the HUB PE sends it towards access switch, which is MST. As it notices
inferior PVST BPDU it starts generating superior PVST BPDU's in every VLAN
every 2s towards the HUB PE.

Now as the HUB PE has many EoMPLS's, these superior PVST BPDU's travel to
many many PE's in the network. And from these PE's they are sent towards
that PE's access network. Here's the kicker some PE's view it as superior
BPDU, and go to root guard, others who do not view it as superior, continue
propagating it in all VLANs.

So now I have several PE boxes not connected to access network at all, as
switchport is in root guard. Of course all this happened within second,
things just blew up all around. Rolling back the originally added new
EoMPLS has no effect, as there are now many ports in network in PVST/MST
boundary mode, generating BPDU's in every VLAN.

Setting metroring priority to 0 wouldn't fix anything, we'd just move the
superior/inferior decision to MAC address, and again some ports would be
root guarded some in boundary spewing superior BPDU's.

Only way to fix your network in above situation is to shutdown all the
ports in boundary mode, make sure they're removed from boundary operation
and bring them back up when you're sure they are not receiving PVST's
anymore. Even one box left, will propagate error again throughout the
network.

After this, we added bpdufilter between PE<->Switch, which in retrospect
we should have done, the day we started deploying EoMPLS. But what
I'd really hope would be that PVST/MST boundary would generate PVST
BPDU only for the VLAN where it has received PVST BPDU, not for
every VLAN, then the problem wouldn't propagate uncontrollably.


-- 
  ++ytti