第 3 層 LACP 目標地址散列究竟是如何工作的？
基於一年多前的一個較早的問題（多路復用 1 Gbps 乙太網？），我開始設置一個帶有新 ISP 的新機架，並在整個地方都帶有 LACP 鏈路。我們需要這個，因為我們有單獨的伺服器（一個應用程序，一個 IP）為整個 Internet 上的數千台客戶端電腦提供超過 1Gbps 的累積速度。
這個 LACP 想法應該讓我們打破 1Gbps 的障礙，而無需在 10GoE 交換機和 NIC 上花費一大筆錢。不幸的是，我在出站流量分配方面遇到了一些問題。（儘管 Kevin Kuphal 在上述連結問題中發出警告。）
ISP 的路由器是某種 Cisco。（我是從 MAC 地址推斷出來的。）我的交換機是 HP ProCurve 2510G-24。伺服器是執行 Debian Lenny 的 HP DL 380 G5。一台伺服器是熱備用。我們的應用程序無法集群。這是一個簡化的網路圖，包括所有具有 IP、MAC 和介面的相關網路節點。
雖然它包含所有細節，但很難處理和描述我的問題。因此，為簡單起見，這裡是簡化為節點和物理鏈路的網路圖。
所以我開始在新機架上安裝我的套件，並從他們的路由器連接我的 ISP 的電纜。兩台伺服器都有到我的交換機的 LACP 連結，並且交換機有到 ISP 路由器的 LACP 連結。從一開始，我就意識到我的 LACP 配置不正確：測試顯示，進出每台伺服器的所有流量都通過一個物理 GoE 鏈路專門在伺服器到交換機和交換機到路由器之間傳輸。
通過一些Google搜尋和大量關於 linux NIC 綁定的 RTMF 時間，我發現我可以通過修改來控制 NIC 綁定
/etc/modules# /etc/modules: kernel modules to load at boot time. # mode=4 is for lacp # xmit_hash_policy=1 means to use layer3+4(TCP/IP src/dst) & not default layer2 bonding mode=4 miimon=100 max_bonds=2 xmit_hash_policy=1 loop這使流量按預期通過兩個 NIC 離開我的伺服器。但是流量仍然只通過一條物理鏈路從交換機傳輸到路由器。
我們需要通過兩條物理鏈路的流量。在閱讀和重讀 2510G-24 的管理和配置指南之後，我發現：
$$ LACP uses $$源-目標地址對 (SA/DA)，用於通過中繼鏈路分配出站流量。SA/DA（源地址/目標地址）使交換機根據源/目標地址對將出站流量分配到中繼組內的鏈路。即交換機將來自相同源地址的流量通過同一條中繼鏈路發送到相同的目的地址，並通過不同的鏈路將來自同一源地址的流量發送到不同的目的地址，這取決於交換機之間路徑分配的輪換。樹幹中的連結。
似乎綁定鏈路只提供一個 MAC 地址，因此我的伺服器到路由器的路徑總是在交換機到路由器的一條路徑上，因為交換機只看到一個 MAC（而不是兩個 - 一個來自每個埠）用於兩個 LACP 連結。
知道了。但這就是我想要的：
更昂貴的 HP ProCurve 交換機是 2910al 在其散列中使用 3 級源和目標地址。從 ProCurve 2910al 的管理和配置指南的“跨中繼鏈路的出站流量分配”部分：
通過中繼的流量的實際分佈取決於使用源地址和目標地址中的位進行的計算。當 IP 地址可用時，計算包括 IP 源地址和 IP 目的地址的後五位，否則使用 MAC 地址。
好的。所以，為了讓它按照我想要的方式工作，目標地址是關鍵，因為我的源地址是固定的。這引出了我的問題：
第 3 層 LACP 散列究竟是如何工作的？
我需要知道使用了哪個目標地址：
- 客戶端的 IP，最終目的地？
- 或者路由器的IP，下一個物理鏈路傳輸目的地。
我們還沒有離開併購買了替換開關。請幫助我準確了解第 3 層 LACP 目標地址散列是否是我需要的。購買另一個無用的開關不是一種選擇。
您正在尋找的通常稱為“傳輸雜湊策略”或“傳輸雜湊算法”。它控制從一組用於傳輸幀的聚合埠中選擇一個埠。
事實證明，獲得 802.3ad 標準很困難，因為我不願意在上面花錢。話雖如此，我已經能夠從半官方來源收集到一些資訊，這些資訊可以幫助您了解您正在尋找什麼。根據2007 Ottawa, ON, CA IEEE 高速研究組的此展示文稿，滿足802.3ad 標準並沒有要求“幀分配器”使用特定算法：
本標準不強制要求任何特定的分發算法；但是，任何分發算法都應確保，當幀由 43.2.3 中規定的幀收集器接收時，該算法不應導致 a) 作為任何給定會話一部分的幀的錯誤排序，或 b) 幀的重複. 通過確保構成給定會話的所有幀按照它們由 MAC 客戶端生成的順序在單個鏈路上傳輸來滿足上述保持幀順序的要求；因此，此要求不涉及向 MAC 幀添加（或修改）任何資訊，也不涉及相應幀收集器部分的任何緩衝或處理以重新排序幀。
因此，無論交換機/網卡驅動程序使用何種算法來分配傳輸的幀，都必須遵守該展示文稿中所述的要求（大概是從標準中引用的）。沒有指定特定的算法，僅定義了兼容的行為。
即使沒有指定算法，我們也可以查看一個特定的實現來了解這種算法是如何工作的。例如，Linux 核心“bonding”驅動程序有一個符合 802.3ad 的傳輸散列策略來應用該函式（請參閱核心原始碼的 Documentation\networking 目錄中的 bonding.txt）：
Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>這會導致源 IP 地址和目標 IP 地址以及源 MAC 地址和目標 MAC 地址都影響埠選擇。
在這種類型的散列中使用的目標 IP 地址將是幀中存在的地址。花點時間考慮一下。路由器的 IP 地址，位於從您的伺服器到 Internet 的乙太網幀標頭中，並未封裝在此類幀中的任何位置。路由器的MAC 地址存在於此類幀的標頭中，但路由器的 IP 地址不存在。封裝在幀有效負載中的目標 IP 地址將是向您的伺服器發出請求的 Internet 客戶端的地址。
考慮到源 IP 地址和目標 IP 地址的傳輸散列策略（假設您擁有廣泛多樣的客戶端池）應該會非常適合您。通常，當使用基於第 3 層的傳輸散列策略時，流經這種聚合基礎設施的流量中更廣泛變化的源和/或目標 IP 地址將導致更有效的聚合。
您的圖表顯示了從 Internet 直接發送到伺服器的請求，但值得指出代理可能對這種情況做些什麼。如果您將客戶端請求代理到您的伺服器，那麼正如克里斯在他的回答中所說，那麼您可能會導致瓶頸。如果該代理從其自己的源 IP 地址發出請求，而不是從 Internet 客戶端的 IP 地址發出請求，那麼在嚴格基於第 3 層的傳輸雜湊策略中，您將擁有更少的可能“流”。
只要符合 802.3ad 標準中的要求，傳輸散列策略也可以考慮第 4 層資訊（TCP/UDP 埠號）。正如您在問題中提到的那樣，這種算法位於 Linux 核心中。請注意，該算法的文件警告說，由於碎片化，流量可能不一定沿同一路徑流動，因此，該算法並不嚴格符合 802.3ad。