Load testing a DHCP server

jcpunk has asked for the wisdom of the Perl Monks concerning the following question:

Ahoy!

I am attempting to write a script up that will issue lots and lots of DHCP requests to test and see if the new DHCP server can handle the load, as well as prove once and for all that an 386 with a 10BaseT card should not be the primary DHCP server.
But I am running into snags left and right....
I managed to find Net::DHCPClient and it looks to be perfect for what I intend, but I am still having lots more difficulty than I feel that I should be...
My first attempt has been:

use strict;
use Net::DHCPClient;

my $mac_address = `ifconfig |grep HW |cut -d: -f2-7|cut -dr -f3 |cut -
+d' ' -f2`;  # get the MAC address

my $dhcp = new Net::DHCPClient (
                                maccaddr => $mac_address,
                                interface => 'eth0',
                               );

$dhcp->discover(61 => $mac_address);
$dhcp->request;
$dhcp->release;
[download]

I have got Ethereal out there sniffing and when I run this nothing happens... Not even a complaint from perl telling me my syntax is totally wrong...

What have I done wrong?
Can anyone recomend a better way to initate this test?
My understanding of DHCP is limited, is this test even possible or does the link between MAC address and IP address cause a problem with requesting 20 addresses a second?

jcpunk

all code is tested, and doesn't work so there :p (varient on common PM sig for my own ammusment)

Comment on Load testing a DHCP server Download Code

Replies are listed 'Best First'.
Re: Load testing a DHCP server by darrellb (Acolyte) on Nov 05, 2004 at 18:44 UTC
I bet Net::DHCPClient::discover/request are blocking calls. If they are, there's no way you'll be able to use them to stress-test the DHCP server. I'd recommend ripping out Net::DHCPClient::doit into a script and modify it to suit your environment. Unless you're building a generalized DHCP stress tester, you can just hardcode your MAC and whatever else you need. But the point is to be in control of sending and receiving the packets so you can send the next without waiting for any particular response (asynchronous). Then, to correlate responses with requests, you'll probably want to store information on outgoing requests in a hash. Then you index into that hash when you receive responses. Using this low-level approach, you should be able to hammer your DHCP server pretty well and get round-trip times as well (which you'd expect to increase as your applied load increases).	[reply]
Re: Load testing a DHCP server by NetWallah (Canon) on Nov 05, 2004 at 18:12 UTC
A few recommendations: Error-check object creation and method calls Use Net::Address::Ethernet to get MAC address Try /sbin/pump , or /sbin/dhclient to release/renew DHCP-assigned address (Not familiar with these - I would use "ipconfig/release /renew" on Win32) I think you are using the wrong approach to justify improving the server. A 386 will work fine to serve DHCP to ~250 client machines - maybe more, depending on lease time. You should approach this more from the angle of RELIABILITY of an aging machine. Earth first! (We'll rob the other planets later)	[reply]
Re^2: Load testing a DHCP server by waswas-fng (Curate) on Nov 05, 2004 at 20:29 UTC
Sorry but a 386 with ISC dhcpd with a > 2 day lease can support normal load on way over 8k leases. If a power outage happens and you have all clients hitting at the same relative time it just takes a little longer to feed all of the requests. I would still upgrade and replace the hardware with newer supported hardware and setup failover pools on more than one server -- no need to have all your eggs in a basket. -Waswas	[reply]