（接上一篇文章：网络高可用性技术之一）
9链路检测
随着客户对网络可用性的要求越来越高，当前网络设备一个越来越重要的特征是，必须能快速检测到相邻设备之间的通信故障，这样可以尽快选择一条替代路径，使网络从故障中快速恢复。快速检测相邻设备之间通信故障的要求，故障检测速度很大程度上决定了网络的收敛速度。
一般的故障，如链路up/down、设备断电重起可以很快被物理链路检测到并上报给上层选路协议，但更多深层的故障（如转发引擎故障、链路单通故障等），大部分链路（比如Ethernet）并不能提供相关的检测机制。这时候，故障检测需要依靠上层选路协议以Hello、keepalive等报文实现的软检测机制，往往比较慢。当然，通过缩小报文发送间隔，可以加快故障检测，但这些Hello、keepalive报文都有检测连通性以外的多种用途，结构相对复杂，处理开销也大，报文发送间隔太小时，往往导致CPU不堪重负，且容易引起误报，这是前面章节介绍的路由协议的“Fast Hello”机制的致命缺陷。除了RSVP Hello这种专门设计用来检测连通性的机制外，其他协议的Hello、Keepalive报文，其检测故障的时间实践中都在1秒以上。使用特定协议的Hello、Keepalive机制检测故障的另外一个缺点是报文和具体的协议相关，如果不启用这个协议就不能实现检测，另外，协议差异性也导致难以用硬件作通用的实现。
9.1DLDP链路检测协议
1.DLDP协议简介
当连接两台设备的光纤或铜质以太网线在物理层上是相通的，如果链路两端的端口之一可以收到对方发送的链路层报文，但对端不能收到本端发送的报文，将这种链路定义为设备上的单向链路。由于此时链路物理层处于连通状态，能正常工作，因而物理层的检测机制无法发现设备间通信存在问题。以下图为例，图中所示的光纤连接的错误就无法通过物理层的自动协商等机制发现。单向链路会引起一系列问题，比如生成树拓扑环路等。
DLDP(Device Link Detection Protocol)协议的作用就是在上述情形下，检测单向链路的存在。它负责在通过光纤或铜质以太网线（例如超五类双绞线）连接的交换机上，监控物理线路的链路状态，当发现单向链路后，向用户发送告警信息，并根据用户配置，自动或者手动地关闭相关端口。
DLDP协议是二层协议，与一层（物理层）机制协同工作以监控链路状态。在一层，自动协商机制进行物理信号和故障的检测。如果一端的链路未连通，逻辑链路未启用，DLDP不起作用。如果链路两端在第一层都能独立正常工作，DLDP执行自动协商机制所不能完成的任务，在第二层检测这些链路是否正确连接，关闭不可达端口。第一层和第二层的检测机制的协同工作防止了物理和逻辑的单向连接以及其他协议的失效。
DLDP协议通过与对方交互协议报文（DLDPDU）来识别对端设备，检测链路的连接正确性。端口上DLDP使能后将启动协议状态机，在状态机的不同状态下会发送不同的报文，与对端交互信息以检测单向链路。其中，DLDP通告报文（Advertisement）的时间间隔可由用户配置，以便根据不同的网络环境使DLDP对链路连接错误做出更快的响应。
DLDP能正确工作的前提是，链路两端都正确使能了DLDP功能、双方的DLDP通告报文的发送时间间隔相等、认证方式和密码相同等。
2.DLDP协议报文格式
DLDPDU协议报文格式如下：
各域的含义如下：
1)Destination MAC Address（DA）：DLDPDU的DA地址为我司私有组播地址：010F-E200-0001。
2)Source MAC Address (SA)：根据我司的《以太网MAC地址使用技术规范》，DLDPDU的SA为设备的端口MAC地址，不使用设备的桥MAC地址。
3)类型（Length/Type）：目前我司对以太网II格式封装的协议报文中该值的填写未作任何定义。考虑到设备通过特殊DA来识别DLDPDU，不会与其它的二层慢速协议报文混淆，因而该字段目前采用802.3中为慢速二层协议分配的值0x8809。
4)DLDP标识（Identifier）：该字段主要用于DLDP协议类型的扩展。目前只支持一种类型，该值定义为0x0001。
5)DLDP版本编号（Version Number）：目前的版本号为0x01。
6)DLDPDU 类型（DLDP Type）：目前DLDPDU的类型和取值包括7种类型，各报文的具体含义和用途请参见后述5.7.1小节。
a)0x01：DLDP通告报文（Advertisement）。报文中不带邻居信息，只带本端口信息（包括端口编号和本设备的桥MAC地址、认证模式和认证密码）。通告报文实际上分为普通报文、FLUSH报文和RSY报文三种子类型。这三种通告报文通过PDU中的FLAG域区分。
b)0x02：DLDP探测报文（Probe）。该报文携带本端口的信息，邻居信息可选择是否携带。
c)0x03：DLDP应答报文（Echo）。该报文用于应答对端发送的探测报文，携带有本端口的信息和邻居信息。
d)0x06：DLDP Disabled状态通知报文。该报文不携带邻居信息，只带本端口信息。
e)0x07：DLDP的快速LINK DOWN通知报文。该报文不携带邻居信息，只带本端口信息。
f)0x08：DLDP的自动恢复探测报文（RecoverProbe）。该报文用于端口状态从DISABLE中恢复，不携带邻居信息，只带本端口信息，需要对端以自动恢复应答报文（RecoverEcho）作为响应。
g)0x09：DLDP的自动恢复应答报文（RecoverEcho）。该报文携带本端口信息和邻居信息。
h)其它：无效报文类型。
7)特殊功能标志（FLAG）：主要用于标识特定类型DLDPDU中的报文子类型，目前只有通告报文定义了子类型，示意如下：
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
RSY | Flush | Reserved | | | | | |
特殊功能标志位
lRSY标志：表明本端口处于ACTIVE状态或者本端口的某个邻居的信息老化。
lFlush标志：表明本端口将关闭DLDP协议，触发对端将本端口的信息从邻居信息中删除。
8)认证模式（Auth-mode）：目前支持3种不同的认证模式，其中0x00表示不需要验证认证口令，0x01表示明文发送认证口令，0x02表示以MD5加密方式发送认证口令。
9)认证口令（Password）：如果不需要认证时，该域的值为0。如果为明文发送时，该域放入认证口令的ASCII码。如果为MD5模式，放入认证口令ASCII码的MD摘要。
10)通告时间间隔（Interval）：本设备发送通告报文的时间间隔，等于用户配置值或系统缺省值5s。
11)保留字段（Reserved）：供协议扩展使用，目前该域取值为0。
12)本设备MAC地址（Host MAC Address）：用于识别本端口所在设备的信息，为本设备的桥MAC地址。
13)本端端口编号（Host Port Identifier）：本端口信息的编号。目前采用端口的Portindex。
14)邻居信息（Neighbor Info）：该域携带本端口保留的邻居信息（端口编号和对端设备的MAC地址）生成的MD5摘要，其中前16byte放入端口编号生成的MD5摘要，后16byte放入对端的桥MAC地址生成的MD5摘要。不需要携带邻居信息时，此字段以0填充。
3.定时器
DLDP协议中使用了8个定时器，分别是：
1)Active定时器（active_timer）
时间间隔为1秒。在ACTIVE状态下，每秒发送一个RSY报文，共发送5个。
2)Advertisement定时器（adv_timer）
发送Advertisement报文的时间间隔。可以通过命令行配置。默认值为1秒。
3)Probe定时器（probe_timer）
时间间隔为1秒。在PROBE状态下，每秒发送两个Probe报文，共发送10个。
4)Echo等待定时器（echo_waiting_timer）
时间间隔为10秒。在发送PROBE报文后为每个需要探测的邻居启动一个，如果Echo等待定时器超时还未收到来自此邻居应答本端的Echo报文，则将此邻居状态置为单通，并将状态机转到DISABLE状态，根据用户配置的关闭模式，手动关闭端口或自动将端口设为DLDP Down。
5)邻居老化定时器（neighbor_age_timer）
每个邻居一个，发现新邻居时为其建立邻居表项，并启动老化定时器，每次收到邻居的非Flush报文时都会复位与该邻居表项对应的老化定时器，一旦定时器超时，如果DLDP工作在普通模式，直接删除该邻居表项，并发送RSY报文。如果工作在加强模式，启动加强定时器，主动探测该邻居，如果在Echo等待定时器超时前收到邻居的Echo报文，刷新该邻居表项，否则进入DISABLE状态。
6)加强定时器（enhance_timer）
在加强模式下，一旦邻居老化定时器超时，就会启用加强定时器，每秒发送两个Probe报文，连续发送8个。如果Echo等待定时器超时，仍收不到Echo报文，则进入DISABLE状态。
7)恢复探测定时器（recover_timer）
时间间隔为2秒。处在DISABLE状态下的端口每2秒发送一个RecoverProbe报文，用于检测单向链路是否恢复。
8)DelayDown定时器（delaydown_timer）
端口物理Down后启动DelayDown定时器，等DelayDown定时器超时后才进入INACTIVE状态。该定时器的值可以通过命令行配置。默认值为1秒。
4.协议状态机
DLDP的协议状态机是针对端口运行的，即每个使能了DLDP协议的端口都有自己独立运行的状态机，互不干扰。DLDP在的协议状态机共有7种状态，每种状态的含义如下：
状态 | 说明 |
INITIAL | DLDP未使能时的初始化状态 |
INACTIVE | DLDP已使能但是端口处于物理Down时所处的状态 |
ACTIVE | DLDP已使能且端口物理Up，或者全部邻居信息都老化时所处的一种过渡状态 |
ADVERTISEMENT | 所有邻居双向连通或者处于ACTIVE状态5秒后进入的状态。这是一种没有发现单向链路时的比较稳定的状态 |
PROBE | 发送探测报文检测链路是否为单向链路 |
DELAYDOWN | 端口物理Down后进入的短暂状态 |
DISABLE | 协议检测到单向链路后的状态。如果工作在加强模式下，邻居一旦消失也会进入此状态 |
5.快速LINK DOWN通知机制
在某些情况下，本端端口已经物理Down，但对端却不能检测到此变化。为了避免对端需要经过3倍的Advertisement间隔时间后才能察觉到与本端连接异常，DLDP设置了快速LINKDOWN通知机制。当物理层检测到本端端口Down时，需要调用DLDP模块提供的接口，以尝试向对端发送LINK DOWN报文。如果此时端口Down是由于光纤的Rx线中断，但Tx线完好，那么对端能够收到LINKDOWN报文，进行快速迁移。如果此时Rx和Tx线均断裂，那么对端也会发现线路中断的情况，此时即使LINK DOWN报文发送不成功，也不会出现较长时间内才能检测到连接异常的问题。此机制避免了某些产品无法区别端口Down是由于Rx中断，还是Tx和Rx同时中断的情况。
快速LINK DOWN通知机制提供了一种快速的单通快速检测方法，收到通告报文的设备可立即使端口迁移到DLDP DOWN状态，从而使整个单通检测到端口状态迁移在2秒内完成。即便上图中左边Switch因为某种原因没有收到LINK DOWN通知报文，也会按照正常的协议处理流程，在等待3倍Advertisement时间后进入DLDP DOWN状态。
9.2BFD
Bi-directional Forwarding Detection (BFD) ，即双向转发检测，试图为各种上层控制协议提供一种通用的低开销快速故障检测服务，上层控制协议利用BFD提供的服务来决定自己采取相应操作，比如重新选路。之所以称为双向，是因为BFD通过三次握手机制，能提供链路来回两个方向的连通性检测。BFD可以快速检测到转发路径上的接口和链路故障、节点的转发引擎故障等，并把故障通知上层协议，使上层协议快速收敛。BFD可用于检测任何形式的路径，包括直接相连的物理链路、虚电路、隧道、MPLS LSP乃至多跳的路由通道。甚至对于单向链路，只要有回来的路径，都可以检测。BFD可以适用于任何传输介质和封装格式，可以方便的用软件或硬件实现。
至于工作原理，可以认为BFD是一个简单的Hello协议，和我们熟悉的路由协议的Hello机制类似，只不过更简洁更通用。建立BFD会话的两个系统之间周期性的互发报文，如果在一个商定的时间段内没有收到对端报文，就认为和对端的通信通道出现故障，BFD会话down，并通知上层协议重新选路。为了减少设备负荷，BFD还设计了一些特殊的应用方式，在这些方式下，可以减少BFD报文发送，或者不必周期性的发送BFD报文，只在需要的时候才发送。
BFD标准还没有完全成熟，目前以draft方式存在，不过CISCO、Juniper都有相关实现。下面详细的介绍BFD相关知识。
1.BFD工作模式
BFD提供了两种工作模式，一种是异步模式（Asynchronous mode），这是BFD的基本工作模式。在这种模式下，建立了BFD会话的两个系统之间必须周期性的互发BFD报文，如果某个系统在商定的时间段内一直没有收到对端发来的报文，就认为对端down。
另一种模式称为查询模式（Demand mode）。这种模式假定建立了BFD会话的两个系统之间有其他独立的能暗示连通性的方法，只是在需要的时候才触发BFD进行显式的故障检测。在这种模式下，BFD会话建立后，系统就停止发送BFD报文，只有当系统需要显式确认连通性时，才短时间发送一个BFD报文系列，然后又停止。我们可以设想这样一种应用：在两个点到点链路相连的系统中，如果接口入队列中有报文，系统就默认和对端是连通的，当队列中没有报文时，才触发发送BFD报文系列，显式确认对端是否仍然连通。
查询模式可以大大减少BFD报文的发送和接收，减少系统的CPU负荷，适合于用在系统对负荷较重的情况下（比如BFD会话很多）。查询模式的缺点是故障检测时间不由BFD确定，而是由具体的应用来确定的，这和BFD独立于各种应用的初衷有一定背离。另外，如果要求的故障检测时间小于报文在系统之间的一次来回时间，也不能使用查询模式。
在两种工作模式之外，BFD还提供一项辅助功能，称为回声功能（Echo function）。回声功能在两种工作模式下都可以使用。如果某个系统的回声功能是激活的，那么它发送回声报文，对端把回声报文沿转发路径环回（loop back）回来，如果发送端在一段时间内没有收到回声报文，就认为对端Down。因为回声报文事实上可起到检测连通性的作用，所以在异步模式下可以减少BFD控制报文的发送，在查询模式下甚至可以完全不用发送BFD控制报文，直接使用回声报文检测连通性。
回声报文的优点是只检测转发平面，和控制平面无关，这可以减少报文往返的延迟，能提供更短的故障检测时间。回声报文的形式和应用相关，不过因为它纯粹只检测连通性，报文可以比普通BFD报文更简单，处理开销更小。回声功能可以只在一个方向上激活，我们称某个系统的回声功能是激活的，是指本端能发送回声报文，且对端能环回回声报文。
2.BFD报文封装
BFD报文的详细封装格式和具体的应用相关，比如在IPV4环境下的应用，就使用UDP封装BFD报文，目的端口为3784，源端口在49152到65535之间。不过，不管在什么应用环境下，使用何种具体封装，报文的BFD部分都由两部分组成，一部分是强制必须有的，另一部分是可选的认证部分。
强制部分的格式如下：
可选认证部分：
其中各个字段的含义和作用如下：
lVers：版本字段，目前为版本号1。
lDiag：Diagnostic，诊断字段，说明本地系统最后一次改变BFD会话状态的原因。
ü0 -- No Diagnostic，没有振荡信息。
ü1 -- Control Detection Time Expired，检测时间超时。
ü2-- Echo Function Failed，回声功能失败
ü3-- Neighbor Signaled Session Down，对端通知会话down。
ü4-- Forwarding Plane Reset，转发平面重置。
ü5-- Path Down，BFD监控的路径down。
ü6-- Concatenated Path Down，和BFD监控的路径相连的路径down，路径方向为指向监控路径。
ü7-- Administratively Down，管理员强制down掉BFD会话。
ü8-- Reverse Concatenated Path Down，和BFD监控的路径相连的路径down，路径方向为远离被监控路径。
ü9-31 -- Reserved for future use，保留。
lSta：Status，本地系统认为的BFD会话的状态，两个bit，四种状态：
ü0 – AdminDown，管理员强制down。
ü1 – Down，故障导致的down
ü2– Init，初始化状态。
ü3– Up，up状态。
lP bit：Poll位，如设置，说明发送报文的系统要求确认连通性或者确认参数改变。查询模式时，如果需要显式确认连通性，会发送一系列Poll置位的BFD报文。另外，如果BFD会话的参数改变，两种工作模式下都要求发送Poll置位的报文。
lF bit：Final位，如设置，说明是对Poll置位的BFD报文的回应。
lC bit：Control Plane Independent位，如设置，说明系统的BFD实现和控制平面无关。
lA bit：Authentication Present位，如设置，数码携带验证部分。
lD bit：Demand位，如设置，说明发送报文的系统希望工作在查询模式。
lR bit：Reserved位，保留位，必须为0。
lDetect Mult：Detect timer multiplie，故障检测时间的乘数因子。用这个值乘以协商出的报文发送时间间隔，就得到异步模式下的故障检测时间。
lLength：以字节计的报文长度。
lMy Discriminator：我的区分符，发送报文的系统用它来区分两个系统之间的多个BFD会话，对每个会话唯一，为非零数值。
lYour Discriminator：你的区分符，使用从对端收到的报文的“My Discirminator”字段。初始建立会话或其他情况下，若不知道“Your Discriminator”，填0。
lDesired Min TX Interval：本地系统期望的发送BFD报文的最小时间间隔，单位为微秒（百万分之一秒）。
lRequired Min RX Interval：本地系统希望收到对端发来的BFD报文的最小间隔，单位为微秒（百万分之一秒）。
lRequired Min Echo RX Interval：本地系统希望收到对端发来的Echo报文的最小间隔，单位为微秒（百万分之一秒）。如果这个值为0，表示本地系统不支持接收Echo报文，即不能环回对端发过来的Echo报文。
lAuth Type：如果A bit设置，则表示使用的认证类型。
ü0 – Reserved，保留。
ü1 - Simple Password，简单密码认证。
ü2- Keyed MD5认证。
ü3- Meticulous Keyed MD5认证。
ü4- Keyed SHA1认证。
ü5- Meticulous Keyed SHA1认证。
ü6-255 - Reserved for future use，保留。
lAuth Len：包含认证类型、认证长度和认证数据在内的认证部分的长度，以字节计。
Echo报文的格式和具体的应用相关，比如在IPV4环境中，Echo报文要求封装在UDP中，目的端口为3785，目的地址的选择标准是必须使对端把报文沿原路回送，源地址的选择标准是不会导致对端发送ICMP重定向报文。Echo报文的具体内容不作要求，只要能区分出Echo属于哪个Session即可。
3.BFD工作原理
BFD本身不提供邻居发现机制，所以BFD需要依靠它为之服务的上层应用来提供邻居的地址信息，然后向邻居发送BFD报文。比如，如果在两个相邻的系统上配置了BFD为OSPF应用服务，那么OSPF通过Hello报文发现对端邻居后，就告知BFD对端邻居的地址。
获取对端系统地址后，如果本地系统的BFD是Active角色，那么主动向对端发送BFD控制报文，启动会话建立；如果是Passive角色，那么在收到对端发来的本会话的BFD报文之前，不发送BFD报文。在IPV4和IPV6应用环境下，要求两端系统都必须是Active角色，即主动发起会话连接。
注意：刚启动会话建立时，BFD控制报文必须以较低速率周期性发送，大约在一秒一个的水平。如果一个系统开始启动会话建立，那么它发送的第一个BFD报文中，“My Discriminator”设置为一个本地唯一的整数值，因为不知道对端情况，“Your Discriminator”未知，所以设为为0，Status为down；对端收到后，回应的报文中，“My Discriminator”也设置为对端本地唯一的数值，“Your Discriminator”为刚收到的报文中的“My Discriminator”，Status为“init”；启动会话的系统收到回应报文后，发现自己的“Discriminator”已经在其中的“Your Discriminator”中，知道双向通信已经完成，会话可以UP，发送的报文中会话Status为“UP”， “Your Discriminator”字段拷贝刚收到的报文的“My Discriminator”；对端收到后，也确认双向通信完成，会话状态设为“Up”。于是，三次握手过程完成，会话建立成功。
会话建立成功后，如果本端能支持Echo报文的发送，对端支持Echo报文的环回，那么本端系统可以启用Echo功能。启用Echo功能后，Echo报文可用来检测连通性，如果在商定的时间内没有收到环回回来的Echo报文，那么认为对端故障，会话Down。因为Echo报文有检测连通性的作用，BFD报文的发送可以控制在比较低的速率，比如1秒1个。
如果会话两端系统都打算使用查询模式，那么会话建立后，BFD报文的发送就停止，BFD报文静默期间，系统之间的连通性需要有BFD以外的途径来揭示。如果本地系统想显式确认连通性，那么就会发送一系列Poll置位的BFD报文，对端收到Poll置位的BFD报文，需要立即回送一个Final置位，Poll位清除的报文，本地系统收到这个报文就停止发送Poll置位的BFD报文，如果没有收到会继续发送Poll置位的BFD报文，如果在商定的时间内没有收到Final置位的回应报文，认为对端故障，会话Down。
如果没有启动Echo功能，也不使用查询模式，那么BFD报文的发送速率必须上升到“定时器协商”过程商定的水平，定时器协商在会话建立时就可以完成。
如果查询模式没有启用，且商定的时间内没有收到BFD控制报文，那么系统认为会话Down，在后续发送的报文中，Status字段设为Down。
如果会话Down，那么停止发送Echo报文，BFD控制报文的发送速率也降到启动会话建立时的低速率。如果一个会话被宣告为Down，只有当对端也宣称它自己Down时，即收到对端发送的报文中状态为Init或Down，才能重新UP，这说明会话拆除也是一个有确认过程的三次握手的过程。
如果两个系统之间有多个BFD会话，那么如何区分接收到的BFD报文属于哪个会话？这由接收报文中的“Your Discriminator”字段来确定，把接收报文中的“Your Discriminator”和本地的Discriminator比较，就知道应该归入哪个BFD会话。使用Your Discriminator来确定会话归属，就可以不依附于具体的应用，不依赖于具体的拓扑，即使接收BFD报文的接口发生了变化，或者源地址发生了改变，都可以用“Your Discriminato”来正确的区分会话。不过在实际的应用中，为了提高效率，可能使用其他的手段来区分会话，比如BFD在IPV4/V6环境中，一些实现可能使用UDP源端口号来区分会话。
BFD会话两端的系统都会在它的BFD控制报文中，宣告它能以多快的速度发送BFD报文（Desired Min TX Interval），能以多快的速度接收并处理BFD报文（Required Min RX Interval）。系统将选择以它自己的“Desired Min TX Interval”和接收到的“Required Min RX Interval”中较大的哪个，作为发送BFD报文的间隔，这意味选择两者中速度较慢的作为发送速率，这可以避免接收者CPU负荷过重。
为了避免自同步现象，即在同一时间发送较多BFD报文，要求BFD报文的发送间隔随机减小0-25%，这意味着平均的发送间隔可能比协商的要小12.5%。
知道了BFD报文发送间隔，就很容易计算检测时间（Detect time），检测时间指的是检测出对端出现故障的时间，即如果超过了检测时间，一直没有收到对端的BFD报文，就认为对端故障，会话状态置为Down。在异步模式和查询模式下，检测时间计算有一些差别。
异步模式时检测时间＝ 接收到的对端“Detect Mult”* 协商的对端报文发送间隔。注意，这里都是指对端，这是因为不同方向上BFD报文发送速率可以不同，我们判断对端是否故障，应该根据对端是否在商定的时间内送达了BFD报文来判断。
查询模式时的检测时间＝ 本端系统的“Detect Mult”* 协商的本端报文发送间隔。这里只所以都用本地的参数，是因为查询模式下，Poll置位的BFD报文系列是由本地系统发送的，对端收到就立即回应Final置位的BFD报文，所以检测时间长短由本端系统参数决定。
如果Detect Mult为1，因为BFD报文发送、传输和接收处理都需要一定时间，所以为了保证检测时间不在收到BFD报文之前就超时，发送BFD报文的时间间隔不应该大于商定间隔的90%。另外BFD报文发送时间间隔不应该小于商定间隔的75％，这是前面避免自同步时，减少发送间隔的下限。
BFD允许随时改变如Desired Min Tx Interval、Required Min Rx Interval等决定BFD报文发送间隔和会话检测时间的参数，而不影响会话。不过当修改了相关参数时，需要作一些合理的处理，避免会话状态的误判：
l如果查询模式激活，则无论改变Desired Min Tx Interval还是改变Required Min Rx Interval，必须发送一个Poll置位的序列，相当于改变参数后作一次显式确认；
l如果查询模式未激活，则无论改变Desired Min Tx Interval还是改变Required Min Rx Interval，所有接下来要发送的BFD控制包都必须将Poll比特置位，直到接收一个F比特置位的报文为止；
ü如果Desired Min Tx Interval增加，那么在接收到一个Final比特置位的报文之前，实际的发送间隔必须不能改变。这是为了确保在本地系统以较慢速度发送报文前，远端系统更新了它的检测时间，否则远端系统可能误判BFD状态。
ü如果Required Min Rx Interval减少，且bfd.SessionState为“Up”，那么在接收到Final比特置位的控制包之前，为远端系统计算的检测时间不能改变。这保证在减少检测时间之前，远端系统已经按照较高的速率发送BFD控制包。
另外，为了避免那些状态不为“Up”的会话消耗过多的带宽，如果bfd.SessionState不为“Up”，则系统必须将bfd.DesiredMinTxInterval设置为一个不小于1秒的值。这个功能是比较有用的，特别如果本端启动了BFD，而对端根本没有启动，那么频繁快速发送BFD会作过多无谓的消耗。
当回声功能激活时，因为实际的连通性检测功能由回声报文完成，BFD控制报文不必频繁发送，这时，系统应该将bfd.DesiredMinTxInterval设置为一个不小于1秒的值。
5.BFD的认证机制
作为通用的故障检测机制，BFD会话状态的判断会影响控制平面协议作出新的选路决策，对网络有较大影响，因此保证BFD会话状态的安全有一定意义。
BFD提供了认证机制来保证会话安全。BFD提供的认证机制有：
lSimple Password，简单密码认证。
lMD5认证：Keyed MD5认证和 Meticulous Keyed MD5认证。
lSHA1认证：Keyed SHA1认证和Meticulous Keyed SHA1认证。
其中只有SHA1是必须实现的。具体的认证情况在本文不作介绍。
6.BFD和GR
在GR中，我们知道，在控制平面故障的情况下，必须转发平面正常，启动GR过程才有意义。而BFD正好可以用于检测转发平面的故障，BFD和GR结合，可以确保，如果转发平面在设备主备切换时不能保持正常，可以快速发现这种异常，尽快退出GR，重新选路。
不过，BFD的实现虽然draft建议在转发平面上实现，但实践中，有些厂商的实现却和控制平面相关，这会在BFD报文的C bit得到体现。如果BFD的实现和控制平面不相关的话，那么BFD状态可用来确定GR是否可进行，如果BFD失败则意味着转发平面失效，应该通知设备撤消GR进程。如果BFD的实现和控制平面相关，BFD的失败可能有多种原因引起，不好判断，比如只是控制平面的重起引起，而数据转发平面仍然正常，这时所以最好不要废止GR进程。
