santanudas
Technical User
Hi guys,
I'm a bit confused with the behaviour of my dhcp server. I'm just wondering if you can help or explain. To summarize every thing else in the dhcpd.conf file is under our own subnet section, like this:
subnet 1.2.3.0 netmask 255.255.255.0 {
deny unknown-clients;
authoritative;
....
....
}
and the rest of the configuration assigns static IP addresses based on the MAC address.
Yet one of the departments - being in the different subnet (say, 1.2.4.) and their server being is the same location as their clients - running mostly windows clients getting DHCPNAK packets from my dhcp server. The situation is most of the groups use the central DHCP server except only a few other including myself. As far as it's been reported that the problem is only with that particular department, rest of them are absolutely fine.
It looks like DHCP specification says that the negotiation must fail if a DHCPNAK is received by the client before the negotiation is complete. Even when a specific DHCP server's response is sent first, the client has to DHCPREQUEST and then receive a DHCPACK *before* being immune to DHCPNAK packets, even from another server.
Then I found, the man-page says: "If the server knows nothing about the address, it will remain silent, unless the address is incorrect for the network segment to which the client has been attached and the server is authoritative for that network segment, in which case the server will send a DHCPNAK even though it doesn't know about the address."
So, I though, perhaps serv05 (my dhcp server) sees foreign clients requesting an IP address in 1.2.4/24 which it thinks is incorrect for my 1.2.3/24 subnet and is sending DHCPNAK for that reason? And then when I commented out "authoritative;" line, I see the the problem gone. Dose it explain the situation very well?
In the other hand, I'm thinking why does the other server seem to fail to respond to it's own clients in the first place?. As far as I understand, the client broadcasts “dhcpdiscover”, using 0.0.0.0 as source address and 255.255.255.255 as destination and the first available DHCP server responds (i.e. dhcpoffer) using a broadcast, as the client does not yet have an IP address. Then, if everything goes okay with “dhcprequest” (i.e. the client selects an IP and sends a dhcprequest to all DHCP servers), the server will send “dhcpack” - if the DHCP server that was
selected sends a successful acknowledgement or a “dhcpnack” - if the dhcprequest was unsuccessful, the DHCP server broadcasts a negative acknowledgement, which is pretty normal for my server as it’s offering only MAC address based static DHCP service.
Now as my server is still responding, even though being in the different subnet and location, maybe something is not okay with the other departmet's server, hence being failed to respond to it’s own clients in the first place?
Which one is right way to think? Any help or explaination??
Thanks in advance.
I'm a bit confused with the behaviour of my dhcp server. I'm just wondering if you can help or explain. To summarize every thing else in the dhcpd.conf file is under our own subnet section, like this:
subnet 1.2.3.0 netmask 255.255.255.0 {
deny unknown-clients;
authoritative;
....
....
}
and the rest of the configuration assigns static IP addresses based on the MAC address.
Yet one of the departments - being in the different subnet (say, 1.2.4.) and their server being is the same location as their clients - running mostly windows clients getting DHCPNAK packets from my dhcp server. The situation is most of the groups use the central DHCP server except only a few other including myself. As far as it's been reported that the problem is only with that particular department, rest of them are absolutely fine.
It looks like DHCP specification says that the negotiation must fail if a DHCPNAK is received by the client before the negotiation is complete. Even when a specific DHCP server's response is sent first, the client has to DHCPREQUEST and then receive a DHCPACK *before* being immune to DHCPNAK packets, even from another server.
Then I found, the man-page says: "If the server knows nothing about the address, it will remain silent, unless the address is incorrect for the network segment to which the client has been attached and the server is authoritative for that network segment, in which case the server will send a DHCPNAK even though it doesn't know about the address."
So, I though, perhaps serv05 (my dhcp server) sees foreign clients requesting an IP address in 1.2.4/24 which it thinks is incorrect for my 1.2.3/24 subnet and is sending DHCPNAK for that reason? And then when I commented out "authoritative;" line, I see the the problem gone. Dose it explain the situation very well?
In the other hand, I'm thinking why does the other server seem to fail to respond to it's own clients in the first place?. As far as I understand, the client broadcasts “dhcpdiscover”, using 0.0.0.0 as source address and 255.255.255.255 as destination and the first available DHCP server responds (i.e. dhcpoffer) using a broadcast, as the client does not yet have an IP address. Then, if everything goes okay with “dhcprequest” (i.e. the client selects an IP and sends a dhcprequest to all DHCP servers), the server will send “dhcpack” - if the DHCP server that was
selected sends a successful acknowledgement or a “dhcpnack” - if the dhcprequest was unsuccessful, the DHCP server broadcasts a negative acknowledgement, which is pretty normal for my server as it’s offering only MAC address based static DHCP service.
Now as my server is still responding, even though being in the different subnet and location, maybe something is not okay with the other departmet's server, hence being failed to respond to it’s own clients in the first place?
Which one is right way to think? Any help or explaination??
Thanks in advance.