Can GRE interfaces be VRF aware?

darthnul · ‎09-04-2009

I have a 400+ site frame-relay/ATM WAN that will be migrating to IPSEC VPNs. The sites are currently divided into 4 different OSPF stub areas. I want to maintain the integrity of the stub areas during the migration so I can avoid re-addressing all the remote sites. I'll be going GRE over IPSEC with OSPF on the VPNs. For my test sites I just un-configured the frame-relay sub-interface on my hub router and created a GRE interface and addressed it like the deleted FR sub-interface. I don't want to do this for the rollout because the hub router is old and due to be replaced/retired. I thought of attaching 4 new routers (one for each area) to the existing hub router through some /30 subnets appropriately addressed for their areas (to maintain the old router's role as the OSPF ABR) and create the new GRE interfaces there, but it would be cleaner if I could do one or two new routers with a vrf for each area. Then I'll just make the new routers ABRs when the old hub goes away. Anybody do anything like this (or have a better idea)?

Thanks in advance.

Peter Paluch · ‎09-05-2009

Hi Joseph,

I do not fully understand the point of creating VRFs here. If you create a new VRF then you will have to run a separate OSPF process for it. Now if you will ever need one VRF to see routes from other VRF, you will have to redistribute between OSPF processes, leading to external OSPF routers instead of inter-area routes (at least in your particular case), and also, redistribution between different OSPF processes can be cumbersome.

Can you perhaps explain more what did you want to achieve by enclosing each area in a separate VRF? Is it not possible or sufficient to simple create areas per-interface for your ABRs?

Just to answer your question - the Tunnel interfaces are VRF-aware. There are two points to consider: first, in which VRF does the tunnel interface appear as an interface, and second, in which VRF should be used to look up the source and destination of the tunnel. The first point is determined by the usual "ip vrf forwarding" command, while the other is configured using the "tunnel vrf" statement.

Quoting from the IOS Interface and Hardware Component Command Reference:

The following example shows how to associate a VRF with a tunnel destination. The tunnel endpoint, 10.5.5.5 will be looked up in the blue VRF.

interface tunnel0

ip vrf forwarding green

ip address 10.3.3.3 255.255.255.0

tunnel source loop 0

tunnel destination 10.5.5.5

tunnel vrf blue

Best regards,

Peter

darthnul · ‎09-09-2009

Thanks for the response!

THis would not be a "normal" use of VRFs. I would achieve the functionality of the following by connecting one physical router instead of four routers and a switch:

1. Create four sub-interfaces on available Ethernet port of existing frame-relay hub router which is ABR for four stub areas.

2. connect to trunk port of ethernet switch with four VLANs.

3. Connect four routers (one for each OSPF area) to the switch.

4. Create GRE tunnels for each remote site as the site converts from frame-relay to GRE over IPSEC VPN.

I'm not sure OSPF would function correctly if I just connected a second router to the existing ABR and assigned GRE interfaces to the four different areas. WOuldn't multiple ABRs for stub areas cause problems in this arrangement? If the four routers were physically or logically separated, the inter-area routing would still only be happening on the original ABR. I think I'd also need four connections between the two routers (one for each area) and I think that would cause some confusion between the routers unless those link were going to different (physical or virtual) routers.

Joseph W. Doherty · ‎09-09-2009

Like Peter, don't see how VRF provides you benefit. Also, as far as I know, you should be able to use one or more ABRs. If you do, there's benefit to having them adjacent (OSPF neighbors) on the LAN within the same OSPF areas. (Yes, if both routers host the same OSPF areas, there might be four physical or virtual links between them. Works fine w/o VRF. I've done it with both physical interfaces and subinterfaces using VLANs.)

darthnul · ‎09-09-2009

Thanks!

I'll give it a shot. Unfortunately I can't test this in my lab first, so it's a bit scary...