Bug 133223

Summary: IP reservation does not work while lease is alive
Product: Red Hat Enterprise Linux 3 Reporter: Andrew Martynov <andrewm>
Component: dhcpAssignee: Jason Vas Dias <jvdias>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: shillman
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-06-02 15:47:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 153928    

Description Andrew Martynov 2004-09-22 15:05:05 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040616

Description of problem:
If IP was taken by client then adding reservation in /etc/dhcpd.conf 
does not work while lease is active.

Client holding this lease can renew it at least one time.



Version-Release number of selected component (if applicable):
dhcp-3.0pl2-6.14

How reproducible:
Always

Steps to Reproduce:
1. install DHCP server
2. configure it with no reservation 
   (comment host statement)
3. wait while client will lease this IP
   first client should get 172.16.0.127
4. uncomment host statement
5. look on client on 'ifconfig'
6. restart DHCP server
7. issue on client 'service network restart'
8. look on client on 'ifconfig'
    

Actual Results:  Client IP was not changed, lease is renewed.

Expected Results:  Client change IP address, lease is released for
specified MAC adress

Additional info:

# /etc/dhcpd.conf --------------------------
ddns-update-style none;
authoritative;

subnet 172.16.0.0 netmask 255.255.0.0 {
        ddns-updates off;
        max-lease-time 259200;
        default-lease-time 259200;
        option broadcast-address 172.16.255.255;
        option subnet-mask 255.255.0.0;
        option domain-name "mylan";
        option domain-name-servers 172.16.0.147, 172.16.0.10;
        option time-servers 172.16.0.107, 172.16.0.18;
        option netbios-name-servers 172.16.0.147, 172.16.0.10;
        option netbios-node-type 8;
        pool {
                ddns-updates off;
                range 172.16.0.1 172.16.0.127;
                }
        pool {
                ddns-updates off;
                range 172.16.0.128 172.16.254.254;
                }


group {
#        host tst1 {
#          fixed-address 172.16.0.127;
#          hardware ethernet ab:cd:ef:ab:cd:ef;
#        }
}

}

Comment 1 Jason Vas Dias 2004-09-22 15:14:56 UTC
Please try the latest version of DHCP-3.0.1 for EL3, that will be in 
RHEL-3-U4, but which meanwhile is available from:
http://people.redhat.com/~jvdias/DHCP/RHEL-3 

I think the above issue is actually a "feature" : if the last 
recorded lease in /var/lib/dhcp/dhclient.leases has not expired,
then dhclient will try to renew the existing lease, not request 
a new one.


Comment 2 Andrew Martynov 2004-09-23 06:45:43 UTC
Yes, it looks like a feature, but it does not documented anywhere.
This is strange, as client meaning of lease activity should not
has primary role. I suppose server configuration should dominate
in lease renew process.

I can reproduce this situation in new version.

Comment 3 Suzanne Hillman 2005-04-05 21:29:46 UTC
Internal RFE bug #153928 entered; will be considered for future releases.

Comment 4 Jason Vas Dias 2005-06-02 15:47:47 UTC
I think this is the way DHCP is meant to work:
 - When the server grants the 172.16.0.127 static lease for 
   ab:cd:ef:ab:cd:ef, it creates an entry in its lease database 
   /var/lib/dhcp/dhcpd.leases, and the client creates an entry
   in its lease database /usr/lib/dhcp/dhclient-${IF}.leases .

 - When the server is restarted with the static lease commented
   out, it still has the 172.16.0.127 lease in its lease database,
   which is also valid in the dynamic lease pool, so it allows the
   client to renew this lease, which is its default behaviour.

So I don't think this issue is a bug.
Please try the latest dhcp version in RHEL-3: dhcp-3.0.1-10 , and
let me know if this issue is still a problem for you; if so, I'll
re-open this bug.