On 6/19/25 15:39, Andre Roberge via Kea-users wrote:
Hi,
I'm having some issues with classifying my client classes with the vlan
out of option 82. I'm getting the interface with my vlan using Juniper
Network. Is there a way not to get the interface appended to the vlan
from a Juniper ?
*Here is my client class selection which is working:*
"client-classes": [
// vlan45
{
"name": "vlan45",
"test": "substring(option[82].option[1].hex, 12,2) == 0x3435",
},
],
*Log Eval *
*
*
2025-06-19T16:38:12.567815-04:00 c3dhcp1 kea-dhcp4: DEBUG [kea-
dhcp4.eval.140363547969216] EVAL_DEBUG_SUBSTRING [hwtype=1
b4:e9:b8:2c:cf:8c], cid=[01:b4:e9:b8:2c:cf:8c], tid=0x3b67ca88: Popping
length 2, start 12, string 0x67652D302F302F32312E303A3435 pushing result
0x3435
2025-06-19T16:38:12.567982-04:00 c3dhcp1 kea-dhcp4: DEBUG [kea-
dhcp4.eval.140363547969216] EVAL_DEBUG_HEXSTRING [hwtype=1
b4:e9:b8:2c:cf:8c], cid=[01:b4:e9:b8:2c:cf:8c], tid=0x3b67ca88: Pushing
hex string 0x3435
2025-06-19T16:38:12.568735-04:00 c3dhcp1 kea-dhcp4: DEBUG [kea-
dhcp4.eval.140363547969216] EVAL_DEBUG_EQUAL [hwtype=1
b4:e9:b8:2c:cf:8c], cid=[01:b4:e9:b8:2c:cf:8c], tid=0x3b67ca88: Popping
0x3435 and 0x3435 pushing result 'true'
2025-06-19T16:38:12.568858-04:00 c3dhcp1 kea-dhcp4: INFO [kea-
dhcp4.dhcpsrv.140363547969216] EVAL_RESULT [hwtype=1 b4:e9:b8:2c:cf:8c],
cid=[01:b4:e9:b8:2c:cf:8c], tid=0x3b67ca88: Expression vlan45 evaluated
to true
*Juniper Config *
dhcp-relay {
relay-option-82 {
circuit-id {
use-vlan-id;
}
}
forward-only;
server-group {
c3dhcp {
10.14.3.10;
}
}
active-server-group c3dhcp;
group all {
interface irb.45;
}
}
Thank You
Andre Roberge
robergean...@yahoo.com
You may be better off asking a Juniper community that specific question,
but a quick search suggests that the answer is unfortunately no.
However, the likely X to what seems to be an X-Y problem, getting the
VLAN ID out of the string when the interface name length varies, can be
solved using the split function:
split(option[82].option[1].hex, ':', 2) == '45'
The Juniper docs indicate that the VLAN ID is separated from the
interface name by a colon, and the option content from your debug log
lines matches this.
Another approach, instead of manually defining classes for each VLAN ID,
define a template class that returns the VLAN ID in the template-test,
like this:
"client-classes": [
{
"name": "vlan",
"template-test": "split(option[82].option[1].hex, ':', 2)"
}
]
Then each client will be in the class "SPAWN_vlan_<id>" where "<id>" is
replaced with their VLAN ID. You can define these special classes in
your config (without a test) to set options that are specific to that VLAN.
All of that said, it most likely makes more sense to just set whatever
options on the subnet or shared network in use rather than using the
VLAN ID at all. Subnet selection is based on the address of the relay
in the received DHCP packet, and the relay uses its address in the VLAN
that the original broadcast came from.
-Doug
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
