Objective 2.05 on the 301a blueprint requires the candidate to describe use cases for MAC masquerading. MAC masquerading is a feature that allows you to manually allocate a MAC address to a traffic group across a BIG-IP pair configured for High Availability. More specifically this MAC address floats between the devices in a HA pair along with the floating self-IPs and Virtual Addresses within the same traffic group.
Here is a typical network setup before MAC masquerade. Everyone is plodding along happily, all tables have converged and traffic is flowing.
Under failover conditions, the standby unit will become active for the traffic group(s) and send out a GARP for all failover objects in the traffic group(s):
The network infrastructure must now converge on the new topology. The Layer 2 switches will need to flush out their CAM tables for the MAC addresses associated with the floating objects and learn about them via the new interface attached to the previously standby, now active, unit. The Layer 3 devices (routers, firewalls etc.) are not immune to change in this scenario. They too will need to update their ARP tables with the new information.
If we now add MAC masquerade into the mix we should see slightly different behaviour. Configuring a MAC masquerade address is done per traffic group. F5 provide some guidelines on how to craft a unique MAC masquerade address. The steps are:
Here is a typical network setup before MAC masquerade. Everyone is plodding along happily, all tables have converged and traffic is flowing.
Under steady-state conditions the active unit in the HA pair will respond to all ARP requests for all VLANs (within the traffic group) with the MAC address for the appropriate VLAN interface.
Under failover conditions, the standby unit will become active for the traffic group(s) and send out a GARP for all failover objects in the traffic group(s):
The network infrastructure must now converge on the new topology. The Layer 2 switches will need to flush out their CAM tables for the MAC addresses associated with the floating objects and learn about them via the new interface attached to the previously standby, now active, unit. The Layer 3 devices (routers, firewalls etc.) are not immune to change in this scenario. They too will need to update their ARP tables with the new information.
MAC Masquerade Configuration
If we now add MAC masquerade into the mix we should see slightly different behaviour. Configuring a MAC masquerade address is done per traffic group. F5 provide some guidelines on how to craft a unique MAC masquerade address. The steps are:
- Identify the pre-assigned MAC address.
- Convert the first byte of the address to binary.
- Change the second-to-last bit from 0 to 1.
- Convert the binary value back to hexadecimal.
- Replace the first byte of the original MAC address with the new hexadecimal value.
If we take our example topology we have two VLANs in the traffic group. The decision in this scenario of which MAC address to modify and use as the MAC masquerade address is arbitrary. In a production network you may wish to consult your peers. We will use the VLAN 300 interface on the (originally) active unit. So using the steps above we calculate thus:
- Original MAC address = 00:0C:29:8B:B3:45
- First byte to binary = 0000 0000
- Second to last bit from 0 to 1 = 0000 0010
- Binary back to hex = 02
- Replace first byte with new hex = 02:0C:29:8B:B3:45
Now go to Device Management ›› Traffic Groups and click on the traffic group you wish to modify and add into the MAC Masquerade Address box the MAC address above then click Update. Now synchronise the HA pair.
That is all there is to it. The active unit will now send out another GARP request so the network infrastructure can update their tables accordingly. Note that the ARP and MAC address tables will only change for the floating objects. The static self IPs assigned to each BIG-IP device will always remain the same and do not change.
Our converged network topology looks like the following. Notice the ARP table update for the router for the .109 address and the floating self IPs between the HA pairs both use the same MAC address now.
If we were to go ahead and simulate a failover we should find that the Layer 3 devices do not need to update their ARP tables for the floating objects as technically not much has really changed. Of course in the real world it would depend which switch the Layer 3 device connects to. The Layer 2 switches will still need to update their CAM tables as the MAC masquerade address would now be seen on a different port. There may also be a Spanning Tree convergence time penalty to think about, depending on how your network is setup.
Summary
In a lab setting the failover time is negligible, I think I lost one ping. In a production environment, however, you may have hundreds of failover objects and the compounding effect this has with the various table updates could increase failover times. To that end MAC masquerade could help to bring down the failover time. The team that deals with troubleshooting would need to be educated on the new way of working as they would see the same MAC address on each VLAN that carries the failover objects.
Thanks for reading.