企业官网建设流程全解析

1. 从一个让人抓狂的线上故障说起

做后端开发或者运维的朋友，大概率都遇到过这种场景：两台路由器之间的链路明明物理层是通的，但业务流量就是时断时续，丢包率忽高忽低。你登录设备一看，接口状态是UP，协议状态也是UP，一切看起来岁月静好，但用户那边已经炸锅了。更让人头疼的是，这种故障往往不是持续性的，而是间歇性发作，等你赶到机房或者连上设备的时候，它可能又恢复正常了，查日志也查不出个所以然。

这类问题的根源，很多时候就出在链路故障检测这个环节上。传统的做法是依赖路由协议自身的Hello机制或者硬件层面的载波检测，但这些手段要么检测周期太长，要么只能发现物理层的硬故障，对于中间经过传输设备、光电转换器这类“透明”链路的场景，物理层往往是感知不到远端故障的。这时候，BFD（Bidirectional Forwarding Detection，双向转发检测）就派上用场了。

BFD的核心价值可以用一句话概括：它能在毫秒级别内检测到两台设备之间双向转发路径的连通性故障。注意这里的关键词——“双向”和“转发路径”。它不是去检测某个接口的物理状态，而是实实在在地验证“我从这里发出去的包，能不能到达对面，对面发回来的包，我能不能收到”。这个机制一旦建立起来，上层路由协议或者应用就可以快速感知故障并触发切换，把业务中断时间从秒级压缩到毫秒级。

这篇文章适合谁看？如果你正在做网络设备的开发、测试，或者负责数据中心、企业广域网的运维，又或者你只是对网络协议底层机制感兴趣，想搞清楚BFD到底是怎么在毫秒级完成检测的，那这篇内容应该能给你一些实实在在的参考。我会从BFD的设计动机讲起，把报文格式、状态机、检测模式这些核心机制拆开揉碎，然后给出一个可落地的实现思路，最后分享一些在实际开发和调试中踩过的坑。

2. BFD的设计哲学：为什么不能只靠路由协议自己检测

2.1 路由协议自带的检测机制为什么不够快

在BFD出现之前，网络里检测链路故障主要靠这么几种手段。第一种是硬件载波检测，比如以太网的Link状态、POS口的物理层告警。这种方式最快，物理层一断立刻就能感知，但它有个致命局限：只能检测直连链路的物理状态。如果中间隔了传输设备、微波、卫星链路，或者经过了一层光转电再电转光的转换，物理层的故障信号根本传不回来。

第二种是路由协议的Hello/Keepalive机制。比如OSPF默认的Hello间隔是10秒，Dead Interval是40秒；BGP的Keepalive是60秒，Hold Time是180秒。这意味着一条链路断了，路由协议最长可能要等几十秒甚至三分钟才能感知到，然后才开始重新计算路由。对于现在的实时业务、金融交易、语音视频来说，这个时间完全不可接受。

第三种是ICMP探测或者应用层心跳。这种方式精度可以做得比较高，但它是针对特定目的地址的，无法覆盖所有转发路径，而且ICMP报文在很多网络里会被限速甚至丢弃，可靠性存疑。

2.2 BFD的核心设计目标

BFD的设计目标非常明确，就是要在不依赖任何特定路由协议、不依赖物理介质的前提下，提供一种轻量级、快速、通用的链路故障检测机制。它要满足几个硬性要求：

• 检测时间可配置且足够短：从几十毫秒到几秒，根据网络规模和对收敛速度的要求灵活调整。
• 协议无关：不管是OSPF、BGP、IS-IS还是静态路由，都可以调用BFD来加速故障感知。
• 介质无关：以太网、POS、隧道、MPLS LSP，只要底层能转发IP包或者MPLS标签包，BFD就能跑。
• 开销小：BFD报文本身非常短，固定头部只有24字节，加上可选字段也不会超过几百字节，对带宽和CPU的消耗极低。
• 双向检测：必须确认两个方向都能通，单方向能通不算数。

2.3 BFD在协议栈中的位置

理解BFD的定位很重要。它不是一个路由协议，也不是一个传输协议，它更像是一个网络层的“心跳”机制。BFD报文封装在UDP里，目的端口号是3784（单跳场景）或者4784（多跳场景）。单跳场景下，BFD报文的目的IP通常是224.0.0.184这个组播地址，TTL设置为255，这样接收方可以通过TTL来判断报文是否经过了多跳转发。多跳场景下则使用单播地址，TTL通常设置为254。

BFD和上层协议的关系是松耦合的。BFD本身不关心上层跑的是什么协议，它只负责检测“到某个邻居的转发路径是否通”。上层协议通过一个叫做“BFD会话”的逻辑通道来订阅检测结果。一旦BFD检测到故障，它会通知所有订阅了该会话的上层协议，各个协议再各自决定怎么处理——OSPF会立刻撤销邻居关系，BGP会重置会话，静态路由会切换到备份路径。

这种设计的好处是显而易见的：检测机制和路由计算解耦，各司其职。BFD专注做快速检测，路由协议专注做路径计算，两者通过一个清晰的接口交互。

3. BFD报文格式与状态机：毫秒级检测的底层逻辑

3.1 报文头部逐字段拆解

BFD的控制报文格式是理解整个协议的基础。它的固定头部是24字节，结构非常紧凑。我按字段顺序逐个说明：

• Version（3比特）：协议版本号，目前标准版本是1。
• Diagnostic（5比特）：诊断码，用来指示会话最后一次状态变化的原因。比如0表示“无诊断信息”，1表示“检测时间超时”，3表示“邻居信号会话Down”。这个字段在排障时非常有用，能告诉你会话为什么断。
• State（2比特）：当前会话状态，取值0到3，分别对应AdminDown、Down、Init、Up四个状态。
• Poll（1比特）：轮询标志。置1时表示发送方请求对方立即回复一个报文，用于快速确认连通性。
• Final（1比特）：最终标志。置1时表示这是对Poll请求的响应，接收方收到后不再需要回复。
• Control Plane Independent（1比特）：控制平面独立标志。置1表示BFD会话的检测不依赖于控制平面的状态，即使控制平面故障，转发平面仍然能独立完成检测。
• Authentication Present（1比特）：认证标志。置1表示报文携带了认证字段。
• Demand（1比特）：需求模式标志。置1表示启用了需求模式，这是一种特殊的检测方式，后面会详细讲。
• Reserved（1比特）：保留位，发送时置0，接收时忽略。
• Detect Mult（8比特）：检测倍数。这个字段和协商的发送间隔一起决定了最终的检测时间。检测时间 = 接收到的Desired Min TX Interval × Detect Mult。
• Length（8比特）：BFD报文的整个长度，单位是字节。
• My Discriminator（32比特）：本地会话标识符。每个BFD会话在本地设备上有一个唯一的非零标识符，用来区分不同的会话。
• Your Discriminator（32比特）：对端会话标识符。这是从对端收到的My Discriminator值，用来告诉对方“我在回复你的哪个会话”。
• Desired Min TX Interval（32比特）：本地期望的最小发送间隔，单位是微秒。
• Required Min RX Interval（32比特）：本地要求的最小接收间隔，单位是微秒。这个值告诉对方“我最快能每多少微秒处理一个报文”。
• Required Min Echo RX Interval（32比特）：本地要求的最小Echo接收间隔，单位是微秒。如果为0，表示本地不支持Echo功能。

这些字段里，My Discriminator和Your Discriminator是会话匹配的关键。两个设备之间可能同时存在多个BFD会话，靠这两个字段来区分。Desired Min TX Interval和Required Min RX Interval的协商过程决定了实际使用的发送和接收间隔，这个协商逻辑是BFD实现中最容易出错的地方之一。

3.2 会话状态的四个阶段

BFD会话的状态机有四个状态：AdminDown、Down、Init、Up。状态迁移的逻辑如下：

• AdminDown：管理员手动关闭了会话。在这个状态下，设备不发送BFD控制报文，或者发送的报文里State字段为AdminDown。
• Down：会话初始状态，或者检测到故障后的状态。在这个状态下，设备会周期性发送BFD控制报文，State字段为Down。
• Init：本端已经收到了对端的Down报文，正在等待对端也进入Init状态。这个状态是一个中间过渡态。
• Up：会话建立成功，双方都在正常收发BFD控制报文，检测机制正式生效。

状态迁移的典型过程是这样的：A和B两个设备都配置了BFD会话，初始都是Down。A发送State=Down的报文，B收到后，发现报文里的Your Discriminator和自己的My Discriminator匹配，于是B把状态从Down迁移到Init，并发送State=Init的报文。A收到State=Init的报文后，也把自己的状态从Down迁移到Init，并发送State=Init的报文。B收到A的Init报文后，状态从Init迁移到Up。A收到B的Up报文后，状态也从Init迁移到Up。至此，会话建立完成。

这个过程中有一个容易混淆的点：Init状态的含义是“我收到了你的Down，我知道你还没收到我的报文”。所以当双方都进入Init之后，实际上已经确认了双向连通性，接下来就是确认双方都知道了对方的存在，于是迁移到Up。

3.3 检测时间的协商与计算

BFD的检测时间不是单方面决定的，而是双方协商的结果。具体来说：

• 本端的实际发送间隔= max(本端Desired Min TX Interval, 对端Required Min RX Interval)。
• 本端的实际检测时间= 对端实际发送间隔 × 本端Detect Mult。

举个例子：A的Desired Min TX Interval是100ms，Required Min RX Interval是100ms，Detect Mult是3。B的Desired Min TX Interval是200ms，Required Min RX Interval是50ms，Detect Mult是5。

那么A的实际发送间隔 = max(100ms, 50ms) = 100ms。B的实际发送间隔 = max(200ms, 100ms) = 200ms。A的检测时间 = 200ms × 3 = 600ms。B的检测时间 = 100ms × 5 = 500ms。

这个协商机制保证了双方都能以自己的能力处理报文，同时检测时间由接收方的Detect Mult决定，发送方无法单方面缩短检测时间。这种设计避免了某一方因为处理能力不足而误判故障。

注意：Detect Mult的最小值是1，但实际部署中通常建议至少设置为3。设置为1意味着只要丢一个包就判定故障，在网络抖动或者CPU繁忙时极易误报。

4. BFD的两种检测模式：异步模式与需求模式

4.1 异步模式：最常用的检测方式

异步模式是BFD最基础、最常用的检测模式。它的工作方式很简单：双方都周期性地发送BFD控制报文，如果在检测时间内没有收到对方的报文，就判定会话Down。

这种模式的特点是：

• 实现简单，逻辑清晰。
• 检测时间由双方的发送间隔和Detect Mult共同决定。
• 每个方向独立检测，A检测B是否活着，B也检测A是否活着。
• 报文开销与发送间隔成反比，间隔越短，开销越大。

在实际部署中，异步模式适用于绝大多数场景。比如两台路由器之间的直连链路、数据中心内部的Leaf-Spine互联、企业分支和总部之间的广域网链路，都可以用异步模式。

异步模式的一个变种是带Echo功能的异步模式。Echo功能的设计目的是进一步降低设备CPU的负担。它的原理是：本端发送BFD Echo报文，这个报文的目的地址是本端自己，但通过转发路径被送到对端，对端收到后直接把它环回来。如果本端在检测时间内收到了环回来的Echo报文，就说明转发路径是通的。

Echo报文的好处是对端不需要参与BFD状态机，它只是简单地把报文环回，不需要解析BFD头部，也不需要维护会话状态。这样对端的CPU负担大大降低。但Echo功能也有局限：它依赖于对端的转发平面能够正确环回报文，如果对端有ACL或者策略路由把Echo报文丢了，就会误判。而且Echo报文是UDP报文，目的端口是3785，很多网络设备默认不处理这个端口的报文。

4.2 需求模式：按需检测的取舍

需求模式是一种更“激进”的检测方式。在需求模式下，双方约定不再周期性发送BFD控制报文，而是在需要确认连通性的时候，由一方发送一个Poll置1的报文，另一方收到后回复一个Final置1的报文。如果发送方在检测时间内没有收到回复，就判定故障。

需求模式的优势是大幅减少报文开销。在链路稳定的情况下，几乎没有BFD报文在网络上传输。但它的缺点也很明显：

• 检测的实时性依赖于Poll的触发时机。如果上层协议不主动触发Poll，BFD就无法及时发现故障。
• 实现复杂度更高，需要和上层协议紧密配合。
• 如果Poll报文本身丢了，会导致误判。

因此，需求模式在实际部署中远不如异步模式常见。它更适合那些对带宽极其敏感、但又需要快速检测的场景，比如某些低速链路或者卫星链路。

4.3 两种模式的对比与选型建议

我的建议是：除非有明确的带宽限制或者特殊需求，否则一律优先选择异步模式。异步模式的实现成熟、调试方便、行为可预测，出了问题也容易排查。需求模式看起来省带宽，但省下来的那点带宽对于现在的网络来说微不足道，反而增加了不确定性和排障难度。

5. 从零实现一个BFD会话：核心模块与关键代码逻辑

5.1 整体架构设计

实现一个BFD会话，从软件架构上可以拆成几个核心模块：

• 报文收发模块：负责BFD报文的封装、解封装、发送和接收。需要处理UDP socket的创建、组播加入、TTL设置等。
• 会话管理模块：维护每个BFD会话的状态、配置参数、统计信息。负责会话的创建、删除、状态迁移。
• 定时器模块：BFD的核心是定时器。需要实现发送定时器和检测定时器，精度要求较高，通常需要毫秒级。
• 状态机模块：实现BFD的状态迁移逻辑，根据收到的报文和定时器超时事件驱动状态变化。
• 上层接口模块：提供API给路由协议或者其他应用，用于订阅BFD会话状态变化。

这几个模块之间的关系是：报文收发模块收到报文后，交给会话管理模块找到对应的会话，然后驱动状态机模块进行状态迁移。定时器模块在发送间隔到达时触发报文发送，在检测时间超时时触发故障判定。状态机模块的状态变化通过上层接口模块通知订阅者。

5.2 报文收发的关键细节

BFD报文的收发有几个容易踩坑的地方。首先是组播加入。单跳BFD使用224.0.0.184，设备需要在这个组播地址上监听。有些操作系统或者网络栈对组播的处理比较特殊，需要显式地加入组播组，并且设置正确的接口。

其次是TTL的设置和校验。单跳BFD报文的TTL必须设置为255，接收方收到后要检查TTL是否为255。如果不是，说明报文经过了多跳转发，应该丢弃。这个检查是为了防止BFD报文被意外转发到非直连的邻居。多跳BFD的TTL通常设置为254，接收方检查TTL是否大于某个阈值。

第三是源地址的选择。BFD报文的源地址应该是本地接口的地址，目的地址是组播地址或者对端单播地址。如果源地址选择错误，对端可能无法正确匹配会话。

下面是一个简化的BFD报文发送逻辑的伪代码：

def send_bfd_packet(session): packet = BfdPacket() packet.version = 1 packet.diag = session.diag packet.state = session.state packet.poll = session.poll_flag packet.final = session.final_flag packet.control_plane_independent = session.cpi packet.auth_present = 0 packet.demand = session.demand_mode packet.detect_mult = session.detect_mult packet.length = 24 packet.my_discriminator = session.local_discriminator packet.your_discriminator = session.remote_discriminator packet.desired_min_tx_interval = session.desired_min_tx_interval packet.required_min_rx_interval = session.required_min_rx_interval packet.required_min_echo_rx_interval = session.required_min_echo_rx_interval raw = packet.serialize() sock = get_bfd_socket(session.interface) sock.sendto(raw, (session.dest_addr, 3784))

接收端的逻辑需要做几件事：解析报文、校验版本和长度、检查TTL、根据My Discriminator和Your Discriminator找到对应的会话、更新会话的远端参数、驱动状态机。

5.3 定时器的精度与实现

BFD对定时器的精度要求比较高。如果发送间隔是50ms，检测倍数是3，那么检测时间是150ms。如果定时器精度不够，比如实际发送间隔变成了60ms，检测时间就变成了180ms，虽然还能工作，但检测精度下降了。更严重的是，如果检测定时器延迟触发，可能会导致误判故障。

在Linux环境下，实现毫秒级定时器有几种选择：

• timerfd：Linux特有的定时器接口，可以配合epoll使用，精度较高，适合高并发场景。
• POSIX timer：可移植性好，但精度和开销取决于实现。
• 时间轮：适合大量定时器的场景，但实现复杂度较高。
• 忙等待+时间检查：精度最高，但CPU占用大，不推荐。

我的经验是，对于BFD这种定时器数量不多但精度要求高的场景，timerfd配合epoll是比较好的选择。每个会话的发送定时器和检测定时器各用一个timerfd，在epoll循环里统一处理。这样既能保证精度，又不会占用太多CPU。

注意：BFD的发送间隔和检测时间都是微秒单位，但实际实现中很难做到微秒级精度。通常能做到毫秒级就已经很不错了。在协商参数时，如果本端无法支持对方要求的微秒级间隔，应该通过Required Min RX Interval字段告知对方自己的实际能力。

5.4 状态机的实现要点

状态机的实现看起来简单，但有几个细节容易出错。第一个是状态迁移的触发条件。BFD状态迁移由两类事件触发：收到报文和定时器超时。收到报文时，要根据报文里的State字段和Your Discriminator字段来决定是否迁移。定时器超时时，直接判定会话Down。

第二个是AdminDown状态的处理。当管理员关闭会话时，本端进入AdminDown状态，并发送State=AdminDown的报文。对端收到后，应该把会话状态迁移到Down，而不是Init。这个逻辑和普通的Down/Init迁移不同，需要单独处理。

第三个是Diag字段的更新。每次状态迁移时，都要更新Diag字段，记录迁移的原因。比如从Up迁移到Down时，如果是因为检测超时，Diag应该设置为1；如果是因为收到了AdminDown报文，Diag应该设置为3。这个字段对于后续排障非常重要。

下面是一个简化的状态机处理逻辑：

def handle_bfd_packet(session, packet): if packet.state == ADMIN_DOWN: session.state = DOWN session.diag = 3 return if session.state == DOWN: if packet.state == DOWN: session.state = INIT session.diag = 0 elif packet.state == INIT: session.state = UP session.diag = 0 elif session.state == INIT: if packet.state == INIT: session.state = UP session.diag = 0 elif packet.state == DOWN: session.state = DOWN session.diag = 0 elif session.state == UP: if packet.state == DOWN: session.state = DOWN session.diag = 0 elif packet.state == INIT: session.state = DOWN session.diag = 0 session.remote_discriminator = packet.my_discriminator session.remote_desired_min_tx = packet.desired_min_tx_interval session.remote_required_min_rx = packet.required_min_rx_interval session.remote_detect_mult = packet.detect_mult update_timers(session)

这个逻辑里，update_timers函数会根据协商后的参数重新计算发送间隔和检测时间，并更新定时器。这是BFD实现中最容易出bug的地方，因为协商逻辑涉及多个参数的比较和取最大值/最小值。

6. 实际部署中的坑与调试经验

6.1 会话建立不起来的常见原因

在实际调试BFD的时候，最常见的问题就是会话一直停留在Down或者Init状态，无法迁移到Up。根据我的经验，原因通常集中在以下几个方面：

第一，Discriminator不匹配。BFD会话的匹配依赖于My Discriminator和Your Discriminator。如果本端发送的Your Discriminator和对端的My Discriminator不一致，对端就会丢弃报文。这种情况通常发生在会话刚创建、双方还没有交换过Discriminator的时候。解决办法是确保初始状态下Your Discriminator为0，收到对端报文后再更新。

第二，组播加入失败。如果设备没有正确加入224.0.0.184组播组，就收不到对端发送的BFD报文。这个问题在Linux上尤其常见，因为默认情况下组播是关闭的，需要显式地通过setsockopt加入组播组，并且指定正确的接口。

第三，TTL校验失败。如果BFD报文的TTL不是255，接收方会丢弃。有些网络设备在转发BFD报文时会修改TTL，或者因为路由配置导致报文经过了额外的跳数。检查方法是抓包看TTL值。

第四，防火墙或者ACL拦截。BFD使用UDP 3784端口，如果中间有防火墙或者ACL规则没有放行这个端口，报文就会被丢弃。这个问题的排查方法是看双方的收发计数，如果一方发了但另一方没收到，基本就是被拦截了。

第五，发送间隔和检测倍数不匹配。如果一方的发送间隔是100ms，另一方的检测倍数是1，检测时间是100ms，那么只要有一个报文稍微延迟一点，就会误判故障。建议双方的参数配置保持一致，或者至少保证检测时间有足够的余量。

6.2 误判故障的排查思路

BFD误判故障是另一个让人头疼的问题。明明链路是通的，业务也没问题，但BFD会话就是时不时Down一下，然后马上又Up。这种抖动会导致路由协议频繁切换，业务流量跟着震荡。

排查误判故障，我通常按这个顺序来：

1. 看BFD会话的统计信息：收发包计数、错误计数、状态迁移次数。如果状态迁移次数很高，说明确实在频繁抖动。
2. 抓包分析：在双方设备上同时抓包，看BFD报文的实际发送间隔和到达间隔。如果发送间隔不稳定，说明本端定时器有问题；如果到达间隔不稳定，说明中间链路有抖动或者有QoS策略影响了BFD报文。
3. 检查CPU负载：如果设备CPU负载很高，BFD报文的处理可能会被延迟，导致检测超时。这时候需要优化BFD的实现，比如把BFD处理放到高优先级线程，或者使用Echo模式减轻对端负担。
4. 检查链路质量：如果链路本身有丢包或者抖动，BFD自然会频繁超时。这时候需要先解决链路质量问题，或者适当放宽BFD的检测参数。
5. 检查QoS配置：有些网络设备会对UDP报文进行限速或者优先级调整，BFD报文如果被限速，就会导致检测超时。确保BFD报文被标记为高优先级。

注意：BFD的检测时间越短，对链路质量和设备性能的要求就越高。在配置BFD参数时，不要一味追求毫秒级，要根据实际链路质量和设备处理能力来设置。一般来说，检测时间设置在300ms到1秒之间是比较稳妥的。

6.3 与上层协议联动的注意事项

BFD本身只是一个检测机制，它的价值在于和上层协议联动。在实际部署中，有几个联动细节需要注意：

第一，BFD会话的创建和删除要与上层协议同步。比如OSPF邻居建立时创建BFD会话，邻居断开时删除BFD会话。如果BFD会话没有及时删除，会浪费资源，还可能导致误报。

第二，BFD状态变化要快速通知上层协议。BFD检测到故障后，应该立即通知所有订阅者，而不是等到下一个周期。通知机制可以是回调函数、消息队列或者事件总线，关键是延迟要低。

第三，上层协议要对BFD状态变化做去抖处理。BFD可能会因为瞬时抖动而短暂Down，如果上层协议一收到Down就立刻切换路由，可能会导致不必要的震荡。建议上层协议在收到BFD Down通知后，等待一个短暂的抑制时间（比如100ms到500ms），如果BFD恢复Up就取消切换，如果仍然Down就执行切换。

第四，BFD会话的AdminDown和物理Down要区分处理。AdminDown是管理员主动关闭，不应该触发路由切换；物理Down是故障，应该触发切换。上层协议需要根据BFD的Diag字段来判断故障原因。

6.4 性能优化的几个方向

如果BFD会话数量很多，比如几千个甚至上万个，性能就会成为一个问题。优化方向主要有几个：

• 批量处理：把多个BFD报文的发送和接收合并处理，减少系统调用次数。
• 定时器合并：如果多个会话的发送间隔相同，可以用一个定时器统一触发，减少定时器数量。
• 无锁设计：BFD会话的状态更新和报文处理可能在不同线程，使用无锁数据结构或者细粒度锁来减少竞争。
• Echo模式：对于对端设备CPU较弱的情况，启用Echo模式可以大幅降低对端负担。
• 硬件卸载：有些网络芯片支持BFD硬件卸载，把BFD报文的收发和检测逻辑放到硬件里，CPU完全不参与。这是性能最好的方案，但需要硬件支持。

我在实际项目中遇到过BFD会话数量超过5000的场景，当时用的是时间轮+批量发送的方案，CPU占用控制在5%以内，检测精度也能保持在毫秒级。关键是要避免每个会话一个独立线程或者独立定时器，那样开销太大了。

7. 一些个人体会

BFD这个协议看起来简单，但真正实现起来，细节非常多。我刚开始接触的时候，觉得不就是发个心跳包嘛，能有多复杂。结果真正动手写代码的时候，才发现状态机的迁移条件、定时器的精度、参数的协商逻辑，每一个环节都有坑。尤其是参数协商那块，Desired Min TX Interval和Required Min RX Interval的交互逻辑，我反复看了好几遍RFC才彻底搞清楚。

另一个体会是，BFD的调试非常依赖抓包。很多问题光看日志是看不出来的，必须抓包看实际的报文交互。我建议在开发BFD功能的时候，把抓包工具常备在手边，遇到问题先抓包，看报文有没有发出去、有没有收到、字段对不对、TTL对不对。大部分问题都能通过抓包定位。

最后，BFD的参数配置不要照搬网上的模板。不同的网络环境、不同的设备性能，适合的参数是不一样的。我的经验是，先从比较保守的参数开始（比如发送间隔200ms，检测倍数5），观察一段时间，确认稳定后再逐步收紧。如果一上来就配50ms×3，很可能因为链路抖动或者设备性能不足导致频繁误判，反而影响业务。