只要主机不桥接流量，就不存在环路。portfast和bpduguard（思科说，其他供应商可能有其他术语）是通常应用于主机端口的设置。

续流量由可能确保该MAC地址学习：交换机的最基本功能。

一旦主机故障转移到（以前的）备用接口，当帧到达给定的交换机端口时，它发出的以太网帧会自动触发交换机更新它们的 CAM 表。

由于不能确保所有主机的（单播）帧都到达所有交换机，因此在所有交换机更新其表之前可能会有一些轻微的延迟。然而，来自该主机或 VM 的第一个广播或多播帧将被所有交换机看到，并且由于广播确实经常发生，您可能永远不会真正注意到延迟。但是，在某些情况下，管理员可能会遇到“旧的 mac 地址表问题”——正如 Darrel Root 指出的那样。

这就是为什么某些虚拟机管理程序主机具有称为“通知交换机”的功能（例如 VMware ESXi 及其 vSwitches）的原因。如果他们将一个 VM 重新分配给另一个 NIC，例如在 NIC 故障转移或故障恢复的情况下，他们将通过给定 VM 的新上行链路发出一连串 RARP 广播消息，其中包含每个适用的 VM 的 MAC 地址作为源 MAC 地址。所有这些 RARP 都是广播的，因此它们在整个网络（或 VLAN）中传播，所有交换机都可以相应地更新它们的 CAM 表。一旦ESXi看到“线路协议已启动”，就会立即发送这些广播突发，因此拥有portfast或portfast trunk位于 ESXi 的交换机端口是必不可少的。没有portfast [trunk]，交换机端口进入 FWD 模式之前的 30 秒超时将终止所有“通知交换机”的尝试。这种 30 秒的延迟甚至存在于快速生成树环境的非 portfast 端口上。

终端主机通常不使用生成树协议，也不转发 BPDU*，因此交换机上的两个端口都将处于转发状态。您可能会将这些端口配置为主机端口 (portfast)，以便快速生成树正常运行。

在一个方向上进行故障转移后，您可能会在交换机上遇到旧的 Mac 地址表问题，因此请确保在两个方向上测试故障转移。

• 我已经对由于配置终端主机进行桥接而导致的一些网络中断做出了回应。这可能会导致 BPDU 通过主机。

关于 MAC 地址表泛洪的编辑：

如果您在正常操作下（而不是在故障转移后立即）在一台交换机上遭受 mac-address-table 泛洪，这是一个很好理解的问题，并且已经在最佳实践中针对 HSRP 和 ECMP 的组合进行了完整的解释

这是快速摘要：

命名您的设备：

router-left
router-right  (assume this is HSRP primary)
switch-left
switch-right
host-left   (lets assume this one is "standby" right now)
host-right  ("active" right now)

1. 从其他网络入站的流量由路由器左侧和路由器右侧之间的路由协议（OSPF、IS-IS 等）进行负载平衡。
2. 路由器左侧和路由器右侧都是主机右侧的 ARP。
3. （编辑：删除）
4. 主机权限响应两个 ARP 请求
5. 对路由器权限的 ARP 响应填充路由器权限的 ARP 表。它还通过 switch-right 填充其 mac-address-table
6. 对路由器左侧的 ARP 响应填充路由器左侧的 ARP 表。也通过两个交换机填充它们的 mac-address-tables。
7. 来自主机权限的出站流量进入路由器权限（HSRP 主节点）并通过交换机权限，继续刷新其 mac-address-table 中的计时器。但是 switch-left 没有看到这个流量！
8. Cisco 默认的“arp 超时”因平台而异，但我看到文档从 1500 秒到 14,400 秒不等。
9. Cisco mac-address-table 交换机超时为 300 秒。
10. 路由器左侧的初始 ARP 后 300 秒，交换机左侧的 mac-address-table 超时到期。路由器左派ARP还没有到期。所以 switch-left 开始泛滥发往 host-right 的入站网络流量。

我过去使用的解决方案是将 ARP 超时减少到 290 秒或将 mac-address-table 超时增加到 14,500。由于这是一个 HA 故障转移环境，在这种情况下我会减少 ARP 超时，即使这是一个（不方便的）接口配置命令。