Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
Kea
Kea
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 416
    • Issues 416
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 67
    • Merge Requests 67
  • Operations
    • Operations
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • ISC Open Source Projects
  • KeaKea
  • Issues
  • #1084

Closed
Open
Opened Jan 15, 2020 by Rob Austein@sra

Kea does not recover from interface down when Kea starts

Problem scenario: Debian 9 server running Kea 1.7.1 package, server has three interfaces: eth1 serves directly connected hosts, eth2 and eth3 serve via DHCP relays, so must use "raw" rather than "udp" configuration. Problem is: server is part of a large rack of equipment, and we have no control over the order in which things come up, not to mention various replacement and reinstall scenarios. Kea quietly fails to listen on interfaces that show no carrier at the time Kea first starts, and never notices when they come up.

So far I have not thought of anything better than a separate process which monitors link states (eg with PyRoute2) and sends a config-reload control message whenever any of the interfaces comes up. This seems kind of lame.

Is this a known issue? Note that this is not the "new interface" problem: we know all the interfaces and list them in the config file, we just can't guarantee that they'll be up (and in some cases they can't come up until after Kea does because they're waiting for a DHCP lease in order to install the software that will eventually bring up the other end of the link).

Is this something ISC is likely to be able to fix anytime soon? Is there a better workaround?

Thanks! (Obligatory note: on the whole I'm very happy with Kea as a replacement for isc-dhcpd, don't think I'm complaining about the new thing... I just need to find a solution to this problem.)

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Kea1.9-backlog
Milestone
Kea1.9-backlog
Assign milestone
Time tracking
None
Due date
None
Reference: isc-projects/kea#1084