Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Kea Kea
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 505
    • Issues 505
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 52
    • Merge requests 52
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • KeaKea
  • Issues
  • #221

Closed
Open
Created Nov 06, 2018 by Francis Dupont@fdupontDeveloper

Kea vs ISC DHCP timers

ISC DHCP uses 3 values (max, min and default) values for lease-time (valid-lifetime) in Kea). These 3 values are in the Kea code (aka the triplet class) but are not reflected in config. (note I don't say a solution is better but they are different). As the valid-lifetime is a mandatory config parameter this means Kea is rigid (same comment).

For other timers ISC DHCP has preferred-lifetime but derives t1 and t2 (aka renew and rebind timers) from the valid one using standard formula. ISC DHCP follows more the client query, i.e., it uses configured values including computed values only as default and bounds.

This is not a call to change something: it is just a summary for documentation and some infos in the case a customer requests more flexibility.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking