高级工程师：OSPF怎么同步链路状态数据库

前面我们提到过，OSPF通过Hello报文建立起邻居关系后，除非双方都是DRother，否则就需要交换链路状态信息并保存在LSDB中，使双方的LSDB完全相同，如同拥有相同的一张“地图”。

怎么交换链路状态信息呢？

直接把自己所有的链路状态信息二话不说全部都给邻居？这肯定不行，太占带宽资源了，而且有些信息邻居可能已经有了。只有RIP这货才会这么干。

OSPF会把自己所有的链路状态信息弄个“目录”给邻居，邻居拿到“目录”后，看看需要哪些信息，告诉我，我再给他就好了。

这个“目录”，就是OSPF的第二个协议报文，叫DD报文（Database Description，数据库描述，也有叫DBD的）。

可是，OSPF是由不太靠谱的IP来传输的，如果我发的DD丢了，我重发就好，可问题是，我怎么知道丢了呢？

知道为什么Hello要周期地维护邻居关系了吧，知道为什么邻居失效时间是4倍Hello了吧，Hello报文丢一次、二次、三次都没关系，丢四次才认为邻居失效（三次或者五次不行吗？当然行，只是OSPF规定四次。你可以自己设计一个路由协议，想规定几次都行）。

难道DD也要靠计时来决定是不是丢了？我发个DD，若干时间内没有收到邻居的回复就重发？虽然也是个办法，但这会导致OSPF收敛变慢。传说中OSPF的收敛速度是很快的，这个办法肯定不行。那OSPF怎么处理呢？

OSPF规定，在发DD之前，双方先确定一下谁是Master，各发送一个空的DD，里面没有任何数据库摘要信息，只用来竞选谁当Master。这时候的邻居状态为Exstart。

这是一个空的DD，包含了Header，接口MTU，Options和Hello里的一样。解释一下后面的几个标志位：

R位：带外LSDB重新同步，完成无邻接关系变化的LSDB重新同步。在OSPF GR技术中使用。先不管它，看后面三个；

I位：当发送连续多个DD报文时，如果这是第一个DD报文，则置1，否则置；

M位：当发送连续多个DD报文时，如果这是最后一个DD报文，则置，否则置1，表示后面还有其他的DD报文；

MS位：置1表示发送方为Master。

还有一个DD Sequence，DD报文序列号，这个一会说。

双方互相发了空的DD，这几个标志位都相同，意思是双方都是发的第1个DD报文，还没发完，都想当Master。

比较Header中的RID，大的一方为Master，Slave方接下来开始发送真正的DD报文。这时候的邻居状态为Exchange：

这是Slave方发送的包含数据库摘要的真正的DD报文，MS位为，不再是Master，注意看序列号，为5266，这正是Master刚才发的空的DD的序列号。

这样一来，Master收到这个DD，可以确定刚才发的DD报文Slave方收到了。这其实就是一种“隐式”确认。

Slave都会使用Master发送的DD报文中的序列号。

一般情况下，双方链路状态数据库在同步之前，内容、大小各不相同。如果Master方信息较多，发了多个DD，Slave方即使已经用DD把数据库摘要发送完，也会发空的DD来对Master进行确认，反过来也一样。

如果有一方把数据库摘要发送完成，即M=0，另一方不论DD有没有发完，都会立即向对方发送LSR报文，开始向对方索取自己没有的LSA（你已经把目录都给我了，我看看哪些我没有，就向你索要）。

LSR（Link State Request，链路状态请求），是OSPF的第三种协议报文，目的是向对方索要自己没有的LSA（Link State Advertisement，链路状态通告，里面包含链路状态信息）。只要有一方发完DD，另一方的邻居状态就会迁移到Loading状态，开始向对方发LSR。

这是一个LSR报文，里面请求了11条链路状态信息。每一条请求只包含摘要，比如第1条请求里面只有LSA类型、链路状态标识、始发路由器三个内容。

对方收到这个LSR报文后，会把里面所请求的LSA的详细信息放在LSU报文中回复给对方。

如果路由器发出LSR后，RxmtInterval时间（默认5秒）没有收到对方回复的LSU，则重发LSR。

LSU（Link State Update，链路状态更新），是OSPF的第四个协议报文，目的是回复对方请求的链路状态详细信息，使双方的链路状态数据库达到同步（完全相同）。

这是收到LSR后回复的LSU报文，LSR请求了11条，LSU把这11条链路状态的详细信息回复给对方。比如LSR请求的第1条链路状态详细信息，LSU回复的是这样：

其中的内容我们以后再讨论。

收到对方发送的LSU后，本端需要发送一个LSAck报文，告诉对方LSU已收到。没办法，IP不靠谱，OSPF只能自己来保证可靠性。前面的DD报文用序列号确认，是“隐式”确认，而LSAck则是独立的一个确认报文，对收到的LSU进行确认，是“显式”确认。

LSAck（Link State Acknowledgment，链路状态确认），是OSPF的第五个，也是最后一个协议报文，目的是对收到的LSU进行确认，告诉对方LSU已收到。LSAck包含所确认的LSA头部信息，没有具体的链路状态详细信息。

路由器发送LSU后，如果超过RxmtInterval时间没有收到对方的LSAck确认，则重发。

那么，如果路由器发送的LSAck确认报文丢失了怎么办？其实很简单，那就意味着对方没有收到LSAck，RxmtInterval时间后对方会重发LSU，本端收到后再发LSAck即可。

RxmtInterval时间不仅LSR报文、LSU报文要靠它重发，DD报文也会用它重发。比如，Master端发了序列号为5266的DD报文，如果超过RxmtInterval时间没有收到Slave端发的序列号也为5266的DD报文，则重发序列号为5266的DD报文。反过来也类似，如果Slave发送了序列号为5266的DD报文，超过RxmtInterval时间没有收到Master端的序列号为5267的DD报文，则重发5266的DD。如果有一端的DD报文不为空，另一端依然会用空的DD报文回复，直到双方DD报文中的M位都为，表示双方DD都发完了，后面不会再发DD。

经过在Loading状态互发LSR、LSU、LSAck，双方链路状态数据库LSDB中的链路状态信息最终会完全相同，称为同步，双方邻居关系迁移到最终的Full状态。