随着心跳和keepalived，我一直使用的冗余选项通过将虚拟IP地址移动到新的机器（第3层解决scheme）工作。 新机器发出一个免费的arp告诉networking上的机器，其MAC地址是该IP的新MAC。
是否有任何当前的networking冗余选项使用在机器之间移动的虚拟MAC地址（第2层）以及虚拟IP？ 这对于某些不了解GARP请求的操作系统会很有用。 我发现这个keepalivd线程 （从一个服务器故障用户它发生），但它从2005年。是否有人知道在Linux的虚拟MAC故障转移的当前状态？
VRRP（ RFC2338用于VRRPv2， RFC5798用于支持IPv6的VRRPv3）为每个实例的虚拟路由器使用一个虚拟MAC地址，但是在切换时仍然发送免费ARP。
虽然keepalived VRRP实施忽略规范的这一部分，并简单地使用接口MAC，VRRPd能够使用虚拟MAC。
但是，虚拟MAC的概念与Linux的networking接口概念并不一致， VRRPd进程在接pipe时必须将接口的MAC地址改为虚拟MAC地址，这样可以防止在一个给定的接口上运行多个VRRP虚拟路由器。
当然惠普的各种“VirtualConnect”产品允许您使用预先configuration的MAC或范围的MAC，然后根据需要映射到特定的服务器。 我已经广泛地使用了它，它在我们使用它来预先定义新服务器的以太网和FC环境之前物理服务器到达现场，但它可以以您描述的方式使用。
这完全是OS-gnostic顺便说一句，这是一个虚拟硬件的事情，我不知道一个特定于Linux的方式，而不是通过某种forms的脚本。
CARP为每个IP冗余组使用虚拟MAC地址（类似于VRRP ，但未授权）。 组中的主控主机使用虚拟MAC进行响应。 发生故障转移时，MAC不会更改。 我在Linux上使用过ucarp ，对此非常满意。
编辑：
这不会帮助你（每个人都放弃了！）。 我链接到的Linux CARP实现ucarp实际上并不使用虚拟MAC地址。 最初的OpenBSD实现，但Linux实现不。 在我的部署中，一切都按照我的想法工作，所以我从来没有深入研究过（直到今天上午），才发现Kyle的需求在第2层没有任何用处。
我在Linux HA列表上看到一些关于使用ifconfig在故障转移时为接口分配虚拟MAC地址的讨论。 这听起来不是一个非常糟糕的select，特别是如果你使用的是虚拟硬件，并且可以在其上花费虚拟网卡。