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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
