主页 / server / 问题 / 1141927
Accepted
F.I.V
Asked: 2023-08-19 12:49:56 +0800 CST

Windows 路由中最长前缀匹配的行为

  • 772

描述

我面临着不发生最长前缀匹配的情况。

设置

在我的实验室机器上，我有一个虚拟网卡 VMnet11 (VMWare)，IP 地址为 181.0.0.10/8。我有一个 IP 地址为 192.168.4.110/24 的物理网卡，它将流量路由到 192.168.4.84 作为默认网关（可以访问互联网）。

问题

尽管指标相同 (291)，但当我 ping 181.0.0.1 时，流量通过默认网关路由到互联网（匹配 0.0.0.0 前缀），而不是通过 VMnet11 尝试流量。（255.0.0.0前缀不匹配）

注意 当 ping 181.0.0.10（本地分配给 VMnet11 的 IP）时，会观察到正确的行为。（即本地接口上匹配255.255.255.255前缀）

输出

以下是“路线打印”的相关部分：

===========================================================================
Interface List
 26...00 e0 4c 62 16 05 ......Realtek RTL8139/810x Family Fast Ethernet NIC
  7...00 50 56 c0 00 0b ......VMware Virtual Ethernet Adapter for VMnet11

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.4.84    192.168.4.110    291
        181.0.0.0        255.0.0.0         On-link        181.0.0.10    291
       181.0.0.10  255.255.255.255         On-link        181.0.0.10    291
  255.255.255.255  255.255.255.255         On-link        181.0.0.10    291

===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0     192.168.4.84  Default
===========================================================================

这是“ipconfig”的相关输出：

C:\Users\user>ipconfig
Ethernet adapter PCI:

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 192.168.4.110
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.4.84

Ethernet adapter VMware Network Adapter VMnet11:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::a2e7:a501:ffd5:ccac%7
   IPv4 Address. . . . . . . . . . . : 181.0.0.10
   Subnet Mask . . . . . . . . . . . : 255.0.0.0
   Default Gateway . . . . . . . . . :

这是“traceroute”的相关输出：

C:\Users\user>tracert -d  181.0.0.1

Tracing route to 181.0.0.1 over a maximum of 30 hops

  1    <1 ms     1 ms    <1 ms  192.168.4.84
  2     1 ms     1 ms    <1 ms  <public ip>
  ...

问题

是什么阻止了最长前缀匹配的发生？

更新

Reddit 链接提供了丰富的信息（谢谢）。另外提到 ARP 很有用（谢谢）。

我现在怀疑这是微软的（设计）问题（在 ARP 未命中时恢复到 def gw 这不是路由器的预期行为，因此为什么 reddit 的人称微​​软的操作系统是更糟糕的路由器）。下面是 ping 和 ARP 的更多输出。

这是我期望在 ping 181.0.0.2 时发生的事情

C:\Users\user>ping 181.0.0.2

Pinging 181.0.0.2 with 32 bytes of data:
Reply from 181.0.0.10: Destination host unreachable.
Request timed out.
Request timed out.

但这是固定 181.0.0.1 时发生的不良行为：

C:\Users\user>ping 181.0.0.1

Pinging 181.0.0.1 with 32 bytes of data:
Reply from 181.0.0.1: bytes=32 time=478ms TTL=43
Reply from 181.0.0.1: bytes=32 time=454ms TTL=43

没有arp条目

C:\Users\user>arp -a 181.0.0.1
No ARP Entries Found.

C:\Users\user>arp -a 181.0.0.2
No ARP Entries Found.

（显然我的实验室网络上不存在这样的 IP，我期望的不是通过 icmp 响应的回显回复）

ip-routing

1 个回答

  1. Best Answer

    由于 IP 堆栈在 Vista 中被重写以提供 IPv4 和 IPv6 之间的功能对等，因此 Windows 对 IPv4 和 IPv6 使用 RFC 3484。

    您在这里看到的问题可能是由于源地址选择造成的。由于您自己不提供源地址，系统需要选择一个。在 IPv4 中，应始终选择与属于从最长前缀匹配确定的路由的接口相匹配的地址。然而，在 RFC 3484 第 5 节（“源地址选择”）末尾附近有以下段落：

    Rule 8 may be superseded if the implementation has other means of
choosing among source addresses.  For example, if the implementation
somehow knows which source address will result in the "best"
communications performance.

    （规则8是最长前缀匹配）

    由于目标地址的邻居发现（或 IPv4 中所说的 ARP）失败，路由器知道直接联系将会失败。因此，默认路由是最佳匹配，并且其关联接口的地址将用作源地址。

    ping在您的情况下，如果您向using提供源地址-s，则应否决源地址选择，因此不应尝试默认路由。

    （很抱歉，我几乎没有参考资料，但由于这种变化发生在大约 15 年前，很难找到具有合理可信度的文章）

    • 2

相关问题