在 Linux 中綁定介面時切換泛洪
+--------+ | 主持人A | +----+---+ | eth0（AA：AA：AA：AA：AA：AA） | | +----+-----+ | 開關 1 | （第 2/3 層） +----+-----+ | +----+-----+ | 開關 2 | +----+-----+ | +----------+----------+ +-------------------------+ 開關 3 +-------------------- -----+ | +----+-----------+----+ | | | | | | | | | | eth0（B0：B0：B0：B0：B0：B0）| | eth4（B4：B4：B4：B4：B4：B4）| | +----+-----------+----+ | | | 主持人乙 | | | +----+-----------+----+ | | eth1 (B1:B1:B1:B1:B1:B1) | | eth5 (B5:B5:B5:B5:B5:B5) | | | | | | | | | +------------------------------+ +------------------------------+
- 拓撲概述
- 主機 A 有一個 NIC。
- 主機 B 有四個使用 balance-alb 模式綁定的 NIC。
- 兩台主機都執行 RHEL 6.0，並且都在同一個 IPv4 子網上。
- 流量分析
- 主機 A 正在使用一些 SQL 數據庫應用程序向主機 B 發送數據。
- 從主機 A 到主機 B 的流量：源 int/MAC 是 eth0/AA:AA:AA:AA:AA:AA，目標 int/MAC 是 eth5/B5:B5:B5:B5:B5:B5。
- 從主機 B 到主機 A 的流量：源 int/MAC 是 eth0/B0:B0:B0:B0:B0:B0，目標 int/MAC 是 eth0/AA:AA:AA:AA:AA:AA。
- 一旦建立了 TCP 連接，主機 B 就不再向 eth5 發送幀。
- eth5 的 MAC 地址從 Switch 1 和 Switch 2 的橋接表中過期。
- 交換機 1 繼續從主機 A 接收發往 B5:B5:B5:B5:B5:B5 的幀。
- 因為交換機 1 和交換機 2 不再具有 B5:B5:B5:B5:B5:B5 的橋接表條目，所以它們會將幀從同一 VLAN 上的所有埠中溢出（當然，除了它進入的埠之外）。
- 複製
- 如果您從連接到交換機 1 或 2 的工作站 ping 主機 B，則 B5:B5:B5:B5:B5:B5 重新進入橋接表並且泛洪停止。
- 五分鐘後（預設橋接表超時），泛洪恢復。
- 問題
- 很明顯，在主機 B 上，幀到達 eth5 並退出 eth0。這似乎沒問題，因為這就是 Linux 綁定算法的設計目的——平衡傳入和傳出流量。但是由於交換機停止接收帶有 eth5 源 MAC 的幀，它會超時超出網橋表，從而導致泛洪。
- 這是正常的嗎？為什麼不再有來自 eth5 的幀？是因為根本沒有其他流量在進行嗎（唯一的連接是來自主機 A 的單個大數據傳輸）？
我已經研究了很長時間，但沒有找到答案。文件指出，使用 Linux 介面綁定 (balance-alb) 的模式 6 時無需更改開關。發生這種行為是因為主機 B 沒有從 eth5 發送任何進一步的數據包，而在正常情況下它會發生嗎？一種解決方案是設置一個 cron 作業來 ping 主機 B 以防止橋接表條目超時，但這似乎是一個骯髒的 hack。
是的 - 這是預期的。您遇到了一個相當常見的問題，即 NIC 綁定到主機、單播泛洪。正如您所注意到的，您的交換機上的計時器用於相關硬體地址，因為沒有觀察到來自這些地址的幀。
以下是一般選項-
1.) 更長的地址表超時。在混合 L2/L3 交換機上，ARP 和 CAM 計時器應該彼此接近（CAM 計時器執行時間長幾秒鐘）。無論其餘配置如何，此建議均有效。在 L2 交換機上，定時器通常可以設置更長的時間，而不會出現太多問題。也就是說，除非您完全禁用計時器，否則如果沒有來自其他地址的某種流量來源，您最終會回到相同的情況。
2.) 您可以對相關交換機上的 MAC 地址進行硬編碼（不幸的是，圖中的所有交換機）。由於多種原因，這顯然不是最優的。
3.) 將 Linux 端的綁定模式更改為使用公共源 MAC（即 802.3ad / LACP）的模式。如果您的交換機支持它，這將具有很多操作優勢。
4.)通過每個介面的 cron 作業生成免費的arp 。您可能需要在各種介面上設置一些虛擬 IP，以防止出現振盪情況（即主機的 IP 循環通過各種硬體地址）。
5.）如果是交通問題，就去10GE！（對不起 - 不得不把它扔在那裡）
LACP 路由可能是最常見和最受支持的路由，並且可以將交換機配置為在各個鏈路上相當均勻地平衡到伺服器的入站流量。失敗了，我認為免費的 arp 選項將是最容易集成的。