Subject: Re: static route strangeness
To: Chris Hopps <chopps@allegronetworks.com>
From: Tad Hunt <tad@entrisphere.com>
List: tech-net
Date: 10/28/2002 17:08:57
Thanks for the pointer to gated(8).  It does everything I need.  Now
our software simply has to construct a gated.conf file and say
"gdc reconfig" whenever it changes.

The only thing it doesn't handle is the interface MTU changing,
but it does handle the interface going up and down, so as long as
I bring the interface down before changing the mtu, all of the
routes are maintained correctly.

WHOO!

-Tad

In message <B4DFCB7CDE2DD4118F690008C786941604D785A4@tahoe.allegronetworks.com>
, you said:
;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