Hi Tom,
i think i am able to reproduce your problem on -current:
# sh /etc/netstart em0
# route -n show -inet
default 192.168.2.1 UGS 0 0 - 8 em0
192.168.2/24 192.168.2.100 UCn 1 0 - 4 em0
192.168.2.1 link#1 UHLch 1 2 - 3 em0
[...]
# route add 192.168.2.0/25 192.168.2.1
add net 192.168.2.0/25: gateway 192.168.2.1
# route -n show -inet | grep /25
192.168.2.0/25 192.168.2.1 UGS 0 0 - 8 em0
# route delete 192.168.2/24
delete net 192.168.2/24
# route add 192.168.2/24 -iface -cloning -nostatic 192.168.2.100
add net 192.168.2/24: gateway 192.168.2.100
# route -n show -inet|grep /2
192.168.2/24 192.168.2.100 UC 0 0 - 56 em0
192.168.2.0/25 192.168.2.1 UGS 0 0 - 8 em0
That is very similar to what you have, see the quote from your
posting at the very end.
Now ping 192.168.2.1 doesn't work because
(1) there is no specific route to 192.168.2.1/32
(2) the closest matching route is to 192.168.2.0/25
(3) but that is a *gateway* route via 192.168.2.1, which doesn't
help because how to get to 192.168.2.1 is exactly what we are
trying to figure out...
I can make it work as follows, continuing the previous example:
# route add 192.168.2.1 -iface -cloning 192.168.2.100
add host 192.168.2.1: gateway 192.168.2.100
# route -n show -inet | grep UHCS
192.168.2.1 192.168.2.100 UHCS 0 0 - 8 em0
# ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=0.651 ms
# route delete default
delete net default
# route add default 192.168.2.1
add net default: gateway 192.168.2.1
# route -n show -inet
default 192.168.2.1 UGS 1 1 - 8 em0
192.168.2/24 192.168.2.100 UC 0 0 - 56 em0
192.168.2.0/25 192.168.2.1 UGS 0 165 - 8 em0
192.168.2.1 74:31:70:fd:f0:12 UHLch 1 4 - 7 em0
192.168.2.1 192.168.2.100 UHCS 1 0 - 8 em0
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=34.990 ms
Like that, we *also* have a specific route to the gateway,
given that the closest matching route is unusable for the purpose.
Note the "h" flag on the 192.168.2.1 UHLch route. That's because
i added the default route after the route to the gateway.
The other way round, the "h" would be missing and it wouldn't work.
So what you are doing seems fragile to me. It may sometimes work
due to order of configuration, timeouts, whatever, i'm not sure.
But once part of it gets broken for whatever reason, i don't see
how it could possibly automatically recover via the normal RTF_CLONING
mechanism.
If you must have a static route to a subnet that includes the
gateway address (5.134.92.1), thus defeating the purpose of the
RTF_CLONING flag on the 5.134.92/22 route, it would seem safest
to me to manually add the following route *before* adding the
default route:
# route add 5.134.92.1 -iface -cloning 5.134.92.142
# route add default 5.134.92.1
Take all this with a grain of salt, even though i committed to
the route(8) program lately, i'm not at all an expert on it.
Yours,
Ingo
P.S.
Your setup seems weird and is likely still fragile even with the
above improvement. Having gateway routes for hosts in directly
attached networks is very unusual indeed, to wit:
Tom Smyth wrote on Tue, May 01, 2018 at 07:05:39AM +0100:
> The only (unusual network config) im using is that im deploying
> more specific static routes (than the connected route) to allow
> clients on a non broadcast network to route to each other
> ie if a client wants to talk to another client send packet to
> default gateway (icmp redirects are off on the gateway)
>
> #ifconfig em0
> inet 5.134.92.142 netmask 0xfffffc00 broadcast 5.134.95.255
>
> # route -n -T0 show
> 5.134.92/22 5.134.92.142 UC 0 0 - 4 em0
> 5.134.92/23 5.134.92.1 UGS 0 80897 - 8 em0
