写在前面
最近在做ospf相关的项目，于是对ospf进行学习，从思科等文档上学习到很多，不过对于详细的邻居建立过程，没有找到带有报文的实例，所以笔者通过抓包查看，做一个归纳总结，如果其中有遗漏的地方，还希望指正~ ~ ~
拓扑如下，通告网段192.168.1.0/24 area 0
one - 192.168.1.1/24 two - 192.168.1.2/24
three - 192.168.1.3/24
先来看一下总体的报文情况，接下来将一一进行分析
1. one发送第一个hello包
发送hello报文，其中不包含Active neighbor字段
2. one收到邻居two发来的hello报文
one收到报文后，会记录下two的routerid。并且将two视为Init状态
3. one发送第二个hello报文，并且将two的routerid存储在hello报文中
4. 当two收到这样的报文后，就会认为与one建立了双边关系，在two端查看one邻居状态会变为two-way。同时two也会发送带有one的routerid（0.0.0.100）报文，one收到后将two的状态变为two-way，至此，第一个稳态建立。
5. 接下来会进入ex-start状态，开始master，slave的协商，值得注意的是协商M/S 是为了决定后续LSA中谁来决定DD的序列号，而routerid大的那个ospf路由器的接口会变成master，由它来决定DD seq，对端成为slave。这里的master不是DR。下面将详细分析DD报文的交互。
6. one 设备发送第一个DD报文，其中不包含lsa信息
7. one设备收到two发来的第一个DBD包，其中不包含lsa信息。发现two的routerid更大，可以成为master，所以继续发送DBD包
8. one继续发送DBD包，其中包含lsa的信息。且MS位变为0，M位变为0.表示没有更多的DBD包。
9. 当two收到这条报文，Init位0，则Ex-start状态过去，改为ex-change，并且存储one发来的LSA头部，自己也要发送自己的DB摘要给邻居。并且由于two是master，他可以决定DD seq
10. 此时，根据以上两个包，one two都知道了这是对端的最后一个DBD包（此处值得注意，可能会好奇为什么是有5个DD包，根据查阅rfc以及相关博客）
在Exchange状态下，何时发送DD包，取决于路由器的主从状态。
主机：在下列两个条件之一时，发送DD包：
a）从机通过回显DD序号，确认了前一个DD包；
b）经过了RxmtInterval秒也没有收到确认，这时重传前一个DD包。
从机：只能在接收到由主机发送的DD包时，才能发送DD包作为回应。如果从主机收到了一个新的DD包，则发送新包；否则，重新发送前一个DD包。在Loading和Full状态下，当收到主机重复的DD包时，从机必须重新发送最后一个DD包来作出回应。为此，从机必须等待RouterDeadInterval秒，才能释放最后一个DD包。在此之后收到的DD包，会生成SeqNumberMismatch邻居事件。
R1收到R2发过来的BDB，要发送DBD的确认给DBD的主路由器也就R２,同时R1没有DBD的包了，所以M＝0,表示为最后一个DBD包。（但如果主再发DBD包过来，从还是要发DBD进行确认， 序列号为主的序列号 ，这叫隐式确认）
如果有自己感兴趣的lsa，就会期望更详细的lsa信息，将对端置为loading状态。并且开始发送LSR报文请求特定的lSA的详细信息。
11. 当对端收到LSR时，会以LSU进行回应，其中包含了对方请求的LSA详细信息。
12. 接收方收到对端发送的LSU后，需要回传一个LSA确认包，表示自己已经接收到了。
13. 这里需要注意的是，lsu有三种情况，分别是dst ip为224.0.0.5 224.0.0.6 以及目的接口的ip
由于所有的都会主机都可以接收224.0.0.5的包，只有DR和BDR才会接收224.0.0.6的包。所以我们看到1.1.1.1发送出的包都是目的地址为224.0.0.6和单播报文。关于单播lsu如何出现，还没有了解的很清楚，这里先留一个空，下次再更。
14. 当发送LSR的发送端主机收到了所有待请求的lsa后，便会将邻居置为Full状态。并且给对端发送LSA ack。至此，邻居关系建立，达到全毗邻状态。
