Send dhcp-users mailing list submissions to
[email protected]
Advertising
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
[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 dhcp-users digest..."
Today's Topics:
1. NoBinding after confirmation and subsequent REQUEST message
(Shankar Anand R)
2. Re: Static IP and IP management (Bernard Fay)
3. Re: [Ext] Re: Static IP and IP management (Bernard Fay)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Feb 2016 23:41:40 +0530
From: Shankar Anand R <[email protected]>
To: [email protected]
Subject: NoBinding after confirmation and subsequent REQUEST message
Message-ID:
<CAGOaVCwzkAU97W9Lg=Rmx3CU+Gj20dO4W5a++T4hzEk6o=3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I have a few queries regarding a particular sequence of events described
below. I request for your help in clarifying them.
1. Client reboots and sends out a CONFIRM message with 1 IA_NA
containing 1 IA_ADDR option.
2. Server sends a REPLY with Status code 0 with status message "All
addresses still on link."
3. After some time client sends a RENEW message with same IA_NA and
IA_ADDR option.
4. Server, due to some reason, sends a REPLY with status code 3
(NoBinding) with status message "Address not bound to this interface."
5. Client sends out a REQUEST message with 1 IA_NA containing the same
old IA_ADDR option.
6. Server sends a REPLY message with 1 IA_NA containing a new IA_ADDR
option.
*My queries:*
1. In what possible scenario would an ISC DHCPv6 server send a "NoBinding"
REPLY to an IA_ADDR which it had recently confirmed to the client? Just to
be clear: the server has not rebooted in between.
2. When the server sends a REPLY message with NoBinding in response to a
RENEW message, RFC 3315 section 18.1.8 says
" When the client receives a Reply message in response to a Renew or Rebind
message, the client examines each IA independently. For each IA in the
original Renew or Rebind message, the client:
- sends a Request message if the IA contained a Status Code option
with the NoBinding status (and does not send any additional
Renew/Rebind messages)"
Should this next REQUEST message contain the same IA_ADDR option for which
the server has sent a "NoBinding"?
3. When the server sends a REPLY message with an IA_ADDR which is different
from what the client has asked in it's REQUEST message, what should the
client do? I can see that ISC DHCPv6 client retains both the old IA_ADDR
(which the server had actually a NoBinding) and the new IA_ADDR contained
in the latest REPLY message from the server. This doesn't seem to be
correct to me. Is this the expected behaviour?
Thanks in advance.
Regards,
Shankar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20160224/6e534d83/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 24 Feb 2016 13:17:13 -0500
From: Bernard Fay <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Static IP and IP management
Message-ID:
<cah3ae4box8tqvekp7mnb0ozssgmzkyrrl8k73gmmjs24+1v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I like this idea.
But thinking about it....
When the dhcpd server assign a static IP to a device, it also instruct bind
to add an entry in the DNS zone file. One thing I realized is that if a
device didn't renew his lease, the entry in the DNS zone file is not
removed. I would have thought to use the zone files to know if a device is
in use or not. I had in mind that the lease time would have help to know
if a device therefore an IP is use or not. In other words, a device
requires an IP and the dhcpd server assigned it a statically defined IP
address. The dhcpd server also instruct bind to add an entry in the
appropriate zone file. Eventually the device is turned off, the lease time
reach its limit then I would have expected the dhcpd server to instruct
bind to remove the entry regarding this device but it is not the case.
Then I could have take a look at the zone files to know what is in used and
I would know what is not in use.
Either I made something in my configuration or I was expecting too much
from dhcpd and bind.
Thanks,
On Wed, Feb 24, 2016 at 12:11 PM, Chuck Anderson <[email protected]> wrote:
> On Wed, Feb 24, 2016 at 05:04:10PM +0000, Simon Hobson wrote:
> > Patrick Trapp <[email protected]> wrote:
> >
> > > If you are using host entries to dictate what address a device gets
> (and not allowing devices to grab random addresses - effectively making
> them static without having to configure it on the device), then when you
> delete that host entry from the dhcpd.conf, you would know that address is
> free.
> >
> > Yes, but I think the primary issue is knowing that the assignment is no
> longer needed - as in, that device hasn't been here for a while. Jim has
> given an example of how I suspect most systems manage it - literally keep
> track of what IPs and MACs are in use, and see if any of them go stale.
> >
> > An alternative approach could be to use reserved leases. That way, each
> usage of the assignment goes through the normal DHCP lifecycle - including
> DNS updates. By tracking lease usage etc you can then see if a lease is no
> longer being used.
> >
> > Basically it's the old problem - when something is needed for something
> else to work then it gets noticed, when that something is no longer needed
> then it just gets forgotten about.
>
> One other possibility if you can force everyone to use DHCP is just
> keep the DHCP logs and look at them from the last time a device
> DHCP'd. That way you can keep using fixed-address assignments, but
> managed via DHCP. It helps if you have switches that support DHCP
> Snooping, ARP Inspection, IP Source Guard so you can really enforce
> the use of DHCP.
> _______________________________________________
> dhcp-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20160224/b26e7635/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 24 Feb 2016 13:20:15 -0500
From: Bernard Fay <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: [Ext] Re: Static IP and IP management
Message-ID:
<cah3ae4zhg81dvqsvtm1ngtskuww9qjjt0j6dohxpu9+p57k...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
This is interesting! I'll have to find out how to write such scripts.
Would you have some pointers related to this subject?
Thanks Jim
On Wed, Feb 24, 2016 at 10:00 AM, Jim Glassford <[email protected]> wrote:
> Hi,
>
> This works for us, ymmv. We use home grown scripts that pull information
> from a database to build our dhcpd.conf and dns files for all static
> assignments. We also have different scripts that pull the arp tables from
> the routers each hour and from layer two switches ports to keep track of
> who is where.
>
> Put these together to keep some control for IPAM, sure the commercial
> products do a better job.
>
> As part of the hour run script, we do a compare on what is found in arp
> tables to what we have in the assigned database. If a match, the MAC and IP
> address match what is in the database, update a count field and the date it
> was found. If a MAC is found in arp table does not match the assigned IP
> address, send and email for a discrepancy (someone hard coded when they
> should not or other issue that needs addressed)
> Once in awhile (when I need more static IP addresses for a subnet) review
> the count and last updated fields, if older than a year +/- then safe to
> re-assign this IP address.
>
> best!
> jim
>
>
> On 2/24/2016 9:16 AM, Bernard Fay wrote:
>
> I manage a lab where there is about 300-400 IPs assigned to different
> network equipments, physical and virtual servers. So IPs might be assigned
> for a while then equipments removed because not needed anymore, remember
> this is a lab. I would like to know which IPs are in used or not.
> Equipments removed means IPs not used anymore so we could reuse those IPs.
>
> I hope I am clear enough
> Thanks,
>
>
> On Wed, Feb 24, 2016 at 9:06 AM, Patrick Trapp <[email protected]>
> wrote:
>
>> I believe a helpful answer will require some context. You haven't told us
>> what issues you are having with IP management, so it's going to be
>> difficult to identify how static IP's might be beneficial.
>>
>> Are you having a specific issue you wish to address?
>>
>> ------------------------------
>> *From:* <[email protected]>
>> [email protected] [[email protected]] on
>> behalf of Bernard Fay [ <[email protected]>[email protected]]
>> *Sent:* Wednesday, February 24, 2016 7:39 AM
>> *To:* Users of ISC DHCP
>> *Subject:* Static IP and IP management
>>
>> Hello everyone,
>>
>> I have been told that static IP assignation can help in IP management.
>> Of course, I can know which IPs are assigned by looking in dhcpd.conf. But
>> after a while an IP might not be used anymore and nothing in dhcpd or bind
>> will tell me if it still in use or not. I have setup a lab to experiment
>> where I have configured dhcpd and bind and I cannot find out how static IP
>> can really help in IP management.
>>
>> Did I miss something somewhere?
>>
>> Thanks,
>> B
>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> [email protected]
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>
>
>
> _______________________________________________
> dhcp-users mailing
> [email protected]https://lists.isc.org/mailman/listinfo/dhcp-users
>
>
>
> _______________________________________________
> dhcp-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20160224/3e83f0a6/attachment.html>
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 88, Issue 26
******************************************
