Benefit from Using Failover MAC Address

In this post I’ll focus on a topic that’s mentioned in the Cisco FIREWALL training class but isn’t emphasized there or in the online Cisco ASA documentation. When configuring failover on a pair of ASA security appliances, a situation can arise in which network disruption occurs due to the secondary ASA in a failover pair becoming active first and then the primary comes online second. Both the documentation and the courseware point out that this causes the secondary (and active ASA) to swap its interface MAC addresses with those of the primary. Being naturally skeptical about this behavior, I decided to investigate. The rest of this post illustrates my confirmation of this phenomenon.

Using a pair of configured ASA 5520 security appliances, I deliberately powered off the primary ASA and rebooted the secondary ASA. As shown below, the secondary ASA was configured to display its hostname, designation (primary or secondary), and role (active or standby). Not surprisingly, as the only powered-on ASA, it became active with the following MAC addresses (superfluous output has been omitted here):

ASA/sec/act(config)# show int
Interface GigabitEthernet0/0 "outside", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
<output omitted>
MAC address 0019.5517.e054, MTU 1500
IP address 200.200.1.2, subnet mask 255.255.255.0
<output omitted>
Interface GigabitEthernet0/1 "inside", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
<output omitted>
MAC address 0019.5517.e055, MTU 1500
IP address 10.10.0.1, subnet mask 255.255.255.0
<output omitted>
Interface GigabitEthernet0/2 "dmz", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
<output omitted>
MAC address 0019.5517.e056, MTU 1500
IP address 172.16.1.1, subnet mask 255.255.255.0
<output omitted>
Interface GigabitEthernet0/3 "lanfail", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
<output omitted>
MAC address 0019.5517.e057, MTU 1500
IP address 192.168.25.4, subnet mask 255.255.255.0
<output omitted>

The output below shows what happened after the primary ASA was powered up:

ASA/sec/act(config)# show int
Interface GigabitEthernet0/0 "outside", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
<output omitted>
MAC address 0019.5517.df18, MTU 1500
IP address 200.200.1.2, subnet mask 255.255.255.0
<output omitted>
Interface GigabitEthernet0/1 "inside", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
<output omitted>
MAC address 0019.5517.df19, MTU 1500
IP address 10.10.0.1, subnet mask 255.255.255.0
<output omitted>
Interface GigabitEthernet0/2 "dmz", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
<output omitted>
MAC address 0019.5517.df1a, MTU 1500
IP address 172.16.1.1, subnet mask 255.255.255.0
<output omitted>
Interface GigabitEthernet0/3 "lanfail", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
<output omitted>
MAC address 0019.5517.e057, MTU 1500
IP address 192.168.25.4, subnet mask 255.255.255.0
<output omitted>

As you can see, the MAC addresses for each of the three traffic passing interfaces changed, but the IP addresses didn’t. This could clearly cause problems with the ARP (Address Resolution Protocol) caches of neighboring devices. To prevent this infrequently observed scenario (or “corner case”), a simple fix is to statically configure a MAC address pair for each traffic passing interface using the actual “burned in” addresses for each ASA. You can do this using either the CLI or the ASDM GUI.