交換機端口聚合的問題小解

交換機端口聚合功能使用廣泛，既能增加帶寬，又能提供冗余鏈路功能，深受網絡工程師的喜愛，在一些大型網絡環境，配合集群或虛擬化，可以對網絡的高可靠性提供更進一步的鏈路保障。

最近筆者單位為提高網絡安全，新增安全設備，在實施過程中，因為單位機房設備眾多，且安全設備主要是對機房核心設備進行防護，又不想更改現有網絡拓撲結構，安全設備就安裝在了用戶核心交換機與服務器核心交換機之間，做透明方式接入，拓撲圖如圖1所示。

兩臺交換機之間使用千兆電口做聚合、使用相同的聚合組（聚合組只具有本地有效性，此處是方便記憶）。兩臺防火墻獨立運行，沒有使用HA（此次使用的防火墻不支持HA雙活，不支持跨設備端口聚合，防火墻使用透明模式接入，每臺防火墻使用三個電口，兩個電口做橋接，接入網絡，一個電口做為管理口，用來管理安全設備）。兩臺交換機配置如下（部分）。

圖1 單位網絡拓撲圖

服務器核心交換機、用戶接入核心交換機：

使用intface vlan2作為路由接口，用戶網段與服務器網段使用VLAN2虛擬接口路由。

以上配置完畢，用戶反映內網服務器使用正常，在運行了一段時間后，突然有人反映，應用出現訪問緩慢，甚至打不開的情況。在用戶網段使用ping命令測試與服務器的鏈接情況，出現丟包現象。

當時認為是服務器出現問題，但在服務器網段訪問應用服務器時，應用打開速度正常，使用ping命令測試延時也在正常范圍內，且未出現丟包現象，通過與更多內網辦公用戶溝通，出現應用緩慢，甚至打不開的情況非常普遍。

當時認為是防火墻出現了問題，登錄防火墻查看情況，咨詢了防火墻廠家技術人員，都沒有找到防火墻策略出現了什么問題。

正在非常苦悶時，突然發現防火墻的一個橋接端口顯示狀態為“down”。當時第一想法是，“我做的端口聚合，即便有口‘down’掉了，鏈路是冗余的，所有流量都應自動切換到另外一條鏈路上，不應該出現丟包的問題的”。然后順便查看了接口上有沒有收到錯誤的數據包等工作，都沒有找到相關的問題。

無意中使用“dis linkaggregation ver”查看了服務器核心交換機聚合口的狀態，發現如圖2所示情況。

圖2 查看服務器核心交換機聚合口的狀態

圖3 在另外一臺交換機查看相關狀態

當然，有接口“down”掉，此接口變成了“U”狀態，也是正常的。但當在另外一臺交換機使用“dis linkaggregation ver”查看相關狀態時，瞬間明白了丟包的原因，如圖3所示。

兩臺交換機使用的都是1/0/1口跟1/0/2口，但是用戶核心交換機兩個口都是“S”狀態，然而服務器核心交換機1/0/1的狀態為“U”，1/0/2的狀態為“S”。

在使用靜態端口聚合時，端口在聚合組中是否傳輸數據的標準是：1.端口的狀態是否為“UP”狀態；2.端口是否為“選中”裝態，即“S”狀態。如果某個端口狀態為“UP”，但在聚合組中狀態為“U”，那么這個端口也不傳輸數據。

在此次問題中，因為服務器核心交換機的1/0/1接口連接的線纜脫落，接口的狀態為“down”，接口在聚合組中的狀態為“U”，因此這個接口不參與數據的轉發；但是用戶核心交換機1/0/1端口狀態為“UP”，在聚合組中的狀態卻為“S”，所以此接口參與數據轉發。

由于以上情況的發生，從而造成用戶核心交換機通過GE1/0/1與GE1/0/2兩個接口發送數據，而服務器核心交換機只能通過GE1/0/2接收數據，數據鏈路層接收到的數據不完整，導致應用層數據包也不完整，所以表現為應用打開緩慢或無法打開。

導致此次問題的根本原因是接口線纜的松動，但是也由此次問題讓筆者更深刻的認識靜態端口聚合所存在的問題，以及以后使用端口聚合時需要注意的問題，從而避免靜態端口聚合出現類似“接口分裂”的情況。