(Old) DHCP Benchmarking


The aim is to get a tool to benchmark a DHCP server and one that can be used on both DHCPv4 and Kea.

The tool will benchmark a DHCP server and should, mostly, treat the server as a black box. Where it may have some knowledge of the server is in the configuration data - in particular what leases are available.

For the first version we would like to see results for two items:

  • how many discover (v4) or solicit (v6) messages can be processed per second.
  • how many 4-way packet exchanges (v4 - DORA, v6 - SARR) can be processed per second.

We talked about possible ways to build the tool and the suggestion is to simulate a client for v6 and a relay for v4. In both cases the tool should be able to create and send a flurry of packets and timestamp and process the returns in order to verify that the response was correct and to get timing information. Also in both cases the tool can use a pre-built template packet for both sending and verification. Basically it should take a copy of a packet and modify the id type information (client id, MAC addresses, transaction id etc.) then send the packet and eventually collect the response. (We may be able to skip some of the packet modification if necessary.)

For the discover/solicit test it should be able to send an adjustable number of packets per second and receive and verify the replies then report how many responses made it back and the time frame for those responses. Simply receiving the response isn't sufficient - we need to know when the response arrived to determine how many packets the server can process per second.

For the 4-way exchange it should again be able to send an adjustable number of packets per second, then receive and verify the replies and then send the DHCP request messages and receive and verify those replies. Again we want to get the timing information to see how many full lease exchanges we can perform per second.

In the v6 case you should be able to open and use a standard socket on the correct port and look like a standard client. In the v4 case a client would need to be able to work without an IP address which would complicate the code. Instead you can simulate a relay and use a standard socket - note that you'll need to adjust the server configuration to match the relay information in the packets.

The test program should be written in C and will go into the Bind10 repository. Eventually it should be something that can be automatically invoked - we will probably need to have a pre-built configuration to go along with the test.

Proposed Command Interface

perfdhcp: Execute a performance test against a DHCP server.


perfdhcp [-hv] [-4|-6] [-r<rate>] [-n<num-request>] [-p<test-period>] [-d<drop-time>]
         [-D<max-drop>] [-l<local-addr|interface>] [-i] [-x<diagnostic-selector>] [server]

The [server] argument is the name/address of the DHCP server to contact.  For DHCPv4
operation, exchanges are initiated by transmitting a DHCP DISCOVER to this address.
For DHCPv6 operation, exchanges are initiated by transmitting a DHCP SOLICIT to this
address.  In the DHCPv6 case, the special name "all" can be used to refer to
All_DHCP_Relay_Agents_and_Servers (the multicast address FF02::1:2), or the special name
"servers" to refer to All_DHCP_Servers (the multicast address FF05::1:3).  The [server]
argument is optional only in the case that -l is used to specify an interface, in which
case [server] defaults to "all".

Exchanges are initiated by transmitting a DHCP SOLICIT to
All_DHCP_Relay_Agents_and_Servers (the multicast address FF02::1:2) via this interface.

The default is to perform a single 4-way exchange, effectively pinging the server.
The -r option is used to set up a performance test.

-4: DHCPv4 operation (default). This is incompatible with the -6 option.
-6: DHCPv6 operation. This is incompatible with the -4 option.
-h: Print this help.
-i: Do only the initial part of an exchange: DO or SA, depending on whether -6
    is given.
-l<local-addr|interface>: For DHCPv4 operation, specify the local hostname/address to use
    when communicating with the server.  By default, the interface address through which
    traffic would normally be routed to the server is used.
    For DHCPv6 operation, specify the name of the network interface via which exchanges
    are initiated.
-r<rate>: Initiate <rate> DORA/SARR (or if -i is given, DO/SA) exchanges per
    second.  A periodic report is generated showing the number of exchanges which
    were not completed, as well as the average response latency.  The program
    continues until interrupted, at which point a final report is generated.
-v: Report the version number of this program.
-x<diagnostic-selector>: Include extended diagnostics in the output.
    <diagnostic-selector> is a string of single-keywords specifying the operations
    for which verbose output is desired.  The selector keyletters are:

The remaining options are used only in conjunction with -r:

-d<drop-time>: Specify the time after which a request is treated as having been
    lost.  The value is given in seconds and may contain a fractional
    component.  The default is 1 second.
-D<max-drop>: Abort the test if more than <max-drop> requests have been dropped.
    Use -D0 to abort if even a single request has been dropped.  If <max-drop>
    includes the suffix "%", it specifies a maximum percentage of requests that
    may be dropped before abort.  In this case, testing of the threshold begins
    after 10 requests have been expected to be received.
-n<num-request>: Initiate <num-request> transactions.  No report is generated
    until all transactions have been initiated/waited-for, after which a report
    is generated and the program terminates.
-p<test-period>: Send requests for the given test period, which is specified in
    the same manner as -d.  This can be used as an alternative to -n, or both
    options can be given, in which case the testing is completed when either
    limit is reached.

Exit status:
The exit status is:
0 on complete success.
1 for a general error.
2 if an error is found in the command line arguments.
3 if there are no general failures in operation, but one or more exchanges are not successfully completed.

Proposed Design

The IDs in requests sent to the server are made unique as necessary to track responses. In order to calculate response latency, either a table of transmitted packet IDs with transmit-times or some means of mapping ID to transmit time is used. For a 4-way exchange, the table would separately record the times for the initial and secondary exchange. For simplicity, the IDs used for the two exchanges may have a fixed relationship (e.g. even for initial exchange, odd for the secondary exchange).

Transmission of requests and receipt of responses are multiplexed via select(). If necessary for performance, the program may be converted to multithreaded operation.

The program will generate diagnostics if it is unable to send requests at the requested rate (due to either CPU-resource or network limitations).

The default output will begin with the utility version number and the options the utility was invoked with, to aid in interpretation of results when they are captured and sent to others for analysis.

Note: additional parameters to control the contents of requests may be useful. This will be decided after experience with use.

Last modified 7 years ago Last modified on Dec 2, 2011, 5:35:59 PM