wiki:DhcpTestPlan

Kea (BIND10 DHCP) Test Plan (outdated)

If you are looking for Kea requirements that used to be listed here, see KeaRequirements.

The following sections identify the various tests that need to be done to check each of the functional elements for work done in 2012. They are being migrated to Confluence (see Test Design Specification: DHCP 2013 in dhcp global space).

BIND 10 Integration

The following tests of the servers are needed. Where a client is required for a test, the ISC DHCP client will be used.

  1. Start/stop
    • Start/stop the DHCPv4/v6 server via bindctl and check that it is running/stopped.
    • Starting and stopping the DHCPv4/6 server many times in quick succession.
    • Verify that the DHCPv4/v6 server starts with the whole BIND10, if configured to do so.
    • Verify that the DHCPv4/v6 server stops with the whole BIND10.
  1. Logging
    • Enabling logging (verbose) and check that messages from the V4/V6 server are being logged.
    • Enabling logging (non-verbose) and check that only "important" messages are logged.
    • Verify that logging can be configured using various levels (debug, info, warning, error).
  1. Configuration
    • Check that the configuration is preserved when server is restarted.
    • Check that the existing configuration can be completely removed.
    • Check that the configuration can be applied with several commits (each applying a portion of whole configuration). Each step (a separate commit) must be self consistent.
    • Check that an existing subnet, pool, option value can be modified (updated)

(Access to configuration items is checked in other tests, so the tests only check the handling of the configuration data, not access to it)

  1. DHCPv4 features
    1. General
      • Check that leases are correctly allocated from:
        • A single subnet and single pool
        • Multiple subnets with one pool each
        • Multiple subnets each with multiple pools
      • Check that appropriate debug messages are issued when a lease can't be allocated due to pool exhaustion (A debug message - which is usually disabled - as opposed to a warning message (enabled) to prevent a DOS attack causing a flood of messages).
      • Check that clients can renew leases.
      • Setup single subnet and pool without time parameters and check that it inherits the default time values
      • Setup multiple subnets and pools without time parameters and check that they inherit the default time values
      • Check that the incomplete or invalid subnet definition is rejected.
    2. Robustness
      • Check that the server rejects all but DISCOVER, REQUEST and RELEASE messages.
      • Check that the server rejects malformed DISCOVER, REQUEST and RELEASE messages.
      • Check that a server receiving an inappropriate REQUEST (e.g. for an unallocated address) sends a NAK.
  1. DHCPv6 features
    1. General
      • Check that leases are correctly allocated from:
        • A single subnet and single pool
        • Multiple subnets with one pool each
        • Multiple subnets each with multiple pools
      • Check that appropriate debug messages are issued when a lease can't be allocated due to pool exhaustion (A debug message - which is usually disabled - as opposed to a warning message (enabled) to prevent a DOS attack causing a flood of messages)
      • Check that clients can renew leases.
      • Check that clients can release leases.
      • Setup single subnet and pool without time parameters and check that it inherits the default time values
      • Setup multiple subnets and pools without time parameters and check that they inherit the default time values
      • Check that the incomplete or invalid subnet definition is rejected.
    2. Robustness
      • Check that the server rejects all but SOLICIT, REQUEST, RENEW and RELEASE messages.
      • Check that the server rejects malformed SOLICIT, REQUEST, RENEW and RELEASE packets.
      • Check that a server receiving an inappropriate REQUEST (e.g. for an allocated address) sends a NAK.
      • Check that the server correctly handles lease RELEASE packets for incorrect leases (e.g. address not allocated, DUID does not match etc.)
  1. Options (V4 and V6)
    • Check that the server sends requested options of the correct scope (global or subnet).
    • Check that the server ignores requests for unset options.
    • Check it is possible to define user options.
    • Check it is possible to set values for user-defined options.
    • Check that the server sends requested user-defined options of the correct scope (global or subnet).
    • Check that the incomplete or invalid option value is rejected.
    • Check that the configured option value can be removed.
  1. Performance tool
    • Check it is able to send DHCPv4 packets.
    • Check it is able to send DHCPv6 packets.
    • Run against a DHCPv4 server and check two-packet and four-packet exchanges.
    • Run against a DHCPv6 server and check two-packet and four-packet exchanges.
    • Check that packets from the tool can appear to come from at least 100 clients.
    • Check statistics give desired values
    • Able to measure performance for both initial handshake (DISCOVER/OFFER and SOLICIT/ADVERTISE) and full packet exchange (DISCOVER/OFFER/REQUEST/ACK and SOLICIT/ADVERTISE/REQUEST/RESPONSE).
  1. Performance (V4 and V6)
    The tests here are for a single DHCP process. The ultimate goal is to have multiple DHCP processes running within the BIND 10 framework, so pushing overall throughput up. For now though, multi-process support has not been implemented, so all tests are for a single process.
    • Run the performance tool against the server to assess performance. (Note: a high-performance server will be available for this.)
      • What is the peak sustained rate the server can handle
      • What is the response latency
      • What is the standard deviation in the value of the data returned.
  1. General
    • Run the server (both V4 and V6) in normal operation for an extended period of time to check that leases are handed out successfully.
    • Check that memory usage does not grow without bounds.
    • Check the CPU usage
    • Check that the server rejects junk packets sent to its port.
Last modified 22 months ago Last modified on Mar 18, 2015, 2:15:19 PM