设为首页 收藏本站
查看: 1145|回复: 0

OSPF为什么不形成邻接在PRI、BRI或者拨号程序接口?

[复制链接]

尚未签到

发表于 2015-5-25 11:37:40 | 显示全部楼层 |阅读模式
  前言
当拨号程序接口配置作为点到点链路时,此技术说明 解释OSPF邻接的形成的一个问题。
  问题
OSPF网络类型在主速率接口、基本速率接口(BRI)和 拨号程序接口点到点,意味着接口不能形成邻接与超过一相邻。 一个常见的问题当时PRI、BRI或者拨号程序接口设法形成 OSPF邻接是相邻困住在exstart/exchange进程里。请查看示例。
DSC0000.jpg
  使用 show ip ospf neighbor 命令 ,我们能发现相邻状态在"EXSTART"被滞留。
  RTR-A#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   EXSTART/  -     00:00:37    3.3.3.3         Serial6/0:23
3.3.3.4           1   EXSTART/  -     00:00:39    3.3.3.4         Serial6/0:23
RTR-B#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:36    3.3.3.2         BRI0
RTR-C#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:35    3.3.3.2         BRI0

RTR-Bs配置显示网络类型点到点:
  RTR-B#show ip ospf interface bri0
      BRI0 is up, line protocol is up (spoofing)
        Internet Address 3.3.3.3/24, Area 2
        Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 1562
        Transmit Delay is 1 sec, State POINT_TO_POINT,
        Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
          Hello due in 00:00:06
        Index 1/1, flood queue length 0
        Next 0x0(0)/0x0(0)
        Last flood scan length is 1, maximum is 1
        Last flood scan time is 0 msec, maximum is 0 msec
        Neighbor Count is 1, Adjacent neighbor count is 0
        Suppress hello for 0 neighbor(s)

我们能使用debug ip ospf adj命令调试此 情况。请查看被采取的若 干示例输出当在RTR-B运行此命令在以上时图:
  1: Send DBD to 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x7 len 32
2: Rcv DBD from 3.3.3.2 on BRI0 seq 0x1D06 opt 0x42 flag 0x7 len 32  mtu 1500 state EXSTART
3: First DBD and we are not SLAVE
4: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x2 len 92  mtu 1500 state EXSTART
5: NBR Negotiation Done. We are the MASTER
6: Send DBD to 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x3 len 92
7: Database request to 3.3.3.2
8: sent LS REQ packet to 3.3.3.2, length 12
9: Rcv DBD from 3.3.3.2 on BRI0 seq 0x250 opt 0x42 flag 0x7 len 32  mtu 1500 state EXCHANGE
10: EXCHANGE - inconsistent in MASTER/SLAVE
11: Bad seq received from 3.3.3.2 on BRI0
12: Send DBD to 3.3.3.2 on BRI0 seq 0x2441 opt 0x42 flag 0x7 len 32
13: Rcv DBD from 3.3.3.2 on BRI0 seq 0x152C opt 0x42 flag 0x2 len 92  mtu 1500 state EXSTART
14: Unrecognized dbd for EXSTART
15: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x0 len 32  mtu 1500 state EXSTART
16: Unrecognized dbd for EXSTART
第1行-第3行:RTR-B发送第一DBD到 3.3.3.2 (RTR-A)与顺序0xB41并且从3.3.3.2接受第一DBD (RTR-A) 与顺序# 0x1D06.邻接协商仍然不完成。
  第4行-第6行:RTR-B收到从(RTR-A) 表明的 3.3.3.2的一个回复RTR-A接受了RTR-B的第一DBD。因为RTR-B 有更高的路由器ID,RTR-A 选择自己从属。在收到应答以后 从RTR-A,RTR-B在它自称重要并且发送第一DBD带有数据。注 释序号,是0xB42。因为RTR-B是主设备,只有能增加序号。
  第7行:RTR-B请求数据从 RTR-A因为RTR-A指示有更多数据发送(标志位集对0x2在从RTR-A接收 前DBD)。
  第8行:RTR-B寄发一 个链路状态请求信息包到3.3.3.2 (RTR-A)。这是OSPF信息包 第三类型。此信息包通常寄发到邻接IP 地址。在这 种情况下,邻接IP地址是其路由器ID。
  第9行-第11行:RTR-B收到从从属(RTR-A)带有 一个完全不同的序号和0x7标志位的一个回复,是init标志位。 此DBD为另一个路由器(很可能RTR-C)打算,但RTR-B不正确地 接受了它。RTR-B宣称那里是差误因为0x7 标志位意味着从 属更改了其状态到主设备通过设置MS (主从的)位在邻接交换期间。 因为有故障,RTR-B也抱怨序号。从属应该总跟随主设 备的序号。
  第12行:RTR-B通 过发送第一DBD 重初始化邻接到3.3.3.2重选主设备和从属。
  第13行-第14行:RTR-B从 3.3.3.2接受DBD (RTR-A),表明它是从属,没有认可RTR-B的序号。 RTR-B宣称不认可此DBD因为重要和从属协商不完成。此DBD信息包为另一个路由器打算。
  第15行:RTR-B收到从3.3.3.2的一个回复(RTR-A)为老DBD, 但太晚因为RTR-B已经重初始化邻接进程。
  第16行:RTR-B不能认可此DBD因为是为"老"邻 接,RTR-B已经切断了。
  此进程将重 复操作得不尽地。
  解决方案
根据RFC 2328在接口达到双向状态以 后,第8.1部分,OSPF发送一个组播信息包为一个点到点的网络类型 。因为RTR-A设法形成邻接带有RTR-B和RTR-C,RTR-B收到为 RTR-C意味着的DBD信息包并且RTR-C收到为RTR-B意味着的DBD 信息 包。
  解决此问题,更改网络类型在 所有 路由器到点对多 点。 这更改OSPF工作情况在双向状态以后发送单播信息包。 现在RTR-B收到为本身注定的仅信息包并且RTR-C收到为本身 注定的信息包。 更改网络类型这样保证OSPF路由器在PRI、 BRI或者拨号程序接口将形成邻接。
  更改网络类型,输入以下配置命令,结束每条线路通过按Enter。 我们将更改RTR-B例如。
  RTR-B#conf term
RTR-B(config)#int bri 0
RTR-B(config-if)#ip ospf network point-to-multipoint
RTR-B(config-if)#end
现在 如果我们查看 show命令为 RTR-B,我们能验证网络类型点对多点并且状态是充分的。
  RTR-B#show ip ospf interface bri0
BRI0 is up, line protocol is up (spoofing)
   Internet Address 3.3.3.3/24, Area 2
   Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_MULTIPOINT, Cost: 1562
   Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
   Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
     Hello due in 00:00:16
   Index 1/1, flood queue length 0
   Next 0x0(0)/0x0(0)
   Last flood scan length is 1, maximum is 1
   Last flood scan time is 0 msec, maximum is 0 msec
   Neighbor Count is 1, Adjacent neighbor count is 1
     Adjacent with neighbor 172.16.141.10
   Suppress hello for 0 neighbor(s)
RTR-B#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.141.10     1   FULL/  -        00:01:36    3.3.3.2         BRI0

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-70527-1-1.html 上篇帖子: OSPF+PPPoE的技术实现 下篇帖子: 华为路由器与第三方路由器对接OSPF经验
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表