SEO

How can I determine how many addresses I have remaining to give out on my
server?

I do a pntadm -P but it shows some addresses that the lease has expired, I
want to know if it locks that ip...

Client ID Flags Client IP Server IP Lease Expiration
Macro Comment

01080020000000 00 192.168.50.70 192.168.50.250 06/25/2003
it-dhcp
0100E098000000 00 192.168.50.84 192.168.50.250 06/23/2003
it-dhcp
0100E029000000 03 192.168.50.163 192.168.50.250 Forever
it-dhcp


I also after time get some ip's that have been flagged as 04 and I never
made that change....

LHradowy wrote:
>
> How can I determine how many addresses I have remaining to give out on my
> server?
>
> I do a pntadm -P but it shows some addresses that the lease has expired, I
> want to know if it locks that ip...
>
> Client ID Flags Client IP Server IP Lease Expiration
> Macro Comment
>
> 01080020000000 00 192.168.50.70 192.168.50.250 06/25/2003
> it-dhcp
> 0100E098000000 00 192.168.50.84 192.168.50.250 06/23/2003
> it-dhcp
> 0100E029000000 03 192.168.50.163 192.168.50.250 Forever
> it-dhcp
>
> I also after time get some ip's that have been flagged as 04 and I never
> made that change....

If the lease has expired (i.e. the current system time is after the
reported Lease Expiration time) then in theory that address is available
to the server for allocation. However, the default action of the server
is to check whether an address is in use before it allocates it, as the
last thing you want is two hosts active with the same IP address. If the
server gets a response to its check, whether because the client is
erroneously still using the address or because some other host has
stolen it, it will mark the address as UNUSABLE, which has the value 04,
as it knows that something is not playing by the rules. Once an address
has gone UNUSABLE the DHCP server will ignore that entry until some
external influence clears the UNUSABLE flag.

You can also get the 04 state when a client working to the older DHCP
spec (RFC 1541) issues a DHCPDECLINE message when it does not like
something in the DHCPACK message, because the reasons for DHCPDECLINE
are vague in section 3.2 (3) of the spec. Unfortunately in section 4.3.3
the DHCP server is required to mark the address as unuseable when it
receives a DHCPDECLINE. This can create a "domino" effect, where each
address in turn is offered to such a client, which rejects them all,
until there are no more left!

The later DHCP spec (RFC 2131) limits the client use of DHCPDECLINE to
only the case where the client recognizes that the address is already in
use, and so the domino effect should be removed.

But there can still be an "old" client out there - I saw one last year -
that will knock out a whole subnet if it does not like something in the
DHCPACK it receives, which can be something missing that it expected. In
this case the client objected because a bug in the Solaris DHCP server
caused it to discard some of the data the client should have received,
but even if the bug had not been present the same thing would have
happened if the configuration had not exactly matched the client
expectations.

You can also get to the UNUSABLE state if a client issues a DHCPRELEASE
message and then continues to use the address, even if only briefly, as
it may cause the server to fail its "is the address in use" check noted
above. I had one of those last year as well!

John Howells