我有一个相当有趣的问题。我们有2个工作网络，它们是彼此的物理副本（网络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
这两个设备通过群集心跳的广播相互发现。心跳包含设备IP地址等，这使得它们可以相互建立通信。很标准的东西。现在，假设我引入了一个网络配置错误，以便其中一个设备配置为不同的sunbet：
设备X IP：192.168.1.115 子网掩码：255.255.255.0 默认网关：192.168.1.1
这里发生的是两个设备仍然从群集广播中了解彼此（它们在同一个交换机上物理连接在一起）。但是，正如您所料，他们无法按预期相互通信。但是，当这些设备尝试相互通信时，我看到一些关于连接超时的奇怪行为。例如，如果设备连接在网络A上，则连接会在几秒钟内尝试超时，这很好。现在，如果我将两个设备都放在网络B上，我会看到完全不同的行为。在网络B上，connect（）调用在设备之间建立套接字连接不会很快失败。相反，他们陷入这种退避和重新传输周期需要189秒才能最终放弃（通过wireshark验证，在3,6,12,24,48和96秒重新传输）。
所以我想知道的是，为什么connect（）调用在网络A中而不是在网络B中如此迅速地失败。我尝试使用阻塞套接字和调用connect（）以及非阻塞套接字和调用connect（）后调用select（）。在这两种情况下，我都无法让连接放弃任何超过189秒的时间。我知道我可以在调用中强加一个较短的超时选择并尽快放弃，但这不是重点。我试图了解造成这个问题的这两个网络可能有什么不同。
答案 0 :(得分：0)
也许你应该提供更多地址？目前还不清楚究竟是什么IP。
我的猜测是：
请尝试strace阻塞套接字，错误代码应该不同。