DHCP Server Testing IxLoad

TEST PLAN DHCP Server Testing IxLoad www.ixiacom.com 915-6646-01, 2006 Copyright © 2006 by Ixia All rights reserved Ixia 26601 West Agoura Road, ...
Author: Gavin Leonard
0 downloads 0 Views 1MB Size
TEST PLAN

DHCP Server Testing IxLoad

www.ixiacom.com

915-6646-01, 2006

Copyright © 2006 by Ixia All rights reserved Ixia 26601 West Agoura Road, Calabasas, CA 91302 (877) FOR-IXIA This Test Plan contains a general outline for testing a particular technology. Not all the capabilities of Ixia technology have been exposed in this document. Please feel free to contact us if additional capabilities are required.

DHCP Server Test Plan Contents DHCP Server Test Plan . . . . . . . . . . . . . . . . . . . . . 1 Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . 4 Basic Setup . . . . . . . . . . . . . . . . . . . . . . . 5 Advanced Setup . . . . . . . . . . . . . . . . . . . . 6 1. Test 1 – Maximum Client Capacity . . . . . . . . . . . 9 Objective . . . . . . . . . . . . . . . . . . . . . . . . . 9 Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Input Parameters . . . . . . . . . . . . . . . . . . . 10 Methodology . . . . . . . . . . . . . . . . . . . . . 11 Results . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Test 2 – Maximum Transaction Rate Objective . . . . . . . . . . . . . . . . Setup. . . . . . . . . . . . . . . . . . . Input Parameters . . . . . . . . . . . Methodology . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . .

. . . . . . . . . 15 . . . . . . . . 15 . . . . . . . . 15 . . . . . . . . 16 . . . . . . . . 17 . . . . . . . . 18

3. Test 3 – Optimal Client Response Time Objective . . . . . . . . . . . . . . . . . . Setup. . . . . . . . . . . . . . . . . . . . . Input Parameters . . . . . . . . . . . . . Methodology . . . . . . . . . . . . . . . Results . . . . . . . . . . . . . . . . . . . . 4. Test 4 – Server Resiliency Objective . . . . . . . . . Setup. . . . . . . . . . . . Input Parameters . . . . Methodology . . . . . . Results . . . . . . . . . . .

© 2006 by Ixia

p.3

. . . . .

. . . . . . . 20 . . . . . . 20 . . . . . . 21 . . . . . . 22 . . . . . . 23 . . . . . . 24

. . . . . . . . . . . . . . . . 25 . . . . . . . . . . . . . . 25 . . . . . . . . . . . . . . 25 . . . . . . . . . . . . . . 26 . . . . . . . . . . . . . . 27 . . . . . . . . . . . . . . 28

www.ixiacom.com

DHCP Server Test Plan This test plan assists you in comprehensively testing the scalability and performance of your DHCP server(s)under normal and extreme load conditions. Today’s DHCP servers play a vital role in any enterprise or carrier network and must be rigorously tested to ensure that they: • Provide a scalable platform to service a large number of subscribers • Provide a reliable and fail-safe platform to ensure maximum network availability • Provide resiliency to bursty DHCP traffic after an outage or during startup • Provide auto-configuration based on the type of host requesting network information • Provide the capability to detect unauthorized host systems and deny network information The recommended testing methodology presented here is also meant to be used as a guideline for creating more case-specific testing scenarios to further characterize the performance limits of the DHCP infrastructure.

© 2006 by Ixia

p.1

www.ixiacom.com

DHCP Server Test Plan

Background Dynamic Host Configuration Protocol (DHCP) is an essential part of any IP network. It is used to dynamically provide IP address and network configuration parameters to host systems. In fact, the dynamic configuration of host systems is one of the key reasons for using DHCP. DHCP is used extensively by enterprises and service providers for wired and wireless/roaming networks. It can be used to provide hosts with IP address/mask and gateway address information and DNS servers, among several other configurable options. As enterprises grow beyond the traditional office walls, it has become critical that host systems be authorized and authenticated before providing network access. DHCP makes this possible without the introduction and overhead of new technologies. Using DHCP, end hosts can be authenticated before providing configuration information. Specific options in DHCP can be used to identify a host system, as well as the user requesting network configuration. Wireless hot spots and remote access technologies such as VPNs also use DHCP to provide configuration to hosts connecting to their IP network remotely. DHCP servers must be able to accommodate this growing user base to support real-time changes with minimal service outages. In addition, Service Providers use DHCP to configure customer premise equipment, effectively testing DHCP to assure carriergrade deployment. In a Carrier network, DHCP is used to provide the expected class of service to various devices. Consider the deployment of a Triple Play services delivery network. A subscriber with multiple customer premise equipment, such as a remote-gateway, a voice-gateway, and one or more IP set-top boxes, will require a different class of service to perform optimally. DHCP is essential in making this sophisticated service deployment possible.

© 2006 by Ixia

p.2

www.ixiacom.com

DHCP Server Test Plan

DHCP requests include device-specific information that allows the Carrier network to provision the required class of service for the various devices. Ensuring that DHCP servers are able to handle complex scenarios without becoming a bottleneck for service provisioning is essential to ensure a successful deployment of a Triple Play network. Network resiliency is a top priority for users and businesses. Network resiliency refers to the ability of a system or network to recover or adjust dynamically to failure conditions. DHCP servers may use any of the following methods to maintain partial or full failover state information to provide higher network resiliency: • Server clustering – a mirrored configuration for one or more servers with OS-level or hardware-based cluster management for load balancing and failover. • Split scopes – multiple servers share a reserved range for an address scope. • DHCP failover – multiple servers use a draft-rfc, and implement a DHCP failover protocol for automatic load balancing and failover. Testing DHCP server resiliency under adverse and failure conditions is extremely important in ensuring a successful DHCP server deployment.

© 2006 by Ixia

p.3

www.ixiacom.com

DHCP Server Test Plan

Performance Metrics To determine the performance of a DHCP server, several performance metrics will be used in this test plan. The following terms are defined and used to provide objective performance characteristics for the DHCP server, the device-under-test (DUT) in this test plan. Connection – A single TCP connection between two end hosts, using connection establishment (3-way handshake). Transaction – A single request for an object from a client to server. A transaction is made within an established Connection. Connections-per-second – The rate at which new TCP connections are initiated per second. Transaction Response Time – The amount of time elapsed between the time a client sends a request and the time an acceptable response to it is received. Complete Transaction Response Time – The amount of time elapsed between the time a client sends the first request and the time the last acceptable response is received successfully from subsequent requests. Client Capacity – Number of clients that a server can support. The maximum client capacity of a server is the threshold beyond which the server can no longer support any additional clients. Success Rate – The ratio of successful transactions calculated over the total attempted transactions.

© 2006 by Ixia

p.4

www.ixiacom.com

DHCP Server Test Plan

Basic Setup The basic test configuration requires the DHCP server to host one or more address scopes to lease to the DHCP clients. Specifically, a large pool of addresses must be configured to ensure sufficient addresses are available for the test duration. One or more Ixia test ports is required to send multiple DHCP requests to the server. The test network will be a flat network, and DHCP requests will be broadcast on the local link to reach the DHCP server. Ixia DHCP Clients

DHCP Server

Ixia Port

Figure 1. Basic DHCP Server test topology The following DHCP client and server interaction provides a basic understanding of how a DHCP client acquires network configuration information from a DHCP server. A similar request/ response transaction is used for address renewal (RequestRenew), address rebind (Request-Rebind), or address release (Release), among other DHCP commands. DHCP Discover (Broadcast)

DHCP Offer (Broadcast)

DHCP Request (Broadcast)

DHCP Client

DHCP ACK (Broadcast)

Figure 2. Typical DHCP request/response

© 2006 by Ixia

p.5

www.ixiacom.com

DHCP Server Test Plan

Advanced Setup This advanced test configuration is appropriate when several DHCP servers are responsible for hundreds of lease scopes. The lease scopes may service users in different physical and logical networks, using VLANs or routed networks. To maintain high availability, the DHCP server is usually configured for load balancing, and provides failover protection using one of following methods (among others): • Server clustering – a mirrored configuration for one or more servers with an operating-system or hardware-based cluster mechanism used to initiate failover. • Split scopes – multiple servers share a reserved range for an address scope. • DHCP failover – multiple servers use a draft-rfc, and implement a DHCP failover mechanism for automatic load balancing and failover. DHCP servers in a cluster are generally located in different subnets than DHCP clients. In addition, because the servers manage several scopes with thousands of IP addresses based on physical and logical topologies of an enterprise or carrier network, these DHCP servers are not directly reachable by the DHCP clients using DHCP packets which are broadcast-based. DHCP Relay Agents are helper services residing on client networks that help facilitate communication between the DHCP clients and servers over routed networks where broadcast traffic is not possible. For this test setup, one or more test ports is required to send multiple DHCP requests to the server.

© 2006 by Ixia

p.6

www.ixiacom.com

DHCP Server Test Plan

Ixia DHCP Clients

DHCP RA

L3 Switch DHCP Failover Server Cluster

Ixia Port

Figure 3. Advanced DHCP Server test topology with Optional DHCP Failover and Relay Agent To use the DHCP Relay Agent (RA) functionality in such a network, the DHCP protocol on the client side does not require any changes. The RA on the client’s local link network is configured to forward any DHCP packets to a designated DHCP server. This is configurable on a per-VLAN, per-interface, or per subnet basis, i.e., on a L3 switch. Note: Ixia’s L7 stateful traffic generation test tool IxLoad provides DHCP Relay Agent (RA) emulation capability. When this test tool is used, it is not required that an intermediary switch support DHCP RA functionality. When using either Ixia’s emulated RA and/or an upstream RA, some considerations when using a DHCP RA include: • DHCP servers must support RA functionality. These DHCP servers must be able to offer leases based on the identification of RA found in the giaddr field of a DHCP Discover packet as forwarded by a RA. • A RA configuration on the test tool and/or the network switch will be required. – A reachable DHCP server address must be configured on a per-VLAN, per-interface or per-subnet as designed – Most L3 network switches require a “trusted” configuration for a downstream RA if the test tool is configured as an RA © 2006 by Ixia

p.7

www.ixiacom.com

DHCP Server Test Plan

The implications of using a RA must be factored into the performance characterizations of the DHCP server. The perceived performance metrics determined may differ if the RA is not used. It is recommended that the testing be done on a network that closely resembles the production/real-world setup. The following DHCP client and server interaction provides a basic understanding of how a DHCP client acquires network configuration information from a DHCP server that is located in a different network, either logically or physically. A similar request/ response method is used for address renewal (Request-Renew), address rebind (Request-Rebind), or address release (Release) among other DHCP commands.

DHCP Client

DHCP Discover (Broadcast)

DHCP Discover (Unicast to Server)

DHCP Offer (Broadcast)

DHCP Offer (Unicast to RA)

DHCP Request (Broadcast)

DHCP ACK (Broadcast)

L3 Switch with RA Capability

DHCP Request (Unicast to Server)

DHCP ACK (Unicast to RA)

DHCP Server

Figure 4. DHCP client/server response using Relay Agent (RA)

© 2006 by Ixia

p.8

www.ixiacom.com

DHCP Server Test Plan

1. Test 1 – Maximum Client Capacity Objective To support the growing requirements of a DHCP server to handle various load conditions, it is critical to characterize its peak capabilities. This test will help determine the maximum steady-state DHCP requests/transactions handling capability of the server. The maximum client capacity is reached when no additional clients can be realized. At this operating limit, the server will sustain a steady flow of DHCP requests, and then drop or not process any additional packets, achieving a 100% success rate. This metric is important in understanding how the DHCP server can scale to support a large number of DHCP clients, as well as in provisioning one or more servers as the DHCP client base grows. Setup The setup requires at least one Ixia test port to generate stateful DHCP traffic. The configuration presented here is indicative of a typical large-scale DHCP server deployment and may not reflect any specific use-case. Refer to Topology illustration below to be sure to set up the test appropriately. Ixia DHCP Clients

DHCP RA

L3 Switch DHCP Failover Server Cluster

Ixia Port

Figure 5. Topology for Test 1 – Maximum sustained client capacity

© 2006 by Ixia

p.9

www.ixiacom.com

DHCP Server Test Plan

Input Parameters Parameter

Description

Client Configuration

100 or more [user] per test port Retransmission (initial timeout timer) – iterative determination Number of retransmissions = None (to determine first failed packets)

Client Network

One or more VLAN with untagged and/or 802.1q tagged packets per VLAN

Client Command-list

DISCOVER, Wait (iterative), REQUEST, Wait (iterative), RELEASE, Wait (iterative)

Test Ports

At least one (more ports can be used to scale the test)

DHCP Server(s)

1 or more external DHCP server

DHCP Server Configuration

Several lease scopes to allow server test to scale to offer 100 or more IP addresses Specific lease offer hold times to optimize test configuration requirements

Test Objective

Iterative method to determine the maximum concurrent connections Requires iterative use of users/second ramp-up rate to determine maximum capacity without packet loss

Table 1. Input Parameters for Test 1 – Maximum Client Capacity

© 2006 by Ixia

p.10

www.ixiacom.com

DHCP Server Test Plan

Methodology 1. Configure the DHCP server with one or more lease scopes. This configuration is contingent on the test network. If one or more VLANs is used to classify different groups of DHCP clients, several lease scopes must be set up to accommodate the DHCP clients. Refer to the Input Parameters table. 2. Configure any network devices to forward DHCP broadcast packets to an upstream DHCP server. This process may include enabling “helper” services on a per-port or per-VLAN basis. Additionally, if using the RA capability included with the test tool, a “trusted” mode of operation may need to be enabled on the switch to forward such packets. 3. Set up the emulated DHCP client network appropriately. Configure the DHCP clients to use one or more VLAN tags per test port. A trunk-port, for example, supports several VLAN tags. This configuration must match the lease scope and network switch configuration. 4. Configure the emulated DHCP client traffic. Refer to the Input Parameters table. 5. Set up the test objective to determine the maximum number of sustained users. The following client-side parameters can be determined iteratively to optimize the performance of the DHCP server: retransmission of packets based on the initial packet timeout, # of retransmissions, # of Mandatory and Optional options to include in the DHCP Discover packets, and Wait/Think times between commands to control the rate of traffic to the server. Consider that the Objective of this test is to determine the maximum number of sustained users supported by the server. For this reason, the rate of arrival of packets at the server does not necessarily need to be high. This will allow for more sustained users at a lower transaction rate. Adjust the parameters to determine the maximum client capacity. This metric is the threshold reached when there are no timeouts, no retransmissions, nor packets losses on the server-side.

© 2006 by Ixia

p.11

www.ixiacom.com

DHCP Server Test Plan

Results The objective of this test was to determine the maximum client handling capacity. To determine this, the test was run iteratively to reach the operating limit of the server. At this limit, the server was able to sustain a steady flow of DHCP requests without packet loss. The result of three test-runs is presented here to characterize the performance of the DHCP server. The results illustrate the raw performance of the server and more importantly provide insight into the tradeoffs of achieving high client capacity. Run 1 – No errors • 150 users (cycled through the command-list) • Users ramp-up rate: 3 users/second • Request timeout: 5 seconds, No retransmissions • Inter-command wait interval: 4 seconds

Figure 6. Test Case 1 – Run 1 results

© 2006 by Ixia

p.12

www.ixiacom.com

DHCP Server Test Plan

Run 2 – With Timeouts • 250 users (cycled through the command-list) • Users ramp-up rate: 3 users/second • Request timeout: 5 seconds, No retransmissions • Inter-command wait interval: 4 seconds

Figure 7. Test Case 1 – Run 2 results Run 3 – With Timeouts • 250 users (cycled through the command-list) • Users ramp-up rate: 1 user/second • Request timeout: 5 seconds, No retransmissions • Inter-command wait interval: 4 seconds

Figure 8. Test Case 1 – Run 3 results

© 2006 by Ixia

p.13

www.ixiacom.com

DHCP Server Test Plan

The following observations were made in verifying the maximum client capacity of the DHCP server under test: 1. The maximum sustained client capacity was 150 users with an average of 3 users/sec ramp-up. 2. When the number of users increased by 100 in Test Run 2, 2.6% (110/4217) of packets timed out on the client-side. The increase in the number of users also resulted in higher (worse) client response times. 3. In Test Run 3, the ramp-up rate was reduced to 1 user/ second. The results indicate a significant improvement in timeouts (0.31%) and also improved client response times. Therefore, the maximum client capacity of a DHCP server is best determined by understanding the tradeoff between required and acceptable performance. If no errors or timeouts are required, then 150 users with a reasonable ramp-up rate is the maximum client capacity based on this server’s performance under test. With a reduced ramp-up rate, it can be expected that more clients can be accommodated, as long as the increased possibility of errors and timeouts is acceptable. The following parameters can be used to optimize the client and server performance: • Lease hold time on the Server can be manipulated to ensure that pending lease offers are released in a timely manner when running such a test. • The initial timeout for commands on the Client side can be set to a reasonable value so that pending leases from the DHCP can make it back to the client during this time. • The inter-command Wait time on the Client can be determined iteratively, which provides a good balance of steady traffic to the DHCP server.

© 2006 by Ixia

p.14

www.ixiacom.com

DHCP Server Test Plan

2. Test 2 – Maximum Transaction Rate Objective This test will help determine the maximum transaction rate that the DHCP can sustain without any errors or packet losses (100% success rate). The maximum transaction rate will include all transactions for a new DHCP client to request and obtain its network configuration information from the DHCP server. This metric is important in characterizing the DHCP servers’ performance. The metric provides another dimension to the server’s capabilities, not in being able to maintain a steady-state client capacity, but in being able to service more requests for short durations (e.g., extreme conditions) possibly with minimal and acceptable performance degradation. Setup The setup requires at least one Ixia test port to generate stateful DHCP traffic. The configuration presented here is indicative of a typical large-scale DHCP server deployment and may not reflect any specific use-case. Refer to the Topology illustration below to be sure to set up the test appropriately. Ixia DHCP Clients

DHCP RA

L3 Switch DHCP Failover Server Cluster

Ixia Port

Figure 9. Topology for Test 2 – Maximum Transaction Rate

© 2006 by Ixia

p.15

www.ixiacom.com

DHCP Server Test Plan

Input Parameters Parameter

Description

Client Configuration

100 or more [user] per test port Retransmission (initial timeout timer) – iterative determination Number of retransmissions = None (to determine first failed packets)

Client Network

One or more VLAN with untagged and/or 802.1q tagged packets per VLAN

Client Command-list

DISCOVER, Wait (iterative), REQUEST, Wait (iterative), RELEASE, Wait (iterative)

Test Ports

At least one. More ports can be used to scale the test

DHCP Server(s)

1 or more external DHCP server

DHCP Server Configuration

Several lease scopes to allow server test to scale to offer 100 or more IP addresses Specific lease offer hold times to optimize test configuration requirements

Test Objective

Iterative method to determine the maximum transactions per second

Table 2. Input Parameters for Test 2 – Maximum Transaction Rate

© 2006 by Ixia

p.16

www.ixiacom.com

DHCP Server Test Plan

Methodology 1. Configure the DHCP server with one or more lease scopes. This configuration is contingent on the test network. If one or more VLAN is used to classify different groups of DHCP clients, the configuration will require several lease scopes to be set up to accommodate the DHCP clients. Refer to the Input Parameters table. 2. Configure any network device to forward DHCP broadcast packets to an upstream DHCP server. This process may include enabling “helper” services on a per-port or per-VLAN basis. Additionally, if an RA capability is included with the test tool, a “trusted” mode of operation may need to be enabled on the switch to forward such packets. 3. Set up the emulated DHCP client network appropriately. Configure the DHCP clients to use one or more VLAN tags per test port. For example, a trunk-port supports several VLAN tags. This configuration must match the lease scope and network switch configuration. 4. Configure the emulated DHCP client traffic. Refer to the Input Parameters table. 5. Set up the test objective to determine the maximum transactions per second. Consider that the Objective on this test is to determine the maximum transaction rate. Therefore, it is not necessarily important to achieve high client capacity. A typical number of clients with a high rate of IP address assignment and renewal may be sufficient to overwhelm the DHCP server. Adjust the parameters to determine the maximum transactionsper-seconds without errors or packet loss.

© 2006 by Ixia

p.17

www.ixiacom.com

DHCP Server Test Plan

Results The objective of this test was to determine the maximum transactions-per-second that the DHCP could handle. To determine this, the overall user count was not deemed as relevant as the steady-state arrival rate (transaction rate) being processed successfully by the server. The result of three test-runs is presented here to characterize the performance of the DHCP server. RUN 1

RUN 2

RUN 3

Number of Users

95

95

95

Ramp-up rate (users/sec)

10

40

10

Request timeout (sec)

5

5

5

# of Retransmissions

0

0

0

Inter-command Wait (sec)

4

1

1

The table below is a condensed report from all three test runs that contains request rates and failures due to timeouts. IxLoad Report

RUN 1

RUN 2

RUN 3

14.18

20.73

25.25

377.64

490.85

631.11

9.86

12.58

16.57

Avg Bytes Transmitted/s

4529.18

6657.42

8118.95

Avg Bytes Received/s

3191.20

4121.62

5399.71

Avg Throuhput/s

7720.39

10779

13518.46

• DHCP DISCOVER

33.32

63.92

50.29

• DHCP REQUEST

48.79

78.23

73.64

VALID IPs

525

588

892

DISCOVER Total Packets

565

848

1005

0

129

53

525

713

937

0

125

45

DHCP Requests Sent/s DHCP Responsses Received/s Average Transactions Completed/s

Command Level Statistics

• DISCOVER Failures REQUEST Total Packets • REQUEST Failures

© 2006 by Ixia

p.18

www.ixiacom.com

DHCP Server Test Plan

Run 1 produced the maximum transaction rate for the DHCP server without any errors. The following observations were made: 1. As the ramp-up rate was increased from 10 to 40 users/ second, and the inter-command Wait time was reduced from 4 to 1 second (to further accelerate the DHCP request rate), there were significant failures due to timeouts. 2. In the third run, the ramp-up rate was reduced to 10 users/ second. Errors were still seen due to timeouts, but the error number was significantly lower. By running more extreme test cases in Run 2 and 3, it was found that the DHCP server could still service bursty traffic; however, there was a performance penalty to be paid. There were increased packet loss (timeouts) and increased (worse) client response times as the server was overwhelmed with processing more requests.

© 2006 by Ixia

p.19

www.ixiacom.com

DHCP Server Test Plan

3. Test 3 – Optimal Client Response Time Objective This test will help determine the optimal client response time by verifying an acceptable level of performance for the DHCP server. The maximum client capacity and the maximum transaction rates will be used to help determine the upper limits of the DHCP server. To achieve the maximum client capacity, the rate of arrival of DHCP requests at the server may be reduced to allow the server to service more requests. Therefore, to highest client capacity may require a reduced rate of arrival (transaction-rate) of DHCP requests. On the other hand, to achieve the maximum number of transactions-per-second, the number of users is not as important as the rate of arrival. Consider that even a small pool of active users can inundate a DHCP server with frequent requests to acquire, release, or renew IP address information. The motivation for determining the optimal client response time is that most DHCP servers will not operate under either one of the conditions (i.e., maximum number of transactions-per-second or maximum number of users) at any length of time; therefore, it is reasonable to assess the optimal performance of the server at a point of equilibrium between the two.

© 2006 by Ixia

p.20

www.ixiacom.com

DHCP Server Test Plan

Setup The set up will require at least one Ixia test port to generate stateful DHCP traffic. The configuration presented here is indicative of a typical large-scale DHCP server deployment and may not reflect any specific use-case. Refer to Topology illustration below to set up the test appropriately. Ixia DHCP Clients

DHCP RA

L3 Switch DHCP Failover Server Cluster

Ixia Port

Figure 11. Topology for Test 3 – Optimal Client Response Time

© 2006 by Ixia

p.21

www.ixiacom.com

DHCP Server Test Plan

Input Parameters Parameter

Description

Client Configuration

100 or more [user] per test port Retransmission (initial timeout timer) – iterative determination Number of retransmissions = None (to determine first failed packets)

Client Network

One or more VLAN with untagged and/or 802.1q tagged packets per VLAN

Client Command-list

DISCOVER, Wait (iterative), REQUEST, Wait (iterative), RELEASE, Wait (iterative)

Test Ports

At least one. More ports can be used to scale the test

DHCP Server(s)

1 or more external DHCP server

DHCP Server Configuration

Several lease scopes to allow server test to scale to offer 100 or more IP addresses Specific lease offer hold times to optimize test configuration requirements

Test Objective

Iterative method to determine the maximum transactions per second in the context of maintaining an acceptable Client Response Time

Table 3. Input Parameters for Test 3 – Optimal Client Response Time

© 2006 by Ixia

p.22

www.ixiacom.com

DHCP Server Test Plan

Methodology 1. Configure the DHCP server with one or more lease scopes. This configuration is contingent on the test network. If one or more VLAN is used to classify different groups of DHCP clients, the server will require several lease scopes to be setup to accommodate the DHCP clients. Refer to the Input Parameters table. 2. Configure any network devices to forward DHCP broadcast packets to an upstream DHCP server. This process may include enabling “helper” services on a per-port or per-VLAN basis. Additionally, if using the RA capability included with the test tool, a “trusted” mode of operation may need to be enabled on the switch to forward such packets. 3. Set up the emulated DHCP client network appropriately. Configure the DHCP clients to use one or more VLAN tags per test port. For example, a trunk-port supports several VLAN tags. This configuration must match the lease scope and network switch configuration. 4. Configure the emulated DHCP client traffic. Refer to the Input Parameters table. 5. Set up the test objective to determine the maximum number of sustained users. Adjust the parameters to determine the optimal client response time. The most effective method is to start the iterative process that yields the maximum client capability and work down to increase the transactions-per-second rate so that there is a mutual compromise between the two, which produces an acceptable level of client response time.

© 2006 by Ixia

p.23

www.ixiacom.com

DHCP Server Test Plan

Results This test was set up to determine the optimal client response time with an acceptable level of performance. The following test runs were considered to determine the optimal client response time: RUN 1

RUN 2

RUN 3

150

250

100

Ramp-up rate (users/sec)

3

3

1

Request timeout (sec)

5

5

5

# of Retransmissions

0

0

0

Inter-command Wait (sec)

4

4

4

Number of Users

The graph below shows the DHCP Discover response times for three test runs:

Illustrated in the graph, the best response time was achieved in RUN 3. This test run used a reasonably large number of clients with an acceptable level of rate of transactions-per-second. The resulting combination created a desirable operating condition for the DHCP server where the performance of the server and the perceived client response times were both acceptable.

© 2006 by Ixia

p.24

www.ixiacom.com

DHCP Server Test Plan

4. Test 4 – Server Resiliency Objective This test will help to characterize how resilient DHCP servers are under adverse or failure conditions. It will assess any service degradation that is to be anticipated during an active failover transition, and also provide user response time analysis when servers are working in a degraded state. Large enterprises and carrier-grade DHCP implementations usually service thousands of users at any given time. An outage condition due to human error or device failure is generally not acceptable. To reduce the impact of such failures, DHCP servers are clustered to provide load balancing under normal operating conditions, and to provide failover services in the event of a failure, to maintain service availability. Setup The setup will require at least one Ixia test port to generate stateful DHCP traffic. The configuration presented here is indicative of a typical large-scale DHCP server deployment and may not reflect any specific use-case. Refer to Topology illustration below to set up the test appropriately. Ixia DHCP Clients

DHCP RA

L3 Switch DHCP Failover Server Cluster

Ixia Port

Figure 12. Topology for Test 4 – Server Resiliency

© 2006 by Ixia

p.25

www.ixiacom.com

DHCP Server Test Plan

Input Parameters Parameter

Description

Client Configuration

100 or more [user] per test port Retransmission (initial timeout timer) – iterative determination Number of retransmissions = None (to determine first failed packets)

Client Network

One or more VLAN with untagged and/or 802.1q tagged packets per VLAN

Client Command-list

DISCOVER, Wait (iterative), REQUEST, Wait (iterative), RELEASE, Wait (iterative)

Test Ports

At least one. More ports can be used to scale the test

DHCP Server(s)

1 or more external DHCP server

DHCP Server Configuration

Several lease scopes to allow server test to scale to offer 1000 or more IP addresses Specific lease offer hold times to optimize test configuration requirements

Test Objective

Iterative method to determine the behavior of the server under normal and failed conditions – using a combination of “typical” transactions per second and/ or “typical” client capacity

Table 4. Input Parameters for Test 4 – Server Resiliency

© 2006 by Ixia

p.26

www.ixiacom.com

DHCP Server Test Plan

Methodology 1. Configure the DHCP server with one or more lease scopes. This configuration is contingent on the test network. If one or more VLAN is used to classify different groups of DHCP clients, the server will require several lease scopes to be setup to accommodate the DHCP clients. Refer to the Input Parameters table. The DHCP failover and cluster setup is vendor-specific and not covered in this test. At a minimum, ensure that there is a “heartbeat” between the clustered systems or the failover services between the servers. 2. Configure any network devices to forward DHCP broadcast packets to an upstream DHCP server. This process may include enabling “helper” services on a per-port or per-VLAN basis. Additionally, if using the RA capability included with the test tool, a “trusted” mode of operation may need to be enabled on the switch to forward such packets. 3. Set up the emulated DHCP client network appropriately. Configure the DHCP clients to use one or more VLAN tags per test port. For example, a trunk-port supports several VLAN tags. This configuration must match the lease scope and network switch configuration. 4. Configure the emulated DHCP client traffic. Refer to the Input Parameters table. 5. Set up the test objective to perform under “normal” load conditions. Normal load condition refers to typical load conditions for the DHCP server to handle. 6. Run the test. Perform an unscheduled system shutdown of the Primary DHCP server (or perform any other failure condition). The assessment of this action must be monitored closely. Look for statistics that indicate how well the failover was implemented and if there was any noticeable service degradation during the failover. Refer to the Results section for analysis.

© 2006 by Ixia

p.27

www.ixiacom.com

DHCP Server Test Plan

7. Bring the Primary server back online and assess the performance improvement, such as faster client response times and less errors due to timeouts and retransmissions. 8. Iteratively perform several failure scenarios while changing the test parameters to assess the performance of the DHCP server. For example, taking down one of a dual-server system that normally runs at 40% of client capacity with acceptable client response times will entail looking at the response times with only one server fulfilling all the requests. This can lead to longer timeouts and increased errors if the server is unable to process all the requests.

Results The objective of this test was to characterize the DHCP server(s) performance working under degraded conditions. It was expected that the performance of the DHCP server in servicing requests would be lower, and the client response time would increase as the server was required to process more requests than if it was working under normal operating conditions. To characterize how resilient the DHCP servers are during a failure condition, several statistics must be monitored during this critical condition: • Number of DHCP requests sent to the servers that failed due to timeouts • Number of DHCP request retransmissions due to timeout conditions • Incorrect leases offered to clients if the DHCP servers are not synchronized before the failure • Duplicate addresses detected on the client-side because of uncommitted transactions on the Primary server results in out-ofsync Backup database

© 2006 by Ixia

p.28

www.ixiacom.com

Notes: ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________

Notes: ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________

Notes: ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________

Notes: ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________ ___________________________________________________________

About Ixia Ixia is a leading provider of performance test systems for IP-based infrastructure and services. Its highly scalable solutions generate, capture, characterize, and emulate network and application traffic, establishing definitive performance and conformance metrics of network devices or systems under test. Ixia’s test systems are used by Network and Telephony Equipment Manufacturers, Semiconductor Manufacturers, Service Providers, Governments, and Enterprises to validate the functionality and reliability of complex IP networks, devices, and applications. Ixia’s Triple Play test systems address the growing need to test voice, video, and data services and network capability under realworld conditions. Ixia’s vision is to be the world’s pre-eminent provider of solutions to enable testing of next generation IP Triple Play networks. Ixia’s test systems utilize a wide range of industry-standard interfaces, including Ethernet, SONET, ATM, and wireless connectivity, and are distinguished by their performance, accuracy, reliability, and adaptability to the industry’s constant evolution.

Contact Ixia

For more information, contact Ixia or visit our Web Site at http://www.ixiacom.com.

Ixia Worldwide Headquarters Corporate Center 26601 W. Agoura Rd. Calabasas, CA 91302

Info: [email protected]

(Toll Free North America) 1.877.367.4942 (Outside North America) +1.818.871.1800 (Fax) 818.871.1805

Renewals: [email protected]

www.ixiacom.com

Training: [email protected]

Ixia USA Sales

Phone: 1.866.355.4942

Ixia Canada Sales

Phone: 1.877.367.4942

Ixia China Sales

Phone: +86.10.84549199

Investors: [email protected]

Sales: [email protected] Support: [email protected]

Email: [email protected] Email: [email protected] Email: [email protected]

Ixia Europe, Middle East, & Africa Sales Phone: +44.1753.722056 Email: [email protected] Ixia India Sales

Phone: +91.80.25633570

Ixia Japan Sales

Phone: +81.3.5365.4690

Ixia Oceania Sales

Phone: 1.818.292.1561

Email: [email protected] Email: [email protected] Email: [email protected]

Ixia South Korea Phone: +82.11.897.1326

Ixia Federal Sales

Phone: 1.703.822.7527

Email: [email protected] Email: [email protected]

© 1998-2006 Ixia. All rights reserved. This publication may not be copied, in whole or in part, without Ixia’s consent. Ixia and its licensors retain all intellectual property rights in all products identified in this publication. Such products may be covered by one or more patents and/or pending patent applications, including but not limited to the following U.S. patents: 6,717,917; 6,408,335; 6,397,359; 6,061,725; 5,937,165; 5,881,237; and 5,838,919. All software and related documentation identified in this publication is licensed, not sold, pursuant to a separate license agreement between Ixia and the recipient. The recipient’s use of such software and documentation is subject to the terms of that agreement. Restricted Rights Legend Use, duplication, or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19. THIS PUBLICATION IS PROVIDED “AS IS” AND WITHOUT ANY WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED. IXIA SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. THE INFORMATION HEREIN IS FURNISHED FOR INFORMATIONAL USE ONLY, IS SUBJECT TO CHANGE BY IXIA WITHOUT NOTICE, AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY IXIA. IXIA ASSUMES NO RESPONSIBILITY OR LIABILITY FOR ANY ERRORS OR INACCURACIES CONTAINED IN THIS PUBLICATION. Ixia, the Ixia four petal logo, and IxLoad are either trademarks or registered trademarks of Ixia in the United States and/or other countries. All other trademarks belong to their respective owners.