Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. how to confgiure gateway address for a subnet in key.conf
(anuj chauhan)
2. Re: how to confgiure gateway address for a subnet in
key.conf (Marcin Siodelski)
3. Conflict Resolution in Host Reservation - seeking input
(Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 29 Jan 2015 15:54:01 +0530
From: anuj chauhan <[email protected]>
To: [email protected]
Subject: [kea-dev] how to confgiure gateway address for a subnet in
key.conf
Message-ID:
<CADijJA=_yqkdc6ccgwzykafst+wu_8sq0kv2jax18ocug3e...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I want to send deault gateway to dhclients for a subnet.
What json syntax i need to put in key.con for defining
gatway addr.
Regards
Anuj Chauhan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20150129/a6e7782e/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 29 Jan 2015 11:36:21 +0100
From: Marcin Siodelski <[email protected]>
To: anuj chauhan <[email protected]>, [email protected]
Subject: Re: [kea-dev] how to confgiure gateway address for a subnet
in key.conf
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Please use the following syntax:
"Dhcp4": {
"subnet4": [
{
"option-data": [
{
"name": "routers",
"data": "192.0.2.3"
},
...
],
...
},
...
],
...
}
or
"Dhcp4": {
"subnet4": [
{
"option-data": [
{
"code": 3,
"data": "192.0.2.3"
},
...
],
...
},
...
],
...
}
Marcin
On 01/29/15 11:24, anuj chauhan wrote:
> Hi,
> I want to send deault gateway to dhclients for a subnet.
> What json syntax i need to put in key.con for defining
> gatway addr.
>
>
>
>
>
> Regards
> Anuj Chauhan
>
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
Message: 3
Date: Thu, 29 Jan 2015 12:38:08 +0100
From: Marcin Siodelski <[email protected]>
To: Kea Dev List <[email protected]>
Subject: [kea-dev] Conflict Resolution in Host Reservation - seeking
input
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear kea-dev mailing list participants,
For the upcoming Kea 0.9.1 release, we're implementing static allocation
of addresses, a.k.a. Host Reservation. When our QA team executed the
recently developed system tests for Host Reservation it has become
apparent that the DHCP engineering team members have some different
opinions on how "address conflict resolution" should work in Kea.
In order to clarify what I mean by the conflict resolution, let me give
an example (also stated in http://kea.isc.org/ticket/3693).
1. There are no static reservations made initially.
2. Client X obtains an address A from the dynamic pool.
3. A new static reservation is made for address A, but it is assigned to
the MAC address of client Y.
4. Client Y doesn't contact the server just yet.
5. Client X tries to renew his lease for address A. Because the renewed
address is now reserved for client Y there is a conflict: client X is
using an address reserved for client Y.
There is a question, how this conflict should be resolved? There are two
approaches that we have discussed.
Approach 1
1. Client X sends DHCPREQUEST to renew the lease for address A.
2. Server responds with DHCPNAK to indicate that client X should not use
this address *but the server doesn't remove the lease until client A
performs a 4-way exchange to acquire a new address*.
3. Let's assume that the Client X doesn't send the DHCPDISCOVER just yet.
4. Instead, client Y sends the DHCPDISCOVER.
5. The server discards the client's message because there is still a
lease for address A for client X.
6. If the client A doesn't perform a 4-way exchange for the remaining
lease lifetime, the lease eventually expires. If the client X performs
the 4-way exchange it is allocated a different address and the address A
becomes available to client Y.
7. Client Y retries DHCPDISCOVER and the server determines that the
lease for the address A has expired so it can be allocated for client Y.
8. When client X contacts the server it is acquired a different address.
Approach 2
1. Client X sends DHCPREQUEST to renew the lease for address A.
2. Server responds with DHCPNAK to indicate that client X should not use
this address *and the server automatically removes the lease for client
A* <<< --- Note that this is the major difference between Approach 1 and
Approach 2
3. Let's assume that the Client X doesn't send the DHCPDISCOVER just yet.
4. Instead, client Y sends the DHCPDISCOVER.
5. The server allocates the reserved address A to client Y, because the
lease owned by client X for the address A has been removed when DHCPNAK
was sent.
6. When client X contacts the server it is acquired a different address.
In summary: the difference between the two approaches is that in case of
Approach 2, the server removes the lease in conflict when it sends a
DHCPNAK to client X. In case of Approach 1, the server doesn't remove
the lease with sending a DHCPNAK but it rather waits for the client X to
send DHCPDISCOVER and then DHCPREQUEST and acquire a different address.
Each of those have some pros and cons. So for example: the Approach 2
allows for potentially faster conflict resolution because the client Y
doesn't have to wait for the lease to expire before it is allocated an
address for which it has a reservation. On the other hand, if the Client
X gets the DHCPNAK, most likely it will immediately fall back to
DHCPDISCOVER/DHCPREQUEST and obtain a new address, which will result in
making the reserved address available for client Y. But, there is a
possibility that right after getting the DHCPNAK, the client was
stopped (e.g. machine shut down) in which case it will never send
DHCPDISCOVER and the client Y will have to wait for the lease
expiration. It may take long to wait if the valid lifetime is long.
The Approach 1 protects the client X against the situation that the
DHCPNAK hasn't reached the client and the client may potentially
continue to use this address which may also be allocated to some other
client. This may occur as a result of a network error. Obviously, there
is a question of how many of such network errors statistically happen
over time.
The Approach 1 is the one currently implemented. We're discussing here
if we should move to Approach 2. We're seeking input from the mailing
list participants as to what the desired behavior is. Mostly, we wonder
if participants may come up with some use cases / scenarios that would
indicate that one approach is better than the other.
As for the current implementation, I don't think there is a big issue
here because the client which received the DHCPNAK would immediately
transition to the INIT state and acquire a new address and the conflict
will get resolved anyway. But the question still stands.
Looking forward to your input.
Marcin Siodelski
ISC DHCP Team
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 10, Issue 8
**************************************
