求教各位大佬一个OSPF的问题？

OSPF在full状态，当邻居路由器重启OSPF进程后，为什么己端OSPF立马就变成down状态，为什么不用等老化时间，求教各位大佬？

当标准的OSPF进程A重启(Restart)时，会立马清空自己的neighbor。进程一旦开始调度，会立马发送自己的Hello消息。由于没有neighbor信息，故Hello消息没有携带neighbor ID。

邻居B接收到Hello消息，发现自己的id不在hello消息里，意识到可能对方在重启或者单通导致对方的dead timer超时。于是果断将自己的状态机切换到init状态，触发自己发送hello消息。由于邻居A的hello消息看到邻居A的neighbor ID信息，故B发送的hello消息里，不仅要携带自己的ID，还要携带邻居A的ID。这样A收到hello消息会切换到2-way状态，双方继续消息交互，直到双方完成LSA信息同步到Full。

很显然，重启发送hello消息的时间要远远领先于邻居B的dead timer超时时间，dead timer 通常为 4 * hello time = 4 *10 =40秒。哪个事件(event)先发生，就由哪个事件触发邻居B的call chain。

假如A不是重启OSPF，而是shutdown OSPF进程长达40秒。邻居B此时的dead timer就会超时，会清空自己的neighbor database，并将state machine切换到down状态。此时再启动A的OSPF进程，双方就会开始一次全新的down---full的状态同步过程。

TCP的超时重传，3 Duplicated ACK都会触发TCP重传，哪个事件先发生，就由谁来触发重做动作。3 Duplicated ACK在时间维度上，总是领先于retransmit timer，故总是由3 Duplicated ACK这个事件来触发retransmit。故，3 Duplicated ACK美其名曰Fast Re-transmit。

上文所谓的标准OSPF进程，是指不支持Graceful Restart的OSPF进程。

双方都支持Graceful Restart的OSPF进程，如果A需要Restart，会立马发一个hello消息携带restart bit =1，告诉邻居B，自己要放空一下，请保持邻居关系，状态机保持full状态，FIB转发表保持继续forward packet。

当A重启完毕，双方完成LSA database的同步，再用重新计算的route tale更新FIB表。整个过程packet一直可以forward，理想状态下，不会发生任何packet丢包。这个机制就是Non-Stop Graceful Restart。

如果B的dead timer 超时依然没有A来和自己协商，才将邻居关系清空，并尝试建立新的邻居关系。