网络高可用性技术白皮书之三

网络高可用性技术白皮书（三）
杭州华三通信技术有限公司
目录
网络高可用性技术白皮书（三） (1)
1. 路由快速收敛 (1)
1.1 等价多路径(ECMP) (1)
1.2 浮动静态路由 (1)
1.3 IGP快速收敛 (2)
1.1.3 快速Hello (2)
2.1.3 iSPF (3)
1.4 MPLS FRR (4)
1.1.4 本地保护 (4)
2.1.4 路径保护 (8)
2. 链路检测 (8)
2.1 DLDP链路检测协议 (9)
2.2 BFD (14)
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.3IGP快速收敛
目前常用的标准路由协议为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}
z其中如果使用Seconds参数，就是正常OSPF情况，缺省是4倍的Hello interval，但允
许用户自己配置，单位为秒。

z使用“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.3iSPF
在通常的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为根的最短路径子树。

图1unused link and stub changes
iSPF算法只对受链路状态变化（up、down、insert、delete）影响的子树及其关连节点进行计算，设计良好的iSPF算法可以较大的提升路由计算速度。

iSPF算法在最近的20多年中吸引了很多人的研究，提出了各种算法。

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

1.4MPLS 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.几个术语
在正式开展之前，有必要先明确一下后面常用到的几个术语的含义：
z Protected LSP：被保护LSP，也称主路径（main path）、主LSP（main LSP）。

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

z Detour LSP：指One-to-One backup方式中的备份LSP。

Detour LSP的头节点是PLR，尾节点是主LSP的尾节点，不过，在MP节点Detour LSP和主LSP进行了归并。

z Bypass Tunnel：指Facility backup方式下的备份LSP。

Bypass Tunnel的头节点是PLR，尾节点是MP。

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

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

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

这个交汇LSR，被称为DMP。

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

z 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的例子：
图2One-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。

下图是倒换前后，标签交换情况：
R7R8R5R6物理链路
主LSP Detour 12IP 23IP
图3 One-to-One backup 标签交换示意图
倒换前，走主路径，标签交换过程如上图中黄色标签。

如果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 的一个例子：
图4 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的情况：
图5Facility Backup标签交换示意图
可以看到，在R2把LSP1的流量倒换到备份路径后，R2把R4在LSP1上分配给R3的标签 “28”作为内层标签，R7作为备份路径的倒数第二跳，弹出外层标签，直接以28发送给R4，R4根据标签28，知道应该走LSP1。

把Facility Backup方式和One-to-One Backup方式作一下比较，会有一些有趣的发现： z one-to-one backup方式不使用标签栈，而Facility backup使用。

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

z 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.1DLDP链路检测协议
1.DLDP协议简介
当连接两台设备的光纤或铜质以太网线在物理层上是相通的，如果链路两端的端口之一可以收到对方发送的链路层报文，但对端不能收到本端发送的报文，将这种链路定义为设备上的单向链路。

由于此时链路物理层处于连通状态，能正常工作，因而物理层的检测机制无法发现设备间通信存在问题。

以下图为例，图中所示的光纤连接的错误就无法通过物理层的自动协商等机制发现。

单向链路会引起一系列问题，比如生成树拓扑环路等。

图6 光纤错连示意图
DLDP(Device Link Detection Protocol)协议的作用就是在上述情形下，检测单向链路的存在。

它负责在通过光纤或铜质以太网线（例如超五类双绞线）连接的交换机上，监控物理线路的链路状态，当发现单向链路后，向用户发送告警信息，并根据用户配置，自动或者手动地关闭相关端口。

DLDP协议是二层协议，与一层（物理层）机制协同工作以监控链路状态。

在一层，自动协商机制进行物理信号和故障的检测。

如果一端的链路未连通，逻辑链路未启用，DLDP不起作用。

如果链路两端在第一层都能独立正常工作，DLDP执行自动协商机制所不能完成的任务，在第二层检测这些链路是否正确连接，关闭不可达端口。

第一层和第二层的检测机制的协同工作防止了物理和逻辑的单向连接以及其他协议的失效。

DLDP协议通过与对方交互协议报文（DLDPDU）来识别对端设备，检测链路的连接正确性。

端口上DLDP使能后将启动协议状态机，在状态机的不同状态下会发送不同的报文，与对端交互信息以检测单向链路。

其中，DLDP通告报文（Advertisement）的时间间隔可由用户配置，以便
根据不同的网络环境使DLDP对链路连接错误做出更快的响应。

DLDP能正确工作的前提是，链路两端都正确使能了DLDP功能、双方的DLDP通告报文的发送时间间隔相等、认证方式和密码相同等。

2.DLDP协议报文格式
DLDPDU协议报文格式如下：
图7DLDPDU协议报文格式
各域的含义如下：
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 4 3 2 0 RSY
sh 5 1Flu Reserved
特殊功能标志位
z
RSY标志：表明本端口处于ACTIVE状态或者本端口的某个邻居的信息老化。

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