[lug] Linux Router Experimenting...Where is Metric Set?
stimits at comcast.net
stimits at comcast.net
Sat Nov 28 13:14:27 MST 2015
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?
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LUG