有什么理由不使用BFD？

在寻求实现双向转发检测（BFD）时，它在计时器调整方面似乎非常灵活，在任何开销方面都轻巧，并且在整体应用方面非常灵活。

因此，例如，如果它可以用于检测以太网上的链路故障，多跳上的MPLS，网络边缘，IGP收敛，隧道等，为什么不能在某些情况下使用它，并且还有其他新兴的替代方法吗？要知道吗？

我只直接知道BFD的一个问题，即CPU需求。我目前正在调查Cisco 7301的问题，与高峰期相比，在高峰时段增加流量时，BFD有时会超时，并且将行程路由到下一个链接。

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

但是，我发现以下信息提示了BFD的其他问题（在此 NANOG演示中，演示中有更多内容，它是一个很好的内容，请仔细阅读！）

有哪些警告？

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

BFD资源需求

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

BFD资源需求（续）

• 可以安全尝试哪些值？
• 根据与几位操作员的交谈，300ms乘以3的倍数（检测到900ms）似乎是一个安全值，可以在大多数设备上很好地工作。
• 这是对某些替代方案的重大改进。

BFD和L2链路捆绑

• BFD不了解底层的L2链路捆绑成员。
• 4x10GigE L2捆绑包（802.3ad）将作为单个L3邻接出现。BFD数据包将在单个成员链路上传输，而不是在所有4个链路上传输。
• 带有BFD的链接发生故障将导致整个L3邻接失效。
• 但是，在某些情况下，发生故障的成员链接可能会导致仅单个BFD数据包被丢弃。后续数据包可能会在工作成员链接上路由。

我已经看到未实施BFD的两个原因：

1. 对此一无所知（我对此感到内gui）。

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

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

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

完善javano答案的几件事：

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

当两个对等点之间存在中间设备时，BFD是一项发明用于检​​测L2连接问题的功能。因此，BFD是故障检测功能。

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

因此，不使用BFD的原因是：-包装盒不支持BFD。-不需要BFD，因为您没有中间设备（请改用udld和carrier-delay）。