HP Procurve 1800 交換機到交換機幹線和 LACP（還有 VLAN！）
我正在考慮將兩台（也可能是三台）HP Procurve 1800 交換機與乾線或 LACP 連接在一起。我無法通過 Google 或此處找到對我的問題的任何實質性答案。
我確實在 Procurve 交換機中找到了這個問題 Server-to-Switch Trunking，這是什麼意思？但問題的答案似乎是：a) 中繼可能意味著任何事情；b) 定義了 LACP。問題*是首選中繼還是 LACP？*沒有回答 - 它不是交換機到交換機，而是交換機到伺服器。
我還發現了這個問題LAN Design Question with HP Procurve但它也沒有回答上面提出的問題：*首選中繼還是 LACP？*無論如何，這個問題與 HP Procurve 2510 而不是 HP 1800 有關。
這些問題似乎都沒有討論我們的確切情況。共有三個交換機（所有 HP 1800）：
SW1(VLAN1) <-> SW2(VLAN1) <-> SW3(VLAN1) SW2(VLAN6) <-> SW3(VLAN6)這些交換機都是 HP 1800-24G（硬體版本 R01），具有以下軟體版本：
- SW1：PB.03.01
- SW2：PB.03.01
- SW3：PB.03.04
交換機 SW2 和 SW3 之間的鏈路都只允許 Tagged Packets，並且沒有 PVID（根據幫助文件的建議）。其他埠是 VLAN 1 或 VLAN 6，並允許所有數據包。除了偶爾的 100Mb 全雙工設置外，所有埠都是自動協商的；其他都是 1Gb - 沒有一個是 10Mb。
問題是 SW2 似乎沒有快速響應 ping 並且經常失去數據包（從 SW3 上的監控主機監控）。其他開關都很好，並且響應適當。主機之間的連接似乎沒問題。來自管理界面上的 SW1 和 SW2 的 HTTP 響應似乎很慢 - 比 SW3 慢。
我懷疑存在交通瓶頸，並想創建一個更大的管道。ping 到交換機的 IP 地址，與 HTTP 埠的連接也顯示響應時間很慢。據推測，連接（HTTP 和 ICMP）在 VLAN1 上，因為那是 IP 所在的位置 - 而 VLAN1 無論如何都是管理 VLAN。
從閱讀其他問題來看，聽起來“主幹”可以將兩個 VLAN 的流量組合在同一條線路上 - 將兩個連接減少到一個，或者使流量通過多個 VLAN 的多條線路。聽起來中繼線也可以與 LACP 結合使用，但這是否可取？
我的問題：
- 在這種情況下，首選中繼還是 LACP？為什麼？
- 在這種情況下，HP 將什麼稱為“主幹”？
- 在這種情況下應如何處理 VLAN？
- 我試圖解決錯誤的問題嗎？
- 韌體升級有幫助嗎？
無論如何，我想回答所有問題。
更新我忘了提到我發現這個網頁似乎很有幫助，但也沒有直接回答我的問題。聽起來（從那裡的答案）中繼是用於交換機到交換機的通信，而 LACP 是用於伺服器到交換機的通信。
LACP 是鏈路聚合控制協議。當有多個鏈路可用並且另一端也使用 LACP 時，這一切都是關於自動和動態地設置鏈路聚合。它通常與冗餘伺服器-交換機互連一起使用，因為只要沒有載入 NIC 驅動程序（實現鏈路聚合的地方），使用鏈路聚合的靜態設置就會中斷伺服器連接，從而有效地破壞預引導伺服器管理或網路引導能力。
對於交換機互連，通常首選靜態設置 - 儘管我認為這純粹是個人喜好問題。
“鏈路聚合”和“中繼”通常用作同義詞。LA (802.3ad) 有一個已定義的 IEEE 標準，並且在標準化之前已經出現了許多專有的供應商擴展，出於向後兼容性的原因，其中大多數甚至在較新的交換機模型中都有實現。
如果設置鏈路聚合或中繼組 (LAG/TG)，則應為兩側的交換機定義與組成員相同的 VLAN。如果您 a) 確切知道您在做什麼並且 b) 在兩個連接的交換機上啟用了 STP，則您只應在兩台交換機之間定義多條路徑（即多條 LAG 互連）。
如果您只是懷疑頻寬瓶頸，請使用交換機的埠統計計數器來驗證它 - 頻寬使用很可能會很好，而您的問題是完全不同的問題。大多數情況下，交換機確實有相當慢的 CPU 和快速的 ASIC，它們能夠完成大部分處理而不會給 CPU 帶來任何負擔。一些操作仍然會佔用 CPU 週期，其中非常“流行”的是接收廣播或多播數據包。如果您的網路正在生成大量廣播/多播流量，則處理和丟棄數據包本身可能會使交換機的 CPU 過度飽和。再次，檢查計數器以查看是否在網路上看到過多的廣播。