BOOTP, DHCP, and TFTP Implementation

By: Bruce Bahlmann - Contributing Author (your feedback is important to us!)

Created: November 6, 1996

Note: Birds-Eye.Net offers a DHCP Stress Testing Suite [evaluation/buy] as well as expert consulting help for the peskiest of DHCP configurations [consulting].

Overview:

 The following implementation of DHCP is based on the DHCP Recommendations document written earlier. The basic idea is to dynamically provide (lease) an IP address to a customer’s computer in such a way that the following are satisfied:

1.      Network reconfiguration can be done with a minimum amount of customer interaction (brief notification [e-mail] of predicted outage) – note this includes reorganizing IP address distribution.

2.      Simplify IP administration to reduce instances of duplicate IP addresses.

3.      Enable installation technicians in the field to utilize DHCP on their laptops so they wouldn’t have to know which subnet they were on and just be able to pug-n-play. Enable them to roam the serving area while only consuming “one” IP address lease. Also eliminates field technicians from having to reconfigure their laptops when accessing the corporate net back at the office.

4.      Restrict customer access or DHCP distribution of IPs to known personal computers using the MAC address associated with these machines.

While DHCP is near-fully implemented (security concerns remain), dynamic BOOTP is merely in its infancy in version 1.0. BOOTP refers to the provisioning (activation) of the LANCity personal (LCp) or modem that enables the customer’s computer to access the Highway1 network and its services. The basic idea behind dynamic BOOTP is to provide configuration information (brains) to diskless devices across a network. The reasons for automating this are:

1.      Migrate from the stand alone Intel based provisioning server (LCn) as the primary source of provisioning modems. Note that the Intel based platform is not as easily capable of automation due to limitations in its operating system.

2.      Enable service personnel the ability to provision and deprovision modems from the field– requires Remedy.

3.      Enable a Remedy provisioned cable modem that is plugged into the cable plant of any active town (regardless of what frequency, subnet, or device) and just work. Also allow that modem to roam the cable plant and consume only one IP address lease.

4.      To enable a reliable means by which customer access can be shut off (in the event of disconnect, hacking, financials, etc.) – this has been termed “deprovisioning”

Using DHCP and dynamic BOOTP have clear advantages over statically assigned IP address mechanisms for the following reasons:

1.      Fully scaleable solution for provisioning modems

2.      Automated tracking for modem and pc IP address usage

3.      Significantly smoother node transition during times of network reconfiguration and or IP address reallocation

4.      Significantly less customer contact during the above activity

5.      Significantly reduced complexity for customer IP address administration

6.      Reduced installation time (computer configuration) taking advantage of plug-n-play

7.      Significantly reduced provisioning complexity

Implementation:

Figure1. Systems communications model for provisioning 

The following implementation (1.01) of provisioning modems and PCs follows the diagram in Figure 1. In this diagram, all the major communications between systems are indicated. DHCP, dynamic BOOTP, and TFTP implementation are based on the use of an application called Join (by Competitive Automation) which runs on various open systems. Join has the capability to do DHCP and dynamic BOOTP at the same time. Join should be setup in the following configuration to run LANCity equipment. Refer to the appendix section 1 for specific settings of Join and TFTP. This implementation assumes the use of Sun equipment and Solaris 2.5.1 OS. Note that in the above model both the subscriber network and the provisioning server reside outside the firewall. This implies that communications involving Remedy must take place through the firewall.  

To provision a customer with version 1.01 in Remedy, the following things must happen:

1.      At the field site, enter the MAC address of the modem, and computer network interface (if known – note that in some cases this can only be done on-site because some computers have built-in ethernet [Macintosh]) into a Remedy client. This step merely registers the MAC address (authorizes or allows it to be recognized by the provisioning server). The provisioning server does not do anything with this information until the registered device (modem/pc) actually requests.

·        Appendix section 2 describes the use of jdbreg and how to enter a MAC address in the authorized register

·        Appendix section 3 shows how to confirm a entry into the registry

2.      Once the device (modem/pc) is activated (power up) it requests an IP address or a BOOTP and this is handled and logged by the provisioning server.*

·        Appendix sections 9-12 shows how various DHCP requests are received and processed.

·        Appendix sections 6-8 shows how various BOOTP requests are received and processed.

3.      Behind the scenes, a BOOTP file which contains the information the modem needs to operate is downloaded as a result of a successful BOOTP request. This should activate the modem for network activity.**

4.      The computer must be configured to run DHCP. Supported clients are Windows 95 TCP/IP and Macintosh Open Transport version >1.1 – the result will activate the network software to communicate with the DHCP server (receive a valid IP address lease).

5.      For both pieces of equipment (modem, and computer) their IP addresses will be stored in the provisioning server. These addresses can be obtained by querying the provisioning server for a specific MAC address’s leased IP address.

·        Appendix section 4 shows how to lookup an IP address of device (by MAC) that has obtained an authorize IP address using DHCP. The same goes for looking up IP addresses of authorized modems.*** 

*Note that Macintosh clients do not immediately request an IP lease from the DHCP server. This is due to a setting in the TCP/IP client that will not request an IP lease until a TCP/IP application is launched which requires an IP address. If this is changed it will immediately request an IP when the system is active at power up. To configure this, go into the TCP/IP control panel, under the “Edit” menu select “User Mode…”, select “Advanced” and click “OK”, select the “Options” button, deselect the checkbox (load only when needed) and click “OK”, click out of TCP/IP screen (upper left checkbox), and click “Save” to save the changes made (client should then request an IP address from server). Note also that some versions of Macintosh require a newer version of Open Transport to work (>1.1) 

**Note that with the latest version of LANCity equipment there are some options available to adjust the throughput of the modem. This implementation (v1.01) is geared toward everyone having the same speed (all people on a particular subnet have the same BOOTP file). Future versions of implementation will include varying throughput on a customer to customer basis. The “normal” service people will all use the same BOOTP file. While this implementation does not include this functionality, it is designed with this in mind. 

***Note Remedy will only do lookups when needed for troubleshooting (ping, fast-ping, trace-route, etc.) Ordinarily, the IP address will not reside in Remedy and can only be obtained through using one of the troubleshooting tools in the “HSD-Calls” section. 

BOOTP File structure for TFTP: 

BOOTP files are not generated for each device* in this implementation. Instead, like devices within a neighborhood area network (NAN**) share the same BOOTP file. The file naming convention and directory structure of the BOOTP files within the TFTP directory have been selected to simplify operation and address complex dynamic IP address assignment for BOOTP. If other directory structures are used future services (varying levels of throughput speeds of modems) will not work correctly. This directory structure is as follows:

·        Each IP address block has reference files for each service (headend, basic***, isdn) – others can be added as other services are offered.

·        The names of these reference files must be the same across all directories. Naming them different will disable dynamic IP address assignment for additional levels of service.

·        The directories containing BOOTP files for a particular IP address block (subnet) will be associated with home directory defined for that IP address block within the provisioning server (subnets tab).

·        The service which has the greatest number of users should have its BOOTP file name (basic) associated with each IP address block (subnets) in the provisioning server. This file association along with the use of a home directory enables the command jdbreg to activate this device dynamically.

·        When additional levels of service are offered (using this implementation), each one must entered into the nodes section of the provisioning server (dhcpcap file). Only minimal information (Name, Hardware Address/Client ID, Hardware Type, and Boot file) needs to be entered for each device. Note this information will NOT be IP address specific (since the IP address will be chosen dynamically)

·        BOOTP file specifics:

1.      The number of devices entered on the LCn for creation of these BOOTP files should be 4 (the maximum number of devices for an LCw)****.

2.      IP addresses of authorized SNMP machines should be entered for all BOOTP files (headend, basic, etc.) for an additional level of security on BOOT-able devices (once it is known – initially this may not be possible) 

*This is done for a number of reasons. Most importantly, because it will make modifications to the network easier. If all “basic” service customers use the same BOOTP file it cuts down on the complexity of maintaining a BOOTP file for each device and makes upgrading or changes to the BOOTP files easier. 

**A neighborhood area network (NAN) is a collection of several Cable serving areas (each may be served by a separate fiber node) grouped by networking hardware (hubs, routers, headend equipment) in such a way that they (serving areas within the group) share a IP address block. 

***Basic is an asymmetric service chosen for the modems at roll-out. This service provides 1500b/s forward service and 300b/s return. While these figures can change, all the “basic” files must be consistent across all the subnets. 

****The number of active devices is controlled by DHCP and not BOOTP, devices LCp, LCb, and LCh ignore this field, and from an implementation standpoint it is easier to have several devices share the same BOOTP file. 

The functionality implemented in version 1.00 is changed by the advent of dynamic BOOTP.

1.      Given a customer’s city, fiber node, and a modem Remedy will provision (create a BOOTP entry) for the customer’s modem. Note this is a highly interactive (manual) process, requires multiple fields from Remedy, and there are several problems that prohibit scaling of this implementation. Note that it also does not address the Technicians need for spare LCps.

2.      If the city, node, or modem are modified, Remedy will NOT de-provision the old information and re-provision the new information automatically These are currently separate steps that require the user to APPLY each action. 

Join Overview:

As with any application, Join comes with a “big” question mark on the box. Where does one start getting their arms around the task at hand (provisioning modems for a cable company). At first glance the provisioning server is but one process in the activation but after further study it becomes the heart of the system. The following is a list of some of the things the provisioning server either does or plays the key role in: 

·        Maintaining a list of all active leases and the hardware addresses associated w/ them.

·        Maintaining a list of all the devices registered to use the server

·        Providing IP addresses for the purpose of maintaining accurate DNS tables

·        Providing IP addresses for the purpose of SNMP management of modems

 Join Setup & Customization:

 Using the Xwindows interface “xjoin” (which is the preferred tool for building and maintaining the server) and starting with the Server/Security tab, here are the settings currently used for Join in the North East: 

Server/Security Parameters

* This setting accounts for the smaller DHCP packets that are a characteristic of Apple DHCP clients.

** Enables BOOTP clients to request an immediate reboot, not all boot requests are successful so failed requests be allowed to bootp again.

*** Deprovisioning takes care of this for us.

 IP Ranges

Note the subnet block 36 uses 24.128.1.34 as the DHCP server, the IP ranges define the available pool of IP addresses. We start IP ranges with “80” to allow for headend nodes, router ports, etc that are configured statically. 

Under the Subnets tab is where the IP Ranges created above are further defined. Subnets, once created should not be changed rather re-allocated. Meaning, once four class C addresses have been ciderized (? - joined together by a subnet mask) they should stay together keeping their BOOTP files the same. The titles of these settings refer to a category in Join that displays varied information (BASIC DHCP Parameters is the default, JOIN Parameters will display a complete list). Note that default setting is ok for everything but configuring the Groups. 

BASIC DHCP Parameters (Subnet Tab)

Note the two naming conventions “basic” for LCp files, and Needham#a for headend group. It is important to have a # symbol in the headend groups and basic and heandend for the names of BOOTP files.  

Under the Nodes tab is where headend nodes are entered. Headend nodes are entered statically but are managed using a specially developed script. Note that the nodes area will also indicate a option to be developed later (multiple service offerings). The node entries should look similar to the following: 

BASIC DHCP Parameters (Nodes Tab)

Note the naming convention “needham_9” the “_” is used in the script to depict headend nodes. 

Lastly are the groups. The groups can be thought of as headends. Using the configuration that there are two DNS servers per headend it is a good idea to setup two groups per headend. In this way you can balance primary DNS servers by reversing the order of the DNS Servers listed for each Group. 

JOIN Parameters (Groups Tab)

Forget everything else if you can remember that priorities of the information entered into the groups, nodes, subnets, server/security follows this order of priority:

 Sever/security à Groups à Subnets à Nodes

 In other words, information entered into Nodes has the final say (or supersedes) that which may have been set previously.  

Discussion:

 While the actual implementation of DHCP is relatively easy, there are some issues regarding security and availability that need to be addressed:

1.      The possibility exists that someone (customer?) could potentially load or activate DHCP service on their machine. Administrators of DHCP need to develop a strategy of how to determine this and what action they would take in this situation.

·        Some level of protection does exist within the DHCP clients running on windows software (unknown on the Macintosh DHCP client). This protection is in the form of a pointer (IP address to the correct DHCP server) that is loaded when the customer PC originally (at installation) received their IP lease. This pointer remains intact unless the customer performs a “release all” (theoretically but this does not work 100% à the client pretty consistently keeps pointing to the DHCP server) which would clear the pointer and go look for a DHCP server again. Should our server go down, the customer client will remain pointing to the correct server. In the case where a customer starts their own DHCP server, this would be first noticed during installation as service people try to obtain the original lease. The IP address of this DHCP server should be matched with its MAC address and looked up in Remedy. Worst case, is to use router tables to find the MAC address (probably not a device listed in Remedy) and then poll modems ethernet port to find the MAC address that matches the one in question, call that customer and or shut down their modem.

·        Another possible solution may be to add a relay agent to the cable modem so that all broadcasts are forwarded to a specific address. In this way, the any DHCP services started on a customer’s machine will not “receive” any broadcasts.

2.      Since the DHCP server is administered through a remote shell, some protection must be in place such that customers can not access this service and modify or halt DHCP services.

·        Some level of protection is gained through placing the provisioning server on a separate machine that is outside the HA server cluster. A minimal amount of services will run on this server.

·        There must be some way to gain access to the provisioning server GUI. Currently an X-Server (eXodus) running on a Macintosh is used to access this GUI. A more secure X-Server should be found.

Þ    Solution to this problem is to telnet into the server and then assign the variable DISPLAY to the address of the X-Server on the PC and run the x-windows application remotely. This solution works without any known problems.

3.      If DHCP is used for all customers that means there is the potential that customers could potentially switch to manual or static IP addressing. Should this occur, it is possible that two people could have the same IP address. In this situation only one person would be able to access the network (in most cases this is the person who turns on their machine first – the other person [potentially the one using DHCP correctly] would get a duplicate IP address message). To deal with this situation (critically important) we must have some kind of mechanism to continually check router tables (they contain a backlog of computers MAC address and IP address that have used them) and compare them to data contained in our database (DHCP) for incorrectly mapped IP addresses. If something like this is found a trouble ticket with highest priority should be generated to the TSS’s attention. The person performing such an action should be shut-off from the network (disable modem), warned about this activity and instructed how to change back to DHCP. We may be encouraging static addressing if we can’t respond promptly in this situation.

·        Another way to do this may be to set some kind of filtering on the modem so that only a specific IP address is able to pass through the modem.

4.      Another result of the change from DHCP to static which might produce the same result as above is when someone merely configures their machine statically to the parameters that DHCP gave them. In this situation, they would not be responding to the DHCP server and the DHCP server may come to believe that since the client failed to renew its lease the server gives the IP address to someone else. DHCP does ping an IP address before it gives it to someone but in this case if the person had their machine off it would not respond to the ping and will create a duplicate situation.

5.      Since there is currently only one provisioning server there should be some form of back up feature or high availability.

·        An attractive option is to mirror the internal drive and configure a second machine exactly the same as the primary. In the event the primary fails, the backup machine is installed so it takes over where the other server left off (same IP address, etc.). This machine should also be networked in such a way that it is highly available (between two switches).

6.      Due to the expected popularity of this service the single server model may not be a long term solution. While the network grows and inevitable outages occur, a more distributed model may decrease the load of a particular server.

·        If the provisioning server works like its supposed to, this may be implemented at the application level of the server software and not involve additional information from Remedy. In this way, requests coming from a particular subnet will be forwarded to a “local” provisioning server based on the gateway associated with the request. The master provisioning server would communicate authorize hosts down to all slaves so that the roaming feature would not be lost. Slaves would communicate their leases up to the host for management purposes. Some of this functionality seems to already be in the provisioning server. 

To effectively deal with the duplicate IP addresses it may be well served to proactively search for unauthorized IP usage. Since there is a relationship between IP addresses and MAC addresses in the DNS server, the router tables, and the DHCP server, the three could combine to effectively track IP address usage proactively. This netwatch service should look for unregistered MAC addresses (comparing the IP addresses mapped to MAC addresses that are in a router table to the information contained in the Join database) and flag discrepancies (these could result in notifiers sent to Remedy in terms of an unauthorized use of an IP address. From there, a TSS could address the issue by either calling the customer or shutting down their access. 

Although BOOTP is relatively low-level procedure consisting of trivial system tasks, there are some issues regarding security and availability that need to be addressed: 

1.      BOOTP files have the potential to become corrupt. This has already happened on the Intel platform and while the UNIX file system is significantly better the potential still exists. To combat this problem one could easily make a backup of the BOOTP files that are placed in the TFTP directory for distribution. In later versions of the Remedy software, a copy command (cp *) could easily blast the files located in the TFTP directory.

Appendix:

Revised 8/2/96 bfb

 1) Configuring Join Server:

/etc/join/dhcpcap

 # more dhcpcap

(BootP Entries – used for statically assigned headend reference nodes [LCb])

needham1:ht=1:ha=0000ca032a9a:ip=24.128.60.11:bf=headend:

needham2:ht=1:ha=0000ca031cf8:ip=24.128.60.12:bf=headend:

 (Global Variables)

global:dn=highway1.com:ds=24.128.1.80 24.128.1.81 24.128.60.7 24.128.60.8:lt=86400:t2=4200:t1=3600:sa=206.35.219.20:lg=0.0.0.0:to=0:

 (Network and BootP File Assignment)

subnet60.0:nw=24.128.60.0:sm=255.255.252.0:tc=global:gw=24.128.60.1:ba=:bf=basic:hd=/usr/tftp/net24.128.60.0

 1a) Configuring IP Ranges:

this area allows entry of new IP address ranges to available pools.

/etc/join/nets

 # more nets

24.128.60.0 24.128.1.34 24.128.160.75-24.128.63.254

 1c) Join Settings from:

more /var/join/log

=====================================================================

JOIN server startup  on Thursday August 01 15:20

JOIN Server Release 3.1j for Sparc with Solaris 2.x

Copyright 1992-1996 Competitive Automation, Inc.  All Rights Reserved.

 official host internet address = 206.35.219.20

server domain name              =

lmgr: available licenses = 50000, licenses in use = 0, overdraft limit = 5000

debug level                     = 2

default lease duration          = 86400

finite bootp auto extension    = 0 secs

ttl of provisional lease       = 60 secs

timeout on ICMP echo            = 500 msecs

minimum legal bootp packet     = 300 bytes

name service                    = none

name service updateable         = false

naming policy                   = by hw address

accept client name              = false

free list length                = 8

bootp support                   = true

bootp addr from pool            = true

registered clients only        = true

listen on ppp interfaces       = false

ping bootp clients              = true

reply when relay on same net   = false

send options in offer           = false

auto-reread modified dhcpcap   = true

validate bootp client net#     = true

auto synchronise disk database = true

release ip when client moves   = true

syncing databases

Listening on interfaces: hme0

Re-acquiring licenses:

=====================================================================

 1d) TFTP Setup

the TFTP service must be started (use directory /usr/tftp). This is merely a matter of taking out the comment out of the inetd.conf file. NOTE that the -s option used in inetd.conf may need to be removed for this service to work.

 # Tftp service is provided primarily for booting.  Most sites run this

# only on machines acting as "boot servers."

#

tftp    dgram   udp      wait    root    /usr/sbin/in.tftpd      in.tftpd  /usr/tftp

 2) Example MAC Address Entry (provision):

used for entering (preloading) authorized MAC addresses for modems and computers

jdbreg <filename>

 # more newcustomer

00:00:0c:31:d8:a4|1|6|

 jdbreg newcustomer

 3) Listing of registry (MAC Address Table)

current listing of all MAC addresses (modem & computer) that have been registered

/opt/join/jdbreg -s

 # jdbreg -s

00:80:c7:25:eb:86|1|6|

00:00:0c:31:d8:a4|1|6|

00:a0:24:4e:61:6e|1|6|

00:aa:00:21:7e:c4|1|6|

00:a0:24:23:9f:61|1|6|

00:a0:24:3c:aa:fb|1|6|

00:80:19:2c:70:6e|1|6| 

4) Example of Active IP Address Listing:

listing of current IP address leases, NOTE that unless “auto synchronise disk database = true” this list will lag behind actual leases made to authorize MAC addresses. A reset command can also do this but without the performance hit need to synchronize Join’s databases.

 /opt/join/jdbdump

 01:00:a0:24:8e:fb:0e|0|7|206.35.218.150|838167284|838253684|838170884|

838167284|206.35.219.20|||

 5) Example IP address deprovision:

used for removing a MAC address from the registry and releasing the IP lease

jdbreg -d (newcustomer)  removes mac address from registry

jdbmod -d (grep of jdbdump on mac address)   -- terminates ip address lease

snmp reset:

 6) Unsuccessful BOOTP due to unregistered MAC address

=====================================================================

received on address 206.35.219.20

BOOTP request from 00:00:ca:03:1d:42

unregistered host <MAC>=<00:00:ca:03:1d:42> sending Dynamic BOOTP -- ignored

=====================================================================

7) Successful BOOTP with no boot file designated (boot process fails)

=====================================================================

received on address 206.35.219.20

BOOTP request from 00:00:ca:03:2a:9a

seeking BOOTP client (1,6,00:00:ca:03:2a:9a) on subnet 206.35.217.0

BOOTP packet from <MAC> <00:00:ca:03:2a:9a> configured with <IP> <0.0.0.0>

 Reply Host structure:

ci=0.0.0.0:gi=206.35.217.1:sa=206.35.219.20:yi=206.35.217.160:flags=1,2,3,6,7,15

,28,66,513,514:sm=255.255.255.0:to=0:gw=206.35.217.1:ds=192.52.71.5:lg=0.0.0.0:d

n=ctcne.com:ba=206.35.217.255:sn=paperboy:

=====================================================================

8) Successful BOOTP and TFTP

=====================================================================

received on address 206.35.219.20

BOOTP request from 00:00:ca:03:2a:9e

seeking BOOTP client (1,6,00:00:ca:03:2a:9e) on subnet 206.35.218.0

BOOTP packet from <MAC> <00:00:ca:03:2a:9e> configured with <IP> <0.0.0.0>

 Reply Host structure:

ci=0.0.0.0:gi=206.35.218.1:sa=206.35.219.20:yi=206.35.218.157:flags=1,2,3,6,7,13

,15,28,66,67,513,514,520:hd=/usr/tftp:sm=255.255.255.0:to=0:gw=206.35.218.1:ds=1

92.52.71.5:lg=0.0.0.0:bs=0:dn=ctcne.com:ba=206.35.218.255:sn=paperboy:bf=/usr/tf

tp/net206.35.218.0:

=====================================================================

9) DHCP discover – unregistered MAC address

=====================================================================

received on address 206.35.219.20

Starting txn 838927432 on Thursday August 01 15:23

from (ip_address,port#)=(206.35.218.1,68) to=(206.35.219.20,67) received on inte

rface hme0

xid=0x5c739973 secs=1024 flags=0000

Received Host structure:

ht=1:ha=00.a0.24.8e.fb.0e:ci=0.0.0.0:gi=206.35.218.1:sa=0.0.0.0:yi=0.0.0.0:flags

=12,50,53,61,515,523:vm=rfc1048:ho=Default:ip=206.35.218.154:ck=0100a0248efb0e:m

t=1 (DHCPDISCOVER):

 unregistered host <MAC>=<00:a0:24:8e:fb:0e> sending DHCPDISCOVER -- ignored

=====================================================================

10) DHCP discover – lease offer

=====================================================================

received on address 206.35.219.20

Starting txn 838928162 on Thursday August 01 15:36

from (ip_address,port#)=(206.35.218.1,68) to=(206.35.219.20,67) received on inte

rface hme0

xid=0x1c031c03 secs=0 flags=0000

Received Host structure:

ht=1:ha=00.a0.24.77.e6.19:ci=0.0.0.0:gi=206.35.218.1:sa=0.0.0.0:yi=0.0.0.0:flags

=12,50,53,61,515,523:vm=rfc1048:ho=WColeman:ip=206.35.218.151:ck=0100a02477e619:

mt=1 (DHCPDISCOVER):

 DHCPdiscover

seeking client (0,7,01:00:a0:24:77:e6:19) on subnet 206.35.218.0

DHCPDISCOVER from HW address 00:a0:24:77:e6:19 : provisional lease

address 206.35.218.153 is in use elsewhere and will be marked unavailable

seeking client (0,7,01:00:a0:24:77:e6:19) on subnet 206.35.218.0

DHCPDISCOVER from HW address 00:a0:24:77:e6:19 : provisional lease

License checked out for 206.35.218.156 

Reply Host structure:

ci=0.0.0.0:gi=206.35.218.1:sa=0.0.0.0:yi=206.35.218.156:flags=51,53,54:lt=86400:

sv=206.35.219.20:mt=2 (DHCPOFFER):

=====================================================================

11) DHCP request -- due to expiration of IP lease

=====================================================================

received on address 206.35.219.20

Starting txn 838928162 on Thursday August 01 15:36

from (ip_address,port#)=(206.35.218.1,68) to=(206.35.219.20,67) received on inte

rface hme0

xid=0x1a031a03 secs=0 flags=0000

Received Host structure:

ht=1:ha=00.a0.24.77.e6.19:ci=0.0.0.0:gi=206.35.218.1:sa=0.0.0.0:yi=0.0.0.0:flags

=12,50,53,55,61,515,523:vm=rfc1048:ho=WColeman:ip=206.35.218.151:ck=0100a02477e6

19:mt=3 (DHCPREQUEST):rv=1,3,6,15,44,46,47:

DHCPrequest(rebooting)

client wants address 206.35.218.151

subnet=206.35.218.0  mask=255.255.255.0   server interface=206.35.219.20

DHCPREQUEST(rebooting) from HW address 00:a0:24:77:e6:19 : lease expired

Reply Host structure:

ci=0.0.0.0:gi=206.35.218.1:sa=0.0.0.0:yi=0.0.0.0:flags=53,54,56:sv=206.35.219.20

:em=lease expired:mt=6 (DHCPNAK):

=====================================================================

12) DHCP request -- lease renewal

=====================================================================

received on address 206.35.219.20

Starting txn 838928167 on Thursday August 01 15:36

from (ip_address,port#)=(206.35.218.1,68) to=(206.35.219.20,67) received on inte

rface hme0

xid=0x5b055b05 secs=1024 flags=0000

Received Host structure:

ht=1:ha=00.a0.24.77.e6.19:ci=0.0.0.0:gi=206.35.218.1:sa=0.0.0.0:yi=0.0.0.0:flags

=12,50,53,54,55,61,515,523:vm=rfc1048:ho=WColeman:ip=206.35.218.156:sv=206.35.21

9.20:ck=0100a02477e619:mt=3 (DHCPREQUEST):rv=1,3,6,15,44,46,47:

DHCPrequest(selecting)

client wants address 206.35.218.156

subnet=206.35.218.0  mask=255.255.255.0   server interface=206.35.219.20

DHCPREQUEST(selecting) from HW address 00:a0:24:77:e6:19 : new lease

Reply Host structure:

ci=0.0.0.0:gi=206.35.218.1:sa=206.35.219.20:yi=206.35.218.156:flags=1,3,6,12,15,

28,51,53,54,58,59,67,514:sm=255.255.255.0:gw=206.35.218.1:ds=192.52.71.5:ho=WCol

eman:dn=ctcne.com:ba=206.35.218.255:lt=86400:sv=206.35.219.20:t1=3600:t2=4200:bf

=net206.35.218.0:mt=5 (DHCPACK):

=====================================================================

 Known Bugs: 

Macintosh:

·        Open Transport 1.1 can not have lease times longer than 30 hours (fixed in version 1.1.1)

·        Open Transport uses smaller DHCP packets (244) which are ignored by Join unless the min BOOTP Packet Size is set to around 200.  

Windows 95:

·        When a DHCP client receives a duplicate IP address it locks up the network interface. The only way to unlock it is to do a release all, power down the computer for 30 seconds, and then restart the computer.

·        Note that “release all” will not fix a duplicate IP address because the network interface is locked. Release all also will not force a DHCP discover as it should. 
 

Check out these other Birds-Eye.Net papers/products regarding DHCP:

Products:

• DHCP Stress Testing Suite - The only commercially available DHCP stress testing suite
• DHCP Snoop Agent - The perfect tool to count various types of DHCP packets and more...
• DHCP Custom Packet Generator - A one shot tool for composing, sending, and receiving individual DHCP packets

White Papers and Reading Material

• ABCs of Understanding DHCP Performance - A beginners guide to understanding operation and performance of DHCP servers
• Carrier Class DHCP Testing - Devising a carrier-class test environment to measure near-real-world DHCP performance
• DHCP Filtering - Stopping unwanted DHCP packets before they can damage performance
• DHCP Network Traffic Analysis - What represents "normal" traffic on a large DHCP network?
• DHCP Recommendations - Insight into the first major DHCP deployment and what was going through our heads
• IP Address Management - An introduction to Internet Protocol (IP) address management
• IP Address Provisioning Overview - An introduction to IP address provisioning for data over cable service

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.

(C) Copyright Birds-Eye.Net, All rights reserved.
It is against the law to reproduce this content or any portion of it in any form without the explicit written permission of Birds-Eye Network Services, LLC. Federal copyright law (17 USC 504) makes it illegal, punishable with fines up to $100,000 per violation plus attorney's fees.