DHCP Performance Guide

Tomasz Mrugalski

Marcin Siodelski

This is a companion document for BIND 10 version - 20120712.

Abstract

BIND 10 is a framework that features Domain Name System +DHCP Performance Guide

DHCP Performance Guide

Tomasz Mrugalski

Marcin Siodelski

This is a companion document for BIND 10 version + 20120817.

Abstract

BIND 10 is a framework that features Domain Name System (DNS) suite and Dynamic Host Configuration Protocol (DHCP) servers with development managed by Internet Systems Consortium (ISC). This document describes various aspects of DHCP performance, measurements and tuning. It covers BIND 10 DHCP (codename Kea), existing ISC DHCP4 software, perfdhcp (a DHCP performance - measurement tool) and other related topics.

List of Tables

3.1. Synchronous results
3.2. Asynchronous results
3.3. Estimated performance

Preface

Table of Contents

Acknowledgements

Acknowledgements

ISC would like to acknowledge generous support for + measurement tool) and other related topics.

List of Tables

3.1. Synchronous results
3.2. Asynchronous results
3.3. Estimated performance

Preface

Table of Contents

1. Acknowledgements

1. Acknowledgements

ISC would like to acknowledge generous support for BIND 10 development of DHCPv4 and DHCPv6 components provided - by Comcast.

Chapter 1. Introduction

+ by Comcast.

Chapter 1. Introduction

This document is in its early stages of development. It is expected to grow significantly in a near future. It will cover topics like database backend perfomance measurements, pros an cons of various optimization techniques and tools. -

Chapter 2. ISC DHCP 4.x

TODO: Write something about ISC DHCP4 here. -

Chapter 3. Kea

Table of Contents

Backend performance evaluation

MySQL backend

MySQL tweaks

SQLite-ubench

SQLite tweaks

memfile-ubench

memfile tweaks

Performance measurements

Possible further optimizations

Chapter 3. Kea

Table of Contents

3.1. Backend performance evaluation

3.2. MySQL backend

3.2.1. MySQL tweaks

3.3. SQLite-ubench

3.3.1. SQLite tweaks

3.4. memfile-ubench

3.4.1. memfile tweaks

3.5. Performance measurements

3.6. Possible further optimizations

Backend performance evaluation

3.1. Backend performance evaluation

Kea will support several different database backends, using both popular databases (like MySQL or SQLite) and custom-developed solutions (like in-memory database). BIND 10 @@ -64,7 +62,7 @@

The framework attempts to do the same amount of operations for every backend thus allowing fair complarison between them. -

MySQL backend

MySQL backend requires MySQL client development libraries. It uses +

3.2. MySQL backend

MySQL backend requires MySQL client development libraries. It uses mysql_config tool (that works similar to pkg-config) to discover required compilation and linking options. To install required packages on Ubuntu, use the following command: @@ -113,13 +111,13 @@ Possible command-line parameters: -c yes|no - should compiled statements be used (MySQL only)

MySQL tweaks

One parameter that has huge impact on performance is a a backend engine. +

3.2.1. MySQL tweaks

One parameter that has huge impact on performance is a a backend engine. You can get a list of engines of your MySQL implementation by using

> show engines;

in your mysql client. Two notable engines are MyISAM and InnoDB. mysql_ubench will - use MyISAM for synchronous mode and InnoDB for asynchronous.

SQLite-ubench

SQLite backend requires both sqlite3 development and run-time package. Their + use MyISAM for synchronous mode and InnoDB for asynchronous.

3.3. SQLite-ubench

SQLite backend requires both sqlite3 development and run-time package. Their names may vary from system to system, but on Ubuntu 12.04 they are called sqlite3 libsqlite3-dev. To install them, use the following command: @@ -134,7 +132,7 @@ Possible command-line parameters:

> ./sqlite_ubench

> ./sqlite_ubench > results-sqlite.txt

SQLite tweaks

To modify default sqlite_ubench parameters, command line +

3.3.1. SQLite tweaks

To modify default sqlite_ubench parameters, command line switches can be used. Currently supported parameters are (default values specified in brackets):

-f filename - name of the database file ("sqlite.db")
-n num - number of iterations (100)
-s yes|no - should the operations be performend in synchronous (yes) @@ -145,13 +143,13 @@ Possible command-line parameters: turned to several modes of operation. Its value can be modified in SQLite_uBenchmark::connect(). See http://www.sqlite.org/pragma.html#pragma_journal_mode for - detailed explanantion.

memfile-ubench

Memfile backend is custom developed prototype backend that + detailed explanantion.

3.4. memfile-ubench

Memfile backend is custom developed prototype backend that somewhat mimics operation of ISC DHCP4. It uses in-memory storage using standard C++ and boost mechanisms (std::map and boost::shared_ptr<>). All database changes are also written to a lease file. That file is strictly write-only. This approach takes advantage of the fact that simple append is faster - than edition with potential whole file relocation.

memfile tweaks

To modify default memfile_ubench parameters, command line + than edition with potential whole file relocation.

3.4.1. memfile tweaks

To modify default memfile_ubench parameters, command line switches can be used. Currently supported parameters are (default values specified in brackets):

-f filename - name of the database file ("dhcpd.leases")
-n num - number of iterations (100)
-s yes|no - should the operations be performend in synchronous (yes) @@ -159,7 +157,7 @@ Possible command-line parameters:
memfile can run in asynchronous or synchronous mode. This mode can be controlled by using sync parameter. It uses fflush() and fsync() in synchronous mode to make sure that - data is not buffered and physically stored on disk.

Performance measurements

This section contains sample results for backend performance measurements, + data is not buffered and physically stored on disk.

3.5. Performance measurements

This section contains sample results for backend performance measurements, taken using microbenchmarks. Tests were conducted on reasonably powerful machine:

 CPU: Quad-core Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (8 logical cores)
@@ -172,13 +170,13 @@ SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe7
       asynchronous. As those modes offer radically different
       performances, synchronous mode was conducted for 1000 (one
       thousand) repetitions and asynchronous mode was conducted for
-      100000 (hundred thousand) repetitions.
Table 3.1. Synchronous results
Backend Operations Create Search Update Delete Average
MySQL 1000 31.603978s  0.116612s 27.964191s 27.695209s 21.844998s
SQLite 1000 61.421356s  0.033283s 59.476638s 56.034150s 44.241357s
memfile 1000 41.711886s  0.000724s 42.267578s 42.169679s 31.537467s

Following parameters were measured for asynchronous mode.
+      100000 (hundred thousand) repetitions.
Table 3.1. Synchronous results
Backend Operations Create Search Update Delete Average
MySQL 1000 31.603978s  0.116612s 27.964191s 27.695209s 21.844998s
SQLite 1000 61.421356s  0.033283s 59.476638s 56.034150s 44.241357s
memfile 1000 41.711886s  0.000724s 42.267578s 42.169679s 31.537467s

Following parameters were measured for asynchronous mode.
       MySQL and SQLite were run with 100 thousand repetitions. Memfile
-      was run for 1 million repetitions due to much larger performance.
Table 3.2. Asynchronous results
Backend Operations Create [s] Search [s] Update [s] Delete [s] Average [s]
MySQL 100000 10.584842s 10.386402s 10.062384s  8.890197s  9.980956s
SQLite 100000  3.710356s  3.159129s  2.865354s  2.439406s  3.043561s
memfile 1000000 (sic!)  6.084131s  0.862667s  6.018585s  5.146704s  4.528022s

Presented performance results can be computed into operations per second metrics.
+      was run for 1 million repetitions due to much larger performance.
Table 3.2. Asynchronous results
Backend Operations Create [s] Search [s] Update [s] Delete [s] Average [s]
MySQL 100000 10.584842s 10.386402s 10.062384s  8.890197s  9.980956s
SQLite 100000  3.710356s  3.159129s  2.865354s  2.439406s  3.043561s
memfile 1000000 (sic!)  6.084131s  0.862667s  6.018585s  5.146704s  4.528022s

Presented performance results can be computed into operations per second metrics.
       It should be noted that due to large differences between various operations (sometime
       over 3 orders of magnitude), it is difficult to create a simple, readable chart with
-      that data.
Table 3.3. Estimated performance
Backend Create [oper/s] Search [oper/s] Update [oper/s] Delete [oper/s] Average [oper/s]
MySQL (async) 9447.47 9627.97 9938.00 11248.34 10065.45
SQLite (async) 26951.59 31654.29 34899.70 40993.59 33624.79
memfile (async) 164362.01 1159195.84 166152.01 194299.11 421002.24
MySQL (sync) 31.64 8575.45 35.76 36.11 2169.74
SQLite (sync) 16.28 20045.37 16.81 17.85 7524.08
memfile (sync) 23.97 1381215.47 23.66 23.71 345321.70

Graphical representation of the performance results
-          presented in table Table 3.3, “Estimated performance”.

Backend	Operations	Create	Search	Update	Delete	Average
MySQL	1000	31.603978s	0.116612s	27.964191s	27.695209s	21.844998s
SQLite	1000	61.421356s	0.033283s	59.476638s	56.034150s	44.241357s
memfile	1000	41.711886s	0.000724s	42.267578s	42.169679s	31.537467s

Backend	Operations	Create	Search	Update	Delete	Average
MySQL	1000	31.603978s	0.116612s	27.964191s	27.695209s	21.844998s
SQLite	1000	61.421356s	0.033283s	59.476638s	56.034150s	44.241357s
memfile	1000	41.711886s	0.000724s	42.267578s	42.169679s	31.537467s

Backend	Operations	Create [s]	Search [s]	Update [s]	Delete [s]	Average [s]
MySQL	100000	10.584842s	10.386402s	10.062384s	8.890197s	9.980956s
SQLite	100000	3.710356s	3.159129s	2.865354s	2.439406s	3.043561s
memfile	1000000 (sic!)	6.084131s	0.862667s	6.018585s	5.146704s	4.528022s

Backend	Operations	Create [s]	Search [s]	Update [s]	Delete [s]	Average [s]
MySQL	100000	10.584842s	10.386402s	10.062384s	8.890197s	9.980956s
SQLite	100000	3.710356s	3.159129s	2.865354s	2.439406s	3.043561s
memfile	1000000 (sic!)	6.084131s	0.862667s	6.018585s	5.146704s	4.528022s

Possible further optimizations

+ that data.

Table 3.3. Estimated performance

Backend	Create [oper/s]	Search [oper/s]	Update [oper/s]	Delete [oper/s]	Average [oper/s]
MySQL (async)	9447.47	9627.97	9938.00	11248.34	10065.45
SQLite (async)	26951.59	31654.29	34899.70	40993.59	33624.79
memfile (async)	164362.01	1159195.84	166152.01	194299.11	421002.24
MySQL (sync)	31.64	8575.45	35.76	36.11	2169.74
SQLite (sync)	16.28	20045.37	16.81	17.85	7524.08
memfile (sync)	23.97	1381215.47	23.66	23.71	345321.70

Graphical representation of the performance results + presented in table Table 3.3, “Estimated performance”.

3.6. Possible further optimizations

For debugging purposes the code was compiled with -g -O0 flags. While majority of the time was spent in backend functions (that was probably compiled with -O2 flags), the @@ -196,54 +194,51 @@ SQLite version: 3.7.9sourceid version is 2011-11-01 00:52:41 c7c6050ef060877ebe7 Multi-threaded or multi-process benchmark may be considered in the future. It may be somewhat difficult as only some backends support concurrent access. -

Chapter 4. perfdhcp

Table of Contents

Purpose

Key features

Command line options

Starting perfdhcp

perfdhcp command line examples

Example: basic usage
Example: rate control
Example: templates

Purpose

- There is a growing need to evaluate performance of DHCP servers in - different traffic conditions to understand their bottle necks. - This helps to elimante bugs in existing DHCP software as well - as make informed decisions regarding new DHCP software designs - to significantly improve its performance. The perfdhcp tool has - been created to fill the gap in performance measurement capabilities - mostly. However, the number of implemented features and parameters - exposed to the user make this tool useful for functional testing as - well. -

Key features

- The perfdhcp exposes the number of command line parameters to - control DHCP message exchanges. Currently they fall back to +

Chapter 4. perfdhcp

Table of Contents

4.1. Purpose

4.2. Key features

4.3. Command line options

4.4. Starting perfdhcp

4.5. perfdhcp command line examples

4.5.1. Example: basic usage
4.5.2. Example: rate control
4.5.3. Example: templates

4.1. Purpose

+ Evaluation of the performance of a DHCP server requires that it + be tested under varying traffic loads. perfdhcp is a testing + tool with the capability to create traffic loads + and generate statistics from the results. Additional features, + such as the ability to send customised DHCP packets, allow it to + be used in a wide range of functional testing. +

4.2. Key features

+ perfdhcp has a number of command line switches to + control DHCP message exchanges. Currently they fall into the following categories: -

+
- Rate control - control how many DHCP exchanges - are initiated within a period of time. Tool can also simulate - best effort conditions attempting to initiate as many DHCP - packet exchanges within a unit of time as possible. + are initiated within a period of time. The tool can also simulate + best effort conditions by attempting to initiate as many DHCP + packet exchanges as possible within a unit of time.
- - Test exit specifiers - control the conditions when test - completes including number of initiated exchanges, test period or - maximum number of dropped packets. + Test exit specifiers - control the conditions for test + completion, including the number of initiated exchanges, + the test period orthe maximum number of dropped packets.
- Packet templates - specify files containing packet templates that - are used by perfdhcp to create custom DHCP messages instead of - default. Tool also allows to specify number of values indicating - offsets of variable values within a packet that are modified in - flight by the tool. + are used by perfdhcp to create custom DHCP messages. The tool + allows the specification of a number of values indicating + offsets of values within a packet that are set by the tool.
- - Reporting - for each test produce the set of performance data - including achieved packet exchange rate (server performance). - There is also a number of diagnostic selectors available that - enable periodic (intermediate) reporting, packet timestamps - printing and detailed information about perfdhcp internal + Reporting - for each test produce a set of performance data + including the achieved packet exchange rate (server performance). + There are a number of diagnostic selectors available that + enable periodic (intermediate) reporting, printing of packet timestamps, + and the listing of detailed information about internal perfdhcp states (for debugging).
- - Different mode of operations - specify DHCP version used - (v4 or v6), 2-way or 4-way exchanges, use Rapid Commit option - for DHCPv6. + Different mode of operations - specify the DHCP protocol used + (v4 or v6), two-way or four-way exchanges, use of the + Rapid Commit option for DHCPv6.
- - IP layer options - specify local/remote address, local interface + IP layer options - specify the local/remote address, local interface and local port to be used for communication with DHCP server. -

Command line options

- The following command line options may be used with perfdhcp tool. - This summary also presents its possible exit codes as well as - error counters printed along when test is complete: +

4.3. Command line options

+ The following "help" output from the tool describes the + command line switches. This summary also lists the tool's + possible exit codes as well as describing the + error counters printed when the test is complete:

$ ./perfdhcp -h
 perfdhcp [-hv] [-4|-6] [-r<rate>] [-t<report>] [-R<range>] [-b<base>]
     [-n<num-request>] [-p<test-period>] [-d<drop-time>] [-D<max-drop>]
@@ -367,47 +362,51 @@ The exit status is:
   exchanges are not successfully completed.

Starting perfdhcp

- In order to run performance test at least two separate systems - have to be installed: client and server. The first one has to have - perfdhcp tool installed, the latter has to have DHCP server - running (v4 or v6). If only single system is available the client +

4.4. Starting perfdhcp

+ In order to run a performance test, at least two separate systems + have to be installed: client and server. The first one must have + perfdhcp installed, and the latter must be running the DHCP server + (either v4 or v6). If only single system is available the client and server can be run on virtual machines (running on the same - phisical system) but in this case performance data may be heavily - impacted by the performance of VMs. + physical system) but in this case performance data may be heavily + impacted by the overhead involved in running such the virtual + machines.

- The DHCP operates on low port numbers (67 for DHCPv4 relays and - 547 for DHCPv6). Running perfdhcp with non-root priviliges will + Currently, perfdhcp is seen from the server perspective as relay agent. + This simplifies its implementation: specifically there is no need to + receive traffic sent to braodcast addresses. However, it does impose + a requirement that the IPv4 + address has to be set manually on the interface that will be used to + communicate with the server. For example, if the DHCPv4 server is listening + on the interface connected to the 172.16.1.0 subnet, the interface on client + machine has to have network address assigned from the same subnet, e.g. +

#ifconfig eth3 172.16.1.2. netmask 255.255.255.0 up

+ As DHCP uses low port numbers (67 for DHCPv4 relays and + 547 for DHCPv6), running perfdhcp with non-root privileges will usually result in the error message similar to this: +

$./perfdhcp -4 -l eth3 -r 100 all
 Error running perfdhcp: Failed to bind socket 3 to 172.16.1.2/port=67

- perfdhcp has the '-L' command line option that - imposes use of custom local port. Thus the following command - line will work: + + The '-L' command line switch allows the use of a custom local port. + However, although the following command line will work: +

$./perfdhcp -4 -l eth3 -r 100 -L 10067 all

- but in the standard configuration no responses will be received - from the ISC DHCP server because server responds to default relay - port 67. - Alternative way to overcome this issue is to run perfdhcp as root. -

- Currently, perfdhcp is seen from the server perspective as relay agent. - This simplifies its implementation (specifically there is no need to - receive traffic sent to braodcast addresses). This imposes that IPv4 - address has to be set manually on the interface that will be used to - communicate with the server. For example, if DHCPv4 server is listening - on the interface connected to 172.16.1.0 subnet, interface on client - machine has to have network address assigned from the same subnet - on one of its interfaces connected to this subnet: -

#ifconfig eth3 172.16.1.2. netmask 255.255.255.0 up

perfdhcp command line examples

- In this section the perfdhcp command line examples + + in the standard configuration no responses will be received + from the DHCP server because the server responds to default relay + port 67. A way to overcome this issue is to run + perfdhcp as root. +

4.5. perfdhcp command line examples

+ In this section, a number of perfdhcp command line examples are presented as a quick start guide for new users. For the detailed list of command line options refer to - the section called “Command line options”. -

Example: basic usage

- If server is listening on interface with IPv4 address 172.16.1.1 - the simpliest perfdhcp command line will look like this: + Section 4.3, “Command line options”. +

4.5.1. Example: basic usage

+ If server is listening on interface with IPv4 address 172.16.1.1, + the simplest perfdhcp command line will look like:

#./perfdhcp 172.16.1.1
 ***Rate statistics***
 Rate: 206.345
@@ -436,15 +435,13 @@ max delay: 258.634 ms
 std deviation: 56.936 ms
 collected packets: 0

- In this case perfdhcp will use remote address 172.16.1.1 as a - destination address and will use suitable local interface for - communication. Since, no rate control parameters have been specified - it will be initiating DHCP exchanges with the maximum possible - rate (it will try to initiate maximum number of exchanges per - second and count number of completed exchanged). Due to server's - performance constraints, many DHCP packets sent to server are likely - to be dropped. The performance test will be running until it is - not interrupted by the user (with ^C). + Here, perfdhcp uses remote address 172.16.1.1 as a + destination address and will use a suitable local interface for + communication. Since, no rate control parameters have been specified, + it will initiate DHCP exchanges at the maximum possible rate. Due to the server's + performance limitation, it is likely that many of the packets will be dropped. + The performance test will continue running until it is + interrupted by the user (with ^C).

The default performance statistics reported by perfdhcp have the following meaning: @@ -453,40 +450,44 @@ collected packets: 0 completed within a second.

sent packets - total number of DHCP packets of a specific type sent to the server.

received packets - total number of DHCP packets of specific type received from the server.

drops - number of dropped packets for the - particular exchange. Number of dropped packets is calculated as - a difference between number of sent packets and number of - response packets received from the server. It is likely that - server sent the reponse but perfdhcp execution had ended before - reponse arrived. In such case this packet will be assumed - dropped.

orphans - number of packets that have been + particular exchange. The number of dropped packets is calculated as + the difference between the number of sent packets and number of + response packets received from the server. In some cases, the + server will have sent a reponse but perfdhcp execution ended before + the reponse arrived. In such case this packet will be counted + as dropped.

orphans - number of packets that have been received from the server and did not match any packet sent by perfdhcp. This may occur if received packet has been sent - to some other host or if exchange time out has occured and - has been been garbage collected.

min delay - minimum delay that occured between - sending the packet to the server and receiving reponse from + to some other host or if then exchange timed out and + the sent packet was removed from perfdhcp's list of packets + awaiting a response.

min delay - minimum delay that occured between + sending the packet to the server and receiving a reponse from it.

avg delay - average delay between sending the - packet of the specific type the server and receiving response - from it.

max delay - maximum delat that occured between - sedning the packet to the server and receiveing response from - it.

std deviation - standard deviation of delay + packet of the specific type the server and receiving a response + from it.

max delay - maximum delay that occured between + sending the packet to the server and receiving a response from + it.

std deviation - standard deviation of the delay between sending the packet of a specific type to the server and - receiving response from it.

collected packets - number of garbage collected - sent packets. Packets may get garbage collected when waiting time - for server response exceeds value set with + receiving response from it.

collected packets - number of sent packets that + were garbage collected. Packets may get garbage collected when + the waiting time for server a response exceeds value set with the + '-d' (drop time) switch. -d<drop-time>.

- perfdhcp allows to run the test using specified interface: + Note: should multiple interfaces on the system running perfdhcp be + connected to the same subnet, the interface to be used for the test + can be specified using either the interface name:

#./perfdhcp -l eth3

- or local address assigned to it: + or a local address assigned to it:

#./perfdhcp -l 172.16.1.2

Example: rate control

- In the examples above perfdhcp initiates new exchanges with best - effort rate. In this case many packets is expected to be dropped by the - server due to performance limitations. Many times it is desired to set - the expected (reasonable) rate and verify if generated traffic is - handled without packet dropes by DHCP server. The following command will - make perfdhcp to initiate 300 4-way exchanges per second and test will - last for 60 seconds: +

4.5.2. Example: rate control

+ In the examples above perfdhcp initiates new exchanges with a best + effort rate. With this setting, many packets are expected to be dropped + by the server due to performance limitations. In many cases though, it is + desired to verify that the server can handle an expected (reasonable) rate + without dropping any packets. The following command is an example of such + a test: it causes perfdhcp to initiate 300 four-way exchanges + per second, and runs the test for 60 seconds:

#./perfdhcp -l eth3 -p 60 -r 300
 ***Rate statistics***
 Rate: 256.683 exchanges/second, expected rate: 300 exchanges/second
@@ -515,12 +516,13 @@ max delay: 576.749 ms
 std deviation: 58.189 ms
 collected packets: 0

- Note that in this example the packet drops have been significantly - reduced thanks to setting reasonable rate. The non-zero number of - packet drops and achived rate (256/s) below expected rate (300/s) - indicate that server's measured performance is lower than 300 leases - per second. Further rate decrease should eliminate most of the packet - drops and bring achived rate close to expected rate: + Note that here, the packet drops for the DISCOVER-OFFER + exchange have been significantly reduced (when compared with the + output from the previous example) thanks to the setting of a + reasonable rate. The non-zero number of packet drops and achieved + rate (256/s) indicate that server's measured performance is lower than 300 leases + per second. A further rate decrease should eliminate most of the packet + drops and bring the achieved rate close to expected rate:

#./perfdhcp -l eth3 -p 60 -r 100 -R 30
 ***Rate statistics***
 Rate: 99.8164 exchanges/second, expected rate: 100 exchanges/second
@@ -549,21 +551,24 @@ max delay: 189.658 ms
 std deviation: 5.876 ms
 collected packets: 0

+ There are now no packet drops, confirming that the server is able to + handle a load of 100 leases/second. Note that the last parameter (-R 30) configures perfdhcp to simulate - traffic from distinct 30 clients. -

Example: templates

- By default the DHCP messages are formed in-flight with default options. - If desired, there is a way to define custom packet format with template - files. Content in template files is encoded in hexadecimal format. The + traffic from 30 distinct clients. +

4.5.3. Example: templates

+ By default the DHCP messages are formed with default options. With + template files, it is possible to define a custom packet format. +

+ The content in template files is encoded in hexadecimal format. perfdhcp forms the packet by replacing parts of the binary stream read - from the file with variable data such as elapsed time, HW address, DUID + from the file with variable data such as elapsed time, hardware address, DUID etc. The offsets where such variable data is placed is specific to the template file and have to be specified from the command line. Refer to - the section called “Command line options” to find out how to + Section 4.3, “Command line options” to find out how to specify offsets for particular options and fields. With the following command line the DHCPv6 SOLICIT and REQUEST packets will be formed from - solicit-example.hex and request6-example.hex packets: -

#./perfdhcp -6 -l eth3 -r 100 -R 20 -T templates/solicit-example.hex -T templates/request6-example.hex -O 21 -E 84 -S 22 -I 40 servers
+          solicit.hex and request6.hex packets:
+          
#./perfdhcp -6 -l eth3 -r 100 -R 20 -T solicit.hex -T request6.hex -O 21 -E 84 -S 22 -I 40 servers
 ***Rate statistics***
 Rate: 99.5398 exchanges/second, expected rate: 100 exchanges/second
 
@@ -591,10 +596,10 @@ max delay: 6.490 ms
 std deviation: 0.518 ms
 collected packets: 0
           

-          where:
+          where the switches have the following meaning:
           
two occurences of -O 21 - DUID's last octet
-            positions in SOLICIT and REQUEST respectively.
-E 84 - elapsed time option position in
-            REQUEST template
-S 22 - server id position in REQUEST
-            template
-I 40 - IA_NA option position in REQUEST
+            positions in SOLICIT and REQUEST respectively.
-E 84 - elapsed time option position in the
+            REQUEST template
-S 22 - server id position in the REQUEST
+            template
-I 40 - IA_NA option position in the REQUEST
             template

-

\ No newline at end of file +

Command line options - The following command line options may be used with perfdhcp tool. - This summary also presents its possible exit codes as well as - error counters printed along when test is complete: + The following "help" output from the tool describes the + command line switches. This summary also lists the tool's + possible exit codes as well as describing the + error counters printed when the test is complete: $ ./perfdhcp -h ] [-t] [-R] [-b] [-n] [-p] [-d] [-D] @@ -794,46 +791,51 @@ The exit status is:

Starting perfdhcp - In order to run performance test at least two separate systems - have to be installed: client and server. The first one has to have - perfdhcp tool installed, the latter has to have DHCP server - running (v4 or v6). If only single system is available the client + In order to run a performance test, at least two separate systems + have to be installed: client and server. The first one must have + perfdhcp installed, and the latter must be running the DHCP server + (either v4 or v6). If only single system is available the client and server can be run on virtual machines (running on the same - phisical system) but in this case performance data may be heavily - impacted by the performance of VMs. + physical system) but in this case performance data may be heavily + impacted by the overhead involved in running such the virtual + machines. + + + Currently, perfdhcp is seen from the server perspective as relay agent. + This simplifies its implementation: specifically there is no need to + receive traffic sent to braodcast addresses. However, it does impose + a requirement that the IPv4 + address has to be set manually on the interface that will be used to + communicate with the server. For example, if the DHCPv4 server is listening + on the interface connected to the 172.16.1.0 subnet, the interface on client + machine has to have network address assigned from the same subnet, e.g. + #ifconfig eth3 172.16.1.2. netmask 255.255.255.0 up - The DHCP operates on low port numbers (67 for DHCPv4 relays and - 547 for DHCPv6). Running perfdhcp with non-root priviliges will + As DHCP uses low port numbers (67 for DHCPv4 relays and + 547 for DHCPv6), running perfdhcp with non-root privileges will usually result in the error message similar to this: + $./perfdhcp -4 -l eth3 -r 100 all Error running perfdhcp: Failed to bind socket 3 to 172.16.1.2/port=67 - perfdhcp has the '-L' command line option that - imposes use of custom local port. Thus the following command - line will work: + + The '-L' command line switch allows the use of a custom local port. + However, although the following command line will work: + $./perfdhcp -4 -l eth3 -r 100 -L 10067 all - but in the standard configuration no responses will be received - from the ISC DHCP server because server responds to default relay - port 67. - Alternative way to overcome this issue is to run perfdhcp as root. - - - Currently, perfdhcp is seen from the server perspective as relay agent. - This simplifies its implementation (specifically there is no need to - receive traffic sent to braodcast addresses). This imposes that IPv4 - address has to be set manually on the interface that will be used to - communicate with the server. For example, if DHCPv4 server is listening - on the interface connected to 172.16.1.0 subnet, interface on client - machine has to have network address assigned from the same subnet - on one of its interfaces connected to this subnet: - #ifconfig eth3 172.16.1.2. netmask 255.255.255.0 up + + in the standard configuration no responses will be received + from the DHCP server because the server responds to default relay + port 67. A way to overcome this issue is to run + perfdhcp as root. +

perfdhcp command line examples - In this section the perfdhcp command line examples + In this section, a number of perfdhcp command line examples are presented as a quick start guide for new users. For the detailed list of command line options refer to . @@ -841,8 +843,8 @@ Error running perfdhcp: Failed to bind socket 3 to 172.16.1.2/port=67

Example: basic usage - If server is listening on interface with IPv4 address 172.16.1.1 - the simpliest perfdhcp command line will look like this: + If server is listening on interface with IPv4 address 172.16.1.1, + the simplest perfdhcp command line will look like: #./perfdhcp 172.16.1.1 ***Rate statistics*** Rate: 206.345 @@ -871,15 +873,13 @@ max delay: 258.634 ms std deviation: 56.936 ms collected packets: 0 - In this case perfdhcp will use remote address 172.16.1.1 as a - destination address and will use suitable local interface for - communication. Since, no rate control parameters have been specified - it will be initiating DHCP exchanges with the maximum possible - rate (it will try to initiate maximum number of exchanges per - second and count number of completed exchanged). Due to server's - performance constraints, many DHCP packets sent to server are likely - to be dropped. The performance test will be running until it is - not interrupted by the user (with ^C). + Here, perfdhcp uses remote address 172.16.1.1 as a + destination address and will use a suitable local interface for + communication. Since, no rate control parameters have been specified, + it will initiate DHCP exchanges at the maximum possible rate. Due to the server's + performance limitation, it is likely that many of the packets will be dropped. + The performance test will continue running until it is + interrupted by the user (with ^C). The default performance statistics reported by perfdhcp have the @@ -893,52 +893,56 @@ collected packets: 0 received packets - total number of DHCP packets of specific type received from the server. drops - number of dropped packets for the - particular exchange. Number of dropped packets is calculated as - a difference between number of sent packets and number of - response packets received from the server. It is likely that - server sent the reponse but perfdhcp execution had ended before - reponse arrived. In such case this packet will be assumed - dropped. + particular exchange. The number of dropped packets is calculated as + the difference between the number of sent packets and number of + response packets received from the server. In some cases, the + server will have sent a reponse but perfdhcp execution ended before + the reponse arrived. In such case this packet will be counted + as dropped. orphans - number of packets that have been received from the server and did not match any packet sent by perfdhcp. This may occur if received packet has been sent - to some other host or if exchange time out has occured and - has been been garbage collected. + to some other host or if then exchange timed out and + the sent packet was removed from perfdhcp's list of packets + awaiting a response. min delay - minimum delay that occured between - sending the packet to the server and receiving reponse from + sending the packet to the server and receiving a reponse from it. avg delay - average delay between sending the - packet of the specific type the server and receiving response + packet of the specific type the server and receiving a response from it. - max delay - maximum delat that occured between - sedning the packet to the server and receiveing response from + max delay - maximum delay that occured between + sending the packet to the server and receiving a response from it. - std deviation - standard deviation of delay + std deviation - standard deviation of the delay between sending the packet of a specific type to the server and receiving response from it. - collected packets - number of garbage collected - sent packets. Packets may get garbage collected when waiting time - for server response exceeds value set with + collected packets - number of sent packets that + were garbage collected. Packets may get garbage collected when + the waiting time for server a response exceeds value set with the + '-d' (drop time) switch. ]]>. - perfdhcp allows to run the test using specified interface: + Note: should multiple interfaces on the system running perfdhcp be + connected to the same subnet, the interface to be used for the test + can be specified using either the interface name: #./perfdhcp -l eth3 - or local address assigned to it: + or a local address assigned to it: #./perfdhcp -l 172.16.1.2

Example: rate control - In the examples above perfdhcp initiates new exchanges with best - effort rate. In this case many packets is expected to be dropped by the - server due to performance limitations. Many times it is desired to set - the expected (reasonable) rate and verify if generated traffic is - handled without packet dropes by DHCP server. The following command will - make perfdhcp to initiate 300 4-way exchanges per second and test will - last for 60 seconds: + In the examples above perfdhcp initiates new exchanges with a best + effort rate. With this setting, many packets are expected to be dropped + by the server due to performance limitations. In many cases though, it is + desired to verify that the server can handle an expected (reasonable) rate + without dropping any packets. The following command is an example of such + a test: it causes perfdhcp to initiate 300 four-way exchanges + per second, and runs the test for 60 seconds: #./perfdhcp -l eth3 -p 60 -r 300 ***Rate statistics*** Rate: 256.683 exchanges/second, expected rate: 300 exchanges/second @@ -967,12 +971,13 @@ max delay: 576.749 ms std deviation: 58.189 ms collected packets: 0 - Note that in this example the packet drops have been significantly - reduced thanks to setting reasonable rate. The non-zero number of - packet drops and achived rate (256/s) below expected rate (300/s) - indicate that server's measured performance is lower than 300 leases - per second. Further rate decrease should eliminate most of the packet - drops and bring achived rate close to expected rate: + Note that here, the packet drops for the DISCOVER-OFFER + exchange have been significantly reduced (when compared with the + output from the previous example) thanks to the setting of a + reasonable rate. The non-zero number of packet drops and achieved + rate (256/s) indicate that server's measured performance is lower than 300 leases + per second. A further rate decrease should eliminate most of the packet + drops and bring the achieved rate close to expected rate: #./perfdhcp -l eth3 -p 60 -r 100 -R 30 ***Rate statistics*** Rate: 99.8164 exchanges/second, expected rate: 100 exchanges/second @@ -1001,25 +1006,29 @@ max delay: 189.658 ms std deviation: 5.876 ms collected packets: 0 + There are now no packet drops, confirming that the server is able to + handle a load of 100 leases/second. Note that the last parameter (-R 30) configures perfdhcp to simulate - traffic from distinct 30 clients. + traffic from 30 distinct clients.

Example: templates - By default the DHCP messages are formed in-flight with default options. - If desired, there is a way to define custom packet format with template - files. Content in template files is encoded in hexadecimal format. The + By default the DHCP messages are formed with default options. With + template files, it is possible to define a custom packet format. + + + The content in template files is encoded in hexadecimal format. perfdhcp forms the packet by replacing parts of the binary stream read - from the file with variable data such as elapsed time, HW address, DUID + from the file with variable data such as elapsed time, hardware address, DUID etc. The offsets where such variable data is placed is specific to the template file and have to be specified from the command line. Refer to to find out how to specify offsets for particular options and fields. With the following command line the DHCPv6 SOLICIT and REQUEST packets will be formed from - solicit-example.hex and request6-example.hex packets: - #./perfdhcp -6 -l eth3 -r 100 -R 20 -T templates/solicit-example.hex -T templates/request6-example.hex -O 21 -E 84 -S 22 -I 40 servers + solicit.hex and request6.hex packets: + #./perfdhcp -6 -l eth3 -r 100 -R 20 -T solicit.hex -T request6.hex -O 21 -E 84 -S 22 -I 40 servers ***Rate statistics*** Rate: 99.5398 exchanges/second, expected rate: 100 exchanges/second @@ -1047,15 +1056,15 @@ max delay: 6.490 ms std deviation: 0.518 ms collected packets: 0 - where: + where the switches have the following meaning: two occurences of -O 21 - DUID's last octet positions in SOLICIT and REQUEST respectively. - -E 84 - elapsed time option position in + -E 84 - elapsed time option position in the REQUEST template - -S 22 - server id position in REQUEST + -S 22 - server id position in the REQUEST template - -I 40 - IA_NA option position in REQUEST + -I 40 - IA_NA option position in the REQUEST template