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.
Getting CCNA or CCNP Certified?
Self-paced Books. On-demand Courses. Practice Tests.
Sign up for a 10-day free trial with unlimited access!
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.
This is just another fantastic how-to guide on IP SLA, Sir Alirio did a very wonderful job with the design and the configuration. I have been able to do the lab successfully and tested out the failover using eve-ng. I will recommend every engineer to take this wonderful site very seriously as it contains very easy to follow and amazing network design and real-life scenario that is very hard to come by.
Thank you always for the great contribution you are doing for the community, Sir Alirio.
Thank you
Ben
Thank you, Ben! Due to the lack of Boolean Object Tracking support on the ASA, combining IP SLA with Object Tracking and Longest Match Routing is one way to monitor two reliable Internet hosts to failover when needed. Keep on practicing!
Saludos Alirio,
It’s good to see you here and to have this informative blog about the networks that is your specialty, an excellent initiative, a big hug chamo, and I hope to continue keeping in touch, greetings to the family.
I’m glad you found this article on LinkedIn. Yes, routing and switching are my specialty. In this case, I wanted to provide a monitoring and failover design with two ISPs and no BGP. Thanks for your comment. Cheers.
Great post. Have you ever tried to use track with EEM , for example to send email notifications from cisco router just in case that track (ip sla state ) is down.
BR
Thank you! I actually did! Years ago, on a DMVPN implementation, I configured an EEM script to monitor the up or down syslog message and then send an email to the IT department’s generic email account. I should probably create a post with that configuration. Thanks for your comment.
Thanks for a very informative post. How would you implement IP SLA & Boolean Object Tracking with 3 ISPs?
Mi Mike. With three ISPs, you’d need to split the default even further and use more tracking objects. With one tracking object per ISP, it would look like this:
route ISP1 0.0.0.0 192.0.0.0 10.1.1.2 track 1
route ISP1 64.0.0.0 192.0.0.0 10.1.1.2 track 1
route ISP1 128.0.0.0 192.0.0.0 10.1.1.2 track 1
route ISP1 192.0.0.0 192.0.0.0 10.1.1.2 track 1
route ISP2 0.0.0.0 128.0.0.0 10.2.2.2 track 2
route ISP2 128.0.0.0 128.0.0.0 10.2.2.2 track 2
route ISP3 0.0.0.0 0.0.0.0 10.3.3.2
With two tracking objects per ISP, the design would work but it’d get more complicated since you’d need to break the default route even further.