Why one asa primary status always go into secondary status ?

[eigrpy]

Hi I configured failover ASA as following. I set up ASA1 as primary ASA, but after running for a while, the ASA1 become secondary. After i added command "failover lan unit primary", the ASA1 became primary. After a while, it automatically changed back to secondary again. I want ASA1 is always primary. Any one can give me some suggestion ? Thank you

HSRP has priority command, does failover have ? 

ASA1/sec/act# sh run failover 
failover
failover lan unit secondary
failover lan interface folink GigabitEthernet0/5
failover key *****
failover replication http
failover interface ip folink 10.255.1.1 255.255.255.252 standby 10.255.1.2
FW/sec/act# 

[Maykol Rojas]

Ok this is the part that is very confusing, and will try to explain as best as I can. 

When you configure the firewalls for Active/Standby failover, ALL the configuration is being replicated, all of it, except for the failover commands, so when you say that you are accessing ASA1 because of the hostname, that really doesnt make any sense since both ASAs will have the hostname as ASA1 (being "hostname" a command that is replicated). 

You should NEVER use the "failover lan unit xxx" to change roles, you should be changing states meaning making a unit active or standby, not changing their priorities. Priorities will never change unless you apply the command you are showing there. 

If you want to access the primary firewall, you should use the regular IP that you use to connect, however, if you want to connect to the SECONDARY firewall, you need to use the standby IP configured. 

NOW, to your problem: 

Probably the units are doing failover, so when you connect to the Unit you are really connecting to the active one, in some cases the active unit might be the secondary unit. In this case, it seems to be so: 

ASA1/sec/act# 

The middle indicator says that you are connecting to the secondary Unit, probably you connect to it using the regular IP address you use to connect to your firewall. 

in order to find out why it is doing failover, you might need to pull the "show failover history" and "show failover state" to see the reason for the failure. 

Let me know if you have any questions. 

Mike. 

[eigrpy]

Thank you so much for your reply

I am sorry that I did not tell it clearly in the post. In fact, I gave the same name -- ASA to both firewalls. but in order to identify the two ASA, I mentioned ASA1 in previous post. I hope ASA1 is configured as primary. ASA2 is second. I configured ASA1 as primary and ASA2 as second and then i run the two ASA. After a while, the ASA1 become secondary though it is still active, while ASA2 become primary though it is still standby. My question is why ASA1 become secondary automatically and ASA2 become primary ? I hope ASA1 is always primary and ASA2 is second. Active/standby is not issue. The issue is primary/secondary

[Marvin Rhoads]

The Primary ASA should ALWAYS stay Primary. If you believe this is changing without you manually changing the role via cli, we must be missing some fact. I have worked on hundreds of ASAs and never seen this behavior.

A member in an HA pair state may change from active to standby based on any number of things - monitored interface down, hardware failure, software module crash etc. As Mike mentioned, the couple of show commands can almost always very quickly show us why a certain state is in existence and when that happened.

[eigrpy]

Thank you for your reply. In fact, the pair of failover had been working very well for a little longer time in non-production. Recently we connected the ASA to the production. we found ASA1 cannot be primary even if we configured it as primary several times. it is strange. and we even cannot ping its inside interface(it possibly is other issue that we need to rule out) . After I removed ASA2, the ASA1 seems can work(can ping its inside interface), which needs to further confirm. 

[Marvin Rhoads]

It appears your production setup has a connectivity issue that's preventing the unit from ever establishing itself as primary.

Some further analysis of the running-configuration and show commands mentioned earlier by Mike would be necessary to troubleshoot further. 

[eigrpy]

The following behavior is strange. As you can see below, When I used command "failover active" to test active transfer to ASA2, we can see "pri"  become "sec". Instead, ASA2 does not become active. Is this a abnormal ? it is very strange. 

ASA2/pri/stby# failover active 

The semaphore timeout period has expired.

Type help or '?' for a list of available commands.
ASA2/sec/stby> en
Password: **********
ASA2/sec/stby# 
ASA2/sec/stby# 

[Scott Reedman]

Hi Marvin,

As read through this post I am wondering if this is possible after a reload?

I have the same thing going on, my primary is now the secondary and I am wondering if what I did is possible.

We had a backup VPN down to a partner site and their admin recommended rebooting the firewalls. I remember doing a wr mem on each of them but did not see the status before doing it. If the secondary is standby/active would I have messed up the config by saving if secondary was active? Or did even doing the wr mem on the secondary do it?

When I look at the copied running config before which was saved and copied to a notepad file also after original configuration, it has definitely changed. I am using the same IP address to connect. 10.14.233.18 used for all these outputs.

Original from text file,

failover
failover lan unit primary
failover lan interface failover Vlan8
failover interface ip failover 192.168.255.1 255.255.255.252 standby 192.168.255.2

From sh run now,

failover
failover lan unit secondary
failover lan interface failover Vlan8
failover interface ip failover 192.168.255.1 255.255.255.252 standby 192.168.255.2
 

This is the output from sh fail now, this is using the same IP 10.14.233.18 that was used to do sh run in original from text file above,

INDY-ASA5505# sh fail
Failover On
Failover unit Secondary
Failover LAN Interface: failover Vlan8 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 4 of 23 maximum
MAC Address Move Notification Interval not set
Version: Ours 9.2(4), Mate 9.2(4)
Last Failover at: 01:10:13 UTC Oct 1 2015
        This host: Secondary - Active
                Active time: 1204067 (sec)
                slot 0: ASA5505 hw/sw rev (1.0/9.2(4)) status (Up Sys)
                  Interface inside (10.14.233.18): Normal (Monitored)
                  Interface outside (x.x.x.x): Normal (Monitored)
                  Interface outside-ATT (x.x.x.x): Normal (Monitored)
                slot 1: empty
        Other host: Primary - Standby Ready
                Active time: 21964 (sec)
                slot 0: ASA5505 hw/sw rev (1.0/9.2(4)) status (Up Sys)
                  Interface inside (10.14.233.20): Normal (Monitored)
                  Interface outside (x.x.x.x): Normal (Monitored)
                  Interface outside-ATT (x.x.x.x): Normal (Monitored)
                slot 1: empty

This is sh fail output from 10.14.233.20 now

INDY-ASA5505# sh fail
Failover On
Failover unit Primary
Failover LAN Interface: failover Vlan8 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 4 of 23 maximum
MAC Address Move Notification Interval not set
Version: Ours 9.2(4), Mate 9.2(4)
Last Failover at: 01:10:13 UTC Oct 1 2015
        This host: Primary - Standby Ready
                Active time: 21964 (sec)
                slot 0: ASA5505 hw/sw rev (1.0/9.2(4)) status (Up Sys)
                  Interface inside (10.14.233.20): Normal (Monitored)
                  Interface outside (x.x.x.x): Normal (Monitored)
                  Interface outside-ATT (x.x.x.x): Normal (Monitored)
                slot 1: empty
        Other host: Secondary - Active
                Active time: 1203776 (sec)
                slot 0: ASA5505 hw/sw rev (1.0/9.2(4)) status (Up Sys)
                  Interface inside (10.14.233.18): Normal (Monitored)
                  Interface outside (x.x.x.x): Normal (Monitored)
                  Interface outside-ATT (x.x.x.x): Normal (Monitored)
                slot 1: empty

Any insight would be appreciated as I have no idea how this happened and I am positive the same 10.14.233.18 IP was used for all the outputs you see above except the last sh fail. I need to get this back to the way it was and also want to make sure I don't cause this again if I did cause it during the reload. But have no clue why if it is even possible.

[Marvin Rhoads]

Scott,

Your failover pair appears healthy. It's just that your Primary unit is in Standby Ready state. You can easily fix that by logging into the Secondary - Active unit and running:

no failover active

It will kick you out as the session is bound to an IP address that just left that device in favor of its mate. Log back in to the same address and you will see you are now on the Primary unit and it is Active.

Remember that in an ASA pair, the primary IP address follows the active unit. So don't get hung up on which physical device you log into when you log into a given address.

To keep myself straight, I always change the prompt in an ASA HA pair to show me which unit I am logged into and its state:

prompt hostname priority state

[Scott Reedman]

Marvin,

Thank you for the prompt reply. This is a big relief, this was setup before my time and as a newbie I think I am still pretty afraid to make changes, which I guess is a good thing with my experience.

One more question if I may,

Do the recommended commands disrupt connectivity or is this best done in a maintenance window?

[Marvin Rhoads]

You're welcome. Nothing wrong with being cautious especially given how human error is one of the major causes of network outages. (Second most common in my estimation - after physical layer problems.)

Switching failover state (without stateless failover setup) will interrupt active TCP connections. Most users and applications never notice it as the transport layer will recover unbeknownst to them - but a few may notice if they have something unusually sensitive to the least interruption.

If it's a critical production environment I always schedule it during an approved maintenance window even though it only takes a second. Most smaller customers are fine with just doing it after close of business. Larger enterprises with potentially thousands of users usually require a stricter pre-approved scheduled time during very late night or on certain weekends.

Changing the prompt has no impact on traffic at all.

[Scott Reedman]

Worked like a charm. Mission accomplished.

Thanks.

[Marvin Rhoads]

Great. Please rate the replies that were useful. Regards.