Graceful Restart-完美重启-犀利重启-给力重启

开题报告：

路由协议从开发至今一直被广泛的部署和应用。作为网络工程师来说，除了要理解基础的路由协议操作之外，更应该了解路由协议的一些附加特性。RFC也在不断的对原始的路由协议进行补充。

其实现在提出的Fast Hello，BFD以及我们要将的Graceful Restart都是路由协议的一种补充，有了这些附加机制，我们的路由协议能够工作的更加出色。

下面我们就来讲讲Graceful-Restart，这个中文名不是很好翻译，姑且我们就叫完美重启吧。

一，Graceful-Restart的基本概念：

看图，没有GR的情况的切换过程：

下面是有GR能力的网络切换过程：


那么什么是Graceful-Restart呢？

Graceful Restart简称GR，字面意义是完美重起，主要功能是在路由协议重起的时候保证数据转发的正常，以保证关键业务不中断，所以有时候GR也被称为NSF（Non-stop Forwarding）

GR按照能力可以分为：

GR Capable路由器
GR Aware路由器
GR Unaware路由器
如果要支持GR，路由器必须是GR Aware或者GR Capable
详情请参考
NSF-aware routers tolerate neighboring router failures. After the neighbor router restarts, an NSF-aware router supplies information about its state and route adjacencies on request.

NSF-capable routers support NSF. When they detect a stack master change, they rebuild routing information from NSF-aware or NSF-capable neighbors and do not wait for a restart.


按照任务又可以分为：
GR Restarter
GR Helper

这里注意，GR特性仅适用于双主控、控制与转发分离（线卡具有独立处理器）的硬件平台，GR用于软件或硬件错误导致Active RP重起或Active RP失效；或者管理员的主备切换命令。

事实上GR实现的思路无非就是以下几个方面：
路由协议重启时不删除转发表项，一定时间内将邻居关系和路由信息保持稳定，重启后尽快将各种路由信息恢复。这样的话，基本可以实现不间断转发。

GR的流程可以用下图来描述：


Graceful-Restart针对不同的协议，操作方式均不一样。OSPF和BGP甚至EIGRP实施GR的方式都不尽相同。所以我们需要分开讨论。
OSPF实现GR的标准有两种：
IETF Grace-LSA方案，IETF的RFC3623通过增加Graceful LSA的方式实现GR功能。
IETF三草案，draft-nguyen-ospf-lls-05.txt，draft-nguyen-ospf-oob-resync-05.txt，draft-nguyen-ospf-restart-05.txt

首先先看看Grace-LSA方案：
Grace-LSA的功能用于GR能力协商及GR过程消息交互，其格式采用Opaque-LSA的格式，其中Opaque Type为3，Opaque ID为0。




TLV的类型有三种，如下表：

名称	Type	Length	作用
Grace Period TLV	1	4	表示周边邻居设备进入GR Helper角色的最长保持时间
Graceful Restart Reason TLV	2	1	用于携带重启原因
IP Interface Address TLV	3	4	用于携带发送Grace-LSA的接口的IP地址

GR Restarter进入GR状态前需要保证转发表的准确，并在重启过程中被保护；解决保存各接口所使用的LSA序列号的问题并且产生Grace-LSA，age=0，并给出GR周期。
GR Restarter在GR过程中不会产生LSA；当收到源于自己的LSA时，不做处理，并认为有效；通过从邻居获取LSA来得到重起前的网络拓扑并且不能下发路由项到转发表。同时它还要侦听接口上的HELLO报文知道自己是否为DR，如果是DR，还会保持，如果自己为DR，那么会保持在自己的hello中宣告自己为DR。
GR Restarter退出GR后重新在所有关联区域泛洪1类LSA，如果是DR，还要重新泛洪2类LSA；重新计算路由并下发到转发表，产生必要的3、5、7类LSA；删除残存在转发表中不再有效的路由；向区域内刷新那些源于自己的LSA并刷新掉Grace-LSA。

作为IETF三草案来说它是通过改造hello报文结构以及LSDB同步过程实现GR功能，对应有三篇草案：
draft-ietf-ospf-lls-00 (Cisco)
draft-ietf-ospf-oob-resync-01 (Cisco)
draft-ietf-ospf-restart-01 (Cisco)

draft-ietf-ospf-lls-00这草案定义了LLS，LLS指Link-local Signaling，该草案针对OSPF协议报文提出了一种新的扩展方案，使得原本比较僵化的OSPF协议报文格式具有更好的扩展性，经过扩展后的OSPF协议报文可以灵活携带各种应用数据。
LLS Data被加在了OSPF协议报文的末尾，而且它只跟在Hello和DD报文的最后。OSPF协议使用报文中option字段中的L bit（0x10）来标识hello和DD报文后面是否携带了LLS Data，LLS Data采用了具有良好扩展性的TLV结构。

这里，当LLS TLV中Type为1时表示是Extended Options (EO) TLV，在EO TLV中，Value处填写的是4字节的Extended Options，它作为传统OSPF协议报文中Option字段的扩展，用于携带各种能力属性值。

draft-ietf-ospf-oob-resync-01这个草案提出了基于DD报文的一种信令，OOB指Out-of-band LSDB resynchronization.传统OSPF只有在邻居初建的时候才进行LSDB同步，而某些特殊场合可能需要在邻居关系和网络拓扑保持稳定的时候对OSPF LSDB进行重新同步，因此引进了OOB流程。
协议使用LLS Data中的EO TLV来进行OOB能力协商。如果本机具备OOB能力，则在发送Hello和DD报文时将EO TLV的Extended Options字段置上LR(LSDB Resynchronization)位，具体值为0x00000001。
协议规定通过DD报文Options字段中的R bit来向周边邻居设备通知开始进行OOB流程。如果接收到的DD报文option字段中R bit位被置1，并且I、M、MS位均被置1，此时如果该邻居状态为FULL，则将该邻居的状态降为ExStart，通过OOB流程开始LSDB同步，在此过程中不管邻居状态怎么变迁（ExStart、Exchange或者Loading），都将被当作FULL状态进行处理。

在前两个draft的基础上，通过draft-ietf-ospf-restart-01规定了OSPF GR的基本流程，协议规定通过HELLO报文LLS Data中的RS (restart signal)位来向周边邻居通知进入GR流程，其中RS位在Extended Options (EO) TLV的Extended Options字段所占的具体位置为0x00000002，并且借助OOB流程完成GR期间的LSDB同步。

路过占楼而已

写的真的很不错

我是来刷分的，嘿嘿

这是什么东东啊

相当不错，感谢无私分享精神！