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)