1.技术作用

BFD(Bidirectional Forwarding Detection，双向转发检测)是一种快速故障检测机制，常用于IP/MPLS网络中用于链路的连通性检测，为各种上层协议静态路由、Track等)快速检测设备之间的路径故障，早期上层协议常用Hello报文机制来检测故障，所需时间是秒级，在没有路由协议的地方，"Hello"机制也是无效。

BFD为上述问题提出了一种解决方案，一方面它的检测速度达到毫秒级，能用于电信级50ms保护切换切换需求，另外一方面它能够在系统之间的任何类型通道上进行故障检测，这些通道包括直接的物理链路、虚电路、隧道、MPLS LSP、多跳路由通道，以及非直接的通道,正是由于BFD实现故障检测的简单、单一性，致使BFD能够专注于转发故障的快速检测 ,帮助网络以良好QoS实现语音、视频及其它点播业务的传输，从而帮助服务提供商基于IP网的实现，为客户提供所需的高可靠性、高适用性VoIP及其它实时业务。

2.技术原理

对于BFD而言，它本身是没有发现机制的，它是通过被服务的上层协议来建立会话，也就是邻居的参数及检测参数(包括目的地址和源地址等)是由上层协议通告给BFD。BFD得到邻居参数和检测参数之后，开始建立BFD会话，会话建立后会周期性地快速发送BFD报文，如果在检测时间内没有收到BFD报文则认为该双向转发路径发生了故障，通知被服务的上层应用进行相应的处理。

BFD的会话有有以下几种工作方式：

• 异步模式

在这种模式下，系统之间相互周期性地发送BFD控制包，如果某个系统在检测时间内没有收到对端发来的BFD控制报文，就宣布会话为Down。

• 按需模式

在按需模式下，每个系统都有一个独立的方法用来确认它连接到其他系统,一旦BFD会话建立起来以后，系统停止发送BFD控制报文，除非某个系统需要显式地验证连接性，在需要显式验证连接性的情况下，系统发送一个短系列的BFD控制包，如果在检测时间内没有收到返回的报文就宣布会话为Down，如果收到对端的回应报文，协议再次保持沉默。

• 回声功能(ECHO)

回声功能是一种辅助功能，当使能回声功能时，将会发送一个BFD回声报文，远端系统通过它的转发通道将它们环回回来。如果本地系统连续几个回声报文都没有接收到，会话就被宣布为Down，回声功能可以和上述两种检测模式一起使用 。

在现在主流交换机或路由器中，大多只支持异步模式；对于按需模式，该模式的限制比较大，基本上不用于快速检测，故在实际系统中应用很少，笔者也没有发现任何一家主流的交换机或路由器中支持；对于ECHO功能一般也不用于故障检测，作为主动查询远端设备是否在线的一种补充手段。

2.1 报文格式

2.1.1 控制报文

Vers：BFD协议版本号，目前为1

Diag：标明远端BFD系统最后一次会话改变的的原因

Sta：远端BFD系统的本地状态 0 -- AdminDown 1 -- Down 2 -- Init 3 -- Up

P：置为1表示远端系统的参数(一般指发送或接收时间间隔)发生改变，发送请求到对方进行确认，并期望对端回F给予响应；如果置为0，则不请求对方进行确认和响应；

F：响应P标志置位的回应报文中必须将F标志置位

C：转发/控制分离标志，一旦置位，控制平面的变化不影响BFD检测，如：控制平面为ISIS，当ISIS重启/GR时，BFD可以继续监测链路状态。

A：认证标识，置为1表示BFD报文会携带加密的信息到报文中

D：查询请求，置位代表发送方期望采用查询模式对链路进行监测

M：置1表示 point-to-multipoint应用；否则置为0.

Detect Mult：检测超时倍数，用于本地检测远端系统是否存在的计算超时时间。

Length：报文长度，如果A置为0，则等于26.

My Discreaminator：BFD会话连接本地标识符

Your Discreaminator：BFD会话连接远端标识符

Desired Min Tx Interval：向对端声明本地支持的的最小BFD报文发送间隔

Required Min RX Interval：向对端声明本地支持的最小BFD接收间隔

Required Min Echo RX Interval：本地支持的最小报文接收间隔(如果本地不支持Echo功能，则设置0)

Auth Type：认证类型Auth Length：认证数据长度

Authentication Data：认证数据其中认证部分为可选部分，可以在报文中选择使用，其中认证方式可以有：Simple Password、Keyed MD5、Meticulous Keyed MD5、Keyed SHA1、Meticulous Keyed SHA1，一般在现有交换机芯片实现中，都不支持认证部分。

2.1.2 ECHO报文

BFD协议并未定义回声报文的格式，但是对于回声报文，其格式只是与本地相关，远端只需把此报文在反向通道上返回。

2.2. 状态机

每个系统都通过发出的BFD控制报文中的状态域(Sta)来交流各自的状态，并结合收到报文的状态和本地状态来驱动状态机；

• Down状态意味着会话是Down的(或刚刚建立)。会话将保持Down，直到远端系统通过发送状态域为除Up以外的BFD控制包来表明它认同当前的Down状态。如果收到的包是Down，则会话变成Init；如果包是Init，则会话变Up
• Init状态表明远端系统正在通信，本地系统希望会话能变Up，但远端系统并没有意识到这一点。会话将保持在Init状态，直到收到一个状态为Init或Up的BFD控制包(这种情况下会话变为Up)，或直到检测时间超时，意味着和远端系统的通信已经丢失(这种情况下会话变为Down状态) ；
• Up状态意味着BFD会话已经成功地建立，且暗示着两系统间的连通性正常，则会话将保持Up，直到连通性失败，或者会话被管理Down。如果远端系统通告Down状态或检测时间超时，则会话变成Down状态；
• AdminDown状态意味着会话被管理Down，这将导致远端系统进入Down状态，并将保持Down状态直到本地系统退出管理Down状态。

BFD会话建立时状态机的交互过程如下：

2.3 时间协商

BFD会话建立前BFD控制报文以1秒的时间间隔周期发送以减小报文流量。在会话建立后系统两端将重新协商的发送/接收时间间隔，并以协商后的时间间隔发送BFD控制报文以实现快速检测。在BFD会话建立的同时，BFD控制报文发送时间间隔以及检测时间也会通过设置将BFD报文的P/F报文来交互协商确定(会话建立时的时间协商过程参考上图),在BFD会话的不同方向的时间协商是分别独立进行的，其发送时间间隔和接收时间时间是可以不同的。

当本端设备处于up状态，且收到的BFD报文P置为1将进行时间协商，同时立即向对端发送F置为1的BFD报文(P置为0)，当参数改变端接收到F置为1的报文后也将完成最终的时间协商，并且清除本地的P状态，在下一轮发送BFD报文时P将不再置1,其协商的公式如下：

actualTxInterval = MAX(本端的DMTI, 接收到的RMRI )

actualRxInterval = MAX(本端的 RMRI, 接收到的 DMTI)

注: DMTI -Desired Min Tx Interval RMRI-Required Min RX Interval

BFD的各种参数在会话建立起来以后都可以动态的改变，其中可以动态改变的参数有：DMTI、RMRI、DT(Detect Mult)；如果参数改变后可在发送的BFD报文中通过置P为1来告知对方进行时间参数协商而不影响会话状态。

BFD会话期间时间协商的交互过程如下

2.4 故障检测

BFD会话建立及定时器协商完成后，两端会以协商后的发送时间间隔发送BFD控制报文。而在本端则会根据得到的接收间隔和检测倍数(一般为3)来计算远端丢失的检测时间，其检测时间=协商后的接收时间间隔*接收到检测间隔即DetecTime =actualRxInterval * DetectMult,每当收到BFD控制报文时，就会重置检测时间DetecTime ，并保持会话UP状态。如果在检测时间内没有收到BFD控制报文，即DetecTime为0时，BFD会话会迁移到DOWN状态，并产生dLoc,通知该会话所服务的上层应用发生故障，由上层应用采取相应的保护措施。

如果本端BFD会话主动检测到链路故障(如Loc,Linkdown,ErrorDown等)，会主动将本地会话状态改为DOWN，在发给对端的BFD控制报文中的Sta字段就填为1，Diag字段也将修改为1/5/6等引起本段Down的具体原因，当对端的BFD会话收到此BFD报文后，状态机也迁移到DOWN状态。

3.BFD应用

目前针对BFD在IP、MPLS、MPLS TP、VXLAN、TRILL等网络中IETF发布了一序列RFC，目前在主流的交换机厂商中广泛支持IP/MPLS BFD，以及MPLS TP BFD，对于其他BFD由于RFC是最几年才出来的，目前还没有得到广泛的支持，但笔者所在盛科网络研发的交换芯片对下面所列的BFD从硬件层面都得到了很好的支持，包括状态机/时间协商等功能都在都在芯片中进行了实现，在后续的文章中，对于在不同网络中应用的BFD会展开进行阐述。