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 415
    • Issues 415
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 65
    • Merge Requests 65
  • 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
  • #242

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

ISC DHCP server config option server-id-check

The server-id-check statement

server-id-check flag;

The server-id-check statement is used to control whether or not a server, participating in failover, verifies that the value of the dhcp-server-identifier option in received DHCP REQUESTs match the server's id before processing the request. Server id checking is disabled by default. Setting this flag enables id checking and thereafter the server will only process requests that match. Note the flag setting should be consistent between failover partners.

Unless overridden by use of the server-identifier statement, the value the server uses as its id will be the first IP address asso- ciated with the physical network interface on which the request arrived.

In order to reduce runtime overhead the server only checks for a server id option in the global and subnet scopes. Complicated configurations may result in different server ids for this check and when the server id for a reply packet is determined, which would prohibit the server from responding.

The primary use for this option is when a client broadcasts a request but requires that the response come from a specific failover peer. An example of this would be when a client reboots while its lease is still active - in this case both servers will normally respond. Most of the time the client won't check the server id and can use either of the responses. However if the client does check the server id it may reject the response if it came from the wrong peer. If the timing is such that the "wrong" peer responds first most of the time the client may not get an address for some time.

Care should be taken before enabling this option.

Dubious idea: for documentation purpose only.

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