Path: utzoo!attcan!utgpu!watmath!iuvax!mailrus!accuvax.nwu.edu!morrison
From: morrison@accuvax.nwu.edu (Vance Morrison )
Newsgroups: comp.protocols.tcp-ip
Subject: Re: BOOTP through gateways
Message-ID: <966@accuvax.nwu.edu>
Date: 28 Jul 89 17:37:22 GMT
References: <806@abvax.UUCP>
Sender: news@accuvax.nwu.edu
Reply-To: morrison@accuvax.nwu.edu (Vance Morrison )
Distribution: na
Organization: Northwestern Univ. Evanston, Il.
Lines: 49


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 University