GR设计原理剖析

最新推荐文章于 2023-03-23 13:59:08 发布

JJYY_2013

最新推荐文章于 2023-03-23 13:59:08 发布

阅读量1.5k

点赞数 1

分类专栏：协议技术文章标签：路由协议主备倒换 GR 网络协议

本文链接：https://blog.csdn.net/jjyy201301/article/details/81024701

版权

协议技术专栏收录该内容

7 篇文章 0 订阅

订阅专栏

一、摘要

关于GR技术的文档，目前只有各个协议GR原理细节的相关介绍，对协议GR设计全过程却鲜有描述。本文首先从协议GR问题提出出发，对问题进行分析直至提供总体解决方案；其次再根据每个具体协议的特点分析出一些差异性的细节处理。通过本文会对GR技术的来龙去脉有一个比较清晰的理解，从而对GR技术会有一个更加深入的认识。

二、正文

2.1 问题发现

网络设备主控制器发生故障后，备控制器接管主控制器继续运行，由于路由协议经历了重新建链的过程，导致路由撤销和路由重新通告，最终使得流量出现了一段时间内的中断，这对很多业务是无法容忍的，那么问题是在网络设备发生主备切换期间，如何保证流量不发生中断。

注1:这个问题还是比较容易发现的，没有特别高的要求，极有可能是运营商提的需求。有很多问题在当时可能不是问题，但是随着用户需求越来越高，后续会逐步演变为亟待解决的问题，网络技术的发展也是一直延续着这个规律。

2.2 问题分析

紧紧抓住上述遇到的问题：在网络设备发生主备切换期间，如何保证流量不发生中断。既然要解决网络设备发生主备切换期间流量发生中断的问题，那么首先就要分析一下网络设备发生主备切换期间流量为什么会发生中断。只有找到引起问题的原因，才能对症下药提出解决方法。

网络设备发生主备切换，备控制器接管主控制器运行后，协议进程重新运行，和邻居设备重新建链，邻居设备感知到本端重新建链，会将本端设备先前通告的数据删除，此时由于邻居设备没有对应的路由数据，流量到达邻居设备时查找不到路由表项丢弃进而出现流量中断的现象，当与邻居设备邻居关系重新建立完成，路由学习正常后流量恢复。至此我们知道了网络设备发生主备切换期间导致流量发生中断的原因是邻居设备感知到本端设备重启进而删除路由。

由上述分析知道，由于邻居设备感知到本端设备重启进而删除路由导致流量出现了中断，紧紧抓住导致问题的原因，分析怎样才能保证网络设备发生主备切换期间流量不发生中断。最直接的方法是破除导致问题的原因，即让导致问题的原因不成立，在这里也就是网络设备发生主备切换不让邻居设备知道或者邻居设备知道了但是不删除路由。

接下来原始问题转化为如下两个不相交的新问题：

（1）网络设备发生主备切换时怎样让邻居设备不知道？

（2）怎么让邻居设备知道了本设备发生了主备切换并且不删除路由？

2.2.1 问题一

网络设备发生主备切换时怎样让邻居设备不知道？

一般情况下邻居设备是通过接收到引起邻居UP状态发生切换的HELLO报文而感知本端设备重启。备控制器接管主控制器运行后，协议进程重新运行，接口开始发送 HELLO报文，最先发送出去的 IHELLO报文里面不会携带任何的邻居信息，邻居设备接收到这个HELO报文后会将邻居状态由UP调整为非UP，此时邻居设备也就感知了本端设备发生了变化。如果备控制器起来后发送出去的HELL○报文中携带了邻居设备的信息，或者更一般地说如果发送的报文信息和重启前报文信息一样，那么邻居设备也就不会感知到本端设备发生了变化。

为了完成上述的任务，主备切换期间设备必须保存切换前所有的邻居信息，或者至少保存已经处于UP状态的邻居信息，这样可以保证备控制器运行后发送出去的报文会携带先前的邻居状态，邻居设备就不会感知到本设备发生了变化，,进而也就不会删除路由。

注2：解决了邻居状态不回切这个问题，接下来需要解决的问题是怎么快速同步主备切换设备的数据库？即将主备切换设备的数据库恢复到切换前状态。因为是仅仅依靠主备切换设备独立完成任务，所以邻居设备根本就不知道本端设备发生了主备切换,也就不会知道本端设备数据库此时为空，那么也就不会主动将数据库信息发送过来。这种情况下我们需要主动发送信号给邻居设备，请求邻居设备将本地数据库所有数据发送过来(邻居设备可能会询问原因，也可能不询问原因，关于如何请求邻居设备将数据库数据发送过来，这里限于篇幅不做过多讨论,后续可能以单独的文档来进行讨论)。邻居设备将数据全部发送过来后，本端设备数据库便恢复到切换前状态,此后进入正常状态。

注3：目前的NSR技术也属于GR技术中一种，主备控制器时刻在同步数据，当主控制器切换为主控制器时，由于先前数据同步一致，备控制器可以无缝接管主控制器,对于外界而言根本感知不到任何变化。

2.2.2 问题二

怎么让邻居设备知道了本设备发生了主备切换并且不删除路由？

邻居设备知道了本端设备发生切换并且不删除路由，唯一可能就是邻居设备因为某种原因对我们网开面提供额外帮助,否则不可能出现上述结果。按照现代社会的正常礼节，遇到困难时需要主动请人帮忙，虽然也存在不少主动提供帮助的好心人。这里就涉及到一系列问题：怎么向别人求助(这一点包括何时向别人求助,怎么将求助的信息告知别人)、遇什么事件时需要别人帮助、请求别人提供什么帮助等等,接下来将围绕这几个问题进行讨论。

2.2.2.1 子问题1

什么时候向别人求助？

找人帮忙解决问题在生活中很常见,需要解决的问题主要有两种类型。一种是立即解决型任务，也就是我遇到一个难题，此时请求别人帮忙；一种是预约型任务，就是目前暂时没有遇到问题，可能在将来出现问题,提前和别人打好招呼,如果将来遇到问题时请求给予帮忙。具体使用哪一种主要取决于遇到困难时能不能及时将求助信号传递给别人，如果可以及时传递，那么推荐采用立即解决型方式；如果不能及时传递,采用预约型方式。

2.2.2.2子问题2

怎么将求助信息告知别人？

怎样将求助的信息传递给别人，可能的思路有两种。一种是将求助信息单独封装报文信息传递给别人，一种是将求助信息携带在目前已有的信息中。这两种方式各有优缺点，单独封装报文信息更显诚意，复用封装利用效率高，复用封装还有一个好处是可以可靠地传递求助信息和帮助方返回的确认信息,能不能帮我，直接告诉我得了，好让我知道。单独封装方式发送求助信息必然以单独的报文进行确认，也就存在丢失的风险,复用封装可以将这种风险降到最低程度。

2.2.2.3 子问题3

遇到什么事件时需要帮助？

必须事先约定好，将来遇到哪些具体事情，才需要你给予我帮助，比如将来没钱吃饭时请你借钱给我度过难关等，如果没有约定好具体事情，别人是无法提供帮助的，GR场景中对应约定事情是当你感知到我这边的邻居状态要发生切换时，麻烦你给我提供帮助。

你不要切换邻居状态，这样的话就简单明确多了，当别人感知到即将要切换状态时(也就是你遇到了问题)，先看一下你先前有没有打过招呼请求帮忙，如果打过招呼请求帮忙的话，就继续保持邻居状态不变(提供帮助)；如果没有打过招呼请求帮忙的话，就不保持当前邻居状态(不提供帮助)。

2.2.2.4 子问题4

请求别人提供什么帮助？

延续子问题3继续讨论，在你感知到我这边的邻居状态要发生切换时，你要给我提供帮助。此时你需要帮助我的事情有：此时不要切换邻居状态,继续保持邻居状态和先前一致。具体过程是：当感知到即将要切换状态时，先看一下你先前有没有打过招呼请求帮忙，如果打过招呼请求帮忙的话，就继续保持邻居状态不变(提供帮助)；如果没有打过招呼请求帮忙的话，就不保持当前邻居状态(不提供帮助)。

至此，邻居接收到本端发送的报文引起状态回切这问题已经解决，接下来还有数据库同步问题(可以采取主动请求方式，这一点完全由本端设备向邻居备主动请求将数据库中所有数据重新发送过来)，正所谓帮人帮到底，既然请求邻居设备提供帮助不切换邻居状态，还得麻烦邻居设备额外再帮忙同步数据库。这种方式会加快数据库的同步，提高数据库的同步效率。

2.2.2.5 子问题5

其它一些需要考虑的问题(主要是道德层面)

此时还要站在帮助者角度上考虑问题，比如求助方应该设个期限，需要帮助方提供帮助的最长时长，不然帮助方可能会拒绝提供帮助，也可能碍于情面表面勉强答应提供帮助但是心里不情愿导致中途退出帮助。求助方向帮助方承诺只要超过了最长帮助时间，不管问题有没有搞定，帮助方可以立即停止帮助，还比如帮助者发现你使用了“狼来了”戏弄的把戏(你说目前有困难，但实际上却没有，你不是在玩我嘛)帮助者会立刻拂袖而去不再提供帮助。

2.3 问题解决

对问题进行分析后，接下来主要是针对各个协议提供具体的解决方案，包括RIP、ISIS、OSPF、BGP路由协议，其它协议比如LDP等也可以套用上述分析的思路进行考虑。我们主要采用的是“怎么让邻居设备而道了本设备发生了主备切换但是不删除路由”这一种场景。

经过上述分析得知，要完成邻居设备知道了本设备发生了主备切换并且不删除路由这一任务，需要做的事情主要有两个：一个是当邻居设备感知本端设备发生变化时邻居状态不切换，也就是状态保持；另一个是状态保持的前提下帮助本端设备完成数据同步。数据同步完成后，邻居设备便可停止帮助,本端设备进入正常状态,这期间发生的事情除了邻居设备知道外，没有其它设备知晓,只有我知、邻居知,天不知、地也不知。

2.3.1 状态保持

2.3.1.1 RIP

RIP没有邻居发现机制，即不是首先通过 HELLO报文建立邻居关系再进行路由同步，那么也就不存在状态保持这一说法，所以RIP协议天然支持GR技术，主备控制板切换以后发岀去的路由更新报文不会导致对居设备的路由接收区别处理。

2.3.1.2 ISIS

ISIS怎么向邻居设备传递GR请求信号？由于直接影晌状态切换的报文是HELLO报文，如问题二中子问题2中讨论所述，是单独封装GR请求信号还是将GR请求信号复用封装在已有信息中，这里已有信息是 HELLO报文。

这里选择封装在HELL○报文中更妥切。如果单独封装的话，一是要重新设计GR报文，影响传递效率；其次单独传递会有不可靠传输情况，单独封装GR请求的报文和直接引起邻居状态发生切换的HELLO是相对独立的，接收到引起邻居状态发生切换的 HELLO之前可能没有接收到单独封装GR请求的报文，最终导致邻居设备不会提供帮助；反之如果将GR请求信号复用封装在HELLO报文中，可以保证接收到引起邻居状态发生切换的HEllO时肯定也会收到了GR请求信号，从而会提供更可靠的帮助。ISIS先天完美的TLV报文格式使得该思路成为可能，包含GR请求信号所有相关信息的TLV中承载在HELO报文中即可。

关于问题二中的子问题1“什么时候向别人求助立即解决型方式还是预约型方式？由于ISIS完全依靠自己收发报文，有条件保证出现问题时可以及时将GR请求信号传递给邻居设备，所以采用立即解决型方式，即主备切换时才发送GR请求信号。

2.3.1.3 OSPF

上述已经分析GR请求信号到底应该是单独封装GR请求信号还是将GR请求信号复用封装在已有报文中，OSPF由于先天报文设计的缺陷，HELLO报文无法承载GR请求信号，所以只能将GR请求信号单独封装，由于请求信号当且仅当发送给邻居设备即可，所以采用Link洪泛范围9型LSA中来承载包含GR请求信号的TLV。

关于问题二中的子问题1“什么时候向别人求助”，OSPF和ISIS类似,由于自身可以提供报文收发，有条件保证出现问题时可以及时将GR请求信号传递给邻居设备，所以采用立即解决型方式，即主备切换时才发送GR请求信号。

2.3.1.4 BGP

相对于ISIS/OSPF等IGP协议，BGP显得更特殊，除了BGP自身状态改变外，还需要考虑底层提供报文可靠传输的TCP，TCP状态的变化会对BGP产生影晌，所以BGP这里关于前述问题二中的子问题3“遇到什么事件时需要帮助”，这里还包括感知TCP断链。

关于问题二中的子问题1“什么时候向别人求助”是立即解决型方式还是预约型方式？由于BGP建链是以TCP可靠传输为基础，那么出现问题时也就无法保证可以及时可靠地将GR请求信号传递给邻居设备(TCP断链后,无法将携带GR信号的BGP报文传递给邻居设备，除非将GR请求信号封裝在TCP报文中,这样设计会非常麻烦并且代价不菲)，所以只能采用预约型方式，即提前打招呼发送GR请求信号给邻居设备，将来邻居设备若感知到TCP断链，需要保持我的状态，比如保持我先前通告的路由，此外由于BGP也是基于TLV报文格式，那么GR请求信号可以复用封装在HELLO报文中。

2.3.2 数据同步

接下来的任务是进行数据同步，IGP主要是数据库同步，BGP是路由同步，LDP是标签同步(这里我们统一用数据来表示)，将主备切换设备的数据状态恢到切换前状态。

2.3.2.1 RIP

主备切换后，本端设备RIP协议重新运行，接口上会发送特殊请求报文，请求邻居将路由表中的路由全部发送过来，这样就可以保证邻居设备第一时间将路由数据全部发送过来，从而协助本端设备完成路由数据同步。

但是这里有一点需要注意一下，主备切换设备需要知道邻居设备何时已经将路由数据全部发送过来，这样可以使得本端设备及时知道对方帮助是否结束从而快速地恢复成正常状态。目前RIP协议还没有这样的支持手段，需要对协议进行扩展，比如可以在路由更新报文设置标志位来标识路由已经发送完毕。

2.3.2.2 ISIS

路由同步的协助者只能是接收到本端发送的GR请求信号并且答应提供帮助的邻居设备。P2P链路上最多只有一个邻居设备，所以提供者当且仅当可能是这唯设备；广播网上可能存在多台设备，只要满足条件的其中一台设备提供帮助即可。

是本端设备自己选择一个邻居设备来协助同步还是所有邻居设备自发地诜举出一个设备来主动提供同步？如果是自己选择一个邻居设备来协助同步，会涉及一系列过程，包括自己选择一个同步的邻居设备，然后还要向该邻居设备发送同步信息的信号，为什么这里还要发送同步信息的信号？如果不发送的话，邻居设备会主动发送路由协助本端设备同步，那么N个满足条件的邻居设备都会主动发送，从而出现了同步数据冗余的缺点。如果让满足条件的其中一个邻居设备主动发送路由，则会变得简单的多，具体哪一个邻居设备主动发送路由应该由所有的邻居设备根据规则来协商，比如依据优先级等属性进行选择最优的邻居设备来提供帮助。

确定了满足条件的邻居设备后，接下来的问题是怎么发送同步数据？是直接将数据发送过来还是先将摘要信息发送过来？理想的情况是如果主备切换设备数据库是空的，直接发送完整LSP过来；如果不是的话，则发送摘要信息CSNP过来，并且CSNP也隐含了结束的标志。目前采用的是发送CSNP摘要报文过来以便让主备切换设备根据摘要主动请求所缺少的LSP。

2.3.2.3 OSPF

由于OSPF采用的是单独封装方式来传递GR请求信号，也就存在无法确认邻居设备是否同意提供帮助这问题。既然不能可靠确认，只能走一步算一步，期间再推测邻居设备是否正在帮助我,如果判断出不再帮助我的话,立刻结束GR。

同ISIS一样，OSPF也面临到底选择哪个邻居邻居设备进行数据库同步这一问题。OSPF区别于ISIS独特之处是建链过程中必然经历完整的数据库同步(终极完整状态为FULL),这样也就隐含了结束标志，最终的问题也就转变化和哪个邻居设备进行建立邻接FULL关系，所以GR数据库同步方式与普通情况下数据库同步一致，不需要像lSIS那样需要额外选举邻居设备来发送CSNP报文。