Static Route Tracking: ASA Appliance vs. IOS Router

A relatively new feature on the ASA Security appliance is static route tracking, introduced in OS7.2. When properly configured, this capability allows the use of a backup default route when, through continuous monitoring, the primary route is determined to be down. As we will discuss, this feature is also available for Cisco IOS routers. This blog will be the first in a series that compares differences in feature implementation between the ASA and the router.

First, let’s examine this feature implementation on an ASA appliance. The first component to be configured is the monitoring process which defines how the primary route will be tracked:
ciscoasa(config)# sla monitor sla_id
ciscoasa(config-sla-monitor)# type echo protocol ipIcmpEcho target_ip
interface if_name

The above configuration will, by default, send 1 echo packet every 60 seconds. This can be modified by specifying the num-packets and frequency parameters in the sla-monitor sub-configuration mode. This is next followed by the sla schedule global configuration command where the parameters typically entered start the monitoring immediately and continue it indefinitely.

Following the inception of the monitoring, the static route to be configured is associated with the monitoring process:
ciscoasa(config)# track track_id router sla_id reachability

Finally, we configure the primary route to be tracked: (AD – Administrative Distance)
ciscoasa(config)# route if_name1 dest_ip mask gateway_ip <AD> track

For the IOS router, the static route redundancy defined above is known as Reliable Static Route Backup using Object Tracking. The syntax used for configuring this feature is dependent on the level of operating system used. Prior to 12.3(14)T, the rtr command was used; afterward, this became ip sla monitor.This was further shortened to just ip sla in release 12.4(4)T. The number of options available in this router sub-configuration mode are too numerous to mention here; the guidelines mention a limitation of 2000 operations!

While the ASA implementation of static route tracking in this mode is limited to the use of ICMP, the corresponding router feature is much more robust including TCP and UDP-based protocol tests. Another key option available for the router but not the ASA is the inclusion of a configurable time threshold parameter which will cause not only a syslog event but also begin recording the monitor history when service deterioration is detected.

To finish the configuration steps provided above for either the ASA or the router implementation, a “floating static” route is added: (if_name2 is the secondary ISP interface)
ciscoasa(config)# route if_name2 dest_ip mask gateway_ip <AD>

The Admin Distance (AD) here is usually chosen to be a high value (> 200).

Author: Doug McKillip


In this article

Join the Conversation


  1. Josh Stroup Reply

    How do you configure the INBOUND traffic when using SLA route tracking?

  2. Doug McKillip Reply

    You don’t. This is strictly for an
    alternate default route for outbound

  3. Josh Stroup Reply

    Doug I understand that this is strictly for outbound traffic. But unless you only send data in one direction, you still have to deal with inbound traffic. How do you deal with inbound traffic?

  4. Doug McKillip Reply

    Since I still don’t understand your question completely, let me take a stab at it from two (2) perspectives:
    a) Inbound responses to connections initiated outbound
    b) Connections initiated inbound

    As to a), remember there is only one primary path; therefore, stateful
    firewall behavior should allow valid response traffic. If, however,
    there is a switchover in the middle of a connection, the stateful tables
    will show a violation and the connection will need to be re-initiated.
    The ASA has an Asymmetric Route Group feature in an Active-Active Failover setup to allow for this.

    As to b), while static route tracking for inbound connections COULD
    potentially be configured, I would consider it to be INFERIOR to a
    dynamic routing protocol because of slower convergence to the new

    Hope this helps,