- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
13-BFD-GR操作
本章节下载： 13-BFD-GR操作 (336.19 KB)
目 录
本章所指的路由器代表了一般意义下的路由器，以及运行了路由协议的三层交换机。为提高可读性，在手册的描述中将不另行说明。
BFD（Bidirectional Forwarding Detection，双向转发检测）是一套全网统一的检测机制，用于快速检测、监控网络中链路或者IP路由转发的连通状况。为了提升现有网络性能，相邻协议之间必须能快速检测到通信故障，从而更快的建立起备用通道恢复通信。通常采用以下几种检测方法：
l 通过硬件检测信号（如SDH传输系统告警），快速检测到链路硬件上的故障。
l 在没有提供硬件检测信号，或不能通过硬件信号检测出故障时，网络通常采用路由协议中相对比较慢的Hello报文机制，检测到故障的时间超过1秒钟。当数据达到吉比特速率级时，这样长的检测到故障时间将导致大量的数据丢失。
l 用单一的机制对任何介质、任何协议层进行实时检测，并支持不同的检测时间与开销。
BFD提供了一个通用的、标准化的、介质无关、协议无关的快速故障检测机制，可以为各上层协议如路由协议、MPLS等统一地快速检测两台路由器间双向转发路径的故障。
BFD在两台路由器上建立会话，用来监测两台路由器间的双向转发路径，为上层协议服务。BFD本身并没有发现机制，而是靠被服务的上层协议通知其该与谁建立会话，会话建立后如果在检测时间内没有收到对端的BFD控制报文则认为发生故障，通知被服务的上层协议，上层协议进行相应的处理。
l 应用层协议通过自己的邻居发现机制建立邻居后通知BFD建立会话，通知的内容包括协议类型、邻居地址、所在接口、是否直连邻居。BFD收到应用通知消息后开始发送控制报文建立会话。
l 应用层协议禁止BFD功能或者删除邻居时通知BFD删除会话，BFD收到来自应用层的删除会话消息后如果没有其他应用需要监测该段链路，则删除对应的会话。
BFD会话建立后，如果在故障检测时间内没有收到邻居发来的控制报文，则将会话状态置为down，并将会话down的消息通知给创建该会话的协议。
应用协议收到BFD发来的故障通知消息后，说明链路已经出现问题，需要进行邻居down的处理。
& 说明：
BFD草案中没有规定检测的时间精度，目前支持BFD的设备大多数提供的是毫秒级检测。
l 控制报文方式：链路两端会话通过控制报文交互监测链路状态。
l Echo报文方式：链路某一端通过发送Echo报文由另一端转发回来，实现对链路的双向监测。
BFD会话建立前有两种模式：主动模式和被动模式。
l 主动模式：在建立会话前不管是否收到对端发来的BFD控制报文，都会主动发送BFD控制报文；
l 被动模式：在建立对话前不会主动发送BFD控制报文，直到收到对端发送来的控制报文；
在会话初始化过程中，通信双方至少要有一个运行在主动模式才能成功建立起会话。
BFD会话建立后有两种模式：异步模式和查询模式。通信双方要求运行在相同的模式。
l 异步模式：以异步模式运行的设备周期性地发送BFD控制报文，如果在检测时间内没有收到BFD控制报文则将会话down。
l 查询模式：假定每个协议都有一个独立的方法，确认自己连接到其他协议。这样，只要有一个BFD会话建立，协议停止发送BFD控制报文，除非某个协议需要显式地验证连接性。
& 说明：
l 目前仅支持异步模式。
l 目前仅静态路由支持以echo报文方式实现BFD功能，且实现方式与BFD草案存在差异。
l 当BFD会话工作于echo报文方式时，不受运行模式控制。
会话建立后，可以动态协商BFD的相关参数（例如最小发送间隔、最小接收间隔、初始模式、报文认证等），两端协议通过发送相应的协商报文后采用新的参数，不影响会话的当前状态。
BFD提供了三种认证方式，分别是：
l Simple：简单字符认证
l MD5：MD5认证
l SHA1：SHA1认证（Secure Hash Algorithm 1）
BFD控制报文格式如图1-1
图1-1 BFD控制报文格式
l Vers：协议的版本号，协议版本为1；
l Diag：给出本地协议最后一次从up状态转换到其他状态的原因如表1-1；
表1-1 Diag原因描述
|
Diag |
描述 |
|
0 |
无诊断信息（No Diagnostic） |
|
1 |
控制检测超时（Control Detection Time Expired） |
|
2 |
回声功能失效（Echo Function Failed） |
|
3 |
邻居通知会话down （Neighbor Signaled Session Down） |
|
4 |
转发平面重启（Forwarding Pane Reset） |
|
5 |
通道失效（Path Down） |
|
6 |
连接通道失效（Concatenated Path Down） |
|
7 |
管理down（Administratively Down） |
|
8~31 |
保留位（Reserved for future use） |
l State(Sta)：BFD会话当前状态，取值为：0代表AdminDown，1代表Down，2代表Init，3代表Up。
l Demand(D)：设置为1，表示发送协议希望操作在查询模式；设置为0，表示发送协议不区分操作在查询模式，或者表示发送协议不能操作在查询模式；
l Poll(P)：设置为1，表示发送协议请求进行连接确认，或者发送请求参数改变的确认；设置为0，表示发送协议不请求确认；
l Final(F)：设置为1，表示发送协议响应一个接收到P比特为1的BFD包；设置为0，表示发送协议不响应一个P比特为1的BFD包；
l Control Plane Indepentent(C)：设置为1，表示发送协议的BFD实现不依赖于它的控制平面（换句话说，BFD在转发平面实施，即使控制平面失效了，BFD仍然能够起作用）；设置为0，表示BFD在控制平面实施；
l Authentication Present(A)：如果设置为1，则表示控制包包含认证字段，并且会话是被认证的；
l Reserved(R)：在发送时设置为0，在接收时忽略；
l Detect Mult：检测时间倍数。在异步模式下，发送协议的检测时间为协商的发送间隔乘以检测时间倍数；
l Length：BFD控制包的长度，单位字节；
l My Discriminator：发送协议产生的一个唯一的、非0鉴别值，用来对两个协议之间的多个BFD会话进行分离；
l Your Discriminator：从远端协议接收到的鉴别值，这个域直接返回接收到的“My Discriminator”，如果不知道这个值就返回0；
l Desired Min Tx Interval：本地协议发送BFD控制包时想要采用的最小间隔，单位毫秒；
l Required Min Rx Interval：本地协议能够支持的接收两个BFD控制包之间的间隔，单位毫秒；
l Required Min Echo Rx Interval：本地协议能够支持的接收两个BFD回声包之间的间隔，单位毫秒。如果这个值设置为0，则发送协议不支持接收BFD回声包；
l Auth Type：BFD控制包使用的认证类型；
l Auth Len：认证字段的长度，包括认证类型与认证长度字段。
与BFD相关的协议规范有：
l draft-ietf-bfd-base-05：Protocol Independent Bidirectional Forwarding Detection
l draft-ietf-bfd-v4v6-1hop-05：BFD for IPv4 and IPv6 (Single Hop)
在需要为网络提供检测机制的情况下，可以配置BFD的各项功能。
表1-2 BFD配置任务简介
|
配置任务 |
说明 |
|
|
配置BFD基本功能 |
可选 双向转发检测的基本配置，是其他配置任务的基础 |
|
|
配置基于静态路由的BFD |
必选 使能BFD应用，实现在静态路由所指向的链路上进行转发连通状况检测 |
在配置BFD检测方式之前，需完成以下任务：
l 配置接口的网络层地址，使相邻节点之间网络层可达
l 配置可支持BFD的路由协议
表1-3 配置BFD会话参数
|
操作 |
命令 |
说明 |
|
进入系统视图 |
system-view |
- |
|
使能会话建立模式 |
bfd session init-mode { active | passive } |
可选 缺省情况下，会话模式为active |
|
配置echo报文源地址 |
bfd echo-source-ip ip-address |
可选 |
|
进入接口视图 |
interface interface-type interface-number |
- |
|
配置接口最小报文发送间隔 |
bfd min-transmit-interval value |
可选 缺省情况下，接口最小报文发送间隔为400ms |
|
配置接口echo报文最小接收间隔 |
bfd min-echo-receive-interval value |
可选 缺省情况下，接口echo报文最小接收间隔为400ms |
|
配置接口最小报文接收间隔 |
bfd min-receive-interval value |
可选 缺省情况下，接口最小报文接收间隔为400ms |
|
配置会话监测系数 |
bfd detect-multiplier value |
可选 缺省情况下，会话监测系数值为5 |
|
配置接口认证类型 |
bfd authentication-mode { md5 key-id key | sha1 key-id key | simple key-id password } |
可选 缺省情况下，接口为不认证模式 |
& 说明：
当BFD会话工作于echo报文方式时，必须配置echo报文源地址。
BFD是一个双向检测协议，需要检测两端建立会话。对于动态路由协议来说是有邻居概念的，因此在检测两端动态路由协议都会通知BFD会话邻居信息，从而检测两端的BFD任务可以通过向邻居发送BFD控制报文来建立会话。由于静态路由没有什么邻居的概念一般使用以下方法解决：
l 静态路由使用控制报文方式的BFD功能时，对端必须存在对应的BFD会话（对端的BFD会话可以由静态路由创建，也可以由其他协议创建）。
l 利用BFD echo报文，通过echo报文建立会话，echo报文的目的地址为本设备接口地址，发送给下一跳设备后会直接转发回本设备而不经过BFD任务处理。
|
操作 |
命令 |
说明 |
|
进入系统视图 |
system-view |
- |
|
配置静态路由运行BFD |
ip route-static dest-address mask | mask-length { [ gateway-address bfd { control-packet | echo-packet } ] | [ interface-type interface-number gateway-address bfd { control-packet | echo-packet } ] } |
二者必选其一 |
|
ip route-static vpn-instance s-vpn-instance-name&<1-6> dest-address { mask | mask-length } { gateway-address bfd { control-packet | echo-packet } [ public ] | interface-type interface-number [ gateway-address bfd { control-packet | echo-packet } ] | vpn-instance d-vpn-instance-name gateway-address bfd { control-packet | echo-packet } } |
注意：
l 路由振荡时，使能BFD检测功能可能会加剧振荡，需谨慎使用。
l 静态路由如果出接口为含SPOOFING属性的接口（例如：Loopback接口），不能使用BFD进行检测。
l BFD可以检测下一跳地址为直连接口地址的静态路由。如果静态路由的下一跳地址为非直连接口地址，则不支持BFD检测。
l 在草案中BFD echo功能进行了修改，当使用echo报文方式时，仅在一端建立BFD会话。
l 有关静态路由的配置，请参见“IPv4路由”中的“静态路由配置”。
在完成上述配置后，在任意视图下执行display命令可以显示配置后BFD的运行情况，通过查看显示信息验证配置的效果。
在用户视图下执行reset命令可以清除BFD会话的统计信息。
表1-5 BFD显示和维护
|
操作 |
命令 |
|
显示使能的BFD接口信息 |
display bfd interface [ verbose ] |
|
显示PAF配置信息 |
display bfd paf |
|
显示BFD会话信息 |
display bfd session [ verbose ] |
|
清除BFD会话统计信息 |
reset bfd session statistics |
Switch A、Switch B、Switch C相互可达，在Switch A上配置静态路由可以到达Switch C，并使能BFD检测功能。
图1-2 配置静态路由BFD组网图
# 在Switch A上配置静态路由，并使能BFD检测功能，通过BFD echo报文方式实现BFD功能。
<SwitchA> system-view
[SwitchA] bfd echo-source-ip 123.1.1.1
[SwitchA] interface vlan-interface 10
[SwitchA-vlan-interface10] bfd min-echo-receive-interval 300
[SwitchA-vlan-interface10] bfd detect-multiplier 7
[SwitchA-vlan-interface10] quit
[SwitchA] ip route-static 120.1.1.1 24 10.1.1.100 bfd echo-packet
[SwitchA] quit
# 在Switch A上打开BFD功能调试信息开关。
<SwitchA> debugging bfd event
<SwitchA> debugging bfd scm
<SwitchA> terminal debugging
在Switch A上可以打开BFD功能调试信息开关，断开Hub和Switch B之间的链路，验证配置结果。验证结果显示，Switch A能够快速感知Switch A与Switch B之间链路的变化。
& 说明：
本章所指的路由器代表了一般意义下的路由器，以及运行了路由协议的三层交换机。为提高可读性，在手册的描述中将不另行说明。
GR是Graceful Restart（平滑重启）的简称，它表示当路由协议重启时保证转发业务不中断。
GR机制的核心在于：当某设备的路由协议重启时，能够通知周边设备在一定时间内将到该设备的邻居关系和路由保持稳定。在路由协议重启完毕后，周边设备协助其进行路由信息同步，在尽量短的时间内使该设备的各种路由信息恢复到重启前的状态。在整个协议重启过程中，网络路由和转发保持高度稳定，报文转发路径也没有任何改变，整个系统可以不间断地转发IP报文。这个过程即称为平滑重启。
配置了GR属性的设备，我们称之为“具备GR能力”的设备。即该设备在路由协议重启时，能实现GR。不具备GR能力的设备，在路由协议重启的情况下，只能遵循普通的重启过程。GR中涉及到的基本概念如下：
GR重启路由器，指由管理员或由于故障触发进行协议重启的路由器，必须具备GR能力。
即GR Restarter的邻居，能协助重启的GR Restarter保持路由关系的稳定，也必须具备GR能力。
GR会话，是GR Restarter和GR Helper之间的协商过程。包括协议重启通告，协议重启过程中的信息交互等。通过该会话，GR Restarter和GR Helper可以掌握彼此的GR能力。
GR时间，是GR Restarter和GR Helper协商建立一个会话所用的时间。当某GR路由器发现邻居路由器处于down状态时，将在该时间内仍保留其发出的拓扑信息或路由。
在网络中配置一个设备为GR Restarter，该设备与其GR Helper必须支持GR或具备GR能力。这样当GR Restarter重启时，其GR Helper就可以感知它的重启进程。
& 说明：
GR Restarter与GR Helper的作用是相互的。在某些情况下，GR Restarter与GR Helper的位置和作用可以互换。
GR Restarter和GR Helper之间的具体通讯过程如下：
图2-1 在GR Restarter与GR Helper间建立GR Session
如图2-1所示，Router A承担GR Restarter角色，Router B、Router C和Router D分别是Router A的GR Helper，在GR Restarter和GR Helper之间建立起GR Session。
图2-2 GR Restarter的重启过程
如图2-2所示，当各GR Helper发现其对端GR Restarter处于协议重启状态时，不仅继续保持GR Session，而且在GR Time内仍保留来自GR Restarter的路由。
图2-3 GR Restarter重启完毕后向GR Helper发送信号
如图2-3所示，GR Restarter的重新启动完成后，会向其每个GR Helper发送信号，从而重新建立GR Session。
图2-4 GR Restarter从GR Helper获取拓扑或路由信息
如图2-4所示，GR Restarter通过与所有GR Helper建立GR Session，可获得拓扑或路由信息，并以此重新计算自己的路由表。
交换机支持基于BGP、OSPF、IS-IS协议的GR机制。
有关上述协议各自GR机制的实现原理及相关的配置过程，请分别参见“IPv4路由”中的“BGP配置”、“OSPF配置”和“IS-IS配置”。
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!
支持
