sla monitor on ASA5510 not working as expected

Unanswered Question
Mar 26th, 2009

ASA5510, v8.0(4)

I've set up sla monitor per Cisco Document ID: 70559

This morning it failed over to the backup link like it should.

However, when the primary ISP link was restored it was not reinstalled as the primary default-route. I disconnected both primary and backup links from the ASA, waited 60 seconds and then reconnected the primary link. Route still did not come back up. I reconnected the backup link and it was installed as the default-route.

I had to remove the SLA code to get the primary ISP route restored.

I also turned on SLA debugging, but was not getting ANY msgs.

Any ideas?



Edit: Does ip verify reverse-path break SLA?

The 5510 is a security plus in case it matters.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
robertson.michael Thu, 03/26/2009 - 12:50

Hi Phil,

Can you post a sanitized copy of your configuration? This should help us to troubleshoot your issue.

Also, take a look at the output of 'show sla monitor operational-state ' after the backup route has taken over and you have reconnected your primary connection. This output may give you some clue about what is going on in lieu of the debug messages.

To answer your last question: ip verfiy reverse-path should not prevent SLA from working as expected. In fact, I am currently using SLA monitoring and RPV on the same device and have not had any issues.

Hope that helps.


robertson.michael Fri, 03/27/2009 - 14:43

Hi Phil,

Your SLA config looks good to me.

When you reconnect the primary link, are you able to manually ping 63.X.Z.1 from the firewall?

Also, let's take a look at the output of 'show sla monitor operational-state 111' after the backup route has taken over and you have reconnected your primary connection.


Phil Williamson Fri, 03/27/2009 - 18:50


The monitor target was back up by the time I looked at what had happened, but note that I'm still on the backup interface - the primary route is never restored. The only way I could get the primary back up was to delete the SLA code. We tried disconnecting the backup, but that had no effect. I'm remote from my client and the first thing I tried was to ping the SLA target and I got a response.

ciscoasa# show running-config sla monitor

sla monitor 111

type echo protocol ipIcmpEcho 63.X.Z.1 interface outside

num-packets 3

frequency 10

sla monitor schedule 111 life forever start-time now


ciscoasa# sho sla monitor config

SA Agent, Infrastructure Engine-II

Entry number: 111



Type of operation to perform: echo

Target address: 63.X.Z.1

Interface: outside

Number of packets: 3

Request size (ARR data portion): 28

Operation timeout (milliseconds): 5000

Type Of Service parameters: 0x0

Verify data: No

Operation frequency (seconds): 10

Next Scheduled Start Time: Start Time already passed

Group Scheduled : FALSE

Life (seconds): Forever

Entry Ageout (seconds): never

Recurring (Starting Everyday): FALSE

Status of entry (SNMP RowStatus): Active

Enhanced History:

ciscoasa# show sla monitor operational-state

Entry number: 111

Modification time: .09:08:02.163 EDT Tue Mar 24 2009

Number of Octets Used by this Entry: 1480

Number of operations attempted: 17546

Number of operations skipped: 0

Current seconds left in Life: Forever

Operational state of entry: Active

Last time this entry was reset: Never

Connection loss occurred: FALSE

Timeout occurred: TRUE

Over thresholds occurred: FALSE

Latest RTT (milliseconds): NoConnection/Busy/Timeout

Latest operation start time: .09:52:12.153 EDT Thu Mar 26 2009

Latest operation return code: Timeout

RTT Values:

RTTAvg: 0 RTTMin: 0 RTTMax: 0

NumOfRTT: 0 RTTSum: 0 RTTSum2: 0

ciscoasa# show clock

09:52:32.423 EDT Thu Mar 26 2009


ciscoasa# show route

Gateway of last resort is 67.X.Y.81 to network

C is directly connected, inside

C 67.X.Y.80 is directly connected, backup

C 63.X.Y.48 is directly connected, outside

S* [254/0] via 67.X.Y.81, backup


ciscoasa# ping backup 63.X.Z.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 63.X.Z.1, timeout is 2 seconds:


Success rate is 100 percent (5/5), round-trip min/avg/max = 10/10/10 ms


-Puzzled in NC

robertson.michael Fri, 03/27/2009 - 18:57

Hi Phil,

The output of 'show sla monitor operational-state' shows that the ASA is correctly trying to ping the target that you specified in your SLA configuration. It hasn't missed any of these attempts, so it looks as if SLA is working as expected.

For some reason, though, the firewall is not receiving any response from the target. I might start by looking at a packet capture on your outside interface to see if you can spot the echo request and reply. If you don't see it there, I would then take a look at an ASP drop capture to see if the firewall is dropping the response for some reason.

Here is the command reference for the capture in case you are unfamiliar with the process:

Let us know what you see.


Phil Williamson Fri, 03/27/2009 - 19:02


I'll set up the capture with my customer. It takes days to setup something like this since it's liable to disrupt Internet service for 300+ users and must be done after hours.

I'll let you know what I find.

Thanks for the help - Phil


This Discussion