Than you would have by working on emulator or simulator software. For DHCP clients I use a couple 1700 routers that I picked up for next to. Dhcp Client Request. Attention, Internet Explorer User Announcement: VMware Communities has discontinued support for Internet Explorer 7 and below. In order to provide the best platform for continued. For a DHCP server with network 192.168.10.0/24, if the gateway IP is not the first IP in the subnet (192.168.10.1) but something like 192.168.10.24 then the range option in DHCP server (the option.

Abstract

1. A DHCP client simulation on linux. It can simulates multiple DHCP clients behind a network device. It can help in testing the DHCP servers or in testing switch/router by loading the device with multiple DHCP clients. csikfer/dhtest.
2. Dhcp Simulator Client Software. ISC DHCP v.4.2.3-P2. A freely redistributable reference implementation of all aspects of DHCP. ISC DHCP provides a freely.

When you need to evaluate DHCP performance, it’s very important to understand the role it plays on the network in which it resides. The relevance that a DHCP service has for an enterprise that uses the service for internal purposes is not the same for an ISP (which sees the DHCP as a core business service). Understanding the importance that DHCP has for the business that it’s supporting is key while trying to analyze (and measure) performance requirements. In this paper, we will show different aspects that should be considered while measuring DHCP performance and finally we will share some discoveries we made while we were doing our research.

Why should we analyze DHCP performance?

In the world of ISPs, the DHCP service plays a central role in supporting the provisioning process, providing IP addresses to any device that requires registering into the ISP’s network. If this service does not work properly, the business gets beaten almost instantly and customer calls start flooding the call center. This is why, when analyzing a DHCP server, several aspects need to be evaluated. In this paper, we will focus on one of those aspects: performance.

Measuring DHCP performance is key when trying to understand how this component will work under different load scenarios. Understanding this behavior will provide predictability to the operation and will help to comprehend aspects such as scalability (how much the operation can grow with the current infrastructure) or the time-to-recover concept (how much the operation will need to recover after a massive power outage).

Test Scenario

When talking about performance, we can clearly differentiate two scenarios:

• Normal load scenario: In this scenario, the observed amount of DHCP requests is considered “normal” or “expected” for the operation, we are working on. Understanding what “normal load” means for the operation implies several days of researching and sniffing the network in order to measure a number of requests it’s used to process under typical (normal) conditions. At this point, measuring some basic aspects like I/O wait, CPU, and memory usage and the ratio of ACK/s against DISCOVER/s could help to understand when the service is starting to get stressed or when it’s important to add more infrastructure (more servers).
• Stressed or flooded load scenario: This scenario occurs when an abnormal situation takes place and, as a consequence, the DHCP service simultaneously receives a large amount of DHCP requests. A classic example could be a massive power outage. As a result, the DHCP service is shaken up, the ratio of ACKs/requested IPs start to sink, and some queues of the operating system and services start to get flooded all the time.

While both scenarios are important and relevant to our research, we will focus on the stressed or flooded scenario, simply because it represents a borderline, the worst-case scenario. This scenario creates an extreme situation that pushes the service to an edge and if it’s not properly handled, it may have a huge impact on the service and, therefore, in the business it’s supporting.

Now that we have identified the scenario we want to study, we need to clarify some points and make some definitions:

• What does a stressed or flooded scenario mean for the operation we are studying? To answer this question, we have to ask ourselves: What is the worst scenario the operation could pass through (in terms of DHCP requests)? When trying to simulate a stressed scenario, we need to know the maximum amount of requests that could impact the service and, at least, try to reproduce this very same amount of traffic (ideally, we want to duplicate it) with a performance tool.
• Service configuration and Network topology. As a complex service, the DHCP server has many settings and options that can be configured such as failover, load balancing, dynamic DNS update, ping addresses before allocation, log level, triggers (or extensions), and so on. Each of those settings can have a huge impact while measuring performance in a stressed scenario. It’s very important to identify the environment settings of the service and replicate the configuration in the lab where the tests will be held. The hardware is also a significant factor that we should take care of. The hardware where the DHCP server runs really matters; testing with the wrong hardware will lead you to wrong numbers. The best-case scenario is to run the simulations in exactly the same server that will be used to host the production service. Of course, this is not easy to accomplish, so at least one should try to run the simulation on similar hardware in order to get numbers that “make sense.”
• How do we will simulate the stressed or flooded scenario? Last, but not least, we need to figure out how to simulate a huge amount of traffic and the procedure to apply while doing the simulation. In our case, we have developed our own DHCP client simulator which implements DHCP (v4 and v6) protocol. This performance tool allows us to understand (from the device perspective) if it (the device) has acquired an IP address, how much time it took to get that IP address, and some more technical data that is out of the scope of this paper (we will probably write a paper about DHCP traffic simulation soon) but useful for detailed network analysis.

Metrics

Choosing the appropriate metrics, without drowning in a sea of indicators, is essential to understand the behavior of DHCP service and DHCP clients (simulated). Through our experience, we have found some indicators that provide accurate information regarding the performance achieved. These indicators are:

1. IP addresses delivered per second
2. Response time for different types of DHCP messages
3. Ratio (percentage) of successful DHCP transactions

These values should be analyzed as a whole; there isn’t a definitive indicator. Response time is as important as the number of IP addresses delivered per second. An excessive response time implies that the DHCP client should retry the request before receiving the response; this creates a multiplier effect on the load of the DHCP service which, in the best-case scenario, processes unnecessary messages from the same client and in the worst-case scenario enters a state (which we call “saturation”) where fails to deliver IP addresses. On the other hand, the ratio of successful DHCP transactions (ACKs successfully received against DISCOVERs sent) is a clear indicator of the ability of the DHCP to handle the load under analysis.

Load Testing Methodology

Testbed Setup

The DHCP server must be configured to emulate the production environment of an ISP. This means taking into account the characteristics listed above (failover, the configuration of logs, etc.) and also use a scopes/prefixes configuration equivalent to the production environment. On the other hand, ideally, you should use the same (or at least similar) hardware and operating systems that are used in the production environment. The testbed is completed with at least one additional equipment that will be used to run the performance tool that will generate the DHCP load. Figure 1 shows the default setup of our performance laboratory which includes two computers for load generation, two DHCP servers, and a DDNS server.

Figure 1. Testbed for DHCP performance analysis.

Performance testing protocol

The testing protocol introduced in this white paper evaluates the responsiveness of the DHCP server before different load conditions in order to determine the time-to-recover of the operation for these conditions.

When a fail takes place in a production environment, most of the DHCP clients are known and have a valid lease; this is an important factor because performance for unknown clients can be significantly different than performance for known clients. For this reason, the testing protocol supposes that a high percentage of clients are pre-allocated into the DHCP server (and have a valid lease) before running the performance tests and a small percentage of new DHCP (5%) clients will be requesting a new lease. The number of known clients should be the maximum number of active leases expected on productive DHCP servers.

The performance tool must be configured to simulate DHCP clients with real-world, non-sequential MAC addresses (or DUIDs) and must implement timeouts for DHCP responses. In our experience, a timeout of 500 ms is a good approximation because the timeout must consider the overhead of the ISP’s network and also RFC 3315 specifies an initial timeout of 1 second (RFC 2131 is not specific and is limited to suggest a minimum timeout of 3 seconds for a 10Mb/s Ethernet network).

Our DHCP performance tool emulates an amount of N simultaneous clients trying to obtain their IP addresses. On every run, the number N of simultaneous clients is increased to evaluate the performance of the DHCP engine under different load conditions; if a sudden change of performance is detected between two increments of N is mandatory to run additional performance tests between those two values.

We use the following testing protocol:

For each value of N (simultaneous DHCP clients):

1. Remove all DHCP leases.
2. Preallocate into the DHCP the base list of known clients.
3. Run 3 iterations as follows:
   1. Reload the DHCP server (full stop + start) to ensure that all caches are reset.
   2. Configure the performance tool to use the base list of known clients plus 5% of new (unknown) clients. The list of clients must be randomized every time.
   3. Run the performance tool until the list of DHCP clients is exhausted.
   4. Review DHCP logs. If any abnormal or error condition is detected (such as unavailability of free leases or expiration of previously allocated leases) the iteration is invalid and the configuration must be revised.
   5. Record the results.
4. Analyze the results of the 3 iterations. If a substantial deviation is noticeable in an iteration, the iteration is invalid and must be repeated.
5. Calculate the average for all the values acquired during the performance tests. These average values are the DHCP performance for the load N.

Tests results and data analysis

This section presents the results obtained (using the protocol described above) and analysis conducted when evaluating the DHCPv4 performance of 3 DHCP servers from different vendors.

Usually, the first indicator considered when evaluating performance is the number of IP addresses delivered per second. As shown in Figure 2, DHCP A has an almost constant performance as the number of simulated devices increases. DHCP B initially offers higher performance than DHCP C and therefore, one might be tempted to think that it’s a better choice; however, when the load has increased the performance of DHCP C decreases slightly as the performance of DHCP B drops virtually to zero. This effect is best shown in the graph of saturation point (figure 3) which shows the ratio of ACKs received versus the DISCOVERs sent. This figure shows that when the load approaches 1600 simultaneous devices, DHCP B is saturated and the number of successful transactions declines sharply; on the other hand, for DHCP C a gradual degradation is observed and so, even at higher levels of DHCP load, IP addresses are delivered.

Charts of response time for OFFER (figure 4) and ACK (picture 5) allow inducing some considerations about how DHCP B and DHCP C handle the load. It can be observed that DHCP B latency increases as the load rise, and until the timeout configured in the performance tool is reached (500 ms); the behavior suggests that this DHCP engine doesn’t have a mechanism for protection against high load, but enqueues and tries to process every DISCOVER that has received. In contrast, DHCP C tends to maintain a constant response time, and the rate of failed DHCP transactions increases as the load rises; this suggests that by design, this DHCP engine has some kind of mechanism for protection against high load. In fact, during the tests, it was found that DHCP C performance is dependent on the size of a buffer of the operating system and that this buffer, having a limited size, acts as a protection against high load and stress situations.

Additionally, for DHCP C we observed that the response time for ACK is clearly greater than the response time for OFFER; this behavior is probably a consequence of disk access required to store the lease before sending the response. DHCP A exhibits significantly low response times for both OFFER and ACK; this suggests the existence of a mechanism for optimizing disk access for known DHCP clients.

To summarize, we can state that DHCP A is clearly the best choice from the point of view of performance and scalability. DHCP B will only be a feasible option if you can guarantee that there will not take place an excessive load which causes the performance to drop to zero. DHCP C is a selection that can be considered acceptable if the time-to-recover desired is possible given the performance of the engine and the size of the operation of the ISP.

Conclusion

As a single performance metric, the number of IP addresses per second is far from being a valid indicator; to measure the performance, it is necessary to have a well-designed test protocol that combines different indicators that enable the understanding performance of the DHCP engine in the particular context of the operation. It should be understood that the performance of DHCP can be affected by different factors. In the analysis presented in this paper, for example, the tests were conducted without DHCP extensions, and without Dynamic DNS update; the activation of these features can modify the evaluation, regarding performance, of the DHCP engines.

The variables to be measured (and their combinations) are numerous and detailed assessment should be made according to the special requirements of each operation. For example, this report has not assessed the impact on the performance of DHCP messages such as leasequery, which may (or may not) have an impact on the response times that were measured.

Moreover, the choice of a DHCP engine, from the point of view of performance, depends on the size of the network and the requirements of time to recover from faults. It should be noted that a higher performance generally involves fewer servers which reduces hardware and operating costs.

Metrics and performance analysis are all about knowing the behavior of services under different conditions. Achieving a predictable (or constant) behavior it’s a very important and desirable feature; it helps to understand service capacity and scalability and helps to manage avalanches of DHCP requests.

Dhcp Client Windows 10

Finally, it’s worth mentioning that a complete test could include devices simulated with the test protocol described in this paper and a reduced environment with real (not simulated) devices; thus, it’s possible to observe the effects of the load on a controlled environment and achieve a complete idea of the behavior of the network elements under stress conditions.