链路两端MTU不一致导致OSPF邻居状态不能达到Full状态

【OSPF卡在各种状态的原因】⽹络实验(OSPF卡在各种状态的原因)______________________________________⽩惜凌2018-1-12⽬录⼀、实验⽬的/要求 (1)⼀、OSPF卡在init、2-way、exstart/exchange的原因 (1)⼆、实验环境 (2)三、实验操作步骤 (3)五、总结 (9)⼀、实验⽬的/要求⽬的：1、掌握ospf故障排错2、掌握故障的解决⽅法要求：⽤实验证明OSPF卡在init、2-way、exstart/exchange的原因⼀、OSPF卡在init、2-way、exstart/exchange的原因1.不包含邻居路由器IDINIT状态中如果收到hello包中含有⾃⼰的routerID才会进⼊2-way状态，如果收到hello包中没有含有⾃⼰的routerID或收不到对⽅的hello包⽽⾃⼰可以发hello包时则会停留在INIT状态2.通过修改优先级为0对于MA⽹络，是要选举DR，BDR的，如果把优先级优先级都设为0，那么会停留在2-way状态3.通过修改MTU值MTU的值是从DBD报⽂交互开始的，也是在DBD报⽂交互结束，⽽DBD报⽂交互的在这个阶段原本要选举主从关系，我们通过修改MTU值，使得⽆法选举主从关系停留在exstart/exstart，或者exstart/exchange接下来实验证明请继续往下看⼆、实验环境使⽤GNS3模拟器搭建平台如图所⽰：两台路由器（IOS (tm) 3600 Software (C3660-IK9O3S-M), Version 12.2(40a)）接⼝ip分配如图所⽰：R1 R2Fa0/0:12.12.12.1/24 Fa0/0:12.12.12.2/24三、实验操作步骤实验1. 通过访问控制列表（ACL）INIT状态中如果收到hello包中含有⾃⼰的routerID才会进⼊2-way状态，如果收到hello包中没有含有⾃⼰的routerID则会停留在INIT状态，我们通过ACL（访问控制列表）和验证实现这个现象在R1上配置访问控制列表拒绝hello包分组流量通过，将R1上运⾏ospf的接⼝加⼊到控制列表组100中R1(config)#int fa0/0R1(config-if)#ip access-group 100 in //将接⼝加⼊到访问控制列表组当中R1(config)#access-list 100 permit ip any 12.12.12.0 0.0.0.255 //仅允许⽬的为12.12.12.0⽹段的接⼝地址流量通过，使⽤show ip ospf nei查看邻居，看不到R2了。

USG系列防火墙故障案例集目录USG2100攻击防范导致地址映射不成功接口MTU不匹配导致OSPF邻居卡在 ExStart 状态MTU参数问题导致无法访问外网网站解决ADSL拨号上网NAT SERVER 外网IP不固定问题解决L2TP连接后总部主动和分支通信的问题ADSL接口不能配置PVC命令问题V.35 SA卡双串口绑定与LOOP CONVERTER无法连通UTM模式下，更换部署网络，签名库/病毒库无法更新采用QoS限制其中一个子网访问外网的速率USG2100攻击防范导致地址映射不成功现象描述：用户需要将内部地址8000端口和8999等端口通过地址映射发布到外网，然而在外网访问发布的端口却发现，只有8000端口能够访问进来，其他做了映射的端口均不能访问成功原因分析：1：运营商阻止映射端口的通信2：防火墙包过滤未打开。

3：其它原因。

处理过程：1、将不能访问的端口修改成防火墙web登录的端口，可以访问。

说明运营商未封闭该端口。

2、查看防火墙上的包过滤策略，没有做端口过滤限制。

3、查看会话，发现除了8000端口外，访问任何映射的端口均无任何会话信息。

4、打开抓包功能，检查访问时数据包是否到了防火墙，当外网发起访问时能看到有数据包到达防火墙：[shanxi09]disp firewall packet-capture statisticQueueID CapturedNumber SentState TCP UDP ICMP Other -----------------------------------------------------------------------------0 4( 0%) Unsent 100.00% 0.00% 0.00% 0.00%1 0( 0%) Unused 0.00% 0.00% 0.00% 0.00%2 0( 0%) Unused 0.00% 0.00% 0.00% 0.00%3 0( 0%) Unused 0.00% 0.00% 0.00% 0.00%4 0( 0%) Unused 0.00% 0.00% 0.00% 0.00% 证明访问的报文已经到了防火墙，说明是防火墙将报文丢弃。

1.OSPF邻居形成过程？2.OSPF中承载完整的链路状态的包？3.链路状态协议和距离矢量协议的比较？4.OSPF防环措施？5.OSPF是纯链路状态的协议吗？6.OSPF中DR选举的意义？DR选举时，所有的路由类型？DR和其它路由器的关系？7.OSPF的NSSA区域和其它区域的区别？8.OSPF的LSA类型，主要由谁生成？9.IBGP为什么采用全互联？不采用全互联怎么部署？10.路由反射器的反射原则？11.OSPF邻居形成过程？12.OSPF有几类LSA？13.OSPF的NSSA区域与其它区域的通信方法？14.PPP协商过程？15.OSPF没有形成FULL状态的原因？1、该网络根本就没有启动OSPF。

接口上没有激活ospf，即在network语句的时候没有匹配清楚，在show ip ospf interface的时候不会显示希望激活的接口；2、OSPF邻居的hello及dead interval值不一致；3、在Stub或NSSA区域，有些路由器没有配置成Stub或NSSA。

需要注意，这点是经常被遗忘的；4、OSPF验证配置错误或不一致；5、OSPF链路两端的网络类型不一致；6、OSPF网络类型是NBMA，但没有在OSPF协议模式下配置邻居，观察邻居状态一直处于ATTEMPT状态；7、OSPF网络类型是NBMA，已配置邻居，但在诸如Frame relay的map语句中没有增加broadcast关键字，导致协议报文不能到达对方；8、OSPF Router ID有问题，可能和某个其它路由器配置相同，导致无法确认出Master和Slave；9、OSPF链路两端的MTU相差比较大，通常停留在EXSTART状态（需要在其接口下配置OSPF忽略MTU检查或修改MTU）；10、区域号不一致，链路的网络地址不一致，注意检查两边的mask。

（PPP协议可以自动协商出地址，mask不一致也会形成Full关系）；11、建立邻居的接口被passive掉；12、物理层或者是数据链路层协议down；13、OSPF的hello组播地址被ACL Block。

OSPF路由协议故障及排错解决方案
OSPF路由协议故障
常见故障：
(1) OSPF邻居建立失败(故障原因：1-8)
(2) OSPF邻居建立成功但是未交换任何路由信息(故障原因：9-10)
(3) OSPF邻居建立成功，但是接受到的路由信息不齐全(故障原因：11)
故障原因：
(1) 建立OSPF邻居的端口未被宣告
(2) 链路两端OSPF区域配置不一致
(3) OSPFRouter-id冲突
(4) OSPF验证模式不一致
(5) 有一端接口被配置为静默端口
(6) OSPF验证密钥错误，密码不匹配
(7) OSPFHello时间间隔不一致
(8) NBMA网络类型中未指定邻居
(9) OSPF链路一端端口网络类型为P2P，另一端为广播
(10) 对端设备未发布任何路由信息
(11) 链路两端接口MTU配置不一致
解决方案：
(1) 正确宣告两端接口地址
(2) 修改两端AREA配置，保证区域的一致性
(3) 正确配置OSPFRouter-id，保证Router-id的唯一性
(4) 正确配置OSPF验证，保证认证模式配置一致
(5) 解除端口静默模式配置
(6) 修改端口验证密码，保证使用正确的验证密码
(7) 修改Hello时间间隔，间隔一致
(8) 使用peerx.x.x.x指定邻居
(9) 修改端口网络类型，保持端口网络类型一致
(10) 宣告正确的网段
(11) 修改端口MTU值，保持两端MTU配置一致。

OSPF的协商MTU问题
问：OSPF中MTU 在哪里比较，如果不通过是什么状态？在什么报文里，如果IP 网络中没有MTU 一致性的统一规定会有什么问题出现？
答：MTU在EXSTART状态的时候进行比较。

MTU在DBD报文里面，如果MTU不通过，两台OSPF路由器的邻居状态会停留在EXSTART状态，不会达到完全邻接状态。

华为设备默认不检查MTU，所以在发送DBD报文时MTU字段都填入0，对于收到的DBD报文则忽略MTU字段。

具体情况以下分3种情况分析
⏹情况1：2端MTU不一致，并且任意1端开启MTU检查。

结果：2端可以建立FULL
的邻居关系。

分析原因：不开启MTU检查的一端收到对方的DBD后忽略MTU的检查直接通过，本身发送时MTU值填0，对方可以通过检查(向小兼容)。

⏹情况2：两端同时开启MTU检查，MASTER的MTU小，SLAVE的MTU大。

结果：MASTER
停留在EXSTART阶段，SLAVE停留在EXCHANGE阶段。

分析原因：由于MASTER的MTU小，所以MASTER不能通过MTU检查，直接卡在EXSTART阶段。

SLAVE通了MTU检查，并且开始发送有内容的DBD报文，所以卡在EXCHANGE阶段。

⏹情况3：两端同时开启MTU检查，MASTER的MTU大，SLAVE的MTU小。

结果：MASTER
和SLAVE同时停留在EXSTART阶段
分析原因：由于SLAVE的MTU小，所以MASTER可以通过MTU检查，等SLAVE送有内容的DBD。

但SLAVE不能通过MTU检查，所以不会主动送有内容的DBD，这样两者都卡在EXSTART阶段。

OSPF 邻居关系不能正常的原因和解决方法1、接口上没有激活ospf就是在network语句的时候没有匹配清楚，比如配置了错误的反掩码不对，在show ip ospf interface 的时候不会显示你希望激活的接口使用show ip ospf interface来验证这时候的邻居表是空的R2#show ip ospf neighborR2#2、物理层或者是数据链路层协议down.使用show ip int brief 或者是show int type nomber会导致ospf packet 封装失败。

3、建立邻居的接口被passive掉R2#show ip ospf interface Ethernet 0Ethernet0 is up, line protocol is upInternet Address 131.108.1.2/24, Area 0Process ID 1, Router ID 131.108.1.2, Network Type BROADCAST, Cost: 10Transmit Delay is 1 sec, State DR, Priority 1Designated Router (ID) 131.108.1.2, Interface address 131.108.1.2No backup designated router on this networkTimer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5No Hellos (Passive interface)Neighbor Count is 0, Adjacent neighbor count is 0Suppress hello for 0 neighbor(s)4、OSPF的hello组播地址被ACL BlockR1#interface Ethernet0ip address 131.108.1.1 255.255.255.0ip access-group 100 in!access-list 100 permit tcp any anyaccess-list 100 permit udp any anyaccess-list 101 permit ip 131.108.1.0 0.0.0.255 host 224.0.0.5R2#interface Ethernet0ip address 131.108.1.2 255.255.255.0ip access-group 100 in!access-list 100 permit tcp any anyaccess-list 100 permit udp any anyaccess-list 101 permit ip 131.108.1.0 0.0.0.255 host 224.0.0.5R2#debug ip packet 101 detailIP packet debugging is on (detailed) for access list 101IP: s=131.108.1.2 (Ethernet0), d=224.0.0.5, len 68, access denied, proto=89这时候的邻居关系是INITR2#show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface131.108.2.1 1 INIT/- 00:00:33 131.108.1.1 Ethernet0R1#show access-list 101Extended IP access list 101permit ip 131.108.1.0 0.0.0.3 host 224.0.0.5 (8 matches)R1#debug ip packet 101 detailIP packet debugging is on (detailed) for access list 101R1#IP: s=131.108.1.1 (local), d=224.0.0.5 (Ethernet0), len 60, sending broad/multicast,proto=89 IP: s=131.108.1.2 (Ethernet0), d=224.0.0.5, len 82, access denied, proto=89IP: s=131.108.1.1 (local), d=224.0.0.5 (Ethernet0), len 60, sending broad/multicast,proto=89 IP: s=131.108.1.2 (Ethernet0), d=224.0.0.5, len 82,access denied, proto=895、在broadcast链路上的子网掩码不匹配6、Hello/dead 间隔不匹配7、认证方式或者是认证密码不匹配使用debug ip ospf adj 来查看,可以自己使用不同的情况来验证8、两台路由器处于不同的AREAR1#debug ip ospf adjOSPF adjacency events debugging is onR1#OSPF: Rcv pkt from 131.108.1.2, Ethernet0, area 0.0.0.0mismatch area 0.0.0.1 in the headerR2#show log%OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must bevirtual-link but not found from 131.108.1.1, Ethernet09、Stub/transit/NSSA 区域类型不匹配，这个是常常不小心会被忘记的。

OSPF卡在各种状态的原因1．OSPF 邻居停滞于Attempt状态只有在NBMA中才会出现ATTEMPT状态，ATTEMPT状态是路由器在NBMA模式中必须经过的一个普通状态。

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

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

①Neighbor指向了错误的邻居②在NBMA中单播连接中断。

例如：ACL 阻止了单播2．OSPF邻居停滞于INIT状态路由器收到第一个分组将使路由器进入正常的INIT状态。

当一个路由器从邻居收到一个OSPF Hello 分组的时候，它在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-way4．OSPF邻居停滞于EXSTART / EXCHANGE状态在EXSTART / EXCHANGE 状态阶段：路由器选择一个主设备、一个从设备、一个初始序列号。

（EXSTART状态）整个数据库交换。

（EXCHANGE状态）停滞于EXSTART / EXCHANGE状态的原因：①不匹配的接口MTU 。

（邻居关系还没有建立好时）重传25次后DOWN掉后，等待一分钟，然后再次建立邻居关系结论：1．如果邻居建不起来（2-way 状态之前）网络类型为NBMA，邻居表显示一边是ATTEMPT状态，一边是INIT状态；网络类型为point-to-multipoint NBMA，邻居表显示一边是DOWN状态；一边是INIT状态。

如下是OSPF错误状态的总结：
1.OSPF陷入ATTEMPT
仅对neighbor语句的NBMA网络有效。

陷入ATTEMPT是指一台路由器试图通过发送它的HELLO来联系邻居但是它没有收到响应。

原因：错误配置neighbor；NBMA上的单播连通性断了，可能是由错误的DLCI，访问列表或转换单播的NAT引起的。

2.OSPF陷入INIT
INIT状态表示路由器收到来自邻居的HELLO分组，但是双向通信并没有建立。

原因：一方访问列表阻止了HELLO；
一方的多播能力失效（一个交换机故障）；
λ
λ一方的HELLO在第2层丢失了。

3.OSPF陷入2-WAY
双向状态是指路由器在HELLO分组的邻居字段中见到了自己的路由器ID。

原因：类似于所有路由器的优先级都为0，则不会发生选举，所有路由器停留在双向状态中。

某些情况下是正常状态。

4.OSPF陷入EXSTART/EXCHANGE
在EXSTART或EXCHANGE状态的OSPF邻居正处于尝试交换DBD（数据库描述）分组的过程中。

原因：不匹配的接口MTU
邻居上重复的路由器IDλ
无法用超过特定MTU 长度进行PINGλ
λ断掉的单播连通性，它可能是因为错误的DLCI，访问列表或转换单播的NAT
5.OSPF陷入LOADING
邻居没有应答或邻居的应答从未到达本地路由器，路由器也会陷入LOADING状态。

原因：不匹配的MTU
错误的链路状态请求分组λ。

OSPF卡在各种状态的原因1．OSPF 邻居停滞于Attempt状态只有在NBMA中才会出现ATTEMPT状态，ATTEMPT状态是路由器在NBMA模式中必须经过的一个普通状态。

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

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

①Neighbor指向了错误的邻居②在NBMA中单播连接中断。

例如：ACL 阻止了单播2．OSPF邻居停滞于INIT状态路由器收到第一个分组将使路由器进入正常的INIT状态。

当一个路由器从邻居收到一个OSPF Hello 分组的时候，它在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-way4．OSPF邻居停滞于EXSTART / EXCHANGE状态在EXSTART / EXCHANGE 状态阶段：路由器选择一个主设备、一个从设备、一个初始序列号。

（EXSTART状态）整个数据库交换。

（EXCHANGE状态）停滞于EXSTART / EXCHANGE状态的原因：①不匹配的接口MTU 。

（邻居关系还没有建立好时）重传25次后DOWN掉后，等待一分钟，然后再次建立邻居关系结论：1．如果邻居建不起来（2-way 状态之前）网络类型为NBMA，邻居表显示一边是ATTEMPT状态，一边是INIT状态；网络类型为point-to-multipoint NBMA，邻居表显示一边是DOWN状态；一边是INIT状态。