Home > ALU Services > Using routed VPLS for aggregation and troubleshooting

Using routed VPLS for aggregation and troubleshooting

Everyone surely knows about SVIs, they’re great. They allow you to groom many physical links in to a subnet. If I want to do this on a Cisco that’s all very straightforward, it’s probably one of the first things you learn.  Not so easy on a 7750.

Because the 7750 is a service router it isn’t designed to operate as a closet switch. It’s a mean, lean provider router and has a specific purpose. One recent-ish development I came across was the routed VPLS solution.  It’s a simple concept, it’s easy to implement but it’s hardware specific.  You need to use IOM3 or IMMs to do it which can be sucky, especially if you need its functionality on something like an SR1.  This post will look at two scenarios: aggregation and troubleshooting


OK, I get a request in that a HA pair of voice devices need to be connected in.  They must be in the same subnet but they don’t support many features such as VRRP, LACP and I don’t want to do any pre aggregation because that adds extra points of failure, latency which we don’t want for the traffic type.  We can’t run any FHRP on the PE so we need to take everything in at layer 2 and have a logical binding to layer 3 in there somehow.  My immediate thoughts would be to use an SVI, it’s simple and well understood across operational teams. Unfortunately as we now know this isn’t supported on my 7750.  What about using group interfaces? This is where you can aggregate broadband subscribers to a single subnet from multiple MSANs, sounds positive. Unfortunately all testing indicates it’s not going to work, confirmed by the vendor TAC. What can we do then?  Didn’t I read something about binding a layer 2 service to a layer 3 interface?  Why yes I did. Enter rVPLS.

I need to take 4 connections from a centralized server HA pair and terminate them on a single IP address on the PE.  rVPLS allows me to do this by binding a VPLS service to a VPRN. It will look something like this physically.

rvpls aggregation

The first thing you need to do is create the services.  If we look at the VPLS first there are only a couple of commands needed outside of a standard configuration, we will put in some make believe SAPs too:

config service vpls 1234
service-name "routed vpls"
sap 1/1/1:100
sap 1/1/2:100
sap 2/1/2:100

That’s pretty much it for the VPLS. We need to bind it to our layer 3 interface and we’re done:

config service vprn 4321
interface "gateway" create
vpls "routed vpls"

By specifying vpls "routed vpls"  under the interface instead of a SAP or SDP allows  hosts on the VPLS to use as their gateway. It’s certainly elaborate compared to an SVI but I do like the concept, giving us more service flexibility.


Here we have a layer 2 broadband aggregation service, the MSAN (CO/FTTx) terminates on an IMM48 and for many reasons we may not have a layer 3 interface to ping from. This is the perfect time to use a routed VPLS if we need to test reachability.

This is a scenario I have used in lab work but never in production.  The reason I have not used it in a live environment is you have OAM commands available to carry out diagnostics (cpe ping etc) and therefore probably don’t need it.  Of course if you accidentally use an already allocated address it can be impacting to a customer.  Use this at your own peril.

So what is the setup?  We have a single physical interface to the MSAN from the PE carrying multiple services.  Each tagged service comes in to a distinct VPLS on the PE.  As this is the last point from the MPLS network to the end user it’s a good place to prove a problem off the core network and in to the access layer.


Our goal here is to configure an ‘interception point’ in to the layer 2 network so we may pin point the fault location further.

If we reuse the configuration from the aggregation example we would simply need to apply the  allow-ip-int-binding/service-name commands to the VPLS, create the random VPRN 4321 and set the service name under the VPRN interface, exactly as we did above. Basically this is allowing us to put an intermediate layer 3 pointer in to a layer 2 only service.  Once we have completed the configuration steps we can ping the home user.  Of course this could be filtered by the end user, the MSAN may have security measures but you get the point, the same logic applies to all media.

A:PE# ping router 4321
PING 56 data bytes
64 bytes from icmp_seq=1 ttl=64 time=0.150ms.
64 bytes from icmp_seq=2 ttl=64 time=0.125ms.
ping aborted by user
---- PING Statistics ----
2 packets transmitted, 2 packets received, 0.00% packet loss
round-trip min = 0.125ms, avg = 0.137ms, max = 0.150ms, stddev = 0.015ms

So you see we can use this to jump in the middle of PPP sessions to test the connection to the customer or upstream if the BRAS is off the MPLS network domain.  Added to that if we have a native ethernet network of 7750s, with no MPLS, then we can use this technique to pin point the problem area in the switched network.  I have no idea why you wouldn’t have MPLS if you splashed out on IMMs for your 7750s though! 😀

As a final example before I have some ice cream what if we sell a managed CE service but the core network is using a VPLS.  We could use CFM, Y.1731 to measure connectivity.  Maybe our end point CE doesn’t support these protocols but it does support IP SLA.  We could set an rVPLS interface on each PE and run a local IP SLA echo to measure connectivity in the event of an attachment circuit failure.


I have not tried it before but I think I might.  Maybe you know or want to try it for the craic yourself, race ye!

Categories: ALU Services
  1. Burak Dikici
    January 23, 2014 at 2:51 pm


    Could you share your experiences about connection configuration between Cisco switch and 7750 devices if have got an idea ? They have got different connection logic.

    • iamjeffvader
      January 23, 2014 at 3:11 pm

      Hi, what exactly do you mean? The only problems I have seen physically between them is autonegotiate is required between a 7750 and a 6500, it doesn’t like it when you use no auto/auto limited versus no negotiate on the Cisco.
      Also for Ciscos using 10/100 interfaces like a 3560 with a 7750 using an electrical SFP doesnt really work too well. I tend to have to connect the the 7750 to a 7210 and then on to the 3560/ISR, creating a null sap epipe between the two ports. That can be handy for sniffing anyway

  2. Raymond
    November 25, 2015 at 10:24 pm

    HI, Have you tried spoke-sdp on your vpls service or will it only work on sap?

  3. iamjeffvader
    December 10, 2015 at 6:12 pm

    Hi Raymond, it will work with SDP based VPLS as well, doesn’t need to be a SAP.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: