How would you use VPLS transport in L2 DCI?

One of the questions answered in my Data Center Interconnect webinar is: “what options do I have to build a layer-2 interconnect with transport technology X”, with X {dark-fiber, DWDM, SONET, pseudowire, VPLS, MPLS/VPN, IP}. VPLS is one of the tougher nuts to crack; it provides a switched LAN emulation, usually with no end-to-end spanning tree (which you wouldn’t want to have anyway).

Imagine the following simple scenario where we want to establish redundant connectivity between two data centers and the only transport technology we can get is VPLS (or some other Carrier Ethernet LAN service):

I could figure out two obvious ways of using VPLS:

  • Use it as an IP+MPLS subnet and run customer-side VPLS-over-MPLS, VPLS-over-MPLS-over-GRE (which makes no sense unless you need IPsec) or OTV over this subnet;
  • Run TRILL over VPLS.

Are there any others? Please tell me in the comments!

TRILL supports standard bridges and VLANs between RBridges and can thus work over VPLS service. FabricPath and Shortest Path Bridging (SPB; 802.1aq) require point-to-point links between FP/SPB-enabled switches and might work over EoMPLS/L2TPv3 pseudowires (depending on how transparent they are), but not over VPLS.


  1. Get two independent VPLS services (instances) and use them as you would two point to points. ;)
  2. Thought about that. How would you stop forwarding loops? With EoMPLS P2P you can bundle the two links in a (MC-)LAG (assuming the PW is truly transparent) to prevent loops. Can't do that with VPLS.
  3. What about running vPC or any flavor of multichassis etherchannel across it?
  4. See above. VPLS is not transparent enough.
  5. you got the icons?
  6. sorry, where I get the icons used
  7. Hi Ivan,

    I'm looking to do something very similar right now. One solution that I've found is to run VRRP over VPLS. You can short circuit the CE and PE functionality by tying the CE interface back into the PE / VPLS interface. That way you have a routable IP interface / sub-interface that will communicate VRRP over the VPLS.

    I was able to set this up with Brocade gear in a lab and it's working really well. Right now I have it working with LDP, but am hoping to utilize FRR over RSVP next week.

  8. If your DC edge boxes support PBB, you could use that. Probably will have to do some S-hooks (running cables between ports on the same box to access the PBB edge function). That'll five you enough transparency to run LAG.

    There's also L2TPv3.

    And, if by chance you additionally need some FC links between these same DCs, you could always use an excellent ex-Nortel's, now Ciena's OM-5130: in front of your DC edge switches. They'll do you fully transparent 1G Ethernet P2Ps and/or 1G FCs over your choice of fibre/Ethernet/IP.
  9. There is an upcoming solution called Routed-VPLS (R-VPLS) that runs with BGP- still in draft phase. This works very well for MC-LAG as it will avoid forwarding loops, duplicate frames, etc shortcomings of VPLS. Alcatel-Lucent boxes (proprietary) run this feature. We will be implementing it in near future.
  10. Maybe I can ask your opinion, the proliferation of terms confuses me, when I ask a SP rep, what they mean by Metro Ethernet, VPLS, Lan Extension, MPLS, L3VPN, L2VPN and finally MPLS/VPN, I never get an answer that I'm satisfied with.

    Perhaps its my lack of networking knowledge because I don't have a CCNP or CCIE.

    But I wanted what my Cisco rep calls a Extranet VPN. My SP rep says they can't deliver but they can deliver a L2 interface to my router on their CIU which is connected to their PE via VPLS, which is connected to the far end PE over L3VPN. This they call Metro Ethernet.

    So really all I wanted was my partners to connect to my central server cluster and have their traffic segregated from each other. But instead of solution I get sold acronyms?

    Thanks for all the information, I find your posts very informative.
  11. I think the best way to use VPLS for DCI is trunks from the access layer into PE's that can add a Q tag (QinQ for the 'VPLS VLAN' so that you don't have to build PW meshes per VLAN) before placing the traffic into the MPLS network. You can do this with ES modules but you need them on both sides of the PE. It looks a bit crazy when you start adding resilience with EEM etc, but this is certainly possible for multipoint VPLS.

    If you want point-to-point as in your diagram (2 DCs) then really you want to look at MLAG with pseudowires, as you said Ivan. The world is a lot simpler then. A question for you on the flip-side; If MC-LAG is the only option and you need multipoint (3 DCs)... are you restricted to controlling the network with inter-site STP?.... eurgh, that's somewhere I /never/ want to go.
  12. TRILL over an encapsulated multipoint WAN (like VPLS) brings interesting designs to mind. I'm thinking the network could be multi-homed without using multi-chassis technology and loop-free. It sounds too utopian to be true!
  13. Ah there goes me always thinking like the SP and not the 'customer'. I guess in that case my first paragraph is just explaining your VPLS-over-MPLS type setup.
  14. The world is a lot simpler with MC-LAG. A question for you on the flip-side; If MC-LAG is the only option and you need multipoint (3 DCs)... are you restricted to controlling the network with inter-site STP?.... eurgh, that's somewhere I /never/ want to go.
  15. Sorry to go slightly off-topic/on a tangent Ivan but...

    As you know, in a 2 DC environment, the world is a lot simpler with MC-LAG over pseudowires. A question for you on the flip-side; If MC-LAG is the only option and you need multipoint (3 DCs)... are you restricted to controlling the network with inter-site STP (.... eurgh, that's somewhere I /never/ want to go) or are there alternative ways to ensure a loop-free network in that situation?
  16. FabricPath, SPB and TRILL should work over (transparent enough) pseudowires.

    If you want to stay with "traditional" technologies, you have to choose between IP/MPLS-based solution or STP.
  17. It is true, it just has to be implemented.
  18. Interesting question, will cover it in one of the upcoming blog posts (but it may take a while).
Add comment