网络高可用性技术白皮书（一）

转自 http://blog.163.com/yzc_5001/blog/static/20619634201218105450112/

网络高可用性技术，基本都可以归入容错技术，即在网络出现故障（错误）时，确保网络能快速恢复。对目前常用的高可用性技术，可以作一个简单的归类：
? 单个设备上的硬件冗余，如双主控、单板热插拔、电源冗余、风扇冗余等；
? 链路捆绑，如以太网链路聚合、MP、MFR等；
? 环网技术，如RPR、RRPP；
? STP、Smart Link、Flex Link等二层冗余技术；
? 冗余网关技术，如VRRP、HSRP、GLBP；
? ECMP，浮动静态路由，动态路由快速收敛（如快速hello，iSPF）；
? 不间断转发：NSF/SSO/GR；
? MPLS 快速重路由；
? 快速故障检测技术，如BFD。
1. 硬件冗余
这里的硬件冗余指的是单台设备上的硬件冗余，一般有主控冗余、交换网冗余、单板热插拔和电源风扇冗余等，使用冗余部件可以在单个部件可靠性一定的情况下，提高整个设备的可用性。随着硬件技术的进步，目前很多设备交换网集成在主控板上，所以交换网冗余不单独介绍。
1.1 主控冗余
在设备只有单主控的情况下，如果主控板故障，重起主控板需要加载映象文件、初始化配置、重新注册业务板，然后重建控制平面和转发平面表项，整个过程在5分钟左右，这个时间实在是太长了，特别对于网络中处于单点故障的节点来说更是如此，因为业务在这个过程中将完全中断。为了缩短这个时间，主控冗余应运而生。
主控冗余是指设备提供两块主控板，互为备份。因为主控冗余在控制和转发分离的架构下才能发挥最大的效用，这里先介绍一下控制和转发分离的概念。在控制和转发分离的架构中，控制平面负责各种协议，如路由协议（如RIP/OSPF/IS-IS/BGP）、标签分发协议（如LDP/RSVP-TE/BGP）等的处理，形成路由信息表（RIB）和标签信息表（LIB），从其中选择最优者，加上必要的二层信息，形成路由转发信息表（FIB）和标签转发信息表（LFIB），下发到转发平面，转发平面据此实现快速转发。控制平面的处理在主控板上进行，转发平面的处理既可以在主控板（集中式设备），也可以在业务板（分布式设备）。一旦实现了控制和转发分离，即使控制平面出现故障，转发平面的转发表项在短时间内可以认为仍然合理，继续转发数据而不会导致问题（如环路），当然，控制平面必须能快速恢复并重新和邻居建立协议会话，收敛后再对转发平面进行检查，对表项作必要更新，删除在新的会话环境下不再正确的转发表项。
在主控冗余的设备上，配备了两块主控板，一块实际起作用，称为Master，另一块备用，

称为Slave。只有Master进行控制平面的处理，并生成转发表项。Slave上的映像文件虽然也充分启动，配置也从Master实时备份，但Slave不参与控制平面的处理。不过，Master转发平面的各种表项（如L2/L3转发表项、组播转发表项、标签转发表项），会以实时增量备份和定期完整备份相结合的方式持续备份到Slave上。虽然Slave上的控制平面对网络状况一无所知，但转发平面确因为和Master进行了同步而基本能反映当时的网络转发状态，随时可以替换Master承担起转发任务，这就是转发和控制分离带来的效果。
设备实时检测Master是否正常工作，检测手段可以是检测主备板之间的硬件心跳，也可以使用IPC通道或用其他方式进行检测。一旦发现Master异常，立即启动主备切换，由Slave接管Master的工作，Master和Slave的角色互换。和单主控相比，双主控的收敛性能要好得多，因为在双主控情况下，Slave已经预先完成映象文件的加载和配置的初始化工作，主备切换时业务板不需要重新注册，二三层接口也不会出现up/down。另外，因为Slave上已经备份有转发表项，可以立即承担转发任务，在一定程度上可以避免业务中断。
不过，因为新的Master在主备切换前不参与控制平面的处理，在切换后需要重新和邻居进行会话协商，所以虽然保存了完整的转发表项，但只能避免部分流量不中断。比如，二层业务，以及从本设备往外发送的流量可以不中断；另外，如果和邻居之间配置的是静态路由或静态LSP的话，邻居也会继续往发生倒换的设备发送流量，流量不中断。但如果和邻居之间是动态路由协议或动态标签分发协议，和邻居之间的流量是会中断的，这是因为控制平面会话重置的情况下，邻居的控制平面会重新计算，选择它认为合适的路径。以OSPF协议为例，新Master在发出的Hello报文中没有原来邻居的RID，会导致邻居把OSPF会话状态重置，并把和发生切换的设备相关的LSA删除，导致路由重新计算，如果有其他可选路径的话，流量会绕开发生主备切换的设备，如果没有可选路径，则需要等待OSPF重新收敛，在重新收敛之前，邻居是不会把流量发给发生主备切换的设备的。
下面分析一下主备切换的收敛时间。主备切换的前提条件，是检测到Master故障。在Master故障但没有被检测到的时间内，会导致报文丢失。其次，主备切换期间也会丢一部分报文。最后，主备切换完成后，设备需要和和邻居重建协议会话，这也需要一定时间。总的来说，主备切换的收敛时间为：Master故障检测时间+切换时间+信令收敛时间。
1.2 单板热插拔
单板热插拔，是指在设备正常运行时，在线插拔单板，而不影响其他单板的业务。一般的中高端机架式设备，均支持单板热插拔。单板热插拔功能包括：
? 往机框中新增单板不影响已经在用单板
? 可在线更换单板，即拔出单板换一块新单板（或老板重新插入）时，新单板能继承原来的配置，并且不影响其他单板的工作。
? 对于分布式设备，在添加或插拔单板时，FIB表能同步到单板。
单板热插拔和跨板的链路捆绑技术相结合，一定程度上提供了单板间的1：N备份功能。
单板热插拔的收敛时间不好衡量，就以配置继承和生效为例，收敛时间和配置的类型及配置的多少有极大的关系。如果和链路捆绑结合，收敛时间还和链路捆帮的收敛时间相关。

1.3 电源风扇冗余
为了保证设备电源收入的稳定，中高端设备一般提供双路电源输入，当一路输入出现故障时，能自动切换到另一路，不影响设备功能。另外，中高端设备一般通过多个电源模块供电，采取1：N备份方式，一个电源模块为其他N个提供备份，在拔出某一个电源模块时，其他模块能提供足够电源功率。
风扇作为散热的重要手段，中高端设备也提供风扇冗余，一般提供多个风扇框，可以在线更换其中的风扇框，不影响产品功能。
电源和风扇的切换和更换不应该影响产品的转发功能，可以认为其收敛时间为0。
2. 链路捆绑技术
链路捆绑，就是把多个属性相同的物理链路捆绑在一起，逻辑上当成一个链路。链路捆绑能带来以下好处：
? 能提供更高的链路带宽
? 流量可在各个链路间实现负载分担
? 链路间互为备份，可提高可用性。
另外，跨单板、跨设备的链路捆绑事实上提供了一定程度的单板、设备间的互为备份功能，较大的提高了网络的可用性。
常见的链路捆绑有：以太网链路聚合，多链路PPP，多链路帧中继等。因为链路捆绑相对比较简单，这里不展开叙述。
3. 热补丁技术
1. 热补丁原理
补丁是计算机软件系统和软件工程学中的一个术语，一般是为了对系统中的某些错误进行修正而发布的独立的软件单元。它能够在不影响系统正常运行的情况下完成对系统错误的修正，也就是对系统进行动态升级。
基本原理就是在系统中保留一段内存空间，将新的函数实体以补丁文件的方式加载其中，根据要被替换函数的入口地址找到被替换函数的第一条执行指令，将其改为一条跳转指令，跳转地址为新函数的入口地址；这样当其他函数要调用被替换函数时，CPU根据跳转指令就会执行新的函数实体。
2. 热补丁状态转换
各厂商实现热补丁的基本原理大体相同，但具体实现上有一定差别，下边以H3C公司热补丁技术为例简单介绍状态机转换和各状态的作用。
补丁存在四种状态：
? 空闲(IDLE)：初始状态，补丁没有被加载

? 去激活(DEACTIVE)：补丁已经加载，但未被激活
? 激活(ACTIVE)：补丁处于试运行状态
? 运行(RUNNING)：补丁处于正式运行状态
激活态与运行态的最大区别在于系统重启后，激活态的补丁转换为去激活态，不再发挥作用，而运行态的补丁在系统重启后仍然保持为运行态，继续发挥作用。补丁的激活态主要是提供一个缓冲带，以防止因为补丁错误而导致系统连续运行故障。
补丁的状态只有在用户命令的干预下才会发生切换，命令与补丁状态的切换关系如下图所示

 

 

4. IRF智能弹性架构
IRF(Intelligent Resilient Framework)，即智能弹性架构，是创新性建设网络核心的新技术。它将帮助用户设计和实施高可用性、高可扩展性的千兆以太网核心和汇聚主干。
运用IRF技术可以将多台三层交换机互联在一起形成一个逻辑交换实体，称为一个fabric，fabric内每一个交换机称为一个unit。从管理和配置的角度看，一个fabric看起来就像一台交换设备；从性能角度看，分布式交换架构中的每台交换机都能针对其端口上的第二层/第三层流量通信业务制定本地转发决策。

和传统的堆叠技术相比，IRF是一种更为增强的堆叠技术，在多方面进行了创新或增强，除了可以做到扩展端口、统一管理之外，IRF在高可靠性、冗余备份方面比传统堆叠有了很大提高。IRF技术可以容许全局范围内的跨设备链路聚合，提供了全面的链路级保护。同时，IRF技术实现了跨设备的三层路由冗余，可以支持多种单播路由协议、组播路由协议的分布式处理，真正实现了多种路由协议的热备份技术，这些方面都是传统堆叠技术难以做到的。此外，IRF技术实现了二层协议在fabric内分布式运行，提高了堆叠内unit的利用率和可靠性，减少了设备间的协议依赖关系。
具体来说，IRF主要包括3方面的技术实现：DDM（分布式设备管理）、DDR（分布式路由）、DLA（分布式链路聚合）
4.1 分布式设备管理
从外界看来，整个fabric是一台整体设备，用户可以通过CONSOLE、SNMP、TELNET、WEB等多种方式来管理整个fabric。

 

 IRF技术最多可以连接8台设备组成一个fabric，无论是管理特性、还是转发特性，在用户看来，fabric就像是一台设备在运行。既然多台设备堆叠当成一台设备运行，就要解决堆叠设备间配置不相同的问题。系统内的配置被分为全局配置和局部配置，全局配置包括三层接口、IP地址、路由协议、安全特性等，这些配置在fabric内每台设备上是必须要一致的；局部配置包括端口参数等，是每个设备特有的，不必相同。
1. 配置同步
当配置不相同的设备堆叠在一起时，会选取unit编号最小的设备作为master，其他的堆叠设备作为slave。与选举相关的因素有三个：UnitID、UnitRole、RunMode。UnitID是堆叠设备在fabric中的编号，1~8；UnitRole是指该unit的角色，分为master和slave，宏对应值为0和1；RunMode是指该unit的运行模式，分为L3和L2，宏对应值分别是0和1。选举master的考虑顺序是：UnitRole > RunMode > UnitID，“>”表示左边比右边优先考虑，比较的时候值小的为优先级高。
堆叠时，slave设备先获取到master设备的当前配置，与自己当前的全局配置比较，如果相同，直接堆叠起来。如果不相同，slave会用master的全局配置和自己的局部配置组成临时配置文件，自动重启后用这个配置文件配置设备，完成配置同步过程，从而使堆叠组内所有unit的全局配置保持一致。
2. 软件版本升级
对于以前的简单堆叠，软件版本升级需要在堆叠组内每个unit上执行一次，而IRF技术在这方面有了明显改善，通过WEB网管，用户只需要执行一次操作，就可以实现fabric内所有unit软件的自动同步升级。
3. 设备的热插拔
当一台设备通过堆叠线加入到一个正在运行的fabric内，原有的fabric就会检测到新设备，同时验证新设备是否可以加入到fabric，如果验证通过，新加入设备会得到原有的全局配置信息和转发信息，同时将自己的局部配置和转发信息广播到fabric内每台unit，经过短暂的信息交互，新加入设备就可以参与转发了。这个过程不会影响原有fabric内业务的转发，也可以支持两个fabric合并。

当一台设备从fabric分离出去，可能会形成一个新的fabric，由于fabric内所有unit全局配置都是相同的，分离出去的fabric和原fabric具有完全相同的全局配置，这样可能会产生冲突，如三层接口ip地址冲突。IRF提供了Resilient ARP技术，当检测到分离出去的unit与原fabric存在ip地址冲突，则会把其中之一的设备降为二层设备使用，避免冲突而引起网络路由的震荡。
通过支持热插拔特性，当设备扩容的时候只需更多的交换机堆叠在一起，就可以简单实现扩容端口和交换容量的目的；单台设备故障，可认为是fabric减少了一台堆叠设备，对fabric内其他设备流量转发不会产生影响，通过本设备的业务流也会快速切换到其他设备上。
4.2 分布式路由
IRF交换机支持的多数协议，如：RSTP、IGMP-SNOOPING、LACP等，都是分布运行在fabric内各个设备上的，每个设备独立运行协议，与外部协议实体进行交互；同时，为了保持IRF作为一个整体运行，unit之间完成必要的信息交互。
下面以三层转发为例说明IRF如何实现分布式路由功能的，fabric内的任意一个unit都有完整的三层转发能力，当它收到待转发的三层报文时，可以通过查询本unit的三层转发表得到报文的出接口以及下一跳，然后将报文从正确的出接口送出去，这个出接口可以在本unit上，也可以在其它unit上，因为fabric始终是作为一台设备进行工作的，任何一个unit上的接口都是fabric上的接口，将报文从一个unit送到另外一个unit是一个纯内部实现，对外界是完全屏蔽的，即对于三层报文来说不管它在fabric内部穿过了多少unit，在跳数上只增加1，即表现为只经过了一个网络设备，在fabric内部的报文传递是不会改变报文的三层属性的。

不管转发出端口是在本地，还是在fabric内其他设备上，通过在本地一次查找路由转发表，报文就可以实现三层转发任务。相对于集中式的转发，减少了对单台设备的依赖，同时减轻设备的转发负载。二层分布式转发与三层类似。
4.3 分布式链路聚合
分布式的聚合技术进一步消除了聚合设备单点失效的问题，提高了聚合链路的可用性。由于聚合成员可以位于系统的不同设备上，这样即使某些成员所在的设备整个出现故障，也不会导致聚合链路完全失效，其它正常工作的unit会继续管理和维护剩下的聚合端口状态。这对于核心交换系统和要求高质量服务的网络环境意义重大。

DLA技术允许IRF堆叠组进行跨unit的链路聚合（静态、手工、LACP模式），在实现到同一宿主主机链路备份的同时，也能够完成聚合链路的负载分担，保证在单链路/unit实效时，不会影响所有业务，极大提高了全网的可用性。

 

网络高可用性技术白皮书（二）  

2012-02-08 12:37:10|  分类： 网络技术 |  标签：可靠性   |字号大中小 订阅

 

 

1. 环网技术
环网技术通过把设备环形相连，在提供一定链路冗余的情况下避免了复杂的Mesh组网，环网有很强的单点故障自愈能力。环网技术分单环和双环两种结构。通信技术的发展过程中，出现了不少的环网技术，如Token Ring、FDDI、SDH等。
环网也因其固有拓扑而导致一些缺点，首先，对于多点故障难以提供故障保护，故障保护手段比较单一；其次，只要有一个区段出现带宽不足，需要环网的所有区段都扩容；另外，环网的每个节点只有两个纬度，资源利用效率相对较低。
这里简单介绍一下两种相对较新的环网技术：RPR（Resilent Packet Ring，弹性分组环）、RRPP（Rapid Ring Protection Protocol ，快速环保护协议），其中RPR为双环、RRPP为单环。
1.1 RPR
RPR（Resilient Packet Rings，弹性分组环）工作在OSI协议模型第二层的MAC层，和物理层无关，可运行于Ethernet 、SONET/SDH和DWDM之上。 RPR技术吸收了以太网的经济性、灵活性和可扩展性以及SDH对延时和抖动的严格保障、可靠的时钟和50ms环网保护特性，RPR不仅支持IP业务，也能很好的支持传统的TDM业务。
RPR组网沿袭了SDH的环型结构，是互逆双环结构，分别为0环和1环，0环数据传送方向为顺时针，1环为逆时针。RPR继承了SDH的快速自愈能力，能实现50ms的故障切换。
RPR有两种故障自愈方式：绕回（wrap）方式和抄近路（Steering）方式。绕回方式是数据在故障链路两端节点的0环和1环环回，优点是收敛快，缺点是绕回路径长，占用带宽较多。抄近路方式是直接走另外一个环，抄近路方式因为走另外一个环需要重新收敛，因此收敛速度稍慢，不过路径短，占用带宽少。下图列出了在正常情况下报文的转发路径，以及出现故障后，Wrap方式和Steering方式时报文的转发路径。

 

在两种故障自愈方式下，收敛时间都在50ms以内。

1.2 RRPP
为了缩短网络故障收敛时间，华为3Com推出了革新性的以太环网技术——RRPP（Rapid Ring Protection Protocol，快速环网保护协议）。RRPP技术是一种专门应用于以太网环的链路层协议，它在以太网环中能够防止数据环路引起的广播风暴，当以太网环上链路或设备故障时，能迅速切换到备份链路，保证业务快速恢复。与STP协议相比，RRPP协议具有算法简单、拓扑收敛速度快和收敛时间与环网上节点数无关等显著优势。
1. RRPP基本概念
a) RRPP域（RRPP Domain）：
RRPP域由整数表示的ID来标识，一组配置了相同的域ID和控制VLAN，并且相互连通的交换机群体构成一个RRPP域。一个RRPP域具有如下的组成要素。
b) RRPP环：
一个RRPP环物理上对应一个环形连接的以太网拓扑，一个RRPP域由彼此相交的多个RRPP环构成，其中有一个为主环，其他环为子环。相切环情况下可以都配置为一个主环；一个RRPP域也可以只包含一个RRPP环。RRPP环的角色由用户通过配置决定。
c) RRPP控制VLAN：
每个RRPP域可以具有两个控制VLAN，分别叫做主控制VLAN和子控制VLAN。主环的协议报文在主控制VLAN中传播，子环的协议报文在子控制VLAN中传播。
d) 主节点：
主节点是RRPP环上的主要决策和控制节点。每个RRPP环上必须有一个主节点，而且只能有一个。主节点的环上端口分为主端口和从端口，环完整的情况下，通常阻断从端口。
e) 传输节点：
环上除主节点之外的其它节点都可以称为传输节点（边缘节点和辅助边缘节点实际上是特殊的传输节点）。一个RRPP环上可以有多个传输节点。

f) 主端口和从端口：
主节点和传输节点接入以太网环的两个端口中，一个为主端口，另一个为从端口，端口的角色由用户的配置决定。主节点的主端口和从端口在功能上是有区别的。主节点从其主端口发送环路状态探测报文即Hello报文，如果能够从从端口收到该报文，说明本节点所在RRPP环网完整，因此需要阻塞从端口以防止数据环路；相反如果在规定时间内收不到探测报文，说明环网故障，此时需要放开从端口以保证环上所有节点的正常通信。传输节点的主端口和从端口在功能上没有区别。端口的角色同样由用户的配置决定。
2. RRPP基本原理
a) RRPP协议基础
? 每个域上所有节点配置相同的RRPP域ID和控制VLAN
? 协议报文在控制VLAN中传播
b) 正常工作原理
RRPP环主要由一个主节点、多个传输节点和控制VLAN构成，主节点配置主端口和从端口，正常工作时主节点周期性地从主端口发送Hello报文，从端口一旦接收到自己发送Hello报文，立刻阻塞从端口。控制VLAN主要传输RRPP的控制报文，有效保护控制报文。

c) Polling机制
Polling机制是RRPP环的主节点主动检测环网健康状态的机制，主节点周期性地从其主端口发送Hello报文，依次经过各传输节点在环上传播。如果主节点的从端口能收到自己发送的Hello报文，说明环网链路完整；否则如果在规定时间内收不到Hello报文，就认为环网发生链路故障。

 处于故障状态的主节点从端口收到自己发送的Hello报文，立即迁移到环恢复状态，阻塞从端口并刷新转发表，而且主端口发送刷新转发表的报文通知所有传输节点放开临时阻塞端口和刷新转发表。
d) 链路状态变化通知机制
链路状态变化通知机制是一种比Polling机制更快处理环网拓扑改变的机制，这一机制的发起者是传输节点。传输节点总是在监测自己的端口链路状态，一旦状态发生改变，它就会通过发送通知报文把这种变化通知主节点，然后由主节点来决定如何处理。如果检测到端口Down，将会发送故障通知报文。主节点接收到该报文会立刻放开从端口，刷新本地转发表的同时发送报文通知其他节点刷新转发表。

 

e) 故障恢复机制
环故障状态的主节点通常从端口接收不到自己发送的Hello报文；故障节点的链路恢复也会进入临时阻塞状态，但环的Hello报文可以通过该阻塞端口，这样主节点会接收到自己发送的Hello 报文，主节点认为环已经恢复正常，立刻阻塞从端口且刷新转发表，并同时从主端口发送报文通知所有传输节点放开临时阻塞端口和刷新转发表，传输节点接收到该报文后会立刻放开临时阻赛端口且刷新转发表。
2. STP和Smart Link
STP和Smart Link技术都可以解决由于链路冗余而产生的二层环路问题，其中STP可以应用于各种拓扑，Smart Link则可以认为是对特定组网情况下对STP的替代技术。
解决二层环路技术而提出的技术很多，前面的RRPP也可以认为是这种技术。另外一种值得一提的技术是分布式链路聚合技术，通过跨设备的链路聚合，可以避免环路，不用使用STP，并做到链路负载分担。有些分布式链路聚合技术只能在同一个堆叠组的设备间跨设备聚合，另一些

分布式链路聚合技术则可以跨任意设备聚合。
这里只介绍STP和Smart Link。
2.1 STP/RSTP/MSTP
STP（Spanning Tree Protocol，生成树协议）是IEEE为了避免二层链路环路而提出来的技术，在解决二层环路的同时能提供链路冗余，STP适用于任何拓扑，环形拓扑和Mesh拓扑都能胜任。不过，STP的收敛时间较慢，通常是30秒，特殊情况下要到50秒，难以适应当前数据网络中业务的需要。
为了提高STP的收敛速度，IEEE提出了RSTP标准，即快速STP。RSTP相对于STP的改进有：
1． RSTP把端口角色和端口状态进行了分离，并简化了端口状态： RSTP中只有discarding、learning和forwarding三个状态。相对来说，STP有五个状态disable、blocking、listening、learning和forwarding。
2． RSTP更精细的划分了端口角色：root端口、designed端口的定义和STP一样；但对于处于discarding状态的端口，细分为alternate端口和backup端口，分别是对根端口和指定端口的备份；另外，引入了一类特殊的Designed端口——edge端口，即和主机或其他终端设备相连的端口。
3． 基于对端口角色的精确划分，RSTP引入了各种端口的快速迁移机制：
1) designed端口的快速迁移机制，在P2P链路上，如果designed端口处于discarding状态，立即启动proposal和同步过程，快速收敛网络。
2) edge端口可以立即forwarding。这在CISCO中称为portfast。
3) 失去root端口后，立即启用最优的alternate端口。CISCO中称为uplinkfast。
4． 网桥不再简单中继根桥发送的BPDU，而是每hello timer从指定端口独立发送BPDU。如果一个端口三次没有收到该网段指定桥从指定端口发送的BPDU，就认为指定桥故障，这可以加快BPDU的老化，快速发现网络故障。比如，这避免了STP中非直连链路失效时20秒的报文老化时间。
5． 次优BPDU（Inferior BPDU）处理的优化，在STP中，只有Designed端口收到了次优的BPDU，才回应一个BPDU报文。在RSTP中，如果非Designed端口收到了原指定桥的次优BPDU，也立即回应一个BPDU，这避免了一个网段的原指定桥在失去root端口后，需要等待对端20秒时间老化报文后才能收敛。在CISCO中，这个优化称为backbone fast。
6． 只有在非edge端口变为forwarding时才发拓扑改变报文，而且一旦设备感知了拓扑

改变，拓扑改变信息在所有的root端口和非边缘的designed端口扩散，这保证了拓扑改变的信息的快速传播和网络的快速收敛。在STP中，端口变为fowarding或变为blocking都会导致发送拓扑改变报文，而且拓扑改变由感知拓扑改变的桥设备先知会根桥后，再由根桥发送拓扑改变报文，这大大延迟了网络收敛。
RSTP相对于STP，大大加快了收敛时间，链路up/down的情况下可以达到几百毫秒的收敛速度。下面对RSTP和RRPP作一个比较：
1． 适用的拓扑：RSTP可以适用于任何拓扑，RRPP只能适用于环形拓扑。
2． 收敛时间，假设都是环形组网，并且是P2P链路相连。虽然链路up/down或节点的故障检测时间，RRPP和RSTP差不多，但整网收敛时间RRPP相比RSTP收敛时间要快，主要的原因是，RRPP报文的转发在传输节点上是硬件转发并拷贝上CPU，而RSTP报文需要逐跳由CPU处理后再转发，这导致拓扑变化在RSTP下传播比RRPP慢，整网收敛也就慢。
3． 节点个数限制问题：RRPP报文的轮询报文绕环一周，轮询报文的延迟随着环上节点个数的增多而增大，但只是亚毫秒级的影响，对RRPP的收敛性能影响有限，因此和RSTP相比，可以认为RRPP环上的节点的规模没有限制。RSTP因为报文的Max age，环上节点个数也受影响，虽然可调整Max age的大小作出应对，但因为RSTP报文是逐跳送CPU处理的，报文延迟较大，节点个数太多对收敛性能影响较大。
4． 安全性问题，RRPP使用独立的VLAN传播信令，可以认为安全性较RSTP为高。
总体来说，RRPP因为是针对环网开发的，在环网拓扑情况下，相对RSTP这种为适应任意拓扑开发的协议有一定的性能优势。
RSTP相对于STP，解决了收敛速度较慢的问题。但是没有解决冗余链路利用率低的问题，在STP/RSTP中如果一个端口被阻断，那么该端口的链路事实上是被闲置了。
MSTP，即多实例STP的出现解决冗余链路利用率低的问题。MSTP中，一组VLAN使用一个STP实例，每个STP实例使用和RSTP相同的处理规则。在MSTP中，端口的阻塞是逻辑上的，只对某些STP实例进行阻塞，一个端口可能对一个STP实例阻塞，但对另一个STP实例是可以转发的。合理的使用MSTP，可以做到链路的负载分担。而且，因为映射到一个MSTP实例的VLAN可以灵活控制，并且引入了域的概念，使得MSTP在部署时有很好的扩展性。
2.2 Smart Link
在实际组网中经常用到的组网模式是二层双上行链路，其中一条链路作为另一条链路的备份。通常的解决方案是使用STP。但是STP是作为解决二层环路，提供二层冗余链路的通用技术，在这种特定的组网中，体现不出其优势。
H3C和CISCO针对这种常用组网，分别提出了Smart Link和Flex Link技术，作为STP的替代。这里只简单介绍Smart Link的实现机制。

如图10 Smart Link组网图所示，设备30上端口31上的链路是主用链路，端口32上的链路是备用链路，正常情况端口31处于转发状态，端口32处于阻塞状态。当端口31的链路出现故障时，端口31将切换到阻塞状态，端口32将切换到转发状态，切换时间小于200毫秒。这里的链路故障包括端口UP/DOWN，光纤的错纤故障，单纤故障等，此类故障需要响应DLDP的事件。主备链路可以是聚合链路，只有聚合组内所有链路都出现故障时才认为该聚合链路故障。目前我们只支持手工和静态聚合，不支持动态聚合。

说到了Smart Link技术，这里也要提一下Monitor Link。如上边组网图，设备20与设备40汇聚到设备10，当汇聚上行端口，如端口21，出现故障时，由于Smart Link组的主链路仍然都处于正常状态，设备30不会主动将业务切换到备用链路上去，但事实上设备30上的流量已经无法通过端口31的链路上行到设备10。此时应该阻塞端口31，使端口32进入转发，将流量切换到备用链路上。为了使设备30感知到汇聚上行链路的故障，需要对设备30进行上行端口监控，当设备30的上行端口出现链路故障时，将所有Monitor Link组里的下行端口一起SHUTDOWN，从而使Smart Link将流量切换到备用链路上。
当Smart Link发生链路切换时，网络中各设备上的MAC表项可能已经错误，需要提供一种MAC更新的机制。目前刷新机制有两种，一种方式是自动通过流量刷新MAC；另一种方式是由Smart Link设备从新的链路上发送Flush报文。第一种方式需要有双向流量触发，第二种方式需要上行的设备都能够识别Smart Link的Flush报文并进行删除MAC表项的处理，Flush报文还需要继续向上转发。
当原主用链路故障恢复时，将维持在阻塞状态，不进行抢占，从而保持流量稳定。
3. 网关冗余技术
网关冗余技术是为了解决局域网内主机静态配置缺省网关时，存在单点故障问题而提出的技术。基本的设想是，让多个物理网关虚拟出一个或多个虚拟网关，局域网内主机的缺省网关静态配置成这些虚拟网关，虚拟网关的转发任务由选举出来的某个物理网关承担，只要不是所有物理

网关同时故障，总能选举出一个物理网关承担虚拟网关的转发任务。通过把局域网内主机的缺省网关配置成不同的虚拟网关，网关冗余技术还可实现流量的负载分担。
目前的虚拟网关技术有VRRP、HSRP和GLBP，其中HSRP和GLBP是CISCO的私有技术。HSRP（Hot Standby Router Protocol）完成和VRRP类似的功能，这里不作介绍，GLBP相对于VRRP做了优化，所有主机配置同一个网关地址就可实现负载分担，简化了管理。
3.1 VRRP
VRRP，即Virtual Router Redundancy Protocol。VRRP协议把局域网内的多个物理网关组织成一个或多个虚拟网关，局域网内的主机把缺省网关静态配置为这些虚拟网关的IP，主机和外部网络之间的通信流量由虚拟网关进行转发。参与构建一个虚拟网关的多个物理网关称为一个VRRP虚拟组。
虚拟网关的报文转发功能由虚拟组中某个物理网关实际承担，这个网关被称为Master，Master由VRRP虚拟组中的成员根据VRRP协议规则选举产生，竞争Mater失败的其他成员称为Backup。一旦选定的Master因为故障不能承担虚拟网关任务，VRRP协议会快速从其他Backup设备中选择出一个Master继续承担局域网和外部通信的任务，保证局域网和外部网络之间的通信快速恢复。
Master的选举通过比较每个网关在该VRRP虚拟组中的优先级（priority）来实现，优先级高的优先成为Master，如果优先级相同，IP地址大的获胜。判断自己为Master的设备发送VRRP通告报文，其中携带自己的优先级和IP地址信息，收到通告报文的设备进行比较：如果自己优先级更高，那么判断自己为Master，发送VRRP通告，原Master收到这个通告后将判断自己为Backup，不再发送通告；如果自己优先级持平或更低，判断自己为Backup，保持静默。优先级的范围为0－255，通过配置优先级，管理员可以控制Master的选举，可配置的优先级范围为1－254，缺省优先级为100。其中0和255有特殊用处：实际IP地址和虚拟网关IP地址相同的网关，其优先级为255，而且总是成为Master；如果当前Master不再参与VRRP组（比如shutdown），那么发送优先级置为0的VRRP通告，触发Backup立即转为Master，不必等待当前Master超时。
不过，有时优先级高的获胜成为Master会带来问题，比如，在一个VRRP虚拟组中，如果一个优先级高的路由器RA故障，于是RB接替其成为Master。一段时间后RA恢复，如果这时让RA成为Master，VRRP重新收敛，会导致网络产生不必要的中断。针对这种情况，VRRP提出了抢占模式和非抢占模式的概念。在非抢占模式下，如果已经有Master，那么即使其他设备有更高的优先级，也只有原Master故障情况下，其他设备才可能被选举为Master。另外，为了更进一步提高网络可用性，即使在抢占模式下，也建议设置一个延时时间，即选举为Master的设备延迟一段时间才通告自己为Master，因为如果VRRP配置了对上行链路的监控，在网络链路不稳定时，会导致优先级的增减，这时，如果不设置延时时间，会导致VRRP的Master频繁变化，严重影响业务。对链路的监控功能后面会讲到。
如果要实现负载分担，可以构造多个VRRP虚拟组组，每个虚拟组构建一个虚拟网关，局域网内的主机通过配置自己的缺省网关为不同的虚拟网关，可以实现负载分担。不过，VRRP实现负载分担的这种方式不利于根据实际情况动态进行负载分担调整，特别是当某个物理网关发生故障时，最初的分担策略一定程度上失去意义，重新调整用户主机配置又会带来管理上的不便。
下面通过图示，简单说明VRRP的工作原理。

上图中，RA和RB是一个局域网上的两个物理网关，配置了两个VRRP虚拟组，VRID1和VRID2。RA为VRID1的Master，VRID2的Backup；RB为VRID1的Backup，VRID2的Master。局域网内的主机部分配置网关为VRID1的地址，部分网关为VRID2的地址，分别由作为虚拟组Master的RA和RB来承担转发任务，实现负载分担。
VRRP还提供了对上行口监控的功能，上图中，在RA上可配置在虚拟组VRID1中对上行接口进行监控，如果上行接口down，那么RA在VRID1中的优先级会降低，在抢占模式下，RB被选举为VRID1的Master，流量从RB转发，网络不会中断。CISCO在HSRP（IOS12.3）中对这个特性作了经一步扩展，可以监控路由是否可达，更好的确保通过Master可以和外面的网络连通。
最后分析一下VRRP协议的收敛性能。VRRP协议规定，如果3个Adver_interval时间内没有收到Master发送的VRRP报文，就会发生状态切换，所以VRRP的收敛时间理论上可以认为是3×Adver_interval。目前CISCO的Adver_Interval以毫秒为单位，理论上可以作到亚秒级收敛。
不过，Adver_Interval设得过小会极大加重设备CPU负担，特别在存在较多VRRP组的情况下更是如此。当然，不排除随着硬件技术的进步和软件的优化，特别在高端设备上，设备处理VRRP报文的能力得到大幅提升，配置Adver_Interval以毫秒为单位可以成为现实。
3.2 GLBP
GLBP，即Gateway Load Balancing Protocol，是CISCO的私有协议。在VRRP/HSRP中，如果要实现网关的负载均衡，需要配置多个虚拟路由组，相应的，主机需要配置不同的默认网关，这带来了额外的管理开销。GLBP在不用配置多个虚拟组的情况下可以实现负载分担，也即所有主机配置相同网关地址就可以实现负载分担。
一个GLBP虚拟组只提供一个虚拟IP，但为这个虚拟IP分配多个虚拟MAC。和VRRP一样，GLBP为每个GLBP组选举一个AVG（Active Virtual Gateway），GLBP组的其他成员作为AVG的备份。虚拟组中的成员通过GLBP Hello报文（UDP封装，目的IP为组播地址224.0.0.102，源和目的端口均为3222）相互通信，通告相关信息。

虚拟组的成员通过Hello报文知道了谁为AVG后，向AVG发送GLBP Request报文，请求为自己分配虚拟MAC，AVG以GLBP Reply报文回应给请求者分配的虚拟MAC地址，CISCO支持一个组最多四个虚拟MAC。如果一个虚拟组成员分配到了一个虚拟MAC，那么它负责转发目的MAC为这个虚拟MAC的报文，称为这个虚拟MAC的AVF（Active Virtual Forwarder），虚拟组的其他成员作为这个虚拟MAC的备份转发者，在AVF失效时会被选择承担转发任务。AVG还负责回应主机的ARP请求，通过对不同的主机ARP请求回应不同的网关虚拟MAC，可以灵活控制各个GLBP虚拟组成员的负载。
下图是GLBP的原理图，其中主机配置相同的网关IP 10.21.8.10，但他们获取的网关MAC不一样，两个网关Router A和RouterB分别为这两个MAC的AVF。其中RouterA被选举为这个GLBP组的AVG。

和VRRP中的Master选举类似，AVG的选举也是根据网关的priority来选举的，优先级高的获胜。如果优先级相同，IP地址大的获胜。和VRRP一样，GLBP也支持AVG选举的抢占模式和非抢占模式，工作方式也类似，这里不再赘述。
当某个虚拟MAC的AVF失效时，需要从备份组的其他成员中选择一个Forwarder承担 转发任务，这个过程也是通过优先级来选举的，但目前CISCO公开发表的文档中没有对如何确定AVF的优先级给出详细说明。
不过AVF的选举相对于AVG有一点不同，如果某个虚拟MAC的AVF因故障失效，重新选举出一个AVF承担这个虚拟MAC的转发任务的话，那么这个新AVF就承担了两个虚拟MAC的转发，负载过重，GLBP有必要针对目前转发报文的网关少了一个的情况重新实施负载分担的策略。
GLBP的做法是，先假定这个故障的AVF还会恢复，所以在一段时间（Redirect timer）内，AVG会继续给主机回应这个虚拟MAC，新选举出的AVF承担这个虚拟MAC的转发。“Redirect timer”超时后AVG不再回应这个虚拟MAC，但新的AVF仍然继续转发目的地址为这个虚拟MAC的报文，这是为了防止某些主机的ARP超时时间较长。不过，当另一个定时器“timeout timer”超时后，这个虚拟MAC失效，AVF不再转发目的地址为这个虚拟MAC的报文，这个虚拟MAC被AVG回收，可以重新分配。“timeout timer”应该设置为比所有主机的ARP超时时间都长。

GLBP使用一种成为weight的属性来衡量网关的转发能力，GLBP可以配置对接口的up/down状态进行监控来动态改变网关的weight值，如果被监控的接口down掉，weight就减少特定值，表明网关的转发能力遭到了削弱，up就恢复特定值，表明转发能力得到恢复。另外一种更强的监控方式是在监控该接口的up/down的同时，还监控该接口是否启动路由、是否配置了IP地址。
GLBP可以指定如果Weight到达某个lower阈值（认为上行转发能力丧失）就不再承担AVF角色。如果Weight达到某个upper阈值（有一定上行转发能力），就可以承担AVF角色。这也是前面猜测AVF的优先级和weight值相关的原因。
GLBP和收敛相关的有两个定时器，Hellotimer和Holdtimer。Hellotimer为虚拟组成员发送Hello报文的时间间隔。Holdtimer是GLBP组成员认为AVG和AVF有效的时间间隔，超过这个时间没有收到Hello报文，就会重新选举AVG和AVF。
GLBP要求Holdtimer>＝3*Hellotimer。Holdtimer真正决定GLBP收敛时间。Hellotimer默认为3秒，Holdtimer默认为10秒。所以默认收敛时间为10秒。
不过，CISCO的Holdtimer可配置为毫秒级，在较高端的设备上，因为其处理能力较好，可配置Holdtimer在100毫秒级。

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的例子：
图2 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 Detection Time 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 Plane Independent位，如设置，说明系统的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 RX Interval：本地系统希望收到对端发来的BFD报文的最小间隔，单位为微秒（百万分之一秒）。
? Required Min Echo RX Interval：本地系统希望收到对端发来的Echo报文的最小间隔，单位为微秒（百万分之一秒）。如果这个值为0，表示本地系统不支持接收Echo报文，即不能环回对端发过来的Echo报文。
? Auth Type：如果A bit设置，则表示使用的认证类型。
? 0 – Reserved，保留。
? 1 - Simple Password，简单密码认证。
? 2- Keyed MD5认证。
? 3- Meticulous Keyed MD5认证。
? 4- Keyed SHA1认证。
? 5- Meticulous Keyed 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进程。

转载于:https://blog.51cto.com/3layer/898522