Who Me Too'd this solution

Re: Fixed Address Master to Member Replication
Moderator
Moderator
Posts: 72
This widget could not be displayed.
This widget could not be displayed.

Hello,

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 1.1.1.1 inside 1.1.1.0/24 network and if the client's request for an IP address is via 2.2.2.1 which falls in 2.2.2.0/24 network, your client would end up receiving an IP address from the pool inside 2.2.2.0 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 1.1.1.1 from network 1.1.1.0/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 1.1.1.2.

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 1.1.1.2 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 1.1.1.1 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".

 

Best Regards,
Bibin Thomas

View solution in original post

Who Me Too'd this solution