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
way.

I'm not sure if GateD would flush and re-add routes if the only thing that
changed was an interface's MTU.

Chris.

-----Original Message-----
From: Tad Hunt [mailto:tad@entrisphere.com]
Sent: Saturday, October 26, 2002 8:29 PM
To: tech-kern@netbsd.org; tech-net@netbsd.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.

For example:

	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
fxp0.

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?

-Tad