Log options for IPv6 clients.
Amit
amit.kr at nic.in
Wed Apr 9 04:20:13 UTC 2014
Hi,
We have written an script which takes out DUID from iana and convert it in
HEX format, so that Client can easily be identified based on that.
--
Thanks & Regards
Amit Kumar
Scientific Officer
Operation and Routing Group
M/O Communication and IT, NIC, A- Block, CGO Complex, New Delhi
Ph. +911122900332, NKN VoIP:7332
Mob. +919910611621
-----Original Message-----
From: dhcp-users-bounces+amit.kr=nic.in at lists.isc.org
[mailto:dhcp-users-bounces+amit.kr=nic.in at lists.isc.org] On Behalf Of
dhcp-users-request at lists.isc.org
Sent: Monday, April 07, 2014 10:19 PM
To: dhcp-users at lists.isc.org
Subject: dhcp-users Digest, Vol 66, Issue 16
Send dhcp-users mailing list submissions to
dhcp-users at lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-request at lists.isc.org
You can reach the person managing the list at
dhcp-users-owner at lists.isc.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of dhcp-users digest..."
Today's Topics:
1. Log options for IPv6 clients. (Valdinei Rodrigues dos Reis)
2. Re: Log options for IPv6 clients. (Simon Hobson)
3. Re: Multiple ACK Issue (Joey D.)
----------------------------------------------------------------------
Message: 1
Date: Mon, 7 Apr 2014 12:46:30 -0300
From: Valdinei Rodrigues dos Reis <valmatrix at ig.com.br>
To: Users of ISC DHCP <dhcp-users at lists.isc.org>
Subject: Log options for IPv6 clients.
Message-ID:
<CALSJsE4Xvjnq+YF-qm3sFBdhMu6C5DpceqsimTtDtsq5bdibTg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi.
Is there any way to change the host identification stored in the
dhcpd6.leases file?
The default is to store the ia-na, like the example below:
ia-na "\202&\000\026\000\001\000\001\027\231!\177\034\301\336\250gi" {
cltt 1 2014/04/07 13:17:18;
iaaddr xxx:xx:xxxx:xx::xxx {
binding state active;
preferred-life 86400;
max-life 86400;
ends 2 2014/04/08 13:17:18;
}
I think it is better store the MAC address associated with the leased
address.
Another issue, I noticed that only dynamic clients get in into the
dhcpd6.leases file, not the ones that has a host declaration. Is it a normal
behavior? Is it possible to change this?
Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20140407/a31ba4cf/at
tachment-0001.html>
------------------------------
Message: 2
Date: Mon, 7 Apr 2014 17:12:49 +0100
From: Simon Hobson <dhcp1 at thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users at lists.isc.org>
Subject: Re: Log options for IPv6 clients.
Message-ID: <11894092-A9BC-4D9D-BB9C-5708DB45CDCD at thehobsons.co.uk>
Content-Type: text/plain; charset=iso-8859-1
Valdinei Rodrigues dos Reis <valmatrix at ig.com.br> wrote:
> I think it is better store the MAC address associated with the leased
address.
It can't, for two reasons :
1) The RFCs don't allow it - when DHCPv6 was being designed, there was a
policy decision that the MAC address would not be used as an identifier at
all.
2) The server doesn't necessarily even know it.
If you check the list archives, you'll find a thread "MAC vs DUID issue"
where the reasons are discussed (again). While the context is different,
pretty well the same discussion applies to your query.
------------------------------
Message: 3
Date: Mon, 07 Apr 2014 11:49:07 -0500
From: "Joey D." <jobewan at gmail.com>
To: Users of ISC DHCP <dhcp-users at lists.isc.org>
Subject: Re: Multiple ACK Issue
Message-ID: <5342D703.9030908 at gmail.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
It looks like the last response/inquiry was not sent to the list. I'm
sending it back through in hopes of getting additional feedback on my issue.
I'm still looking for info as to whether this is expected behaviour.
- Joey D.
On 04/04/2014 01:50 PM, Joey D. wrote:
> I have tested this with numerous packet captures. In every Packet
> capture, there are 2 DISCOVERs, 1 OFFER (from 'Server B', indicating
> the load-balancing algorithm is doing it's job), 2 REQUESTs (from the
> client, with option 54 noting Server B), 2 ACKS with each server
> sending their own option 54 address.
>
> This scenario does not occur if I wipe the lease data for that client
> from both servers' lease tables; this results in only 1 ACK from the
> server listed in option 54 in the REQUEST (Server B). Once that
> works, if I reboot the client, we are back in the state of ACKS being
> sent from both servers. I can submit more data in a bug report if
> necessary, but I'm not sure if this is a bug just yet...
>
> In the event of T2 timer, there is no option 54 info as mentioned.
>
> I included the email thread including additional data below (we use
> split 128).
>
> Regards,
>
> - Joey D.
>
>
> On 04/04/2014 01:24 PM, Bruce Hudson wrote:
>> My DHCP is a bit rusty these days but I would definitely not
>> expect multiple ACKs during a regular DORA. The request from the
>> client should include the server identifier of the offer it is
>> accepting; and only that server should process the request. That is part
of the protocol.
>>
>> If you are seeing multiple ACKs, either (1) the client is broken
>> and is not including a server identifier, (2) the servers are somehow
>> set to use the same identifier, or (3) the DHCP server is broken and
>> ignoring the identifier in the request. In the absence of packet
>> traces, I am inclined to assume one of the first two. Can you see a
>> server ACKing a client request that includes a different identifier?
>>
>> A client can definitely broadcast a request without an
>> identifier, either during a reboot or at T2 as you suggest. In those
>> cases I would expect any server that sees the request to respond. You
>> will see multiple ACKs.
>>
>> You did not say (or I missed) whether or not these two servers
>> are part of a redundancy pair or not. If they are, that might be the
>> code path that leads to ignoring the server identifier. On the other
>> hand, in that case I would expect the "split" statement to prevent
>> both servers from responding. Do you set the split to 255?
>> --
>> Bruce A. Hudson |Bruce.Hudson at Dal.CA
>> ITS, Networks and Systems |
>> Dalhousie University |
>> Halifax, Nova Scotia, Canada | (902) 494-3405
>
>
>
> On 04/04/2014 12:04 PM, Joey D. wrote:
>> I apologize if it's not proper etiquette to post the same issue
>> to both mailing lists, but I'm looking for a bit of feedback as to
>> whether what I'm experiencing is 'expected' behaviour from the isc
>> dhcp software. It looks as though myself and Leigh are both
>> observing the same 'multiple ack' scenario, but it's a bit of a
>> "muddy" explanation in the RFC as to whether both ACKs should present
>> themself during a reboot/DORA (although I'd expect it to happen at a
>> T2 timer).
>>
>> - Joey D.
>>
>>
>> On 04/02/2014 12:48 PM, jobewan wrote:
>>> In our environment, multiple ACKs are causing an issue. We have our
>>> servers setup in 2 different geographic regions, and there is a DHCP
>>> proxy in-line near the client site. The issue is that the
>>> anti-spoofing mechanism in the dhcp-proxy always picks up on the 1st
>>> ack to make it back, which is always going to be 'Server A' (due to
>>> the latency b/t the regions); although 'Server B' is sending the
>>> offer. This in turn causes issues for the client that is wanting an
>>> IP address from Server B.
>>>
>>> Is the double ACK an expected behavior on a reboot? The RFC on 3.1
>>> says "If the client already knows its address, some steps may be
>>> omitted", which indicates that this should potentially follow the
>>> process noted in 3.2 (showing both servers sending an ACK).
>>> Although, during a reboot, the client doesn't know it's ip address
>>> and follows a simple DORA which would indicate it would use the
>>> process in 3.1 (meaning only 1 server sends an ACK)
>>>
>>> (also, sorry for the double post, It appeared that my initial mail
>>> was caught by a spamfilter).
>>>
>>> - Joey D.
>>>
>>>
>>> On 04/02/2014 11:16 AM, Leigh Porter wrote:
>>>>
>>>> I see a similar issue with a similar config, however the duplicate
>>>> ACK is not on the initial request but for lease renewals.
>>>>
>>>> I've not bothered investigating so far as it seemed to do no harm
>>>> for now..
>>>>
>>>> --
>>>>
>>>> Leigh
>>>>
>>>> *From:*dhcp-users-bounces+leigh.porter=ukbroadband.com at lists.isc.or
>>>> g
>>>> [mailto:dhcp-users-bounces+leigh.porter=ukbroadband.com at lists.isc.o
>>>> rg]
>>>> *On Behalf Of *Joey D.
>>>> *Sent:* 02 April 2014 17:04
>>>> *To:* dhcp-users at lists.isc.org
>>>> *Subject:* Multiple ACK Issue
>>>>
>>>> Below is a diagram of what we witness is happening in the event of
>>>> a device reboot of a previously connected device (meaning the
>>>> device is already established in the leases db on both servers), as
>>>> well as our failover config. Is there a configuration directive
>>>> that can be used which mandates that only the server sending the
>>>> offer can send the ACK? (much like what is done when allocating a
>>>> fresh lease like in sec 3.2 in the rfc). I can detail a bit more
>>>> as to the environment layout if necessary, but I'm hoping there is
>>>> an option I'm simply overlooking.
>>>>
>>>>
>>>> Server A Client Server B
>>>>
>>>> v v v
>>>>
>>>> | | |
>>>>
>>>> | Begins initialization |
>>>>
>>>> | | |
>>>>
>>>> | _____________/|\____________ |
>>>>
>>>> |/DHCPDISCOVER | DHCPDISCOVER\|
>>>>
>>>> | | |
>>>>
>>>> | | |
>>>>
>>>> | | ___________/|
>>>>
>>>> | | /DHCPOFFER |
>>>>
>>>> | |/ |
>>>>
>>>> | Selects configuration |
>>>>
>>>> | | |
>>>>
>>>> | _____________/|\____________ |
>>>>
>>>> |/ DHCPREQUEST | DHCPREQUEST\|
>>>>
>>>> | | |
>>>>
>>>> | | |
>>>>
>>>> | | |
>>>>
>>>> |\_____________ | ____________/|
>>>>
>>>> | DHCPACK \|/ DHCPACK |
>>>>
>>>> | | |
>>>>
>>>> | Initialization complete |
>>>>
>>>>
>>>>
>>>> SERVER A:
>>>> stash-agent-options true;
>>>>
>>>> failover peer "iah-kcm" {
>>>> primary;
>>>> address x.x.1.248;
>>>> port 647;
>>>> peer address x.x.2.248;
>>>> peer port 647;
>>>> auto-partner-down 121;
>>>> max-response-delay 120;
>>>> max-unacked-updates 10;
>>>> load balance max seconds 5;
>>>> mclt 3600;
>>>> split 128;
>>>>
>>>> }
>>>> server-identifier x.x.1.248;
>>>> ping-check false;
>>>>
>>>>
>>>> SERVER B:
>>>> stash-agent-options true;
>>>>
>>>> failover peer "iah-kcm" {
>>>>
>>>> secondary;
>>>> address x.x.2.248;
>>>> port 647;
>>>> peer address x.x.1.248;
>>>> peer port 647;
>>>> auto-partner-down 121;
>>>> max-response-delay 120;
>>>> max-unacked-updates 10;
>>>> load balance max seconds 5;
>>>> }
>>>> server-identifier x.x.2.248;
>>>> ping-check false;
>>>>
>>>>
>>>> - Joey D.
>>>>
>>>>
>>>> ___________________________________________________________________
>>>> ___ This email has been scanned by the Symantec Email
>>>> Security.cloud service.
>>>> For more information please visit http://www.symanteccloud.com
>>>> ___________________________________________________________________
>>>> ___
>>>>
>>>>
>>>> ___________________________________________________________________
>>>> ___ This email has been scanned by the Symantec Email
>>>> Security.cloud service.
>>>> For more information please visit http://www.symanteccloud.com
>>>> ___________________________________________________________________
>>>> ___
>>>>
>>>>
>>>> _______________________________________________
>>>> dhcp-users mailing list
>>>> dhcp-users at lists.isc.org
>>>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20140407/e5f97c20/at
tachment.html>
------------------------------
_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 66, Issue 16
******************************************
More information about the dhcp-users
mailing list