The aim is to get a tool to benchmark a DHCP server and one that can be used on both DHCPv4, DHCPv6 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 (note: only the length is checked today) and to get timing information. Also in both cases the tool can use a pre-built template packet for both sending and verification (sending only today, verification is hard). Basically it should take a copy of a packet and modify the id type information (client id, MAC addresses, transaction id etc., note: transaction id (aka. id) is always random) then send the packet and eventually (note: always) collect the response. (We may be able to skip some of the packet modification if necessary. note: and it is)
For the discover/solicit test it should be able to send an adjustable number of packets per second and receive and verify (see above) 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 (see above) and then send the DHCP request messages and receive and verify (see above again) 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 can 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 (tests/tools/perfdhcp/). 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 (not yet provided).
Current Command Interface
perfdhcp [-hv] [-4|-6] [-e<lease-type>] [-r<rate>] [-f<renew-rate>] [-t<report>] [-R<range>] [-b<base>] [-n<num-request>] [-p<test-period>] [-d<drop-time>] [-D<max-drop>] [-l<local-addr|interface>] [-P<preload>] [-a<aggressivity>] [-L<local-port>] [-s<seed>] [-i] [-B] [-c] [-1] [-T<template-file>] [-X<xid-offset>] [-O<random-offset] [-E<time-offset>] [-S<srvid-offset>] [-I<ip-offset>] [-x<diagnostic-selector>] [-w<wrapped>] [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'. 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, without it exchanges are initiated as fast as possible. Options: -1: Take the server-ID option from the first received message. -4: DHCPv4 operation (default). This is incompatible with the -6 option. -6: DHCPv6 operation. This is incompatible with the -4 option. -a<aggressivity>: When the target sending rate is not yet reached, control how many exchanges are initiated before the next pause. -b<base>: The base mac, duid, IP, etc, used to simulate different clients. This can be specified multiple times, each instance is in the <type>=<value> form, for instance: (and default) mac=00:0c:01:02:03:04. -d<drop-time>: Specify the time after which a requeqst is treated as having been lost. The value is given in seconds and may contain a fractional component. The default is 1 second. -e<lease-type>: A type of lease being requested from the server. It may be one of the following: address-only, prefix-only or address-and-prefix. The address-only indicates that the regular address (v4 or v6) will be requested. The prefix-only indicates that the IPv6 prefix will be requested. The address-and-prefix indicates that both IPv6 address and prefix will be requested. The '-e prefix-only' and -'e address-and-prefix' must not be used with -4. -E<time-offset>: Offset of the (DHCPv4) secs field / (DHCPv6) elapsed-time option in the (second/request) template. The value 0 disables it. -h: Print this help. -i: Do only the initial part of an exchange: DO or SA, depending on whether -6 is given. -I<ip-offset>: Offset of the (DHCPv4) IP address in the requested-IP option / (DHCPv6) IA_NA option in the (second/request) template. -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. -L<local-port>: Specify the local port to use (the value 0 means to use the default). -O<random-offset>: Offset of the last octet to randomize in the template. -P<preload>: Initiate first <preload> exchanges back to back at startup. -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. -R<range>: Specify how many different clients are used. With 1 (the default), all requests seem to come from the same client. -s<seed>: Specify the seed for randomization, making it repeatable. -S<srvid-offset>: Offset of the server-ID option in the (second/request) template. -T<template-file>: The name of a file containing the template to use as a stream of hexadecimal digits. -v: Report the version number of this program. -w<wrapped>: Command to call with start/stop at the beginning/end of the 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: * 'a': print the decoded command line arguments * 'e': print the exit reason * 'i': print rate processing details * 's': print first server-id * 't': when finished, print timers of all successful exchanges * 'T': when finished, print templates -X<xid-offset>: Transaction ID (aka. xid) offset in the template. DHCPv4 only options: -B: Force broadcast handling. DHCPv6 only options: -c: Add a rapid commit option (exchanges will be SA). -f<renew-rate>: A rate at which IPv6 Renew requests are sent to a server. This value must be equal or lower than the rate specified as -r<rate>. If -r<rate> is not specified, this parameter must not be specified too. The remaining options are used only in conjunction with -r: -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. -t<report>: Delay in seconds between two periodic reports. Errors: - tooshort: received a too short message - orphans: received a message which doesn't match an exchange (duplicate, late or not related) - locallimit: reached to local system limits when sending a message. 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.
Remarks on current implementation
As of September 26, 2012 there is a refactored version of perfdhcp available on the master branch of bind10. It is written in C++ and comes with a set of unit tests. The latest version (September 26, 2013) not only does support IPv6 address but also IPv6 prefix acqusition (controlled with the -e command line option).