sla monitor on ASA5510 not working as expected

Phil Williamson · ‎03-26-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?

Thx,

Phil

Edit: Does ip verify reverse-path break SLA?

The 5510 is a security plus in case it matters.

robertson.michael · ‎03-26-2009

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.

-Mike

Phil Williamson · ‎03-27-2009

Mike,

Took a while to sanitize the config. I don't think I've deleted anything of importance, but that remains to be seen.

Thx,

Phil

robertson.michael · ‎03-27-2009

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.

-Mike

Phil Williamson · ‎03-27-2009

Mike,

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#

ciscoasa# sho sla monitor config

SA Agent, Infrastructure Engine-II

Entry number: 111

Owner:

Tag:

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#

ciscoasa# show route

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

C 1.1.1.0 255.255.255.248 is directly connected, inside

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

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

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

ciscoasa#

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

ciscoasa#

-Puzzled in NC

robertson.michael · ‎03-27-2009

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:

http://www.cisco.com/en/US/docs/security/asa/asa72/command/reference/c1_72.html#wp2034121

Let us know what you see.

-Mike

Phil Williamson · ‎03-27-2009

Mike,

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