Recently, I came across a situation in which Cisco ASAs were being used in an active/standby configuration. However, public IP addresses assigned to the network were becoming limited and the standby IP address used in the failover configuration would be very handy if it could be assigned to some other use. The question then became: “How do we keep using failover but also free up some public IP addresses?” In this article, we will discuss two solutions to this issue.

CCNA Training – Resources (Intense)

I will use the diagram below to explain the problem:

To configure failover, you require a pair of Cisco ASAs meeting certain requirements. In an active/standby failover configuration, one ASA will be the active one and if it fails (or some other failover policy is met), then the standby ASA will take over. In a standard Cisco failover configuration, you need to have a standby IP address configured on all interfaces of the Cisco ASAs. This means that you should have at least two free IP addresses when doing ASA failover.

Hint: You can refer to this article on the Intense School site to learn more about failover on the Cisco ASA.

You normally would not have any problems with this requirement on your internal network because of the large private IP address space available for use. The problem can arise on the public-facing leg of your network. For example, if you have a /30 public IP address block from your ISP, it means there are only two usable IP addresses in that block—one for your ISP and one for you. In such a case, there is no extra IP address to be used as a standby IP address.

Solution 1: Redesign the Internet Edge

The first solution is to redesign the Internet edge of your network. What this basically means is that you place a Layer 3 device in front of your ASA pair and that device is the one that connects to your ISP. With this design, you can now use a private IP address block between your ASAs and the Layer 3 device, so a standby IP address should not be a problem.

You need to think about the changes to your network if you use this solution because you have introduced a routed hop on the network. For example, are you going to move your NAT configuration to the router or you will keep it on the ASA? If you will be leaving your NAT configuration on the ASA, then you need to sort out routing on the Layer 3 device, e.g., static routes to point to the ASA for translated addresses.

Solution 2: Don’t Configure a Standby IP Address

No, I didn’t make a mistake with the sub-heading. The truth is that failover will still work even if you don’t configure standby IP addresses; however, this configuration is not recommended by Cisco.

Using the diagram below, I have configured Active/Standby failover between the two ASAs.

The configuration I have on the ASAs is as follows (the same configuration will be on both ASAs due to failover; the only difference will be which unit is primary and which is secondary):

interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 41.1.1.1 255.255.255.252
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2
!
interface GigabitEthernet3
 description LAN/STATE Failover Interface
!
failover
failover lan unit primary
failover lan interface fover_link GigabitEthernet3
failover link fover_link GigabitEthernet3
failover interface ip fover_link 172.16.254.1 255.255.255.0 standby 172.16.254.2

Notice that the outside interface is on a /30 subnet and so I have not configured a standby IP address on that interface. However, failover still works as shown in the output of the show failover command:

Failover works because we have correctly configured the failover link and the ASAs can communicate over that link about the states of the units. If the active unit fails, the standby unit will still take over and start using the primary IP address/MAC address used by the one that failed. Remember that during failover, the primary IP address and MAC address remain unchanged no matter the device that is active (there are rare exceptions). This is why, when a failover occurs, current connections are not necessarily interrupted (although interruptions may occur). For example, if I were to power-off the active ASA, the standby will take over:

However, there are two issues with this configuration, as I will now discuss.

Interface monitoring

If you don’t specify a standby IP address, interface monitoring cannot take place on that interface. If you notice in the above output, the outside interface on the standby ASA has an IP address of 0.0.0.0. So, if the outside interface of one of the ASAs goes down (and the interface does not transition to a down state), there is no way the other one can know it has gone down.

Management of standby ASA

Without a standby IP address, there is no way you can manage (e.g., SSH, HTTPS) that standby ASA from that interface. This may not be an issue for you if, for example, you have a terminal server to which the ASAs are connected and you can access the ASAs through the terminal server. Also, you may not even be interested in accessing the ASAs from the outside to begin with.

Possible Solution 3: Clustering

Although I said I will discuss only two solutions, I decided to add this as a third. ASA Clustering was introduced in ASA version 9.0(1) for the ASA 5580 and 5585-X appliances but is now also available for other ASA 5500-X appliances beginning from version 9.1(4). I have never configured clustering but based on research, it should work since the ASAs in a cluster can be configured to use one IP address on a particular interface.

Summary

In this article, we have looked at one of the challenges faced by people who want to configure failover but can’t afford the luxury of standby IP addresses. We have considered two ways this issue can be resolved. We also mentioned a third way, which involves ASA clustering.

I hope you have found this article useful.

Further reading