Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2020-08-06T22:11:39Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/364Describe the Kea process for selecting a subnet/address and assigning options2020-08-06T22:11:39ZVicky Riskvicky@isc.orgDescribe the Kea process for selecting a subnet/address and assigning optionsIt would be very helpful to have a clear and explicit write up, and/or a diagram showing what information is evaluated, in what order, in the process of determining what address will be offered to a client, and how the options are assign...It would be very helpful to have a clear and explicit write up, and/or a diagram showing what information is evaluated, in what order, in the process of determining what address will be offered to a client, and how the options are assigned.
While there will be exceptions that complicate this, what we are looking for first is, what is the default process for a new offer for a DHCPv4 client?kea1.8.0Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2854Include Client ID in EVAL_RESULT msg2023-08-22T19:17:27ZPeter DaviesInclude Client ID in EVAL_RESULT msgInclude Client ID in EVAL_RESULT msg:
It may be useful for users tracking client behaviour to have the client id present in the INFO message EVAL_RESULT
From:
INFO [kea-dhcp4.dhcpsrv/27.121957] EVAL_RESULT Expression Some_C...Include Client ID in EVAL_RESULT msg:
It may be useful for users tracking client behaviour to have the client id present in the INFO message EVAL_RESULT
From:
INFO [kea-dhcp4.dhcpsrv/27.121957] EVAL_RESULT Expression Some_Class evaluated to 1
To:
INFO [kea-dhcp4.dhcpsrv/27.121957] EVAL_RESULT Expression Some_Class evaluated to 1 for client with cid="e6:3f:f1:2d:ca:3c"
[RT #220060](https://support.isc.org/Ticket/Display.html?id=22060)kea2.5.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1683kea is not accepting custom spaces in option definitions in class2023-04-04T09:50:34ZWlodzimierz Wencelkea is not accepting custom spaces in option definitions in classoptions in kea can be defined in kea standard space `dhcp4` and `dhcp6` or custom spaces e.g.:
```
"option-def": [
{
"array": false,
"code": 242,
"encapsulate": "",
"name": "dls",
"record-types": "",
"space": "X...options in kea can be defined in kea standard space `dhcp4` and `dhcp6` or custom spaces e.g.:
```
"option-def": [
{
"array": false,
"code": 242,
"encapsulate": "",
"name": "dls",
"record-types": "",
"space": "XYZ",
"type": "string"
}
],
```
But Kea accept custom spaces only on global level, returns error with this configuration:
```
client-classes": [
{
"option-def": [
{
"encapsulate": "339",
"code": 43,
"type": "empty",
"name": "vendor-encapsulated-options"
},
{
"code": 2,
"name": "vlanid",
"space": "339",
"type": "uint32",
"record-types": "",
"array": false,
"encapsulate": ""
},
{
"code": 3,
"name": "dls",
"space": "339",
"type": "string",
"record-types": "",
"array": false,
"encapsulate": ""
}
],
"name": "VENDOR_CLASS_339",
"option-data": [
{
"name": "vendor-encapsulated-options"
},
{
"always-send": true,
"data": "123",
"name": "vlanid",
"space": "339"
},
{
"always-send": true,
"data": "sdlp://192.0.2.11:18443",
"name": "dls",
"space": "339"
}
]
}
],
```
Error:
```
2021-01-28 07:16:28.281 INFO [kea-dhcp4.dhcp4/27394.140192072867456] DHCP4_STARTING Kea DHCPv4 server version 1.9.4-git (development) starting
2021-01-28 07:16:28.282 WARN [kea-dhcp4.dhcp4/27394.140192072867456] DHCP4_DEVELOPMENT_VERSION This software is a development branch of Kea. It is not recommended for production use.
2021-01-28 07:16:28.283 ERROR [kea-dhcp4.dhcp4/27394.140192072867456] DHCP4_CONFIG_LOAD_FAIL configuration error using file: /home/wlodek/installed/git/etc/kea/kea-dhcp4.conf, reason: Not allowed option definition for code '2' in space '339' at (/home/wlodek/installed/git/etc/kea/kea-dhcp4.conf:46:21)
2021-01-28 07:16:28.285 ERROR [kea-dhcp4.dhcp4/27394.140192072867456] DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file '/home/wlodek/installed/git/etc/kea/kea-dhcp4.conf': Not allowed option definition for code '2' in space '339' at (/home/wlodek/installed/git/etc/kea/kea-dhcp4.conf:46:21)
```
Making impossible to have multiple suboptions code `2` for different classes.
full config attached [kea-dhcp4.conf](/uploads/d68a9d83bf876bf2b8dd033f738424da/kea-dhcp4.conf)current-stable-2.4https://gitlab.isc.org/isc-projects/kea/-/issues/2841T1 Renewal of lease in Shared subnet to class restricted pool is not working.2023-06-22T13:30:31ZmikkihugoT1 Renewal of lease in Shared subnet to class restricted pool is not working.We have two pools for a serviceprovider network. Customers by default get a CGNAT ip, but we whitelist users who needs a public ip using class public globally. The result seems to be that users in public class works when lease is first d...We have two pools for a serviceprovider network. Customers by default get a CGNAT ip, but we whitelist users who needs a public ip using class public globally. The result seems to be that users in public class works when lease is first done via GI but for T1 release the Kea does not put them in the correct class and therefore blocks them from updating the lease.
The config is quite simple - pasting in relevant sections. The GIs for inital request are on 100.96.0.5-100.96.3.254.
```
"client-classes":[
{
"name":"public"
},
{
"name":"nat",
"test":"not member('public')"
}
],
"reservations": [
// Public to pool
{
"hw-address": "fc:34:97:5c:cb:58",
"client-classes": [ "public" ]
},
{
"valid-lifetime":3600,
// "renew-timer":600,
// "rebind-timer":1000,
"name":"Open Network",
"subnet4":[
{
"id":555,
"pools":[
{
"pool":"181.23.35.130-185.23.35.158"
}
],
"subnet":"181.23.35.128/27",
"client-class":"public"
}
],
"option-data":[
{
"name":"routers",
"data":"181.23.35.129"
}
]
},
{
"id": 222,
"pools":[
{
"pool":"100.96.4.1 - 100.96.127.254"
}
],
"subnet":"100.96.0.0/16",
"client-class":"nat",
"option-data":[
{
"name":"routers",
"data":"100.96.0.60"
}
]
}
]
},
```
This is the T1 renew that fails. We suspect the subnet selection fails since the class is not set for some odd reason.
```
112 14:23:45.644 kea-dhcp4.packets DHCP4_BUFFER_RECEIVED received buffer from 181.23.35.140:68 to 1.1.1.8:67 over interface eth0
112 14:23:45.644 kea-dhcp4.callouts HOOKS_CALLOUTS_BEGIN begin all callouts for hook buffer4_receive
112 14:23:45.644 kea-dhcp4.callouts HOOKS_CALLOUT_CALLED hooks library with index 3 has called a callout on hook buffer4_receive that has address 0x7f1a70d0fa70 (callout duration: 0.146 ms)
112 14:23:45.644 kea-dhcp4.callouts HOOKS_CALLOUTS_COMPLETE completed callouts for hook buffer4_receive (total callouts duration: 0.146 ms)
112 14:23:45.644 kea-dhcp4.hooks DHCP4_HOOK_BUFFER_RCVD_SKIP received buffer from 181.23.35.140 to 1.1.1.8 over interface eth0 is not parsed because a callout set the next step to SKIP.
112 14:23:45.644 kea-dhcp4.eval EVAL_DEBUG_MEMBER Checking membership of 'public', pushing result 'false'
112 14:23:45.644 kea-dhcp4.eval EVAL_DEBUG_NOT Popping 'false' pushing 'true'
112 14:23:45.644 kea-dhcp4.options EVAL_RESULT Expression nat evaluated to 1
112 14:23:45.645 kea-dhcp4.packets DHCP4_PACKET_RECEIVED [hwtype=1 fc:34:97:5c:cb:58], cid=[01:fc:34:97:5c:cb:58], tid=0x19fe2348: DHCPREQUEST (type 3) received from 181.23.35.140 to 1.1.1.8 on interface eth0
112 14:23:45.645 kea-dhcp4.packets DHCP4_QUERY_DATA [hwtype=1 fc:34:97:5c:cb:58], cid=[01:fc:34:97:5c:cb:58], tid=0x19fe2348, packet details: local_address=1.1.1.8:67, remote_address=181.23.35.140:68, msg_typ>
options:
type=053, len=001: 3 (uint8)
type=055, len=009: 1(uint8) 3(uint8) 6(uint8) 12(uint8) 15(uint8) 28(uint8) 33(uint8) 42(uint8) 249(uint8)
type=057, len=002: 1492 (uint16)
type=060, len=012: "udhcp 1.17.4" (string)
type=061, len=007: 01:fc:34:97:5c:cb:58
type=082, len=062:,
options:
type=001, len=014: 73:69:67:32:31:2d:62:66:31:7c:31:30:30:35
type=002, len=021: 4d:4d:2d:42:4e:47:2d:53:45:2d:53:7c:66:72:65:2d:73:65:63:32:31
type=006, len=021: 53:45:52:2d:48:53:49:2d:4f:31:30:30:30:30:31:37:32:30:38:38:35
112 14:23:45.645 kea-dhcp4.dhcpsrv DHCPSRV_SUBNET4_SELECT_NO_RAI_OPTIONS No RAI options found to use for subnet selection.
112 14:23:45.645 kea-dhcp4.dhcpsrv DHCPSRV_SUBNET4_SELECT_NO_RELAY_ADDRESS Relay address (giaddr) in client packet is empty.
112 14:23:45.645 kea-dhcp4.dhcpsrv DHCPSRV_SUBNET4_SELECT_BY_ADDRESS_NO_MATCH No subnet matches address: 181.23.35.140
112 14:23:45.645 kea-dhcp4.packets DHCP4_SUBNET_SELECTION_FAILED [hwtype=1 fc:34:97:5c:cb:58], cid=[01:fc:34:97:5c:cb:58], tid=0x19fe2348: failed to select subnet for the client
112 14:23:45.645 kea-dhcp4.dhcp4 DHCP4_CLASS_ASSIGNED [hwtype=1 fc:34:97:5c:cb:58], cid=[01:fc:34:97:5c:cb:58], tid=0x19fe2348: client packet has been assigned to the following class(es): UNKNOWN
112 14:23:45.645 kea-dhcp4.dhcp4 DHCP4_CLASS_ASSIGNED [hwtype=1 fc:34:97:5c:cb:58], cid=[01:fc:34:97:5c:cb:58], tid=0x19fe2348: client packet has been assigned to the following class(es): ALL, HA_kea1, VENDOR_CLASS_u>
112 14:23:45.645 kea-dhcp4.callouts HOOKS_CALLOUTS_BEGIN begin all callouts for hook leases4_committed
112 14:23:45.645 kea-dhcp4.ha-hooks HA_LEASES4_COMMITTED_NOTHING_TO_UPDATE [hwtype=1 fc:34:97:5c:cb:58], cid=[01:fc:34:97:5c:cb:58], tid=0x19fe2348: leases4_committed callout was invoked without any leases
112 14:23:45.645 kea-dhcp4.callouts HOOKS_CALLOUT_CALLED hooks library with index 3 has called a callout on hook leases4_committed that has address 0x7f1a70d0faf0 (callout duration: 0.123 ms)
112 14:23:45.645 kea-dhcp4.callouts HOOKS_CALLOUTS_COMPLETE completed callouts for hook leases4_committed (total callouts duration: 0.123 ms)
112 14:23:45.645 kea-dhcp4.options DHCP4_PACKET_PACK [hwtype=1 fc:34:97:5c:cb:58], cid=[01:fc:34:97:5c:cb:58], tid=0x19fe2348: preparing on-wire format of the packet to be sent
112 14:23:45.646 kea-dhcp4.packets DHCP4_PACKET_SEND [hwtype=1 fc:34:97:5c:cb:58], cid=[01:fc:34:97:5c:cb:58], tid=0x19fe2348: trying to send packet DHCPNAK (type 6) from 1.1.1.8:67 to 181.23.35.140:68 on int>
112 14:23:45.646 kea-dhcp4.packets DHCP4_RESPONSE_DATA [hwtype=1 fc:34:97:5c:cb:58], cid=[01:fc:34:97:5c:cb:58], tid=0x19fe2348: responding with packet DHCPNAK (type 6), packet details: local_address=181.23.35.254:6>
options:
type=053, len=001: 6 (uint8)
type=054, len=004: 1.1.1.8
type=061, len=007: 01:fc:34:97:5c:cb:58
type=082, len=062:,
options:
type=001, len=014: 73:69:67:32:31:2d:62:66:31:7c:31:30:30:35
type=002, len=021: 4d:4d:2d:42:4e:47:2d:53:45:2d:53:7c:66:72:65:2d:73:65:63:32:31
type=006, len=021: 53:45:52:2d:48:53:49:2d:4f:31:30:30:30:30:31:37:32:30:38:38:35
```https://gitlab.isc.org/isc-projects/kea/-/issues/2739Unstable lease lifetime returns with client classification2023-07-17T13:58:22ZDarren AnkneyUnstable lease lifetime returns with client classificationIt is possible to receive different values for lease lifetimes without altering the configuration if lease lifetimes are specified in the client class as shown in the configuration below
```
{
"Dhcp6": {
"valid-lifetime": 300,
...It is possible to receive different values for lease lifetimes without altering the configuration if lease lifetimes are specified in the client class as shown in the configuration below
```
{
"Dhcp6": {
"valid-lifetime": 300,
"preferred-lifetime": 280,
"interfaces-config": {
"interfaces": [ "ens256" ]
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/tmp/kea-leases6.csv"
},
"client-classes": [
{
"name": "my-filter-v6",
"test": "option[1].exists",
"preferred-lifetime": 74,
"valid-lifetime": 76
}
],
"subnet6": [
{
"subnet": "2001:db8::/64",
"valid-lifetime": 90,
"preferred-lifetime": 85,
"pools": [
{
"pool": "2001:db8::100-2001:db8::200"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/tmp/kea-dhcp6.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
}
}
```
Start the server and run perfdhcp: `perfdhcp -6 -r 1 -R 100 -l ens256`
If the client is added to the class `my-filter-v6`, one would expect that the client would receive a valid lifetime of 76 from the class (and it might). Restart the server again (it may help to clear the lease file or just not use persist - I wasn't able to determine if that had any affect), and the client(s) that are in class `my-filter-v6` might get 90 as their valid lease lifetime which is from the subnet declaration. Remove the subnet level lease lifetimes and clients that match the class might get lease lifetimes from the class. Restart the server again and the client might get global level lease lifetimes of 300. Remove the global lifetime configurations and the clients might get the lifetimes from the class. Restart again and they might get 7200 which is the default.
It may take several restarts to notice the change.
I tested this on 2.0.3, 2.2.0 and 2.3.3 and the behavior was exhibited in all of those versions. I was not able to reproduce this behavior in kea-dhcp4.
[RT 21756](https://support.isc.org/Ticket/Display.html?id=21756)kea2.3.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2720EVAL_RESULT is logged under different logger for v4 and v62023-07-17T13:58:22ZAndrei Pavelandrei@isc.orgEVAL_RESULT is logged under different logger for v4 and v6The evaluation that is done as part of a client class being mentioned in the `require-client-classes` array is logged under different loggers in v4 and v6:
```
INFO [kea-dhcp4.options] EVAL_RESULT Expression all evaluated to 1
```
```
I...The evaluation that is done as part of a client class being mentioned in the `require-client-classes` array is logged under different loggers in v4 and v6:
```
INFO [kea-dhcp4.options] EVAL_RESULT Expression all evaluated to 1
```
```
INFO [kea-dhcp6.dhcp6] EVAL_RESULT Expression all evaluated to 1
```
There seems to be no reason for it, and it can be confusing, and can lead to loss of log messages for users who use both v4 and v6 and filter messages by logger and expect to find the same message types in both logs.
First reported here: https://lists.isc.org/pipermail/kea-users/2022-June/003483.htmlkea2.3.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2664Additional use of test statement2023-07-17T13:58:22ZPeter DaviesAdditional use of test statementA suggestion to improve documentation.
Regarding the "test": statement which may be employed in the definition of client
classes. There are no examples in the ARM that document usage where two separate
values retrieved from a pack...A suggestion to improve documentation.
Regarding the "test": statement which may be employed in the definition of client
classes. There are no examples in the ARM that document usage where two separate
values retrieved from a packet are compared with each other. All examples compare
a value retrieved from a packet with a constant value or test for membership of
other classes. The following is also possible:
```
"client-classes": [
{ "name": "Infrastructure",
"test": "option[82].option[2].hex == pkt4.mac" },
...
],
```
This is a result of discussions done in [RT#21407](https://support.isc.org/Ticket/Display.html?id=21407)kea2.3.5Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2606create documentation for template-classes2023-07-17T13:58:24ZRazvan Becheriucreate documentation for template-classeskea2.3.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2543Add feature to ignore RAI Link Selection suboption for subnet selection2023-07-17T13:58:24ZDan TheisenAdd feature to ignore RAI Link Selection suboption for subnet selectionIt seems that some vendors may not allow granular control of the option 82 suboptions which are sent. We should add a configuration parameter that allows clients to choose whether or not the RAI Link Selection suboption (option 82.5) is ...It seems that some vendors may not allow granular control of the option 82 suboptions which are sent. We should add a configuration parameter that allows clients to choose whether or not the RAI Link Selection suboption (option 82.5) is used as the primary source of truth for which subnet to use. Clients need to be able to choose the subnet selection logic that Kea regardless of which vendors they use for routing equipment. The specific client in question is attempting to use option 82.1 to classify packets into specific client classes, and use client classification to determine the subnet which a client has an address assigned from. The subnet specified by the routers in the Link Selection subnet is not necessarily the subnet which the client should use. The client uses Juniper routers as DHCP relays, and Juniper's docs do not shed light on how to specifically disable the Link Selection suboption: https://stage.juniper.net/documentation/us/en/software/junos/subscriber-mgmt-sessions/topics/topic-map/dhcp-option-82-using.html#id-using-dhcp-relay-agent-option-82-information
Users should be able to ignore the Link Selection suboption as a primary source of truth for subnet selection, and instead fall back to the normal subnet selection process that is used when the Link Selection suboption is not present. In this case, the routers still include a giaddr (relay address) in the bootp header that can be used for shared network selection.
(Another proposed solution was flex-option for queries)
[RT#20921](https://support.isc.org/Ticket/Display.html?id=20921)kea2.3.2Dan TheisenDan Theisenhttps://gitlab.isc.org/isc-projects/kea/-/issues/2336Unexpected stack order message2022-03-16T18:24:35ZPeter DaviesUnexpected stack order message---
name: Unexpected stack order message
about: An error message is generated
---
**Describe the bug**
The following message is generated
"ERROR [kea-dhcp4.options/721920.139927012644608] EVAL_RESULT Expression "bootfile" evaluate...---
name: Unexpected stack order message
about: An error message is generated
---
**Describe the bug**
The following message is generated
"ERROR [kea-dhcp4.options/721920.139927012644608] EVAL_RESULT Expression "bootfile" evaluated to Incorrect stack order. Expected exactly 1 value at the end of evaluation, got 0"
**To Reproduce**
See configuration on RT ticket
**Expected behavior**
This message is unexpected
**Environment:**
- Kea version: 2.0.1
- OS: linux
- Configuration backend
- See RT ticket
**Additional Information**
Maybe related to #2077
[RT #20066](https://support.isc.org/Ticket/Display.html?id=20066)kea2.1.4Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2249early global reservation lookup for classes2022-07-07T07:11:25ZFrancis Dupontearly global reservation lookup for classesThe idea is to introduce a new global boolean parameter (*) which:
- makes global reservations to be search as soon as possible
- add reserved classes to the query
- perform classification
- check the drop class (if the query is in t...The idea is to introduce a new global boolean parameter (*) which:
- makes global reservations to be search as soon as possible
- add reserved classes to the query
- perform classification
- check the drop class (if the query is in the class drop it)
- use classes as guards for subnets and pools
This implements with other goodies the drop using reservations (more convenient in some cases than long classification expressions) asked by some customers.
This change should address #1973, #1543.kea2.1.4Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2077evaluation error on CB class test expressions2022-03-01T06:51:13ZAndrei Pavelandrei@isc.orgevaluation error on CB class test expressions1. Start a Kea with CB and debug logging [kea-dhcp4.conf](https://gitlab.isc.org/isc-projects/kea/-/snippets/1009).
2. Start a kea-ctrl-agent [kea-ctrl-agent.conf](https://gitlab.isc.org/isc-projects/kea/-/snippets/1010).
3. Create a cla...1. Start a Kea with CB and debug logging [kea-dhcp4.conf](https://gitlab.isc.org/isc-projects/kea/-/snippets/1009).
2. Start a kea-ctrl-agent [kea-ctrl-agent.conf](https://gitlab.isc.org/isc-projects/kea/-/snippets/1010).
3. Create a class that tests the equality operator between an option substring and a literal string:
```sh
$ curl -X POST 10.1.0.2:8080 -H 'Content-Type: application/json' -d "$(cat <<HERE_DOCUMENT
{
"arguments": {
"client-classes": [
{
"name": "my-class",
"test": "substring(option[1].hex, 0, 8) == 'my-value'"
}
],
"remote": {
"type": "mysql"
},
"server-tags": [
"all"
]
},
"command": "remote-class4-set",
"service": [
"dhcp4"
]
}
HERE_DOCUMENT
)"
[ { "arguments": { "client-classes": [ { "name": "my-class" } ] }, "result": 0, "text": "DHCPv4 client class successfully set." } ]
```
4. Wait for Kea to pull configuration signaled through the log message: `DEBUG MYSQL_CB_GET_ALL_CLIENT_CLASSES4_RESULT retrieving: 1 elements`
5. Send perfdhcp traffic: `perfdhcp -4 -l vethclient -r 1 -t 1`.
6. Observe error log message: `ERROR EVAL_RESULT Expression my-class evaluated to Incorrect stack order. Expected exactly 1 value at the end of evaluation, got 0`.
Expected result: the my-class expression gets succesfully evaluated to either true or false.
Alternative scenario: configuring the client class in the file configuration evalutes the expression succesfully to true or false.
```json
"client-classes": [
{
"name": "my-class",
"test": "substring(option[1].hex, 0, 8) == 'my-value'"
}
]
```
```
DEBUG EVAL_DEBUG_OPTION Pushing option 1 with value 0x
DEBUG EVAL_DEBUG_STRING Pushing text string '0'
DEBUG EVAL_DEBUG_STRING Pushing text string '8'
DEBUG EVAL_DEBUG_SUBSTRING_EMPTY Popping length 8, start 0, string 0x pushing result 0x
DEBUG EVAL_DEBUG_STRING Pushing text string 'my-value'
DEBUG EVAL_DEBUG_EQUAL Popping 0x6D792D76616C7565 and 0x pushing result 'false'
DEBUG EVAL_RESULT Expression my-class evaluated to 0
```
Hint: in CB's case, `EVAL_DEBUG_*` messages are missing from the logs. I would suggest logging them in this MR if the estimated effort is minimal.
[RT #18874](https://support.isc.org/Ticket/Display.html?id=18874)kea2.0.0 (formerly 1.9.12)Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2028remote-class4-set fails if it depends options that are created in the CB2021-09-22T13:06:31ZPeter Daviesremote-class4-set fails if it depends options that are created in the CBremote-class4-set fails if it depends options that are created in the CB:
The following command fails if the option-data is defined in the CB. It succeeds if the option-data is defined in the configuration file
```
curl -kSs -...remote-class4-set fails if it depends options that are created in the CB:
The following command fails if the option-data is defined in the CB. It succeeds if the option-data is defined in the configuration file
```
curl -kSs -H "Content-Type:application/json" -u 'admin:<pass>' https://10.0.0.1 -d '{"service":["dhcp4"],"command":"remote-class4-set","arguments":{"client-classes":[{ "name": "xxxx", "boot-file-name": "bootfile", "valid-lifetime": 180, "test": "substring(option[60].hex,0,11) == '\''xxxx'\''", "option-data": [ { "space": "XXXX", "name": "config-file-name", "code": 1, "data": "xyz", "always-send": true }, { "space": "dhcp4", "name": "tftp-server-name", "code": 66, "data": "10.0.0.1", "always-send": true } ] }],"remote":{"type":"mysql"},"server-tags":["all"]}}'
```
```
[
{
"result": 1,
"text": "option data is not a valid string of hexadecimal digits: xyz (<wire>:0:151)"
}
]
```
[RT #18879](https://support.isc.org/Ticket/Display.html?id=18879)kea2.0.0 (formerly 1.9.12)Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1973deny-class2022-04-21T06:24:31ZPeter Daviesdeny-classWould it be possible to have a new keyword - maybe called "deny-class" for with IP address allocation based on client classification. Something like the following:
```
"pools": [
{
"client-class": "SPECIAL_CLIENTS", ...Would it be possible to have a new keyword - maybe called "deny-class" for with IP address allocation based on client classification. Something like the following:
```
"pools": [
{
"client-class": "SPECIAL_CLIENTS",
"option-data": [],
"pool": "10.0.0.50-10.0.0.100"
},
{
"deny-class": "UNWELCOME_CLIENTS",
"option-data": [],
"pool": "10.0.0.101-10.50.0.255"
}
]
```
[RT #18741](https://support.isc.org/Ticket/Display.html?id=18741)kea2.1.5https://gitlab.isc.org/isc-projects/kea/-/issues/1672DHCPv4 fixed fields, such as boot-file-name, value precedence order is incons...2021-02-23T16:31:18ZThomas MarkwalderDHCPv4 fixed fields, such as boot-file-name, value precedence order is inconsistent with optionsThere are three "fixed" fields next-server, server-hostname, and boot-file-name sent in DHCPv4 ACKs.
They are not handled like configured options, rather they are handled in Dhcpv4Srv::setFixedFields(). This function cycles through all...There are three "fixed" fields next-server, server-hostname, and boot-file-name sent in DHCPv4 ACKs.
They are not handled like configured options, rather they are handled in Dhcpv4Srv::setFixedFields(). This function cycles through all classes associated with the client's packet, in the order they are associated, and uses the last value for a given option found. This is exactly the opposite of what we do for configured options. For those we evaluate the classes in the associated order BUT we use the first value for a given option. For example, using the following config:
```
"client-classes": [
{
"name":"one",
"boot-file-name":"one.boot",
"option-data": [
{
"name": "domain-name-servers",
"data": "1.1.1.1"
}]
},
{
"name":"two",
"boot-file-name":"two.boot",
"option-data": [
{
"name": "domain-name-servers",
"data": "2.2.2.2"
}]
}
],
"subnet4": [
{
"id": 1500,
"subnet": "178.0.0.0/8",
"pools": [ { "pool": "178.16.1.0 - 178.16.1.255" } ],
"reservations": [
{
"hw-address": "08:00:27:25:d3:f4",
"client-classes": [ "two", "one" ]
}]
}],
```
The value for boot-file-name will be "one.boot" and doman-name-servers will be "2.2.2.2". If we associate the classes in the reverse order, (i.e "one", "two") then I get "two.boot" and "1.1.1.1". This is inconsistent and in my opinion, broken. They should do it the same way. In this case, fixed fields should follow options behavior. The options ordering for classes is clearly documented in the ARM:
https://kea.readthedocs.io/en/latest/arm/classify.html#client-classification-overviewkea1.9.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1377when client has global reservation without an address kea4 is not checking fo...2020-09-01T09:59:13ZWlodzimierz Wencelwhen client has global reservation without an address kea4 is not checking for reservation on subnet level.configuration:
```
{
"Dhcp4": {
"client-classes": [
{
"name": "special"
},
{
"name": "NOTspecial",
"test": "not member('special')"
...configuration:
```
{
"Dhcp4": {
"client-classes": [
{
"name": "special"
},
{
"name": "NOTspecial",
"test": "not member('special')"
}
],
"hooks-libraries": [],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"lease-database": {
"type": "memfile"
},
"loggers": [
{
"debuglevel": 99,
"name": "kea-dhcp4",
"output_options": [
{
"output": "/home/wlodek/installed/git-thread/var/log/kea.log"
}
],
"severity": "DEBUG"
}
],
"multi-threading": {
"enable-multi-threading": true,
"packet-queue-size": 16,
"thread-pool-size": 2
},
"option-data": [],
"rebind-timer": 2000,
"renew-timer": 1000,
"reservation-mode": "global",
"reservations": [
{
"client-classes": [
"special"
],
"hw-address": "ff:01:02:03:ff:04"
}
],
"shared-networks": [
{
"interface": "enp0s9",
"name": "name-abc",
"subnet4": [
{
"client-class": "NOTspecial",
"interface": "enp0s9",
"pools": [
{
"pool": "192.168.50.1-192.168.50.50"
}
],
"subnet": "192.168.50.0/24"
},
{
"client-class": "special",
"interface": "enp0s9",
"pools": [
{
"pool": "192.168.51.1-192.168.51.50"
}
],
"reservation-mode": "all",
"reservations": [
{
"hw-address": "ff:01:02:03:ff:04",
"ip-address": "192.168.51.200"
}
],
"subnet": "192.168.51.0/24"
}
]
}
],
"subnet4": [],
"valid-lifetime": 4000
}
}
```
Scenario: client has a two reservations, one global with class that is manipulating subnet selection from shared network, second on subnet level that has specific address.
Problem: Client is getting address from correct subnet (global reservation works) but kea is not checking for second reservation and assign address from regular pool.
full logs attached [kea.log](/uploads/9f9617fa86188f19ff4a3e5dd8735a69/kea.log)
introduced https://gitlab.isc.org/isc-projects/kea/-/issues/1139 on similar scenario but on pool level works perfectlykea1.9.0https://gitlab.isc.org/isc-projects/kea/-/issues/1376manipulating subnet choice from shared network with class from global reserva...2020-09-01T09:59:19ZWlodzimierz Wencelmanipulating subnet choice from shared network with class from global reservation does not work in kea v6configuration:
```
{
"Dhcp6": {
"client-classes": [
{
"name": "special"
},
{
"name": "NOTspecial",
"test": "not member('special')"
...configuration:
```
{
"Dhcp6": {
"client-classes": [
{
"name": "special"
},
{
"name": "NOTspecial",
"test": "not member('special')"
}
],
"hooks-libraries": [],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"lease-database": {
"type": "memfile"
},
"loggers": [
{
"debuglevel": 99,
"name": "kea-dhcp6",
"output_options": [
{
"output": "/home/wlodek/installed/git-thread/var/log/kea.log"
}
],
"severity": "DEBUG"
}
],
"multi-threading": {
"enable-multi-threading": true,
"packet-queue-size": 16,
"thread-pool-size": 2
},
"option-data": [],
"preferred-lifetime": 3000,
"rebind-timer": 2000,
"renew-timer": 1000,
"reservation-mode": "global",
"reservations": [
{
"client-classes": [
"special"
],
"hw-address": "01:02:03:04:05:07"
}
],
"shared-networks": [
{
"interface": "enp0s9",
"name": "name-abc",
"subnet6": [
{
"client-class": "NOTspecial",
"interface": "enp0s9",
"pools": [
{
"pool": "2001:db8:a::1-2001:db8:a::1"
}
],
"subnet": "2001:db8:a::/64"
},
{
"client-class": "special",
"interface": "enp0s9",
"pools": [
{
"pool": "2001:db8:b::1-2001:db8:b::1"
}
],
"reservation-mode": "all",
"reservations": [
{
"hw-address": "01:02:03:04:05:07",
"ip-addresses": [
"2001:db8:a::1111"
]
}
],
"subnet": "2001:db8:b::/64"
}
]
}
],
"subnet6": [],
"valid-lifetime": 4000
}
}
```
Scenario:
client haas a global reservation with a class, with that class he should get specific subnet from shared-network, and than with reservation from subnet level should get specific address from this subnet.
logs of address selection:
```
2020-08-10 02:20:11.281 DEBUG [kea-dhcp6.dhcpsrv/18466.140536017057536] DHCPSRV_CFGMGR_SUBNET6_IFACE selected subnet 2001:db8:a::/64 for packet received over interface enp0s9
2020-08-10 02:20:11.281 DEBUG [kea-dhcp6.packets/18466.140536017057536] DHCP6_SUBNET_SELECTED duid=[00:03:00:01:01:02:03:04:05:07], tid=0xdfecd6: the subnet with ID 1 was selected for client assignments
2020-08-10 02:20:11.281 DEBUG [kea-dhcp6.packets/18466.140536017057536] DHCP6_SUBNET_DATA duid=[00:03:00:01:01:02:03:04:05:07], tid=0xdfecd6: the selected subnet details: 2001:db8:a::/64
2020-08-10 02:20:11.281 DEBUG [kea-dhcp6.hosts/18466.140536017057536] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv6 reservation for subnet id 0, identified by hwaddr=010203040507
2020-08-10 02:20:11.281 DEBUG [kea-dhcp6.hosts/18466.140536017057536] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=010203040507
2020-08-10 02:20:11.281 DEBUG [kea-dhcp6.hosts/18466.140536017057536] HOSTS_CFG_GET_ALL_IDENTIFIER_HOST using identifier: hwaddr=010203040507, found host: hwaddr=010203040507 ipv6_subnet_id=2 hostname=(empty) ipv4_reservation=(no) siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservation0=2001:db8:a::1111
2020-08-10 02:20:11.281 DEBUG [kea-dhcp6.hosts/18466.140536017057536] HOSTS_CFG_GET_ALL_IDENTIFIER_HOST using identifier: hwaddr=010203040507, found host: hwaddr=010203040507 ipv6_subnet_id=0 hostname=(empty) ipv4_reservation=(no) siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservations=(none) dhcp6_class0=special
2020-08-10 02:20:11.281 DEBUG [kea-dhcp6.hosts/18466.140536017057536] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=010203040507, found 2 host(s)
2020-08-10 02:20:11.281 DEBUG [kea-dhcp6.hosts/18466.140536017057536] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_HOST using subnet id 0 and identifier hwaddr=010203040507, found host: hwaddr=010203040507 ipv6_subnet_id=0 hostname=(empty) ipv4_reservation=(no) siaddr=(no) sname=(empty) file=(empty) key=(empty) ipv6_reservations=(none) dhcp6_class0=special
2020-08-10 02:20:11.282 DEBUG [kea-dhcp6.dhcp6/18466.140536017057536] DHCP6_CLASS_ASSIGNED duid=[00:03:00:01:01:02:03:04:05:07], tid=0xdfecd6: client packet has been assigned to the following class(es): ALL, special
2020-08-10 02:20:11.282 DEBUG [kea-dhcp6.eval/18466.140536017057536] EVAL_DEBUG_MEMBER Checking membership of 'special', pushing result 'true'
2020-08-10 02:20:11.282 DEBUG [kea-dhcp6.eval/18466.140536017057536] EVAL_DEBUG_NOT Popping 'true' pushing 'false'
2020-08-10 02:20:11.282 DEBUG [kea-dhcp6.dhcp6/18466.140536017057536] EVAL_RESULT Expression NOTspecial evaluated to 0
2020-08-10 02:20:11.282 DEBUG [kea-dhcp6.dhcp6/18466.140536017057536] DHCP6_CLASS_ASSIGNED duid=[00:03:00:01:01:02:03:04:05:07], tid=0xdfecd6: client packet has been assigned to the following class(es): KNOWN
2020-08-10 02:20:11.282 DEBUG [kea-dhcp6.leases/18466.140536017057536] DHCP6_PROCESS_IA_NA_REQUEST duid=[00:03:00:01:01:02:03:04:05:07], tid=0xdfecd6: server is processing IA_NA option with iaid=41204 and hint=2001:db8:b::1
2020-08-10 02:20:11.282 DEBUG [kea-dhcp6.dhcpsrv/18466.140536017057536] DHCPSRV_MEMFILE_GET_IAID_DUID obtaining IPv6 leases for IAID 41204 and DUID 00:03:00:01:01:02:03:04:05:07 and lease type IA_NA
2020-08-10 02:20:11.282 DEBUG [kea-dhcp6.alloc-engine/18466.140536017057536] ALLOC_ENGINE_V6_ALLOC_NO_LEASES_HR no leases found but reservations exist for client duid=[00:03:00:01:01:02:03:04:05:07], tid=0xdfecd6
2020-08-10 02:20:11.283 DEBUG [kea-dhcp6.alloc-engine/18466.140536017057536] ALLOC_ENGINE_V6_ALLOC_UNRESERVED no static reservations available - trying to dynamically allocate leases for client duid=[00:03:00:01:01:02:03:04:05:07], tid=0xdfecd6
2020-08-10 02:20:11.283 DEBUG [kea-dhcp6.dhcpsrv/18466.140536017057536] DHCPSRV_MEMFILE_GET_ADDR6 obtaining IPv6 lease for address 2001:db8:b::1 and lease type IA_NA
```
full logs attached [kea.log](/uploads/5b9b4f9cf4fcae04ea438824c405ae4f/kea.log)
Feature introduced in https://gitlab.isc.org/isc-projects/kea/-/issues/1139 and works perfectly on pool level :)kea1.9.0https://gitlab.isc.org/isc-projects/kea/-/issues/1353Guarded subnets must stay allowed2022-02-03T13:31:01ZFrancis DupontGuarded subnets must stay allowedJust after the host reservation lookup the query classes can be cleared and evaluated again with the host reservation classes. During this it is possible to have a selected subnet with a guard (client-class) which finished to not be allo...Just after the host reservation lookup the query classes can be cleared and evaluated again with the host reservation classes. During this it is possible to have a selected subnet with a guard (client-class) which finished to not be allowed (i.e. the guard client class is no longer in the query classes). The whole code assumes the selected subnet is allowed so it can lead to very incorrect behavior.
The fix is easy: just unconditionally add again the guard class (the class add method puts its argument once in the classes: if it is already in them the method does nothing).
Or alternatively make all possible branches to handle this case: the selected subnet is no longer allowed so can be used only in a shared network and a new "start" subnet must be found.kea2.1.3Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1314different pools based on class2020-07-15T08:23:34ZWlodzimierz Wenceldifferent pools based on classRelated: https://support.isc.org/Ticket/Display.html?id=16773
Scenario:
Kea configured with one subnet with two pools inside, one pool is "open" second is only for client that will be assigned to class "super-fun-clients". Class will be...Related: https://support.isc.org/Ticket/Display.html?id=16773
Scenario:
Kea configured with one subnet with two pools inside, one pool is "open" second is only for client that will be assigned to class "super-fun-clients". Class will be assigned via global reservation.
Problem:
I can't make it work, either all clients get all addresses or non of the clients are able to get "super-fun-clients" pool.
Example configuration (I tried more, but this one is, what I think, correct)
```
{
"Dhcp4": {
"client-classes": [
{
"name": "super-fun-clients",
"only-if-required": true
}
],
"hooks-libraries": [],
"interfaces-config": {
"interfaces": [
"enp0s9"
]
},
"lease-database": {
"type": "memfile"
},
"loggers": [
{
"debuglevel": 99,
"name": "kea-dhcp4",
"output_options": [
{
"output": "/home/wlodek/installed/git-thread/var/log/kea.log"
}
],
"severity": "DEBUG"
}
],
"multi-threading": {
"enable-multi-threading": true,
"packet-queue-size": 16,
"thread-pool-size": 2
},
"option-data": [],
"rebind-timer": 2000,
"renew-timer": 1000,
"reservations": [
{
"client-classes": [
"super-fun-clients"
],
"hw-address": "aa:bb:cc:dd:ee:ff"
}
],
"shared-networks": [],
"subnet4": [
{
"interface": "enp0s9",
"pools": [
{
"pool": "10.0.0.1-10.0.0.11",
"require-client-classes": [
"super-fun-clients"
]
},
{
"pool": "10.0.0.15-10.0.0.25"
}
],
"reservation-mode": "global",
"subnet": "10.0.0.0/24"
}
],
"valid-lifetime": 4000
}
}
```
am I making a mistake or is it a bug or pool selection is not possible this way?
EDIT: and packets are classified correctly, pkt with mac address "aa:bb:cc:dd:ee:ff" is assigned to `super-fun-clients` class
`DHCP4_CLASS_ASSIGNED [hwtype=1 aa:bb:cc:dd:ee:ff], cid=[no info], tid=0x3eaf28: client packet has been assigned to the following class(es): ALL, super-fun-clients, KNOWN`kea1.7.10https://gitlab.isc.org/isc-projects/kea/-/issues/1172applying lease timer values to a class2021-08-20T15:36:11ZPeter Daviesapplying lease timer values to a classCustomer request: [#RT16196](https://support.isc.org/Ticket/Display.html?id=16196)
The ability to assign lease timer values to Client Class definitions.Customer request: [#RT16196](https://support.isc.org/Ticket/Display.html?id=16196)
The ability to assign lease timer values to Client Class definitions.kea1.9.11Tomek MrugalskiTomek Mrugalski