EXECUTIVE SUMMARY: Cisco Network Registrar successfully provided IPv6 addresses to up to 18,036 users per second -- all from the cloud.

Despite IPv6's initial promise of removing the need for DHCP, the need for central management made DHCPv6 a necessity. We decided to test Cisco's DHCPv6 performance for two reasons. First, Cisco Network Registrar (CNR) has been ported to run in the cloud -- that is, the DHCPv6 server runs on virtual servers within Cisco's Unified Computing System (UCS). Second, Cisco had some pretty high-performance claims.

This triggered us to ask why performance numbers for a protocol like DHCP are even important. DHCP address requests are typically quite slow and scattered, and even in a failure event, when users come back online and the servers cannot service all requests, the users will simply retry immediately and will typically get it. Cisco explained that residential service providers have expressed concern to them that DHCP would be the weak link when thousands of customers come back online after a failure event -- a failure event that they perhaps don't want customers to know existed.

Since Cisco's CNR was running not on its own appliance but rather on the UCS, the performance can vary depending on what CPUs and memory are on each UCS blade. We used four identical UCS B200-M1 blades for the test. Seven VMs were installed on each of the three UCS blades to run a script emulating users, and a fourth blade had a single VM equipped with Cisco CNR.

At the time of the test, testing DHCPv6 scale was in the Ixia IxLoad roadmap, so we used scripts running on these 21 VMs to emulate the user exchange. Each blade had two 2.93GHz quad-core processors and 98GB of memory. Once Cisco configured 20/64 IPv6 subnets, we could start the client requests.

We did two types of test runs -- some where the DHCP server still had the user (MAC address) to IP address mapping cached, and some tests where we cleared the cache to emulate a situation that users were being added for the first time, or there was an outage that was long enough for the server to timeout its entries. When testing for renewals, the system was pre-cached with 400,000 leases and the emulated clients would send a total of 60,000 requests. When testing for renewals, the cache was cleared, and the clients would send the same 60,000 requests. When testing for new lease request rates, the cache was cleared, and the clients would send the same 60,000 requests.

To verify that the scripts were working as expected we captured traffic through a SPAN port on the Nexus 7010 as shown in our setup diagram. We compared what we saw from the capture with what the server was reporting. The graphs show a varying rate of requests and offers, and when it is compared to the rate reported by the DHCP server, it is about the average value from the graph. This is what we were expecting to see.

The capture consistently left out exactly 25 percent of the offers. Cisco explained that these were being hashed onto different links -- some internal, to the UCS across the Nexus 1000v. We proved it by looking at the port counters on the Nexus 1000v, seeing exactly 120,000 packets in and 120,000 packets out -- one solicit and request coming in for each of the 60,000 transactions, and one advertise and reply going out for each of the transactions. Proving the servers stats were accurate, we repeated each test type three more times for consistency, and looked at the performance as reported by the server.

After our deep dive inspecting the results, and observing the consistency, we felt confident that operators looking to produce these results could surely do so with this setup. For those looking for this kind of performance, we have listed the hardware specifications to get there, but such performance from a DHCP server is not always required in all environments. Finally, the cloud. The setup we used demonstrated that even such basic IT requirements as DHCP can be outsourced to the cloud. While it may be hard to imagine now, even these base services will need to run in the cloud in order for enterprises to reduce IT investments.

Next Page: PCRF in the Cloud
Previous Page: Network Positioning System

Back to the Cisco Test Main Page