Opened 2 years ago

Closed 2 years ago

#5381 closed defect (fixed)

need more shared-network documentation

Reported by: fdupont Owned by: marcin
Priority: medium Milestone: Kea1.3-final
Component: Unclassified Version: git
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

For instance how resource allocation from pools is done: only host reservations are documented.

Subtickets

Change History (10)

comment:1 Changed 2 years ago by tomek

Francis will update this ticket with a list of questions that should be answered. We'll re-evaluate it next week.

comment:2 Changed 2 years ago by fdupont

  • Owner set to fdupont
  • Status changed from new to accepted

comment:3 Changed 2 years ago by fdupont

8.4 and 9.4 first figures are badly indented: the "free" subnet should be at the same level than the shared network (vs subnets in the shared network). I created a trac5381 branch to fix this.

I have another concern about these examples: there is no matching selector (e.g. an interface) for discover. I don't know if it is something required in guide examples but IMHO it is not the best idea to give examples which won't work in the real world without a warning. And it doesn't go well with next .1 subsections.

.2 subsections are not clear enough: what is the difference between two free subnets using client-classes and two subnets in the same shared network using client-classes. According to the text the only difference is in shared network parameters so if I derive shared network parameters in the two classes I should get exactly the same behavior keeping or removing the shared network. I am not against this if it is right but it should be clarified.

.3 (host reservation) subsections are the only shared network documentation which IMHO currently makes sense. I have only two small concerns: what happens with multiple reservations for the same host (undefined, first match is taken, selected subnet has the priority)? (note it is small concern because it is explicitly not recommended). Second is about the auto ID: I believe the reason they should be not used is because the ID is not stable on config changes. If it is the issue then it should be repeated in the subnet ID subsections.

So without client-classes the host reservation handling is clear. It is not the case for pools in particular on DHCPv4 discover or DHCPv6 solicit without a hint. In ISC DHCP pools in shared network are in fact in the shared network scope: quoting ISC DHCP dhcp.conf.5 "There is no way to distinguish on which subnet of a shared network a client should boot.". I believe it is not the case in Kea and pools of the selected subnet are used until there is no resource available (a term to define more accurately because of expired bindings) and pools of other subnets in the same shared network are used. I remember too Thomas arguing the same client should stay in the same subnet...

comment:4 Changed 2 years ago by marcin

  • Milestone changed from Kea-proposed to Kea1.3-final

Per Kea call on October 13th, moving this to 1.3 final.

comment:5 Changed 2 years ago by fdupont

  • Owner changed from fdupont to UnAssigned
  • Status changed from accepted to assigned

comment:6 Changed 2 years ago by marcin

  • Owner changed from UnAssigned to marcin
  • Status changed from assigned to accepted

comment:7 Changed 2 years ago by marcin

  • Owner changed from marcin to UnAssigned
  • Status changed from accepted to reviewing

I improved documentation of shared networks as requested. Hope that makes things clearer.

Proposed ChangeLog entry:

13XX.	[doc]		marcin
	Improved documentation of shared networks within Kea Administrator's
	Manual.
	(Trac #5381, git cafe)

comment:8 Changed 2 years ago by fdupont

  • Owner changed from UnAssigned to fdupont

comment:9 Changed 2 years ago by fdupont

  • Owner changed from fdupont to marcin

Perhaps we should get a second eye by a native English writer...

I have a minor concern about the DHCPv6 changes: there is nothing about prefixes. Note if there is no real differences with addresses there is IMHO no reason to perform another round of review.

A detail: is it the Administrator guide (as the title and common sense suggest) or the user guide (as the Kea web says)?

comment:10 Changed 2 years ago by marcin

  • Resolution set to fixed
  • Status changed from reviewing to closed

Merged with commit c4be6a71ed3705c182d7ba4417a06ed8fa59f2b5

Note: See TracTickets for help on using tickets.