IP-LINK
三个检测周期15s后未收到响应报文则认为故障
收到三次响应后才认为故障消除
ip-link xxx //创建ip-link
destination 1.1.1.1 interface xxx mode xx next-hop 2.2.2.2
ip-link check enable
tx-interval xx
times xx
display ip-link //显示iplink
IP-link作为一个链路测试工具，只要其他相关的配置具有与IP-LINK联动的功能，那么就可以直接将预先创建好的IP-LINK进行调用。
BFD
BFD是一种会话协商的协议，它不借助其他的网络工具，如IP-LINK它就借助arp或者icmp进行网络链路的检测，但是这些协议的发包熟读并不是十分的快，一般来说链路检测的时间达到的是秒级别，而BFD一般来说可以达到毫秒级别的检测速率，主要原因就是上层的BFD模块的发包速率较常规的网测协议快，在模拟器当中最快可以达到1秒100个BFD报文，虽然能够加快链路检测的速率，但是也为网络带来了十分大的流量负载。下面是BFD的报文格式：
主要关注点分三个部分，第一层灰色部分，第二层白色部分，和第三层的灰色部分。第一层主要的作用就是记录一些BFD的相关状态。主要关注点在第二部分，第二部分记录了自己的标识符，对端的标识符，期望的最小发送速率，需要的最小接收速率，以及期望的最小的回声包的接收速率，这些主要是和对端进行相关BFD包速率的协商。第三部分主要作用就是BFD的认证 。
BFD的主要报文是用UDP报文进行承载，一般来说目的端口是3784，也可以手动地修改为4784，单臂回声地目的端口是3785
BFD的链路检测方式
1、二层组播检测(单跳检测)
所谓二层组播检测主要适用场景就是对端BFD并没有配置三层IP地址，所以BFD采用组播地址224.0.0.184对BFD的报文进行封装，在二层组播检测的情况下，我们并没有指定对端的IP，所以BFD会话的两端的角色并没有清晰的指定出来，所以我们必须在指定为二层组播检测完之后，指定本端的标识符和对端的标识符，这样对端在接收到该组播报文的时候才能知道对端是想和我进行一个BFD会话的建立。也正是因为本端和对端标识符的确定，才确定了BFD会话的两端。
对应的命令：bfd xxx bind peer-ip default-ip interface xxx [ source-ip xxx ] //创建bfd会话
discriminator local/remote 10/20
commit
二层组播检测必须指定相应的BFD报文的发送端口，source-ip是一个可选的配置，因为二层组播检测的主要应用场景是在会话双方没有配置IP地址的场景下。
2、三层网络检测
三层网络检测可以指定本端和对端的标识符，也可以采用自动协商，在单跳的三层网络检测可以不用给出对端和本端的标识符，但是在多跳检测中没有仅给出了对端的IP地址，所以我们需要制定会话双方的标识符。
（单跳检测）
对应的命令：bfd xxx bind peer-ip 192.168.0.1 interface g0/0/0 [auto]
discriminator local/remote 10/20 //制定本端和对端标识，如果配置了auto标识可以不用制定
commit //配置提交
上面这种将对端IP和本端IP以及地址都写出来的bfd会话仅仅只能用在单跳检测，如果有跨路由器的情况就不行了，我做过测试如果将这个命令用于多跳检测，那么它会一直困在arp的阶段，也就是不断地发送arp请求，即便有相应的路由条目也还是会不断地发送arp请求，所以这就导致它只能用在单跳检测。
（多跳检测）
对应的命令：bfd xxx bind peer-ip 2.2.2.2
discriminator local/remote 10/20 //制定本端和对端标识
commit //配置提交
在多跳检测的这种配置下，BFD的相关报文的发送主要依靠路由表，会话双方通过UDP报文进行会话的维持，如果报文在路由的过程中出现不能达到对端的情况，那么就会出现BFD会话失败的情况。
3、单臂回声（单跳检测）
单臂回声的主要应用场景是单跳，且对端不能建立BFD会话的情况下，本端将构造下图的报文想对端发送：
该报文是一种UDP报文，源目IP都是发送端的IP地址，当对端接收到这个报文就会返送给发送端，并由此确定对端是否存活。
对应的命令：bfd xxx bind peer-ip 192.168.0.1 inter g0/0/0 one-arm-echo
discriminator local/remote 10/20 //制定本端和对端标识
commit //提交配置
接口和子接口状态绑定
该功能仅仅适用用二层组播探测，在bfd视图下输入
process-interface-status
process-interface-status sub-if
当相关的BFD会话down后，绑定的接口的协议层面会down掉
BFD的可以适用的接口有很多，比如vlanif接口，子接口，普通网口，eth-trunk口
BFD会话信息的查看
比较常用的display bfd session all verbose / display bfd session peer-ip xxxx verbose
下面列出几个常用的
Name:标识BFD的名称
bind peer ip address
NextHop ：表示下一跳地址，这里我没有制定下一跳的地址，仅制定出接口，所以IP是本端的出口IP
min tx interval ：期望的最小发送间隔
actual tx interval：实际的发送间隔
min rx interval ：期望的最小接收间隔
actual rx interval：实际的接收间隔
proc interface status:只有接口绑定了bfd，才会有显示
bind application:绑定的应用，比如绑定了ospf，这里就会显示ospf
其中为什么会有期望的速率和实际的速率的这两个项呢？主要是因为可能bfd会话两边的发送速率不同，所以我们需要进行协商，所以即便我们设置了期望的速率，最后有可能实际的速率并不和期望的速率相同。
local detect multi：本地检测倍数，用于计算会话失效的时长
detect interval：会话失效的时长
bfd相关速率的协商
实际的发送间隔：max（本端期望的最小发送速率，对端期望的最小接收速率）
因为这里是确定发送间隔，所以间隔越大发送越慢，所以快的一边要和慢的一边妥协，要服从慢的一边的速率，所以取间隔大的一端
实际的接收间隔：max（本端期望的最小接收速率，对端期望的最小发送速率）
这里和上面同理
bfd会话失效时长的计算
max（对端实际的发送间隔，本端实际的接收间隔）*对端的检测倍数
BFD的联动
BFD联动的技术有很多，如下图所示：
比如可以帮助静态路由检测间接链路故障，vrrp的间接链路故障由此来帮助它们及时地进行路由和转发路径的切换，和动态路由协议联动可以帮助这些动态路由协议可以更快的收敛，比较常见的就是OSPF和bfd的联动，OSPF的邻居失效时长默认是40s，这可以说很慢了，如果与bfd联动，那么OSPF检测故障的时间将大大减少。
