实验模式:
这张图是我做想要做链路聚合,但是在链路聚合实验中,出现了点儿小小小的问题,介于篇幅太长,所以单独把问题抛出来;
(在这里我们不讨论关于生成树的问题,因为默认为我都掌握)
第一步:我们先进行链路聚合:
在我们进行链路聚合前、先用PC1pingPC3。看下报文传播的路径好了;
当我们进行一个简单的抓包之后,就会发现数据报传输的链路;从LSW1->LSW2->LSW3,但是在没有进行链路聚合之前,我们发现:这三条路,会根据生成树协议选择没有阻塞的端口发出,至于什么生成树就不过多解释;
不过我发现一个比较有意思的事情:
在我没有对LSW1做任何手脚的时候:
它的stp是这样的;
1、当我选择把LSW1的e0/0/5端口shutdown,(这个端口是转发数据的端口),数据只会经过很短暂时间的超时:然后马上恢复正常;
(估计1秒都要不到)这个时候的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