Dado que estas rutas se encuentran en subredes diferentes, aquí interviene más que solo la métrica. Si el tráfico de origen se encuentra en la subred 192.168.1.1, por ejemplo, y hay una ruta coincidente no predeterminada en su tabla de enrutamiento, esa ruta coincidirá con la coincidencia de prefijo más larga antes de que se considere la métrica.
Suponiendo que una ruta no predeterminada no coincide, el núcleo debe interpretar que no tener métrica tiene una métrica de 0 y, por lo tanto, la ruta de mayor prioridad. Aunque esa es una vista simplista porque algunos demonios de enrutamiento luego traducirán esa métrica predeterminada a otro valor como 1024. Espero que esto sea lo que te está sucediendo a ti y a tu distribución sin nombre.
Si ip routeno muestra ninguna métrica, puede confirmar que efectivamente es 0 utilizando el route -ncomando anterior del paquete net-tools o cat /proc/net/route. Sin embargo, esta salida no necesariamente coincide con lo que el demonio de enrutamiento usará internamente cuando encuentra un valor métrico 0.
Además, la forma de crear la ruta también es importante. ip routeusa la API de netlink, mientras que routeusa ioctl. El código de cómo se crean las métricas predeterminadas entre los dos enfoques da como resultado valores de métricas diferentes. Por ejemplo: la creación de una ruta predeterminada de IPv6 ip routegenerará un valor métrico de 1024 en RHEL 7, mientras que la creación de la misma ruta routegenerará una métrica de 1.
De RedHat :
- si no se pasa nada al comando de ruta como métrica de ruta, el comando en sí usa el valor de 1.
- Si no se pasa nada al comando ip como métrica de ruta, el atributo no se crea en absoluto y el núcleo lo entiende como 0, que luego se traduce 1024 como predeterminado.