set@calvin (07/27/89)
I have a question regarding using the BOOTP protocol through gateways. I'm
working on a "factory-floor" device which uses BOOTP and TFTP to load itself
much like a diskless workstation. Currently I use 255.255.255.255 as the
IP destination address for the BOOTP request, as required by the spec.
255.255.255.255 will not be passed-through by any gateways, so booting from
a server not on the local wire requires cooperation by a BOOTP-knowledgeable
gateway. So here's my questions:
1. Is booting through a gateway a typical or useful capability? I have little
(ok, zero) network management experience, but if the feature isn't that
useful, then I'm done now!
2. How common is it for a gateway to provide BOOTP support? If typical gateways
do not support BOOTP, I guess I'll need to implement a "proxy". Are there
any public domain "proxy" programs? (I hate to reinvent)
3. Instead of gateway support or a "proxy", would it be desireable for the
device to perform an expanding search? For instance, uses 255.255.255.255
to search the local wire. If no response, use ICMP to get the subnet mask
and broadcast to the local subnet. If still no response, broadcast to the
entire local net. (too much broadcast traffic?)
I'd appreciate any comments you might have.
-----------------------------------------------------------------------------
Scott Townsend ...!{cwjcc,decvax,pyramid,uunet}!abvax!set
Polymath Corporation, currently working for (but not representing)
Allen-Bradley Company 747 Alpha Dr. Highland Hts. OH 44143 USA (216) 646-5233morrison@accuvax.nwu.edu (Vance Morrison ) (07/29/89)
Hello
Doing Bootp through a gateway is a useful thing to have. We use it here
at NU already and expect to use it more as more diskless devices (terminal
servers, gateways) come on line.
It sounded like you are dealing with the client code. If you implement
the client code correctly, IT SHOULD NOT NEED TO BE CHANGED for a boot
though a gateway. The extra code you need is not client code, it is code
for the proxy (which usually resides in a gateway BUT NEED NOT). All
major gateway manufactures support this proxy code, or a local host can
run CMU's bootpd to act as a proxy (in which case the gateway is not the
proxy).
I stress that the client code need not be changed because at least one
major manufacture (CICSO) screwed up their BOOTP boot sequence so it will
not work unless you have a CISCO acting as a proxy. The correct sequence
of events for a proxy is
1) Client broadcasts (255.255.255.255) the Bootp request
2) The proxy picks this up and forwards it (Thus it is assumed
that the proxy has been configured to forward bootp
requests to the right place). The proxy sets
the gateway field in the BOOTP packet to show that
this BOOTP request is from a proxy.
3) The BOOTP packet makes its way though an arbitrary number of
gateways to get to the BOOTP server.
4) The server looks up the request and prepares the reply. Since
the gateway field is non-zero, the server sends the reply
back to the proxy (instead of broadcasting on the local net).
5) The proxy recieves the BOOTP reply, and broadcasts it on the
correct local net.
6) The Client recieves the BOOTP info. It sets its IP address
AND SUBNET MASK and local gateway from the BOOTP packet
7) The Client uses TFTP to download the proper file from the server
SPECIFIED IN THE BOOTP packet. (It the client could not
set his subnet mask from the bootp packet, he should send
this packet to the gateway for forwarding).
CISCO's make it though step 5 and part of step 6, but instead of using
the information in the BOOTP packet to find the server to TFTP to, it blindly
TFTP's to the broadcast address 255.255.255.255. Of couse this only works
(and works badly) if the server is on the local net.
Vance Morrison
Network Adminstrator
Northwestern Universitysatz@CISCO.COM (Greg Satz) (08/04/89)
Vance, You must be working with old information about our products. While we do not implement BOOTP exactly as you would have liked, we do provide some extra features which you do not describe and apparently are not aware. As you have clearly pointed out, BOOTP clients can utilize the information in the server field of the returned BOOTP REPLY. The implicit assumption in your description is that the BOOTP client can only TFTP from the server that answered the BOOTP. Both Croft's original version (which is three years old now) and CMU's, which is a derivation, return the BOOTP server's address in the server address field. While this does work it isn't the only option left to a client. We consciously chose to decouple our TFTP process from the BOOTP process. This gave us the ability to obtain TFTP information from other then the supplier of BOOTP information. You reported that we can only TFTP from a server on the directly connected network unless there is a cisco router also on the connected network. This is true if you do not have non-volatile memory. If you do have non-volatile memory you have more flexibility and control. We have a boot system command which permits you to load information via TFTP and specify the filename and host address. You can form a list of boot system commands in case the first host (or directed broadcast) fails. We have been successfully performing network boots using this scheme for over three years. Your complaint isn't with our implementation of BOOTP but rather our use of the returned information. We do implement BOOTP proxy forwarding correctly as you point out later in your message. You are correct that adding an option to our TFTP configuration code to permit the usage of the BOOTP server would be a useful feature. Thanks for pointing that out. Greg Satz cisco PS. Comments, questions and complaints about cisco products can be sent to customer-service@cisco.com and are very welcome.