数通故障案例学习.docx
- 文档编号:25336077
- 上传时间:2023-06-07
- 格式:DOCX
- 页数:16
- 大小:46.79KB
数通故障案例学习.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命令,结果如下:
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侧发出的光强度太大,导致传输设备接口故障。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 故障 案例 学习
![提示](https://static.bdocx.com/images/bang_tan.gif)