On Fri, Jul 17, 2009 at 11:20:31PM +0200, Gert Doering wrote: > See my e-mail with the description of our topology. VLAN usage doesn't > mean "trivial topology".
Yes, you're absolutely correct, and I didn't mean to indicate that VLAN usage and topology decisions were linked in any manner. > > I'll go a step further - I doubt that there's a substantially more > > optimal way to compute only the valid topologies. > > Computers in the year 2009 shouldn't require humans to bow for them to > make life easy for the computer. I agree with you, in principle - even five years ago. Unfortunately, my 6500s feel every ounce of everything that gets asked of them. > MST with automatic vlan->instance assignment, auto-creating a new instance > for every distinct VLAN topology encountered, would be a *good* protocol. > Save redundant computing effort, while providing maximum flexibility. Part of the issue is that no bridge ever can have a view on what the complete forwrding topology is, and so no bridge could know when to create a new topology. Which is why I like MST - it lets me tell my gear "hey - you send this stuff here, because it turns out, I can promise this will be your active forwarding topology". The idea of a protocol that could build what VLAN forwarding topologies existed based on what various trunk links carried is interesting, but requires far more complete cooperation between bridges than STP assumes. > (Another nuisance of MST is that if you are forced to interoperate PVSTP > and MST boxes, there seems to be no way to tell the MST cloud "no, you are > not the root of the STP", which brings great pain if all you want to do > is "hook a management link from one of your switches into a customer setup > that needs to run MST". I'm not familiar with the MST-PVST interaction, but if it's MST-RST, you should be able to acheive this. Make sure all of your MST bridges have non-minimal priority and have one (or more) RST bridges, outside of the MST region, have minimal priority. All of your MST bridges should compute instance, internal, and common root paths. The common spanning-tree roots should appear as the RST bridges. This is undoubtedly complicated by having customer-facing ports speak spanning-tree, and that very well may limit your flexability. We have the luxury of running bpdu-guard on all customer-facing switchports because no one is permitted to have a downstream topology that we don't manage. -- Ross Vandegrift [email protected] "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
