I'm not sure if this is a kernel bug, or what. A coworker installed a
system for use on a local net (that has no inter-network connetivity) but
for some reason entered an address for a default gateway. He used the
address that would be correct if that net had a route out, but since it
doesn't, there's no machine at that address.
So upon boot, 'route -n' shows a default route to an ip address that,
while valid, isn't in use.
For the sake of argument we'll say that the ip address of the system is
10.9.8.5 and that the default gateway (which doesn't exist) is set to
'route -n' shows this:
10.9.8.5 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
10.9.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.9.8.1 0.0.0.0 UG 1 0 0 eth0
But if a user tries to use the network, all hosts are unreachable. Indeed,
if the user attempts to ping the local address of "10.9.8.5" there is no
If the administrator manually removes the route, the network is still
If the administrator uses linuxconf to remove the configuration for the
route and then restarts the network, the network is then usable.
I admit it sounds strange but i have been able to reproduce the error
I'm not sure what the problem is here. There appear to be two issues:
1) Configuring a default route to a non-existent host breaks connectivity.
2) Deleting the default route by itself is not sufficient to reestablish
and you appear to have acceptable solutions for both issues.
Meanwhile, what appears to be happening is that there is an attempt to
send packets to the non-existent host through the default route even when
trying to ping the local host. This can be verified using tcpdump, but there
is little reason to devise a solution for having a default route to a
non-existent host (although such a solution probably exists).
Displaying the route table and interface configuration before/after
the administrator corrections should give you a hint about what linuxconf
is doing that the administrator is not.
Actually you're correct that with further examination this appears to be a
kernel bug. It's pretty nasty from my perspective - if the gateway becomes
unavailable (power cycle, momentary wiring change) all local networks are also
unavailable, which is pretty irrational and could serve as an effective DoS
(take out the gateway, shut down the network behind the gateway as well)
I'll report it to linux-net.