网络高可用性技术之四

转载自：华为    网络高可用性技术白皮书（三）

1.路由快速收敛

在实际网络中，通过冗余路由来提高网络可用性是普遍的做法，当其中一条路径发生故障时，流量可以切换到其他冗余路径。冗余路由可以分为两种情况，一种是等价路由，一种是非等价路由。等价路由即等价多路径（Equal Cost Multi Path，ECMP），ECMP 的各条路径在互为备份的同时实现了负载分担。非等价路径情况下，只有最优路径被启用作报文转发，次优路径只有当最优路径失效时才会被启用。

等价多路径有较好的收敛性能，经常被用于提高网络可用性，在下面会分析一下其收敛性能。浮动静态路由也比较常用，也会简单介绍一下。最后本节会介绍目前普遍采用的提高 IGP 收敛性能的两种方法：快速 Hello 和 iSPF。

1.1 等价多路径(ECMP)

对于ECMP 来说，静态和动态情况下其收敛时间基本相同。ECMP 中某条路径出现故障时，其收敛过程大致为：检测到路径故障，故障上报路由模块，路由模块删除软件FIB 表中与该路径相关的表项，如果存在硬件FIB 表，还需要删除硬件 FIB表。故障路径上的流量被重新分布到其他等价路径。所以 ECMP 的收敛时间 = 故障检测时间+故障上报时间+软件 FIB 删除时间+硬件 FIB删除时间。后三个因素加起来，时间大约在 10ms 量级。故障检测时间需要具体分析，如果是链路 UP/DOWN，检测时间在ms 级。如果是其他故障，和故障检测手段相关，部署了 BFD，可以在亚秒级检测到故障。

至于 ECMP 的故障路径恢复，其过程大致是：路由模块重新学习到等价路由，路由下发软件FIB，如果存在的话，还要下发到硬件FIB。因为在路由下发FIB 生效前，流量并不会重新分布，所以从理论上来说，等价路由恢复的收敛时间为0。测试结果也基本证实了这点。

等价多路径有很好的收敛速度，在网络设计中，如果核心网基于纯IP 架构，那么使用ECMP 来保障高可用性是很好的一个选择。

1.2 浮动静态路由

所谓浮动静态路由（floating static route）是指对同一个目的网络，配置下一跳不同，且优先级不同的多条静态路由。正常情况下，只有优先级最高的静态路由起作用。当优先级最高的静态路由失效时，次优静态路由被启用….，以此保障目的网络总是可达，提高网络可用性。

在转发路径故障的情况下，浮动静态路由收敛过程大致是：路径故障上报，路由模块删除软件 FIB，如果存在硬件 FIB，还要删除硬件 FIB，路由模块启用次优路由，路由模块下设软件FIB，如果存在，下设硬件FIB。所以浮动静态路由的收敛时间为：

故障检测时间+路径故障上报时间+软硬件 FIB 删除时间+软硬件FIB 下设时间

后面三个因素消耗的时间大致在10ms到100ms 量级。故障检测时间需要具体情况具体分析，链路 UP/DOWN 的情况故障检测时间在 ms 级，可以忽略不计，其他故障在静态浮动路由的情况下还不好检测。

路径恢复时，其收敛过程和收敛时间跟路径故障时类似。

1.3 IGP 快速收敛

目前常用的标准路由协议为 RIP、OSPF、IS-IS、BGP。其中，收敛速度不是 BGP 协议的设计目标，所以本文不予讨论。RIP 由于其周期性的非可靠路由发布机制，不适合用在高可用性网络，也不讨论。这里主要讲 OSPF、IS-IS 如何达到快速收敛，两者都是链路状态类型的 IGP。

对于 IGP，收敛速度是衡量其优劣的一个重要指标。具体到 OSPF 和 IS-IS 这两中链路状态

路由协议，提高收敛速度，可以从下述几个方面着手：

1.提高邻居故障检测速度

2.提高协议会话建立速度

3.提高链路状态数据库的同步速度。

4.提高SPF计算效率

5.减少LSDB同步到SPF计算开始之间的时间间隔

OSPF 和 IS-IS 都使用 hello 报文来检测邻居状态，缩短 hello报文的发送时间间隔，即常说的快速 Hello 可以有效加快故障检测速度。另外一种加快故障检测速度的机制是 BFD，将在后面的章节讲到。

快速 hello 的另一个作用是可以提高OSPF 和 IS-IS 邻居关系的建立，即上面提到的第 2 点，加快协议会话的建立速度。不过，存在冗余路径的情况，因为协议会话在冗余路径上是已经建立了的，这时快速 Hello 对于提高协议会话建立速度意义不大。不过，在没有冗余路径的情况下，快速 Hello 是可以提高会话建立速度的。

第三点，提高 SPF 计算效率，目前普遍采用 iSPF，即增量 SPF 算法。

第四点，提高链路状态的同步速度，需要对链路变化快速反应，迅速生成新 LSA 并泛洪。

第五点，减少 LSDB 同步到 SPF 计算开始之间的时间间隔，可以通过适当调整 SPF timer 来

实现。

下面介绍快速 Hello 和 iSPF。

1.1.3 快速 Hello 

OSPF 和 IS-IS 均支持快速 Hello，快速 Hello 的设计目标是用于多路访问网络，比如以太网，ATM 网络，当多个路由器通过一个二层以太网交换机或者 ATM 交换机相连时，链路的 UP/Down 被二层交换机隔离，邻居感知不到，这导致邻居丢失需要靠协议的软 Hello 机制来检测。以 OSPF为例，缺省的 Hello interval 为 10 秒，路由器缺省情况在 4 个 Hello interval 内收不到对端的 Hello 报文，才认为邻居丢失，这导致 40 秒之后才会引发 SPF 计算，重新选路。

对于一个高可用性网络来说，40 多秒的收敛时间显然难以接受的。为此，各个设备厂商都

设计了快速 Hello 特性，通过允许把 Hello Interval 设到最小 50ms，来提高邻居丢失检查速度。

以 CISCO 的 OSPF 快速 Hello 为例，其配置命令为：

ip ospf dead-interval {seconds | minimal hello-multiplier multiplier}

其中如果使用Seconds参数，就是正常OSPF情况，缺省是4倍的Hello interval，但允许用户自己配置，单位为秒。

使用“minimal hello-multiplier multiplier”即表示用快速Hello，其中“multiplier”是设备在1秒内发送Hello报文的个数，取值范围为3－20，配置20，相当于Hello interval为50ms。

不过，快速 Hello 会带来很多负面影响，首先 OSPF 和IS-IS 的 Hello 报文本身携带的信息都比较多，其次部署环境是多路访问网络，邻居不会少，Hello 发送过快，会给路由器的 CPU 带来沉重负担，处理不过来的话，会导致误报，引起不必要的路由振荡。

在部署快速 Hello 时，必须由有经验的工程师根据设备 CPU 处理能力和网络部署情况，谨慎调整 Hello interval. 

2.1.3 iSPF 

在通常的 OSPF、IS-IS 协议实现中，如果链路状态发生了变化，那么整个最短路径树都会重新计算。但是在实际情况中，链路状态发生变化时，以发起计算的路由器为源点的最短路径树的绝大部分事实上是不需要重新计算的，只需要对受链路状态变化影响的部分，比如，只需对这条路径树的某些子树作增量计算即可。对链路状态改变引起的变化，充分利用先前的计算结果，只作增量计算，这就是 iSPF（incremental SPF，增量最短路径优先）的目标，也是其名字的由来。

事实上，在标准的 OSPF V2 文本（RFC2328）的 16.5/16.6 已经提到一些只需要增量计算的情况，比如，当收到了变化的 summary-LSAs 和 AS-external-LSAs 时，不一定需要重新计算整棵树，可能只需要更新以 ABR 和 ASBR 为根的子树。

还有一些很明显的情况也只需要作增量计算，如下图，考虑以 A 为源节点的最短路径树，因为 C-D 之间的链路在最短路径树中没有使用，如果这条链路 down，对整棵最短路径树事实上没有任何影响，根本就不需要进行 SPF 计算。再比如，路由器 G 增加了一个邻居 H，那么对于以 A为源的最短路径树来说，只需要计算以 G 为根的最短路径子树。

iSPF 算法只对受链路状态变化（up、down、insert、delete）影响的子树及其关连节点进

行计算，设计良好的 iSPF 算法可以较大的提升路由计算速度。iSPF 算法在最近的 20 多年中吸引了很多人的研究，提出了各种算法。

目前实用的 iSPF 算法，其收敛时间在 100ms 以内。

1.4 MPLS FRR 

在 MPLS TE 网络中，通常情况下，如果某个 LSP 途经的链路或节点故障，故障链路或节点的上游邻节点会发错误消息给 LSP 的头节点，由头节点利用 CSPF 重新计算出一条新的路径，并据此建立 LSP，然后把流量切换到新的 LSP。但是，在IGP 路由收敛之前，CSPF 是无法算出有效路径的，这导致 TE 的收敛时间过长，在 10s 量级，对很多应用来说难以忍受。

解决这个问题的办法是引入 MPLS TE 保护技术，MPLS TE 保护技术也称为 FRR（Fast ReRoute），即 MPLS 快速重路由。FRR 预先为需要保护的 LSP 建立好备份路径，对其局部或全局提供保护，在检测到被保护 LSP 上的某条链路或节点出现故障后，可以立即切换到备份路径，通过引入快速故障检查技术（如 RSVP Hello、BFD 或链路层提供的检测功能）， LSP 可以作到在 50ms 以内收敛。不过，备份路径只提供临时的故障规避措施，路径切换后，被保护 LSP 的头节点需要重新计算，建立新的更优的 LSP，并使用 RSVP-TE 的 Make-before-Break 机制，可把流量无缝切换到新的 LSP，在新 LSP 建立之前，流量会一直延备份路径转发。

MPLS TE 保护技术可以分为两类：

„本地保护（Local Protection），本地保护分为两种：

‹链路保护（link Protection），对LSP上的某条链路进行保护。

‹节点保护（Node Protection），对LSP上的某个节点进行保护。

„路径保护（Path Protection），对LSP实施端到端的保护。

本地保护一般可以在 50ms 内收敛，路径保护相对来说收敛时间稍慢，可能达到几百 ms。

本地保护已经形成正式的标准，RFC 4090，其中定义了两种本地保护方式，一种是 One-to-One 

Backup 方式，在各个可能的故障节点或链路，为不同的被保护 LSP 创建不同的备份路径；另一

种是 Facility Backup 方式，在各个可能的故障节点或链路，可以用一条备份路径保护多条 LSP。

其中，One-to-One Backup 方式最初由 Juniper 推出，Facility Backup 最初由 CISCO 推出。

1.1.4 本地保护

RFC 4090 的目标是把原来各个厂商独立实现的 LSP 本地保护技术，主要是 Juniper 主导的one-to-one backup 和 Cisco 主导的 facility backup，统一到一套相同的协议框架中进行定义，并为试图同时支持这些实现的厂商解决互操作问题。

1.几个术语

在正式开展之前，有必要先明确一下后面常用到的几个术语的含义：

Protected LSP：被保护LSP，也称主路径（main path）、主LSP（main LSP）。

Backup Path：备份路径，泛指One-to-One backup和Facility backup方式下的备份

LSP。

Detour LSP：指One-to-One backup方式中的备份LSP。Detour LSP的头节点是PLR，尾节点是主LSP的尾节点，不过，在MP节点Detour LSP和主LSP进行了归并。

Bypass Tunnel：指Facility backup方式下的备份LSP。Bypass Tunnel的头节点是PLR，尾节点是MP。

PLR：Point of Local Repair，本地修复点，其实就是备份路径的头节点。

MP：Merge Point，归并点，备份路径和主路径在故障点下游的交汇点。

DMP：Detour Merge Point ，在one-to-one backup方式下，如果多个Detour LSP在某个LSR交汇，且下一跳和出接口相同，那么该LSR会合并这些Detour，在这个LSR以下，只需要维护一条Detour信令。这个交汇LSR，被称为DMP。

NHOP：Next-Hop，指PLR的下一跳。

NNHOP：Next-Next-Hop，指PLR的下下一跳。

2.两种本地保护技术

在 RFC4090 中，提出了两种实现 MPLS FRR 本地保护的方法：One-to-One Backup 和 Facility 

Backup。

1)One-to-One Backup 

顾名思义，One-to-One Backup，即一对一备份，为每条主 LSP 创建一条备份路径，备份路径被称为 Detour LSP。下图是One-to-One Backup 的例子：

对照上图，这里对上一节的术语作一下解释：R1、R2 作为两条 Detour 的头节点，是 PLR；R4 作为 Detour 和主 LSP 的交汇点，是 MP；R7 作为 R1’s Detour 和 R2’s Detour 的交汇点，并且两条 Detour 满足归并条件，R7 会归并 R1’Detour 和 R2’s Detour，R7 称为 DMP；另外 R3 是 R2的 NHOP 节点，R4 是 R2 的 NNHOP 节点。

R2’Detour 既保护了 R2 和 R3 之间的链路，也保护了 R3 节点。如果 R2 到 R3 之间的链路故障或者 R3 节点故障，那么 R2 节点会启动倒换，从 R1 发送到 R5 的报文在 R2 节点将倒换到备份路径：R1-R2- R7-R8-R4-R5。下图是倒换前后，标签交换情况：

倒换前，走主路径，标签交换过程如上图中×××标签。如果 R2 检测到 R3 故障，R2 会把流量倒换到 R2’s Detour，出标签为 48，发到 R7；在 R7，因为 R1’s Detour 和 R2’s Detour 进行了归并，这里假设归并到 R1’s Detour，所以在 R7 之后，使用 R1’s Detour 的标签 45 发到 R8，R8使用标签 65 发到 R4；在 R4，Detour 又归并到主 LSP，R4 之后，完全使用主 LSP 的标签向 Egress发送报文。

上述标签交换过程表明，One-to-One backup 方式下，使用备份路径时，标签栈深度不变。

在 One-to-One backup方式下，对一个有 N 个节点的 LSP，如果要实现完整的本地保护，至少需要 N－1 条 Detour。

2)Facility Backup 

Facility Backup 使用一条备份路径保护多条主LSP，备份路径被称为 Bypass Tunnel。下面是 Facility Backup 的一个例子：

上图中，LSP1、2 使用同一条备份路径。R2 和 R3 之间的链路故障或者 R3 故障，都会导致备份路径 R2-R6-R7-R4 被启用。事实上，上图中的备份路径，可以被用来保护任何途经 R2-R6-R7-R4的 LSP。

Facility backup 方式下，备份路径可以保护多条 LSP，这也导致一个问题：在流量切换到备份路径之后，比如上图中，在 R4 节点收到从备份路径过来的流量，如何判断流量是属于 LSP1还是 LSP2？Facility Backup 方式使用标签栈来解决这个问题，外层标签是备份路径的标签，内层标签则是切换前 R4 分配给主 LSP 上其邻节点R3 的标签，比如，如果切换前 R4 在 LSP1 上分配给 R3 的标签为 L1，那么切换后，R2 在把 LSP1 的流量发给 R6 之前，先打上内层标签 L1，再打上外层备份路径的标签。这样，只要在切换后 R4 的 RSVP-TE 信令能维持原来状态，标签转发表就不会改变，R4 收到备份路径中过来的流量后根据内层标签就能正确判断流量属于 LSP1，从LSP1的转发路径转发。至于 R2 如何知道 LSP1 上 R4分配给 R3 的标签，和 RSVP-TE 中的一个称为RECORD_REROUTE 对象相关，这个对象包含在 RSVP-TE 的 RESV 消息中，会沿 LSP 逆向累积纪录各个 LSR 分配给他的上游邻节点的标签，上游节点通过 RESV 消息中包含的这个对象能知道下游各个节点的标签分配情况。

下图是 Facility Backup 方式下，倒换前后的标签交换情况，这里只描述了 LSP1 的情况：

可以看到，在 R2 把 LSP1 的流量倒换到备份路径后，R2 把 R4 在 LSP1 上分配给 R3 的标签“28”作为内层标签，R7 作为备份路径的倒数第二跳，弹出外层标签，直接以 28 发送给 R4，R4 根据标签 28，知道应该走 LSP1。

把 Facility Backup 方式和 One-to-One Backup 方式作一下比较，会有一些有趣的发现：

one-to-one backup方式不使用标签栈，而Facility backup使用。

one-to-one backup方式不用记录主LSP中MP给上游邻节点分配的标签，Facility backup方式需要。

Facility Backup中，备份路径的尾节点为MP（图16中的，R7倒数第二跳弹出标签）；而One-to-One backup，备份路径的尾节点是主路径的Egress节点，MP只不过是备份路径和主LSP的归并点，可以认为MP节点之后，备份路径使用和主路径相同的标签表。

要完整的本地保护一个有 N 个节点的 LSP，Facility backup 方式下，也需要至少有 N-1 条备份路径。不过因为一条备份路径可以保护多条主 LSP，所以从整个 MPLS TE 网络的角度来看，对网络中的所有 LSP 提供保护，其需要的备份路径比 One-to-One Backup 方式少得多。

3.两种本地保护技术的优劣

Facility Backup方式由 CISCO 主导，One-to-One Backup 由 Juniper 主导。相对来说，Facility Backup 方式因为有较好的扩展性，并支持负载分担，应用更为广泛。

One-to-One backup 方式的本地保护，最为人诟病的是其可扩展性不好。CISCO *** Juniper常用的一个例子是，如果一个 MPLS TE 网络中有 5000 条需要保护的 LSP，每条 LSP 平均的跳数为 6，那么总共需要 25000 条 Detour，光维护这些 Detour 的状态，就可能使各 LSR 的 CPU 不堪重负。不过事实上，通过对 Detour 的 PATH 消息进行归并，实际情况可能并没有那么可怕，大量的 Detour 可以被归并，归并后相当于多条 Detour 在 MP 或 DMP 点之后变成了一条。

4.SRLG 

SRLG，Shared Risk Link Group，风险共享链路组，指一组共享相同风险的链路，如果其中一条链路故障，其他链路可能都会失效。比如使用同一条光缆、同一个管道的光纤链路，如果光缆和管道被砍短，所有光纤链路都可能失效，再比如使用同一根光纤的子链路，如果光纤失效，所有子链路也失效。SRLG 在传输网部署中被广泛考虑，在MPLS TE中引入 SRLG，可以使备份路径在选路时，避免和被保护的链路在同一个 SRLG，提供更好保护有效性。

MPLS TE 网络中的设备可以配置哪些接口属于同一个 SRLG，OSPF 或 IS-IS 将把 SRLG 的成员信息，连同其他的链路 TE 信息（如可用带宽等），在网络中泛洪，供设备在 CSPF 计算时使用。

如果备份路径是动态生成的，因为 SRLG 信息可被用于 CSPF 计算，可以计算并生成和被保护链路不在同一个 SRLG 的路径。备份路径如果是手工生成，只能手工避免。

2.1.4 路径保护

路径保护指为 MPLS TE LSP 提供端到端的保护。主路径生成后，可以为它静态配置或动态生成多条备份路径，一旦主路径检测到故障，主路径的头节点会立即把流量切换到其中一条备份路径，如果主路径故障恢复，又把流量切换回主路径。为了避免主路径和备份路径同时发生故障，备份路径应该尽量避开主路径途经的节点和链路。在主路径故障之前，备份路径不转发流量。

路径保护相对于本地保护，可扩展性较差。而且收敛时间也要慢一个数量级，大约在几百毫秒，这是因为主路径中途的 LSR 检测到节点或链路故障后，还需要生成 PATH ERROR 消息发送给头节点，期间，生成消息以及转发过程中的延迟，将消耗较多时间。

一般在只有少量 LSP 需要保护，而且对收敛时间要求相对较低的情况下才使用路径保护。

2.链路检测

随着客户对网络可用性的要求越来越高，当前网络设备一个越来越重要的特征是，必须能快速检测到相邻设备之间的通信故障，这样可以尽快选择一条替代路径，使网络从故障中快速恢复。快速检测相邻设备之间通信故障的要求，故障检测速度很大程度上决定了网络的收敛速度。

一般的故障，如链路 up/down、设备断电重起可以很快被物理链路检测到并上报给上层选路协议，但更多深层的故障（如转发引擎故障、链路单通故障等），大部分链路（比如 Ethernet）并不能提供相关的检测机制。这时候，故障检测需要依靠上层选路协议以 Hello、keepalive 等报文实现的软检测机制，往往比较慢。当然，通过缩小报文发送间隔，可以加快故障检测，但这些 Hello、keepalive 报文都有检测连通性以外的多种用途，结构相对复杂，处理开销也大，报文发送间隔太小时，往往导致 CPU 不堪重负，且容易引起误报，这是前面章节介绍的路由协议的“Fast Hello”机制的致命缺陷。除了 RSVP Hello 这种专门设计用来检测连通性的机制外，其他协议的 Hello、Keepalive报文，其检测故障的时间实践中都在 1 秒以上。使用特定协议的Hello、Keepalive 机制检测故障的另外一个缺点是报文和具体的协议相关，如果不启用这个协议就不能实现检测，另外，协议差异性也导致难以用硬件作通用的实现。

2.1 DLDP 链路检测协议

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中的报文子类型，目前只有通告报文定义了子类型，示意如下：

特殊功能标志位

RSY标志：表明本端口处于ACTIVE状态或者本端口的某个邻居的信息老化。

Flush标志：表明本端口将关闭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 种状态，每种状态的含义如下：

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 状态。

2.2 BFD 

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 部分都由两部分组成，一部分是强制必须有的，另一部分是可选的认证部分。

强制部分的格式如下：

可选认证部分：

其中各个字段的含义和作用如下：

Vers：版本字段，目前为版本号1。

Diag：Diagnostic，诊断字段，说明本地系统最后一次改变BFD会话状态的原因。

0 -- No Diagnostic，没有振荡信息。

1 -- Control DetectionTime 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，保留。

Sta：Status，本地系统认为的BFD会话的状态，两个bit，四种状态：

0 –AdminDown，管理员强制down。

1 –Down，故障导致的down 

2–Init，初始化状态。

3–Up，up状态。

P bit：Poll位，如设置，说明发送报文的系统要求确认连通性或者确认参数改变。查询模式时，如果需要显式确认连通性，会发送一系列Poll置位的BFD报文。另外，如果BFD会话的参数改变，两种工作模式下都要求发送Poll置位的报文。

F bit：Final位，如设置，说明是对Poll置位的BFD报文的回应。

C bit：Control PlaneIndependent位，如设置，说明系统的BFD实现和控制平面无关。

A bit：Authentication Present位，如设置，数码携带验证部分。

D bit：Demand位，如设置，说明发送报文的系统希望工作在查询模式。

R bit：Reserved位，保留位，必须为0。

Detect Mult：Detect timer multiplie，故障检测时间的乘数因子。用这个值乘以协商出的报文发送时间间隔，就得到异步模式下的故障检测时间。

Length：以字节计的报文长度。

My Discriminator：我的区分符，发送报文的系统用它来区分两个系统之间的多个BFD会话，对每个会话唯一，为非零数值。

Your Discriminator：你的区分符，使用从对端收到的报文的“My Discirminator”字段。初始建立会话或其他情况下，若不知道“Your Discriminator”，填0。

Desired Min TX Interval：本地系统期望的发送BFD报文的最小时间间隔，单位为微秒（百万分之一秒）。

Required Min RXInterval：本地系统希望收到对端发来的BFD报文的最小间隔，单位为微秒（百万分之一秒）。

Required Min Echo RX Interval：本地系统希望收到对端发来的Echo报文的最小间隔，单位为微秒（百万分之一秒）。如果这个值为0，表示本地系统不支持接收Echo报文，即不能环回对端发过来的Echo报文。

Auth Type：如果A bit设置，则表示使用的认证类型。

0 –Reserved，保留。

1 - SimplePassword，简单密码认证。

2- Keyed MD5认证。

3- MeticulousKeyed MD5认证。

4- Keyed SHA1认证。

5- MeticulousKeyed SHA1认证。

6-255 - Reserved for future use，保留。

Auth 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 源端口号来区分会话。

4.定时器协商和维护

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报文发送间隔和会话检测时间的参数，而不影响会话。不过当修改了相关参数时，需要作一些合理的处理，避免会话状态的误判：

如果查询模式激活，则无论改变Desired Min Tx Interval还是改变Required Min Rx Interval，必须发送一个Poll置位的序列，相当于改变参数后作一次显式确认；

如果查询模式未激活，则无论改变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 提供的认证机制有：

Simple Password，简单密码认证。

MD5认证：Keyed MD5认证和 Meticulous Keyed MD5认证。

SHA1认证：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 进程。