Cisco ASA : Management Standby (HA-Active/Standby)

[bcr]

Hello,

I have a Cisco ASA, HA - Active/Standby (ASA1 and ASA2) configuration:

1. ASA1: Gigabit 0/0 (Management) - 192.168.1.110,
2. ASA2: Gigabit 0/0 (Management) - 192.168.1.111.

Is it possible to keep the Giga 0/0 management interface of the secondary ASA unchanged during synchronization. I want to access the ASA2 via its management interface using SSH.

The problem is that as soon as I activate the failover, I lose control over the secondary ASA.

For your information, I have a failover key **********.

Thank you.

Cordially,

bcr.

[Cristian Matei]

Hi,

    Can you connect to the console and issue a "show failover" on both, to see what is the actual state?

Regards,

Cristian Matei.

[bcr]

Hello,
This is the result of "show failover"

ASA-1/pri/act# show failover
Failover On
Failover unit Primary
Failover LAN Interface: lien-failover GigabitEthernet0/1 (up)
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 3 of 286 maximum
MAC Address Move Notification Interval not set
failover replication http
Version: Ours 9.12(3)7, Mate 9.12(3)7
Serial Number: Ours 9ASH1Q9V5CM, Mate 9ANR6MQAXAK
Last Failover at: 07:33:07 UTC Apr 8 2020
        This host: Primary - Active
                Active time: 35 (sec)
                slot 0: ASAv hw/sw rev (/9.12(3)7) status (Up Sys)
                  Interface network-OUTSIDE (10.28.85.1): Normal (Waiting)
                  Interface network-INSIDE (10.28.83.65): Normal (Waiting)
                  Interface management (10.28.81.113): Normal (Monitored)
        Other host: Secondary - Standby Ready
                Active time: 446 (sec)
                  Interface network-OUTSIDE (0.0.0.0): Normal (Waiting)
                  Interface network-INSIDE (0.0.0.0): Normal (Waiting)
                  Interface management (10.28.81.114): Normal (Monitored)

Stateful Failover Logical Update Statistics
        Link : lien-statefull GigabitEthernet0/2 (up)
        Stateful Obj    xmit       xerr       rcv        rerr
        General         262936     0          14189      0
        sys cmd         14189      0          14189      0
        up time         0          0          0          0
        RPC services    0          0          0          0
        TCP conn        2          0          0          0
        UDP conn        0          0          0          0
        ARP tbl         248744     0          0          0
        Xlate_Timeout   0          0          0          0
        IPv6 ND tbl     0          0          0          0
        VPN IKEv1 SA    0          0          0          0
        VPN IKEv1 P2    0          0          0          0
        VPN IKEv2 SA    0          0          0          0
        VPN IKEv2 P2    0          0          0          0
        VPN CTCP upd    0          0          0          0
        VPN SDI upd     0          0          0          0
        VPN DHCP upd    0          0          0          0
        SIP Session     0          0          0          0
        SIP Tx  0          0          0          0
        SIP Pinhole     0          0          0          0
        Route Session   0          0          0          0
        Router ID       0          0          0          0
        User-Identity   1          0          0          0
        CTS SGTNAME     0          0          0          0
        CTS PAC         0          0          0          0
        TrustSec-SXP    0          0          0          0
        IPv6 Route      0          0          0          0
        STS Table       0          0          0          0
        Umbrella Device-ID      0          0          0          0

        Logical Update Queue Information
                        Cur     Max     Total
        Recv Q:         0       30      120842
        Xmit Q:         0       31      320415
ASA-1/pri/act#
ASA-1/pri/act#
ASA-1/pri/act#

Thank you.


Cordially,
bcr.

[BrianSekleckiGE]

This has been a problem with the nature of ASA Fail-over for at least a decade.

The solution to your problem will almost certainly be:

  Purchase a Serial Console Gateway.

Of course, if you're not on salary, and the device is more than an hour drive, it may be an overtime opportunity :)

 The customer will change their opinion on the cost of a Serial console Server once they get your invoice/time-sheet.

[bcr]

Hello,

What do you mean: Purchase a Serial Console Gateway

I connect to the ASAs via their management interfaces which are connected to the local network.

As long as I'm connected to the LAN, I should have ssh access.

Thank you. (Chuckles)

My best regards,

bcr.

[Cristian Matei]

Hi,

   Are you managing the ASA on the IP from the management interface? For the outside and inside interfaces, you have not configured the standby IP address.

Regards,

Cristian Matei.

[bcr]

Hello,

Oui, je gère les ASAs depuis des interfaces de gestion.
Pour les deux interfaces, je l'ai fais après avoir poser la question.
Merci.

Cordialement,
bcr.

[Cristian Matei]

Hi,

   So after activating failover, one ASA is Active and the other ASA is standby, and you can access both of them. If you want the ASA to failover upon an interface failure, you would need to configure standby IP addresses, otherwise those interfaces are not monitored.

   To simulate a failover, first fix the above problem and ensure all interfaces show up as "Monitored" in "show failover". Afterwards shutdown the switch interface facing the primary ASA inside or outside interface, failover should happen, and you should afterwards gain SSH access to both ASA's.

Regards,

Cristian Matei.

[bcr]

Hello,

I have all the interfcaes supervised.

When I do 'shutdown' on giga 0/1 (ASA-1 , Outside), the two interfaces ASA1 (giga 0/1) and ASA2 (giga0 / 1) become down. No failover.

When I do "no failover active" on ASA-1, I stay for a few seconds and then I try to connect via ssh, it is not possible.

here is the result of the "show failover"

ASA-1/pri/act# show failover
Failover On
Failover unit Primary
Failover LAN Interface: lien-failover GigabitEthernet0/1 (up)
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 3 of 286 maximum
MAC Address Move Notification Interval not set
failover replication http
Version: Ours 9.12(3)7, Mate 9.12(3)7
Serial Number: Ours 9ASH1Q9V5CM, Mate 9ANR6MQAXAK
Last Failover at: 12:45:06 UTC Apr 8 2020
        This host: Primary - Active
                Active time: 44 (sec)
                slot 0: ASAv hw/sw rev (/9.12(3)7) status (Up Sys)
                  Interface network-OUTSIDE (10.28.85.1): Normal (Monitored)
                  Interface network-INSIDE (10.28.83.65): Normal (Monitored)
                  Interface management (10.28.81.113): Normal (Monitored)
        Other host: Secondary - Standby Ready
                Active time: 675 (sec)
                  Interface network-OUTSIDE (10.28.85.2): Normal (Monitored)
                  Interface network-INSIDE (10.28.83.66): Normal (Monitored)
                  Interface management (10.28.81.114): Normal (Monitored)

Stateful Failover Logical Update Statistics
        Link : lien-statefull GigabitEthernet0/2 (up)
        Stateful Obj    xmit       xerr       rcv        rerr
        General         306482     0          16631      1
        sys cmd         16634      0          16633      1
        up time         0          0          0          0
        RPC services    0          0          0          0
        TCP conn        3          0          0          0
        UDP conn        0          0          0          0
        ARP tbl         289875     0          0          0
        Xlate_Timeout   0          0          0          0
        IPv6 ND tbl     0          0          0          0
        VPN IKEv1 SA    0          0          0          0
        VPN IKEv1 P2    0          0          0          0
        VPN IKEv2 SA    0          0          0          0
        VPN IKEv2 P2    0          0          0          0
        VPN CTCP upd    0          0          0          0
        VPN SDI upd     0          0          0          0
        VPN DHCP upd    0          0          0          0
        SIP Session     0          0          0          0
        SIP Tx  0          0          0          0
        SIP Pinhole     0          0          0          0
        Route Session   1          0          0          0
        Router ID       0          0          0          0
        User-Identity   3          0          0          0
        CTS SGTNAME     0          0          0          0
        CTS PAC         0          0          0          0
        TrustSec-SXP    0          0          0          0
        IPv6 Route      0          0          0          0
        STS Table       0          0          0          0
        Umbrella Device-ID      0          0          0          0

        Logical Update Queue Information
                        Cur     Max     Total
        Recv Q:         0       31      141999
        Xmit Q:         0       31      373680
ASA-1/pri/act#

Thank you

Regards,

bcr.

[Cristian Matei]

Hi,

    That's why is said to shutdown the switchport facing the ASA outside or inside interface, not the ASA port itself. When you shutdown the port on the Active ASA, the config is synced over and also the Standby ASA link goes down, there is no failover as both ASA's are equally preferred (both have the same link down, thus the Active ASA remains Active).

    So, shutdown the switchport facing the Active ASA outside or inside interface, you should loose connectivity, failover should happen and you should regain connectivity via SSH to both devices. Give it more than just few seconds. 

   You keep saying that after you do a failover you loose access to the ASA (normal), but after failover is done, you can no longer have access to the ASA. In this case, how can you collect all these outputs? If after failover, and waiting like let's say 30 seconds, you can't get access to the ASA, go via the console and see the state of both ASA's.

Regards,

Cristian Matei.

[bcr]

Hello,

I'm in a lab (vSphre), I need to test and be sure it works before I deploy. That's why I'd like to see the failover test.

The INSIDE and OUTSIDE interfaces are not connected but they are in the same VLANs.

At first I have access to both ASAs (ASA-1 & ASA-2) via ssh. I do "failover" then I wait 2 minutes. I try to connect to the ASAs via ssh but it's not possible.

I can check on the vSphere command line interface that there is a failover, so change of address.

Thank you.

My best regards,
bcr.

[Cristian Matei]

Hi,

   Are you trying to SSH from the same subnet as the management subnet? Can you clear your ARP cache after the failover? Like disable and re-enable your NIC? Do a failover, clear your ARP cache, connect again.

   So failover works as expected, it's just a problem that you can no longer access the ASA after the failover, right?

Regards,

Cristian Matei.

[bcr]

Hello,

Yes, failover works. It's just a problem that I can no longer access the ASA after the failover.

I used « tracert » to check the path, all the intermediaries are responding, just the ASAs are not responding.

I've restarted my computer and waited a lot of minutes. Then when I try to reconnect, the ASAs don't respond.

Thank you in advance.

Sincerely,

bcr.

[D Le Wando]

Yo folks,

this is rather old, but I faced the same "issue". It seems that Cisco ASA, other than devices from different vendors, is using the management interface in high-availability. So the management interface is NOT independent to HA!
Means, it is not possible to initiate failovers and use the same ssh-session to the management interfaces. This is a bit annoying but we need to live with it ...

[BrianSekleckiGE]

Assumption:Active/Standby

1) If you're using the physical management interfaces, then I'm uncertain if those interfaces are intrinsicly exempted from HA activity and operate independent of HA/Failover; I assume-so, check it.

 (Fortinet has this feature: "Reserved Management Interface"):

2) If you're using Multi-Context mode, the Mgmt interfaces (VLAN or Physical) would normally be assigned to the ADMIN VDOM 

3) In Multi-Context mode, if you're using a VLAN interface for Management (On a  Trunk / Dot1Q / EtherChannel), that VLAN should be assigned to the Admin VDOM and it should have a standard HA IP Configuration and standard failover behavior.

Ultimately, because ASA OS Interface HA IP Behavior is not like HSRP (three IPs), but instead a two-IP behavior, it really doesn't matter as long as one IP is reachable, you can execute commands on the OTHER (standby) chassis with:

(For example, lets say you're investigating a failover after-the-fact, and you suspect a faulty power supply)

ASA-Active/Sec > failover exec {active | standby | mate} show env

ASA-Active/Sec> failover exec active show inventory