Dual ISP Redundancy: IP SLA, Boolean Object Tracking & Longest Match Routing

In dual ISP designs, some of us have enjoyed the benefits of having two or more ICMP IP SLA sessions with Boolean OR object tracking on Cisco IOS routers. The beauty of this configuration is that a Boolean OR tracking instance will declare a down state only when “both” IP SLA sessions stop receiving ping replies.

Unfortunately, when it comes to ASAs, this Boolean OR feature is not available.

In this post, I will first show you a dual ISP scenario on Cisco IOS routers with IP SLA and Boolean OR Tracking and then, I will show an equivalent configuration with similar functionality but based on Longest Match Routing on Cisco ASAs.

Are you ready? Let’s get started.

Dual ISP Redundancy Configuration on IOS Routers: IP SLA & Boolean Object Tracking

A very common application of IP SLA and tracking on Cisco routers is used in dual ISP designs. When a router links up to two ISPs, you want to router to detect when Internet access through ISP 1 goes down so the router can redirect Internet traffic over to ISP 2. In this design, your router monitors for ICMP reachability to at least two devices on the Internet located past your primary ISP.

If pings to one target host, let’s say 8.8.8.8, do not come back, but pings to the other host, let’s say 4.2.2.2, do still come back, you can say that something happened to that unresponsive host or in the transit path to/from that host; however, since your router is still receiving pings from the second host, IP routing through ISP 1 must is still good. There’s no need to fail over to the second ISP.

In the situation when both pings stop coming back, it is likely that something happened to ISP 1. Either the circuit is down or there is a routing problem on the ISP 1 network. Keep in mind that although other problems can cause this failure, they’re very unlikely.

Here’s a summary of the operations:

• The router is configured with two IP SLA sessions. Each IP SLA session pings a reliable host on the Internet: Google DNS at 8.8.8.8 and Level 3 DNS at 4.2.2.2. Traffic to these two hosts must be forced out the interface to ISP 1.
• Two tracking instances are configured to monitor the up-down state of each IP SLA. One tracking instance per IP SLA session.
• A Boolean OR tracking instance is configured to combine the two previously configured tracking instances.

What’s important with this configuration is that the Boolean OR tracking will declare its state as down when “both” child tracking instances are down. If one child tracking remains up, the Boolean OR tracking state remains as up.

As a side note, a Boolean AND tracking will report a down state when any of the child tracking instances goes down.

Sample Configuration

The lines below show the basic IP SLA Configuration needed to have the router ping 8.8.8.8 and 4.2.2.2 with a source IP of 10.1.1.1, the IP assigned to G0/0 to ISP 1.

ip sla 1
 icmp-echo 8.8.8.8 source-ip 10.1.1.1
 exit
ip sla schedule 1 life forever start-time now

ip sla 2
 icmp-echo 4.2.2.2 source-ip 10.1.1.1
 exit
ip sla schedule 2 life forever start-time now

Next, you’ll find the Object Tracking configuration that will monitor the IP SLA sessions configured above. Track 1 monitors IP SLA 1 and track 2 monitors IP SLA 2.

track 1 ip sla 1 reachability
 exit

track 2 ip sla 2 reachability
 exit

Boolean OR track 3 monitors track 1 and 2. For track 3 to declare a down state, “both” track 1 and 2 should be in a down state.

track 3 list boolean or
 object 1
 object 2
 exit

Configure a local route policy to force the router’s ICMP packets out ISP 1 and ONLY ISP 1.

• Notice that the access list matches packets sourced from 10.1.1.1 and destined to 8.8.8.8 and 4.2.2.2 as configured on IP SLA 1 and 2 above.
• The route policy sets a next hop is 10.1.1.2, which is the edge router on ISP 1.

ip access-list extended G00-ICMP-TO-DNS-SERVERS
 permit icmp host 10.1.1.1 host 8.8.8.8 echo
 permit icmp host 10.1.1.1 host 4.2.2.2 echo
 exit

route-map LOCAL-POLICY permit 10
 match ip address G00-ICMP-TO-DNS-SERVER
 set ip next-hop 10.1.1.2
 exit

ip local policy route-map LOCAL-POLICY

If the G0/0 interface were to go down, the connected route to 10.1.1.0 /30 will be removed from the routing table, and the default route named BACKUP-ISP (shown below) will be installed. As a result, IP SLA ICMP packets will go out to ISP 2 and potentially the router will start receiving ICMP replies.

Remember, you only want IP SLA ICMP packets to go out ISP 1 because you want to track Internet access over ISP 1. If ICMP replies to two reliable hosts stop coming in over ISP 1’s connection, you can assume that something happened in the transit path through ISP 1. This is the key.

When interface G0/0 comes up, the router installs 10.1.1.0 /30 in the routing table as a “connected” route. A connected route has an administrative distance (AD) of 0. When that interface goes down, 10.1.1.0 /30 is removed and if you have a static route to the same subnet of 10.1.1.0 /30, that static route would be installed in the routing table. Remember that a static route has a default administrative distance of 1.

So, to blackhole traffic to 10.1.1.2 when G0/0 goes down, configure a static route for 10.1.1.0 /30 to Null0. Packets directed to 10.1.1.2 will be dropped by this static route.

ip route 10.1.1.0 255.255.255.252 Null0

Lastly, configure static default routes. The PRIMARY-ISP route with a default administrative distance of 1 will be installed on the routing table only when track 3’s state is UP.

When track 3’s state changes to down, the PRIMARY-ISP static default will be uninstalled from the routing table and the floating static default named BACKUP-ISP with an AD of 5 will be installed in the routing table.

ip route 0.0.0.0 0.0.0.0 10.1.1.2 track 3 name PRIMARY-ISP
ip route 0.0.0.0 0.0.0.0 10.2.2.2 5 name BACKUP-ISP

At this point, all traffic is sent to ISP 2 and failover occurs successfully.

When the outage on the ISP 1 side is fixed and ICMP replies start to come back, track 1 and/or 2 will come back up, which in turn brings track 3 up, and the PRIMARY-ISP static default with an AD of 1 gets installed back on the routing table.

All outbound traffic is then redirected back to ISP 1.

Now, can we implement IP SLA with Boolean object tracking on the ASA?

Dual ISP Redundancy Configuration on ASA: IP SLA, Object Tracking & Longest Match Routing

As you may know, the ASA platform does not support Boolean Object Tracking. ASAs support IP SLA and object tracking, but no boolean AND/OR object tracking.

Now, on the ASA, how can you reliably monitor two hosts on the Internet over ISP 1 and failover to ISP 2 when ISP 1 fails?

Longest match routing would help when combined with dual IP SLA sessions monitored by object tracking.

Let’s take a look at how this works altogether on the following sample configuration.

Sample Configuration

First, let’s configure the interfaces on the ASA. Notice their names ISP1 and ISP2.

interface GigabitEthernet0/0
 nameif ISP1
 security-level 0
 ip address 10.1.1.1 255.255.255.252
 no shutdown
 exit

interface GigabitEthernet0/2
 nameif ISP2
 security-level 0
 ip address 10.2.2.1 255.255.255.252
 no shutdown
 exit

Configure IP SLA to two reliable Internet hosts and their respective object tracking instances. In this case, we’re still using the same DNS servers: 8.8.8.8 and 4.2.2.2.

sla monitor 1
 type echo protocol ipIcmpEcho 8.8.8.8 interface ISP1
 exit

sla monitor schedule 1 life forever start-time now

track 1 rtr 1 reachability

sla monitor 2
 type echo protocol ipIcmpEcho 4.2.2.2 interface ISP1
 exit

sla monitor schedule 2 life forever start-time now

track 2 rtr 2 reachability

Now, you need to make sure that all traffic to 8.8.8.8 and 4.2.2.2 is always sent through ISP 1, so you need to configure two static routes forcing traffic to those target hosts out ISP 1. In addition, when IP SLA starts, if there are no routes to 8.8.8.8 and 4.2.2.2, IP SLA is going to fail. Remember that at this point there’s no default route.

route ISP1 8.8.8.8 255.255.255.255 10.1.1.2

route ISP1 4.2.2.2 255.255.255.255 10.1.1.2

For Internet access, the typical configuration uses two default routes. A static default route to ISP 1 associated to track 1 and a floating default route with a higher AD that’ll kick in when track 1’s is down.

route ISP1 0.0.0.0 0.0.0.0 10.1.1.2 track 1

route ISP2 0.0.0.0 0.0.0.0 10.2.2.2 5

Notice that you can use either track 1 or track 2. One at a time. The problem here is that if there’s a, let’s say, 10-second service interruption to the host your router is pinging and ICMP replies stop from coming back, the default route to ISP 2 with AD 5 will be installed temporarily until ping replies start coming back soon after. This situation results in default route flapping (ISP 1 to ISP 2 and then back to ISP 1) potentially breaking active user sessions several times during the day.

Sometimes, ICMP replies don’t make it back for a moment and this results in route flapping.

So, what could you do? You could break up the default route into two. One route represents the first half of the IP address space and the other route the second half. These two routes will be tied to track 1. In addition to these two routes, you should also configure a default route but this time associated to track 2.

route ISP1 0.0.0.0 128.0.0.0 10.1.1.2 track 1

route ISP1 128.0.0.0 128.0.0.0 10.1.1.2 track 1

route ISP1 0.0.0.0 0.0.0.0 10.1.1.2 track 2

These three routes will be installed on the routing table. Traffic will be routed using the longest match routes, 0.0.0.0/1 and 128.0.0.0/1, and not the default route. When track 1’s state goes down, either briefly or permanently, these two longest-match routes will become invalid and be withdrawn from the routing table.

Since track 1’s state is down, the default route takes over and therefore, Internet traffic will still be routed to ISP 1 using that default route. There won’t be a need to flap over ISP 2 anymore!

Even it track 1’s state is down and then quickly back up, Internet traffic won’t flap over to ISP 2 because the default route to ISP 1 takes over momentarily.

If track 1 and track 2 were to go down because the circuit is down or there’s a routing issue on ISP 1, the three routes above tied to tracks 1 and 2 will be withdrawn from the routing table and the backup default route with an AD of 5 would take over. As a result, Internet traffic resumes but over ISP 2.

route ISP2 0.0.0.0 0.0.0.0 10.2.2.2 5

Keep in mind that because this backup route is installed in the routing table, pings to 8.8.8.8 and 4.2.2.2 could resume over ISP 2. This is why you need to make sure that you have two static host routes for these two hosts pointing to the next hop on ISP 1.

Summary

As you can see, Cisco routers and ASAs support IP SLA and Object Tracking; however, IOS routers support Boolean Object Tracking whereas ASAs don’t.

So, on ASAs, because they perform NAT and keep a state of TCP, UDP, and ICMP connections per interface, you can resort to using Longest Match Routing to avoid default route flapping from the primary interface to the secondary and back. Route flapping can result in connection drops.

I hope you enjoyed this post. Remember, there are different ways to skin the cat. My take on this post is just one of them. Please, let me know in the comments below if you have any questions or other suggestions that could enhance these configurations.

Cheers.