I asked about default routes installed by rc.local disppearing on me,
and I got lots of useful responses. The core of my query:
> While conducting some tests in preparation for splitting up a large
> subnet, I've found default routes that were installed on boot by
> rc.local disappearing on me. I don't have enough examples to be sure,
> but it seems to be that the routes disappear only if they're not used
> for some time, like several days.
> After we're on our own subnet, we'll only need the default route, but
> until then we can reach several gateways directly, so we run routed.
> Can that cause a static route to be flushed?
Yes it can. More to the point, it *will*, unless you take certain
precautions. There are actually two problems, one more or less
documented and one not.
First, as noted in the man page for routed, routed expects to exchange
routing information with gateways it knows about and will delete
routes through them if it doesn't hear from them "for a period of
time". To prevent this, you declare the gateway to be "passive" with
a /etc/gateways entry. Mine now looks like this:
net default gateway crdrtr01 metric 1 passive
(I had read the routed man page - or rather, I had skimmed it, since I
had been through it in detail long ago. Either my memory is deficient
or things have changed rather a lot in recent years.)
Second, even this is not complete protection. Routed reads the
gateways file only once, when it starts up, and notes that it does not
"own" routes marked passive. However, if it later receives routing
info that includes such a route, it will thereafter think that it
installed that route. If it later stops receiving updates including
that route, it times out the route and deletes it. Special thanks to
shj@ultra.com (Steve Jay) for describing this second problem and the
possible fix described below - if you want to know about networking,
ask a network guy!
Our network manager says we had a case of this once when a PC began
sending out routing info including a default route and later many of
our hosts lost their default routes.
The (maybe) fix for this, documented in the 4.3BSD man page for routed
but not in Sun's man page, is to mark the route "external" instead of
just passive. This "is to inform routed that another routing process
will install such a route, and that alternate routes to that
destination should not be installed."
HOWEVER, the reason Sun doesn't document this may be that it doesn't
work. A little poking around in the source quickly found where the
appropriate flag bit was set and where it was tested to prevent routed
from announcing the route, but I didn't find anyplace where its being
set would prevent routed from trying to overwrite the route. I only
spent a few moments looking at the source though; I looked mostly at
the 4.3BSD source - the SunOS 4.1 source looks identical.
Several people told me I simply shouldn't run routed but should use
only a default route or just manually-installed routes instead. When
my group is subnetted and the whole world is beyond a single router,
I'll need only a default route. But right now reaching the 20,000
hosts on our company network involves 168 routes through 26 gateways
off the subnet I'm on.
BTW, for those who haven't seen it yet, the latest SunOS subrelease
(4.1.1b) comes with an rc.local that doesn't start routed if you
install a default route via the new /etc/defaultroute mechanism. The
resulting lack of a routed is the only reason *any* of my group's Suns
still had the default route needed to reach the host being brought up
on the test subnet - and, in fact, it's the only reason the machine
booted at all, since there is no YP/NIS server on the test subnet.
Thanks to:
pbh@cfsmo.honeywell.com (Paul Henninger)
shj@ultra.com (Steve Jay)
Howie Kaye <howie@ivory.cc.columbia.edu>
Neil W Rickert <rickert@cs.niu.edu>
"Matt Crawford" <matt@oddjob.uchicago.edu>
dan@ees1s0.engr.ccny.cuny.edu (Dan Schlitt)
shollen@valhalla.cs.wright.edu (Sheila Hollenbaugh)
kuhn@zariski.harvard.edu (Robert Kuhn)
per@erix.ericsson.se (Per Hedeland)
casper@fwi.uva.nl (Casper H.S. Dik)
Alan Stebbens <aks%anywhere@hub.ucsb.edu>
tefan Mochnacki <stefan@centaur.astro.utoronto.ca>
and to John Ivory and Charlie Labrec, our on-site Sun consultants, and
to Jim Bradt, our network manager.
-- Dick St.Peters, GE Corporate R&D, Schenectady, NY stpeters@crd.ge.com uunet!crd.ge.com!stpeters
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:18 CDT