软件工程与网络维护的统一方法论

今天下午帮助诺西的工程师解决了一个网络的小故障,回来的路上回想了整个解决问题的过程,发现解决问题的思路和软件工程的解决问题的方法是一致的,基本上就是一个套路,方法论是抽象于技术之上的。

问题是这样的:前天下午我们网管局域网突然出现大量丢包,网络严重阻塞,到其中一个机房的数据通信全阻。整个局域网处于一个广播域,我的机子也在这个广播域中,也受到影响。不多说直接上wireshark,抓包结果发现大量的Ethnet II的包,源和目的地址都是mac地址,协议unknown,很显然是这是个广播风暴。由于到那个机房最严重,完全不通,无法维护软交换设备了,叫上公司的车赶到机房先看看再说。

打开机柜门,诺西厂家最近新加了一对CE和一对SPC,四根网管的网线赫然接到同一个网管交换机上,这个交换机级联到汇聚交换机再到省里去,简单粗暴的拓扑,呵呵。上网管的时间和故障发生时间几乎都是在那天下午,时间上一致,应该和这个有关系,因为设备还没上线,断然拔掉这四根网线,测试,故障消失。

第一感觉就是有环路,这也比较明显,有网络基本知识的都知道。

回来后把问题告知厂家检查CE和SPC之间是不是有环路连接,厂家认为CE间是三层连接不会出现环路。

今天厂家约我一起到机房去查故障,好吧,去看看。笔记本接上网管交换机,持续ping网关,测试丢包情况。

厂家说他们核查没什么问题,我说这样吧,你把拓扑给我:

上面是拓扑图,显然四根线都有可能分别形成一个环路。

撕下一页纸,把拓扑复制一份,标上1,2,3,4,我说你到那头去,先把1234都拔掉,然后我要你插那根你就插哪根,一根一根加,看什么时候会丢包。

先加1,没有丢包

再加2,没有丢包

再加3,出现丢包

拔掉3,插上4,没有丢包

明显就是3所在的这个环有问题,厂家这时说三层的路由器的怎么会呢,我说那要看是不是二层连接,这时厂家说CE1和CE2的这两个接口属于同一个VLAN,我说那不就出来了吗,你两个CE处于同一个VLAN16然后又接到一个广播域里面去,不就创造了一个环路吗。厂家说看看网管交换机数据, 显示配置没有STP,于是说STP没开所以会有这个问题。这时我就不同意了,STP生成树检测不能为环路的出现负责,假定其他的设备将STP打开的前提是没有道理的,因为没有STP你也应该消除环路,stp的职责是检测和保护不是允许你出现环路。 我说这根本的原因不是STP,而是你不该做CE的trunk透传这个vlan的数据,每根线都独立连接到网管交换机,网管又不需要保护切换,这个数据是多余的。厂家点头,对,是不需要。

取消trunk的vlan16,问题解决。

----------------------------------------------

 这是网管维护中的一个很小的故障,但是我后来想了一下发现很有意思,因为我处理这个问题很多地方都体现了一个程序员的思维。

步骤:

  Programming Debug Networking Troubleshooting
分析你的架构,定位你的问题可能出现在哪些代码模块,估算大概位置 画出网络拓扑图,找出可能的环,标出可疑的连接 
退到可测试通过的版本,然后一点一点的增加代码,测试,再增加,测     试,直到问题出现 拔掉可疑的所有连接,回到正常情况。增加一根,测试,再增加一根,测试,直到问题出现
找到问题代码后,分析出现的原因 找到问题链路后,分析出现的原因
4 修改数据或者重构,解决问题。 修改数据,解决问题

原则:

1、不要认为你的代码没有问题:

          三层连接没有环路吗?如果是二层呢?

2、不要用其他的理由为你的问题找借口,不要让你的代码高耦合,成功运行不应该依赖于附加的非必要的前提条件:

      STP不应该为环路的出现负责,查环路不应该把STP作为前提,应该在没有STP检测保护的情况下也能正常工作。

类比:

设计模式和通信协议也是一样

如TCP/IP七层协议:

底层好比抽象类,上层好比实现,实现必须依赖于抽象。

下层封装了上层数据,抽象封装了多种实现。

上层出问题,先看下层有没有问题,一层一层来看。模式架构的问题首先出现在抽象层封装不好。

凡事的道理都差不多,抽象,高观点的看待问题总是能发现问题的一致性,从而可以重用移植方法达到共性的解决。

掌握科学的思维工具所获得的生产力是巨大的。

posted @ 2011-05-12 20:46  babykick  阅读(318)  评论(0编辑  收藏  举报