Let's show small example. # route add 192.168.0.0/16 -iface lo0 -reject add net 192.168.0.0: gateway lo0 # route add 192.168.0.0/24 1.1.1.1 # over bge1 add net 192.168.0.0: gateway 1.1.1.1 # route add -host 192.168.0.0 -iface tun0 # or ng0 add host 192.168.0.0: gateway tun0 # route -n get -host 192.168.0.0 route to: 192.168.0.0 destination: 192.168.0.0 fib: 0 interface: tun0 flags: <UP,HOST,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 So far, so good. And now: # route -n get -net 192.168.0.0 route to: 192.168.0.0 destination: 192.168.0.0 fib: 0 interface: tun0 flags: <UP,HOST,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 Wrong. This is HOST route, it should skip it while looking up. This works just fine in 12.x and earlier showing another (non-host) route: # route -n get -net 192.168.0.0 route to: 192.168.0.0 destination: 192.168.0.0 mask: 255.255.0.0 fib: 0 interface: lo0 flags: <UP,REJECT,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0
(In reply to Eugene Grosbein from comment #0) ># route -n get -net 192.168.0.0 That's probably failing due to the removal of classful bits[1], please compare the bug 258874. route -n get -net 192.168.0.0/24 from your example works as intended on the recent stable/13. [1] https://cgit.freebsd.org/src/commit/sbin/route/route.c?id=d28210b2c2aaf3200907ed30d296b0d4856dd03c
The task is look up a route not knowing a mask beforehand and find the mask.
(In reply to Marek Zarychta from comment #1) > route -n get -net 192.168.0.0 At the very least, shouldn't it produce an error, rather than giving a host route when "-net" is specified?
(In reply to Eugene Grosbein from comment #2) > The task is look up a route not knowing a mask beforehand and find the mask. But did it ever work though? I'm sure that on 12.X and earlier, it's not actually finding the mask, it's just assuming you're looking for a /24. If you try creating (say) a /23 instead of a 24, you'll find the 'route -n get -net 192.168.0.0" doesn't return the /23, it instead fails. The confusion to me is that it now seems that "-net" / "-host" are redundant. - A "net" without a mask is now considered a host, not given the old pre-cidr default mask.