|
LANCity BOOTP Development
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: July 24, 1996
Note: For help designing your DHCP network or developing tools to help you audit/test the performance your applications contact Birds-Eye.Net.
BOOTP File:
·
There are very few
differences between BOOTP files generated by LANCity’s provisioning server
1. The
BOOTP file (x.MD5) consists of several fields (much of which does not change among all
BOOTP files).
2. Within
a subnet, ALL headend (LCb) and modem (LCp) BOOTP files are identical.
3. A
BOOTP file made by a process that converts all its operating parameters to hexidecimal
characters (basically what is contained in the Intel based LCn .cfg file is converted to
hexidecimal). After this is complete, an application (off the shelf – freeware)
called a MD5 converter reads the file created in the previous step, generates a unique KEY
based on that information, and appends this KEY to the end of the BOOTP file. A
“FF” signifies the end of the BOOTP file and padding may be added to reach the
required size 162 bytes.
·
It is proposed that a
script be written to construct this BOOTP files utilizing arguments on the script to
handle the fields that are unique to each field.
1. Since
there is much duplication of BOOTP files within a particular node I recommend that we take
advantage of this duplication and utilize the same file (reduce the complexity of the file
storage process). In this manner all LCps residing in the same subnet share the same BOOTP
file. The names of these BOOTP files (located in the TFTP directory) would reflect which
subnet they will serve.
2. New
modems can be provisioned by communicating the IP Address, MAC Address, and BOOTP file
name during the BOOTP process (all contained in the BOOTP table.
3. This
enables the use of the existing Intel based provisioning server (LCn) to generate the
reference BOOTP files – eliminates the need for 3rd party development of a
script to generate BOOTP files (note this may be wasted $ since it would only work for
current LANCity BOOTP devices and would need to be re-written or modified each time
LANCity revises its BOOTP file structure – LANCity’s implementation does not
necessarily follow BOOTP standards).
TFTP Interaction:
Trivial File Transfer Protocol (TFTP) provides a means of downloading
BOOTP files to LANCity devices (diskless machines). TFTP is an automated service that will
basically download requested files on demand. In this instance, the TFTP directory will
contain a BOOTP file for each subdirectory that was created on the Intel based
provisioning server (LCn) and moved (FTP) over to the TFTP server’s directory.
Because TFTP interaction is based on a LANCity device successfully completing BOOTP
(obtaining operating parameters from the BOOTP table), TFTP will not be initiated by the
LANCity device unless the device obtains the necessary information to request a TFTP
(mainly the filename of the .md5 file and the IP address of the TFTP server).
Remedy:
·
Create a new schema(s) to
handle multiple DHCP/BOOTP servers
·
Add a modem type (LCh, LCp,
LCw, etc.) to existing modem schema
·
initally all that will be supported is the LCp
Subnet Table
City |
Node |
Frequency |
Number of Customers |
Subnet |
Subnet Mask |
Integer Subnet |
Server Table
Integer Subnet |
DHCP Server |
BOOTP Server |
HA Servers ??? |
Need to figure out if we can trap error messages (commands not
executed) and flag those commands to be repeated later (in the event a network outage or
down server) à generate
TT from trap
Workflow of BOOTP Creation Process (new customer)
1. Customer
calls and request a level of service
2. CableData
stores city and of the customer record
3. Remedy
stores the node number, frequency along with other modem specific information
4. Warehouse
assigns modem (MAC), NIC (MAC) to customer [NIC may already be in customer’s
computer]
5. >>
As soon as modem MAC address is entered for the customer, the Remedy to BOOTP
communication is activated:
·
Use the Subnet table to
checkout an available IP address (from available pool) for the subnet
·
Create a record in the
BOOTP table for that modem (MAC, IP – note other fields will be added to this record
in the future)
·
Write out this BOOTP table
and use the Server table to direct transfer (FTP?) command to the correct server (s)
– may execute command for each server (i.e. backup files, HA BOOTP servers)
·
Communicate with BOOTP
server (Rshell) and execute copy (cp) command
·
The copy command will
replace the existing dhcpcap file with the one FTPed over from Remedy
·
The DHCP/BOOTP server now
uses the new dhcpcap file (no reset is needed)
Workflow of BOOTP Deletion Process (deactivate customer):
1. Customer
calls to cancel service or for some other reason (financial, hacking, replacement, typeo)
the customer has to be deactiveated. The link from Remedy to the customer BOOTP server is
the Modem MAC address (this is actually the name of the BOOTP table entry).
2. >>
As soon as there is a modification to the customer’s status (deactivated), modem MAC
address, City, Node, Modem Type the process is activated.
3. Since
the LANCity device is contained in a BOOTP table contained in a Remedy schema (dhcpcap),
the deactivation process involves deleting the record of that modem and copying the
dhcpcap file over to the DHCP/BOOTP server, and then performing a software reset on that
customer’s modem.
4. Use
the Server table to direct the delete command to the correct server (s) – may execute
command for each server (i.e. backup files, HA BOOTP servers).
5. Note
that replacement of modems or typos may involve two actions on the database (add record
and delete record) before the file is transferred to DHCP/BOOTP server.
Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white
papers hot off
the presses by adding our RSS feed to your reader.
|