OSPF建立邻接关系的过程

首先要了解这个过程中涉及到的几种分组：

（1）Hello分组：这是一台路由器告诉其他路由器自己存在的一种方式。Hello分组会定期发送，以告诉其他路由器自己还活着。

（2）DBD分组：数据库描述，这是链路状态的一个概况，可以把它看做是链路状态的一个目录，其中包含它知道的所有路由器的ID，以及各条链路的序列号（用来判断链路的新旧程度）。

（3）LSU分组：链路状态更新，这是真正的链路状态信息，也就是通往某个目标的详细路径信息。

（4）LSR分组：用来请求一个链路状态信息。

（5）LSAck分组：对其他分组进行确认。

还有一个概念就是LSDB（链路状态数据库），它保存所有链路状态信息。

下面我们结合在R1上执行debug ip ospf events的输出（该输出来自互联网），来详细说明建立的步骤：

1. R1的OSPF接口开始向外发送Hello分组，发送的时候使用组播，组播地址是224.0.0.5。这个Hello分组包含一些重要的信息：路由器ID、DR/BDR、区域号、优先级等，以及R1知道的所有邻居的列表（这时侯为空）。

*Apr  8 00:47:54.059: OSPF: Interface FastEthernet0/0 going Up
*Apr  8 00:47:54.059: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 10.1.1.1
 

2. R2收到Hello分组后，会将R1加入到自己的邻居表中，邻居表中除了从Hello分组中得到的信息之外，还会从承载Hello分组的IP数据包中得到源IP地址（R1某个接口的IP地址），以及本路由器收到这个分组的接口。R2会查看R1发送过来的这个Hello分组当中的邻居列表字段，发现当中并没有自己的路由器ID，我们称这个状态为init状态，这时候，双方的通信关系还没有建立起来。

 

3. R2会发送一个Hello分组给R1作为响应（使用单播），其中的邻居列表中包含R1的ID，R1会将R2加到自己的邻居表中，这个时侯，双方的邻居表都已经有对方的存在了。这时候称为2-way状态。

*Apr  8 00:47:58.919: OSPF: Rcv hello from 10.1.1.2 area 0 from FastEthernet0/0 10.1.1.2
*Apr  8 00:47:58.923: OSPF: 2 Way Communication to 10.1.1.2 on FastEthernet0/0, state 2WAY
 

4. R1收到R2的这个分组后，会立即发回一个Hello分组来进行响应，这时候使用的也是单播，只发给R2。这时候，是真正交换链路之前的状态，称为exstart状态。

*Apr  8 00:47:58.923: OSPF: Send immediate hello to nbr 10.1.1.2, src address 10.1.1.2, on FastEthernet0/0
*Apr  8 00:47:58.923: OSPF: Send hello to 10.1.1.2 area 0 on FastEthernet0/0 from 10.1.1.1
*Apr  8 00:47:58.927: OSPF: End of hello processing
 

5. 接下来我们会看到R1会继续向外组播Hello两次，这只是Hello的周期性行为，以确定对方的状态。我们看到两次Hello的时间间隔刚好是10秒。

*Apr  8 00:48:04.063: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 10.1.1.1
*Apr  8 00:48:08.927: OSPF: Rcv hello from 10.1.1.2 area 0 from FastEthernet0/0 10.1.1.2
*Apr  8 00:48:08.927: OSPF: End of hello processing
*Apr  8 00:48:14.063: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 10.1.1.1
*Apr  8 00:48:18.935: OSPF: Rcv hello from 10.1.1.2 area 0 from FastEthernet0/0 10.1.1.2
*Apr  8 00:48:18.939: OSPF: End of hello processing

 

6. 接下来R2开始向R1发送DBD，这里我们看到几个重要标记：seq（DBD的序列号）、flag（一个三bit的标志位，第1位是initial位，如果为1表示第一个DBD，第2位为more位，表示后面还有DBD要发送，第3位是master位，表示主、从）。这里提到的主、从（master、slave）大概可以想象为人跟影子的关系，人是主，影子是从，影子总会跟着人走。后面的state表示当前双方的状态，这里依然是2WAY。我们看到这里的收到的两条DBD，它们的seq相同。flag为0x7，二进制为111，说明这是第一个DBD，而且第2条收到的DBD还不是最后一条，因为第2位为1，最后一位也为1，说明这是MASTER，在初始的时候，每个路由器都会认为自己是MASTER。

*Apr  8 00:48:18.939: OSPF: Rcv DBD from 10.1.1.2 on FastEthernet0/0 seq 0x4DB opt 0x52 flag 0x7 len 32  mtu 1500 state 2WAY
*Apr  8 00:48:18.943: OSPF: Nbr state is 2WAY
*Apr  8 00:48:23.955: OSPF: Rcv DBD from 10.1.1.2 on FastEthernet0/0 seq 0x4DB opt 0x52 flag 0x7 len 32  mtu 1500 state 2WAY
*Apr  8 00:48:23.959: OSPF: Nbr state is 2WAY
 

7. Hello间隔又到期了，R1又会组播Hello分组。另外，从上面的DBD中的flag我们得知该DBD还没有完整，所以我们看到下面还收到了两条DBD，序列号跟上面的相同，也是0x4DB。最后一行我们看到“end of Wait...”，这是路由器在推举DR/BDR之前的一个等待时间，这时候该等待时间到期，于是开始推举DR/BDR，所以我们可以推断出，接下来路由器的动作应该是推举DR/BDR。另外，那个DBD的flag依然显示后面还有DBD，所以后面应该还会收到序列号为0x4DB的DBD。

*Apr  8 00:48:24.063: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 10.1.1.1
*Apr  8 00:48:28.919: OSPF: Rcv hello from 10.1.1.2 area 0 from FastEthernet0/0 10.1.1.2
*Apr  8 00:48:28.923: OSPF: End of hello processing
*Apr  8 00:48:28.927: OSPF: Rcv DBD from 10.1.1.2 on FastEthernet0/0 seq 0x4DB opt 0x52 flag 0x7 len 32  mtu 1500 state 2WAY
*Apr  8 00:48:28.927: OSPF: Nbr state is 2WAY
*Apr  8 00:48:33.959: OSPF: Rcv DBD from 10.1.1.2 on FastEthernet0/0 seq 0x4DB opt 0x52 flag 0x7 len 32  mtu 1500 state 2WAY
*Apr  8 00:48:33.963: OSPF: Nbr state is 2WAY
*Apr  8 00:48:34.059: OSPF: end of Wait on interface FastEthernet0/0
 

8. 开始DR/BDR的选举过程。这里我们两台路由器都使用默认的优先级，所以选举的结果是谁的路由器ID大就谁当DR，由于只有两台路由器，所以R2为DR，R1为BDR。

*Apr  8 00:48:34.059: OSPF: DR/BDR election on FastEthernet0/0
*Apr  8 00:48:34.059: OSPF: Elect BDR 10.1.1.1
*Apr  8 00:48:34.059: OSPF: Elect DR 10.1.1.2
*Apr  8 00:48:34.059: OSPF: Elect BDR 10.1.1.1
*Apr  8 00:48:34.063: OSPF: Elect DR 10.1.1.2
*Apr  8 00:48:34.063:        DR: 10.1.1.2 (Id)   BDR: 10.1.1.1 (Id)

9. R1也开始向R2发送DBD，我们看到这时候它的DBD的序列号是0x56，flag也是0x7，所以R1也会宣告自己是MASTER。另外Hello定时器又到期，于是又组播Hello分组。

*Apr  8 00:48:34.063: OSPF: Send DBD to 10.1.1.2 on FastEthernet0/0 seq 0x56 opt 0x52 flag 0x7 len 32
*Apr  8 00:48:34.067: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 10.1.1.1
*Apr  8 00:48:38.927: OSPF: Rcv hello from 10.1.1.2 area 0 from FastEthernet0/0 10.1.1.2
*Apr  8 00:48:38.931: OSPF: End of hello processing

10. 收到R2发送过来的最后一个序列号0x4DB的DBD，由于这时候R2已经收到了R1的序列号为0x56的那个DBD，所以这时候R2可以根据路由器ID确定自己才是真正的MASTER，并在最后一个DBD中将状态更改为EXSTART状态，而R1成为SLAVE。这样，以后R1发送的所有DBD都必须要跟R2所提供的序列号相一致。“NBR Negotiation Done”表明主、从的磋商结束。我们这里也看到，虽然一开始的时候R2发送了很多个DBD过来，但真正可以用来决定MASTER/SLAVE关系的是R1送出的那个DBD（这才算交换）。我们看到这里最后一行，R1发送的DBD的序列号已经由前面的0x56改为跟R2的一致（0x4DB），另外，flag改为0x2，二进制为010，表明这不是第一个DBD，而且后面还有DBD，并且这是一个SLAVE发出的DBD。

*Apr  8 00:48:38.955: OSPF: Rcv DBD from 10.1.1.2 on FastEthernet0/0 seq 0x4DB opt 0x52 flag 0x7 len 32  mtu 1500 state EXSTART
*Apr  8 00:48:38.959: OSPF: NBR Negotiation Done. We are the SLAVE
*Apr  8 00:48:38.959: OSPF: Send DBD to 10.1.1.2 on FastEthernet0/0 seq 0x4DB opt 0x52 flag 0x2 len 52

11. 接下来两台路由器继续交换DBD，由于已经确立了主从关系，这时候称为EXCHANGE状态。R2发送一个序列号为0x4DC的DBD，R1收到后，也要在自己下一个发送的DBD的seq标记为0x4DB。最后一行表明R2已经将DBD完整地传给R1（但R1并不一定已经传送完DBD给R2）。

*Apr  8 00:48:39.071: OSPF: Rcv DBD from 10.1.1.2 on FastEthernet0/0 seq 0x4DC opt 0x52 flag 0x3 len 52  mtu 1500 state EXCHANGE
*Apr  8 00:48:39.075: OSPF: Send DBD to 10.1.1.2 on FastEthernet0/0 seq 0x4DC opt 0x52 flag 0x0 len 32
*Apr  8 00:48:39.215: OSPF: Rcv DBD from 10.1.1.2 on FastEthernet0/0 seq 0x4DD opt 0x52 flag 0x1 len 32  mtu 1500 state EXCHANGE
*Apr  8 00:48:39.219: OSPF: Exchange Done with 10.1.1.2 on FastEthernet0/0

12. 接下来的过程很像我们到餐馆吃饭的过程。双方交换了DBD之后，对自己的LSDB（链路状态数据库）中没有的链路，或者链路的序列号比自己的数据库中的链路的序列号高（看到菜谱中有新菜式），那么路由器会向对方发送一个LSR分组来请求对方将这条链路的详细信息发送过来（点菜）。对方路由器于是会把该链路的详细信息通过LSU分组来发送过来（服务员上菜），路由器会把接收到的链路加到自己的LSDB（吃进肚子里了）。具体到下面是，由于R1先收完DBD，所以R1向外发送LS REQ请求，这里count为1，表明请求的LS数量为1条。接下来R1继续把未发完的DBD发送给R2，flag的值为0x0表明这是最后的一个DBD，R2收到完整的DBD之后，也会向R1发送LSR，于是R1向R2发送LS UDP，然后R1也收到R2发送过来的LS UDP。接下来链路状态数据库同步完成。接下来将新链路状态加入到链路状态数据库，上述过程称为LOADING。当交换完毕链路状态之后，称为FULL状态。

*Apr  8 00:48:39.219: OSPF: Send LS REQ to 10.1.1.2 length 12 LSA count 1
*Apr  8 00:48:39.219: OSPF: Send DBD to 10.1.1.2 on FastEthernet0/0 seq 0x4DD opt 0x52 flag 0x0 len 32
*Apr  8 00:48:39.223: OSPF: Rcv LS REQ from 10.1.1.2 on FastEthernet0/0 length 36 LSA count 1
*Apr  8 00:48:39.223: OSPF: Send UPD to 10.1.1.2 on FastEthernet0/0 length 40 LSA count 1
*Apr  8 00:48:39.263: OSPF: Rcv LS UPD from 10.1.1.2 on FastEthernet0/0 length 64 LSA count 1
*Apr  8 00:48:39.267: OSPF: Synchronized with 10.1.1.2 on FastEthernet0/0, state FULL
*Apr  8 00:48:39.267: %OSPF-5-ADJCHG: Process 1, Nbr 10.1.1.2 on FastEthernet0/0 from LOADING to FULL, Loading Done