Front-VRF and NAT

[AllertGen]

Hello, everyone.

At my router I have 2 ISP connections (Internet). And I'm trying to connect this router by 2 DmVPN clouds to my central Hub. Because I want them 2 works at the some time I put 1 of the interfaces (backup ISP) to the front-VRF (because both ISP gives me Internet access).

Now I'm trying to solve how to deal with NAT if one (main) ISP will fail. Route leaking from VRF to router doesn't works because it's a defaulte route (0.0.0.0 0.0.0.0 [GW]).

I also tryed to use route-map like this:

route-map NAT permit 10

 set ip next-hop verify-availability  [GW Main ISP] track #

route-map NAT permit 20

 set ip vrf [VRF] next-hop [GW Backup ISP]

But it doesn't works too. If track is down it doesn't try to use a 20 sequance. And I can't undestand why it can't.

So any ideas how to deal with NAT (I don't want to use EEM)?

Best Regard.

[Philip D'Ath]

I haven't tried this, but I reckon it would work

Create two loopback interfaces, one in each VRF.  Then create a two GRE tunnels, one in each VRF, and between the two loopback interfaces.  Understand that the two GRE tunnels are connected to each other.  What goes in one pops out of the other in the other VRF.

Now you have a tunnel from one vrf to another vrf.  Make your primary default route "tracked", and then put a more expensive static default via your new GRE tunnel.  The remote VRF will need to nat its local GRE tunnel to the VRF outside interface.  You wont be able to load the local subnet into that one or it will break DMVPN.

Another easier option is if you have two space physical Ethernet interfaces.  Connect them together via a physical cable.  Put each into a difference VRF and put a common /30 on it.  Repeat the idea for the tunnels.

If you post your current config I can probably help you a bit further along.

[AllertGen]

WOW!

It's a really creazy idea!

And I think it will work too. But it will take more CPU for transfering traffic and there will be really a lot of configuration lines (more points to make errors and harder to debug problems). I hoped that there is some more simple solution.

But thank you very much for this solution. At any rate it is interesting point of view.

My test configuration in attachment (of cource I'm doing tests before doing it at exploitation ;) ). At this test configuration I tryed to do it by leaking routing. But at the command "sh ip route" and "sh ip route vrf ###" there is no default routes at all.

At the soultion with route-map (as I listed above and without "ip route" commands) traffic can go to the internet only while track is up.

I'm also thinking to do it only by using a route-maps. But as I know VRF (or front-VRF) is more prefered for solutions with 2 internet ISPs.

Best Regards.

[Philip D'Ath]

I don't think the CPU overhead will be that high.  Remember when a packet is moved from one interface to another the packet data is not actually copied.  The layer 3 packet header is left unchanged.  The only thing that changes is the outer layer 2 frame, which then just contains a pointer to the static buffer.

But I do agree, lots of config!

Another approach I have used many times which works great is on the head end.  Create two tunnels, one for primary connections and one for secondary connections.  Now the really important bit - they must have different "tunnel source" addresses.  The two IP addresses can be in the same subnet (just use ip address xxx secondary on physical interface, or the standby command [even if you only have one router]).

Then on the spoke put in hard coded permanent routes.  So you route all traffic to the primary address out ISP1, and all traffic to the secondary out ISP2.  Make sure these are static "permanent" routes.

Then on the spoke you have two tunnels, primary and secondary, with the respective destinations.  No "ip sla" or anything needed then.  The great thing about this is the end to end connectivity over each path is permanently tested.  Spoke config is nice and short.

Then in your case, if you want to swing the default route for web browsing use something simple like "track 1 interface Tunnel10 ip routing".  Where Tunnel10 goes via the primary path.  Tunnel10 will only be up when it can build a VPN via the primary, and if that works you know the primary ISP is working.  If it can't, then you just withdrawl the default route.

So the default route failover is about 3 lines of config.

[AllertGen]

The configuration with permanent routes is not clear for me. Both my ISP gives me Internet access (not a VPLAN, IP VPN or MPLS). If I'll use just a "ip route" command for routing it will not work beacuse 2 tunnels has the same destination address but different source address.

If I'll leave it only by static ip routes it will try to use my primary ISP (if default routes will have a different metric like this:

ip route 0.0.0.0 0.0.0.0 [GW_ISP_1] 1 permanent

ip route 0.0.0.0 0.0.0.0 [GW_ISP_2] 2 permanent

) even with "source tunnel" command (yap, I did check it a long time ago and by a logic point of view it should be so). If I'll leave 2 ip routes (to each ISP) with the same metric router will start to use a L3 route balance so even with "source tunnel" comand there is high chance that a router can try to establish a tunnel via a different interface.

And I really need a default route because without it my clients can't go to the internet directly via a branch router.

So for this (I mean to establish tunnels from each interface) I did use a global route-maps. But just by using route-maps I had some strange situations (it didn't worked until there is no "ip route" commands and "sh dmvpn" showed that all my runnels at the IKE status but in fact all my tunnels worked well).

I heard that for separating interfaces with 2 internet ISP it's better to use VRF. And it really work well. But the only problem that is still no solved is access to the internet by a NAT (from a local branch office).

Best Regards.

[Philip D'Ath · Accepted solution]

No,no - on the head end you need two different IP addresses.  One for a tunnel to terminate primary connections, and one for a tunnel to terminate secondary connections.

Then on a spoke with two ISP connects you create a permanent static route  to the hub primary IP address via ISP1 and a permanent static IP address for the secondary hub IP address via the secondary ISP.

So on the hub you end up with:

ip route <primary hub ip> 255.255.255.255 <isp1> permanent
ip route <secondary hub ip> 255.255.255.255 <isp2> permanent

[AllertGen]

Hi, p.dath.

It will not work at my case because as you can see from my configuration I have 2 tunnels (30 and 130) that goes at the same hub (the same destination IP) but from different local ISP (tunnel source).

Best Regards.

[Philip D'Ath]

You're not understanding.  You configure two ip addresses on the hub.  Tunnel 30 uses one of those IP addresses and tunnel130 uses the other.

[AllertGen]

Ok, now I've got it. So I should buy one more IP address from my ISP for each hub. Well, it's a good solution, but I really hoped that Cisco devices has a more simple solution just by configuration devices.

Thank you very much.