網絡之間的套接字連接超時有所不同

我有一個相當有趣的問題。我們有兩個工作中的網絡彼此物理重複（網絡A和網絡B）。他們只是在不同的子網上運行。網絡之間的套接字連接超時有所不同

我正在爲我們在網絡上相互集羣的設備進行一些容錯改進。我正在練習的一個測試案例是引入錯誤配置時這些設備的行爲。例如，可以說我有以下接口配置了兩種設備：

設備X IP：10.200.234.127 子網掩碼：255.255.254.0 默認網關：10.200.234.1

元件Y IP：10.200.234.127 子網掩碼：255.255.254.0 默認網關：10.200.234.1

這些2個設備經由簇H的廣播發現彼此eartbeats。心跳包含設備IP地址等，這使得它們可以建立彼此的通信。相當標準的東西。現在，可以說我這樣介紹，這些設備中的一個被配置爲一個不同的sunbet網絡配置錯誤：

設備X IP：192.168.1.115 子網掩碼：255.255.255.0 默認網關：192.168.1.1

這裏發生的是兩臺設備仍然從集羣廣播中相互瞭解（它們在同一交換機上物理連接在一起）。但是，正如您所期望的那樣，他們無法按預期相互溝通。但是，當這些設備試圖彼此通信時，我發現連接超時方面存在一些奇怪的行爲。例如，如果設備連接在網絡A上，則連接嘗試在幾秒鐘內超時，這很好。現在，如果我將兩臺設備放在網絡B上，我會看到完全不同的行爲。在網絡B上，connect（）調用在設備之間建立套接字連接不會很快失敗。相反，它們落入這種退避和重新傳輸循環中，最終放棄需要189秒（在經Wirehark驗證的3,6,12,24,48和96秒時重新傳輸）。

所以我想知道的是爲什麼connect（）調用在網絡A中失敗如此之快，而不是在網絡B中。我嘗試過使用阻塞套接字和調用connect（）以及非阻塞套接字並調用connect（），然後調用select（）。在這兩種情況下，我都無法讓連接放棄189秒。我知道我可以在呼叫中加入更短的暫停，以便儘早選擇並放棄，但這不是重點。我試圖理解這兩個網絡導致此問題的可能不同之處。

來源

2011-10-25 Chappelle

防火牆可能會拒絕TCP段而不回覆任何內容，以便主機連接將繼續嘗試... –

嗯...在網絡A的情況下，當立即發生超時時，實際上看不到任何數據包離開設備。所以也許問題是爲什麼在網絡A中，我在網絡B上沒有看到任何數據包，我呢？ – Chappelle

也許你應該給更多的地址？目前尚不清楚知識產權是什麼。

我的猜測是：

在緩慢的情況下，你得到ARP故障（不響應，因爲目標有不正確的網絡掩碼）
在快速的情況下你得到一個路由故障。如果主機有一個不正確的較小的網絡掩碼，它甚至不會嘗試ARP。

請嘗試對阻塞套接字進行分隔，錯誤代碼應該不同。

來源

2011-10-25 18:17:28 cdleonard

謝謝你慢慢記住事情的arp一面。我甚至沒有想到，實際上我的10.200.234.0/16網絡中可能有一臺設備，它具有IP 192.168.1.1，這是我選擇的靜態設備配置的網關IP。同樣，這個想法是選擇一個完全失敗的配置。但是，一旦我捕獲了所有的arp數據包，立即就會發現某些frickin設備在IP 192.168.1.1的網絡上。所以這是所有超時麻煩的根源。再次感謝cdleonard。 – Chappelle

網絡之間的套接字連接超時有所不同

回答

相關問題