作者:来自社区编辑部
说起这个trouble shooting啊真是坑人不少哭笑不得。大学里面学的时候都懂,但到实际的生产环境中做TS那真是一个字——坑!
这次分享的东东是我们很常见的网络层排错。可能最终的原因很简单但这实践经验真的感觉十足珍贵。
前提是这样的,处于某种原因我参与到了某某工控实验室的搭建工作当中来,按理说一个实验室环境的搭建并且所有网络环境都设计为二层这很容易搞定的,但结果呢?各种莫名其妙的问题搞得天天加班,泣不成声~由于设备大部分都是二次利用的,在没有恢复出厂的情况下做配置修改确实会惹很多令人脑裂的小问题……这里不细讲了,下面介绍一下基本的拓扑环境。
上图是实验室的基本网络拓扑,由于是工业网络所以加入了工业交换机组成的环网,其余的交换机都采用华为的S5700以及S5700s作为核心和接入,由于每个交换机都配置了管理地址所以测试网络层通信的时候都是通过ping管理地址来实现的,包括安全网关、防火墙(透明模式)也是。
所有交换机都没有起三层所有二层部署很快就OK了,接下来进入到了测试阶段,ping……ping,ping……好吧,最害怕出问题的环网不给力了,ping各种丢包啊,由于大学时候学的都是树形网络,对环网基本没有接触也没有想过这世界上竟然还有环网,所以环网出问题感觉手无足措,缺乏经验的我首先想到的是广播风暴,通过观察环网交换机的指示灯以及丢包现象来看初步判断就是组环失败,但按照说明手册配置确实是没有问题的,随后咨询厂家400将环网协议配置为RIP V3后现象消失。至于为什么我就不敢多想了呵呵……
确认组环成功后开始又一轮的测试,但测试到工业环网又出了问题,环网的核心和节点交换机ping都没问题,唯独三台安全网关ping测试不正常,而且现象是通一段时间后就超时,然后又通一段时间又超时,这是什么鬼?一!脸!懵!逼!
file:///C:/Users/74174/AppData/Local/Temp/msohtmlclip1/01/clip_image002.jpg
由于出问题的只有三台安全网关所以好好排查一下设备自身的问题看有没有什么限制,检查了配置没毛病,检查了线路没毛病,最后抱着一丝希望想到了是不是管理口MAC地址冲突,于是乎我在最上端的网络也就是企业网的核心交换中“display arpall”发现交换机学到的两个安全网关的MAC地址 一!样!为了确认现象,我便console到这两个安全网关查看管理口的MAC地址,仔细对比发现确实是一模一样!这概率可能晴天走路上都可能被
啊。
接下来就是想为什么物理接口的MAC地址会一样呢?可能是人工修改过吧毕竟是linux的内核。随后root登陆其中一台安全网关:
但这里有个问题就是设备重启就失效,MAC地址会恢复,所以想到了将配置内容添加到rc.d文件中,这个rc.d文件在/sbin文件夹中,vi打开却发现了些蹊跷。
红框标注的地方本应该是down却变成了up,这非常有可能是人为修改过的遗留错误,果断改了回来。
好了,reboot一下再看看吧……
结果令人失望,原先的MAC地址并没有改变。于是乎再次寻找原因,重新打开rc文件研究,发现一个net_mac.config的文件路径,根据名称判断很有可能与MAC地址配置有关!
顺藤摸瓜……
丫的,这不就是各个接口的MAC地址嘛!
这里可以看到端口agl0的MAC就是那个重复的错误MAC地址,原来根源在这里,果断又修改之,reboot……
两台安全网关都成功ping通,大功告成!
虽然端口MAC地址重复不是什么疑难杂症,但确实让我发现了实践的重要性,在当时的学习过程中认为这样的问题就算实际工作中遇到也很容易解决,但当自己真正遇到综合性的TS问题时这种不可思议的小问题可能就是最难逾越的沟坎。牢记:Impossible is nothing!
很高兴自己的经验值又+1了!
|