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

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

问题是这样的：前天下午我们网管局域网突然出现大量丢包，网络严重阻塞，到其中一个机房的数据通信全阻。整个局域网处于一个广播域，我的机子也在这个广播域中，也受到影响。不多说直接上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
1	分析你的架构，定位你的问题可能出现在哪些代码模块，估算大概位置	画出网络拓扑图，找出可能的环，标出可疑的连接
2	退到可测试通过的版本，然后一点一点的增加代码，测试，再增加，测     试，直到问题出现	拔掉可疑的所有连接，回到正常情况。增加一根，测试，再增加一根，测试，直到问题出现
3	找到问题代码后，分析出现的原因	找到问题链路后，分析出现的原因
4	修改数据或者重构，解决问题。	修改数据，解决问题

原则：

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

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

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

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

类比：

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

如TCP/IP七层协议:

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

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

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

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

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