数通故障案例学习.docx
《数通故障案例学习.docx》由会员分享，可在线阅读，更多相关《数通故障案例学习.docx（16页珍藏版）》请在冰豆网上搜索。
数通故障案例学习
接口速率不同导致接口无法对接
网络环境
NE80E/40E上某光接口单板，需要与对端设备的100M接口对接。
该单板光接口默认速率是1000M。
故障分析
1. 在接口视图下执行命令speed100，出现错误提示信息。
不能将端口速率改成100M，因此无法与对端设备对接。
[Quidway-GigabitEthernet1/0/0]speed100
Settingtheconfigfail
Currentinterfacecan'tsupportthiscommand
2. 执行命令displaylogbuffer检查路由器的LOG，发现了该GE接口频繁的出现口Up/Down信息。
操作步骤
步骤1 在该接口下执行命令port-typefiber-100,将端口速率改为100M。
步骤2 在该接口下配置与对端接口在同一网段的IP地址，能够Ping通，故障解决。
----结束
案例总结
无论什么端口对接需先保证端口速率一致。
如果遇到不能识别的SFP模块，可以使用port-type命令将接口设置为对应的模式，强制接口在该模式下工作。
Eth-Trunk接口加入到VLAN失败
网络环境
在一台NE40上配置三层Eth-Trunk没有问题，但是在该设备上配置二层Eth-Trunk加入VLAN时却不成功。
故障分析
步骤1 在路由器上配置三层Eth-Trunk没有问题，说明Eth-Trunk的配置也不存在问题。
步骤2 配置二层Eth-Trunk加入VLAN时出现错误提示：
[Quidway-Eth-Trunk2]portdefaultvlan200
RoutedVLANshouldnothaveaggregationport
根据提示信息，判断可能是VLAN下配置有问题。
步骤3 在路由器上的VLAN视图下执行displaythis命令，检查VLAN的配置，发现VLAN下没有相关的冲突配置。
[Quidway-vlan200]displaythis
#
return
步骤4 考虑是否是VLANIF接口下的配置导致冲突。
在VLANIF接口视图下执行displaythis命令，检查VLANIF接口的配置，发现接口下配置了路由属性。
[Quidway-Vlanif200]displaythis
#
interfaceVlanif200
undoshutdown
propertyrouting
#
return
----结束
处理步骤
在NE40上执行以下操作。
步骤1 执行命令system-view，进入系统视图。
步骤2 执行命令interfacevlanif200，进入VLANIF接口视图。
步骤3 执行命令undopropertyrouting，取消VLAN接口的路由属性。
步骤4 执行命令portdefaultvlan200，配置Eth-Trunk加入VLAN。
步骤5 执行命令return退回到用户视图，执行命令save，保存对配置的修改。
----结束
案例总结
在二层Eth-Trunk接口加入VLAN时不要在VLANIF接口下配置propertyrouting命令。
propertyrouting命令用于配置VLAN接口的路由属性为routing，配置propertyrouting
采用Eth-Trunk接入，一部分分散用户无法正常访问网络（NE80/40）
网络环境
如图4-2所示，用户使用PPPoE方式拨号上网。
路由器使用Eth-Trunk方式，将用户的拨号报文送至认证服务器。
图4-1Eth-Trunk接入组网图
一段时间后，有一部分用户无法正常拨号上网，这部分用户分布很广，并不是集中在一个地方。
故障分析
步骤1 检查出现故障的用户MAC地址，出现故障的用户MAC地址比较分散，没有明显共同特性，排除在路由器或认证服务器上分别对这些用户进行限制的可能。
步骤2 重新安装其中一个用户的客户端，仍然不能正常拨号。
排除客户端故障的可能。
步骤3 从用户到认证服务器，执行命令ping，逐条检查每段链路的连通性。
发现从Router到认证服务器的链路上有丢包现象。
步骤4 执行命令displayinterface，发现Eth-Trunk的一条成员链路虽然物理层和链路层状态为Up，但是不能正常转发数据。
Eth-Trunk的成员链路通过Hash算法来分担流量，一个MAC地址按照固定的Hash算法，会分配到固定的一条链路上。
因此造成分配到同一条故障链路的用户均无法正常拨号。
----结束
处理步骤
步骤1 在故障链路的接口上执行命令shutdown，关闭该故障链路，使Eth-Trunk能够感知到链路故障。
步骤2 更换Router和认证服务器之间的故障链路。
完成后，用户可以正常拨号，故障解决。
----结束
案例总结
在排查Eth-Trunk的故障原因时，应充分考虑到成员链路负载分担的算法特征。
配置顺序不正确导致Eth-Trunk接口无法配置default-vlan
网络环境
图4-1Eth-Trunk典型组网图
NE40A配置Eth-Trunk后无法指定该接口的defaultVLAN，并有如下提示：
[Quidway-Eth-Trunk2]portdefaultvlan201
RoutedVLANshouldnothaveaggregationport
故障分析
Eth-Trunk接口无法配置default-vlan有如下可能的原因：
● Eth-trunk没有配置成二层特性，即没有在Eth-trunk接口下面执行portswitch命令。
● NE40A上面没有配置相应的VLAN。
进一步进行分析：
步骤1 执行命令displaycurrent-configuration，查看NE40A已经配置为二层特性并已经加入到VLAN中。
如下所示：
#
vlanbatch200to202
#
interfaceEth-Trunk2
undoshutdown
portswitch
#
interfaceGigabitEthernet1/0/0
undoshutdown
eth-trunk2
#
interfaceGigabitEthernet1/0/1
undoshutdown
eth-trunk2
步骤2 进一步查看日志发现原来设备上面曾经配置过VLAN201接口，而且VLANIF201下面配置了propertyrouting参数
具体见如下日志：
%May1114:
50:
472007QuidwaySHELL/5/CMD:
task:
vt0ip:
210.21.6.253user:
panrunkengcommand:
intvlan201
%May1114:
51:
172007QuidwaySHELL/5/CMD:
task:
vt0ip:
210.21.6.253user:
panrunkengcommand:
prorouting
%May1303:
06:
142007QuidwaySHELL/5/CMD:
task:
vt0ip:
210.21.6.253user:
liuweizhangcommand:
undointerfacevlanif201
在删除VLANIF201之前没有删除接口下面的propertyrouting参数导致VLAN201的propertyrouting属性没有删除，即使新建VLAN201后该属性依然存在。
该属性存在导致Eth-Trunk无法加入到VLAN中。
----结束
处理步骤
在NE40上执行如下的操作。
步骤1 执行命令system-view，进入系统视图。
步骤2 执行命令vlanvlan-id，进入VLAN视图。
步骤3 执行命令undopropertyrouting，去使能路由属性。
步骤4 执行命令return，返回到用户视图。
步骤5 执行命令save，保存对配置的修改。
----结束
完成上述操作后，在Eth-Trunk视图下，执行命令portdefaultvlan201，可以把Eth-Trunk接口加入到VLAN中。
案例总结
如果在VLANIF接口下面配置了propertyrouting参数的情况下，在删除这个VLANIF接口时，需要先删除VLANIF接口下面的propertyrouting参数，然后再删除VLANIF接口。
NE40端口自保护机制明确，当端口在时间段内没有收到数据业务报文，端口会自动的执行up/down的操作。
步骤1 执行命令interfaceethernetinterface-number，进入接口视图。
步骤2 执行命令port-self-protectdisable，去使能端口自保护功能。
没有使用ARP广播功能导致dot1q终结子接口下挂业务不通
网络环境
图4-1dot1q终结子接口下挂业务组网图
RouterA通过Eth-Trunk和SwitchA对接，RouterA的Eth-Trunk子接口配置dot1q终结子接口作为SwitchB下挂PC的网关；在RouterA上先shutdownRouterA和SwitchA的互连接口，然后undshutdown后发现在RouterA上PING不通PC。
故障分析
步骤1 检查中间SwitchA和SwitchB，没有发现异常。
步骤2 执行命令displayarpall，发现RouterA没有PC的ARP表项。
RouterA没有学习到PC的ARP表项造成RouterA无法PING通PC。
----结束
处理步骤
在RouterA上执行以下的操作。
步骤1 执行命令system-view，进入系统视图。
步骤2 执行命令arpbroadcastenable，使能终结子接口的ARP广播功能。
步骤3 执行命令quit，返回到用户视图。
步骤4 执行命令save，保存对配置的修改。
----结束
完成上述操作后，RouterA的ARP表项中有PC的表项。
RouterA可以PING通PC。
案例总结
arpbroadcastenable命令是为了避免大量发送ARP请求报文而影响系统工作而设计的一条命令，dot1q终结子接口缺省情况不使能该命令。
在端口上使用了该命令之后可以主动从该端口发送ARP请求报文，去请求对端的ARP，如果在该端口没有使能此命令，则无法主动发送ARP请求报文出来，包括主动PING以及ARP-MISS，都不会发送ARP请求报文出来，并且该端口在协议up之后会打上黑洞路由的标记。
BRAS下的用户可拨号，但打不开网页
网络环境
MA5200F通过155MPOS口与NE40路由器RouterA相连，MA5200F下接拨号上网用户。
如图5-5所示。
图5-1BRAS下的用户故障组网图
故障现象为：
MA5200F下的拨号用户可以正常拨号，但打不开网页。
故障分析
步骤1 从MA5200F的拨号用户进行拨号上网，从用户计算机上ping外网的网站可以ping通，排除上层设备路由问题。
步骤2 检查MA5200F和NE40的配置，发现没有配置ACL对报文进行过滤，排除设备配置的问题。
步骤3 检查NE40和MA5200F的POS接口状态，发现NE40的POS口的MTU为1024，而MA5200F的POS口的MTU为1500字节，两端不匹配。
步骤4 在NE40的POS口上进行本地环回，同时把POS口的MTU值改为1500，插上光纤后，发现NE40的POS的MTU值自动更改为1024。
据此可以判断是POS口SPF模块故障。
----结束
处理步骤
步骤1 取消NE40的POS口上的本地环回。
步骤2 更换NE40的POS口的SPF模块。
步骤3 检查NE40的POS口的状态，等到接口状态Up。
步骤4 从MA5200F的拨号用户登录到外网的网站，可打开网页，故障得以排除。
----结束
案例总结
本次故障现象，ping网站可以ping通，ping大包，小包都没有丢包。
此时，需要检查有没有配置ACL限制报文，和接口的MTU值是否两端一致。
CPOS接口的PPP协商正常结束后，无法ping通对端
网络环境
路由器与其他厂商设备通过CPOS接口互连，CPOS接口通道化为E1，链路层采用PPP协议。
在PPP协商正常结束后，不能正常ping通直连地址或访问对端设备连接的网络。
故障分析
步骤1 使用测试仪器检查链路，排除物理接口和链路故障。
步骤2 使用displaycurrent-configurationinterfaceserial和displaycurrent-configurationcontrollercpos命令，检查本端设备，发现其配置正确而且与对端匹配。
步骤3 使用displayinterfaceserial命令，结果如下：
displayinterfaceserial3/0/0/8:
0
Serial3/0/0/8:
0currentstate:
up
Lineprotocolcurrentstate:
up
AU-41,TUG-32,TUG-23,E11,ChannelGroup0,ChannelID 1
Description:
"rt-bb-ura1-01->cl-rt-ura-uniube-01（0497509-URA）Link-2"
Internetaddressis201.16.248.18/30
TheconfiguredMTUis1500bytes,andthenegotiatedMTUis0bytes
TimeSlotListinclude1-8,theBandWidthis512Kbits
TheMaxHQOSBandWidthis448Kbits
Link-protocolisPPP,loopbacknotset,clocksourcemaster,urpfdisabled
MRU:
1500bytes,NegotiateTimeoutset3seconds
PeerMRU:
notnegotiate,Magicnumber:
50342202
PeerIPaddressis201.16.248.17/32
LCP:
Opened
NCP:
IPCPOpened,MPLSCPStopped
Input:
94Lcps,0Ipcps,0Ip6cps,0Mplscps,0Osicps,0Invalids
Output:
52Lcps,0Ipcps,0Ip6cps,42Mplscps,0Osicps,0Invalids
Holdtimeis10（sec）
Input:
52TimerholdPackets
Output:
52TimerholdPackets
Last5minutesinputrate36bytes/sec,0packets/sec
Last5minutesoutputrate11bytes/sec,0packets/sec
Input:
376packets,19566bytes
0errors,0CRC,0giants
Output:
161packets,6068bytes,0underruns
0CRC,0abortedsequences,0giants
接口协商的MTU值为0。
初步断定可能是此MTU协商不成功导致的故障。
步骤4 使用displaycurrent-configuration命令，没有发现配置安全策略而过滤流量。
步骤5 进一步了解，发现其他厂商设备在MTU值为1500字节的情况下，不进行MTU协商。
此时，其他厂商设备既不发送MTU协商报文，也拒绝接收对端设备发送的协商报文。
而路由器在任何情况下都会进行MTU协商，协商的初始值是0，每次协商以上一次的协商结果为基础，如果协商失败则保持上次协商结果。
因此，当两端MTU都是1500字节时，路由器发送协商报文给其他厂商设备后被拒绝，同时也收不到其他厂商设备的协商报文，这样路由器得到的协商结果就是0，而其他厂商设备则保持自己的1500字节。
路由器在MTU是0的情况下不会转发数据，从而直连不通。
处理步骤
在路由器上执行以下操作：
步骤1 执行命令system-view，进入系统视图。
步骤2 执行命令interfaceserialinterface-number，进入同步串口视图。
步骤3 执行命令mtu1400，配置同步串口的MTU值。
将MTU值修改为1400字节。
同时，在对端也将MTU值修改为1400字节。
步骤4 执行命令shutdown，关闭同步串口。
步骤5 执行命令undoshutdown，启用同步串口。
完成后，两端协商的MTU值为1400字节，可以ping通对端，故障解决。
----结束
案例总结
在和其他厂商设备进行互通时，应注意分析路由器和其他厂商设备在一些协议上的不同实现方式。
光接口发光太强导致NE40的POS接口物理UP协议Down
网络环境
NE80和NE40通过传输设备以POS接口互连。
NE40侧POS接口的状态为物理UP协议Down。
故障分析
推测有以下几个原因：
● 两端的C2字节不匹配。
● 传输链路不好。
● POS接口模块有问题。
操作步骤
步骤1 检查配置确认两端接口参数配置无误。
步骤2 通过在设备上面打环测试，接口物理状态能够UP，能够检测到环路，确认单板的芯片没有问题。
步骤3 通过尾纤打环，接口物理状态能够UP，能够检测到环路，确认光接口模块没有问题。
步骤4 在传输上面向NE40侧打环测试，发现接口无法收到环路，所以怀疑是传输链路问题。
步骤5 传输人员检查传输后确认从NE40侧发出的光强度太大，导致传输设备接口故障。
升级会员 