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