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):

 Responding to the review by Jeff...

 > What about DHCP client - is that yet supported in Kea?
 Not yet - the current focus has been on the server.

 > 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
 The plan for the current phase of development is to have V4 clients
 supported by relay and V6 clients supported through direct access.  The
 next phase will have both V6 and V6 clients supported by both means of
 access.

 > How about server failover and/or load balancing; is that supported yet?
 No.  However, using a MySQL database does suggest that it might be
 possible to do a "poor man's failover" using the database multi-master
 capabilities.  This is not part of the deliverables, but at some point in
 the future I would like to experiment with that.

 > Can Kea use different ports than default (67/68)?
 In standalone mode yes, as the post number can be set with the "-p"
 switch.

 > Any need to test BOOTP?
 No - BOOTP is explicitly not supported.

 > 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)?
 Kea is started through the general BIND 10 process control mechanism, so
 if there is a problem in this area, it is most likely to be a general BIND
 10 problem rather than a Kea-specific one.  However, we can add a test to
 start/stop Kea a number of times in succession.

 > Might be good to see how performance tracks with logging
 level...obviously we would expect more logging => less performance
 Again, that is a general BIND 10 issue.  However, I take your point - if
 some messages are logged at the wrong severity, it could impact
 performance.  A meaningful measure might be to run with default logging
 and compare it with a run with logging disabled.

 > 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
 As soon as we have a full list, I'll let you know.

 > 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?
 Yes - the item "Responding with appropriate options (and values) in
 response to a client requests".


 > 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'll expand the performance test section.

 > 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.
 Will add this.

 > 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.
 Good idea - will add.

 > Might make sense to throw in some static IPs that pools must "work
 around"
 When fixed leases are implemented, we can add this.

 > 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"?)
 It does make sense to test different clients against the server.

 > Also toward the future: we might consider testing in different network
 topology situations (e.g. serving requests to local networks; thru VPN
 tunnels)
 Agreed.  We may need relays, so until we implement a relay in Kea, we
 could use the DHCP4 relays for the tests.

 > What kind of boundary and negative tests can we think of? This might
 particularly be useful for testing config params.
 Let's look at this when we get the list of configuration parameters ready.

 > Vulnerability testing? Packet of death/fuzz tests? mmap has some DHCP-
 specific plugins, and scapy might be a great tool to use for pit-of-death
 scenarios.
 Agreed.

 Thanks for the review.

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