[Kea-users] kea answers to relay using giaddr instead of source address. any way to fix?

[Sergey Klusov]

Hi, i'm using kea-dhcp4 version 1.1.0 from epel repo.
Here is tcpdump:

13:35:31.734452 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
UDP (17), length 335)
     x.x.x.156.67 > x.x.x.90.67: [udp sum ok] BOOTP/DHCP, Request from
f4:8b:32:a3:79:3f, length 307, hops 1, xid 0x88cd169e, secs 2, Flags
[none] (0x0000)
           Gateway-IP 100.101.101.1
           Client-Ethernet-Address f4:8b:32:a3:79:3f
           Vendor-rfc1048 Extensions
             Magic Cookie 0x63825363
             DHCP-Message Option 53, length 1: Discover
             Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f
             MSZ Option 57, length 2: 1500
             Vendor-Class Option 60, length 18: "android-dhcp-6.0.1"
             Hostname Option 12, length 17: "MINOTELTE-MiPhone"
             Parameter-Request Option 55, length 9:
               Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
               MTU, BR, Lease-Time, RN
               RB
13:35:31.736533 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto
UDP (17), length 330)
     x.x.x.90.67 > 100.101.101.1.67: [udp sum ok] BOOTP/DHCP, Reply,
length 302, hops 1, xid 0x88cd169e, Flags [none] (0x0000)
           Your-IP 100.101.101.132
           Gateway-IP 100.101.101.1
           Client-Ethernet-Address f4:8b:32:a3:79:3f
           Vendor-rfc1048 Extensions
             Magic Cookie 0x63825363
             Subnet-Mask Option 1, length 4: 255.255.255.0
             Default-Gateway Option 3, length 4: 100.101.101.1
             Domain-Name-Server Option 6, length 4: x.x.x.10
             Hostname Option 12, length 17: "MINOTELTE-MiPhone"
             Lease-Time Option 51, length 4: 86400
             DHCP-Message Option 53, length 1: Offer
             Server-ID Option 54, length 4: x.x.x.90
             Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f

Agent's giaddr is not reachable by server, why it keeps sending replies
to it?
Is there an option to reply to packet's source address?
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Marcin Siodelski]

On 28.09.2017 11:14, Sergey Klusov wrote:

> Hi, i'm using kea-dhcp4 version 1.1.0 from epel repo.
> Here is tcpdump:
>
> 13:35:31.734452 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
> UDP (17), length 335)
>     x.x.x.156.67 > x.x.x.90.67: [udp sum ok] BOOTP/DHCP, Request from
> f4:8b:32:a3:79:3f, length 307, hops 1, xid 0x88cd169e, secs 2, Flags
> [none] (0x0000)
>           Gateway-IP 100.101.101.1
>           Client-Ethernet-Address f4:8b:32:a3:79:3f
>           Vendor-rfc1048 Extensions
>             Magic Cookie 0x63825363
>             DHCP-Message Option 53, length 1: Discover
>             Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f
>             MSZ Option 57, length 2: 1500
>             Vendor-Class Option 60, length 18: "android-dhcp-6.0.1"
>             Hostname Option 12, length 17: "MINOTELTE-MiPhone"
>             Parameter-Request Option 55, length 9:
>               Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
>               MTU, BR, Lease-Time, RN
>               RB
> 13:35:31.736533 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto
> UDP (17), length 330)
>     x.x.x.90.67 > 100.101.101.1.67: [udp sum ok] BOOTP/DHCP, Reply,
> length 302, hops 1, xid 0x88cd169e, Flags [none] (0x0000)
>           Your-IP 100.101.101.132
>           Gateway-IP 100.101.101.1
>           Client-Ethernet-Address f4:8b:32:a3:79:3f
>           Vendor-rfc1048 Extensions
>             Magic Cookie 0x63825363
>             Subnet-Mask Option 1, length 4: 255.255.255.0
>             Default-Gateway Option 3, length 4: 100.101.101.1
>             Domain-Name-Server Option 6, length 4: x.x.x.10
>             Hostname Option 12, length 17: "MINOTELTE-MiPhone"
>             Lease-Time Option 51, length 4: 86400
>             DHCP-Message Option 53, length 1: Offer
>             Server-ID Option 54, length 4: x.x.x.90
>             Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f
>
> Agent's giaddr is not reachable by server, why it keeps sending replies
> to it?
> Is there an option to reply to packet's source address?
> _______________________________________________
> Kea-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users

From RFC2131:

"If the 'giaddr' field in a DHCP message from a client is non-zero,
   the server sends any return messages to the 'DHCP server' port on the
   BOOTP relay agent whose address appears in 'giaddr'."

I read this as the server is doing what it is supposed to do.

Marcin
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Sergey Klusov]

Okay, thanks. But is there an option to change that behavior?

On Чт 28.09.2017 14:24, Marcin Siodelski wrote:
> >From RFC2131:
> "If the 'giaddr' field in a DHCP message from a client is non-zero,
>     the server sends any return messages to the 'DHCP server' port on the
>     BOOTP relay agent whose address appears in 'giaddr'."
>
> I read this as the server is doing what it is supposed to do.
>
> Marcin
>

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Francis Dupont]

IMHO the simplest is to write a little hook which resets the giaddr,
or to understand why the client or relay sets it and fix this.

Regards

Francis Dupont <[hidden email]>
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Sergey Klusov]

On Чт 28.09.2017 14:37, Francis Dupont wrote:
> IMHO the simplest is to write a little hook which resets the giaddr,
> or to understand why the client or relay sets it and fix this.
>
> Regards
>
> Francis Dupont <[hidden email]>
>
Client is a mikrotik router with some specific setup: lan segment which
it runs relay for is in VRF instance, but there is a limitation in
RouterOS that dhcp-relay destination will be contacted using main
routing table.

Because of that, relay messages are sent out-of-band, using different
interface.

Right now i'm working on supplying additional option 82 information to
kea, by wich it should select appropriate subnet.

14:30:40.033857 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
UDP (17), length 360)
     x.x.x.156.67 > x.x.x.90.67: [udp sum ok] BOOTP/DHCP, Request from
f4:8b:32:a3:79:3f, length 332, hops 1, xid 0xa111bece, secs 17, Flags
[none] (0x0000)
           Gateway-IP x.x.x.156
           Client-Ethernet-Address f4:8b:32:a3:79:3f
           Vendor-rfc1048 Extensions
             Magic Cookie 0x63825363
             DHCP-Message Option 53, length 1: Discover
             Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f
             MSZ Option 57, length 2: 1500
             Vendor-Class Option 60, length 18: "android-dhcp-6.0.1"
             Hostname Option 12, length 17: "MINOTELTE-MiPhone"
             Parameter-Request Option 55, length 9:
               Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
               MTU, BR, Lease-Time, RN
               RB
             Agent-Information Option 82, length 23:
               Circuit-ID SubOption 1, length 6: M-~^K.M-AM-tz
               Remote-ID SubOption 2, length 13: 100.101.101.0

Can someone tell me how to make kea select subnet 100.101.101.0/24 by
Remote-ID "100.101.101.0" suboption and giaddr?

Should i define some class and apply it to subnet?

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Francis Dupont]

A client class is the easiest way to perform specific subnet selection.

Regards

Francis Dupont <[hidden email]>
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Sergey Klusov]

On Чт 28.09.2017 15:16, Francis Dupont wrote:
> A client class is the easiest way to perform specific subnet selection.
>
> Regards
>
> Francis Dupont <[hidden email]>
> .
>
   Trying this way, but does not work:

   "client-classes": [
     {
       "name": "routed_100_101_101_0_24",
       "test": "relay4[2].text == '100.101.101.0'"
     }
   ],

2017-09-28 15:27:31.459 DEBUG [kea-dhcp4.packets/4408]
DHCP4_BUFFER_RECEIVED received buffer from x.x.x.156:67 to x.x.x..90:67
over interface lan0.96
2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.options/4408]
DHCP4_BUFFER_UNPACK parsing buffer received from x.x.x.156 to x.x.x.90
over interface lan0.96
2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.eval/4408] EVAL_DEBUG_OPTION
Pushing option 2 with value 'type=002, len=013:
31:30:30:2e:31:30:31:2e:31:30:31:2e:30'
2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.eval/4408] EVAL_DEBUG_STRING
Pushing text string '100.101.101.0'
2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.eval/4408] EVAL_DEBUG_EQUAL
Popping 0x3130302E3130312E3130312E30 and
0x747970653D3030322C206C656E3D3031333A2033313A33303A33303A32653A33313A33303A33313A32653A33313A33303A33313A32653A3330
pushing result 'false'
2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.options/4408] EVAL_RESULT
Expression routed_100_101_101_0_24 evaluated to 0
2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.packets/4408]
DHCP4_PACKET_RECEIVED [hwtype=1 74:23:44:5d:44:4a],
cid=[01:74:23:44:5d:44:4a], tid=0xb9926426: DHCPDISCOVER (type 1)
received from x.x.x.156 to x.x.x.90 on interface lan0.96
2017-09-28 15:27:31.460 DEBUG [kea-dhcp4.packets/4408] DHCP4_QUERY_DATA
[hwtype=1 74:23:44:5d:44:4a], cid=[01:74:23:44:5d:44:4a],
tid=0xb9926426, packet details: local_address=x.x.x.90:67,
remote_adress=x.x.x.156:67, msg_type=DHCPDISCOVER (1), transid=0xb9926426,
options:
   type=012, len=018: "RedmiNote3-xrn3pro" (string)
   type=053, len=001: 1 (uint8)
   type=055, len=009: 1(uint8) 3(uint8) 6(uint8) 15(uint8) 26(uint8)
28(uint8) 51(uint8) 58(uint8) 59(uint8)
   type=057, len=002: 1500 (uint16)
   type=060, len=018: "android-dhcp-6.0.1" (string)
   type=061, len=007: 01:74:23:44:5d:44:4a
   type=082, len=023:,
options:
     type=001, len=006: fe:0b:2e:c1:f4:7a
     type=002, len=013: 31:30:30:2e:31:30:31:2e:31:30:31:2e:30
2017-09-28 15:27:31.461 DEBUG [kea-dhcp4.packets/4408]
DHCP4_SUBNET_SELECTION_FAILED [hwtype=1 74:23:44:5d:44:4a],
cid=[01:74:23:44:5d:44:4a], tid=0xb9926426: failed to select subnet for
the client
2017-09-28 15:27:31.461 DEBUG [kea-dhcp4.dhcp4/4408]
DHCP4_CLASS_ASSIGNED [hwtype=1 74:23:44:5d:44:4a],
cid=[01:74:23:44:5d:44:4a], tid=0xb9926426: client packet has been
assigned to the following class(es): VENDOR_CLASS_android-dhcp-6.0.1

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Francis Dupont]

 "test": "relay4[2].text == '100.101.101.0'"

=> please try "test": "relay4[2].hex == 100.101.101.0"
(.text does not return what you want if the (sub-)option is not a string
and IP address litterals are supported).
                             
Regards

Francis Dupont <[hidden email]>
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Sergey Klusov]

On Чт 28.09.2017 16:09, Francis Dupont wrote:

>   "test": "relay4[2].text == '100.101.101.0'"
>
> => please try "test": "relay4[2].hex == 100.101.101.0"
> (.text does not return what you want if the (sub-)option is not a string
> and IP address litterals are supported).
>
> Regards
>
> Francis Dupont <[hidden email]>
>

Didn't work, because it converts 100.101.101.0 into 4-byte IP address.

For now it works this way "relay4[2].hex==0x3130302e3130312e3130312e30",
but it rather clumsy.

Mikrotik does not allow to specify binary value either.

Some function like relay4[2].string would be nice.


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Marcin Siodelski]

On 28.09.2017 13:22, Sergey Klusov wrote:

> On Чт 28.09.2017 16:09, Francis Dupont wrote:
>>   "test": "relay4[2].text == '100.101.101.0'"
>>
>> => please try "test": "relay4[2].hex == 100.101.101.0"
>> (.text does not return what you want if the (sub-)option is not a string
>> and IP address litterals are supported).
>>            
>> Regards
>>
>> Francis Dupont <[hidden email]>
>>
> Didn't work, because it converts 100.101.101.0 into 4-byte IP address.
>
> For now it works this way "relay4[2].hex==0x3130302e3130312e3130312e30",
> but it rather clumsy.
>
> Mikrotik does not allow to specify binary value either.
>
> Some function like relay4[2].string would be nice.
>
>
> _______________________________________________
> Kea-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users

Perhaps it will be better to specify the "relay" parameter on the subnet
level:

"relay": {
    "ip-address": "100.101.101.0"
}

See: http://kea.isc.org/docs/kea-guide.html#dhcp6-relay-override

The classification will be needed for filtering the RAI option values to
more specifically select the subnet but relay parameter should narrow
down the selection for the relay address.

Marcin
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Jason Lixfeld]

Hi,

> On Sep 28, 2017, at 5:49 AM, Sergey Klusov <[hidden email]> wrote:
>
> On Чт 28.09.2017 14:37, Francis Dupont wrote:
>> IMHO the simplest is to write a little hook which resets the giaddr,
>> or to understand why the client or relay sets it and fix this.
>>
>> Regards
>>
>> Francis Dupont <[hidden email]>
>>
> Client is a mikrotik router with some specific setup: lan segment which it runs relay for is in VRF instance, but there is a limitation in RouterOS that dhcp-relay destination will be contacted using main routing table.

If your relay supports RFC3527, it will reset giaddr to the IP of the relay’s outbound server facing interface instead of the IP of the relay’s inbound, client facing interface.  It will also then encode the subnet of the interface that the packet arrived on at the relay into option 82 sub option 5.

In Cisco, this is usually enabled using the ‘vpn’ keyword with the 'ip dhcp relay information option’ command.

I believe that Kea will then be able to use sub option 5 to select the correct subnet, but in my particular use case, I use RFC3527 only in my lab (I cannot use that feature in production) and I match remote-id in a client-class and include that class in the appropriate subnet declaration, so I don’t honestly know if Kea will use sub option 5 as intended.  I could try if you’d like?

Standard:

14:58:26.420087 IP (tos 0x0, ttl 253, id 36242, offset 0, flags [none], proto UDP (17), length 343)
    10.219.45.114.67 > 10.219.66.10.67: [udp sum ok] BOOTP/DHCP, Request from 00:01:47:dc:fa:5a, length 315, hops 1, xid 0xe53cd04, Flags [none] (0x0000)
          Gateway-IP 10.63.255.1
          Client-Ethernet-Address 00:01:47:dc:fa:5a
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Client-ID Option 61, length 8: "1448201"
            Parameter-Request Option 55, length 14:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, Lease-Time, DHCP-Message
              Server-ID, TFTP, NTP, Time-Zone
              Option 120, Classless-Static-Route
            Vendor-Class Option 60, length 20: "ZNID-GE-2628A-NA-0GN"
            Agent-Information Option 82, length 21:
              Circuit-ID SubOption 1, length 6: ^@^D^L7^BP
              Remote-ID SubOption 2, length 11: ^A^Irgw01.lab
            END Option 255, length 0
14:58:26.429253 IP (tos 0x0, ttl 64, id 12783, offset 0, flags [DF], proto UDP (17), length 368)
    10.219.66.10.67 > 10.63.255.1.67: [bad udp cksum 0x5793 -> 0x77ad!] BOOTP/DHCP, Reply, length 340, hops 1, xid 0xe53cd04, Flags [none] (0x0000)
          Your-IP 10.63.255.115
          Gateway-IP 10.63.255.1
          Client-Ethernet-Address 00:01:47:dc:fa:5a
          file "26xx_current/S0300608"[|bootp]

RFC3527:

15:10:33.158538 IP (tos 0x0, ttl 253, id 36799, offset 0, flags [none], proto UDP (17), length 380)
    10.219.45.114.67 > 10.219.66.10.67: [udp sum ok] BOOTP/DHCP, Request from 00:01:47:e3:2f:60, length 352, hops 1, xid 0x507b2ecb, Flags [none] (0x0000)
          Gateway-IP 10.219.45.114
          Client-Ethernet-Address 00:01:47:e3:2f:60
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Client-ID Option 61, length 8: "1488880"
            Parameter-Request Option 55, length 14:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, Lease-Time, DHCP-Message
              Server-ID, TFTP, NTP, Time-Zone
              Option 120, Classless-Static-Route
            Vendor-Class Option 60, length 20: "ZNID-GE-2628A-00-0GN"
            Agent-Information Option 82, length 58:
              Circuit-ID SubOption 1, length 6: ^@^D^L7^B^A
              Remote-ID SubOption 2, length 11: ^A^Irgw01.lab
              Unknown SubOption 151, length 23:
                0x0000:  0072 6573 6964 656e 7469 616c 2d6d 616e
                0x0010:  6167 656d 656e 74
              Unknown SubOption 5, length 4:
                0x0000:  0a3f ff00
              Unknown SubOption 152, length 4:
                0x0000:  0a3f ff01
            END Option 255, length 0
15:10:33.169563 IP (tos 0x0, ttl 64, id 61753, offset 0, flags [DF], proto UDP (17), length 405)
    10.219.66.10.67 > 10.219.45.114.67: [bad udp cksum 0x86c4 -> 0x8fae!] BOOTP/DHCP, Reply, length 377, hops 1, xid 0x507b2ecb, Flags [none] (0x0000)
          Your-IP 10.63.255.16
          Gateway-IP 10.219.45.114
          Client-Ethernet-Address 00:01:47:e3:2f:60
          file "26xx_current/S0300608"[|bootp]

> Because of that, relay messages are sent out-of-band, using different interface.
>
> Right now i'm working on supplying additional option 82 information to kea, by wich it should select appropriate subnet.
>
> 14:30:40.033857 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 360)
>    x.x.x.156.67 > x.x.x.90.67: [udp sum ok] BOOTP/DHCP, Request from f4:8b:32:a3:79:3f, length 332, hops 1, xid 0xa111bece, secs 17, Flags [none] (0x0000)
>          Gateway-IP x.x.x.156
>          Client-Ethernet-Address f4:8b:32:a3:79:3f
>          Vendor-rfc1048 Extensions
>            Magic Cookie 0x63825363
>            DHCP-Message Option 53, length 1: Discover
>            Client-ID Option 61, length 7: ether f4:8b:32:a3:79:3f
>            MSZ Option 57, length 2: 1500
>            Vendor-Class Option 60, length 18: "android-dhcp-6.0.1"
>            Hostname Option 12, length 17: "MINOTELTE-MiPhone"
>            Parameter-Request Option 55, length 9:
>              Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
>              MTU, BR, Lease-Time, RN
>              RB
>            Agent-Information Option 82, length 23:
>              Circuit-ID SubOption 1, length 6: M-~^K.M-AM-tz
>              Remote-ID SubOption 2, length 13: 100.101.101.0
>
> Can someone tell me how to make kea select subnet 100.101.101.0/24 by Remote-ID "100.101.101.0" suboption and giaddr?
>
> Should i define some class and apply it to subnet?
>
> _______________________________________________
> Kea-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/kea-users

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Sergey Klusov]

On Чт 28.09.2017 16:54, Jason Lixfeld wrote:
> If your relay supports RFC3527, it will reset giaddr to the IP of the
> relay’s outbound server facing interface instead of the IP of the
> relay’s inbound, client facing interface. It will also then encode the
> subnet of the interface that the packet arrived on at the relay into
> option 82 sub option 5.

I've already configured agent to set it's giarrd to external address and
also specified that address in subnet's "relay" setting.
Still i need to use classes, because there will be tens of networks on
this router, all of them dhcp-relayed to same kea server.

Here is how i configure agent:

/ip dhcp-relay
add add-relay-info=yes\
  dhcp-server=x.x.x.90\
  disabled=no\
  interface=eoip-101\
  local-address=x.x.x.156\
  name=relay1\
  relay-info-remote-id=100.101.101.0

that "relay-info-remote-id" could only be specified as ASCII string
value, and it's seen by kea as relay4[2] option. But kea now cannot
compare this option with string '100.101.101.0', only with it's hex
value. Wich is working, but just not comfortable configuring.
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Jason Lixfeld]

> On Sep 28, 2017, at 8:16 AM, Sergey Klusov <[hidden email]> wrote:
>
> On Чт 28.09.2017 16:54, Jason Lixfeld wrote:
>> If your relay supports RFC3527, it will reset giaddr to the IP of the relay’s outbound server facing interface instead of the IP of the relay’s inbound, client facing interface. It will also then encode the subnet of the interface that the packet arrived on at the relay into option 82 sub option 5.
>
> I've already configured agent to set it's giarrd to external address and also specified that address in subnet's "relay" setting.
> Still i need to use classes, because there will be tens of networks on this router, all of them dhcp-relayed to same kea server.
>
> Here is how i configure agent:
>
> /ip dhcp-relay
> add add-relay-info=yes\
> dhcp-server=x.x.x.90\
> disabled=no\
> interface=eoip-101\
> local-address=x.x.x.156\
> name=relay1\
> relay-info-remote-id=100.101.101.0
>
> that "relay-info-remote-id" could only be specified as ASCII string value, and it's seen by kea as relay4[2] option. But kea now cannot compare this option with string '100.101.101.0', only with it's hex value. Wich is working, but just not comfortable configuring.

If RFC3527 is supported on your Mikrotik, it could make this all much easier.  Do you know if it is?  If so, it should just work without a need to do classes or anything.  Just a subnet declaration.

SubOption 5 below decodes to 172 31 255 0, so it seems that Kea supports it properly.

{
        #"client-class" : "rgw01.lab",
        "subnet": "172.31.255.0/28",
        "valid-lifetime": 300,
        "option-data": [
                {
                        "name": "classless-static-routes",
                        "data": "18AC1800AC1FFF01"
                }
        ],
        "pools": [
                {
                        "pool": "172.31.255.2 - 172.31.255.14"
                }
        ]
}



11:43:31.016608 IP (tos 0x0, ttl 253, id 21231, offset 0, flags [none], proto UDP (17), length 361)
    10.219.45.114.67 > 10.219.66.10.67: [udp sum ok] BOOTP/DHCP, Request from 00:01:47:dc:fa:5b, length 333, hops 1, xid 0x4ee7ebbc, Flags [none] (0x0000)
          Gateway-IP 10.219.45.114
          Client-Ethernet-Address 00:01:47:dc:fa:5b
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Client-ID Option 61, length 7: ether 00:01:47:dc:fa:5b
            Parameter-Request Option 55, length 14:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, Lease-Time, DHCP-Message
              Server-ID, TFTP, NTP, Time-Zone
              Option 120, Classless-Static-Route
            Vendor-Class Option 60, length 10: "VOIP_2628A"
            Agent-Information Option 82, length 50:
              Circuit-ID SubOption 1, length 6: ^@^D^KM-=^BP
              Remote-ID SubOption 2, length 11: ^A^Irgw01.lab
              Unknown SubOption 151, length 15:
                0x0000:  0076 6f69 702d 756e 7472 7573 7465 64
              Unknown SubOption 5, length 4:
                0x0000:  ac1f ff00
              Unknown SubOption 152, length 4:
                0x0000:  ac1f ff01
            END Option 255, length 0
11:43:31.031137 IP (tos 0x0, ttl 64, id 30423, offset 0, flags [DF], proto UDP (17), length 373)
    10.219.66.10.67 > 10.219.45.114.67: [bad udp cksum 0x86a4 -> 0x44bd!] BOOTP/DHCP, Reply, length 345, hops 1, xid 0x4ee7ebbc, Flags [none] (0x0000)
          Your-IP 172.31.255.2
          Gateway-IP 10.219.45.114
          Client-Ethernet-Address 00:01:47:dc:fa:5b
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            Subnet-Mask Option 1, length 4: 255.255.255.240
            Lease-Time Option 51, length 4: 300
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, length 4: 10.219.66.10
            RN Option 58, length 4: 900
            RB Option 59, length 4: 1800
            Client-ID Option 61, length 7: ether 00:01:47:dc:fa:5b
            Classless-Static-Route Option 121, length 8: (172.24.0.0/24:172.31.255.1)
            Agent-Information Option 82, length 50:
              Circuit-ID SubOption 1, length 6: ^@^D^KM-=^BP
              Remote-ID SubOption 2, length 11: ^A^Irgw01.lab
              Unknown SubOption 5, length 4:
                0x0000:  ac1f ff00
              Unknown SubOption 151, length 15:
                0x0000:  0076 6f69 702d 756e 7472 7573 7465 64
              Unknown SubOption 152, length 4:
                0x0000:  ac1f ff01
            END Option 255, length 0
11:43:31.041859 IP (tos 0x0, ttl 253, id 21235, offset 0, flags [none], proto UDP (17), length 373)
    10.219.45.114.67 > 10.219.66.10.67: [udp sum ok] BOOTP/DHCP, Request from 00:01:47:dc:fa:5b, length 345, hops 1, xid 0x4ee7ebbc, Flags [none] (0x0000)
          Gateway-IP 10.219.45.114
          Client-Ethernet-Address 00:01:47:dc:fa:5b
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Client-ID Option 61, length 7: ether 00:01:47:dc:fa:5b
            Requested-IP Option 50, length 4: 172.31.255.2
            Server-ID Option 54, length 4: 10.219.66.11
            Parameter-Request Option 55, length 14:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, Lease-Time, DHCP-Message
              Server-ID, TFTP, NTP, Time-Zone
              Option 120, Classless-Static-Route
            Vendor-Class Option 60, length 10: "VOIP_2628A"
            Agent-Information Option 82, length 50:
              Circuit-ID SubOption 1, length 6: ^@^D^KM-=^BP
              Remote-ID SubOption 2, length 11: ^A^Irgw01.lab
              Unknown SubOption 151, length 15:
                0x0000:  0076 6f69 702d 756e 7472 7573 7465 64
              Unknown SubOption 5, length 4:
                0x0000:  ac1f ff00
              Unknown SubOption 152, length 4:
                0x0000:  ac1f ff01
            END Option 255, length 0
11:46:02.272355 IP (tos 0x0, ttl 64, id 41786, offset 0, flags [DF], proto UDP (17), length 363)
    10.219.66.10.67 > 10.219.45.114.67: [bad udp cksum 0x869a -> 0xeb84!] BOOTP/DHCP, Reply, length 335, hops 1, xid 0x4ee7ebbc, Flags [none] (0x0000)
          Client-IP 172.31.255.2
          Your-IP 172.31.255.2
          Gateway-IP 10.219.45.114
          Client-Ethernet-Address 00:01:47:dc:fa:5b
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            Subnet-Mask Option 1, length 4: 255.255.255.240
            Lease-Time Option 51, length 4: 300
            DHCP-Message Option 53, length 1: ACK
            Server-ID Option 54, length 4: 10.219.66.10
            RN Option 58, length 4: 900
            RB Option 59, length 4: 1800
            Client-ID Option 61, length 7: ether 00:01:47:dc:fa:5b
            Agent-Information Option 82, length 50:
              Circuit-ID SubOption 1, length 6: ^@^D^KM-=^BP
              Remote-ID SubOption 2, length 11: ^A^Irgw01.lab
              Unknown SubOption 5, length 4:
                0x0000:  ac1f ff00
              Unknown SubOption 151, length 15:
                0x0000:  0076 6f69 702d 756e 7472 7573 7465 64
              Unknown SubOption 152, length 4:
                0x0000:  ac1f ff01
            END Option 255, length 0
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users

[Sergey Klusov]

On Чт 28.09.2017 20:56, Jason Lixfeld wrote:
>
> If RFC3527 is supported on your Mikrotik, it could make this all much easier.  Do you know if it is?  If so, it should just work without a need to do classes or anything.  Just a subnet declaration.
>

Just read RFC3527 - very usefull, but Mikrotik does not support it.
I wonder why they decided to send replies to giaddr in original DHCP
standart. From my point of view it would be wise to reply to packet sender.
Those old standarts....
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users