正常的重复寻址防御应该处理这种特殊情况。

具体来说，当客户端将 .2 分配给某个服务器时，这与第二个路由器上已经存在的 .2 发生冲突，服务器在尝试启动接口时会产生错误，几乎所有操作系统都对此进行了测试。错误配置的服务器通常会在它出现时为其自己的地址进行 ARP，并且您的 VRRP 路由器将回答真实和虚拟路由器的地址。

如果有一个 DHCP 服务器意外地发出 .2 ，应该会发生类似的事情，因为 DHCP 服务器应该在租用地址之前 ping 或 ARP。

如果您控制交换机，您可以将路由器的地址锁定到它们的以太网地址或使用其他防御措施；从路由器的角度来看，这看起来就像是由错误配置的主机发起的 ARP 欺骗攻击。

最后，我相信您的主路由（到虚拟地址）将继续工作，即使物理地址被错误配置的主机接管，因为 VRRP 路由器间通信是通过多播进行的。

总的来说，我认为考虑任何可能的操作错误是明智的。在这种特殊情况下，我会使用您的实际设备将其设置在工作台上，并尝试一些非常糟糕的客户端配置。

我倾向于同意@jonathanjo 但除此之外：

它经常被放弃，但 VRRP - 与 Cisco HSRP 相反 - 不要求接口的主地址与虚拟地址属于同一网络。（实际上，一个 VRRP 通告包可以包含多个虚拟 IP 地址）。

因此，您还可以将您想要的任何 IP 分配给路由器，从而完全避免该问题。

一个简单的、手工打造的想法：

今天可以免费使用 .2 和 .3（或您计划稍后用于 VRRP 的任何地址）吗？

然后立即获取它们，并在其中ip address <ip> <mask> secondary一台路由器的当前接口上将它们配置为 IP 别名（或在 Cisco 语音中）。

如果这与当前的 VRRP 设置不能很好地混合，请考虑将 VRF/路由实例添加到具有单个附加接口的路由器，将 .2 和 .3 分配给该接口，并将其连接到 LAN 的另一个端口转变。

向该接口添加一个入站流量过滤器，拒绝（不丢弃ping）除 ARP 和 ICMP Echo 请求之外的所有流量到接口 IP，因此任何与这些 IP 对话的尝试都将触发从路由器到发起方的 ICMP 不可达。这应该可以帮助大多数客户端软件快速而温和地使其连接尝试失败，而不是遇到超时。

正如 jonathanjo 已经指出的那样，现代操作系统的重复地址检测机制应该可以防止大多数寻址冲突。

冲突可能仍会发生，但它们会使不合作的用户/管理员脱颖而出 [“啊.. 你拿走了 .2？现在新安装的服务器不会......？是的？哦，是的，无论如何，请务必重新访问 17 个月前的寻址指南..."]。

由于地址是辅助地址或位于单独的接口上，因此任何这些冲突都不会损害路由器的当前运行状态。