ospf hello时间和dead_OSPF分享-邻居建立过程

这篇分享是针对OSPF邻居建立过程实现原理剖析
通过一个简单的实验拓扑的报文来详细分析OSPF工作机制，参照OSPF 的邻居状态机流程来进行剖析OSPF 邻居建立过程

Down----->Init ----> Two-way ----> Exstart --->Exchange----> Loading ----> Full

其中的Down状态，将不作为第一步分析，毕竟很容易理解，就是在Deadinternal间隔内都没有收到hello报文，则认定为邻接失效。

实验拓扑如下：

3台路由器，通过一个交换机（广播网络)互联，都在E0/0上运行OSPF，形成了OSPF的Full邻接关系。

1.邻居发现---Init 阶段（Hello报文：OSPF报文类型1）

hello报文的用途：

• 发现和协商邻居（邻居发现阶段）
• 在广播和NBMA(非广播多路访问）网络中协商DR和BDR （DR/BDR选举阶段）
• 邻居建立之后的充当keepalive的角色（OSPF后续的保活阶段）

hello报文在实现如上3个用途的时候，OSPF在处于邻接关系的3个不同阶段，在不同的阶段，hello把中的信息也是不一样的。这里我们先介绍OSPF邻居的发现阶段

1）我们先看看hello报文的网络层信息，可知这是一个OSPF报文（R3接口抓取报文）

我们的实验用例是用来一个多址网络，网络类型且是广播类型，OSPF的Hello报文发送的方式是组播方式。关于网络类型对于OSPF的工作机制的影响，还有组播MAC和IP，这个会在DR/BDR单独的文章中分享。

2）去掉IP包头，我们看看各路由器初始Hello报文的OSPF报文信息

每台路由器都会在开启ospf的接口组播方式发送hello报文，目标IP:224.0.0.5,且 DR/BDR为空，优先级默认为1，报文中还有不少字段。部分字段将在邻接的其他的过程中讲解，还有其余字段，将会在另外的OSPF分享中讲解。

当其他路由器监听224.0.0.5组播地收到这类始发hello报文信息匹配无误后，如“版本、区域ID、认证信息、接口掩码、Hello-interval、Dead-interval”(其实还有Option字段），这些信息必须匹配，才认为对方是自己的“邻居”，路由器利用收到的Hello报文信息，为接口创建一个“接口数据结构，将邻接关系设置为于“Init状态"。这个被创建的数据结构的信息将会被用于后续发送Hello报文。

这里我们用了 邻居和 邻接关系这2个词。
邻居他只是一个名词，而OSPF中，对于两台设备的互联关系，我们用邻接来表示。至于OSPF能否在两个邻居之前正常交互，要形成一个完成的邻接关系才行。 举个例子，你和老王住在对门，彼此见过面，彼此知道对方是住在对面房间的人或者户主，你们就已经成为邻居了。但是至于邻居关系知否处理好，在后续的日子中能否有效的交流和处事，要看你们的邻居关系的建立了。如果在后续的各个方面都比较认同，信息共享，那就有了一层 很好的邻接关系。下面我们看看OSPF如何在邻居之前建立邻接关系。

2.双向通信建立---Two-way阶段(Hello报文：OSPF报文类型1)

当路由器首次收到其他路由器的初始hello报文，并确认信息对上之后，路由器会再次通过组播方式发出的一个包含“Active neighbor"字段的Hello报文到该链路上，该字段的值就是，在该链路收到过的所有的Hello报文（前提是信息匹配）中的RID。

当其他路由器通过这个链路收到的这个路由器带有”Active neighbor”字段的Hello报文，发现其中"active nb"字段包含了自身 rid，类似于对方认为对方有效邻居的时候，此时彼此的就达成了初步双方认可，则将对方的邻接关系设置为“Two-way"双向通信状态。

之前出现了网络类型和DR的概念， 在进入下一阶段之前，我们需要先插播一条关于DR/BDR(包含网络类型）的知识广告，
因为这将直接影响OSPF邻接关系的建立逻辑。

DR/BDR知识点插播：

• DR: Designate router，指定路由器
• BDR：Backup Disignate router，备用指定路由器
• DROthers：其余非DR/BDR路由器
• DR/BDR选举规则：先比较接口优先级，越大越优先。优先级相同，比较RID，越大越优先

在一个多址网络（比如广播、NBMA）网络中，一个链路上会存在多个OSPF路由器，这也是为什么这里会用3个路由的实例来介绍OSPF邻居建立过程。当多个OSPF路由器出现的时候，会有DR/BDR机制，来控制邻接关系的有组织的建立，而不是一通乱邻接，形成一个Full-me sh的全员相互Full邻接状态，造成邻接关系众多复杂的现状。

这里我们先明确一点：在邻居邻接关系达到“Two-way”的状态后，会先在这个多址网络中确认DR/BDR/DROthers角色关系，才会进行后续的邻接关系协商过程。而且角色一旦确认后，DR/BDR，除了彼此还会和所有DRothers建立完整邻接关系，而DROthers彼此之间不会再 进一步的建立邻接关系，他们之间的邻接关系将维持在“Two-way”状态。

示例中根据上面的 DR/BDR选举规则，都是默认的优先级，显然R3将成为DR，R2成为BDR，R3成为DROthers，最终还是一个Full-mesh的Full邻接关系状态，因为用3个路由器的实例，只是为了引出在OSPF邻接关系过程中必不可以少的一个阶段。

关于DR/BDR的详解描述，将在下一篇文章。现在DR/BDR/DROthers的角色已经判定了，我们接着往下走。

3. 数据库描述的主从关系确认&LSA摘要传递---Exstart&Exchange阶段(DB description报文：OSPF报文类型2）

接下来将开始双方同步OSPF 数据库中的信息，但是同步的第一步需要协商一个Master/slave主从关系。

3.1 问题：协商主从的作用是什么？

答案：在两台OSPF邻接的路由器数据库信息同步的过程中，“主”路由器确保每次只有1个“DB description”报文是未处理的，也就是每次都是处理完一个，再发下一个。每次都是主路由器发出一个"DB description“报文，从路由器收到后，回应一个具有相同”DB sequence"的“DB description”确认报文，来确认主路由器之前发的“DBdescription“报文。如果主路由器在”RxmtInterval“间隔内，未收到从路由器的确认报文，主路由器会重新发送一个这个”DB description“报文。其中DB-sequence字段也同时用来判定“DB description”是否是重发，比如从路由器收到一个主路由器发来的“DB description”报文，其中seqence和之前已回复的确认报文 sequence相同，则表示这个"DB description“报文是重发的。

3.2 下面来分析下 "DB description“(以下简称DB-dsec)报文是如何在Exstart和Exchange状态进行交互的。

在拆解报文之前，我们先了解下DB-desc报文内容信息中（非Header）的几个特殊字节的意义和用途。

• • I(Init):set：表示这的数据库描述报文的初始报文
  • M(More):set：表示还有后续更多的“DB description"报文还需要发送
  • MS(Master):yes：表示始发路由器是 数据库交互过程中的 主，因为是初次发送，都会认为自己是主
  • DB sequence: 表示数据库描述序列号，在主从关系确认过程的首次发包时，是根据路由器当前按照顺序确认应该使用的序列号，所有邻接关系
    中的路由发送的首个“DB decription"报文中的 DB序列号没有关联，一般是不一致的 。

1) Exstart和Excahge过程DBD报文的交互过程原理

以RTA-RTB这种1对1角色名称为例：

1. RTA向所有处于“Two-way”状态的邻居，单播发送首个DB-description(下面简称DBD）报文（init:set,More:set,Master:set),且都认为自己是DB-desc交互过程中的“主”角色。同时各自发送的DB-desc初始报文的 "DD sequence“序列号是不一致的，因为主从关系还没有确认，都是认为自己是主。
2. RTB收到邻居发来的首个DBD报文后，将RTA邻接关系设置为“Exstart"状态。同时根据RID大小，判断主从
3. 如果判断RTB自己是主：则回应一个初始DBD报文（Init:set,More:set,Master:yes)
4. RTA收到了RTB的第一个DBD初始报文，将RTB的状态设置为 “Exstart”状态。同时根据RID大小，判定自己是从，则回应一个MS置位”No“， 且DB sequence和RTA（主）发送的初始DBD报文一致的DBD报文，同时！：还会携带自身的LSA描述信息（从设备会提前搞事！）。当RTB（主）收到了RTA（从）的DBD报文后，双方都确认主从关系。关键报文中携带了LSA描述信息，RTB（主）将RTA（从）的邻接关系设置为 “Exchange"状态。
5. RTB（主）开始发送携带LSA描述信息的DBD报文，RTA收到后，也将RTB（主）的邻接关系设置为“Exchagne"状态。
6. 由RTB（主）控制DBD报文的“一来一回”交互，因为主发送的DBD报文，必须要收到从发出的携带和主发送相同"DB sequence“的回复包，主才会开始发送下一个DBD报文。同时没发一次DBD报文，报文中的“DB sequence”字段数值就+1
7. 就按照上述的“一来一回”交互，当自己的LSA描述信息已经发送完全，会将发送的DBD报文中的“M”位置位为“Not set"。只有当双方的DBD报文的“M”位都置位为“Not set”，才会认为是同步完毕。因为是主设备来主导这个“一来一回”交互过程，所有永远都是从设备最先知道，通过是否完毕。
8. LSA描述信息同步的过程中，一旦一方收到了包含LSA描述信息的DBD报文，就可以开始发起“LSU”报文进行LSA的请求更新了，但邻居的邻接关系
   状态仍然还是“Exchange”，除非同步完毕，自动切换到“Loading"状态。

2）通过报文分析Exstat和Exchange报文交互过程

①R1发送首个DBD报文给R3

②R3收到首个邻居的DBD报文，将对方邻居关系设置为“Exstart”状态，同时回应一个DBD初始报文给R1。

③R1认怂，跟着老大（主）调整步调，并直接开始汇报（发送LSA描述信息）

④R3（主）收到 R1的DBD确认报文（序列号一致，身份为从），且包含了LSA描述信息，将R1的邻接关系设置为“Exhange”状态 并开始发送携带自身LSA描述信息的DBD报文

⑤R3也开始发送包含LSA描述信息的DBD报文

⑥R1收到R3带有LSA描述信息的报文后，将R3的邻接关系设置“Exchange”状态

⑦双方按照上述原理的逻辑继续交互，知道都确认LSA描述信息发送完毕，同步完毕。同时将会设置为下一个状态："Loading”

我们在多看一眼抓包的图：

发现R1/R2/R3在DB-desc同步的过程（Excahgne阶段）中，就已经私下开始请求和更新LSA了。消息还没同步完，你们就开始搞事了，效率可以啊。

这是因为：在DBD报文同步LSA描述的过程中，路由器就可以根据收到的LSA描述，同步像对方发起LS requet报文，进行LSA请求进行更新了，也就是Loading阶段，所以Exchange和Loading阶段是有交差的，也能提高OSPF收敛的速度。

4. LSA update---Loading（LSR & LSU 报文：OSPF报文类型3&4）

Loading的过程，就是对 LSA的请求、更新、确认的过程。当所有的LSA信息都完成并确认时，Loading的过程才算结束，形成Full的邻接关系（邻接完全体）。4.1 Loading过程的报文交互和原理

1. 路由器收到LSA描述信息后，如果发现这些信息不在自己的链路状态信息数据库中，或者比链路状态数据库信息中对应条目状态更新的时候，路由器将会把这些LSA摘要信息加入“链路状态请求列表”中，并通过LS request报文（简称LSR)，并发送给邻居，请求其对应的完整LSA拷贝。
2. 邻居收到后，将把针对这些请求报文中涉及的LSA的完整拷贝，通过LS update报文（简称LSU）回应请求的始发路由器，每个LS update报文可以携带多个LSA信息。
3. 始发请求路由器收到LS update报文，将报文的包含LSA信息，从对应的链路状态从之前的请求列表中删除，当邻居对应的“链路状态请求列表为空时，
   把改邻居的邻接状态设置为“Full”，形成了邻接完全体

4.2 R3(DR)和R1(DROthers)的loading阶段交互

Tips：LSR/LSU分别对应OSPF报文类型的3,4，在如下报文中可体现

①R1单播向R3发起了一个LSR请求报文，LSA-Type为Router-LSA(3)

2）R3单播方式回应对应完整的LSA信息给R1，其中包含2条LSA信息

3）R3也像R1单播发送了LSR请求报文

4）R1以单播方式呼应了DR(R)3的LSU请求

⑤当所有LSA都更新完毕后，将对方邻接关系更新为“Full”形成邻接完全体