Home / server / Questions / 456501
Accepted
user76678
Asked: 2012-12-10 02:19:42 +0800 CST

Newbie questions on MAC and high availability failovers

  • 772

I am reading about High Availability and I can not understand the following I read: On failover the primary IP migrates to the backup server BUT so must the MAC address.

Specifically I read that every machine has a unique address MAC that can be used by all interfaces in the machine. I don't get this part. Doesn't the MAC belong to the NIC? What is meant by interfaces in this sentence?

Also on failover the clients must update their IP/MAC mapping and found 3 ways for this one of which is by using a custom MAC and move it from primary to backup along with the public IP. How is this possible? Do high availability software e.g. Pacemaker do this? How?

linux

4 Answers

  1. Best Answer

    The book is correct, however there are pieces it left out.

    • MAC addresses are not as fixed as you would think, most higher end NICs have the ability to change the MAC address to something specific. Either in the NIC's BIOS or in the driver itself.
    • There are specific ranges of MAC address set aside for 'virtual' systems (see What range of MAC addresses can I safely use for my virtual machines?)
    • Clustering software may use MAC addresses from these set-aside ranges to present the cluster IP services.
    • The linux network stack has the ability to create virtual NICs with specific MAC addresses.

    The procedure followed by clustering software to create a service based on a virtual MAC address is pretty straight forward. When the service comes up, it offers a Gratuitous Arp packet saying that the specific IP address can be found on the virtual MAC address. When failover happens, the 'down' node removes its local IP/MAC binding and the new node starts listening to that virtual MAC address and IP combination. No muss no fuss.

    The other method used by clustering software is to not bother with virtual MACs at all and rely on Gratuitous ARP the whole way. The startup/failover sequence for such a system would look like:

    1. cluster software binds IP to Node A.
    2. Node A G-ARPs "192.168.244.60 is on 02-00-ab-cd-ef-01"
    3. All devices on the subnet update their ARP tables.
    4. Time passes.
    5. Node A crashes.
    6. Cluster software binds IP to Node B.
    7. Node B G-ARPs "192.168.244.60 is on 02-00-ab-cd-41-ba"
    8. All devices on the subnet update their ARP tables.

    In my experience the second method, pure G-ARP, is the one used by most linux clustering these days. However, both methods are valid and have been used. The benefit of the G-ARP method is that you don't have to muck about assigning virtual MAC addresses. The benefit for the pure virtual-MAC method is that it doesn't rely on G-ARP working on a given subnet.

    • 5

  2. This sounds like you find pretty bad reading material. Mind posting a reference?

    In general: the OSI layer model solves most of those problems and you should almost never have to work on multiple layers at once.

    A MAC address may only appear once in an Ethernet segment. On physical machines those are globally unique and never appear twice (not even on multiple NICs on the same machine). With virtual machines you set the MAC by software and have to use some of the private MAC ranges similar to the private IP ranges.

    For high availability of IPs it is sufficient to configure an IP on a different host. The operating systems and network infrastructure on layer 2 will take care of updating their MAC/IP mappings automatically.

    However, some equipment is stubborn and needs "gratuitous" ARP requests to force them to update their caches.

    On Linux I use "ucarp" with additional scripting to automatically configure machines with those "cluster" IP.

    • 1

  3. You might be mixing up two forms of High Availability or Load Balancing.

    Linking bonding does (can) assign the same IP address to multiple interfaces on the same host.

    For cluster load balancing with HA the machines are all assigned the same IP, with different MACs. One machine will receive all the traffic, but it can forward it to other machines, who can respond directly because they have the same IP. If the master machine fails, a new one is elected, and a gratuitous ARP is done to notify devices that a new machine has the IP.

    • 1

  4. In some HA scenario, on a HA event, only the IP address is taken back by the standby node. In this case, the standby node needs to broadcast an unsolicited ARP packet to update the ARP tables of device on the same Ethernet segment. On reception of an unsolicited ARP packet, a device usually does not directly update its ARP table (it would allow easy hacking of a network) but invalidates its ARP entry on the corresponding IP address. The next time the device needs to talk to the HA service, it will do a ARP request to get the MAC corresponding to the IP address.

    In some other HA scenario (as some routers and firewalls), both the MAC and the IP address are taken back by the standby node. This allows the clients on the same Ethernet segment to keep their ARP table intact, but it does not mean that the standby node can save its ARP broadcast (or some other form network traffic). In this case, the ARP broadcast (or other network traffic) is needed to update the switch MAC-to-port table so the traffic does not end on the dead device port.

    You can read this for a more (detailed inner working of switches)[How does network sniffing software work over a switch?.

    • 0