This is meant to be an introduction on the Bootstrap Protocol, or just BOOTP, specified by the RFC 915. On a later post I’ll share my opinion about the current implementations by ISC Dhcpd and Bootp-DD2.
At large enterprises, server farms are often located away from tech personnel; sometimes blocks aways, sometimes in different cities, sometimes in different countries! So situations where physically accessing the machines isn’t an option are something sys admins must be able to deal with. What to do when you need to boot one or several machines to perform any kind of maintenance task?
Most business-grade hardware solutions, like BladeCenters, System P, and so on, provide a way of accessing their console remotely, this is straightforward. What is way harder to do is to burn CDs remotely and load them into these machines’ drives. 🙂
So, what about BOOTP? Well, BOOTP makes it possible for a client machine to grab a boot image from a boot server and load it, the very same way you would do with a LiveCD or Linux Installation CD, but without the physical media.
Deeper into BOOTP
Well, what’s common among all BOOTP scenarios is that you must have a BOOTP server, an images sever (more on this later) and BOOTP-aware clients. I’m not confident to say whether it’s something usual to find x86 desktops or laptops capable of booting through the network, in enterprise systems however, that is something really usual, so let’s assume that’s OK.
I just mentioned we need two servers, a BOOTP server and an images server, this happens because all the Bootstrap protocol cares about is handshaking, no actual file transfers are done with it, thus while the former solves the handshake issue, the latter provides actual file transfer capabilities, usually with TFTP. Although one could use implement any protocol to perform the file transfer, every single case I saw so far used the Trivial File Transfer Protocol (TFTP) which is a very simple transfer protocol built on top of UDP that doesn’t implement authentication, etc. Note that both servers might be running in the same machine, but conceptually these are two different players.
How does it work? The protocol itself is quite simple, imagine we have a client C, a BOOTP server B and a file server F. Basically:
1) C wants to boot so it tells the world about it (more on this later).
2) Hopefully the server B hears the bootp-request packet and sends a bootp-reply packet to C with several data fields, including: an IP the client should use for the subsequent transfer (as well as a netmask, eventually a gateway, etc), the server it should grab the file from and a filename it must ask for – remember, the client machine had just booted, it knows nothing but the fact it wanna boot :-).
3) C requests to F, the file he was told about.
4) F sends the file to C
5) C boots 🙂
It seems simple and it is simple, but useful!
Directed Bootp vs Broadcast Bootp
(From now on, assume “server” means “bootp server” unless told otherwise)
The first time I saw a network boot, both the client and the server were on the same subnet, and for a good amount of time I thought this was the way things had to be. The client was sending its requests on Ethernet broadcast (which are not routable as you should know), the server was checking the client’s MAC address against its table and sending its replies, everything was working fine. But… one day I say a machine booting from a server in another network, with a few routers between them and several hundred miles between them :). I had to understand why that was working.
So, after some research, I found out there were two different “kinds” of BOOTP, the Broadcast one, and the Directed one.
So, here it’s how things work:
Broadcast Bootp –> The client doesn’t need to know anything at all before booting. It just sends a bootp-request in an Ethernet broadcast datagram, assuming the server will be listening on the same network. The server then checks a client list that maps MAC addresses to files, if it finds the client it means the server has authority over it and so it sends a bootp-reply directly to the client MAC address. The client then configures itself with the given IP, etc, and the transfer is done in Unicast (UDP/IP).
Directed Bootp –> This “flavor” has an important advantage over the former, bootp requests and replies can be routed across different networks, that means one server can take care of more clients and clients located farther away. As you may have anticipated, in this mode the BOOTP handshake is also done in IP unicast, that’s why it’s routable, but… this implies one must configure each of the client machines with their network info (IP, netmask, gateway) as well as with the server info (IP). The drawback? In large environments that requires a lot of work and, each time one decides to use another server he must reconfigure each of the clients. This is why the lunch isn’t free this time.
For those willing to learn more about the Bootp protocol I suggest you read the RFC 951, it’s short and has an accessible language. You can also let me know you read this post and leave your comment / question / suggestion below.
Meanwhile I’ll write about a bug I found in current implementations and the patch approach I believe should be followed.