我所在的公司制造和销售工业机器。我们的产品之一是一台由运行 Windows 的 PC 控制的机器。这台机器使用联网设备，该设备连接有数字输入和输出。我们的软件通过以太网发送命令来读取和写入此设备上的 I/O 点的值。该设备使用 UDP 协议进行通信。
我们使用的 PC 通常有两块或多块网卡 (NIC)。我们将其中一块 NIC 命名为 Machine LAN，并为其分配一个私有地址 192.168.1.49/24。I/O 设备的 IP 地址为 192.168.1.11/24、192.168.1.12/24 等。
第二个 NIC 可连接到工厂（客户）的通用网络，称为工厂 LAN。这通常配置为 DHCP 寻址。
我们的应用程序配置了 I/O 设备的 IP 地址，因此会为该地址生成 UDP 流量。在正常情况下，我可以使用 Wireshark 监控此流量，并看到 UDP 数据包通过 Machine LAN 接口来回流向设备的 IP 地址。我还可以 ping I/O 设备，并通过 Machine LAN 接口观察 ICMP 数据包在 PC 和 I/O 设备之间来回反弹。
因为这是一个工业应用程序，我们希望确保一切都尽可能地稳健，并且我们的应用程序可以从网络故障等情况中恢复。为此，我在我们的制造工厂进行测试，我将 I/O 设备与网络断开连接，监控我们的应用程序的行为，然后重新连接 I/O 设备并确保应用程序再次开始与设备通信。有时一切都会恢复，有时则不会。在我看来，有时进行此测试会导致 Windows 开始通过 Mill LAN 接口而不是 Machine LAN 接口发送 192.168.1.11 地址的流量。发生这种情况时，I/O 设备显然没有响应，应用程序无法与设备交互。我研究了 PC 的网络配置和路由表，并花了很多时间在互联网上搜索想法，但我无法找出这种行为的原因。
通过使用 Wireshark 观察流量，我已确认 Windows 正在向 Mill LAN 接口发送 IP 流量，而不是向 Machine LAN 接口发送流量。我可以通过我的应用程序生成的 UDP 数据包和 ping.exe 生成的 ICMP 数据包观察到这一点，因此我得出结论，问题出在我们的应用程序之外。
我尝试过的方法之一是操纵路由指标（接口和网关指标），试图强迫 Windows 使用 Machine LAN 接口。这似乎没有帮助。您将在下面的配置列表中看到这些调整/夸大的指标。
当出现症状时，如果我明确告诉 ping.exe 使用哪个接口，我仍然可以成功 ping I/O 设备：
C:\>ping -S 192.168.1.49 192.168.1.11
Pinging 192.168.1.11 from 192.168.1.49 with 32 bytes of data:
Reply from 192.168.1.11: bytes=32 time=6ms TTL=16
Reply from 192.168.1.11: bytes=32 time=7ms TTL=16
Reply from 192.168.1.11: bytes=32 time=7ms TTL=16
Reply from 192.168.1.11: bytes=32 time=7ms TTL=16
Ping statistics for 192.168.1.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 6ms, Maximum = 7ms, Average = 6ms
有时这种症状会在短时间后自行消失，但通常会持续很长时间（我认为是无限期）。我也可以通过禁用 Mill LAN 接口来消除这种症状；这很有意义，因为 Windows 现在只有一个接口来路由所有流量。我也可以通过删除 I/O 设备的 ARP 条目来消除这种症状（我不知道为什么这样做有效）：
C:\>arp -d 192.168.1.11
当症状出现时，我仍然可以 ping 机器 LAN 上的其他设备，因此通过适当接口路由数据包似乎总体上是有效的（只是不适用于某个特定地址）。无论这种现象是什么，它似乎都与单个 IP 地址有关。由于删除该地址的 ARP 记录会使症状消失，我怀疑某些东西与 ARP 有关，但我并不确定。
似乎在症状发生时，192.168.1.11 的 ARP 条目消失了。在症状开始之前，有一个条目（具有正确的 MAC 地址）：
C:\>arp -a | findstr 192.168.1.11
192.168.1.11 00-50-8e-00-26-e2 dynamic
引发症状后，条目消失：
C:\>arp -a | findstr 192.168.1.11
C:\>
无论出于什么原因，删除不存在的 ARP 条目似乎可以恢复通信。
另外观察一下：我监控了连续 ping 的输出（ping -t 192.168.1.11）。下面是一个例子，我可以拔掉电缆几秒钟，再重新插入，ping 就可以恢复通话：
Reply from 192.168.1.11: bytes=32 time=9ms TTL=16
Reply from 192.168.1.11: bytes=32 time=6ms TTL=16
Request timed out.
Request timed out.
Reply from 192.168.1.11: bytes=32 time=2005ms TTL=16
Reply from 192.168.1.11: bytes=32 time=6ms TTL=16
Reply from 192.168.1.11: bytes=32 time=6ms TTL=16
似乎当症状开始出现（通信无法恢复）时，我看到了“目标主机不可达”消息：
Reply from 192.168.1.11: bytes=32 time=9ms TTL=16
Reply from 192.168.1.11: bytes=32 time=6ms TTL=16
Request timed out.
Request timed out.
Reply from 192.168.1.49: Destination host unreachable.
Request timed out.
Request timed out.
我不能 100% 确定情况总是如此。
以下是接口（请注意我手动分配的指标）：
C:\>netsh interface ip show config
Configuration for interface "Machine LAN"
DHCP enabled: No
IP Address: 192.168.1.49
Subnet Prefix: 192.168.1.0/24 (mask 255.255.255.0)
Default Gateway: 0.0.0.0
Gateway Metric: 1
InterfaceMetric: 1
Statically Configured DNS Servers: None
Register with which suffix: Primary only
Statically Configured WINS Servers: None
Configuration for interface "Mill LAN"
DHCP enabled: Yes
IP Address: ***.16.1.31
Subnet Prefix: ***.16.0.0/20 (mask 255.255.240.0)
Default Gateway: ***.16.0.58
Gateway Metric: 500
InterfaceMetric: 500
DNS servers configured through DHCP: ***.16.6.20
***.16.16.131
Register with which suffix: Primary only
WINS servers configured through DHCP: ***.16.6.20
***.16.16.131
Configuration for interface "Loopback Pseudo-Interface 1"
DHCP enabled: No
IP Address: 127.0.0.1
Subnet Prefix: 127.0.0.0/8 (mask 255.0.0.0)
InterfaceMetric: 50
Statically Configured DNS Servers: None
Register with which suffix: None
Statically Configured WINS Servers: None
以下是路由表（由 netsh 和 route 命令呈现）：
C:\>netsh int ip show route
Publish Type Met Prefix Idx Gateway/Interface Name
------- -------- --- ------------------------ --- ------------------------
No Manual 100 0.0.0.0/0 3 ***.16.0.58
No Manual 1 0.0.0.0/0 4 Machine LAN
No System 256 ***.16.0.0/20 3 Mill LAN
No System 256 ***.16.1.31/32 3 Mill LAN
No System 256 ***.16.15.255/32 3 Mill LAN
No Manual 1 192.168.1.0/24 4 Machine LAN
No System 256 192.168.1.49/32 4 Machine LAN
No System 256 192.168.1.255/32 4 Machine LAN
No System 256 224.0.0.0/4 3 Mill LAN
No System 256 224.0.0.0/4 4 Machine LAN
No System 256 255.255.255.255/32 3 Mill LAN
No System 256 255.255.255.255/32 4 Machine LAN
C:\>route print
===========================================================================
Interface List
4...00 40 05 10 4e 9c ......D-Link DFE-530TX+ PCI Adapter
3...00 1a a0 e8 72 59 ......Intel(R) 82566DM-2 Gigabit Network Connection
1...........................Software Loopback Interface 1
5...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
7...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 ***.16.0.58 ***.16.1.31 600
0.0.0.0 0.0.0.0 On-link 192.168.1.49 2
***.16.0.0 255.255.240.0 On-link ***.16.1.31 756
***.16.1.31 255.255.255.255 On-link ***.16.1.31 756
***.16.15.255 255.255.255.255 On-link ***.16.1.31 756
192.168.1.0 255.255.255.0 On-link 192.168.1.49 2
192.168.1.49 255.255.255.255 On-link 192.168.1.49 257
192.168.1.255 255.255.255.255 On-link 192.168.1.49 257
224.0.0.0 240.0.0.0 On-link ***.16.1.31 756
224.0.0.0 240.0.0.0 On-link 192.168.1.49 257
255.255.255.255 255.255.255.255 On-link ***.16.1.31 756
255.255.255.255 255.255.255.255 On-link 192.168.1.49 257
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 192.168.1.49 1
===========================================================================
尽管我只使用 Wireshark 观察了 Windows 8 上通过错误接口的流量，但我在 XP、Windows 7 和 Windows 8 PC 上也看到了相同的症状。
告白時間：机器局域网上没有任何节点的地址为 192.168.1.1，但我通过 Mill 局域网接口从该地址获得 ping 响应。Mill 局域网上的某个地方（或可从该地方访问）有该地址。以下 tracert 显示它仅一跳之遥，可能位于我公司的内部网络上：
C:\>tracert 192.168.1.1
Tracing route to 192.168.1.1 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms ***.16.0.58
2 12 ms 47 ms 24 ms 192.168.1.1
Trace complete.
我认为这个 192.168.1.1 设备的存在可能构成了错误配置的网络，我应该调查为什么我的 PC 可以看到它（我不认为这些私有地址应该是可路由的）。无论如何，我想弄清楚如何让事情按原样工作，因为根据我的经验，地址为 192.168.1.* 的设备偶尔会出现在客户站点（在 Mill LAN 上），我希望即使出现这种情况，我们的系统也能继续工作。换句话说，我希望我的 PC 只使用 Machine LAN 接口来处理带有 192 地址的流量。如果有人知道我该如何实现这一点，我很乐意听听他们的想法！
答案1
我首先要说的是，这个问题最好在 Superuser 或 Serverfault 上回答，但我想解决你会遇到的一个战略问题：
您已选择使用 192.168.0.0 作为“私有”LAN。不幸的是，您选择了最常用的私有网络地址，并且您很可能经常遇到地址冲突——您似乎在这里就遇到了这种情况。
192.168.0.0 地址无法路由的说法并不正确。它们可以，而且在公司网络内始终被路由。但是，它们无法通过 Internet 路由。您可能正在考虑“链接本地”网络 169.254.0.0/16。该网络根本不（应该）被路由，因此您不会遇到正在经历的地址冲突。
您应该使用 169.254.0.0/16 地址范围内的地址。从该范围中选择一个适合您拥有的设备数量的小子网（例如. 169.254.55.64/28（适用于少于 10 个 I/O 设备）。
答案2
两个词：路由缓存
UDP 是无状态的，因此系统将建立一个“连接”来赋予它状态。只要您继续发送数据包，该连接的缓存就会保持有效。因此，当 Machine LAN 断开连接时，您的流量将默认为 Mill LAN。在错误的路由缓存过期（由于不活动）之前，应用程序将无法工作。
有两种方法可以解决这个问题：1）向您的应用程序添加代码以直接绑定正确的接口，和/或2）添加防火墙规则以防止 192.168.1.0/24 使用 Mill LAN 接口。
（正如@Ron 指出的那样，192.168.1.0/24 是一个非常糟糕的网络选择。）
注意
netsh interface ip show destinationcache：
netsh interface ip delete destinationcache
此外，机器 LAN 永远不应是您的默认网关，并且其度量永远不应为“1”。