backup static route -- not a default route

[jasonrpell20]

Here's the scenario:

I have an L3 switch that connects to an ASA then to a router that  gets to the internet.  The ASA controls all VPN connections so I have a  route set on the L3 switch to send connections to a specific IP to the  ASA, then the ASA will send it over the VPN.  This works fine.

Now, here's the change:

The vendor that this  connection goes to has a contract with us and is adding their own  dedicated internet connection to our network which has a VPN back to  their network.  This connection will go straight to the Vendor's own ASA  sitting at our data center and will then plug into that same L3 switch  as mentioned above.

What I need to do is use the  Vendor's dedicated line as the primary connection back to their network  and then use our currently setup VPN connection as the backup.  Anytime  the primary comes back up after being down, I need for it to take back  over as the primary route.

Some information on the network:

L3 Switch:

handles all internal routing and is the gateway for all users

Both the Company ASA and the Vendor ASA have internal IP Addresses that sit on Vlan1, which of course is the native Vlan for the L3 switch

Default Route:  ip route 0.0.0.0 0.0.0.0 10.1.1.2 (see diagram below)

What I have tried:

I have setup an IP SLA Monitoring with tracking and set the route to populate if the destination can be pinged.  Here's the issue:  This is a route to a specific host, NOT the DEFAULT ROUTE, so when the primary route goes down, it should route to the Company ASA.  I implemented this, but then after the failover, there are false positives because the Track object is able to ping the other side out of the backup route.  So the reachability keeps going up, then down, then up, then down over and over.  Someone suggested using an ACL to block ICMP going out the backup route.  When I do this, then when it fails over to the backup and the primary comes back up, it never switches back to the primary.  Hope this all makes sense.

Here's a generic diagram with generic IPs:

L3 Switch ----------->(10.1.1.3) Vendor's ASA(198.200.1.1) ------>Vendor's dedicated line to their network (this should be the primary route)

(10.1.1.1)

(where all users gain access to Vendor ASA and Company Owned ASA)

|

|

(10.1.1.2)

Company Owned ASA (where the backup VPN is to get to the  Vendor, also the default route to how all users get out to the internet)

(199.200.1.1)

|

|

Router

|

Internet

Thanks for the help.

[IAN WHITMORE]

Can't you just use floating static routes? Just change the admin distance on the "backup" routes.

[jasonrpell20]

I should have added that into my description.  That would certainly be nice, but the problem is that should only test for next hop availability, correct?  What that doesn't do is ensure that there is a complete link from my network, to the vendor's network.  The next hop out either route sits right next to the L3 switch and chances of those ever going down are very slim.  Am I thinking right?  If floating static routes would work while testing a complete connection, please tell me how.  Thanks.

[IAN WHITMORE]

The flaoting statics would go on the L3 switch and the next hop would be the ASA. So point taken, it's improbable that the ASA will fail. So floating statics would only give you first hop redundancy but not far end redundancy over the internet....

Another option, but more complicated is routing protocols. The ASA can speak OSPF as can your L3 switch...a lot more complicated setup BUT dynamic and would work.

I'm thinkout (and typing) out loud. Sometimes I say silly things but it helps me think so bear with me

What if your provider talks OSPF over the internet between their ASA's and then you inject the OSPF routes into your L3 switch. Of course you might need to play with admin distance so that the OSPF routes are preferred. When the (if the) internet or line or provider ASA go down, the OSPF routes will be removed and you should go over your default link.

Or am I complicating thngs too much?

[jasonrpell20]

Left that part out too.  I doubt that Routing Protocols are an option.  Yes, that would actually simply things cause it would verify the routes for me, but most vendors don't agree to set this up.  Next?  ;-)

[IAN WHITMORE]

Er...help...I was looking at route maps but don't think there is anything that would help.

Last resort (for me) talk nicely to your provider.

[jasonrpell20]

Someone else I know actually just threw policy based routing, using route maps, as well and said to try this:

(the 200.1.1.1 IP is a hypothetical IP that sits inside the vendor's network--obviously NATted)

ip access-list extended PBR_ICMP_ACL

permit icmp any host 200.1.1.1 echo

route-map PBR_ICMP_RMAP permit 10

match ip address PBR_ICMP_ACL

set ip next-hop 10.1.1.3

route-map PBR_ICMP_RMAP permit 20

ip local policy route-map PBR_ICMP_RMAP

ip sla 1

icmp-echo 200.1.1.1 source-ip 10.1.1..1

ip sla schedule 1 life forever start-time now

track 1 ip sla 1 reachability

ip route 200.1.1.1 255.255.255.255 10.1.1.3 track 1

ip route 0.0.0.0 0.0.0.0 10.1.1.2

What are your thoughts?  Would it work?  I'm not familiar with this kind of setup so if you can provide a little more info on the route map stuff, that would be helpful for me to understand it.  Thanks.

[IAN WHITMORE]

OK. It's worth a try. Basically it's a combination of route map and floating static route idea. What your telling your L3 switch to do (via a local policy route map) is ping a host in your provider network and track that "pingability". If it pings then the route will be put in the routing table (kinda like a floating static), if not then it will be removed and you're left with your default. Sounds good in theory.

Now the choice of the "200.1.1.1" address is important. If it's a host in the vendor LAN it would be a bad choice 'cos any LAN issue could cause the route to change, but then a LAN issue would deem access via VPN to the LAN out anyway...vicious circle

So the obvious choice for the IP to check reachability on would be the provider ASA public IP address which should be pingable anyway for the VPN to come up.

All I can say is, give it a go and let me know.

[jasonrpell20]

Ok, in case someone else runs into  this issue, I verified 2 possible solutions, in no particular order.   It just depends on your scenario and what options are available to you:

Solution 1:  Policy-based routing with IP SLA tracking for 1 IP Address

Using  the above mentioned solution with a combination of policy based routing  with route maps and IP SLA monitoring.  This is good if there is only  one IP Address that is abled to be pinged at the other end.  This  ensures that all traffic equal to ICMP will only be sent out the  specified hop.  So if the tracked object is good, then the route with  the track object will stay in the routing table.  If not, then it will  be removed and use the default route.  When the tracked route comes back  up then it is put back in the routing table:

One  note.  I was told that policy based routing can become CPU intensive  with larger route-maps, but for what I need with only sending a ping out  a specific hop, then it doesn't do much to the CPU.

(the 200.1.1.1 IP is a hypothetical IP that sits inside the vendor's network--obviously NATted)

ip access-list extended PBR_ICMP_ACL

permit icmp any host 200.1.1.1 echo

route-map PBR_ICMP_RMAP permit 10

match ip address PBR_ICMP_ACL

set ip next-hop 10.1.1.3

route-map PBR_ICMP_RMAP permit 20

ip local policy route-map PBR_ICMP_RMAP

ip sla 1

icmp-echo 200.1.1.1 source-ip 10.1.1.1

ip sla schedule 1 life forever start-time now

track 1 ip sla 1 reachability

ip route 200.1.1.1 255.255.255.255 10.1.1.3 track 1

ip route 0.0.0.0 0.0.0.0 10.1.1.2

Solution 2:  IP SLA with 2 available IP Addresses on the Vendor side

This  uses IP SLA only and is less work on the CPU, but requires 2 IP  Addresses in order to make it work completely.  Two routes will be put  in place.  One will be a static route to the IP Address on the other end  only used for the ping test--not the destination used for hosts.  The  other route will have a track object based on the reachability of the  ping test but will be a route to the destination needed for the hosts.   This way the ping test is based on the one IP Address and always gets  sent out the correct hop.  The routing table will then add the correct  route only when the ping is good.  Easier seen in the config than words:

Host X on remote VPN subnet (primary route) = 200.1.1.1

Host Y on remote VPN subnet (ping test) = 200.1.1.2

Build the SLA, only pinging host Y:

ip sla 1 icmp-echo 200.1.1.2 source-ip 10.1.1.1

ip sla schedule 1 life forever start-time now

track 1 ip sla 1 reachability

Add the tracking route as primary to Host X

ip route 200.1.1.1 255.255.255.255 10.1.1.3 track 1

Then  add another route to always direct traffic for Host Y to the vendor ASA  (i.e. all your pings)… thus, once the vendor VPN is up, pings respond  and SLA returns successful

ip route 200.1.1.2 255.255.255.255 10.1.1.3

Follow that up with the default route as secondary that already exists…

ip route 0.0.0.0 0.0.0.0 10.1.1.2

I  have yet to apply this to production as I'm waiting for the vendor to  finish some work, but I setup a GNS3 lab with all real life IPs and  matching devices as close as possible and everything worked great in  both scenarios.  For the IP SLA ping frequency, I set it to 5 seconds on  both scenarios.

Hope this helps somebody!  It was cool to see it actually work in my lab with no flaws so far!!