ASA Lessons: Failover

August 16, 2019
CCIE
Technology
Failover
Redundancy
ASA

In this post I will go through an example of setting up redundancy between a pair of ASA’s using one of the two methods of accomplishing this. The 2 methods are:

Failover
Clustering

This post is exclusively about the failover option.

First a few details about the topology I will be using. As can be seen below, im running a combination of virtual and hardware devices. In the topology there are 3 hardware devices, 2x ASA-5512-X’s and a physical switch.

The physical switch is hooked up to a virtual switch running in EVE-NG with a trunk carrying all the vlan’s required. This link is the one going from Virtual Switch G0/0 to Physical-Switch F0/48.

Each ASA is hooked up with 3 physical interfaces to the Physical-Switch. G0/0, G0/1 and G0/2. The G0/0 and G0/1 are configured in a port-channel using LACP and the port-channel is configured as a Trunk. The G0/2 is used for the failover-link used for keepalives and configuration synchronization between the pair of ASA’s.

Physical Topology:

Regarding the VLAN’s, for this topology I am using 3 different ones, namely Vlan99 (FAILOVER_VLAN), Vlan100 (INSIDE) and Vlan200 (OUTSIDE)

We end up with a logical topology that looks like this:

Logical Topology:

On top of that I am running EIGRP AS 100 between CSR-2 and ASA-01 and again between ASA-01 and CSR-3. Its important to note that no adjacencies will be formed to the secondary unit under normal circumstances.

Lets take a look at relevant configuration on the CSR-2:

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet1
 ip address 192.168.100.100 255.255.255.0
 negotiation auto
 no mop enabled
 no mop sysid
!
router eigrp 100
 network 0.0.0.0
!
ip route 0.0.0.0 0.0.0.0 192.168.100.1

And just to verify that we have an adjacency running to ASA-01:

CSR-2#sh ip ei nei
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   192.168.100.1           Gi1                      10 00:08:47    6   100  0  11

CSR-2#sh ip route eigrp | beg Gat
Gateway of last resort is 192.168.100.1 to network 0.0.0.0

      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/131072] via 192.168.100.1, 00:09:12, GigabitEthernet1
      10.0.0.0/24 is subnetted, 1 subnets
D        10.0.0.0 [90/3072] via 192.168.100.1, 00:09:12, GigabitEthernet1
      172.16.0.0/24 is subnetted, 1 subnets
D        172.16.100.0 [90/3072] via 192.168.100.1, 00:09:12, GigabitEthernet1

As can be seen we do have an adjacency and we are learning a few routes, among them CSR-3’s loopback (3.3.3.3/32).

Now, lets turn our attention to the ASA configuration.

Basically, its extremely simple to configure a failover pair on the ASA’s as it only involves a few steps:

Configure interfaces to have the standby ASA’s IP addresses with the command: “ip address PRIMARY_IP MASK standby SECCONDARY_IP”
Configure monitoring on interfaces (this is only required on subinterfaces as its the default behavior on physical interfaces)
Configure the failover pair using 4 commands.

This is what my configuration on ASA-01 looks like:

interface Port-channel1.100
 vlan 100
 nameif INSIDE
 security-level 100
 ip address 192.168.100.1 255.255.255.0 standby 192.168.100.2 
!
interface Port-channel1.200
 vlan 200
 nameif OUTSIDE
 security-level 0
 ip address 172.16.100.1 255.255.255.0 standby 172.16.100.2 
!
failover
failover lan unit primary
failover lan interface FAIL_OVER GigabitEthernet0/2
failover interface ip FAIL_OVER 100.100.100.1 255.255.255.0 standby 100.100.100.2
monitor-interface INSIDE
monitor-interface OUTSIDE
!

The command “failover lan unit primary” makes this ASA the primary unit. The command “failover lan interface FAIL_OVER GigabitEthernet0/2” designates GigabitEthernet0/2 to be the failover link with a name of FAIL_OVER.

Next is to assign the IP addressing used on the failover link. First address is of primary unit and the second address of the secondary.

Since im using subinterfaces, I manually monitor both the INSIDE and OUTSIDE links.

All of those failover commands needs to be replicated on the secondary unit, with the exception of “failover lan unit primary” which needs to be: “failover lan unit secondary”.

Finally, the command: “failover” enables the failover mode. This needs to be done manually on both the primary and secondary unit.

After this the ASA’s should team up and go into failover mode. By the way, please modify your prompt, so you can see which is the primary/secondary unit and what state you are in: “prompt hostname priority state”, which will result in this on the primary (ASA-01):

ASA-01/pri/act#

And on ASA-02:

ASA-01/sec/stby#

Notice that the hostname is the same, because you are now running in failover mode and NO configuration should be done on the standby unit!

Now lets verify the state of the failover (on ASA-01):

ASA-01/pri/act# show failover
Failover On 
Failover unit Primary
Failover LAN Interface: FAIL_OVER GigabitEthernet0/2 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 3 of 114 maximum
MAC Address Move Notification Interval not set
Version: Ours 9.2(4), Mate 9.2(4)
Last Failover at: 01:00:39 UTC Aug 16 2019
        This host: Primary - Active 
                Active time: 15804 (sec)
                slot 0: ASA5512 hw/sw rev (1.0/9.2(4)) status (Up Sys)
                  Interface management (0.0.0.0): No Link (Waiting)
                  Interface INSIDE (192.168.100.1): Normal (Monitored)
                  Interface OUTSIDE (172.16.100.1): Normal (Monitored)
                  Interface DMZ (10.0.0.1): Normal (Not-Monitored)
        Other host: Secondary - Standby Ready 
                Active time: 0 (sec)
                slot 0: ASA5512 hw/sw rev (1.0/9.2(4)) status (Up Sys)
                  Interface management (0.0.0.0): No Link (Waiting)
                  Interface INSIDE (192.168.100.2): Normal (Monitored)
                  Interface OUTSIDE (172.16.100.2): Normal (Monitored)
                  Interface DMZ (10.0.0.2): Normal (Not-Monitored)

Stateful Failover Logical Update Statistics
        Link : Unconfigured.

And on ASA-02:

ASA-01/sec/stby# show failover
Failover On 
Failover unit Secondary
Failover LAN Interface: FAIL_OVER GigabitEthernet0/2 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 3 of 114 maximum
MAC Address Move Notification Interval not set
Version: Ours 9.2(4), Mate 9.2(4)
Last Failover at: 23:37:43 UTC Aug 15 2019
        This host: Secondary - Standby Ready 
                Active time: 0 (sec)
                slot 0: ASA5512 hw/sw rev (1.0/9.2(4)) status (Up Sys)
                  Interface management (0.0.0.0): No Link (Waiting)
                  Interface INSIDE (192.168.100.2): Normal (Monitored)
                  Interface OUTSIDE (172.16.100.2): Normal (Monitored)
                  Interface DMZ (10.0.0.2): Normal (Not-Monitored)
        Other host: Primary - Active 
                Active time: 15846 (sec)
                slot 0: ASA5512 hw/sw rev (1.0/9.2(4)) status (Up Sys)
                  Interface management (0.0.0.0): No Link (Waiting)
                  Interface INSIDE (192.168.100.1): Normal (Monitored)
                  Interface OUTSIDE (172.16.100.1): Normal (Monitored)
                  Interface DMZ (10.0.0.1): Normal (Not-Monitored)

Stateful Failover Logical Update Statistics
        Link : Unconfigured.

We can see that they are basically the opposite of each other, which is to be expected. Importantly, the INSIDE and OUTSIDE interfaces are being monitored on both units, which is an indication they are ready to take over from each other.

For testing, lets first verify that we have reachability from CSR-2’s loopback to CSR-3’s loopback (2.2.2.2 -> 3.3.3.3):

CSR-2#ping 3.3.3.3 so loo0 rep 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 6/9/20 ms

All good so far, now lets simulate a failure, by shutting down both interfaces in the portchannel towards ASA-01 and see how long it takes to reconverge:

CSR-2#ping 3.3.3.3 so loo0 rep 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...
*Aug 16 11:19:48.147: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.100.1 (GigabitEthernet1) is down: peer restarted..
*Aug 16 11:19:52.802: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 192.168.100.1 (GigabitEthernet1) is up: new adjacency.!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (994/1000), round-trip min/avg/max = 6/8/30 ms

Basically we lost 6 packets, with a timeout of 2 seconds, so 12 seconds to converge from the one unit to the other and getting adjacencies back up and running. Not too bad.

Please note that even after unshutting the interfaces, preemption toward the primary unit will not occur by default.

So with this information, I hope I have a firm understanding of the failover feature available on the ASA’s.

Hope this has been useful. Until next time!

/Kim