Score:-1

Server

Behavior of longest prefix matching in Windows routing

F.I.V

8/19/24, 4:49 AM

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)

1 + 10

ip-routing

windows-11

Greg Askew

8/19/24, 6:16 AM

What was the result of the arp for the address when you run a netmon packet capture?

djdomi

8/19/24, 9:14 AM

that's not uncommon to a subnet that is, route able by default global imho. since all are using the same metric it will not match a local target iirc

vidarlo

8/19/24, 9:24 AM

@djdomi Normally metric is not used; it's last resort. Routing decisions is made based on prefix length, where longest prefix wins, so the *most* specific route is preferred: A /24 over a /22, and a /8 over default (/0). Only if two routes are otherwise equal will metric be used.

djdomi

8/19/24, 9:27 AM

but the default gateway beat them up by default due a /0 match the complete address room at all so you need to increase the machnism of choosing imho

vidarlo

8/19/24, 10:19 AM

@djdomi No, *opposite*. Default gateway is *last* resort, as *every other prefix* will be longer. Default gateway has /0 as prefix, and longest prefix matching works by selecting the *longest* prefix, the one with most bits set to 1. /0 has 0 bits set to one. This is by design, and makes perfect sense if you think about it; many networks has 3-4 subnets, and a default route. If default route was the most preferred that would be an impossible setup. A /8 *should* win over a /0. This question is asking why that doesn't happen in one special case.

Greg Askew

8/19/24, 12:45 PM

Could be proxy arp somewhere. Not much detail on the VMware networking but it probably isn't a typical configuration.

Greg Askew

8/19/24, 5:32 PM

This thread in Reddit is similar. https://www.reddit.com/r/sysadmin/comments/11ztn6y/windows_server_2022_ignores_routing_table/

F.I.V

8/20/24, 7:32 AM

Thank you all, see the update section please.

Greg Askew

8/20/24, 11:29 AM

`such IP do not exist on my lab` that would be quick and easy to change for a test.

F.I.V

8/21/24, 5:06 AM

since I do not have that IP present, I want no host to reply. I want a timeout or unreachable indicator (instead am unknown internet host responding to my icmp request). Yes, if I add the host (hence arp resolves), the local area host would reply. But if the local area host gows down the foreign internet host takes its place

Score:2

Server

Andreas Rogge

8/23/24, 2:39 PM

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)

+ 1

F.I.V

8/24/24, 9:41 AM

Thanks, you already provided great clues. I found out that the referenced RFC is being obsoleted by 6724 (which core stack for newer versions of windows might probably use instead). Decision to provide feature-parity was a good clue as well. Following your provided info, I found that NCSI process in Windows also influences the address selection. Please allow me to wait a couple of more days to see other possible answers here as well. Thx

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Behavior of longest prefix matching in Windows routing

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.