ospf的建立过程.docx

ospf的建立过程.docx

《ospf的建立过程.docx》由会员分享，可在线阅读，更多相关《ospf的建立过程.docx（12页珍藏版）》请在冰豆网上搜索。

ospf的建立过程

   ospf建立过程

        刚学完了ospf（openshortestpathfirst）、eigrp、bgp等三大协议，这也是路由原理所要求会的知识，尤其ospf，是我们这门课的重点的重点，所以在这里也觉得有了一些自己的看法，也分享一下吧！

！

！

       在理解之前，我觉得，脑中最好有这些东西，它们就像是ospf学习的一些主干吧！

！

 首先有5个报文

1.hello报文

2.databasedscription（DBD）数据描述报文

3.link-staterequest（LSR）链路状态请求报文

4.link-stateupdate （LSU）链路状态更新报文

5.link-stateACK（LSAck）     链路状态确认报文 

然后是七个状态

1.DOWN  状态

2.INIT状态

3.TWO-WAY状态

4.EXSTART状态

5.CXCHANGE状态

6.LODING状态

7.FULL状态

       只有有了这些东西,然后把5个报文分别放入相应的状态里,相信你就会有一个新的理解了!

!

!

!

      好了先从状态入手吧!

1.DOWN状态

    在这状态下,所有的设备刚起动,所以相互之间没有交换任何数据,所以也称关闭状态!

2.INIT状态

     这个状态又称准启动状态,这时所有的设备开始交换hello报文了（有了报文了注意,hello报文就是在这里出现了,内容是通告自己是谁,谁在这个链路上）,邻居收到同样也用hello报文回复一个（我是谁,我有这个链路上）这时,设备知道了对方的存在了,所以开始进入下一个状态

3.TWO-WAY状态

      承上启下,通过比较hello报文中（是否routr-id唯一、是否有相同的生存时间和死亡时间等条件）所有要求符合了，这时就建立了邻居关系（补一点，hello报文也是区分链路状态和距离矢量的重要之处）

        &&&如果所属的网络类型是广播类型，这时就要在这里选举DR/BDR（靠优先级选，优先级相同时，由router-id来选举），再进入下一状态

4.EXSTART状态

        邻居已建立了（从这里到最后都属于邻接关系的建立了

），开始传送一个DBD报文（又出现了一个报文），开始交换自己的（LSDB的一个摘要数据），当彼此收到了DBD报文后就回复一个LSAck报文（出现了一个报文）表示我收到了，双方确认后，进入下一个状态

5.EXCHANGE状态

       这时设备之间就开始用这个DBD报文描述的内容与自身的LSDB（Link-statedatabase链路状态数据库）比较，当发现了DBD报文中的自己没有的内容时，这时便进入了下一个状态       

6.LOAING状态

      设备由对方的DBD报文比较出了自己没有的内容，所以要开始发送LSR报文（出现了一个报文）向邻居学习，这时邻居没有的也会向自己发送LSR报文学习，当彼此收到了LSR便发送一个LSAck报文确认收到，并且再向对方发送一个LSU报文（出现了一个报文）告诉邻居所请求的内容，彼此收到了LSU报文后也要发送一个LSAck报文确认！

！

这时都开始记录了，随之也进入了下一个状态

7.FULL状态

     设备都学习到了LSU报文内容，这时邻接建立完成！

！

FULL状态也完成！

     在时，其实设备的路由表中是不会有任何学习来的条目的，因为ospf是基于报文来让其它设备学习记录的，（这也是链路状态与距离矢量的区别吧）这时如果在设备上showiproute

只能看到直连网段，因为ospf协议在进行完了上面的七种状态后，还要进行spf计算，最后再由管理距离决定最后进入路由表中的条目！

！

      是不是看了上面的过程有点晕，呵呵！

毕竟是我的理解，由于知识及表达能力上的不足，所以也希望你能多看山山几遍！

希望对你有些帮助吧！

！

1.Down状态:

刚刚开启ospf,还没有收到任何数据,此时路由器本身是可以发送hello企图寻找ospf邻居

2.attempt状态:

这是在特殊网络条件下才有的状态,就是不支持广播的网络（非广播网络）,以太网是没有的,因为ospf需要使用组播发送hello,所以在这种网络环境下,必须要指定使用单播来发送hello,这种状态叫做attempt状态

3.init状态:

一方收到了另一方的hello.在这个hello包中还看不到自己是对方的邻居,这种状态叫做init状态.

4.two-way状态:

双方的hello已经交换完成,建立了邻居关系（注意区别于邻接关系）,dr,bdr选举成功,若两端都是drother路由器则会一直停留在这个状态

5.Exstart状态:

交换LSA之前,两端路由器会选择一个主从关系,确定由谁来先发起数据（DBD,LSR等）,router-id较大者成为主路由器,先发送,选举主从关系的状态叫做exstart状态

6.Exchange状态:

交换DBD的过程,DBD相当于一个路由器自己的链路状态数据库的目录,对方收到DBD根据目录来索要自己需要的信息从而发送lsr

7.Loading状态:

邻居收到了对方发来的LSR,回复对方索要的信息LSU,这是一个学习的过程,叫做loading状态

8.Full状态:

完全邻接状态,数据库已经同步,网络收敛完成,就是最后达到的正常的状态

这就是整个ospf建立的过程,若有某处不解请明示,详尽解答!

1.OSPF邻居停滞于Attempt状态

只有在NBMA中才会出现ATTEMPT状态，ATTEMPT状态是路由器在NBMA模式中必须经过的一个普通状态。

如果路由器如果一直停滞于ATTEMPT状态，则表明路由器发送了Hello分组给一个邻居，但是没有收到回应。

这个问题仅仅在定义了neighbor语句的NBMA网络中才会出现。

①Neighbor指向了错误的邻居

②在NBMA中单播连接中断。

例如：

ACL阻止了单播

2.OSPF邻居停滞于INIT状态

路由器收到第一个分组将使路由器进入正常的INIT状态。

当一个路由器从邻居收到一个OSPFHello分组的时候，它在Hello分组中包含进邻居的路由器ID并发送这个Hello分组。

如果它不包含邻居的路由器ID，那么邻居将停滞于INIT状态。

①验证只在某一边启用。

②ACL在某一边阻止了Hello分组。

3．OSPF邻居停滞于2-WAY状态

正常情况下，在MA网络等广播介质中，Drother之间的邻居状态是2-WAY状态，Drother与DR和BDR之间形成FULL状态。

停滞于2-WAY状态的原因：

路由器上都配置了优先级0,DRother与DR/BDR关系都为full,DRother与DRother之间全部都是2-way

4.OSPF邻居停滞于EXSTART/EXCHANGE状态

在EXSTART/EXCHANGE状态阶段：

路由器选择一个主设备、一个从设备、一个初始序列号。

（EXSTART状态）

整个数据库交换。

（EXCHANGE状态）

停滞于EXSTART/EXCHANGE状态的原因：

①不匹配的接口MTU。

（邻居关系还没有建立好时）重传25次后DOWN掉后，等待一分钟，然后再次建立邻居关系

结论：

1．如果邻居建不起来（2-way状态之前）

网络类型为NBMA，邻居表显示一边是ATTEMPT状态，一边是INIT状态；

网络类型为point-to-multipointNBMA，邻居表显示一边是DOWN状态；一边是INIT状态。

网络类型为Broadcast/P2MP/P2P/，邻居表显示一边为空，一边是INIT状态。

2．对于MA网络，如果路由器优先级都设为0，则会停滞于2-way状态，因为这个状态下需要选举DR/BDR。

3．如果MTU不匹配，会卡在Exstart状态；这个字段是携带在DBD中的。

4.网络类型为NBMA/P2MPNBMA,所有的包只能通过单播发送（Neighbor命令）.

5．如果网络类型是point-to-point，则所有的包通过组播发送。

224.0.0.5

6．如果网络类型是Broadcast/P2MP，则发包既有组播，又有单播。

EXCHANGE状态之前的包是用组播发送的。

EXCHANGE状态之后的包是用单播发送的。

（带LSA摘要信息的DBD包）

224.0.0.5:

DR/BDR与Drother通讯,同时BDR监听此地址

224.0.0.6:

DRother找DR时用的地址.

7．Attempt状态只会出现在NBMA网络中，如果路由器发了Hello包而收不到回复，则会置于Attempt状态。

配置好DNS服务器，添加了相应的记录之后，只要IP地址保持不变，一般情况下我们

就不再需要去维护DNS的数据文件了。

不过在确认域名解释正常之前我们最好是测试

一下所有的配置是否正常。

许多人会简单地使用ping命令检查一下就算了。

不过Ping

指令只是一个检查网络联通情况的命令，虽然在输入的参数是域名的情况下会通过DNS进行查询，但是它只能查询A类型和CNAME类型的记录，而且只会告诉你域名是否存在，其他的信息一概欠奉。

所以如果你需要对DNS的故障进行排错就必须熟练另一个更强大的工具nslookup。

这个命令可以指定查询的类型，可以查到DNS记录的生存时间还可以指定使用那个DNS服务器进行解释。

　　查询IP地址

　　nslookup最简单的用法就是查询域名对应的IP地址，包括A记录和CNAME记录，如果查到的是CNAME记录还会返回别名记录的设置情况。

其用法是：

　　nslookup域名

　　以下是A记录的返回情况。

　　nslookup命令会采用先反向解释获得使用的DNS服务器的名称，由于我这里使用的是一个内部的DNS服务器所以没有正确的反向记录，导致结果的前面几行出错。

大家可以不必理会。

重点看的是最后的两行这里看到的是的IP地址是61.145.112.212。

注意即使的主机没有在线同样能够返回结果。

　　如果目标域名是一个别名记录（CNAME），nslookup就开始显示出和ping命令不同的地方了，请看查询CNAME记录的结果。

由于CNAME和A记录最后都是活的IP地址，所以一般情况下两者是等同看待的，命令的格式相同。

　　注意这次nslookup返回了三行信息，前两行显示这是一个CNAME记录，对应的域名和IP地址。

最后显示的就是目标域名，并注明Alias（别名）。

    如果域名不存在会怎样呢？

　　看得懂最后以行的英文吗，不懂没关系记住形状就可以了。

如果一个指定类型的域名不存在对应的记录同样也是这种结果。

　　查询其他类型的域名

　　前面两个命令我们没有加任何参数，所以默认情况下nslookup查询的是A类型的记录。

如果我们配置了其他类型的记录希望看到解释是否正常。

这时候ping就无能为力了。

比如我们配置了MX记录，但是邮件服务器只能发信不能收信，到底是域名解释问题还是其他的问题Ping命令的检查只能让你误入歧途。

nslookup这时候可以模拟你的其他遇见服务器进行域名解释的情况。

我们需要在nslookup上加上适当的参数。

指定查询记录类型的指令格式如下：

　　nslookup–qt=类型目标域名

　　注意qt必须小写。

　　类型可以是一下字符，不区分大小写：

　　A地址记录（Ipv4）

　　AAAA地址记录（Ipv6）

　　AFSDBAndrew文件系统数据库服务器记录（不懂）

　　ATMAATM地址记录（不是自动提款机）

　　CNAME别名记录

　　HINFO硬件配置记录，包括CPU、操作系统信息

　　ISDN域名对应的ISDN号码

　　MB存放指定邮箱的服务器

　　MG邮件组记录

　　MINFO邮件组和邮箱的信息记录

　　MR改名的邮箱记录

　　MX邮件服务器记录

　　NS名字服务器记录

　　PTR反向记录（从IP地址解释域名）

　　RP负责人记录

　　RT路由穿透记录（不懂）

　　SRVTCP服务器信息记录（将有大用处）

　　TXT域名对应的文本信息

　　X25域名对应的X.25地址记录

  看看的邮件服务器记录吧。

　　看看，nslookup把服务器的名称和地址都给出来了，注意preference就是前面所说的优先级，该数值越小则优先级越高。

　　我再看看名字服务器记录是怎么样的。

　　看起来和MX记录的格式差不多，一般情况下服务器会同时返回对应的地址。

不过也有不返回的情况。

　　在这里我希望大家注意一行显示“Non-suthoritativeanswer:

”，这一行在前面的例子中都没有显示过。

它的出现代表这个结果是从服务器的缓存中得到的。

所以提醒你这不是一个授权的答案。

前面我们进行的几次查询过程中192.168.1.104这台机器就采用了我们第一篇文章中描述的过程查询了的域名。

在这个过程中不但缓存了、以及的MX记录等最终结果。

也包括获取的名字服务器等中间结果。

隐含的查询了的NS记录。

后面我们还会介绍这个过程。

　　指定使用的名字服务器

　　在默认情况下nslookup使用的是我们在本机TCP/IP配置中的DNS服务器进行查询，但有时候我们需要指定一个特定的服务器进行查询试验。

这时候我们不需要更改本机的TCP/IP配置，只要在命令后面加上指定的服务器IP或者域名就可以了。

这个参数在我们对一台指定服务器排错是非常必要的，另外我们可以通过指定服务器直接查询授权服务器的结果避免其他服务器缓存的结果。

命令格式如下：

　　nslookup[-qt=类型]目标域名指定的DNS服务器IP或域名

　　我们可看看以下的命令结果：

    这个命令直接从顶级域名服务器查询的NS记录。

所有的二级域名的NS记录都存放在顶级域名服务器中，这是最权威的解释。

注意这次没有非授权结果的提示。

对于二级域名的NS记录查询来说这肯定是授权结果。

顶级域名服务器的名称是a到j.gtld-共十台服务器。

（gtld是GlobalTopLevelDomain的缩写）。

当我们修改域名的NS记录的时候可以通过上述查询知道修改的结果是不是已经在顶级域名服务器上生效。

不过即使已经生效也可能不能正常解释，注意我在上一篇文章中提到的缓存时间的问题。

　　那么到底缓存多久呢？

　　检查域名的缓存时间

　　检查域名的缓存时间需要我们使用一个新的参数：

-d

　　格式如下：

　　nslookup–d[其他的参数]目标域名[指定的服务器地址]

　　请看范例 

　　我们忽略其他的看看Gotanswer后面几行，包括了一个ttl数值。

这个数值就是域名记录的生存时间。

　　这种查询将整个DNS数据包的所有部分都揭示出来，大家可以看到DNS实际上并不是想象中那么简单的东西。

具体的各部分解释大家可以去看看相关的标准文档。

需要提醒大家的是一定要找到ANSWER:

的内容，其他的东西都不是描述最终的结果。

上面就不止一个地方又TTL数值。

  域名解释过程的模拟

　　我们现在来模拟一下一台DNS服务器接到一个不是自己管理的域的域名解释过程。

回忆一下第一篇文章的过程：

　　首先我们会询问根服务器，然后根服务器会让我们去找对应的顶级服务器。

如果查询的是，就会要求我们去找net的服务器。

　　看看下面的范例：

　　这里我们让的服务器解释的域名，很显然这台服务器不用有这个域，需要询问根服务器。

一般情况下DNS服务器会帮我们完成全部的过程。

这种解释方式我们称之为递归解析，为了让大家看到这个过程我家了一个参数让的服务器不要这样做。

这个参数是-norecurse。

这样理论上会让我们去问根服务器，不过由于它已经缓存了顶级服务器的记录，所以直接返回了管理net的顶级服务器记录。

实际上大部分的查询都不需要从根服务器开始。

大家看到了所有的顶级域名服务器的地址都被返回。

　　我们随便选择一个在进行查询。

　　这次顶级服务器就返回了的服务器地址记录的。

然后我们就向这些记录之一进行查询，一定能够得到答案。

可能是一个地址、一个CNAME记录或者告诉你不存在。

　　nslookup的命令就介绍到这里，其实nslookup还有许多其他参数。

不过常用的就俄这么几个，另外如果大家不喜欢命令行方式的话。

还有几个图形界面的nslookup功能的工具。

不过大家还是需要了解域名解释都有些什么才能够正确使用这些工具