實驗模式：
這張圖是我做想要做鏈路聚合，但是在鏈路聚合實驗中，出現了點兒小小小的問題，介於篇幅太長，所以單獨把問題拋出來；
（在這裏我們不討論關於生成樹的問題，因爲默認爲我都掌握）
第一步：我們先進行鏈路聚合：
在我們進行鏈路聚合前、先用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）
我們發現，這時候這倆個都動了！都沒有任何的數據包從這裏轉發；這個時候發送的全都是stp的配置信息；但是對於生成樹協議來說，沒有任何問題；然而他就是不轉發；
於是我們抓包：交換機和主機之間的鏈路：
有從pc1發到pc3的ping請求的報文；但是沒有任何應答；
所以，我還是沒有發現那裏有問題：先把問題丟在這，我很難過！
爲什麼當鏈路關閉後在重啓需要這麼久的時間才能進行轉發，但是查看stp狀態明明都是轉發狀態
不過我發現，只要重啓下pc1的ping，就又能ping通；
所以我還不知道是什麼原因，不過就當寫着玩吧。
如果有大神發現了問題所在，求大神不吝賜教；
2017.3.12 by tea