[lug] Linux Router Experimenting...Where is Metric Set?

[stimits at comcast.net]

Replying to my own message, my research found that the reason why metric was "1" (instead of "0"...the reason routing fails and requires manually resetting metric) is due to Ubuntu incorrectly using IPv6 settings on IPv4. I know this is incorrect because my dhcpd is only IPv4, and the client receiving the address has all IPv6 disabled in /proc. Addresses and routes show as IPv4, but I think short of literally removing the non-module support of IPv6 in the Ubuntu kernel, or getting a bug fix, the metric will be forced to "1". Sadly, the only non-kernel-recompile-without-IPv6 solution seems to create an rc.local script to manually remove the route metric and put into place an IPv4 version...which kind of defeats the purpose of DHCP, so I think I need to abandon that router project (at least if it is based on unmodified Ubuntu).
 
----- Original Message -----From: stimits at comcast.netTo: BLUG <lug at lug.boulder.co.us>Sent: Thu, 26 Nov 2015 02:20:24 -0000 (UTC)Subject: [lug] Linux Router Experimenting...Where is Metric Set?

Hi,
 
So I'm experimenting with using Linux for a router instead of buying something off the shelf. Something I ran into that I'm not quite sure of where to "fix" is the route metric. On this same private network hosts I created statically have a metric of "0" for the 192.168.x.x subnet, while those picking up the same information via DHCP have a metric of "1". This is causing forwarding to fail unless I manually set metric back to "0", which kind of defeats the purpose of DHCP automation. Here's an example:
# routeKernel IP routing tableDestination     Gateway         Genmask         Flags Metric Ref    Use Ifacedefault         myrouter        0.0.0.0         UG    0      0        0 eth0192.168.2.0     *               255.255.255.0   U     1      0        0 eth0 
My question is whether the DHCP server should be sending something to get this metric to be 0, or if the dhcp client should be configured to do this...or if perhaps technically speaking this should be automatic and never messed with? Perhaps it is a case of needing "default" to instead use a metric of "1" to match 192.168.2.0/24 subnet metric?
 
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20151128/d2c9352a/attachment.html>