纯以太网环境，一条链路被blocking掉一定是因为STP发现有一个物理环么？未必！昨晚协助产品实施，发现一个问题，客户方的网管最终发现并解决了问题，可是他的解释却不正确。我想通过写本文来描述一下这件事。
首先是网络拓扑：
以下是相关的配置：
1.设备1的聚合0配置为broadcast方式，也就是同一个帧两根线上都发送；
2.设备1配置成具有聚合0以及E3的双端口网桥；
3.没有了
以下是相关现象：
连接线1被STP block掉了。分析1：
涉及到STP的问题，首先要看一下在布线上是否存在物理环，在以上拓扑中由于聚合接口的存在，物理环是有的，但是聚合接口连接的两根网线并不是独立的端口，因此它是不会从一个真实物理端口接收帧然后从另一个真实物理端口发出的，以上只是我的想法，一个会写代码的网管的想法，然而网管给出的解释不是这样，他为了不把连接线1给block掉，使用常规的方式，将SW1设置为ROOT桥，结果是肯定的，连接线1两端的接口不再处于blocking状态了，此处留下一个悬念。真正的原因是什么呢？没有环，真的没有环，没有环怎么还会block掉接口呢？端倪就在于聚合0接口的配置模式为广播，Switch没有聪明到能区分一个帧是重复绕过来的呢，还是被复制后重放的，这就是原因之所在，由于同样的帧在连接线2和连接线3上均发送，因此SW会认为存在环...
悬念造成的现象：
上述分析1中留下了个悬念，很高兴的看到线路1不再block了，然而过了稍许一会儿，从内网对SW1和SW2的访问很不稳定，掉包率很高。
分析2：
悬念造成的现象很奇怪，然而却在大多数情况下是必然的。千万不要拆东墙补西墙，解决了一个问题，带来的是另一个问题。这个现象还是因为聚合0接口的广播造成的，它直接使SW1和SW2的MAC表/ARP变得混乱(此时监控到了MAC flapping警告！)，内网一台PC的MAC地址分别从SW1和SW2的两个端口都能学习到，于是SW们不知所措了，如果是一台HUB或者百元内的Switch，广播会很多，如果高端些的Switch上再作一些特殊配置，通讯会很不稳定。MAC表的问题只是其一，还有ARP表(SWx均可以配置VLAN Interface)的问题。这个“环”(伪环)实际上是由于聚合0接口造成的，聚合0接口并不能看做是一个简单的HUB，因为它只在一个方向上广播数据。
坑爹的自动协商，坑爹的RSTP，能手工配置的千万别相信什么协议，然而手工配置需要一定的技术功底，那好，没那水平就用协议吧，一旦出了问题，你必须对那些以很精通才能搞定，估计也没那水平！怎么也绕不过，还是要学习啊，程序员们千万别再嘲笑网管没技术含量了，网络这个领域，太深奥了，这就是我，一个会写点代码的网管，一个懂点网络的程序员的心得！
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1268891
