Como essas rotas estão em sub-redes diferentes, há mais envolvimento aqui do que apenas a métrica. Se o tráfego de origem estiver na sub-rede 192.168.1.1, por exemplo, e houver uma rota não padrão correspondente em sua tabela de roteamento, essa rota corresponderá pela correspondência de prefixo mais longa antes que a métrica seja considerada.
Supondo que uma rota não padrão não corresponda, a ausência de métrica deve ser interpretada pelo kernel como tendo uma métrica 0 e, portanto, a rota de maior prioridade. Embora essa seja uma visão simplista, porque alguns daemons de roteamento posteriormente converterão essa métrica padrão em outro valor como 1024. Espero que seja isso o que está acontecendo com você e sua distribuição não identificada.
Se ip routenão mostrar nenhuma métrica, você poderá confirmar que é realmente 0 usando o route -ncomando mais antigo do pacote net-tools ou cat /proc/net/route. No entanto, essa saída não corresponde necessariamente ao que o daemon de roteamento usará internamente quando encontrar um valor métrico 0.
Além disso, como você cria a rota também importa. ip routeusa a API netlink, enquanto routeusa ioctl. O código de como as métricas padrão são criadas entre as duas abordagens resulta em diferentes valores de métricas. Por exemplo: criar uma rota padrão IPv6 via ip routeresultará em um valor de métrica de 1024 no RHEL 7, enquanto criar a mesma rota via routeresultará em uma métrica de 1.
De RedHat :
- se nada for passado para o comando route como métrica da rota, o valor 1 será usado pelo próprio comando.
- Se nada for passado para o comando ip como métrica de rota, o atributo não será criado e o kernel o entenderá como 0, que será traduzido posteriormente 1024 como padrão.