iamjeffvader's studymotron and rantatorium

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

Aggregation:

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.

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
allow-ip-int-binding
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
address 10.10.10.10/24
vpls "routed vpls"

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

Troubleshooting:

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 10.10.10.143
PING 10.10.10.143 56 data bytes
64 bytes from 10.10.10.143: icmp_seq=1 ttl=64 time=0.150ms.
64 bytes from 10.10.10.143: icmp_seq=2 ttl=64 time=0.125ms.
^C
ping aborted by user
---- 10.10.10.143 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!