[EMAIL PROTECTED] wrote:
The fact that REP and EAPS are explicitly *not* compatible with regular IEEE spanning tree is one of the great attractions of these protocols. This means that a customer who sends STP traffic into your network can *not* influence your ring topology/failover.
Honestly this is a moot point anyway because only a mis-configured network would ever allow a customer to interact with the SP's STP. If a SP is dropping MetroE at the edge without bpdufilter enabled then something is seriously wrong. If the SP is doing L2VPN then dot1g-tunnel and L2PT take care of inhibiting interaction between the CE and PE with STP. Otherwise in all other cases the SP should explicitly enabled bpdufilter on all Ethernet CE-facing interfaces as part of the standard template that a SP deploys.
Additionally, REP and EAPS are explicitly made for a ring architecture, and can therefore be made simpler and/or converge more rapidly.
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 have lots of EAPS rings. It works for us. We might be interested in using ME3400 with REP for the same type of rings if it had decent CAM size. Unfortunately, it doesn't - 8K MAC addresses is uncomfortably close to the number of MAC addresses we already have in many of our rings.
Are you learning customer MACs for the service you're offering? That would be the case if you're simply transporting PtP VLANs. However if you're doing L2VPN or dot1q-tunnels then you shouldn't be learning MACs.
Justin _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
