Opened 8 years ago

Last modified 3 years ago

#1337 new enhancement

DHCP benchmarking - enhanced reply verification

Reported by: stephen Owned by:
Priority: low Milestone: Outstanding Tasks
Component: perfdhcp Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description (last modified by tomek)

From a a comment 2 in ticket 1263:

It would be useful to elaborate on reply verification. V4 server responding with NACK is ok or not? What about v6 server sending REPLY with status-code=no-addrs-avail? That is another thing we could eventually add as a feature. In some scenarios negative response as considered a proper one (test passed) and in others it is not (test failed). Make sure that the verification could be tuneable. For now it can be simple, but it will be more complex later.

Subtickets

Change History (3)

comment:1 Changed 8 years ago by tomek

Couple other pass-criteria that we should eventually develop is listed below. They are listed here in no particular order. This list is by no means complete.

  • no mismatched responses, e.g. server could use wrong transaction-id or there may be transactions for real clients - in both cases this means that the experiment is not conducted properly
  • required fields are present. For example in DHCPv6, server response must include client-id (that is a direct copy of what was sent in SOLICIT or REQUEST); server must include its own server-id; server must include IA_NA option in its response for each IA_NA option present in request.
  • response is positive. In v6 check that IA_NA response contains actual address and not status code that says "sorry". In v4 check that we get ACK and not NACK.
  • verify that assigned leases (addresses prefixes) are really from range. That would require additional parameter for perfdhcp to specify allowed range. This would verify that server really assigns something useful and not just garbage.
  • if user specified that he/she wants option X, verify that option X is present in server response

We should eventually look at sending and verifying multiple addresses.

We should eventually develop support for FQDN and name assignments.

We may implement verification that for each message exchange a different address/prefix was ssigned (search for duplicates). That may not be feasible for longer tests.

comment:2 Changed 4 years ago by tomek

  • Milestone changed from DHCP Outstanding Tasks to Outstanding Tasks

Milestone renamed

comment:3 Changed 3 years ago by tomek

  • Component changed from dhcp to perfdhcp
  • Description modified (diff)
Note: See TracTickets for help on using tickets.