ASA 5510 8.2.1 Not failing back to primary ISP after failing over to secondary ISP

I have a very base config to run an SLA monitor on our primary outside interface and failover to a secondary isp.  This is working.  The issue i have is when the ASA fails over, it does not fail back.  We have verified that the primary isp is back up but the ASA doesnt fail back.  I was reading that this version may need reverse route or something like that, anyone have any input on this?
viperspaceAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jan SpringerCommented:
What is your SLA configuration?
0
viperspaceAuthor Commented:
global (Outside) 101 interface
global (VZWFailover) 101 interface

access-group Outside_access_in in interface Outside
access-group VZWFailover_access_in in interface VZWFailover

route Outside 0.0.0.0 0.0.0.0 PRIMARYISP 1 track 1
route VZWFailover 0.0.0.0 0.0.0.0 SECONDARYISP 254

sla monitor 123
 type echo protocol ipIcmpEcho 8.8.8.8 interface Outside
 num-packets 5
 frequency 30
sla monitor schedule 123 life forever start-time now

track 1 rtr 123 reachability
0
Jan SpringerCommented:
That config looks good.  It's possible that the primary ISP has periodic problems reaching 8.8.8.8.

Can you try tweaking "num-packets" to 3 and "frequency" to 10?

You can also add a brief delay, "delay down 3 up 3".  Those numbers are in seconds.

What is the output of:

   show track
   show sla monitor configuration
   show sla monitor operational-state

and optionally:

   debug sla monitor error
   debug sla monitor trace
   debug track
0
Get Cisco Certified in IT Security

There’s a high demand for IT security experts and network administrators who can safeguard the data that individuals, corporations, and governments rely on every day. Pursue your B.S. in Network Operations and Security and gain the credentials you need for this high-growth field.

viperspaceAuthor Commented:
Result of the command: "sh track"

Track 1
  Response Time Reporter 123 reachability
  Reachability is Down
  3 changes, last change 01:32:41
  Latest operation return code: Timeout
  Tracked by:
    STATIC-IP-ROUTING 0

Result of the command: "show sla monitor configuration"

SA Agent, Infrastructure Engine-II
Entry number: 123
Owner:
Tag:
Type of operation to perform: echo
Target address: 8.8.8.8
Interface: Outside
Number of packets: 5
Request size (ARR data portion): 28
Operation timeout (milliseconds): 5000
Type Of Service parameters: 0x0
Verify data: No
Operation frequency (seconds): 30
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:

Result of the command: "show sla monitor operational-state"

Entry number: 123
Modification time: 05:43:49.447 EST Fri Nov 6 2015
Number of Octets Used by this Entry: 1480
Number of operations attempted: 488
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:46:49.447 EST Fri Nov 6 2015
Latest operation return code: Timeout
RTT Values:
RTTAvg: 0      RTTMin: 0      RTTMax: 0
NumOfRTT: 0      RTTSum: 0      RTTSum2: 0


debug sla monitor error
IP SLA Monitor ERROR debugging for all operations is on

debug sla monitor trace
IP SLA Monitor TRACE debugging for all operations is on
0
viperspaceAuthor Commented:
See anything that would prevent failing back to primary connection?
0
Jan SpringerCommented:
What do you see when you add:

route Outside 8.8.8.8 255.255.255.255 PRIMARYISP 1

With both routes (this and the default) in place, whichever interface is up and has the lowest administrative distance should win.
0
viperspaceAuthor Commented:
would that mess with my default route or would it only specifically route out packets going to 8.8.8.8?  This network is in production so i just want to be careful.
0
Jan SpringerCommented:
A default route is 0.0.0.0/0.

This only affects packets to 8.8.8.8/32.
0
viperspaceAuthor Commented:
It pings fine and seems to be going over primary connection due to speed.  I did a show route and it is showing the failover as the gateway as last resort.

Gateway of last resort is 192.168.0.1 to network 0.0.0.0
0
viperspaceAuthor Commented:
So if i am understanding this properly it seems that the primary connection is up but the ASA is not inserting the default route back in.  Any thoughts on what could cause that?  The sla monitor even shows reachability as up but it is still on the failover circuit.  Thank you for all of your help!
0
Jan SpringerCommented:
sh route | i 8.8.8.8

traceroute to 8.8.8.8 to verify the path that it's taking.
0
viperspaceAuthor Commented:
the sh route to 8.8.8.8 showed the correct route going outside to the primary WAN so that seems correct....the traceroute is completing with the primary WAN as the first hop so that seems right.  For some reason it is just not kicking back from the failover.  I read something that said something about reverse routing if we are using 8.2.1 and they fixed it in 8.2.3 or something like that.  Not sure if that is any help.
0
Jan SpringerCommented:
I am not aware of that bug in 8.2(1).  Can you upgrade to 8.2(5)?
0
Jan SpringerCommented:
And, the reverse route issue that I heard about applied to VPNs.
0
viperspaceAuthor Commented:
There is not a smartnet on this device and i am on the road without local access to it.
0
viperspaceAuthor Commented:
When i monitor the track i get this...so when forced, I can ping through that interface but the SLA policy cant.  

Track 1
  Response Time Reporter 123 reachability
  Reachability is Down
  3 changes, last change 00:20:49
  Latest operation return code: Timeout
  Tracked by:
    STATIC-IP-ROUTING 0
0
Jan SpringerCommented:
I saw that before.  That's why I had you add the static route for 8.8.8.8 out the primary.

Unless I've missed something, your configuration looks good.
0
viperspaceAuthor Commented:
When i added the static route i could ping through that interface fine but it still wouldnt fail back to the default route
0
viperspaceAuthor Commented:
I am getting this now but it is still in failover mode.

Track 1
  Response Time Reporter 123 reachability
  Reachability is Up
  4 changes, last change 00:02:17
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    STATIC-IP-ROUTING 0
0
Jan SpringerCommented:
It shows a change in the past two minutes.  Does the default route in the routing table not point to the primary?
0
viperspaceAuthor Commented:
no i still had that reverse route thing in there temporarily and i removed it.  but still not updating the route even though reachability is good.
0
viperspaceAuthor Commented:
Yea the default route is fine...they have been going down nightly and just not failing back to the primary.  Circuit was live until 630am today, isp engineers verified connectivity.
0
Jan SpringerCommented:
I would definitely try upgrading to 8.2(5).  I know it works on that release.  Perhaps there is a bug with SLA in the one you're running.
0
viperspaceAuthor Commented:
It turned out to be a setting on the backup interface.  The checkbox that says to obtain the default route from DHCP ended up overriding the default static route.  Once i unchecked that, failover and failback works just fine.
0
Jan SpringerCommented:
Well, that helps to know that the interface is using DHCP.  If you are not assigned a "sticky" static via DHCP and your address ever changes, you will not be able to fail over.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
viperspaceAuthor Commented:
Well only the failover interface is setup that way.  The primary WAN interface is setup statically.  I didnt think the DHCP one would override the static one but i guess it does.
0
Feroz AhmedSenior Network EngineerCommented:
Hi,

Failover Technology configured on ASA is to replicate data on either side of the ASA .So,that if one ASA fails then the other ASA takes precision over previous ASA .

Clearly it is assumed that when failover is configured 2 ASA are required and the configuration replicates on another ASA with the help of Management port available outside ASA .When ASA1 is configured it replicates the same configuration on ASA2 with the help of Management port and Handshaking takes place between 2 ASA's. ASA1 is considered as Active and ASA2 is considered as Standby.If ASA1 fails then ASA2 comes into position of ASA1 and takeover the action plan of ASA1 till ASA1 comesup.This is the Scenario of Failover in ASA and how it works
0
Jan SpringerCommented:
sm_feroz -- this is not active/passive or active/active failover to which the author is referring.  The question relates to failover routing -- a completely different issue.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Switches / Hubs

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.