Cisco ASA – SLA Monitoring

SHELDON
[Reciting a ditty as he walks down the stairs.]
Proxima Centauri’s the nearest star.
The celestial bodies that follow are:
Alpha Centauri A, Toli, Barnard’s Star,
Wolf 359, Laland 21185,
Sirius A, Sirius B, BL Ceti, UV Ceti,
Ross 154, Ross 248,
Epsilon Eridani, Lac 9352,
Ross 128, Procyon A…
Oh, darn! That’s wrong!
[Sheldon huffs, and climbs back up the stairs to start the recital all over again.]

[Cut to later. Sheldon reaches the ground floor on his second attempt.]
…EZ Aquarii A, EZ Aquarii B,
EZ Aquarii C, Procyon A.
Those are the stars that are nearest to me.
Tra La La and Fiddle Dee Dee.

– The Big Bang Theory

On The Big Bang Theory, the elevator in the apartment building has been broken for years. It’s one of the running gags on the show. Even if the elevator gets fixed someday, none of the regular characters would notice because they they just automatically take the stairs. That’s the main disadvantage of static routes (as opposed to dynamic routing protocols). You don’t automatically take the best route available. You just schlep up and down the stairs because you don’t know any better.

Static routes are manually entered into the routing table of the Cisco ASA. There is little overhead; no need to configure dynamic routing protocols, no neighbors to talk to, no routing updates to send and receive. The downside is, the routing table must be manually changed if there is a change in the routing.

SLA monitoring is a method of tracking whether or not a particular static route is available, and automatically removing that route from the routing table if it is not available. So what makes a route “available”? You set up an SLA process that monitors whether or not a particular IP address is reachable via ping. This can be the actual destination host, or an ISP’s server, or a router along the route that has good uptime and is fairly reliably pingable. Something that is a good indicator of whether or not you can reach your destination via this route.

You can tell the ASA how often to ping the monitored IP address, and you can also define how long to wait for a ping reply, and how many missed ping replies constitutes “unreachable”. Then you tie this SLA process with one or more static routes. As soon as the monitored IP address is “unreachable”, the routes that you’ve associated with the SLA process are removed from the routing table.

This is useful if you have multiple static routes to the same destination. The preferred route should be given a lower metric and also tied to an SLA track. You should give the less-preferred routes a higher metric so that they will only be used if the preferred route is not available. So what will happen is, the preferred route is placed in the routing table and remains in use until something gets buggered along the route and the SLA process cannot reach the monitored IP address. Then, if the monitored IP address is unpingable long enough for it to be deemed “unreachable”, the preferred route is removed from the routing table and is replaced with the less-preferred route. As soon as the monitored IP address becomes reachable again, the preferred route is inserted back into the routing table.

You can get set up some pretty complex route selection with multiple SLA processes, and with multiple routes tied to each SLA process.

So let’s see a simple example:

SLA Monitoring

SLA Monitoring

On my ASA, I’ve configured IP addresses on 3 interfaces. As soon as I’ve cabled up the interfaces to the subnets and brought the interfaces up, these directly-connected subnets are added to the ASA’s routing table and are designated with a C.

ciscoasa# sh ro

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

C    2.2.2.0 255.255.255.0 is directly connected, outside
C    5.5.5.0 255.255.255.0 is directly connected, redundantisp
C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    10.10.10.0 255.255.255.0 is directly connected, inside

I have 2 ISP connections:

  • The outside interface is connected to my primary ISP
  • The redundantISP interface is connected to my secondary ISP

Until I set up a default route, the ASA will only route traffic to these directly-connected subnets. 6.6.6.2 is a server that resides on a subnet several hops away.

ciscoasa# ping 6.6.6.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.2, timeout is 2 seconds:
No route to host 6.6.6.2

Success rate is 0 percent (0/1)

Once I add a default route (via the outside interface), I can ping 6.6.6.2

ciscoasa# conf t
ciscoasa(config)# route outside 0 0 2.2.2.2
ciscoasa(config)# sh ro

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 2.2.2.2 to network 0.0.0.0

C    2.2.2.0 255.255.255.0 is directly connected, outside
C    5.5.5.0 255.255.255.0 is directly connected, redundantisp
C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    10.10.10.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [1/0] via 2.2.2.2, outside
ciscoasa(config)# ping 6.6.6.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

I can add a second default route (via the redundantisp interface), with a higher metric:

ciscoasa(config)# route redundantisp 0 0 5.5.5.2 2
ciscoasa(config)# sh ro

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 2.2.2.2 to network 0.0.0.0

C    2.2.2.0 255.255.255.0 is directly connected, outside
C    5.5.5.0 255.255.255.0 is directly connected, redundantisp
C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    10.10.10.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [1/0] via 2.2.2.2, outside

The default route (via outside interface) is preferred because it has a lower metric, so it remains in the routing table. If the outside interface ever goes down, the redundant default route is placed in the routing table. I can simulate that by administratively shutting down the outside interface:

ciscoasa(config-if)# int g 0/0
ciscoasa(config-if)# shut
ciscoasa(config-if)# sh ro

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 5.5.5.2 to network 0.0.0.0

C    5.5.5.0 255.255.255.0 is directly connected, redundantisp
C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    10.10.10.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [2/0] via 5.5.5.2, redundantisp

And a ping to 6.6.6.2 still succeeds because the ASA send the ping traffic via the redundantISP interface.

ciscoasa(config-if)# ping 6.6.6.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

As soon as the outside interface comes back up, the preferred default route is inserted into the routing table again:

ciscoasa(config-if)# in g 0/0
ciscoasa(config-if)# no shut
ciscoasa(config-if)# sh ro

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 2.2.2.2 to network 0.0.0.0

C    2.2.2.0 255.255.255.0 is directly connected, outside
C    5.5.5.0 255.255.255.0 is directly connected, redundantisp
C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    10.10.10.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [1/0] via 2.2.2.2, outside

So, what if there is a problem with the primary ISP a hop or two away? The ASA will only know that its directly-connected links are up, and it will be unaware of the problem. It will continue to send traffic via the preferred default route. Unlike dynamic routing protocols, where routing updates can inform you of a connectivity problem, static routes are not removed from the routing table unless the connected link is down.

This is where SLA monitoring is useful.

Let’s start again, and remove those default routes. All the ASA knows how to reach is the directly-connected subnets.

ciscoasa(config)# no route outside 0 0 2.2.2.2 1
ciscoasa(config)# no route redundantisp 0 0 5.5.5.2 2
ciscoasa(config)# sh ro

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

C    2.2.2.0 255.255.255.0 is directly connected, outside
C    5.5.5.0 255.255.255.0 is directly connected, redundantisp
C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    10.10.10.0 255.255.255.0 is directly connected, inside
ciscoasa(config)# ping 6.6.6.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.2, timeout is 2 seconds:
No route to host 6.6.6.2

Now we will configure an SLA monitoring process that will ping 6.6.6.2 via the outside interface. I’ve used an SLA monitor ID of 55.

ciscoasa(config)# sla monitor 55
ciscoasa(config-sla-monitor)# type echo protocol ipIcmpEcho 6.6.6.2 interface outside
ciscoasa(config-sla-monitor-echo)# timeout 1000
ciscoasa(config-sla-monitor-echo)# frequency 3
ciscoasa(config-sla-monitor-echo)# sla monitor schedule 55 life forever start-time now

At this point, the monitored host starts receiving pings from the ASA. Now I’ll associate a tracking ID (1) with the SLA monitor ID (55). I’ll also add two routes. The preferred route is via the outside interface. it has a lower metric (1) and it is tied to track 1. The less-preferred route is via the redundant ISP interface, and it has a metric of 2.

ciscoasa(config)# track 1 rtr 55 reachability
ciscoasa(config)# route outside 0 0 2.2.2.2 1 track 1
ciscoasa(config)# route redundantisp 0 0 5.5.5.2 2

So now if that SLA monitoring process is unable to ping 6.6.6.2 via the outside interface, the ASA removes the tracked route from the routing table, and inserts the redundant default route via the redundantisp interface.

If 6.6.6.2 is reachable via the outside interface, the preferred route is in the routing table, designated with an S:

ciscoasa(config)# sh ro

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 2.2.2.2 to network 0.0.0.0

C    2.2.2.0 255.255.255.0 is directly connected, outside
C    5.5.5.0 255.255.255.0 is directly connected, redundantisp
C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    10.10.10.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [1/0] via 2.2.2.2, outside

As soon as I unplug the router a few hops away, the Cisco ASA misses 3 ping replies from 6.6.6.2 and removes the tracked route from its routing table. The less-preferred route is inserted in the routing table in its place.

ciscoasa(config)# sh ro

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 5.5.5.2 to network 0.0.0.0

C    2.2.2.0 255.255.255.0 is directly connected, outside
C    5.5.5.0 255.255.255.0 is directly connected, redundantisp
C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    10.10.10.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [2/0] via 5.5.5.2, redundantisp

I can link multiple static routes to this SLA process. All I have to do is add the static route to the routing table with the “track 1” parameter.

ciscoasa(config)# route outside 6.6.6.0 255.255.255.0 2.2.2.2 1 track 1
ciscoasa(config)# sh ru ro
route outside 0.0.0.0 0.0.0.0 2.2.2.2 1 track 1
route outside 6.6.6.0 255.255.255.0 2.2.2.2 1 track 1
route redundantisp 0.0.0.0 0.0.0.0 5.5.5.2 2
ciscoasa(config)# sh ro

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 2.2.2.2 to network 0.0.0.0

C    2.2.2.0 255.255.255.0 is directly connected, outside
C    5.5.5.0 255.255.255.0 is directly connected, redundantisp
S    6.6.6.0 255.255.255.0 [1/0] via 2.2.2.2, outside
C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    10.10.10.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [1/0] via 2.2.2.2, outside

If the SLA monitoring process cannot reach 6.6.6.2, it removes all the routes that are linked to track 1. If there is another candidate route (e.g. with a higher metric) for a route that is removed, this less-preferred route is inserted in the routing table. For example, the 6.6.6.0 route is removed, but there is no other route to replace it in the routing table. The 0.0.0.0 route (with metric 1) is removed and replaced with the less-preferred route with metric 2 (via the redundantisp interface).

ciscoasa(config)# sh ro

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 5.5.5.2 to network 0.0.0.0

C    2.2.2.0 255.255.255.0 is directly connected, outside
C    5.5.5.0 255.255.255.0 is directly connected, redundantisp
C    127.0.0.0 255.255.0.0 is directly connected, cplane
C    10.10.10.0 255.255.255.0 is directly connected, inside
S*   0.0.0.0 0.0.0.0 [2/0] via 5.5.5.2, redundantisp

Additional Information:

sla monitor command in the Cisco ASA 8.4 and 8.5 Command Reference.

sla monitor schedule command in the Cisco ASA 8.4 and 8.5 Command Reference.

track rtr command in the Cisco ASA 8.4 and 8.5 Command Reference.

shutdown command in the Cisco ASA 8.4 and 8.5 Command Reference.

ping command in the Cisco ASA 8.4 and 8.5 Command Reference.

show route command in the Cisco ASA 8.4 and 8.5 Command Reference.

route command in the Cisco ASA 8.4 and 8.5 Command Reference.

This entry was posted in geek, mecha, v4vendetta and tagged , , , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

3 Comments

  1. mochi
    Posted June 5, 2012 at 6:58 pm | Permalink

    How come you didn’t get an error when defining a default route with different interface? From cisco docs,

    “if you attempt to define a default route with a different interface than a previously defined default route, you receive the following message:

    “ERROR: Cannot add route entry, possible conflict with existing routes.”

    Does that only apply to equal cost static default routes?

  2. mochi
    Posted June 5, 2012 at 7:07 pm | Permalink

    Question about two equal cost static default routes.
    My setup is two asa devices with two static default routes (load balancing). No tracking setup.

    If one of the gateways goes down, that route should stay in the asa routing table. Will the asa attempt to keep sending out the route that went down because, it is less used ( the load balancing part ) and never reach its destination? Or is it still going to alternate between the broken and working route?

    Will setting up tracking help in this situation. From what I understand tracking is used to install a backup route if the active one goes down. But in this setup I already have my other route installed. Would it make sense to use tracking to just remove my broken route and install the backup route which would just be a copy of the 2nd route that I’m already using?

  3. gomjabbar
    Posted June 6, 2012 at 1:15 am | Permalink

    Hey mochi,

    Hope I can answer all those questions!

    Yes, tracking would help. The main reason you use SLA monitoring is to detect that a particular path to a destination is down, even though the next hop may be reachable. The ASA will not send packets out an interface if its interface is down, but what if the link is up? The ASA may not be aware that the gateway or something a hop or two further down the line is having a problem. Let’s say the next hop router is reachable, but not passing the traffic along, the ASA will still send the traffic to the next hop router. So you need some mechanism to tell the ASA to stop using that path to the destination.

    So I usually pick something other than the next hop router as the target for monitoring. Better use the gateway at the destination, or the ISP’s DNS server. That way, you are testing several hops down the path instead of just one hop.

    And yes, the default routes that get inserted into the routing table due to the SLA monitoring all have different metrics, so they do not “conflict”, so to speak. I suppose you could think of them as candidate default routes. Only one of them is in the routing table at any time.

    Thanks for visiting!

    GomJabbar

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*
*