[Kea-users] Global host reservations - unexpected behavior

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Kea-users] Global host reservations - unexpected behavior

Maria Hrabosova
Hello,

I found a use case in which KEA DHCP server behaves differently than I
expected and I would like to ask if it was meant to behave that way or
there is a problem in my configuration. Here is the description:

Imagine you have a known host client-X with a reserved IP address
10.0.0.9. client-X usually connects via the Shared-B network, but one
day it wants to connect via Shared-A. The IP address reserved for
client-X does not match any of the subnets in Shared-A. Therefore, I
would expect that it would be given an IP address from the pool in the
subnet 10.1.1.0/24 (that is how it works in ISC DHCP). However, it is
given it's reserved IP 10.0.0.9 along with the options from the subnet
10.1.1.0/24, which does not make sense to me. Is this how it was meant
to behave?

I found a solution how to make the client-X get an IP address from the
pool in the subnet 10.1.1.0/24 by moving the host reservation from the
global scope to the scope of the subnet 10.0.0.0/24. Anyway, I've been
wondering why it doesn't work the same way with the global reservations.
I tried the global mode first, as I am using host reservations in groups
(which are global) in ISC DHCP and it works as expected there.

Could you please give it a look? Thanks in advance. See the
corresponding configuration and the demonstration of the use case below.

Best regards,

Maria Hrabosova


---

kea-dhcp4.conf:

{
   "Dhcp4": {
     "interfaces-config": {
       "interfaces": [
         "server-eth0"
       ],
       "dhcp-socket-type": "udp"
     },
     "control-socket": {
       "socket-type": "unix",
       "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
     },
     "lease-database": {
       "type": "memfile"
     },
     "shared-networks": [
       {
         "name": "Shared-A",
         "relay": {
           "ip-address": "192.0.2.1"
         },
         "subnet4": [
           {
             "subnet": "10.1.1.0/24",
             "pools": [
               {
                 "pool": "10.1.1.200 - 10.1.1.250"
               }
             ],
             "option-data": [
               {
                 "name": "routers",
                 "data": "10.1.1.1"
               },
               {
                 "name": "domain-name-servers",
                 "data": "10.1.1.2, 10.1.1.3"
               }
             ]
           }
         ]
       },
       {
         "name": "Shared-B",
         "relay": {
           "ip-address": "192.0.1.1"
         },
         "subnet4": [
           {
             "subnet": "10.0.0.0/24",
             "pools": [
               {
                 "pool": "10.0.0.200 - 10.0.0.250"
               }
             ],
             "option-data": [
               {
                 "name": "routers",
                 "data": "10.0.0.1"
               },
               {
                 "name": "domain-name-servers",
                 "data": "10.0.0.2, 10.0.0.3"
               }
             ]
           }
         ]
       }
     ],
     "host-reservation-identifiers": [
       "hw-address"
     ],
     "reservation-mode": "global",
     "reservations": [
       {
         "hw-address": "aa:a0:00:00:11:10",
         "ip-address": "10.0.0.9",
         "hostname": "client-X"
       }
     ]
   }
}

---

dhclient-debug.sh:

#!/bin/sh
env

---

ip add
...
     link/ether aa:a0:00:00:11:10 brd ff:ff:ff:ff:ff:ff link-netnsid 1
...


dhclient client1-eth0 --timeout 2 -sf dhclient-debug.sh -H client-X
...
new_ip_address=10.0.0.9
new_routers=10.1.1.1
new_domain_name_servers=10.1.1.2 10.1.1.3
...

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Global host reservations - unexpected behavior

Gibbins, John (IM&T, Black Mountain)
Hi Maria,

In the 1.5.0 Kea Administrator Reference Manual (p69 of the PDF) it says:

"Note You can reserve any ip-address in a global reservation. Just keep in mind that Kea will not do any sanity checking on the
address and for Kea 1.5.0, support for global reservations should be considered experimental."

I believe that by "sanity checking" it means that it will not ensure that the address is appropriate for the subnet as you found.  I suspect this may change in later releases.

Disclaimer: I'm very new to kea.

I'm trying to translate our ISC DHCP config to kea.  I had assumed from this that I needed to put reservations within the subnet as you discovered.  To me it makes more sense to have them associated with the subnet rather than globally as ISC DHCP did.
My intention is to translate ISC DHCP reservations to subnet reservations and subclasses to global reservations.

Regards
johng

-----Original Message-----
From: Kea-users <[hidden email]> On Behalf Of Maria Hrabosova
Sent: Tuesday, 15 October 2019 1:17 AM
To: [hidden email]
Subject: [Kea-users] Global host reservations - unexpected behavior

Hello,

I found a use case in which KEA DHCP server behaves differently than I
expected and I would like to ask if it was meant to behave that way or
there is a problem in my configuration. Here is the description:

Imagine you have a known host client-X with a reserved IP address
10.0.0.9. client-X usually connects via the Shared-B network, but one
day it wants to connect via Shared-A. The IP address reserved for
client-X does not match any of the subnets in Shared-A. Therefore, I
would expect that it would be given an IP address from the pool in the
subnet 10.1.1.0/24 (that is how it works in ISC DHCP). However, it is
given it's reserved IP 10.0.0.9 along with the options from the subnet
10.1.1.0/24, which does not make sense to me. Is this how it was meant
to behave?

I found a solution how to make the client-X get an IP address from the
pool in the subnet 10.1.1.0/24 by moving the host reservation from the
global scope to the scope of the subnet 10.0.0.0/24. Anyway, I've been
wondering why it doesn't work the same way with the global reservations.
I tried the global mode first, as I am using host reservations in groups
(which are global) in ISC DHCP and it works as expected there.

Could you please give it a look? Thanks in advance. See the
corresponding configuration and the demonstration of the use case below.

Best regards,

Maria Hrabosova


---

kea-dhcp4.conf:

{
   "Dhcp4": {
     "interfaces-config": {
       "interfaces": [
         "server-eth0"
       ],
       "dhcp-socket-type": "udp"
     },
     "control-socket": {
       "socket-type": "unix",
       "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
     },
     "lease-database": {
       "type": "memfile"
     },
     "shared-networks": [
       {
         "name": "Shared-A",
         "relay": {
           "ip-address": "192.0.2.1"
         },
         "subnet4": [
           {
             "subnet": "10.1.1.0/24",
             "pools": [
               {
                 "pool": "10.1.1.200 - 10.1.1.250"
               }
             ],
             "option-data": [
               {
                 "name": "routers",
                 "data": "10.1.1.1"
               },
               {
                 "name": "domain-name-servers",
                 "data": "10.1.1.2, 10.1.1.3"
               }
             ]
           }
         ]
       },
       {
         "name": "Shared-B",
         "relay": {
           "ip-address": "192.0.1.1"
         },
         "subnet4": [
           {
             "subnet": "10.0.0.0/24",
             "pools": [
               {
                 "pool": "10.0.0.200 - 10.0.0.250"
               }
             ],
             "option-data": [
               {
                 "name": "routers",
                 "data": "10.0.0.1"
               },
               {
                 "name": "domain-name-servers",
                 "data": "10.0.0.2, 10.0.0.3"
               }
             ]
           }
         ]
       }
     ],
     "host-reservation-identifiers": [
       "hw-address"
     ],
     "reservation-mode": "global",
     "reservations": [
       {
         "hw-address": "aa:a0:00:00:11:10",
         "ip-address": "10.0.0.9",
         "hostname": "client-X"
       }
     ]
   }
}

---

dhclient-debug.sh:

#!/bin/sh
env

---

ip add
...
     link/ether aa:a0:00:00:11:10 brd ff:ff:ff:ff:ff:ff link-netnsid 1
...


dhclient client1-eth0 --timeout 2 -sf dhclient-debug.sh -H client-X
...
new_ip_address=10.0.0.9
new_routers=10.1.1.1
new_domain_name_servers=10.1.1.2 10.1.1.3
...

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Global host reservations - unexpected behavior

Francis Dupont
> I'm trying to translate our ISC DHCP config to kea.  I had assumed
> from this that I needed to put reservations within the subnet as you
> discovered.  To me it makes more sense to have them associated with
> the subnet rather than globally as ISC DHCP did.

=> BTW this is an easy case because you can infer from the address in
what subnet a reservation should go. But of course when you have no address
i.e. when a reservation is used to set hostname and/or specific options,
you can only rely on a heuristic in particular when you can't use global
reservations (e.g. when you use an old Kea version which does not support
them).

Regards

Francis Dupont <[hidden email]>

PS: teh Kea Migration Assistant is available in the public repository and
should be integrated into the distribution of the next ISC DHCP.
You can get soem idea from it and of course if you can propose improvements
you are welcome.
_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Global host reservations - unexpected behavior

Maria Hrabosova
In reply to this post by Gibbins, John (IM&T, Black Mountain)
Hi John,

Thanks for your reply. Apparently, using the global reservations now,
that they do no sanity checks, isn't a good idea. Unfortunately, the
absence of the checks makes the global reservations containing IP
addresses unusable in any settings, where the clients can move from one
shared network to another. It would be nice if the checks were added in
a future release...

By the way, while looking at the host reservations in KEA more closely,
I found out that the meaning of the KNOWN and UNKNOWN classes is a bit
different from what we know from ISC DHCP. I thought this information
might be useful for you or for others who are migrating to KEA. In ISC
DHCP, the KNOWN class covers all hosts that have a reservation and the
rest of the hosts belongs to the UNKNOWN class. In KEA, the KNOWN class
covers only the hosts that have a reservation in the particular subnet.
Respectively, the UNKNOWN class covers all hosts that are not known in
that subnet (although they can be known in a different subnet or have a
global reservation).

Cheers,
Maria

On 14.10.19 23:03, Gibbins, John (IM&T, Black Mountain) wrote:

> Hi Maria,
>
> In the 1.5.0 Kea Administrator Reference Manual (p69 of the PDF) it says:
>
> "Note You can reserve any ip-address in a global reservation. Just keep in mind that Kea will not do any sanity checking on the
> address and for Kea 1.5.0, support for global reservations should be considered experimental."
>
> I believe that by "sanity checking" it means that it will not ensure that the address is appropriate for the subnet as you found.  I suspect this may change in later releases.
>
> Disclaimer: I'm very new to kea.
>
> I'm trying to translate our ISC DHCP config to kea.  I had assumed from this that I needed to put reservations within the subnet as you discovered.  To me it makes more sense to have them associated with the subnet rather than globally as ISC DHCP did.
> My intention is to translate ISC DHCP reservations to subnet reservations and subclasses to global reservations.
>
> Regards
> johng
>
> -----Original Message-----
> From: Kea-users <[hidden email]> On Behalf Of Maria Hrabosova
> Sent: Tuesday, 15 October 2019 1:17 AM
> To: [hidden email]
> Subject: [Kea-users] Global host reservations - unexpected behavior
>
> Hello,
>
> I found a use case in which KEA DHCP server behaves differently than I
> expected and I would like to ask if it was meant to behave that way or
> there is a problem in my configuration. Here is the description:
>
> Imagine you have a known host client-X with a reserved IP address
> 10.0.0.9. client-X usually connects via the Shared-B network, but one
> day it wants to connect via Shared-A. The IP address reserved for
> client-X does not match any of the subnets in Shared-A. Therefore, I
> would expect that it would be given an IP address from the pool in the
> subnet 10.1.1.0/24 (that is how it works in ISC DHCP). However, it is
> given it's reserved IP 10.0.0.9 along with the options from the subnet
> 10.1.1.0/24, which does not make sense to me. Is this how it was meant
> to behave?
>
> I found a solution how to make the client-X get an IP address from the
> pool in the subnet 10.1.1.0/24 by moving the host reservation from the
> global scope to the scope of the subnet 10.0.0.0/24. Anyway, I've been
> wondering why it doesn't work the same way with the global reservations.
> I tried the global mode first, as I am using host reservations in groups
> (which are global) in ISC DHCP and it works as expected there.
>
> Could you please give it a look? Thanks in advance. See the
> corresponding configuration and the demonstration of the use case below.
>
> Best regards,
>
> Maria Hrabosova
>
>
> ---
>
> kea-dhcp4.conf:
>
> {
>     "Dhcp4": {
>       "interfaces-config": {
>         "interfaces": [
>           "server-eth0"
>         ],
>         "dhcp-socket-type": "udp"
>       },
>       "control-socket": {
>         "socket-type": "unix",
>         "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
>       },
>       "lease-database": {
>         "type": "memfile"
>       },
>       "shared-networks": [
>         {
>           "name": "Shared-A",
>           "relay": {
>             "ip-address": "192.0.2.1"
>           },
>           "subnet4": [
>             {
>               "subnet": "10.1.1.0/24",
>               "pools": [
>                 {
>                   "pool": "10.1.1.200 - 10.1.1.250"
>                 }
>               ],
>               "option-data": [
>                 {
>                   "name": "routers",
>                   "data": "10.1.1.1"
>                 },
>                 {
>                   "name": "domain-name-servers",
>                   "data": "10.1.1.2, 10.1.1.3"
>                 }
>               ]
>             }
>           ]
>         },
>         {
>           "name": "Shared-B",
>           "relay": {
>             "ip-address": "192.0.1.1"
>           },
>           "subnet4": [
>             {
>               "subnet": "10.0.0.0/24",
>               "pools": [
>                 {
>                   "pool": "10.0.0.200 - 10.0.0.250"
>                 }
>               ],
>               "option-data": [
>                 {
>                   "name": "routers",
>                   "data": "10.0.0.1"
>                 },
>                 {
>                   "name": "domain-name-servers",
>                   "data": "10.0.0.2, 10.0.0.3"
>                 }
>               ]
>             }
>           ]
>         }
>       ],
>       "host-reservation-identifiers": [
>         "hw-address"
>       ],
>       "reservation-mode": "global",
>       "reservations": [
>         {
>           "hw-address": "aa:a0:00:00:11:10",
>           "ip-address": "10.0.0.9",
>           "hostname": "client-X"
>         }
>       ]
>     }
> }
>
> ---
>
> dhclient-debug.sh:
>
> #!/bin/sh
> env
>
> ---
>
> ip add
> ...
>       link/ether aa:a0:00:00:11:10 brd ff:ff:ff:ff:ff:ff link-netnsid 1
> ...
>
>
> dhclient client1-eth0 --timeout 2 -sf dhclient-debug.sh -H client-X
> ...
> new_ip_address=10.0.0.9
> new_routers=10.1.1.1
> new_domain_name_servers=10.1.1.2 10.1.1.3
> ...
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Global host reservations - unexpected behavior

Gibbins, John (IM&T, Black Mountain)
Hi Maria,

Thanks for that information.  I don't think I ever looked into the
exact meaning of KNOWN vs UNKNOWN in ISC DHCP so never used them,
so I should be safe.  😊

In ISC, all reservations were global anyway (which always seemed
odd to me).

Regards
johng

-----Original Message-----
From: Maria Hrabosova <[hidden email]>
Sent: Wednesday, 23 October 2019 2:48 AM
To: Gibbins, John (IM&T, Black Mountain) <[hidden email]>; [hidden email]
Subject: Re: [Kea-users] Global host reservations - unexpected behavior

Hi John,

Thanks for your reply. Apparently, using the global reservations now,
that they do no sanity checks, isn't a good idea. Unfortunately, the
absence of the checks makes the global reservations containing IP
addresses unusable in any settings, where the clients can move from one
shared network to another. It would be nice if the checks were added in
a future release...

By the way, while looking at the host reservations in KEA more closely,
I found out that the meaning of the KNOWN and UNKNOWN classes is a bit
different from what we know from ISC DHCP. I thought this information
might be useful for you or for others who are migrating to KEA. In ISC
DHCP, the KNOWN class covers all hosts that have a reservation and the
rest of the hosts belongs to the UNKNOWN class. In KEA, the KNOWN class
covers only the hosts that have a reservation in the particular subnet.
Respectively, the UNKNOWN class covers all hosts that are not known in
that subnet (although they can be known in a different subnet or have a
global reservation).

Cheers,
Maria

On 14.10.19 23:03, Gibbins, John (IM&T, Black Mountain) wrote:

> Hi Maria,
>
> In the 1.5.0 Kea Administrator Reference Manual (p69 of the PDF) it says:
>
> "Note You can reserve any ip-address in a global reservation. Just keep in mind that Kea will not do any sanity checking on the
> address and for Kea 1.5.0, support for global reservations should be considered experimental."
>
> I believe that by "sanity checking" it means that it will not ensure that the address is appropriate for the subnet as you found.  I suspect this may change in later releases.
>
> Disclaimer: I'm very new to kea.
>
> I'm trying to translate our ISC DHCP config to kea.  I had assumed from this that I needed to put reservations within the subnet as you discovered.  To me it makes more sense to have them associated with the subnet rather than globally as ISC DHCP did.
> My intention is to translate ISC DHCP reservations to subnet reservations and subclasses to global reservations.
>
> Regards
> johng
>
> -----Original Message-----
> From: Kea-users <[hidden email]> On Behalf Of Maria Hrabosova
> Sent: Tuesday, 15 October 2019 1:17 AM
> To: [hidden email]
> Subject: [Kea-users] Global host reservations - unexpected behavior
>
> Hello,
>
> I found a use case in which KEA DHCP server behaves differently than I
> expected and I would like to ask if it was meant to behave that way or
> there is a problem in my configuration. Here is the description:
>
> Imagine you have a known host client-X with a reserved IP address
> 10.0.0.9. client-X usually connects via the Shared-B network, but one
> day it wants to connect via Shared-A. The IP address reserved for
> client-X does not match any of the subnets in Shared-A. Therefore, I
> would expect that it would be given an IP address from the pool in the
> subnet 10.1.1.0/24 (that is how it works in ISC DHCP). However, it is
> given it's reserved IP 10.0.0.9 along with the options from the subnet
> 10.1.1.0/24, which does not make sense to me. Is this how it was meant
> to behave?
>
> I found a solution how to make the client-X get an IP address from the
> pool in the subnet 10.1.1.0/24 by moving the host reservation from the
> global scope to the scope of the subnet 10.0.0.0/24. Anyway, I've been
> wondering why it doesn't work the same way with the global reservations.
> I tried the global mode first, as I am using host reservations in groups
> (which are global) in ISC DHCP and it works as expected there.
>
> Could you please give it a look? Thanks in advance. See the
> corresponding configuration and the demonstration of the use case below.
>
> Best regards,
>
> Maria Hrabosova
>
>
> ---
>
> kea-dhcp4.conf:
>
> {
>     "Dhcp4": {
>       "interfaces-config": {
>         "interfaces": [
>           "server-eth0"
>         ],
>         "dhcp-socket-type": "udp"
>       },
>       "control-socket": {
>         "socket-type": "unix",
>         "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
>       },
>       "lease-database": {
>         "type": "memfile"
>       },
>       "shared-networks": [
>         {
>           "name": "Shared-A",
>           "relay": {
>             "ip-address": "192.0.2.1"
>           },
>           "subnet4": [
>             {
>               "subnet": "10.1.1.0/24",
>               "pools": [
>                 {
>                   "pool": "10.1.1.200 - 10.1.1.250"
>                 }
>               ],
>               "option-data": [
>                 {
>                   "name": "routers",
>                   "data": "10.1.1.1"
>                 },
>                 {
>                   "name": "domain-name-servers",
>                   "data": "10.1.1.2, 10.1.1.3"
>                 }
>               ]
>             }
>           ]
>         },
>         {
>           "name": "Shared-B",
>           "relay": {
>             "ip-address": "192.0.1.1"
>           },
>           "subnet4": [
>             {
>               "subnet": "10.0.0.0/24",
>               "pools": [
>                 {
>                   "pool": "10.0.0.200 - 10.0.0.250"
>                 }
>               ],
>               "option-data": [
>                 {
>                   "name": "routers",
>                   "data": "10.0.0.1"
>                 },
>                 {
>                   "name": "domain-name-servers",
>                   "data": "10.0.0.2, 10.0.0.3"
>                 }
>               ]
>             }
>           ]
>         }
>       ],
>       "host-reservation-identifiers": [
>         "hw-address"
>       ],
>       "reservation-mode": "global",
>       "reservations": [
>         {
>           "hw-address": "aa:a0:00:00:11:10",
>           "ip-address": "10.0.0.9",
>           "hostname": "client-X"
>         }
>       ]
>     }
> }
>
> ---
>
> dhclient-debug.sh:
>
> #!/bin/sh
> env
>
> ---
>
> ip add
> ...
>       link/ether aa:a0:00:00:11:10 brd ff:ff:ff:ff:ff:ff link-netnsid 1
> ...
>
>
> dhclient client1-eth0 --timeout 2 -sf dhclient-debug.sh -H client-X
> ...
> new_ip_address=10.0.0.9
> new_routers=10.1.1.1
> new_domain_name_servers=10.1.1.2 10.1.1.3
> ...
>
> _______________________________________________
> 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