注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

山林客

简单不一定幸福,但幸福其实可以很简单。

 
 
 

日志

 
 
关于我

2004年毕业于中山大学,毕业后专注于网站开发和网络工程技术。先后取得SCWCD、CCNP认证,对Asp/Java有丰富的开发经验,对网络工程也有较深的研究。真诚欢迎大家多多指教、多多指点、多多指正,共同分享IT道路和人生道路上的喜怒哀乐。

网易考拉推荐

OSPF建立邻接关系的过程  

2008-10-29 23:15:50|  分类: Cisco |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

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

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

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

(3)LSU分组:链路状态更新,这是真正的链路状态信息,也就是通往某个目标的详细路径信息。

(4)LSR分组:用来请求一个链路状态信息。

(5)LSAck分组:对其他分组进行确认。

还有一个概念就是LSDB(链路状态数据库),它保存所有链路状态信息。

 OSPF建立邻接关系的过程 - 瑞志.net - Bills Tec. Space

下面我们结合在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 

 

 

 

  评论这张
 
阅读(1113)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018