[Kea-users] Class selection with Option 82

[Doug Freed]

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
> robergeandre at 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