08-17-2017 02:51 PM
Replication wouldn't be the first suspect, especially if this is the only issue you are facing. You could always navigate to "Grid-->Grid Manager-->Members-->Replication Status View" and check whether you see very large numbers for 'SendQ' and 'ReceiveQ' though.
I would recommend verifying the below first:
1. Fixed address (FA) definitions are often required to be written directly into the DHCP configuration file (dhcpd.conf), for them to take effect. Hence it is imperative that the service be restarted for the FA to take effect. However, there are features such as "Immediate FA configuration", in NIOS version 7.0 and above which can apply a fixed address without having to restart the dhcp service. Having said that, even if immediate FA configuration is enabled, if the fixed address you are allocating to a MAC address falls in an existing DHCP range, you will have to restart the service for the changes to take effect.
2. DHCP server by default uses relay agent information (giaddr) for subnet selection for a client. For example: If the Fixed Address you configured is 188.8.131.52 inside 184.108.40.206/24 network and if the client's request for an IP address is via 220.127.116.11 which falls in 18.104.22.168/24 network, your client would end up receiving an IP address from the pool inside 22.214.171.124 network. Having said that, I would like to clarify that subnet selection may not always be associated to relay agent info. Sometimes, it could be on the basis of certain custom configuration such as Option-82, sub-option 5 [Link selection].
3. The last scenario I can think of is. Let say that you've configured a fixed address 126.96.36.199 from network 188.8.131.52/24 for MAC aa:aa:aa:aa:aa:aa and restarted the DHCP service. The client though, currenly has an active lease on IP address 184.108.40.206.
In this scenario, the client may continue sending DHCPRENEW packets to the DHCP server instead of DHCPDISCOVER. The renew packet can have the requested IP field set to 220.127.116.11 all the time. The only way the DHCP server can tell the client to drop it and do a full DORA process so that it can assign the FA 18.104.22.168 is by sending a DHCPNAK message to the client.
Now, the point to note is that only authoritative DHCP servers NAK client requests. You may want to navigate to "Data Management-->DHCP-->Member/Servers-->Edit the member" and verify that the 'Authoritative' flag is set on the general sidetab. To ensure that all your DHCP servers are authoritative, you may even do this from "Data Management-->DHCP-->Grid DHCP Properties".