BFD应用场景分析
- 格式：doc
- 大小：5.27 MB
- 文档页数：47
在故障通告的过程中，微码还会将故障消息上送给适配，适配再上送给接口板BFD模块，BFD模块然后再上送接口板应用、主控板BFD模块、主控板应用APP(应用APP可能VRRP、IGP、BGP、PIM、RSVP、LSPM、L2VPN等等)。
3
3.1
应用典型组网
BFD和应用结合原理
在如上图组网中，该场景主要用于TE tunnel的HotStandBy保护场景的快速切换。该场景的检测目的是TE隧道内部主LSP是否可用。正常情况下，流量走主LSP。在主LSP上创建BFD会话，检测该链路是否出现故障。当检测到主LSP出现故障后，在转发层就把流量切到备LSP。在HotStandBy场景下，TE模块会向底层下发两条LSP信息，转发平面根据底层表项中主LSP的状态进行报文转发，一旦主故障，BFD会将LSP down事件通过产品MSG ME模块通告给588/2800，芯片将这主LSP表识为down，从而完成流量的切换。表项查询过程如下：TunnelID->Tunnel Token->LSP status。故障前后表项状态对比：
RoutePort,The Maximum Transmit Unit is 1500
Internet Address is unnumbered, using address of LoopBack0(10.8.8.1/32)
Encapsulation is TUNNEL, loopback not set
3
MPLS维护手册(R7)
产品MPLS维护团队
\\peknas05-rd\NW_VRPV5LMT_F
4
5
1
本文从应用的角度着重介绍了不同BFD session和不同应用APP的结合应用场景。BFD session类型主要包括BFD for IP单跳，多跳，BFD for LSP，BFD for接口联动。
Description:HUAWEI, Quidway Series, Tunnel1/0/5 Interface
RoutePort,The Maximum Transmit Unit is 1500
Internet Address is unnumbered, using address of LoopBack0(10.8.8.1/32)
BFD是如何识别同一个session的？这个是通过BFD中的discriminator来识别不同BFD session的discriminator分为remote和local两个，当这两个值匹配的话，就存在了建立一个BFD session的可能性下图MD = local discriminator，YD =remote discriminator。
[RT13]dis tu
[RT13]dis tunnel--in
[RT13]dis tunnel-in
[RT13]dis tunnel-info 200812a
Tunnel ID: 0x200812a
Tunnel Token: 298//主lsp对应token
Type: lsp
Destination: 10.10.10.3
Encapsulation is TUNNEL, loopback not set
Tunnel destination 10.10.10.3
Tunnel up/down statistics 1
Tunnel protocol/transport MPLS/MPLS, ILM is available,
本文的BFD基本原理介绍是为了更好的理解本文的这些应用，所以对协议细节没有作更多的介绍。
2
BFD是一个简单的“Hello”协议，和路由协议的邻居检测部分相似，一对系统在它们之间所建立会话的通道上周期性的发送检测报文，如果某个系统在足够长的时间内未收到对端的检测报文，则认为在这条到相邻系统的双向通道的某个部分发生了故障。BFD协议可以分为邻居协商阶段和故障探测两个阶段，在学习BFD协议过程中一般有下面几个关注点。
名称
作者
发布日期
查阅地点或渠道
出版单位（若不为本公司发布的文献，请填写此列）
1
BFD特性介绍.ppt
刘燕军51280
\\peknas05-rd\NW_VRPV5LMT_F\04能力进阶图书馆\23设计部培训资料
2
BFD应用场景分析.ppt
刘宇
65139
\\peknas05-rd\NW_VRPV5LMT_F
Out Slot: 1
Instance ID: 0
Out Interface: GigabitEthernet1/0/2
Out Label: 3
Next Hop: 10.1.1.12
Lsp Index: 6172
[RT13-diagnose]efu mpls lsp_status query 1 298
BFD for默认组播session当前只能通过静态配置来建立BFD session，在配置过程中只有绑定接口能够处理BFDdefault组播，则下发BFD表项，然后通过组播地址定时发送组播协商报文，原端收到协商报文后也会发送组播的BFD session报文。协商成功后，进入探测阶段。
BFD是如何完成探测的?BFD探测报文一般是通过NP直接发送的。一个BFD session创建成功后，NP会以10ms为单位，循环查询BFDsession状态，一旦发现有UP的BFDsession，则启动首包发送定时器，收到对端的首包后，开始正常检测，按照协商好的发送间隔发送检测报文。微码下行收到BFD报文后，查询到下行接收表，进行状态机的处理。微码只有两个状态：Up/Down。Up状态收到Up报文，则检测记数器复原，等待下一次轮询再次进行测试；Up状态收到Down报文、或者配置周期内没有收到报文都会使底层状态变Down。底层状态Down后，则会通过广播全局索引到各单板进行状态表项的操作，如果是for lsp类型的会话，可能放置的是LSP Token、Tunnel Index、PW Index等。
300 seconds output rate 52808 bits/sec, 100 packets/sec
0 seconds output rate 0 bits/sec, 0 packets/sec
17767212 packets output, 1172698068 bytes
0 output error
关键词：BFD,PST,PIS快速检测,保护
摘要：本文从应用的角度着重介绍了不同BFD session和不同应用略语
Full spelling英文全名
Chinese explanation中文解释
VRP
Versatile Routing Platform
通用路由平台
BFD
Bidirectional Forwarding Detection
双向转发检测
GFD
General Forwarding Detection
通用转发检测
PST
PortStateTable
端口状态表
PIS
Process Interface Status
处理接口状态
参考资料清单：
编号
BFD for IP session协商过程，用户通过配置或者APP下发BFD session请求，判断Peer ip是否存在路由，如果路由存在，则下发BFD配置信息，启动发送定时器准备发送协商报文，如果协商报文正常，则session协商成功，BFD进入探测阶段。
BFD for LSP场景需要分为静态配置协商过程和通过上层应用APP（一般情况下是LSPM模块或TNLM模块）触发建立session。静态配置的BFD for LSP，BFD模块在收到配置信息后，检察需要绑定的LSP是否UP，如果UP在下发配置表项，启动一个定时器（一般是10-15s之间的一个随即定时器）准备发送协商报文，初始化协商报文携带BFDdown信息。所有协商报文可以通过IP转发也可以通过MPLS转发。一旦协商成功BFD进入探测阶段。在通过上层APP进行下发配置触发建立BFD for LSPsession的场景下，主动发起端会首先向远端发送一个LSP ping request报文在这个报文中携带BFD协商所需要信息包括MY、YD等等协商信息。远端收到LSP ping request报文后，解析发现存在BFD协商信息，则上送BFD模块处理，这时远端BFD会创建会话，并发送BFD协商报文。本端收到远端的BFD报文后才启动定时器，发送参数协商报文进行BFD session协商，协商成功BFD进入探测阶段。
BFD session是如何进行探测时间协商的？系统将较大的间隔(较慢的速率)确定为传送间隔，也即实际的发送间隔为本端期望的发送间隔和对端期望的接收间隔中的较大一方，通俗的说协商的结果，总是要满足能力弱的一方的要求－同情弱者。协商过程可以入下图所示。
BFDsession是如何协商的？BFD不同类型的session类型其协商过程也是不同的。
primary tunnel id is 0x0,secondary tunnel id is 0x0//上层协议收敛后，当前tunnel走备份lsp，Tunnel ID为0
300 seconds output rate 46552 bits/sec, 83 packets/sec
0 seconds output rate 0 bits/sec, 0 packets/sec
[RT13]dis interface Tunnel 1/0/5
Tunnel1/0/5 current state : UP
Line protocol current state : UP
Last line protocol up time : 2010-08-28 14:37:42
Description:HUAWEI, Quidway Series, Tunnel1/0/5 Interface
3
3.1
应用典型组网
BFD和应用结合原理
在如上图组网中，该场景主要用于TE tunnel的HotStandBy保护场景的快速切换。该场景的检测目的是TE隧道内部主LSP是否可用。正常情况下，流量走主LSP。在主LSP上创建BFD会话，检测该链路是否出现故障。当检测到主LSP出现故障后，在转发层就把流量切到备LSP。在HotStandBy场景下，TE模块会向底层下发两条LSP信息，转发平面根据底层表项中主LSP的状态进行报文转发，一旦主故障，BFD会将LSP down事件通过产品MSG ME模块通告给588/2800，芯片将这主LSP表识为down，从而完成流量的切换。表项查询过程如下：TunnelID->Tunnel Token->LSP status。故障前后表项状态对比：
RoutePort,The Maximum Transmit Unit is 1500
Internet Address is unnumbered, using address of LoopBack0(10.8.8.1/32)
Encapsulation is TUNNEL, loopback not set
3
MPLS维护手册(R7)
产品MPLS维护团队
\\peknas05-rd\NW_VRPV5LMT_F
4
5
1
本文从应用的角度着重介绍了不同BFD session和不同应用APP的结合应用场景。BFD session类型主要包括BFD for IP单跳，多跳，BFD for LSP，BFD for接口联动。
Description:HUAWEI, Quidway Series, Tunnel1/0/5 Interface
RoutePort,The Maximum Transmit Unit is 1500
Internet Address is unnumbered, using address of LoopBack0(10.8.8.1/32)
BFD是如何识别同一个session的？这个是通过BFD中的discriminator来识别不同BFD session的discriminator分为remote和local两个，当这两个值匹配的话，就存在了建立一个BFD session的可能性下图MD = local discriminator，YD =remote discriminator。
[RT13]dis tu
[RT13]dis tunnel--in
[RT13]dis tunnel-in
[RT13]dis tunnel-info 200812a
Tunnel ID: 0x200812a
Tunnel Token: 298//主lsp对应token
Type: lsp
Destination: 10.10.10.3
Encapsulation is TUNNEL, loopback not set
Tunnel destination 10.10.10.3
Tunnel up/down statistics 1
Tunnel protocol/transport MPLS/MPLS, ILM is available,
本文的BFD基本原理介绍是为了更好的理解本文的这些应用，所以对协议细节没有作更多的介绍。
2
BFD是一个简单的“Hello”协议，和路由协议的邻居检测部分相似，一对系统在它们之间所建立会话的通道上周期性的发送检测报文，如果某个系统在足够长的时间内未收到对端的检测报文，则认为在这条到相邻系统的双向通道的某个部分发生了故障。BFD协议可以分为邻居协商阶段和故障探测两个阶段，在学习BFD协议过程中一般有下面几个关注点。
名称
作者
发布日期
查阅地点或渠道
出版单位（若不为本公司发布的文献，请填写此列）
1
BFD特性介绍.ppt
刘燕军51280
\\peknas05-rd\NW_VRPV5LMT_F\04能力进阶图书馆\23设计部培训资料
2
BFD应用场景分析.ppt
刘宇
65139
\\peknas05-rd\NW_VRPV5LMT_F
Out Slot: 1
Instance ID: 0
Out Interface: GigabitEthernet1/0/2
Out Label: 3
Next Hop: 10.1.1.12
Lsp Index: 6172
[RT13-diagnose]efu mpls lsp_status query 1 298
BFD for默认组播session当前只能通过静态配置来建立BFD session，在配置过程中只有绑定接口能够处理BFDdefault组播，则下发BFD表项，然后通过组播地址定时发送组播协商报文，原端收到协商报文后也会发送组播的BFD session报文。协商成功后，进入探测阶段。
BFD是如何完成探测的?BFD探测报文一般是通过NP直接发送的。一个BFD session创建成功后，NP会以10ms为单位，循环查询BFDsession状态，一旦发现有UP的BFDsession，则启动首包发送定时器，收到对端的首包后，开始正常检测，按照协商好的发送间隔发送检测报文。微码下行收到BFD报文后，查询到下行接收表，进行状态机的处理。微码只有两个状态：Up/Down。Up状态收到Up报文，则检测记数器复原，等待下一次轮询再次进行测试；Up状态收到Down报文、或者配置周期内没有收到报文都会使底层状态变Down。底层状态Down后，则会通过广播全局索引到各单板进行状态表项的操作，如果是for lsp类型的会话，可能放置的是LSP Token、Tunnel Index、PW Index等。
300 seconds output rate 52808 bits/sec, 100 packets/sec
0 seconds output rate 0 bits/sec, 0 packets/sec
17767212 packets output, 1172698068 bytes
0 output error
关键词：BFD,PST,PIS快速检测,保护
摘要：本文从应用的角度着重介绍了不同BFD session和不同应用略语
Full spelling英文全名
Chinese explanation中文解释
VRP
Versatile Routing Platform
通用路由平台
BFD
Bidirectional Forwarding Detection
双向转发检测
GFD
General Forwarding Detection
通用转发检测
PST
PortStateTable
端口状态表
PIS
Process Interface Status
处理接口状态
参考资料清单：
编号
BFD for IP session协商过程，用户通过配置或者APP下发BFD session请求，判断Peer ip是否存在路由，如果路由存在，则下发BFD配置信息，启动发送定时器准备发送协商报文，如果协商报文正常，则session协商成功，BFD进入探测阶段。
BFD for LSP场景需要分为静态配置协商过程和通过上层应用APP（一般情况下是LSPM模块或TNLM模块）触发建立session。静态配置的BFD for LSP，BFD模块在收到配置信息后，检察需要绑定的LSP是否UP，如果UP在下发配置表项，启动一个定时器（一般是10-15s之间的一个随即定时器）准备发送协商报文，初始化协商报文携带BFDdown信息。所有协商报文可以通过IP转发也可以通过MPLS转发。一旦协商成功BFD进入探测阶段。在通过上层APP进行下发配置触发建立BFD for LSPsession的场景下，主动发起端会首先向远端发送一个LSP ping request报文在这个报文中携带BFD协商所需要信息包括MY、YD等等协商信息。远端收到LSP ping request报文后，解析发现存在BFD协商信息，则上送BFD模块处理，这时远端BFD会创建会话，并发送BFD协商报文。本端收到远端的BFD报文后才启动定时器，发送参数协商报文进行BFD session协商，协商成功BFD进入探测阶段。
BFD session是如何进行探测时间协商的？系统将较大的间隔(较慢的速率)确定为传送间隔，也即实际的发送间隔为本端期望的发送间隔和对端期望的接收间隔中的较大一方，通俗的说协商的结果，总是要满足能力弱的一方的要求－同情弱者。协商过程可以入下图所示。
BFDsession是如何协商的？BFD不同类型的session类型其协商过程也是不同的。
primary tunnel id is 0x0,secondary tunnel id is 0x0//上层协议收敛后，当前tunnel走备份lsp，Tunnel ID为0
300 seconds output rate 46552 bits/sec, 83 packets/sec
0 seconds output rate 0 bits/sec, 0 packets/sec
[RT13]dis interface Tunnel 1/0/5
Tunnel1/0/5 current state : UP
Line protocol current state : UP
Last line protocol up time : 2010-08-28 14:37:42
Description:HUAWEI, Quidway Series, Tunnel1/0/5 Interface
