I attended the packet pushers party on Friday 17th and managed to have some of my questions answered during what was a great show.

My current project is to provide L3 services into one of our sites where the incumbent requires their ip address space back in the near future. This results in the following scenario:-

• Take over customer L3 interfaces from the incumbent.
• Announce these ranges back to the incumbent via BGP.
• Start the migration from incumbent ip addressing to our own.
• Provide BGP transit to current customers.

VRF’s lend themselves to this scenario very well so is the obvious choice.

A VRF will be created for the legacy incumbent interfaces we will take over and we will redistribute these ranges into BGP and announce back to them. We only want to announce incumbents ranges back to them so again, a VRF makes the separation between the legacy and new easy to manage.

This leaves one issue. Instead of going out onto the Internet to come all the way back in via the incumbent to get to ip addresses we are ultimately using on our device, it would be easier for us to use our own links to get to them. This means looking at leaking IGP routes between the VRF and the global table.

Now, you may be thinking this is fairly easy but this is IOS XR. I spent several days asking some colleagues what the best and easiest options were and the consensus was to have 2 physical interfaces on the same device each in a seperate VRF and run a cable between them and create an IGP adjacency. This is so simple I couldn’t believe I hadn’t thought of it!

Something was still niggling at the back of my mind. The 2 interfaces and cable solution seemed like it was a work around rather than a well though out solution. I started to look at tagging ospf routes in the global table and VRF and then redistribute. This seemed far to complex to setup and troubleshoot should the need arise.

This led me to pose the question at the PP party “how do you redistribute ospf routes between VRF’s”. This led to the hosts advice of VASI (VRF Aware Service Interfaces). Now if you follow the link it makes references to requiring the services blade for the ASR but I have it on good authority that only firewall services using VASI need this.

The basic premise of VASI is that you can create interfaces in pairs ( VASI-left and VASI-right ) put them in different VRF’s and then create IGP adjacencies. This sounds exactly what I require!

I will post further updates as I start to implement this into our network.

A big thanks to @jlgaddis and @cloudtoad for alerting me to VASI which has now got me out of a hole and I no longer need to cheat by using a cable to connect to interfaces in seperate VRF’s to exchange routes.

UPDATE – 23/02/2012

It looks like VASI interfaces cannot be used for what I was looking for sadly.  They do not appear to be available on IOS XR 4.1.1.  There is, however, InterFlex links but on trying to use them for the above purpose @aakso is seeing the interflex_mgr crash out when trying to define the service-location.

I posted on the cisco-nsp mailing list and got a great response as below:-

”

In the VASI scenarios I’ve seen, BGP is used to send routes learned from the MP-BGP sessions to the the PE-CE BGP sessions and vice versa.  So, in essence, you have three different BGP domains, the PE-CE, the MP-BGP, and the inter-VASI.  In effect, you have two different “redistributions” going on.  This is the result of having the VASI interfaces “shimmed” between the real interfaces facing the CE and the P/PE MPLS core.

Since you don’t need the VASI construct as you are not trying to apply services to a label switched interface, I don’t think you need the complexity of what VASI introduces.  If you simply need to get routes from one VRF to another, I think that you should be able to do something like this:

router ospf 1

redistribute ospf 2 vrf bar

router ospf 2

redistribute ospf 1 vrf foo

I know that VRF aware redistribution is available in IOS, but not sure about XR (didn’t spend a lot of time hunting through the docs).  To me the downside of redistribution is that you end up with external routes but perhaps that’s not an issue in your environment.

Import/Export may seem like a pain, but I don’t think anymore so than mutual redistribution and the access-lists and/or tags to prevent loops.”