Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-21T14:54:27Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3286Allow absolute values for DDNS RR TTLs (to correctly meet RFC 4702, Section 5)2024-03-21T14:54:27ZRobin EdserAllow absolute values for DDNS RR TTLs (to correctly meet RFC 4702, Section 5)We are currently preparing a migration from `dhcpd` to Kea and are struggling a bit with DNS TTLs for DDNS entries created with Kea. We have a requirement from the organisation to have our default lease time be `2 days` / `172800 seconds...We are currently preparing a migration from `dhcpd` to Kea and are struggling a bit with DNS TTLs for DDNS entries created with Kea. We have a requirement from the organisation to have our default lease time be `2 days` / `172800 seconds`, but in combination with a short TTL of `300 seconds` because our Juniper firewall rules are almost entirely name based.
Since Kea only calculates the TTL we are currently having to set `ddns-ttl-percent` to `.00174` to get a `301 second` TTL. However since we are setting this globally, the result is that any client classes where we explicitly want much shorter lease than the default to get a `1 second` TTL.
RFC 4702, Section 5 does also mention that TTLs should also be configurable as an absolute time interval:
> We recognize that individual administrators
will have varying requirements: DHCP servers and clients SHOULD allow
administrators to configure TTLs and upper and lower bounds on the
TTL values, either as an absolute time interval or as a percentage of
the lease time.
This is something that would be ideal for us and hopefully useful for others. I hope it can be considered.
Thank you to the Kea devs and ISC for all your hard work :heart:next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3259IP allocation fails for reserved client with assingned class2024-03-28T14:57:21ZMichal ŠnajdrIP allocation fails for reserved client with assingned classHello,
using KEA 2.4.1 and experiencing issue with assigning addresses to PXE clients with configured class for assigning different boot image depending on option 60.
I have anonymized MAC to aa:bb:cc:dd:ee:ff from real one and also an...Hello,
using KEA 2.4.1 and experiencing issue with assigning addresses to PXE clients with configured class for assigning different boot image depending on option 60.
I have anonymized MAC to aa:bb:cc:dd:ee:ff from real one and also anonymized IPs.
Same behavior for multiple hosts in multiple subnets, following one host for example. No issue on segments using reservations and not using client-class.
3 messages are logged for each DISCOVERY.
```plaintext
Feb 21 15:23:57 dhcp-srv1 kea-dhcp4: WARN [kea-dhcp4.alloc-engine.139809839666944] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 aa:bb:cc:dd:ee:ff], cid=[no info], tid=0x3969612c: failed to allocate an IPv4 lease in the subnet 10.10.10.0/24, subnet-id 1251066000, shared network (none)
Feb 21 15:23:57 dhcp-srv1 kea-dhcp4: WARN [kea-dhcp4.alloc-engine.139809839666944] ALLOC_ENGINE_V4_ALLOC_FAIL_NO_POOLS [hwtype=1 aa:bb:cc:dd:ee:ff], cid=[no info], tid=0x3969612c: no pools were available for the address allocation
Feb 21 15:23:57 dhcp-srv1 kea-dhcp4: WARN [kea-dhcp4.alloc-engine.139809839666944] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 aa:bb:cc:dd:ee:ff], cid=[no info], tid=0x3969612c: Failed to allocate an IPv4 address for client with classes: ALL, HA_dhcp-srv1.company.cz, archi00, UNKNOWN
```
As seen from log, subnet is correctly recognized and it doesn't have any pool. Checked that configuration file with segment definition is included.
Subnet definition, only reservations (shortened to one host, all reservations defined in same format, no typo on MAC, checked):
```plaintext
{
"subnet": "10.10.10.0/24",
"id": 1251066000,
"option-data": [
{
"name": "routers",
"data": "10.10.10.1"
},
{
"name": "domain-name",
"data": "company.cz"
}
],
"next-server": "10.30.30.30",
"reservations": [
.......
{
#"hostname": "server.company.cz",
"hw-address": "aa:bb:cc:dd:ee:ff",
"ip-address": "10.10.10.57"
},
.......
]
};
```
Configuration of client-classes:
```plaintext
"client-classes": [
{
"name": "archi07",
"test": "(substring(option[60].hex,0,20) == 'PXEClient:Arch:00007') and (pkt.src == 10.10.30.1 or pkt.src == 10.10.10.1 or pkt.src == 10.10.20.1)",
"option-data": [
{
"name": "boot-file-name",
"data": "/grub/x86_64-efi/core.efi"
}
]
},
{
"name": "archi09",
"test": "(substring(option[60].hex,0,20) == 'PXEClient:Arch:00009') and (pkt.src == 10.10.30.1 or pkt.src == 10.10.10.1 or pkt.src == 10.10.20.1)",
"option-data": [
{
"name": "boot-file-name",
"data": "/grub/x86_64-efi/core.efi"
}
]
},
{
"name": "archi00",
"test": "(pkt.src == 10.10.30.1 or pkt.src == 10.10.10.1 or pkt.src == 10.10.20.1) and (not member ('archi07') or not member ('archi09'))",
"option-data": [
{
"name": "boot-file-name",
"data": "/grub/i386-pc/core.0"
}
]
}
],
```
We had switched back to old isc-dhcp-server for affected segments for now. There clients are assigned with address.
Do we miss something or is this a bug?
Thanks Michaloutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3100Support array of OPT_RECORD_TYPE for Option definition2024-01-09T11:40:57ZPiotrek ZadrogaSupport array of OPT_RECORD_TYPE for Option definitionWhile working on #3074 it occurred to me that it would be very useful to be able to define new Option as an array of OPT_RECORD_TYPE.
We could consider implementing that in Kea.While working on #3074 it occurred to me that it would be very useful to be able to define new Option as an array of OPT_RECORD_TYPE.
We could consider implementing that in Kea.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2976Implement the ISC DHCP stash-agent-options in Kea2024-03-28T14:24:33ZFrancis DupontImplement the ISC DHCP stash-agent-options in KeaSee #218 for details but the idea is to handle v4 renew/rebind queries as they went thought a relay. As far as I can remember the idea is to use the hint (requested or client address) from the query to look up the lease and extract the R...See #218 for details but the idea is to handle v4 renew/rebind queries as they went thought a relay. As far as I can remember the idea is to use the hint (requested or client address) from the query to look up the lease and extract the RAI from its user context. Requires some design but on the paper this should do the job...
Note this is for v4 only because v6 requires a specific setup on both the client and the server for direct unicast queries so the problem never occurs in the real world.kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2374kea-admin lease-dump file permisions2022-11-02T15:10:41ZMarcin Godzinakea-admin lease-dump file permisionsCommand `kea-admin lease-dump` exports database as memfile file with permissions of user running the command.
If Kea is running from packages on Ubuntu it expects `/var/lib/kea/kea-leases4.csv`(or v6) file to be owned by `_kea` user/gro...Command `kea-admin lease-dump` exports database as memfile file with permissions of user running the command.
If Kea is running from packages on Ubuntu it expects `/var/lib/kea/kea-leases4.csv`(or v6) file to be owned by `_kea` user/group.
**In this case, we can not directly copy exported file without changing its permissions, or Kea will not be able to read the file and start.**
The problem was discovered during forge tests. The test Starts Kea with database and exports database to the memfile location. Then it restarts Kea using the exported file.
Test failed on Ubuntu using deb packages.
**Possible solutions:**
- We can modify the forge test to account for different permissions and modify help text of `lease-dump` command to warn user about possible permission clash.
- We can modify `lease-dump` script to detect what permissions the file should have, and apply them during export. This will solve import and export on the same system, but the problem will still exist if migrating to other systems with a different way of installing Kea.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2171Migrating old style (TXT) guard DNS records to DHCID2021-11-23T16:01:13ZTomek MrugalskiMigrating old style (TXT) guard DNS records to DHCIDDescription TBDDescription TBDoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2169ddns-rev-domainname2022-11-02T15:10:41ZPeter Daviesddns-rev-domainnameThe ISC dhcp server has the "ddns-rev-domainname" keyword which allows one to override the default reverse dns domain.
This could be handy when working with delegations of address spaces below octet boundaries.
for example:
20.0....The ISC dhcp server has the "ddns-rev-domainname" keyword which allows one to override the default reverse dns domain.
This could be handy when working with delegations of address spaces below octet boundaries.
for example:
20.0.168.192.in-addr.arpa. CNAME 20.0-64.0.168.192.in-addr.arpa.
20.0-64.0.168.192.in-addr.arpa. PTR mypc.example.com.
From a question raised on Kea-users@lists.isc.org mailing list.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1320kea migration advice document (kb?)2020-08-06T15:42:59ZVicky Riskvicky@isc.orgkea migration advice document (kb?)We got this suggestion from a user working on migrating from ISC DHCP to Kea.
Along with the Kea migration tool, we should have a migration doc that has:
- [ ] A high-level block-diagram showing the Kea/CB/Stork/DNS components and outl...We got this suggestion from a user working on migrating from ISC DHCP to Kea.
Along with the Kea migration tool, we should have a migration doc that has:
- [ ] A high-level block-diagram showing the Kea/CB/Stork/DNS components and outlining the primary architectural choices (multiple active/standby pairs, load-balanced pairs, sprinkling of backup servers, diverse geographic location, web server role and location(s), choice of backends vs built-in (leases, hosts, configuration), DHCP client connection, DDNS usage, etc. and how it all connects together
- [ ] 'host' statements for 'known' clients in ISC DHCP are similiar to 'global' reservations in Kea
(pls provide example configuration snippet)
- [x] Suggestion to run 'keama' on your current config to see similiar how other directives translate, and how they don't as a way to see how things translate.
- [ ] I really like the commented out directives, etc. in the template/example kea-dhcp4.conf and other config files, very helpful. Include a section with examples on using 'config-control', and in the API document illuminate how 'subnet4-add' and 'subnet4-del' are only for config-file (and not CB) use. Likewise for 'remote-subnet4-add', etc. Perhaps a mini section for heavy API/CB users pointing out things like that, or grouping/coloring the API methods according to the file vs. CB use and then in the short migration doc reference that.
- [ ] include a collection import of JSON from Postman for the API methods along with the brief instructions on where to get Postman and how to import/run an individual API call as a way to get that much closer to working API examples out-of-the-box.
perhaps give an example of how 'allow member of CLASS' and 'deny member of CLASS' in ISC would map to Kea.
- [ ] 'include' statements in ISC DHCP are similiar to '<? include "/var/dhcpd/etc/kea/kea-include-subnets.json" ?>' in Kea.
having a short section that shows the main DORA messages from ISC DHCP (and the forward-map and reverse-map lines) and how that will now show up in Kea.
- [ ] Provide a short 5-minute online video going over the block diagram, highlighting the decision points, and including the references to the short migration guide that captures the above.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1186JSON translator tool for CB2024-03-21T12:21:55ZPeter DaviesJSON translator tool for CB---
name: JSON translator tool for CB
about: Importing elements from a json configuration into CB
---
**Some initial questions**
This request looks like an extension to GT [#333](https://gitlab.isc.org/isc-projects/kea/-/issues/333) "pa...---
name: JSON translator tool for CB
about: Importing elements from a json configuration into CB
---
**Some initial questions**
This request looks like an extension to GT [#333](https://gitlab.isc.org/isc-projects/kea/-/issues/333) "parser libraries for servers (for netconf)
**Is your feature request related to a problem? Please describe.**
When migrating from a json based configuration to the Configuration Backend the user must identify each element in the configuration, locate the correct hooks command and apply the appropriate parameters
**Describe the solution you'd like**
A tool which takes a json configuration file as an input. The tool should identify any elements that are CB configurable for the current Kea version and produce a set of command which will create the appropriate elements in the CB.
**Describe alternatives you've considered**
As an extra function of keama
**Additional context**
Customer ticket RT [#16203](https://support.isc.org/Ticket/Display.html?id=16203)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/972Pool level DHCP options are ignored while returning ACK to client's INFORM2021-10-20T10:30:59ZGhost UserPool level DHCP options are ignored while returning ACK to client's INFORM**Bug Description**
For a client's DHCPINFORM message that requests (option 55) for a set of DHCP options, Kea ignores DHCP options in the pool configuration and only returns options specified in the subnet configuration while returning...**Bug Description**
For a client's DHCPINFORM message that requests (option 55) for a set of DHCP options, Kea ignores DHCP options in the pool configuration and only returns options specified in the subnet configuration while returning the DHCPACK
**To Reproduce**
For the example below, randomly selected option 67 (bootfile name) to test
1. Run Kea dhcpv4 with the following subnet config
```
"subnet4": [
{
"subnet": "192.168.5.0/24",
"pools": [
{
"pool": "192.168.5.111 - 192.168.5.222",
"option-data": [
{
"name": "boot-file-name",
"data": "poolLevel"
}]
}],
"option-data": [
{
"name": "boot-file-name",
"data": "subnetLevel"
}]
}
]
```
2. Client sends DHCPDISCOVER wherein client requests for Bootfile name (option 67) in the Parameter Request List (option 55)
3. Kea responds with DHCPOFFER that includes Bootfile name (option 67) with value `poolLevel` from pool configuration
4. Client follows up with DHCPREQUEST with the same list of options and Kea returns DHCPACK with the OFFER'd values.
5. Client sends DHCPINFORM requesting for Bootfile name (option 67) in the Parameter Request List (option 55)
6. Kea returns DHCPACK including Bootfile name (option 67) with unexpected value `subnetLevel`
**Expected behavior**
Server must respond to DHCPINFORM with values from the client's matching pool configuration in the DHCPACK, unless no such option is defined in the pool configuration.
In context of the example above, at step 6, server must return DHCPACK with value of Bootfile name (option 67) as `poolLevel`
**Environment:**
- Kea version: 1.7.1-git
git cf6a766d28c565bd4a0abe8631422dd9fdeb27ce
- OS: Ubuntu 18.04.2outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/266ISC DHCP release on roam flag2022-11-02T15:08:42ZFrancis DupontISC DHCP release on roam flag>>>
release-on-roam flag;
When enabled and the dhcpd server detects that a DHCPv6 client
(IAID+DUID) has roamed to a new network, it will release the
pre-existing leases on t...>>>
release-on-roam flag;
When enabled and the dhcpd server detects that a DHCPv6 client
(IAID+DUID) has roamed to a new network, it will release the
pre-existing leases on the old network and emit a log statement
similiar to the following:
"Client: <id> roamed to new network, releasing lease:
<address>"
The server will carry out all of the same steps that would nor-
mally occur when a client explicitly releases a lease. When
release-on-roam is disabled (the default) the server makes such
leases unavailable until they expire or the server is restarted.
Clients that need leases in multiple networks must supply a
unique IAID in each IA. This parameter may only be specified at
the global level.
>>>
Make sense for a moving client which for some reasons does not release its address at the previous location. Can be implemented in Kea if there is an easy and fast way to get leases by IAID+DUID only.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/265ISC DHCP eui-64 based allocation2022-11-02T15:08:42ZFrancis DupontISC DHCP eui-64 based allocationQuoting dhcpd.conf.5 about the optionAL EUI-64 feature:
>>>
use-eui-64 flag;
The use-eui-64 flag, if enabled, instructs the server to con-
struct an address using the client's EUI-64 DUID (...Quoting dhcpd.conf.5 about the optionAL EUI-64 feature:
>>>
use-eui-64 flag;
The use-eui-64 flag, if enabled, instructs the server to con-
struct an address using the client's EUI-64 DUID (Type 3, HW
Type EUI-64), rather than creating an address using the dynamic
algorithm. This means that a given DUID will always generate
the same address for a given pool and further that the address
is guaranteed to be unique to that DUID. The IPv6 address will
be calculated from the EUI-64 link layer address, conforming to
RFC 2373, unless there is a host declaration for the client-id.
The range6 statement for EUI-64 must define full /64 bit ranges.
Invalid ranges will be flagged during configuration parsing as
errors. See the following example:
subnet6 fc00:e4::/64 {
use-eui-64 true;
range6 fc00:e4::/64;
}
The statement may be specified down to the pool level, allowing
a mixture of dynamic and EUI-64 based pools.
During lease file parsing, any leases which map to an EUI-64
pool, that have a non-EUI-64 DUID or for which the lease address
is not the EUI-64 address for that DUID in that pool, will be
discarded.
If a host declaration exists for the DUID, the server grants the
address (fixed-prefix6, fixed-address6) according to the host
declaration, regardless of the DUID type of the client (even for
EUI-64 DUIDs).
If a client request's an EUI-64 lease for a given network, and
the resultant address conflicts with a fixed address reserva-
tion, the server will send the client a "no addresses available"
response.
Any client with a non-conforming DUID (not type 3 or not hw type
EUI-64) that is not linked to a host declaration, which requests
an address from an EUI-64 enabled pool will be ignored and the
event will be logged.
Any client with a non-conforming DUID (not type 3 or not hw type
EUI-64) that is not linked to a host declaration, which requests
an address from an EUI-64 enabled pool will be ignored and the
event will be logged.
Pools that are configured for EUI-64 will be skipped for dynamic
allocation. If there are no pools in the shared network from
which to allocate, the client will get back a no addresses
available status.
On an EUI-64 enabled pool, any client with a DUID 3, HW Type
EUI-64, requesting a solicit/renew and including IA_NA that do
not match the EUI-64 policy, they will be treated as though they
are "outside" the subnet for a given client message:
Solicit - Server will advertise with EUI-64 ia suboption,
but with rapid
commit off
Request - Server will send "an address not on link status",
and no ia
suboption Renew/Rebind - Server will send the requested
address ia
suboption with lifetimes of 0, plus an EUI-64 ia
Whether or not EUI-64 based leases are written out to the lease
database may be controlled by persist-eui-64-leases statement.
>>>
Added to ISC DHCP as an optional feature on customer request. Can be ported to Kea.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/250enforce an option in response2023-07-17T19:16:24ZFrancis Dupontenforce an option in responseISC DHCP configs use this trick (from Dan's samples):
```
option wpad code 252 = text;
....
# Windows doesn't put WPAD on its PRL, but does consume it.
option dhcp-parameter-request-list =
concat(...ISC DHCP configs use this trick (from Dan's samples):
```
option wpad code 252 = text;
....
# Windows doesn't put WPAD on its PRL, but does consume it.
option dhcp-parameter-request-list =
concat(option dhcp-parameter-request-list, fc);
```
The dhcp-parameter-request-list (aka PRL) option in received packets is patched to add the code fc (252) so responses will include it.
This feature was ported to Kea as the **always-send** option-data flag.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/249No shared-network pools2022-11-02T15:08:44ZFrancis DupontNo shared-network poolsIn Kea a pool must belongs to a subnet so pools at shared-network level as in ISC DHCP are no allowed.In Kea a pool must belongs to a subnet so pools at shared-network level as in ISC DHCP are no allowed.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/247ISC DHCP expression2022-11-02T15:08:44ZFrancis DupontISC DHCP expressionISC DHCP supports "expressions" of 3 types: boolean, data (string) and numeric (integer).
They can be used for matching classes, set option values, etc.
Unfortunately this system is not fully consistent, for instance if you'd like to se...ISC DHCP supports "expressions" of 3 types: boolean, data (string) and numeric (integer).
They can be used for matching classes, set option values, etc.
Unfortunately this system is not fully consistent, for instance if you'd like to set an option to true:
```
option ip-forwarding = true;
```
This does not work because true is not a keyword and is parsed as a variable reference. As it is not set at runtime it will be evaluated as null so false...
If you try a constant true expression (aka tautology):
```
option ip-forwarding = 'foo' = 'foo';
```
In this case you specify a boolean expression when the system wants a data expression so refused this attempt at parsing time.
Note it is worse for integers, in:
```
option default-ip-ttl = 12;
```
the 12 is in hexadecimal so in fact is 18... If you want a decimal value you need a context where a number is expected.
Cf KB references:
https://kb.isc.org/article/AA-00334/56/Do-the-list-of-parameters-in-the-dhcp-parameter-request-list-need-to-be-in-hex.html
and about inconsistencies in output/display:
https://kb.isc.org/article/AA-01039/56/Formatting-MAC-addresses-in-dhcpd-or-why-does-binary-to-ascii-strip-leading-zeroes.htmlbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/246ISC DHCP supports an ASCII or binary option type2022-11-02T15:08:44ZFrancis DupontISC DHCP supports an ASCII or binary option typeISC DHCP has two "string" types:
- t - ASCII text
- X - either an ASCII string or binary data. On
input, the option can be specified either as a quoted string or as
a colon-separated hex list.
Kea has string and binary, t matches strin...ISC DHCP has two "string" types:
- t - ASCII text
- X - either an ASCII string or binary data. On
input, the option can be specified either as a quoted string or as
a colon-separated hex list.
Kea has string and binary, t matches string but X can be either string or binary.
Now only one standard option has a trailing X so the implementation converts X to string (option-def) and when building data (option-data) converts full binary input to binary with csv-format to false. For trailing X add a comment saying that the last type should be changed to binary.
Unfortunately mostly for documentation purpose.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/245ISC DHCP users specify interfaces on the command line2022-11-02T15:08:42ZFrancis DupontISC DHCP users specify interfaces on the command lineThere is a real risk when converting an ISC DHCP server config to Kea to end with a config without interfaces. Note to add a wildcard interface does not really help...
As it is a difference in models there is nothing which can be done o...There is a real risk when converting an ISC DHCP server config to Kea to end with a config without interfaces. Note to add a wildcard interface does not really help...
As it is a difference in models there is nothing which can be done other to be aware.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/244ISC DHCP server hostname (vs IPv4 address) in option data2022-11-02T15:08:44ZFrancis DupontISC DHCP server hostname (vs IPv4 address) in option dataWhen it parses an IPv4 address the ISC DHCP parser accepts a DNS hostname which it resolves dynamically (i.e. when the value is used, not when it is parsed) into an address or a list of addresses.
This feature seems convenient at the fi...When it parses an IPv4 address the ISC DHCP parser accepts a DNS hostname which it resolves dynamically (i.e. when the value is used, not when it is parsed) into an address or a list of addresses.
This feature seems convenient at the first view but in fact is not, in particular for option values.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/243duplicate in ISC DHCP configuration2023-07-17T19:08:12ZFrancis Dupontduplicate in ISC DHCP configurationISC DHCP support a lot of duplications in config file, e.g. from Dan's sample:
- multiple class definitions (note the ISC DHCP parser merges definitions with the same class name so the MA does the same as it shares this code)
- multiple...ISC DHCP support a lot of duplications in config file, e.g. from Dan's sample:
- multiple class definitions (note the ISC DHCP parser merges definitions with the same class name so the MA does the same as it shares this code)
- multiple option definitions
- multiple host (aka reservation) definitions sharing the same address
The last two are IMHO errors so I commented them out. In conclusion the problem is more on the ISC DHCP side and to accept less duplication in Kea is both right and should be spread.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/242ISC DHCP server config option server-id-check2023-07-17T19:04:26ZFrancis DupontISC 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 D...>>>
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.backlog