VPLS, RSTP, Full Mesh Redundancy & duplicate packets

Dear all,

I have setup a MT lab using VM’s to model a planned deployment of an MPLS VPLS provider network.

It’s working, and working very well. BUT, I have had to join the PE’s into the same RSTP domain as the customer equipment - which I don’t like and I foresee this being a scalability and reliability issue.

Here’s the scenario:

Green links represent the customer bridged network (dotted = VPLS, solid = ethernet). Blank links represent the MPLS connections (not part of the customer’s bridge - just forwarding MPLS/VPLS packets as you would expect).
MPLS VPLS Lab.jpg
MPLS Cloud: I have 6 sites forming the MPLS cloud. Sites 1 and 4 have been setup with redundant PE’s. OSPF is running between the PE’s for IP routing. iBGP is setup between all PE’s for VPLS signalling - PE1a and PE1b are route reflectors for this purpose that all other PE’s peer with.

Customer VPLS: The customer wants redundant connectivity between their two offices connected to site’s 1 and 4 PE’s. Between sites 1 and 4 I have setup a full meshed VPLS configuration. VPLS’s are dynamically created (bgp-vpls) and split horizon is configured on the pseudo-wires. Customer has implemented two switches at each site connected to the two PE’s. RSTP has been configured in the customer switches SW1a SW1b SW4a and SW4b to prevent loops. SW1a has been nominated as the spanning tree root. Subsequently, the link between SW4a and SW4b transitions to a non-forwarding state resolving any loop. As per diagram below:
MPLS VPLS Lab 2.jpg
This was my original config. However, I found that when a customer sends an ethernet broadcast, it was being duplicated across the VPLS (I believe this is the expected result - http://forum.mikrotik.com/t/vpls-multihomming/34850/4). This in turn caused MAC learning issues at the customer switches. To fix it, I enabled RSTP on the PE’s on the bridge interfaces that connect the VPLS’s to the customer’s access port.

This fixed the issue of duplicates, resolved the MAC learning issues in customer switches, and in-fact it all works very well now. PE4a transitioned the VPLS to PE1b to a non-forwarding state, and same on PE4b to PE1b. As per diagram below:
MPLS VPLS Lab 3.jpg
BUT I really dislike this approach. First, it extends the customer STP into my PE’s - ie; the customer can affect how my PE forwards traffic. Second, the customer may be using some STP implementation that is not compatible with my own. Third, the customer can play with the STP settings which in turn affects how my PE’s behave (they could make me the root for example). And I’m sure there’s many other reasons why this is really bad.

So, is there an alternative?

Rich

Anybody?

Since you’re running an ethernet topology with redundant paths, you’ll have to have a loop prevention mechanism as you have implemented.

You might consider putting a switch at the customer endpoint that supports MSTP - it will allow you to segregate the customer STP domain from the provider domain.