Since these routes are on different subnets, there's more involved here than just the metric. If originating traffic is on the 192.168.1.1 subnet, for instance, and there is a matching non-default route in your routing table, then that route will match via longest prefix match before the metric is ever considered.
Assuming a non-default route is not matching, then having no metric should be interpreted by the kernel as having a metric of 0, and therefore the highest priority route. Although that's a simplistic view because some routing daemons will later translate that default metric into another value like 1024. I expect this is what is happening to you and your unnamed distro.
ip route shows no metric at all, you can confirm that it is indeed 0 by using the older
route -n command from the net-tools package or
cat /proc/net/route. However, this output doesn't necessarily match what the routing daemon will use internally when it encounters a 0 metric value.
Furthermore how you create the route matters too.
ip route uses the netlink API, while
route uses ioctl. The code for how default metrics are created between the two approaches result in different metric values. For instance: creating an IPv6 default route via
ip route will result in a metric value of 1024 on RHEL 7, while creating the same route via
route will result in a metric of 1.
- if nothing is passed to the route command as route metric the value of 1 is used by the command itself.
- If nothing is passed to the ip command as route metric the attribute is not created at all and kernel understands to it as 0, which is later translated 1024 as default.