故障转移时间将由两个主要因素决定：

1.) 检测时间 - 连接的系统可以多快确定链接失败。

2.) 收敛时间 - 一旦检测到故障，流量可以多快重定向到工作路径。

老实说，第一项（故障检测）更难做到正确，最终会在过程中增加最多的时间。物理链路丢失显然是一个简单的指标，但重要的是要记住，这只能在一个方向上看到（例如：一根光纤发生故障，而另一条却没有），并且任何类型的干预中继器实际上都可能掩盖这种行为。

为了解决这个问题，最好的机制倾向于使用某种轻量级的回声机制——某种类型的恒定 OAM 流量在连接的对等点之间来回移动以验证数据实际上正在传递。同步通信链接倾向于将其非常有效地合并到基本协议中（SONET 是一个很好的例子），但我们不得不移植技术以适应更高级别的协议——无论是协议 hellos/keep-alives（如发现在路由协议中），或者最近使用了像双向转发检测 (BFD) 这样的轻量级协议，这是在最近的一个问题中提到的。bfd 的想法是使用常见的保活机制（再次 - 非常轻量级），以高频率（通常在数百毫秒内）运行，通常有硬件辅助。

第二部分（再收敛）有很多相关的其他问题，但其难度往往与网络的宽度成正比。例如 - 用一对冗余链路重新聚合两个交换机或路由器之间的连接是微不足道的。在具有数千个网络设备的复杂国际网络上寻找替代路径？完全不同的球赛。顺便说一下，这就是 SONET 的 50 毫秒黄金标准的由来——因为 APS 要求每个节点都有一条备用路径已经很热并准备好接收失败的流量。

所以 - 回答这个问题......最好的情况是链接快速而完全地失败（即有人剪断电缆）。这会立即为两个连接的设备提供结果，并且在实践中，您不会看到从 L3 转发表中删除一对等成本路由中的一个与更新 L2 端口中的哈希表之间的很大差异渠道。

也就是说 - 如果您运行的 L2 端口通道没有检测链接故障的协议，并且一个链接恰好是单向的，那么您很可能会遇到某些部分流量无限期静默丢弃的情况基础（即没有恢复）。如果您依赖 LACP 或 UDLD 来检测这种情况，则可能需要几秒或几十秒的时间来检测（取决于协议的配置方式）。OSPF 的库存配置将需要 40 秒（10 秒保持连接连续丢失 4 次）将链接标记为失败。某些实现上的普通 BGP 连接可能很容易超过 3 分钟。如果您将 BFD 添加到这些协议（LACP / OSPF / BGP）中的任何一个，那么检测时间可能会快到约 150-200 毫秒，但在实际实践中可能更像是现实世界中的 300 毫秒。

那么，在通用硬件的所有条件下，1ms 始终可能吗？可能不会，除非您的硬件能够以两位数的纳秒精度可靠地发送、接收和处理 OA&M 流量（并且保持这种机制稳定存在一系列问题）。真正的问题往往是找出在链路上运行的协议最有意义的收敛速度。对于标准以太网和 IP，在任何情况下（从实际故障到完全恢复）都在 < 250-300 ms 范围内（通常情况下两位数较低）已证明绰绰有余。

STP，包括 RSTP，故障转移速度最慢。

路由协议排在第二位。

到目前为止，最快的故障转移是端口通道。只要端口通道中的一条链路处于开启状态，端口通道就会保持开启状态。端口通道可以是第 2 层或第 3 层端口通道，但最终效果是相同的。