BIND 10 #2488: Create DHCP Test Plan

[BIND 10 Development]

#2488: Create DHCP Test Plan
-------------------------------------+-------------------------------------
            Reporter:  stephen       |                        Owner:
                Type:  task          |  stephen
            Priority:  medium        |                       Status:
           Component:                |  accepted
  documentation                      |                    Milestone:
            Keywords:                |  Sprint-DHCP-20121213
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DHCP          |                 CVSS Scoring:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by stephen):

 Comments from Jeff Wright on [attachment:kea-test-plan-v1.txt V1 of the
 test plan]

 ===================
 Kea Test Plan !Thoughts/Notes
 ===================

 Overall:

   * What about DHCP client - is that yet supported in Kea?
   * Is DHCP v4 Relay the only way that DHCP v4 clients are supported?
     If Kea supports direct-connect of v4 clients, we'll need to test
     that as well
   * How about server failover and/or load balancing; is that supported
 yet?
   * Can Kea use different ports than default (67/68)?
   * Any need to test BOOTP?


 Specific:

   * Can you crash or hang Kea (either v4 or v6) by starting/stopping
     repeatedly? Or very quickly?
   * Can you send Start or Stop commands more than once in a row without
     something weird happening (like multiple threads/processes spinning
     off)?
   * Might be good to see how performance tracks with logging
     level...obviously we would expect more logging => less performance
   * Config: I'd like to see a full list of all config options, and I'll
     see if I can come up with interesting ways to combine them that
     might cause problems
   * The DHCPv4 and DHCPv6 Features sections seem to only address IP
     address allocation. Should we not also test other network config
     params that are typically doled out by a DHCP server (e.g. net mask,
     gw, etc.)…perhaps this is what is addressed in the "Options (both V4
     and V6)" section of your plan?
   * Some areas for "adequate" performance to test would be: connections
     per second (max sustainable); connections per second (max burst rate
     over a given period, to simulate network outage and subsequent flood
     of reconnects from clients); client request response time; max
     client capacity
   * I would also like to see a "longevity" test where we have many
     clients with different settings/options set, continuously
     releasing/renewing leases to make sure after a certain period of
     time (days?) the server is still working properly.  For this test,
     we might want to record metrics on the server like CPU utilization,
     memory consumption, etc over time to make sure we're not increasing
     without bound.
   * Lease pool "leak" test for various scenarios (single pool; multiple
     pools)…pool starts full; empty it (and what happens when you then
     try to go one beyond empty?); fill it back up again; empty it; etc.
     many many times to make sure nothing is leaking
   * Might make sense to throw in some static IPs that pools must "work
     around"


 Other general thoughts:

   * Thinking toward the future, we will want to do some interop testing
     with various flavors of clients (Windows, Linux, OSX/IOS;
     device-related clients, wireless cards, etc.); and server-server
     interop tests with BIND9 vs BIND10, other-than-ISC  servers vs. BIND
     10, etc. (I don't know if this makes sense or not…do DHCP servers
     "talk"?)
   * Also toward the future: we might consider testing in different
     network topology situations (e.g. serving requests to local
     networks; thru VPN tunnels)
   * What kind of boundary and negative tests can we think of? This might
     particularly be useful for testing config params.
   * Vulnerability testing? Packet of death/fuzz tests?  mmap has some
     DHCP-specific plugins, and scaly might be a great tool to use for
     pit-of-death scenarios.

-- 
Ticket URL: <https://bind10.isc.org/ticket/2488#comment:2>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development