具有奇數源 IP 的 Arp 請求未得到答复
我的伺服器存在網路連接問題，我認為這些問題來自 arp 協議處理問題。
假設網路拓撲如下：
- 網路 192.168.106.0，網路遮罩 255.255.255.0
- 路由器位於 192.168.106.1
- “問題伺服器”位於 192.168.106.2
- 192.168.106.3 的另一台伺服器
現在，假設“問題伺服器”可能在網路上保持沉默的時間足以使其在路由器上的 arp 條目過期。
當來自此網路之外的人嘗試連接到“問題伺服器”時，所有嘗試都會超時。從網路內部到“問題伺服器”的連接成功。
如果“問題伺服器”本身嘗試連接到網路外部的某個其他地址，則連接成功 - 此後，從網路外部到“問題伺服器”的連接也會成功一段時間。此外，從“問題伺服器”到“另一台伺服器”的連接正常。
在“問題伺服器”長時間靜默的情況下查看arp流量，可以看到網路上對“問題伺服器”地址的arp請求，但是這些上的“tell”地址是網路地址（ 192.168.106.0) 而不是路由器地址 (192.168.106.1) - 這就是我認為是這個問題的原因：由於某種原因，路由器在其 arp 請求中的回复地址錯誤。
“另一台伺服器”仍然可以訪問，但我認為原因是它經常與本地網路外部建立連接，從而使其在路由器上的 arp 條目不會過期。
有什麼意見/建議嗎？
有問題的伺服器正在執行 Linux（CentOS 5.x？），並且在 VMWare ESXi（5.0？）中作為虛擬機執行（我將在周一恢復工作後檢查/填寫版本詳細資訊）。路由器品牌/型號對我來說是未知的。
對問題的回答，進一步的發現
很抱歉遲遲無法歸還。
不幸的是，我對網路端（VMWare 平臺本身之外的任何東西）的可見性受到嚴重限制。
基於來自路由器的 arp 請求數據包，它是 Juniper 產品（通過請求者 MAC 地址猜測）。
這是一個小型網路，因此可以將拓撲視為路由器、交換機和託管多個虛擬機的單個 VMWare 伺服器。
至於奇怪的 arp 請求的發起者，它幾乎必須是網路網關：它們僅在我嘗試從網路外部連接到“問題”機器時出現 - 並在嘗試超時或被取消時停止。一個小的奇怪是這些請求中的 MAC 地址與建立出站連接後在伺服器 arp 表中看到的路由器不同。但是，這些“奇數”請求中存在的 MAC 地址以及伺服器 arp 表中顯示的 MAC 地址都具有瞻博網路分配器 OUI。
然後是一個可能相關的發現；似乎Linux不會響應“告訴”地址是網路地址的arp請求，而Windows（至少Vista）會。這是我無法在實際問題環境中測試的，而是在家裡用自己的玩具進行測試。
此外，看起來我並不完全獨自處理這個問題。可以在這裡找到類似的體驗：alpacapowered.wordpress.com
今天帶來了一個有趣的變化。
最終，事情歸結為兩件事：
瞻博網路路由器，或者實際上是集群防火牆系統，不知何故失去了集群各方之間的配置同步。結果，並非 FW 集群的所有部分都具有最新配置，這導致 arp 請求錯誤（是的，錯誤的 arp 請求確實源自路由器/防火牆）。
防火牆的管理應用程序也行為不端，試圖將目前正確配置之外的一些配置推送到防火牆集群的至少一部分。
我沒有關於防火牆本身和管理應用程序所做的詳細資訊，但最終結果是現在 arp 請求上的“告訴”地址是路由器 IP 地址（原始描述中的 .1 )，而不是網路地址 (.0)。
對於這些（“誰有……告訴…… .1”）arp請求，Linux伺服器會按照它應該的方式響應，並且入站連接工作得很好，即使在伺服器地址的任何痕跡失去很久之後從路由器arp記憶體。