我只直接知道 BFD 的一个问题，即 CPU 需求。我目前正在调查 Cisco 7301 的一个问题，与一天中的其他时间相比，在高峰时段推送更多流量时，BFD 有时会超时并路由到下一个链接。

似乎在高流量下，路由器 CPU 使用率正在上升（这并不罕见），但大约 40-50% 的 CPU BFD 数据包没有收到足够的资源。

但是，我发现以下信息表明 BFD 存在其他问题（从这个NANOG 演示文稿中，演示文稿中有更多内容，这是一个很好的内容，请阅读！）

有哪些注意事项？

• 两个主要的：
  1. 根据您的规模，BFD 可能具有很高的资源需求。
  2. BFD 对二层捆绑协议不可见。（以太网 LAG 或 POS 包）

BFD 资源需求

• 每个线路卡或路由器上的 BFD 会话数会影响 BFD 为您扩展的程度。- 每个独特的平台都有自己的限制。
• 已经看到支持 250 毫秒或 2 秒的最小 tx/rx 的捆绑接口。
• 在某些情况下，路由器上的 BFD 实例可能需要在路由处理器上运行，具体取决于实现（基于非邻接的 BFD 会话）。
• 在部署 BFD 之前先测试您的平台。尝试使用您配置的设置将负载置于 RP 或 LC CPU 上。这可以通过以下方式完成：
• 执行占用大量 CPU 的命令
• 到 TTL 的泛洪数据包在目标上过期

BFD 资源需求（续）

• 什么值可以安全尝试？
• 根据与几位操作员的交谈，300 毫秒与 3 的乘数（900 毫秒检测）似乎是一个安全值，适用于大多数设备。
• 这是对某些替代方案的重大改进。

BFD 和 L2 链路捆绑

• BFD 不知道底层 L2 链路束成员。
• 4x10GigE L2 捆绑 (802.3ad) 将显示为单个 L3 邻接。BFD 数据包将在单个成员链路上传输，而不是在所有 4 条链路上传输。
• 带有 BFD 的链路故障将导致整个 L3 邻接失败。
• 但是，在某些情况下，故障成员链路可能会导致仅丢弃单个 BFD 数据包。后续数据包可以通过工作成员链路进行路由。

我看到了 BFD 尚未实施的两个原因：

1. 对它的无知（我为此感到内疚有一段时间）。

2. 成本，如果您是一家思科商店。尽管根据您组织的规模可能可以忽略不计，但现在实施 BFD 会产生相关的许可成本。

从 ISR G2/ASR 时间框架开始，BFD 不再包含在“IP Base”许可包中。您必须至少升级到“数据”许可级别才能解锁 BFD。请参阅Cisco 的这份白皮书。

此许可要求可能不是问题，因为您可能已经为其他功能购买了更高的许可级别，但需要注意这一点。

一些事情来完善javano的答案：

• 请记住，40g 和 100g 以太网可以被视为捆绑包，尽管与 LACP 不同，但是 4x10、4x25 和 10x10
• 在某些硬件上（例如一些高端瞻博网络），BFD 是在线路卡上处理的，这可能是一个好处（在高 RE 负载下没有损失）或一个赤字（如果 RE 死了没有立即损失）
• 在已经是 SPOF（例如，单光纤束）的链路/路径上运行 BFD 可能比仅仅增加载波延迟更糟糕

BFD 是一项发明，用于在两个对等点之间存在某些中间设备时检测 L2 连接问题。所以BFD是一个故障检测功能。

如果我们有 2 个路由器通过 L2 交换机 9 或任何其他 L2 云互连，通常我们需要 BFD。在这种情况下，如果单个路由器出现故障，链路状态将不会反映在另一个路由器上，因为交换机会保持链路正常。如果它只是路由器之间的 P2P 链接（单根电缆），则接口将在对等方发生故障时立即关闭，IGP 将在亚秒间隔内重新收敛。

因此，不使用 BFD 的原因是： - 盒子 [es] 不支持 BFD；- 不需要 BFD，因为您没有中间设备（使用 udld 和carrier-delay 代替）。