On Wed, Jul 23, 2008 at 11:54 AM, Phil Mayers <[EMAIL PROTECTED]> wrote: >> <list of points why STP shouldn't interact> > > ...the key thing being "should not", rather than "will not". Using an > entirely different protocol protects to a degree against human or machine > error e.g. forgetting the bpduguard config.
I agree. It's an extra protection that doesn't hurt... but I prefer to do bpudfilter, as the customer won't interfere with our STP and vice-versa. spanning-tree portfast bpdufilter default (or something like that) is a good tool do impose that beyond normal human error (forgetting to insert a command) but not advanced human error (configuring a customer interface as a backbone interface, for instance). >> I have never seen the point in more STP-like protocols when you can >> configure 802.1w or 1s w/ 1w to converge just as quickly with uniform >> support on all platforms to boot. EAPS does not offer any benefits and in >> fact it offer serious limitations thanks to its infancy. Every vendor has >> interpreted RFC 3619 differently since it was published nearly 5 years ago. >> For example Pannaway supports EAPS but their implementation is limited to >> not allowing EAPS rings to cross VLANs. That's a serious design limitation. > > We've tuned metro rings for 100ms convergence. I've *never* seen STP come > anywhere even close to that, and I frankly doubt it has the capability. It hasn't, and we discovered that the bad way, with a loop that took us a painful downtime. And that's why we are looking at non-standard ring protocols, not because our customers also use STP. One point that could be argued, is what would be the performance of Rapid PVST+ or their IEEE counterparts on a ring-only topology. > 802.1s is (IMNSHO) a bad joke. There are topologies where it's not just > worse than PVST, it's actively harmful. This would be significantly > alleviated if: > * Cisco could run >1 MST "process" > * 802.1s had some way of versioning the config, as opposed to breaking the > 802.1s domain into pieces every time you update the config (or mandating you > decide on vlan->instance mappings on day 0 and never change it - yeah, > right...) We tried to migrate to MST, but just couldn't find a way to migrate gradually from Rapid PVST+. > EAPS (and Foundry MRP) aren't universal solutions, but correctly applied > they bring significant benefits in my experience. Also in the market, Allied Telesis has EPSR or something like that. It would be a Good Thing if all those Ethernet ring protocols were replaced by a standard one, but that doesn't prevent a network from running different rings with different vendors, as they all provide similar performance. > When you say L2VPN, you mean point-to-point? What about multipoint e.g. > VPLS? It's difficult to see how you could avoid MAC learning in a multipoint > case. > > ...which is one reason I prefer L3VPNs, but there's a market for L2VPN. I second that. Rubens _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
