Поведение сопоставления самого длинного префикса при маршрутизации Windows
Описание
Я сталкиваюсь со сценарием, в котором не происходит совпадение самого длинного префикса.
Настраивать
На моей лабораторной машине у меня есть виртуальный сетевой адаптер VMnet11 (VMWare) с IP-адресом 181.0.0.10/8. У меня есть физический сетевой адаптер с IP-адресом 192.168.4.110/24, который направляет трафик на 192.168.4.84 в качестве шлюза по умолчанию (может получить доступ к Интернету).
Проблема
Хотя метрики те же (291), когда я пингую 181.0.0.1, трафик направляется через шлюз по умолчанию в Интернет (префикс 0.0.0.0 соответствует) вместо того, чтобы поток трафика пробовался через VMnet11. (Префикс 255.0.0.0 не совпадает)
Примечания При проверке связи с адресом 181.0.0.10 (локально назначенный IP-адрес VMnet11) наблюдается правильное поведение. (То есть префикс 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 (спасибо).
Теперь я подозреваю, что это (задуманная) проблема Microsoft (возврат к def gw при промахе ARP, что не является ожидаемым поведением маршрутизатора, поэтому парень с Reddit называет ОС Microsoft худшим маршрутизатором). Ниже приведены еще несколько выходных данных для ping и ARP.
Я ожидал, что это произойдет, когда я пропингую 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)