OSPF DC按需链路技术剖析

摘要

本文主要剖析了OSPF DC链路技术的产生过程，从问题背景、问题分析、解决思路、实现方案到最终技术评价这几个维度，相对比较完整地介绍该技术的过去、现在及将来发展趋势。阅读完本文档，预期读者将对OSPF DC按需链路技术有一个全面的理解，并且会体会到全面考虑技术各个维度的重要性。

一、问题背景

互联网兴起初期，一些按需使用的链路带宽非常宝贵，而使能OSPF协议后会有大量的交互报文，比如数据库同步完邻居状态到达FULL后，会有大量定期发送的HELLO报文及定期刷新的LSA更新报文，占用了大量宝贵的链路带宽。如何减少OSPF协议不必要交互的报文以释放所占宝贵的链路带宽，亟需解决。

二、问题分析

2.1 问题定义

由上述问题背景可知，我们遇到的问题是：

如何减少按需链路上OSPF协议不必要交互报文，以释放所占宝贵链路带宽？

2.2 当前技术评估

鉴于当前已有技术，是否存在上述问题的解决方案？我们可能会考虑到如下解决方案：

（1）调整HELLO报文和LSA刷新间隔调至最大，将HELLO报文发送间隔设置为65535，LSA刷新间隔值为固定值1800s，无法修改，这个方案只能在一定程度上减少HELLO报文流量，不符合预期要求。

（2） 按需链路上不启动OSPF，那么也就不会有大量OSPF协议报文占用链路带宽的问题，以其它路由协议来替代OSPF，这样可以从根本上解决上述问题，但是分析会发现其它路由协议也存在定期HELLO报文发送以及大量路由更新报文问题（静态路由不考虑），除非不开启动态路由功能，否则这个方案也不切合实际。

2.3 问题拆解

鉴于当前已有技术无法解决上述问题，所以只能设计新技术方案来解决“如何减少按需链路中OSPF协议不必要交互报文，以释放所占宝贵链路带宽”这个问题。

针对“如何减少按需链路中OSPF协议不必要交互报文，以释放所占宝贵链路带宽”这个问题，首先会想到 可以减少哪些类型OSPF协议报文 这个问题。

  OSPF协议报文主要有两种，一种是维持邻居关系的HELLO报文，另一种是完成数据同步过程的其它类型报文，比如DD、LSR、LSU、ACK。为了及时维持邻居关系和保证LSA健壮性，会定期发送HELLO报文和LSA刷新报文（LSA即使没有任何变化，也需要定期1800s产生刷新并再次洪泛出去）。

如果减少数据库同步过程的协议报文，最终可能会影响数据库同步，而对于链路状态算法来说，数据库不同步是致命的打击，所以唯一可能减少的是：为特殊用途而设计的定期发送的HELLO报文和定期刷新的LSA。

如果抑制定期HELLO和定期刷新LSA发送，那么各自的特殊用途就会失效，设计时需要考虑如何解决对应功能失效的问题。

最终将“如何减少按需链路中OSPF协议不必要交互报文，以释放所占宝贵链路带宽”这个问题转化为如下两个子问题：

 （1）如何抑制HELLO报文发送；

（2）如何抑制定期刷新LSA传播；

三、解决思路

3.1 HELLO报文抑制

除了本端抑制HELLO报文发送外，还需要考虑抑制后对对方的影响，如果对方不支持该能力，本端单方面进行HELLO报文抑制，对方会因为一定时间内接收不到本端HELLO报文，会删除本端邻居关系，所以需要事先进行HELLO报文抑制功能能力协商。

3.1.1 能力协商

  如何进行HELLO报文抑制能力协商？

对于HELLO报文抑制能力协商，第一时间会想到使用HELLO报文携带对应抑制能力，并且HELLO报文是最早交互的协议报文，能够第一时间进行能力协商。

3.1.1.1 协商成功

如果两端都通告了HELLO抑制能力，那么双方协商成功。协商成功后立即开始抑制HELLO报文发送 还是 选择其它合适的时候开始抑制HELLO报文发送，即停止HELLO报文发送？

停止HELLO报文发送的时机选择，需要考虑下面两个方面：

1. 满足原始问题背景，即大量协议交互报文占用宝贵的链路带宽，一般指代邻居关系到达FULL之后还要定期发送的HELLO报文；
2. 基于本端停止HELLO报文发送动作会对对方产生影响考虑，本端停止HELLO报文发送的时机需要能够被对方捕捉，以方便对方能够对此做出相应反应，如关闭邻居超时检测定时器。对端能够捕捉到本端停止发送HELLO报文的时机可能有两种途径，一是本端主动通知，二是对端适时检测邻居相关信息，包括邻居状态机。第一个途径涉及到主动通知，并且通知还涉及到是否需要可靠确认问题，为使问题简化，可以考虑采用第二种途径，

最终问题转化为：当邻居关系到达什么状态时，本端开始停止HELLO报文发送？

选择邻居状态FULL，可以同时满足上述两个条件。如果邻居关系到达FULL时，停止HELLO报文发送，对方当且仅当通过交互报文就可以感知到本端邻居关系状态变化，邻居状态可以从上一个邻居状态Exchange/Loading切换到FULL，此时对方邻居状态应该同步切到Loading/FULL，所以当对方邻居状态切换到Loading/FULL时，关闭邻居超时检测定时器。

3.1.1.2 协商失败

  接收到对方不支持HELLO抑制能力后，后续不走上述3.1.1.1小节抑制处理流程，按正常流程收发HELLO报文。如果先前支持但是当前却宣告不支持，需要立即退出3.1.1.1小节抑制处理流程，按正常流程收发HELLO报文。

3.2 LSA定期刷新传播抑制

和HELLO报文抑制类似，LSA定期刷新传播抑制除了需要考虑抑制定期刷新LSA传播外，还需要考虑关闭定期LSA刷新后可能对其它设备产生的影响，以及如何来消除这个影响。

3.2.1 定期刷新抑制

接收到一条定期刷新没有变化的LSA（包括自己产生），是否需要将这个LSA洪泛给邻居？这个需要和邻居进行定期刷新LSA抑制能力协商。如果已经和邻居协商成功定期刷新LSA抑制能力，那么就不需要再将这条刷新LSA洪泛给邻居；如果没有和邻居协商成功LSA抑制DC能力，则继续走先前洪泛流程，即将这条刷新LSA洪泛给邻居。

怎么协商LSA抑制DC能力？前面已经讨论过HELLO抑制能力，这里又出现了LSA抑制能力，本质上都是抑制报文发送，可以将这两个报文抑制能力合二为一处理，即也通过HELLO报文携带的报文抑制能力协商确定是否需要LSA抑制DC能力。

3.2.1.1 协商成功

由于每个LSA都有对应的生存周期，即对应的age字段，当age>=3600s时，LSA信息失效，所有设备都会将它老化删除。如果不进行LSA定期刷新传播抑制能力协商，可能导致不支持定期刷新传播抑制能力设备错误地将相应LSA老化删除。

正常情况下，每隔1800s，LSA产生者会重新刷新LSA，以免LSA在其它设备被老化删除。为了实现LSA定期刷新传播抑制，产生者需要告诉其它设备这个LSA不能参与老化，如果接收者支持LSA定期刷新传播抑制功能，就能够识别出对应LSA不参与老化，否则无法识别出不参与老化信息。

所以此过程涉及到的问题包括：

1. 产生者和接收者如何协商“是否支持LSA不参与老化”能力？

包括产生者如何告诉别人这个LSA不能参与老化？发送者接收者如何向外宣传？等

（2）如何协商LSA定期刷新抑制能力？协商失败后，又该怎么处理？

3.2.1.1 老化机制更新

产生者如何告诉别人这个LSA不能参与老化？

由于LSA产生者不再定期刷新LSA，所以需要在LSA报文中携带一个标志以表明该LSA不能参与正常老化，否则LSA到达3600s后接收者会老化删除掉该LSA。为了实现上的简单，最好的办法是复用age字段来完成。恰好age字段还有好几个位未被使用，可以利用其中一位来传递LSA不能参与老化的消息。

3.2.1.2 LSA不老化能力协商

如何协商LSA 不老化能力？

因为此时协商不再局限于建立邻居关系的设备之间，而是区域内/AS内所有路由器的协商，所以携带LSA不老化能力字段应该存在于传播范围更广的OSPF协议报文中，目前只有LSA能够做到，可以选取LSA中的字段来携带对应能力，其中option字段正好可以用来完成该任务。

由于LSA传播有不同范围的区分，比如区域范围以及AS范围，那么就有可能出现由于受LSA通告范围限制，导致能力没有被传播范围外设备学习 到这个现象，可能导致传播范围外设备误以为该设备支持这种能力。

  这个问题又该如何解决？

我们可以很快就想到可以借助范围边界设备接力，继续将LSA不老化能力通告继续传递出去以通知传播范围外设备。而范围边界设备便是区域边界路由器ABR，是连接多个区域的桥梁。如果发现区域里面有不支持LSA不老化能力的设备并且其它区域设备无法得知这个信息，此时ABR需要向其它区域通告 有不支持LSA不老化能力的设备存在 这个信息。。

既然是借助ABR通告来传递能力，那么就可能存在多个ABR向同一个区域产生有设备不支持通告信息现象，此时会出现多个相同通告信息，也就是出现了冗余信息，本来DC上链路带宽就非常宝贵，所以此时需要优化一下，当且仅当只让一台ABR产生通告信息，而无需所有ABR都产生，这里会涉及一系列问题，比如最优通告设备的依据是什么？如果最优设备出现故障，其它设备如何第一时间替补产生通告？等等。

3.2.1.2.1 协商成功

如果设备支持LSA不老化能力，便在自己产生的LSA option中打上相应标记，具体是选择一个LSA打上标记还是所有LSA打上标记？为了健壮性，选择所有LSA都打上标记，并且成本可以接受。如果不存在没有打上支持不老化标记的LSA，说明该LSA产生者支持LSA不老化能力，协商成功。

3.2.1.2.2 协商失败

如果发现有不支持LSA 不老化能力的设备存在，即对应LSA中没有打上支持不老化标志或者有ABR通告有不支持能力设备存在， LSA始发者会删除先前产生的携带不参与老化标志的LSA，重新产生不携带不参与老化标志的LSA，如果发现没有不支持LSA DC老化能力的设备存在，则重新产生LSA，并且携带不老化标志。

四、实现方案

4.1 HELLO报文抑制

目前采用HELLO/DD报文里面的option中DC字段来承载HELLO报文抑制能力，当双方都携带DC标记时，表示双方协商成功，后续当邻居状态到达FULL时，停止HELLO报文发送，当邻居状态到达loading/FULL时，关闭邻居超时定时器。

如果有一方不再携带DC标记，则协商失败，如果此时邻居状态处于FULL时，开始发送HELLO报文，如果邻居状态到处于loading/FULL时，重新打开邻居超时定时器。

此外，HELLO报文抑制，也适用于LSA发送抑制，当HELLO报文抑制能力协商成功后，不会再将定期刷新无变化的LSA发送给邻居。

为什么还要使用DD报文中的option字段也来承载DC抑制能力的协商？

其实通过HELLO报文携带是完全足够的，可能是由于HELLO和DD报文复用了相同的option字段，所以也通过DD报文来承载传递DC标记能力。

4.2 定期刷新LSA抑制

为简化实现，目前将LSA age字段最高位定义为DoNotAge，表示该LSA不参与老化，定义LSA报文中option选项其中一位为DC标记，来表示该设备支持LSA不老化能力，反之如果LSA中option字段没有将DC标记置上，说明该设备不支持LSA不老化能力，即不支持DoNotAge LSA处理。

当发现某一区域有不支持LSA不老化能力的设备并且另一个区域不知晓的情况下，ABR需要向另一个区域通告一个特殊四型LSA，Indication LSA，其中LSA的link state id字段为通告者ABR自己，花费值为最大值16777215，option字段清除DC标记。

当有多个ABR设备需要同时向同一个区域通告indication LSA时，为了减少信息冗余，只有Router ID最大者才能继续保留，其它ABR则将产生的indication LSA老化删除掉，当最优通告者不再通告时，次优ABR会接替通告indication LSA。

当需要将一个内容无变化的LSA洪泛给邻居时，如果已经和邻居协商成功HELLO DC能力，则不将LSA洪泛给邻居，反之则需要将LSA洪泛给邻居。

五、技术评价

5.1 技术限制

DC链路技术是为了解决按需链路场景存在过多协议交互报文问题，为了解决这个问题，抑制发送HELLO和LSA刷新，也就去除了HELLO定期发送和LSA刷新这两种方式的优势。比如因为不再定期发送HELLO报文，设备无法能够及时监测邻居设备存在状态，可能存在邻居设备已经长期不存在，但是本端依然保留着邻居设备这个虚链邻居的情况。

如何解决上述这个问题？最容易想到的方法便是，可以定期发送探测报文检测对端设备是否存在，如果在一定时间内对端设备没有响应探测报文，便可认为对端设备已经不在，此时可以将虚链邻居DOWN掉。

5.2 发展趋势

按需链路场景促使了DC技术的产生，但是未来网络带宽会越来越大并且花费也越来越低，所以将来需要DC技术的可能性是越来越小。

这个技术也给予了我们考虑问题的一个指导方向，当存在受客观条件限制场景时，如何修正当前协议以适应该场景需求，OSPF DC技术是受网络带宽限制，除了网络带宽外，还可能存在物理内存、CPU限制，除了OSPF协议外，其它哪些协议也可能存在类似问题？又该如何解决？这些都是我们可以继续考虑的一系列问题。