Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

ASA SLA Tracking w/ multiple icmp checks

I would like to setup a backup internet connection but I don't want the connection to failover if one IP address or sla monitor is down.  I would like at least two to fail before it goes down. The only way I can think of is the config below.  Is there an easier way?

route ouside 0.0.0.0 0.0.0.0 <isp1 route> 1 track 1

route ouside 0.0.0.0 0.0.0.0 <isp1 route> 2 track 2

route outside 0.0.0.0 0.0.0.0 <isp2 route> 254

sla monitor 101
   type echo protocol ipIcmpEcho 10.0.0.1 interface outside

   num-packets 3
   frequency 10

sla monitor 102
  type echo protocol ipIcmpEcho 10.0.0.2 interface outside
  num-packets 3
  frequency 10

sla monitor schedule 101 life forever start-time now

sla monitor schedule 102 life forever start-time now

track 1 rtr 101 reachability

track 2 rtr 102 reachability

14 REPLIES
Cisco Employee

Re: ASA SLA Tracking w/ multiple icmp checks

Unfortunately there is no feature to support a threshold of failed sla tracked router before failing over.

PK

New Member

Hi,I also have interest in

Hi,

I also have interest in this solution. Someone had successfully proposed solution?

Best regards.

New Member

For the scenario that a

For the scenario that a single ASA (or Active-Standby HA cluster) has two ISP uplinks, one as primary and the other as backup. We want to ensure the SLA check more than the direct connected GW. So we can just use one remote "TestTargetIP" (in my case, one hop before my remote ASA.) then use only single SLA monitor for that TestTargetIP and enter a host route for that TestTargetIP to the GW on primary link. If the primary link GW is reachable, the TestTargetIP host route will route through it and reach to the target. If there is a break from ISP1 to TestTargetIP, the SLA test will fail then it will take the floating static to secondary ISP gateway.

 

Assume TestTargetIP is 199.199.199.199, GW to ISP1 is 100.100.100.1 GW to ISP2 is 200.200.200.1

==== ASA config ===

sla monitor 1
 type echo protocol ipIcmpEcho 199.199.199.199 interface outside
 timeout 2000
 threshold 50
 frequency 3
sla monitor schedule 1 life forever start-time now

track 123 rtr 1 reachability

route outside 199.199.199.199 255.255.255.255 100.100.100.1  <= static route force 199.199.199.199 always exist via ISP1 (primary) gateway. ## Please pick a transit IP at one or two hops before your interested destination.


route outside 0.0.0.0 0.0.0.0 100.100.100.1 track 123
route outside-b 0.0.0.0 0.0.0.0 200.200.200.1 180

===========

If primary ISP1 cannot reach to your interested destination (detect by the reach-ability to the transit IP at 1 or 2 hop before it.) the tracked default route will be dropped and backup floating default route will be used.

 

I test this concept in my GNS3 lab. It works.

 

New Member

  I’ve tried all of these

  I’ve tried all of these options any haven’t gotten any of them to work.  But here is what I came up with that does seem to work really well.  You can ping two, four, or even more Internet hosts and only when all of them fail does the ASA failover to the backup ISP:

route outside 0.0.0.0 128.0.0.0 <primary gateway> 1 track 100

route outside 128.0.0.0 128.0.0.0 <primary gateway> 1 track 100

route outside 0.0.0.0 0.0.0.0 <primary gateway> 2 track 101

route outside-failover 0.0.0.0 0.0.0.0 <backup gateway> 254

track 100 rtr 100 reachability

track 101 rtr 101 reachability

sla monitor 100

 type echo protocol ipIcmpEcho 208.67.222.222 interface outside

 num-packets 3

 frequency 10

sla monitor 101

 type echo protocol ipIcmpEcho 8.8.8.8 interface outside

 num-packets 3

 frequency 9

sla monitor schedule 100 life forever start-time now

sla monitor schedule 101 life forever start-time now

  This way both 208.67.222.222 (OpenDNS) and 8.8.8.8 (Google DNS) have to be unreachable for the failover to occur from the primary Internet connection to the backup Internet connection.  You could even expand this out from pinging two Internet IP's to four.  Or using it to have more than one backup Internet connections for a failover of ISP 1 (maybe Fiber) to ISP 2 (for example cable) to ISP 3 (a Cradlepoint router using LTE/4G).

  You can test the failover pretty easily by creating two EC2 Instances on Amazon’s AWS cloud.  Use these two IP’s in the SLA Monitor commands.  Then you can use the Amazon firewall rules (or you can just start & stop the instances) to control the ICMP (ping) access to see how your ASA will failover if one or both of the Instances doesn’t ping.

  Here is what you will see in the routing table:

Track 100 up, Track 101 up:

Gateway of last resort is <primary ISP> to network 0.0.0.0

C    <Backup Interface> 255.255.255.0 is directly connected, outside-failover

C    <LAN Interface> 255.255.0.0 is directly connected, inside

C    <Primary ISP Interface> 255.255.255.240 is directly connected, outside

S    0.0.0.0 128.0.0.0 [1/0] via <Primary ISP Default Gateway>, outside

S*   0.0.0.0 0.0.0.0 [2/0] via <Primary ISP Default Gateway>, outside

S    128.0.0.0 128.0.0.0 [1/0] via <Primary ISP Default Gateway>, outside

Track 100 up, Track 101 down:

Gateway of last resort is <Backup ISP Default Gateway> to network 0.0.0.0

C    <Backup Interface> 255.255.255.0 is directly connected, outside-failover

C    <LAN Interface> 255.255.0.0 is directly connected, inside

C    <Primary ISP Interface> 255.255.255.240 is directly connected, outside

S    0.0.0.0 128.0.0.0 [1/0] via <Primary ISP Default Gateway>, outside

S*   0.0.0.0 0.0.0.0 [254/0] via <Backup ISP Default Gateway>, outside-failover

S    128.0.0.0 128.0.0.0 [1/0] via <Primary ISP Default Gateway>, outside

Track 100 down, Track 101 up:

Gateway of last resort is <Primary ISP Default Gateway> to network 0.0.0.0

C    <Backup Interface> 255.255.255.0 is directly connected, outside-failover

C    <LAN Interface> 255.255.0.0 is directly connected, inside

C    <Primary ISP Interface> 255.255.255.240 is directly connected, outside

S*   0.0.0.0 0.0.0.0 [2/0] via <Primary ISP Default Gateway>, outside

Track 100 down, Track 101 down:

Gateway of last resort is <Backup ISP Default Gateway> to network 0.0.0.0

C    <Backup Interface> 255.255.255.0 is directly connected, outside-failover

C    <LAN Interface> 255.255.0.0 is directly connected, inside

C    <Primary ISP Interface> 255.255.255.240 is directly connected, outside

S*   0.0.0.0 0.0.0.0 [254/0] via <Backup ISP Default Gateway>, outside-failover

  An even better option would be to configure two Raspberry Pi's in a cluster on the outside network of the ASA for the ASA to track with the SLA command.  Then those Raspberry Pi's can be configured so that they can ping any number of hosts and also connect to any number of web sites before signalling the ASA to failover to the backup Internet connection.  This gives a much more control over the failover process than just simple pings - even with the multiple pings allowed by the ASA configuration above.  And the redundant Raspberry Pi's means that even if one fails the ASA route tracking continues to work properly.  Note: You need either one extra static public IP for a single external Raspberry Pi or three extra static public IP's for a cluster of Pi's.  Please see http://www.icepts.com/cisco-asa-firewall-route-tracking-with-multiple-ips/

Dave

  

New Member

Yo, i've been trying to use

Yo, i've been trying to use this to monitor my branch offices connection fiber as it works point to point i dont have a next hop address, if the ISP is down i have to manually change to backup. instead of doing something so horrible i want to make it auto, instead of changing routes i want to disable interfaces: 

I have this setup at a branch if one router stops seeying the main office it shutdownss Interface to 192.168.x.x so the office stops trying to use that router the virtual ip 11.11.11.x goes from 2 to 17 (16 branches):

track 1 ip sla 1 reachability
interface GigabitEthernet0/0
ip address 11.11.11.98 255.255.255.0
glbp 10 ip 11.11.11.14
glbp 10 priority 150
glbp 10 preempt delay minimum 1
glbp 10 forwarder preempt delay minimum 1
duplex auto
speed auto
interface GigabitEthernet0/1
description Conexion Red Usuarios HiperOle
encapsulation dot1Q 100
ip address 192.168.14.2 255.255.255.0
ip helper-address 192.168.1.15
glbp 20 ip 192.168.14.1
glbp 20 priority 150
glbp 20 preempt delay minimum 1
glbp 20 load-balancing host-dependent
glbp 20 authentication text xxxx
glbp 20 forwarder preempt delay minimum 1
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip route 0.0.0.0 0.0.0.0 11.11.11.1
!
ip sla auto discovery
ip sla 1
icmp-echo 192.168.1.253
threshold 2
timeout 500
frequency 3
ip sla schedule 1 life forever start-time now
scheduler allocate 20000 1000
event manager applet AliveTrack
event track 1 state up
action 1.0 cli command "enable"
action 2.0 cli command "config t"
action 3.0 cli command "interface gigabitethernet0/1"
action 4.0 cli command "no shut"
action 5.0 cli command "end"
event manager applet DeadTrack
event track 1 state down
action 1.0 cli command "enable"
action 2.0 cli command "config t"
action 3.0 cli command "interface gigabitethernet0/1"
action 4.0 cli command "shutdown"
action 5.0 cli command "end"
!

Now with main office (11.11.11.1) i cant do something like that because some services connected to main router dont have contingency so i cant really shut down one router if the connection fails so i have two routers with same configuration if i will change it, so far this is what i have:

ip domain list domain.local
ip domain name domain.local
ip name-server 192.168.x.x
ip sla monitor 1
type echo protocol ipIcmpEcho 11.11.11.98
request-data-size 1400
timeout 500
threshold 2
frequency 3
ip sla monitor schedule 1 life forever start-time now
track 1 rtr 1 reachability
interface FastEthernet0/0
no ip address
speed 100
full-duplex
!
interface FastEthernet0/0.100
description Conexion Red Usuarios HiperOle
encapsulation dot1Q 100
ip address 192.168.x.x 255.255.255.0
ip helper-address 192.168.x.x
ip helper-address 192.168.x.x
!
interface FastEthernet0/1/0
Fiber to branchs
interface FastEthernet0/1/1
Wireless to branchs
interface FastEthernet0/1/2
!
interface FastEthernet0/1/3
ip route 0.0.0.0 0.0.0.0 192.168.1.11
ip route 192.168.14.0 255.255.255.0 11.11.11.98
ip route 192.168.14.0 255.255.255.0 11.11.11.99 10

tried to reduce so i want to be able to change to interface 0/1/1 if 0/1/0 goes down but keep the ability to go back if 0/1/0 goes up i believe if both fiber and wireless are in the same Vlan i may not have to do anything as it will send traffic to the one who answers but... this will use wireless at times not fiber always. 

Any idea?

New Member

Dave,

Dave,

Would you be able to explain the following statement within your configuration?

route outside 128.0.0.0 128.0.0.0 <primary gateway> 1 track 100

The rest of the configuration makes total sense to me but I am not sure where you are getting the 128.0.0.0/128.0.0.0 or why you are using it.

Thank you,

Lars

New Member

Exactly for the same reason

Exactly for the same reason as the 0.0.0.0 128.0.0.0 also in the config, it provides a valid route for the second half of the Internet. These two routes split 0.0.0.0/0 in two and act as longer match for the 2 default routes which are invalid (pointing to an invalid default gateway) and are only used to be redistributed into EIGRP.

New Member

Re: ASA SLA Tracking w/ multiple icmp checks

Hey, I know I am late, but I had found your article earlier today looking for an answer for a very similar issue. The problem I see with your solution is that the second route will overwrite the first line. Your cannot have two routes for the same network and same next-hop in a Cisco ASA. My problem was slightly different than yours, as I have a single ISP behind the ASA, but wanted to using multiple SLA monitors for the default-route so it is in the routing table if any SLA is up. The default is being redistributed into EIGRP.

Her is my solution, I hope this will help someone, someday. It is not nice and short as we would like them, but works perfectly for what I needed. I tried to put enough comments so that you understand some choices I had to make.

WAIT!  Did I tell you what follows doesn't look nice? This is for trained professionals only. Make sure you have a deep understanding of IP routing, IP routing protocols and route redistribution before you use this ! Use at your own risks!

OK her it goes...

! Monitoring a single hosts in unsufficient in many production environments.

! Very limited IP SLA tracking in ASA doesn't really allow to monitor multiple hosts at the same time.

! Only one monitor process per track process and no configurable delays for down or up events

! This will show how to create dummy default-routes each bound to a different SLA monitor for distribution into EIGRP, such that a default-route will exist in the routing table if any of the monitored hosts is responding and how to filter redistribution of static routes into EIGRP

! The actual routes the ASA will use are 0.0.0.0/1 and 128.0.0.0/1, but those routes will only be used locally by the ASA, because they are a longer-match than the 0.0.0.0/0

! The most difficult part is preventing the 0.0.0.0/1 routes from getting redistributed in EIGRP along with the 0.0.0.0/0 route.

! The same technique could be applied for RIP or OSPF

!

! ISP router (default gateway)

name x.x.x.x ISPrtr

! Google DNS

name y.y.y.y SLAtesthost1

! Another host on the Internet

name z.z.z.z SLAtesthost2

! Some unused/invalid hosts in the inside interface's subnet, I always use a /28 or bigger subnets so it was easy to find usused host addresses in the subnet

name a.a.a.a invalid-host1

name a.a.a.b invalid-host2

!

sla monitor 1

type echo protocol ipIcmpEcho SLAtesthost1 interface outside

threshold 500

frequency 10

packets 3

sla monitor schedule 1 life forever start-time now

!

sla monitor 2

type echo protocol ipIcmpEcho SLAtesthost2 interface outside

threshold 500

frequency 10

packets 3

sla monitor schedule 2 life forever start-time now

!

track 1 rtr 1 reachability

track 2 rtr 2 reachability

!

! Split the default route in two routes, these will be used by the ASA(longer-match) to forward IP packets to the ISP router. It is EXTREMELY IMPORTANT that these two routes are NOT redistributed into any routing protocol if you rely of the default-route elsewhere on your network. The route-map redist-default below will achieve this, and allow only default

route outside 0.0.0.0 128.0.0.0 255.255.255.255 ISPrtr

route outside 128.0.0.0 128.0.0.0 255.255.255.255 ISPrtr

!

! Create two dummy routes, each bound to its own tracking object/SLA monitor, which won't be used to forward any traffic. They can point to hosts in the inside subnet. We use different and invalid hosts as the next hops (other than the ISP router). First because the same route/same nex-hop cannot coexist in the ASA configuration, secondly because the ISP router's address will be used in a route-map to block the previous 2 routes (split).

route inside 0.0.0.0 0.0.0.0 invalid-host1 track 1

route inside 0.0.0.0 0.0.0.0 invalid-host2 track 2

!

!

access-list deny-all-routes permit host 0.0.0.0

access-list default-route permit host 0.0.0.0

!

access-list ISP-router permit host ISPrtr

!

! The following route-map will ensure only a dummy default route is redistributed in EIGRP, we must absolutely blocck two split routes (0.0.0.0/1 and 128.0.0.0/1)

! Since ASA does not support extended ACL in route-map for filtering on the mask, the first route-map statement denies any route with the real ISP router as the next-hop

! The same route-map could be used for redistributing into RIPv2 or OSPF

route-map redist-default deny 10

match ip next-hop ISP-router

route-map redist-default permit 20

match ip address default-route

route-map redist-default deny 100

!

router eigrp 100

no auto-summary

! Block all inbound route in the ASA

distribute-list deny-all-routes in interface inside

! Allow only the default-route to be advertised toward inside peers

distribute-list default-route out interface inside

! Redistribute only the default-route, adjust metrics to your needs

redistribute static metric 10000 100 255 1 1500 route-map redist-default

passive-interface default

no passive-interface inside

network

!

Thanks,

Marc-André

New Member

ASA SLA Tracking w/ multiple icmp checks

Marc-Andre,

This is a very interesting technique that overcomes some significant limitations in the IP SLA support on the ASA. I do however have a question.

It looks to me like if one of your two monitored IPs were to fail the router would continue to announce the default route internally, however it would only be able to reach the half of the Internet that was still available per the SLA.

Is my understanding correct, or is there something I'm missing? Is there a way to work around this issue, perhaps with another route for 0.0.0.0 0.0.0.0 to the ISP gateway address?

New Member

Hi johnstack,sorry... 2years

Hi johnstack,

sorry... 2years later.

Yes you are missing a small detail in my solution:

The two /1 prefixed routes (0.0.0.0/1 and 128.0.0.0/1) are not tracking any object, so they are always present in the ASAs routing table, and are also the ones used to forward IP packets destined to the Internet since they are longer matches to the bogus 0.0.0.0/0 prefixes.

 

M-A

New Member

Marc-Andre, Brilliant idea by

Marc-Andre,

 

Brilliant idea by using the route recursive look up. Inspired by your idea, I come up a easier configuration for this since I need to find a solution on similar scenario.

 

For the scenario that a single ASA (or Active-Standby HA cluster) has two ISP uplinks, one as primary and the other as backup. We want to ensure the SLA check more than the direct connected GW. So we can just use one remote "TestTargetIP" (in my case, one hop before my remote ASA.) then use only single SLA monitor for that TestTargetIP and enter a host route for that TestTargetIP to the GW on primary link. If the primary link GW is reachable, the TestTargetIP host route will route through it and reach to the target. If there is a break from ISP1 to TestTargetIP, the SLA test will fail then it will take the floating static to secondary ISP gateway.

 

Assume TestTargetIP is 199.199.199.199, GW to ISP1 is 100.100.100.1 GW to ISP2 is 200.200.200.1

==== ASA config ===

sla monitor 1
 type echo protocol ipIcmpEcho 199.199.199.199 interface outside
 timeout 2000
 threshold 50
 frequency 3
sla monitor schedule 1 life forever start-time now

track 123 rtr 1 reachability

route outside 199.199.199.199 255.255.255.255 100.100.100.1  <= static route force 199.199.199.199 always exist via ISP1 (primary) gateway. ## Please pick a transit IP at one or two hops before your interested destination.


route outside 0.0.0.0 0.0.0.0 100.100.100.1 track 123
route outside-b 0.0.0.0 0.0.0.0 200.200.200.1 180

===========

If primary ISP1 cannot reach to your interested destination (detect by the reach-ability to the transit IP at 1 or 2 hop before it.) the tracked default route will be dropped and backup floating default route will be used.

 

I test this concept in my GNS3 lab. It works.

 

New Member

Re: ASA SLA Tracking w/ multiple icmp checks

I have the solution:

Vlan1                    inside                      10.27.0.1            255.255.0.0    

Vlan2                    outside                    66.66.66.1          255.255.255.248

Vlan9                    backup                    55.55.55.1          255.255.255.248

route outside 0.0.0.0 0.0.0.0 1.1.1.1 1 track 1

route outside 0.0.0.0 0.0.0.0 66.66.66.2 10 track 2

route outside 1.1.1.1 255.255.255.255 66.66.66.2 1

route backup 0.0.0.0 0.0.0.0 55.55.55.2 20

sla monitor 101

type echo protocol ipIcmpEcho 66.66.66.2 interface outside

num-packets 3

frequency 30


sla monitor 102

type echo protocol ipIcmpEcho 4.2.2.2 interface outside

num-packets 3

frequency 30


sla monitor schedule 101 life forever start-time now

sla monitor schedule 102 life forever start-time now


track 1 rtr 101 reachability

track 2 rtr 102 reachability

By changing your default route to a bogus address, and then creating a static route for that bogus address to next hop of the real gateway, you can then track 2 objects.

Comments and thoughts are more than welcome.

-Steve Hughes

New Member

This is very ingenious. The

This is very ingenious. The only thing I need to do is test it in my lab with two circuits and see if it actually works. If it does this would be absolutely fantastic, until Cisco FINALLY introduces the track delay, just like the router has.

New Member

  I’ve tried all of these

  I’ve tried all of these options any haven’t gotten any of them to work.  But here is what I came up with that does seem to work really well.  You can ping two, four, or even more Internet hosts and only when all of them fail does the ASA failover to the backup ISP:

route outside 0.0.0.0 128.0.0.0 <primary gateway> 1 track 100

route outside 128.0.0.0 128.0.0.0 <primary gateway> 1 track 100

route outside 0.0.0.0 0.0.0.0 <primary gateway> 2 track 101

route outside-failover 0.0.0.0 0.0.0.0 <backup gateway> 254

track 100 rtr 100 reachability

track 101 rtr 101 reachability

sla monitor 100

 type echo protocol ipIcmpEcho 208.67.222.222 interface outside

 num-packets 3

 frequency 10

sla monitor 101

 type echo protocol ipIcmpEcho 8.8.8.8 interface outside

 num-packets 3

 frequency 9

sla monitor schedule 100 life forever start-time now

sla monitor schedule 101 life forever start-time now

  This way both 208.67.222.222 (OpenDNS) and 8.8.8.8 (Google DNS) have to be unreachable for the failover to occur from the primary Internet connection to the backup Internet connection.  You could even expand this out from pinging two Internet IP's to four.  Or using it to have more than one backup Internet connections for a failover of ISP 1 (maybe Fiber) to ISP 2 (for example cable) to ISP 3 (a Cradlepoint router using LTE/4G).

  You can test the failover pretty easily by creating two EC2 Instances on Amazon’s AWS cloud.  Use these two IP’s in the SLA Monitor commands.  Then you can use the Amazon firewall rules (or you can just start & stop the instances) to control the ICMP (ping) access to see how your ASA will failover if one or both of the Instances doesn’t ping.

  Here is what you will see in the routing table:

Track 100 up, Track 101 up:

Gateway of last resort is <primary ISP> to network 0.0.0.0

C    <Backup Interface> 255.255.255.0 is directly connected, outside-failover

C    <LAN Interface> 255.255.0.0 is directly connected, inside

C    <Primary ISP Interface> 255.255.255.240 is directly connected, outside

S    0.0.0.0 128.0.0.0 [1/0] via <Primary ISP Default Gateway>, outside

S*   0.0.0.0 0.0.0.0 [2/0] via <Primary ISP Default Gateway>, outside

S    128.0.0.0 128.0.0.0 [1/0] via <Primary ISP Default Gateway>, outside

Track 100 up, Track 101 down:

Gateway of last resort is <Backup ISP Default Gateway> to network 0.0.0.0

C    <Backup Interface> 255.255.255.0 is directly connected, outside-failover

C    <LAN Interface> 255.255.0.0 is directly connected, inside

C    <Primary ISP Interface> 255.255.255.240 is directly connected, outside

S    0.0.0.0 128.0.0.0 [1/0] via <Primary ISP Default Gateway>, outside

S*   0.0.0.0 0.0.0.0 [254/0] via <Backup ISP Default Gateway>, outside-failover

S    128.0.0.0 128.0.0.0 [1/0] via <Primary ISP Default Gateway>, outside

Track 100 down, Track 101 up:

Gateway of last resort is <Primary ISP Default Gateway> to network 0.0.0.0

C    <Backup Interface> 255.255.255.0 is directly connected, outside-failover

C    <LAN Interface> 255.255.0.0 is directly connected, inside

C    <Primary ISP Interface> 255.255.255.240 is directly connected, outside

S*   0.0.0.0 0.0.0.0 [2/0] via <Primary ISP Default Gateway>, outside

Track 100 down, Track 101 down:

Gateway of last resort is <Backup ISP Default Gateway> to network 0.0.0.0

C    <Backup Interface> 255.255.255.0 is directly connected, outside-failover

C    <LAN Interface> 255.255.0.0 is directly connected, inside

C    <Primary ISP Interface> 255.255.255.240 is directly connected, outside

S*   0.0.0.0 0.0.0.0 [254/0] via <Backup ISP Default Gateway>, outside-failover

  An even better option would be to configure two Raspberry Pi's in a cluster on the outside network of the ASA for the ASA to track with the SLA command.  Then those Raspberry Pi's can be configured so that they can ping any number of hosts and also connect to any number of web sites before signalling the ASA to failover to the backup Internet connection.  This gives a much more control over the failover process than just simple pings - even with the multiple pings allowed by the ASA configuration above.  And the redundant Raspberry Pi's means that even if one fails the ASA route tracking continues to work properly.  Note: You need either one extra static public IP for a single external Raspberry Pi or three extra static public IP's for a cluster of Pi's.  Please see http://www.icepts.com/cisco-asa-firewall-route-tracking-with-multiple-ips/

Dave

14973
Views
13
Helpful
14
Replies
CreatePlease to create content