Birds-Eye.Net
All things broadband and more...
 
Web Birds-Eye.Net
What's New?

Download Purchased Items

Research:
Analysis
International

Reference:
Acronyms & Definitions
Articles
Broadband Directory
Legacy
Operations
Technical
Yearly Predictions
> RSS Feeds <

Business Forms:
Due Diligence Checklist
Funding & VC Due Diligence
Real Estate Due Diligence

Resources:
Monitoring/Reporting/Benchmarking
Patent Harvesting Kit
Ready to Use Scripts
Source Code

Referral:
Expert Consulting
Referral

Other:
Advertise With Us
Feedback
Recommended Reading
Fishing
House
Baby in the City
Blog

Featured Product:

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.

(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.