组网拓扑:<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><?xml:namespace prefix = w ns = "urn:schemas-microsoft-com:office:word" />
故障现象:
此组网为早期UA5000业务上行的传统组网拓扑,其中Metro100与OSN2500为友商传输设备,主要为下挂的UA5000语音业务提供上行通道。由于业务发展需要,现需将UA5000做短时停电处理(增加电源模块)。由于组网情况,UA5000与传输Metro100在同一机柜.需同时掉电处理.当再次来电后,UA5000业务无法正常.及UA5000对网关与软交换都无法PING通.
故障猜想:
1,UA5000版本问题,由于主备板版本不同而使UA5000在重起后以备用为主用,从而造成业务中断.
2,UA5000在设备重起后,无法正常保存数据从而致使部分数据丢失.
3,Metro100由于掉电问题,致使其数据没有完全保存.从而导致数据丢失.
4,由于原组网设备经过传输通道,需与传输相关人员协调,故障可能由于传输设备问题引起.
5,T64端对端口做有限制,对端口MAC的绑定有一定规定.或者对MAC老化时间规定有一定时间.
6,端口问题,由于传输OSN2500与T64端口模式不同而导致数据无法识别.
故障验证:
1,到达UA5000现场后,通过登录发现,UA5000数据仍在.主备板版本相同.但却无法PING通网关与软交换.排除故障猜想1.
2,通过改造组网拓扑,让UA5000通过光电转换器直接下挂到T64上一新端口.协调网管人员在上端修改数据后.UA5000业务正常.排除故障猜想2.
3,通过与传输相关人员沟通协调,得到确认Metro100在掉电重起后,数据正常.并无数据丢失现象.排除故障猜3.
4,为验证传输是否存在问题,通过与传输工程师沟通做以下验证组网:
通过以上组网拓扑,跟传输工程师沟通后在Metro100与OSN2500上配置好相关通道数据.先让PC1与PC2用网线直连,在确认可互相PING通后,再按上组网分挂传输两端.PC1仍可PING通PC2.从而可以单独排除故障猜想4.
5,为排除上端T64问题,特做以下验证组网:
通过以上组网,将传输与上端T64单独分开定位问题所在,在T64上做上临时验证数据.通过实验结果可以看出.当分开后两部分单独都为正常.从而可以单独排除故障猜想5.
6,将原组网环境搭建好,在T64与传输设备之间加装交换机.特做以下验证组网:
在交换机端口起端口镜像,通过抓包分析,PC1向T64与PC2发的数据包中,无法获取到ICMP报文.只可获取到ARP报文.也即,在T64与PC2中可以通过ARP表项查看到相关PC1的MAC与IP的对应关系.而在PC1端无法查看到上端对应情况.在T64端更换端口后,只能发现泛出的个别广播包.从而可以确认故障为OSN2500与T64对接问题所引出的故障.确定本故障原因为故障猜想6.
故障处理: