有什么理由不使用BFD？

#1 楼

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

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

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

有哪些警告？


主要有两个：

BFD可能对资源有很高的要求，具体取决于您的规模。
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数据包被丢弃。后续数据包可能会通过
工作成员链接进行路由。

#2 楼

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


它的无知（我有一段时间对此感到内gui）。
成本，如果您是思科商店。尽管根据组织的规模可能可以忽略不计，但实施BFD会产生相关的许可成本。包。您必须至少升级到“数据”许可级别才能解锁BFD。请参阅Cisco的本白皮书。

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

#3 楼

完善javano答案的几件事：


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

#4 楼

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

通常，如果我们有BFD，通过L2交换机9或任何其他L2云互连的2个路由器。在这种情况下，如果单个路由器出现故障，则链路状态将不会反映在另一台路由器上，因为交换机会保持链路保持正常状态。
如果这只是路由器之间的P2P链路（单电缆），则接口将处于故障状态

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