网络排障少走弯路两案例速解网管疑难
在网络的管理运维过程中,可以说故障是不可避免的。如果有管理员企图打造零故障的网络,只能是徒劳。因为网络故障有太多的随机性和偶然性,何况还有人为因素。所以,管理员要做的是掌握网络排错技巧,积累经验培养敏锐的嗅觉,能够少走弯路,快速定位并排除故障。笔者做技术支持时目睹过不少网管的排错过程,也看过一些别人的排错文章,发现有不少人有意或者无意地走了不少弯路。下面很大家共享两例网络排错案例,希望对朋友们有所启发。
案例一:病毒引发的网络故障
故障现象
早上刚上班,用户打来电话说某个子网的客户端无法正常上网。并且反馈信息,在Ping DNS时断时续,远程登录三层交换机,检查连接用户办公楼端口,未发现有异常情况。
故障诊断
笔者建议管理员首先检查网络是否出现风暴或网络回环。打开Sniffer软件监控用户所在网络,看是不是出现流量异常的现象,监控两个小时后发现流量很正常。很奇怪,据用户反映在中午下班时网络正常恢复正常,但是下午用户又打来电话说网络又不正常了,初步判断问题出在用户端。
笔者让管理员到用户办公室逐个排查。根据用户反映,如果把网卡禁用后再启用,网络就正常了,但过10分钟又无法ping通,周而复始。我们知道,网卡禁用再启用的过程,就是一个Arp的学习过程,在此期间,它会发出一个Arp的请求,询问谁是这个网段的网关,然后得到这个网关的MAC地址,然后当它需要去访问不同网段机器的时候,就会把数据包丢给那个网关。那么,是不是用户的某台机器中了病毒,导致它可以模仿真实网关的地址,使得在局域网内的客户端在上网时都把数据包发给了这个模仿真实网关的机器,从而产生故障?马上找了一台机器用arp -a命令去查看这台机器默认网关的MAC地址,发现当网络正常时显示的默认网关的MAC地址是正确的,当故障出现时默认网关的MAC地址突然变了。
故障解决
记下出现故障时显示的那个网关的MAC地址,然后在楼道交换机上根据这个MAC地址查到是哪个机器,拔掉该机器的网线后,网络恢复正常。至于为何中午下班时上网正常,是因为用户下班时将中病毒的机器关了,所以大家都又能够正常上网。中毒机器杀毒后也恢复正常。
排错总结
通过对这个网络的故障分析,我们总结出以下几点:首先是当网络出现故障的时候,一定要多到用户端了解情况,最好能通过用户对故障的描述抓住网络故障的实质。其次,当出现奇怪的网络现象时,可以分析是否是用户端的机器中了病毒导致这种现象发生,并不一定是网络设备的问题。
案例二:用户端交换机环路引起故障
故障现象
维护人员发现7号三层交换机远程无法登录,初步怀疑设备故障,于是迅速赶到机房检查设备运行情况,设备供电及其与S8016核心交换机连接均正常,在交换机控制口Ping网关不通;CPU利用率38% ;检查运行日志未发现有告警。检查端口,发现e 0/3流量不正常,输入流量远大于输出,将e 0/3 Down后,交换机Ping网关正常,业务恢复正常,检查所有端口,只有
三口流量不正常,最后确定是三口所带的用户问题,用户端不停地发包,流量过大造成三层交换机上联口拥塞,从而影响其他用户正常上网。
排错过程
到用户端检查,将用户所用的公网IP配置在笔记本电脑上直接上网,上网正常,确定用户端光电转换器和线路无故障。检查用户交换机配置正常,但是只要接上用户交换机,机房内三层交换机就无法正常工作,判断用户交换机故障。由于用户交换机无资料,无法确定每个端口的业务明细,只有采取将交换机上的连接线一个个拔出,同时检查机房三层交换机运行情况的方法来判断故障点的位置。当将用户交换机e 2/8端口线路拔出后,机房内人员报告三层交换机运行恢复正常,立刻检查该线路,发现这条线路的另一端连接在第e 2/29端口,原来是这条线路两端都连接在交换机上造成环路,导致链路拥塞,用户无法上网。详细检查发现造成环路的端口都未配置,并且没有业务使用,交换机没有发出环路告警。
排错总结
故障处理完毕后,总结分析如下:
(1).用户交换机走线杂乱,线路未作标签,业务走向不明,是造成环路故障的主要原因。
(2).由于造成环路的端口未使用,没有配置业务,导致交换机无法在13志中产生环路告警,也未能报告出哪个VLAN故障。
(3).环路可造成广播风暴,数据流量猛增,造成汇聚设备上联口拥塞,远程无法登录。电脑中ARP病毒后不停发包,也能造成设备死机,远程无法登录,两种情况有相似之处。
总结:两个简单的案例,带给我们不少启发。希望管理员朋友们在日常的维护工作中注意机房内的资料整理,确保线路连接整齐规范。在处理故障时多注意观察三层交换机日志和端口流量,能有效地减少网络故障和处理故障时间。
![微信公众号](https://files.cnblogs.com/files/Hackerman/%E9%BB%98%E8%AE%A4%E6%A0%87%E9%A2%98_%E6%A8%AA%E7%89%88%E4%BA%8C%E7%BB%B4%E7%A0%81_2020.gif)
出处:http://www.cnblogs.com/Hackerman/