Behavior of longest prefix matching in Windows routing

Question

Description

I face a scenario in which longest prefix matching does not occur.

Setup

On my lab machine, I have a virtual nic VMnet11 (VMWare) with the ip address 181.0.0.10/8. I have a physical nic with ip address 192.168.4.110/24 that routes traffic to 192.168.4.84 as the default gateway (can access the internet).

Issue

Although the metrics are the same (291), when I ping 181.0.0.1, the traffic is routed via the default gateway to the internet (0.0.0.0 prefix is matched) instead of the traffic flow being tried via VMnet11. (The 255.0.0.0 prefix is not matched)

Notes When pinging the 181.0.0.10 (the locally assigned IPto VMnet11), the correct behavior is observed. (That is 255.255.255.255 prefix is matched on local interface)

Outputs

Here are relevant parts of the 'route print':

===========================================================================
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
===========================================================================

Here is the relevant output of the '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 . . . . . . . . . :

Here is the relevant output of the '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>
  ...

Question

What prevents the longest prefix matching from occurring?

Update

The reddit link was informative (thanks). Also mentioning ARP was useful (thanks).

I now suspect that it is a Microsoft's (by-design) issue (reverting to def gw on ARP miss that is not a router's expected behavior, hence why the reddit guy calls Microsoft's OS the worse router). Below find some more outputs for ping and ARP.

This is something that I expected that happens when I 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.

But this is the unwanted behavior that happens when pining 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

There is no arp entry

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.

(apparently such IP do not exist on my lab network, and I expected else than a echo reply via icmp responses)

Answer 1

Since the IP stack was rewritten in Vista to provide feature-parity between IPv4 and IPv6, Windows uses RFC 3484 for both IPv4 and IPv6.

The problem you're seeing here is probably due to source address selection. As you don't provide a source address yourself, the system needs to choose one. In IPv4 this should always select the address matching the interface belonging to the route determined from the longest-prefix-match. However, in RFC 3484 near the end of section 5 ("Source Address Selection") there is the following paragraph:

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.

(Rule 8 is longest prefix match)

As neighbor discovery (or ARP as we say in IPv4) failed for the destination address the router knows that direct contact will fail. Thus the default route is the best match and the address of its associated interface will be used as source address.

In your case, if you provide the source address to ping using -s, that should overrule the source address selection and thus the default route should not be tried.

(I'm sorry that I have almost no references, but as that change happended about 15 years ago it is hard to find articles of reasonable credibility)