实验模式：

这张图是我做想要做链路聚合，但是在链路聚合实验中，出现了点儿小小小的问题，介于篇幅太长，所以单独把问题抛出来；

（在这里我们不讨论关于生成树的问题，因为默认为我都掌握）

第一步：我们先进行链路聚合：

在我们进行链路聚合前、先用PC1pingPC3。看下报文传播的路径好了；

当我们进行一个简单的抓包之后，就会发现数据报传输的链路；从LSW1->LSW2->LSW3，但是在没有进行链路聚合之前，我们发现：这三条路，会根据生成树协议选择没有阻塞的端口发出，至于什么生成树就不过多解释；

不过我发现一个比较有意思的事情：

在我没有对LSW1做任何手脚的时候：

它的stp是这样的；

1、当我选择把LSW1的e0/0/5端口shutdown，（这个端口是转发数据的端口），数据只会经过很短暂时间的超时：然后马上恢复正常；

这个时候的LSW1已经没有eth0/0/5，而是马上（重点是马上！）根端口变成了eth0/0/6；

2、然后我再次把刚刚shutdown的链路（LSW2的e0/0/2端口）恢复正常后*（undo shutdown），他居然不转发报文了！有点高冷；

3、然后我马上，速度很快很快很快的查看了下stp brief（生成树协议情况），发现eth0/0/5马上出现了。然后又再次变成了根端口，没有毛病啊，依旧处于转发状态啊；但是报文就是一直超时啊。就是ping不通啊；作者表示很尴尬；

4、到现在，都过了3,4分钟了。Pc1还是超时状态；我想了想，貌似也超过stp定时器的delay时间了啊。所以也不应该是生成树重新计算时候导致的链路阻塞；不过就在我准备放弃的时候，尼玛啊，它又通了。打我脸啊、（但是讲真，这个时间真的太久了。）

5、基于我本人无聊的原则，我还是要搞清楚为什么！

和前面的做法一模一样，先shutdown交换机LSW1转发数据的端口，这时候报文没有在E5上跑。而是在新晋根端口E6上面跑；

我们可以发现，我们shutdown端口E5之后，报文在E6上跑的很欢！

在这个时候，我再次把e0/0/5打开（undo shutdown）

4035470.png">

我们发现，这时候这俩个都动了！都没有任何的数据包从这里转发；这个时候发送的全都是stp的配置信息；但是对于生成树协议来说，没有任何问题；然而他就是不转发；

于是我们抓包：交换机和主机之间的链路：

有从pc1发到pc3的ping请求的报文；但是没有任何应答；

所以，我还是没有发现那里有问题：先把问题丢在这，我很难过！

为什么当链路关闭后在重启需要这么久的时间才能进行转发，但是查看stp状态明明都是转发状态

不过我发现，只要重启下pc1的ping，就又能ping通；

所以我还不知道是什么原因，不过就当写着玩吧。

如果有大神发现了问题所在，求大神不吝赐教；

2017.3.12 by tea