I asked: "How does a diskless client find its default route?"
Come on, team! It was a full 1 hour and 50 minutes before I got the
answer. I know you can do better :-).
Here's the poop on the default route for diskless clients:
The kernel does indeed set up a default route before init or any of the
rc scripts have run. The data sent to a client by bootparamd includes
the default route that the client should use. This is undocumented, as
far as I can tell. Bootparamd, in turn, appears to get the route by
rummaging around in the kernel route data base. It looks like bootparamd
sends out the IP address of the first gateway that it finds on the machine's
primary network interface.
The theory is that any gateway will do, as that gateway will use ICMP
redirects to inform the clients of better routes.
We got into trouble because the brain damaged IBM TCP/IP stuff doesn't
ever send out ICMP redirects. We are solving our problem by putting an
explicit "route add default useful-gateway" command in all of our clients'
/etc/rc.local.
Other userful things we learned:
If you boot a diskless client with "b -v", you see lots of entertaining
stuff about what the client is doing during the boot process [thanks
to geertj@ica.philips.nl (Geert Jan de Groot)].
You can see what bootparamd is doing by killing off the rpc.bootparamd
task & running it manually with a "-d" parameter. Don't forget to
restart it without the -d after you are done. [thanks to "Anthony A. Datri"
<datri@concave.convex.com>]
Silicon Graphics machines appear to have a slightly different version
of bootparamd which returns it's own IP address as the default router
for the clients to use. Unfortunately, if the SGI machine doesn't have
more than 1 network interface, it won't send out ICMP redirects. So,
if you've got an SGI machine on the same network as your server & clients,
it's possible for a client to pick up its bootparam info from the SGI,
and therefore end up with the SGI as its default route. The client then
can't get to other networks. This appears to be an SGI bug. In the mean
time, you can comment out the "bootparamd" line in the SGI's inetd.conf
to prevent it from responding with the bogus data.
Thanks to
"Anthony A. Datri" <datri@concave.convex.com>
stern@East.Sun.COM (Hal Stern - Consultant)
emv@ox.com (Ed Vielmetti)
andys@ulysses.att.com
john@mlb.semi.harris.com (John M. Blasik)
geertj@ica.philips.nl (Geert Jan de Groot)
David Stewart <das@edee.edinburgh.ac.uk>
gdmr@lfcs.edinburgh.ac.uk
James Davenport <jhd@maths.bath.ac.uk>
ekrell@ulysses.att.com
Tim Becker <becker@cs.rochester.edu>
northrup@cps.msu.edu
steve@umiacs.UMD.EDU (Steve D. Miller)
rdunbar@tonka.gsfc.nasa.gov (Richard Dunbar)
acheng@ncsa.uiuc.edu (Albert Cheng)
Jim Mattson <jmattson@UCSD.EDU>
mdisea!edm@uunet.UU.NET (Ed Morin)
era@niwot.scd.ucar.EDU (Ed Arnold)
Kennedy Lemke <Kennedy_J_Lemke@Princeton.EDU>
Steve Jay
shj@ultra.com ...ames!ultra!shj
Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA
(408) 922-0100 x130 "Home of the 1 Gigabit/Second network"
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:10 CDT