03-26-2009 09:25 AM - edited 03-11-2019 08:10 AM
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.
03-26-2009 12:50 PM
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
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
03-27-2009 10:12 AM
03-27-2009 02:43 PM
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
03-27-2009 06:50 PM
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
03-27-2009 06:57 PM
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
03-27-2009 07:02 PM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: