Redundant Links the Quick and Dirty Way: SLA Monitoring on Cisco ASA

This topic is old news, but always a good thing to know if you have a constrained budget and limited time to make your network a little more robust. Do you have executives screaming at you because the internet is down and your business is losing tons of revenue by the minute because your services are hosted in the cloud? Then implement redundant links to the internet!

Many small branch offices don’t have redundant links. If those small branches don’t warrant redundant links, you can pretty much bet they don’t have a dedicated router (or pair of routers) either. More commonly, a firewall is used as the termination point for the connection to the Wild, Wild Internet of Things. This is perfectly fine for a small branch of part an organization that doesn’t need to scale quickly (in contrast, see: DMVPN for quick scaling), but once a branch scales beyond “small”, redundant internet links from different ISPs are absolutely necessary. With more and more services moving to a cloud-based platform, business requirements demand uninterrupted access to the internet.

A common firewall platform is the Cisco ASA, and there is a quick and easy way to achieve ISP redundancy using a feature called SLA monitoring.

When you configure a primary internet link connected to your ASA, you configure a default static route. This route is intended for all traffic with a destination IP address that is not in your routing table to flow to. The next-hop of the route points to your primary ISP gateway.


However, static routes are manual entries. In order to fail over to a backup link, the default static route would need to be manually changed to take priority over the primary default route. Moreover, there is no inherent mechanism to determine if a static route is up or down since it is not a dynamic routing protocol. Static routes remain in the routing table even if the next-hop gateway is unavailable! The only time a static route is removed from the routing table is if the associated interface’s link-state goes into a down state. So what happens if the ISP gateway goes down, or if problems occur on your primary ISP’s network? This is where SLA Monitoring comes in.

The SLA Monitoring feature associates a static route with a monitoring target. ICMP echo requests get sent to the target over the specified interface. If the monitored IP is unreachable for a specified amount of time, the static route is removed from the routing table, and the backup route can take over. Once the target becomes reachable from the primary interface again, the primary default route is inserted back into the routing table.


IMPORTANT NOTE: This is a viable solution for outbound traffic from your internal network. However, if you are hosting services that need to be reachable from the internet after a failure (email, web services, etc.), a more advanced solution needs to be put in place. If your primary connection fails, and your services are using public IP addresses from your primary provider, those services are no longer available when the backup takes over. A solution like BGP peering would need to be put in place in order to advertise your public IP space over both internet links — this is a topic for another post.

How to Configure IP SLA

So now that you know what the feature does, how do you implement it?

1. sla monitor sla_id

This configures the monitor process where you specify the parameters to be tracked.

2. type echo protocol ipIcmpEcho target_ip interface if_name

This configures the specific IP address that will be tracked for the monitoring process set up in step 1. The target_ip argument should be an IP address that can be reached from the interface specified in the if_name argument. For example, if you are setting up redundant internet links, you can do something like this for your primary link:

type echo protocol ipIcmpEcho interface outside is a public DNS server which is reachable from the primary interface outside, but the IP address can be any public IP which you see as critical.

3. sla monitor schedule sla_id life forever start-time now

This schedules the monitoring process. The command above is the typical use-case, but it is possible to schedule the monitoring process to begin at a later time and to only occur at specified times. Most of the time, you will want the process to run for an unspecified amount of time and start now. For more information on other options, please see the ASA Configuration Guide.

4. track track_id rtr sla_id reachability

This associates a tracked static route with the SLA monitoring process that was defined in steps 1-3. track_id is a number you assign with this command, while sla_id is the number you chose in step 1.

5. route if_name dest_ip mask gateway_ip track track_id

There are a lot of arguments here, but it is just your standard static routing configuration with the track argument added onto the end. This command defines the static route to be installed in the routing table while the tracked object is reachable. In other words, this static route should be your primary default route. For example, if I have an interface outside with an IP address, a gateway IP of, and a track_id of 1, the resulting command is:

route outside track 1

If my monitored target IP becomes unreachable, this route will be removed from the routing table. That means we need to have a backup default route – using our backup interface – with a higher administrative distance. For example:

route backup 2

I chose 2 as the administrative distance here because it is higher than the default of 1 (which your primary link is using) and lower than 5, which is the AD for an EIGRP summary route. If you’re not using EIGRP or another routing protocol, then this number is arbitrary, but using 2 is still a good practice.

Now you’re all set! If the target IP of the monitoring process becomes unreachable, then the primary default route will be removed, and the backup default route will take over.

Hopefully that makes sense! If you have any comments or questions, please post a comment, email me, or tweet me!

The Best Way To Learn: While Having Fun

If you’ve ever read a white paper, a validated design guide, an RFC, or any other technical documents out there, then you know that although they are rich in content they can be pretty dry reads. After a long, hard day at work, the words start to blur together and acronyms begin to take on a whole new meaning — side note: my favorite TLA is TLA. The documents previously mentioned are absolutely necessary to read, but I guarantee you’ll go crazy if that’s all you do. There are alternative ways to learn skills applicable to your profession.

We all have external interfaces to upload data directly to the brain, right?

If there’s something you want to learn, try to make it interesting! Try to combine your new learning path with a hobby or something else that genuinely engages you.

I know I need to learn Python because that’s where networking is going. Automating redundant tasks leaves more free time for the cool projects that really interest you. Python will enable that. “But I’m a network engineer, not a code monkey; writing scripts sounds so boring!” So make it engaging.

I watched a TED talk about flying robots about a year ago, and it amazed me how these robots could be programmed to follow a certain set of rules, even working together as a team, to accomplish a task. There are so many practical applications that can be realized with this technology, and it genuinely piqued my interest. But how do they do it? Well, it turns out that one of the ways to control these robots is to use Python!

In this day and age, there is a wealth of information available to us at our fingertips. I came across a platform called, which is a collection of universities that have gotten together to provide their coursework online, for free. MIT, Berkeley, Harvard, Cornell, Columbia, just to name a few. These are respected universities that charge an arm and a leg to take their courses. The courses offered range from Arts & Literature to The Sciences. One of the courses they offer is Autonomous Navigation for Flying Robots, which teaches how to use the data gathered by the plethora of sensors on a common flying robot, the Parrot AR Drone, to control its behavior with Python scripts. So far, the course is fantastic.

So that’s how I’m learning Python. It won’t teach me everything I need to know about the language, but it will give me a great start to learn the basics and get comfortable with it. If I pick up a new hobby at the same time, then that’s even better!

 If you’re interested in the course, check out the link I posted above. I think you can still register for it. The 3rd week is about to start, but you should be able to catch up pretty quickly.

The hardest part about learning something is taking that first step. Once the foundation is there, building on top of it is a piece of cake.

Network Services – Consolidation Versus Integration

This post comes out of a conversation I had around Cisco’s Identity Services Engine, and I think it’s an important one to have. I gave a presentation on ISE, and a question came up around filtering web content by categories (social media, YouTube, and the like). This is a function of another Cisco product, Ironport, a dedicated appliance web proxy/filter. ISE can’t do this, so why not consolidate Ironport into ISE? This is definitely a valid question given that ISE controls access to resources on your network, so why not extend that to resources that are on the web? As I thought about it more, I wouldn’t want Ironport consolidated into ISE. Here’s why:

  • ISE is already doing a ton of work keeping track of sessions, ACLs, profiling, posture, and other ISE features. Add in web requests and proxying and you’re going to overload the nodes or limit how large the deployment can scale. Is limiting scalability worth the minor benefits of consolidation?
  • Don’t put all of your eggs in one basket! The more services located in one place, the more devastating a failure is. Even if you have high availability, if a node goes down because of process load it’s likely the secondary node will fail soon after due to the load being shifted from the primary node.
  • Troubleshooting. As noted earlier, ISE is already a complex beast. When troubleshooting in a pinch, you want to be able to solve a problem quickly. Try digging through authorization policies, ACLs on network access devices, communication errors between nodes, and anything else that can cause problems. Now add web content filtering on top of that. I would rather have the services separated so I know exactly where to look when something is wrong. Can’t get to a certain web site? Look at the Ironport appliance. Can’t get access to an internal resource? Look at ISE.

Now that’s not to say I’m not a fan of consolidation. Hypervisors and server virtualization are fantastic examples because they make applications more versatile and highly available, while at the same time lowering management overhead. Consolidation can definitely be a great thing when there is a good reason behind it. However, don’t consolidate just because that’s the buzz word of the week; make a conscious design decision and take the time to weigh the pros and cons.

What I would like to see is integration of ISE and Ironport, similar to how ISE and Prime Infrastructure are integrated. Allow the platforms to be independent, distributed entities while enhancing the functionality of each by sharing information between the two. For example, allow Ironport to use the granularity of ISE device/user profiling to create content filtering rules, but retain the ability to fall back on a set of rules in the event an ISE node is not responding for one reason or another (granted you may have bigger problems at that point, but it could also be as simple as a new firewall rule blocking communication between the two).

What do you think? Leave a comment or send me an email at to get the discussion started!

Keep an eye out for the second part of my ISE technical series on wireless deployments!