Subject: RE: static route strangeness
To: 'Tad Hunt' <firstname.lastname@example.org>
From: Chris Hopps <email@example.com>
Date: 10/27/2002 00:23:28
3) It sounds like you're looking for a routing daemon. I know, for example,
that GateD properly maintains static routes, and updates them based on
changes to interface. Perhaps zebra also supports static routes in a similar
I'm not sure if GateD would flush and re-add routes if the only thing that
changed was an interface's MTU.
From: Tad Hunt [mailto:firstname.lastname@example.org]
Sent: Saturday, October 26, 2002 8:29 PM
To: email@example.com; firstname.lastname@example.org
Subject: static route strangeness
I've recently encountered some problems attempting to maintain a
some static routes.
Specifically, it appears as though NetBSD computes the interface
and MTU used to reach the gateway at the time the static route is
entered into the routing table. This information appears to be
stored in the routing table along with the destination, mask, and
gateway (netstat -nr).
Furthermore, it appears as though bringing a new interface up, or
modifying the MTU of an existing interface doesn't cause any existing
routes to be updated with the new information.
ifconfig fxp0 192.168.1.1 netmask 0xffffff00 up
route add -net 192.168.10.0 192.168.2.2
ifconfig fxp1 192.168.2.1 netmask 0xffffff00 up
After bringing the second interface up, I would have expected the
routing table entry for 192.168.10.2 to become associated with
fxp1. Instead, netstat(1) shows that it is still associated with
This behavior makes interface and routing table management extremely
difficult because it effectively requires the routing table to be
flushed and reconstructed every time an interface is brought up or
down, or the MTU changes.
I believe that the correct behavior is to update the routing table
whenever an interface address, netmask, or MTU is modified.
I have a some questions:
1) Is there some way to configure my system such that the routing table
will automatically be updated?
2) Is there a specific reason that the routing table behaves the way
I described, or is this a problem that nobody has attacked yet?
3) Does anyone have any other suggestions on how to maintain the
routing table when faced with interface changes over time?