Failover Ethernet1/11 (Failed - No Switchover)

[rikkm4n]

Hi all!

I have a question about ASA cluster failover. Failover LAN interface shows the following error:

CGD600167DVPN1/sec/act# sh fail
Failover On 
Failover unit Secondary
Failover LAN Interface: Failover Ethernet1/11 (Failed - No Switchover)
Reconnect timeout 0:00:00
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 6 of 1293 maximum
MAC Address Move Notification Interval not set
failover replication http
Version: Ours 9.12(4)67, Mate 9.12(4)67
Serial Number: Ours JAD2245003H, Mate JAD2245006Q
Last Failover at: 11:41:59 WET Dec 2 2024

But interface is up:

CGD600167DVPN1/sec/act# sh int eth1/11
Interface Ethernet1/11 "Failover", is up, line protocol is up
Hardware is EtherSVI, BW 1000 Mbps, DLY 10 usec
Description: LAN Failover Interface

And the sync state is ok:

CGD600167DVPN1/sec/act# sh fail state

State Last Failure Reason Date/Time
This host - Secondary
Active None
Other host - Primary
Standby Ready Ifc Failure 12:18:44 WET Dec 2 2024
outside: No Link

====Configuration State===
Sync Done
====Communication State===

Can't ping the other peer over failover LAN interface:

CGD600167DVPN1/sec/act# ping 1.1.1.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.5, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)

Should i be worried if cluster fails over?

[MHM Cisco World]

Can i see 

Show interface Ip breif <<- for both units

MHM

[rikkm4n]

CGD600167DVPN1/sec/act# sh int ip brief | i 1/11
Ethernet1/11 1.1.1.6 YES unset up up

CGD600167DVPN1/pri/stby# sh int ip brief | i 1/11
Ethernet1/11 1.1.1.5 YES unset up up 

[MHM Cisco World]

Up/up that good' is failover link connect b2b or to SW ?

MHM

[rikkm4n]

b2b

[MHM Cisco World]

---

@rikkm4n wrote:

b2b

---

https://quickview.cloudapps.cisco.com/quickview/bug/CSCvd78303

Check this bug 

MHM

[rikkm4n]

I don't think it applies here.

ARP is populated and traffic is flowing. 

[MHM Cisco World]

Check ARP 

And do capture in failover link for both asa 

See if hello message send receive' and which one have issue in send receive hello message 

MHM

[rikkm4n]

Different results for both units:

CGD600167DVPN1/pri/stby# sh cap failover

211 packets captured

1: 09:02:50.019865 arp who-has 1.1.1.6 tell 1.1.1.5 
2: 09:02:50.020277 arp who-has 1.1.1.6 tell 1.1.1.5 
3: 09:02:51.019896 arp who-has 1.1.1.6 tell 1.1.1.5 
4: 09:02:51.020293 arp who-has 1.1.1.6 tell 1.1.1.5 
5: 09:02:51.021025 arp who-has 1.1.1.6 tell 1.1.1.5

CGD600167DVPN1/sec/act# sh cap failover

880 packets captured

1: 09:01:58.850511 1.1.1.6 > 1.1.1.5 ip-proto-105, length 56 
2: 09:01:59.269700 arp who-has 1.1.1.6 tell 1.1.1.5 
3: 09:01:59.269929 arp reply 1.1.1.6 is-at d4:c9:3c:c0:b5:3f 
4: 09:01:59.270081 arp who-has 1.1.1.6 tell 1.1.1.5 
5: 09:01:59.270249 arp reply 1.1.1.6 is-at d4:c9:3c:c0:b5:3f

[MHM Cisco World]

So it bug as O mention above

One unit dont get reply to ARP. 

This make this unit can not send hello via failover link

MHM

[Aref Alsouqi]

What's the "show failover state" shows on the primary standby unit? you could try to disable failover on the standby active unit with the command "no failover" and then shut and unshut interface eth1/11 and see if that helps.

[rikkm4n]

CGD600167DVPN1/pri/stby# show failover state

State Last Failure Reason Date/Time
This host - Primary
Standby Ready Ifc Failure 12:18:44 WET Dec 2 2024
Other host - Secondary
Active None

====Configuration State===
Sync Done - STANDBY
====Communication State===

[Aref Alsouqi]

It's interesting that this issue with the interface doesn't seem to affect the failover sync. Could you please try to disable the failover on the standby active unit and shut/unshut interface eth1/11 on the primary standby and see if that helps? if not, you could try to reload the primary standby unit.

[rikkm4n]

This saturday I will try a reload of the standby unit

[MHM Cisco World]

You mandatory to do that 

Workaround: Perform a pre-planned reboot of the device before approaching the 213 days (5124 hours) of up time. After the reboot, it will give you another 213 days of up time.

The workaround of this bug is need reboot.

Note:- reboot unit that dont reply to ARP' according to capture.

MHM