|
DHCP
Network Traffic Analysis
What represents "normal" traffic on a large DHCP
network?
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: June 26, 2005
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].
As DHCP gains increasing acceptance within the networking community and
becomes embedded in everything from wireless network devices to toasters,
the subject of DHCP traffic or more specifically the concern over DHCP
performance is growing. The following discusses some early work done on
analyzing large DHCP networks.
|
DHCP Action |
Peak One Hour Arrival Rate |
Peak Arrival Rate (spikes) |
|
Discovers |
0.83 per second |
4 per second |
|
Request-Selects |
0.61 per second |
3 per second |
|
Request-InitReboots |
0.47 per second |
3 per second |
|
Request-Renews plus Rebinds |
0.21 per second |
2 per second |
|
Releases |
0.19 per second |
2 per second |
Table 1.0 Peak
one-hour DHCP traffic, measured over five days
Table 1.0 describes the actual frequency of DHCP request types measured on a
~20,000 node network. These numbers are based on empirical analysis, assumed
to be in "steady-state" (no network renumbering, no significant outages).
Such data suggests the following steady-state traffic for a ~60,000 node
network (Table 2.0)
|
DHCP Action |
Average Arrival Rate |
Peak Arrival Rate |
|
Discovers |
2.5 per second sustained |
12 per second peak |
|
Request-Selects |
2 per second sustained |
9 per second peak |
|
Request-InitReboots |
1.5 per second sustained |
7 per second peak |
|
Request-Renews +Rebinds |
0.75 per second sustained |
6 per second peak |
|
Releases |
0.75 per second sustained |
6 per second peak |
Table 2.0
Projected Frequency of DHCP Packets for ~60,000 Node Network
One common worst-case scenario for traffic load, particularly DDNS-related
traffic, is network renumbering. Suppose that a renumber (i.e. splits) event
takes place one network at a time, so that half of the subscribers in the
original network will land in a new IP subnet. Network providers have
subnets consisting of one, two, and four Class C address blocks, but an
assumption is made that split take place on a two Class C-block network,
affecting 250 subscriber machines. A reasonable requirement is that DHCP and
DNS need to absorb this renumbering (250 subscribers) within one "network
operations window", i.e. within 1.5 to 2 hours. There should be an
expectation on the DHCP/DDNS server such that the actual number of computers
affected in the renumbered subnet to be approximately 40 since this
corresponds to the 15% “always-on” subscriber subset.
Offending
devices
NT
RAS Servers
A significant percentage
of DHCP traffic is generated by Windows NT RAS servers which can be
greatly reduced with a simple redirect of such requests that assigns
these addresses a “127 network” address – thus effectively silencing
the RAS server.
Cable modems
A significant percentage of broadcast traffic is generated by a small number
of mis-behaving cable modems (constant reboots or those that have be
unregistered but remain connected to the network). This traffic can be
caught and discarded by a well designed DHCP filter.
Macintoshes
A significant percentage
of DHCP Discover and Release traffic is generated by Macintosh
clients. Macintosh clients on average generate four times as much
traffic per device as Windows DHCP clients. The behavior of Dynamic
DNS Updates should be designed to absorb the frequency of these
requests. There may also be configuration changes possible on the
client side (performed during subscriber installation) that could be
completed to reduce the impact of this traffic.
Rogue DHCP servers
Cable modems or the customer installed access device provides isolation for
this type of event. On enterprise networks, such events may still be
possible in which case, such events must be recorded or trigger some type of
network monitoring event (for example send trap to network management
system). Logging the event is the bare minimum but in most cases simply
logging the event is useless.
Configuration issues
Excessive broadcasts based on sub-optimal renew/rebind times
Examination of current DHCP logs
indicate that DHCP rebind times are being set to a smaller time than the
DHCP renewal times. This results in rebinds occurring more frequently than
renews. It also ensures that network renumbering will work. However, this is
at the cost of much higher broadcast traffic since rebinds are broadcast and
renews are unicast.
A simple solution here is to set
the rebind time to a value just slightly higher than the renew time (i.e. 20
seconds). This ensures lower broadcast traffic with support for renumbering.
User Interface traffic analysis
The following requirements have
been identified as performance issues in the command line interface.
Interfacing with DHCP server is required on various aspects including lease
particular look ups and configuration inquiries and changes on the fly. No
existing network will be resized on the fly, only new networks will be added
simplifying the network renumbering events.
Summary
The load on a DHCP server will vary depending on the type of network it is
operating in as well as based on the skill in its operator to understand the
type of clients the DHCP server is configuring. Constructing proper filters
and other configurations can greatly improve the performance of a DHCP
server on a large network. However, depending on the ultimate requirement of
the server needing to remember the on-going lease particulars, commitment of
all details of transactions between client and server to the DHCP database
will ultimately define maximum transaction throughput that is possible.
Check out these other Birds-Eye.Net papers/products regarding DHCP:
Products:
White Papers and Reading Material
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.
|