Our DHCP server currently answers the DHCP Discover requests from ServerX. In our dhcpd.conf file there are parameters defined for ServerX.
Now we introduced some additional Servers into the network and want them to get service from the same DHCP server.
Similar configuration parameters as currently present for ServerX were added for the other Servers into the dhcpd.conf file.
The dhcpd process was restarted.
However, in the /var/log/messages, we could see the incoming DHCP Discover messages for the newly added servers but no OFFER for them.
Mar 7 11:18:05 trber dhcpd: DHCPDISCOVER from mac:mac:mac:mac via IP:IP:IP:IP:IP: unknown network segment
The system keeps sending OFFER for the ServerX only.
We rebooted the DHCP server. It is up and the result is still same.
For confirming that the dhcpd service could use the conf file properly, we removed the entries for ServerX in the dhcpd.conf file and restarted the dhcpd process.
Still DHCP server continue to OFFER for ServerX while there are no parameters for it in the conf file.
It makes me feel that dhcpd process is not interested in any change at dhcpd.conf file, even not use it.
How could it happen?
Our dhcpd.conf file stays in /etc directory : /etc/dhcpd.conf
In some server I could see the directory used is /etc/dhcp/ : /etc/dhcp/dhcpd.conf
Do you have any idea who dhcpd service does not use it's conf file?
Perhaps that depends on the type of DHCP-server software you use. It seems the best, IMHO, to look at its man page or other accompanying documentation to resolve that. Actually i have - in various environments - seen both /etc/dhcpd.conf and /etc/dhcpd/dhcpd.conf . If the documentation is unclear about this (i doubt that, but who knows?) you can create /etc/dhcpd/dhcpd.conf as a symlink to /etc/dhcpd.conf and have it both ways.
2 additional thoughts that might or might not be relevant for your problem:
For DHCP to work properly routers in between the server and the client have to be able to work as a "bootp-relay-agent" because the DHCPrequest packets by which the client asks for an IP-address are broadcasts without a source-IP (obviously). See RFC 1533 or its successor RFC2132 "DHCP Options and bootp Vendor Extensions" or RFC1534 "Interoperation Between DHCP and BOOTP". If the two servers are in different subnets this might affect the operation, if they are in the same subnet then this point is moot, of course.
DHCP (as well as bootp, of which DHCP is a superset) allows to base client configuration on MAC-addresses so that a certain client always gets the same config. It is also possible to configure the server so that it ignores all requests not coming from a defined set of such addresses. This might also be a reason why your new system are being ignored.
I will copy the dhcpd.conf to /etc/dhcp/ directory too and try restarting the dhcpd service. I will check it but not much hope as the working ServerX was fine with the file /etc/dhcpd.conf.
We did the modification on this file /etc/dhcpd.conf but no changes on the behaviour as I mentioned in my first entry.
I didnt get the explanation of why could the server ignore the requests not coming from a defined set of addresses.
For the MAC addresses DISCOVERed in the incoming relayed packet, we have entries in dhcpd.conf and an OFFER should occur.
However, as I tried to explain, anything we do in dhcpd.conf doesnt make any change in DHCP behaviour.
Besides being unable to get OFFER for the new system, another important output is that we removed the entry for the working DHCP client in /etc/dhcpd.conf file but the DHCP server still providing OFFER to that server. I would expect that it starts to give error for the incoming DHCP requests since then.
At this point, to get more qualified help, you might consider telling us a bit more about your environment:
OS + version (of the DHCP server)?
DHCP server software used + version?
Again, where the configuration files can be found depends on the implementation, so don't expect more than generic suggestions as long as you do not provide more specific information.
In general, a daemon will re-read its configuration only if made to do so. The common way of doing so is to send signal 1 (i.e. kill -1 <PID-of-dhcpd> ) but maybe your implementation does it differently - again: tell us what you use and we may offer better/less generic help.
If you hoped for something like press the foo-key three times, turn right, spit over your left shoulder and all is good i have to disappoint you. ;-)) I am, at this point, at the same loss you are and by suggesting whatever comes to my mind as remotely possible i hope to help you to get the right idea eventually.
It is possible to enter rules into the configuration so that "MAC-address X" is always given "IP-address Y (plus other specific information in the DHCP option fields: default route, DNS server, ...)". It is also possible to configure the DHCP server to only answer requests from clients explicitly defined in that way - which implies ignoring all the others. So, provided you have such a setup (and maybe you are not aware of that) and if you did not enter explicit configuration for the new servers it might lead to what you saw. If you have configs for the new systems, this point is also moot.
Another possibility crossed my mind: if you have a firewall between you and the client it might block some of the traffic. This is rather unlikely after what you said as you come across pretty sure the server itself doesn't answer but again: i try to come up with ideas, you have to test them.
You are welcome. If - once you found the solution - tell us what it was and how you resolved to problem we all have learned something and we have to in fact thank you for making us wiser.
I couldnt get the OS version yet. DHCP server is administrated by somebody else. I will update it soon.
DHCP Server 4.1.1-P1
I mentioned before that I was going to copy the /etc/dhcpd.conf to /etc/dhcp/dhcpd.conf
I did that and restarted the service.
Now I started to receive a new kind of error and the service doesnt start. How it was working before with /etc/dhcpd.conf is still something I have no idea.
Mar 7 16:19:30 trber dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1
Mar 7 16:19:30 trber dhcpd: Copyright 2004-2010 Internet Systems Consortium.
Mar 7 16:19:30 trber dhcpd: All rights reserved.
Mar 7 16:19:30 trber dhcpd: For info, please visit .......
Mar 7 16:19:30 trber dhcpd: WARNING: Host declarations are global. They are not limited to the scope you declared them in.
Mar 7 16:19:30 trber dhcpd: Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file
Mar 7 16:19:30 trber dhcpd: Wrote 0 deleted host decls to leases file.
Mar 7 16:19:30 trber dhcpd: Wrote 0 new dynamic host decls to leases file.
Mar 7 16:19:30 trber dhcpd: Wrote 0 leases to leases file.
Mar 7 16:19:30 trber dhcpd:
Mar 7 16:19:30 trber dhcpd: No subnet declaration for eth0 (10.210.148.7).
Mar 7 16:19:30 trber dhcpd: ** Ignoring requests on eth0. If this is not what
Mar 7 16:19:30 trber dhcpd: you want, please write a subnet declaration
Mar 7 16:19:30 trber dhcpd: in your dhcpd.conf file for the network segment
Mar 7 16:19:30 trber dhcpd: to which interface eth0 is attached. **
Mar 7 16:19:30 trber dhcpd:
Mar 7 16:19:30 trber dhcpd:
Mar 7 16:19:30 trber dhcpd: Not configured to listen on any interfaces!
Mar 7 16:19:30 trber dhcpd:
Mar 7 16:19:30 trber dhcpd: This version of ISC DHCP is based on the release available
Mar 7 16:19:30 trber dhcpd: on ftp.isc.org. Features have been added and other changes
Mar 7 16:19:30 trber dhcpd: have been made to the base software release in order to make
Mar 7 16:19:30 trber dhcpd: it work better with this distribution.
Mar 7 16:19:30 trber dhcpd:
Mar 7 16:19:30 trber dhcpd: Please report for this software via the Red Hat Bugzilla site:
Mar 7 16:19:30 trber dhcpd: ......
Mar 7 16:19:30 trber dhcpd:
Mar 7 16:19:30 trber dhcpd: exiting.
Without being able to substantially contribute as my dhcpd days are long gone, I stumble over the obvious discrepancies between eth0 IP (10.210.148.7) and DHCP subnet (172.17.126.192) definition. There must be a router between the two, and bakunin's comment in post #2 becomes noteworthy. Worthwhile digging deeper?
Mar 7 09:05:04 trber dhcpd: DHCPDISCOVER from XX:XX:XX:XX:45:06 via 172.17.126.195: unknown network segment
Mar 7 09:05:04 trber dhcpd: DHCPDISCOVER from XX:XX:XX:XX:45:06 via 172.17.126.194: unknown network segment
Before I was receiving those DISCOVER messages from the interface.
The DHCP broadcast from the client is relayed to 10.210.148.7 .
Requests were received however the dhcp server was not offering an IP while I added the required config into /etc/dhcpd.conf
As this modification did not help, I copied the modified /etc/dhcpd.conf to /etc/dhcp/dhcpd.conf. But now, the process does not go up and give the "no subnet decleration" failure.
The error happening here is clear. These are the relevant log lines:
Mar 7 16:19:30 trber dhcpd: No subnet declaration for eth0 (10.210.148.7).
Mar 7 16:19:30 trber dhcpd: ** Ignoring requests on eth0...
Mar 7 16:19:30 trber dhcpd: Not configured to listen on any interfaces!
Mar 7 16:19:30 trber dhcpd: exiting.
This message means the local system has the given ip at the given interface. But there is no subnet declaration for that. The subnet declaration in your dhcpd.conf is:
subnet 172.17.126.192 netmask 255.255.255.224
The both does not match. You probably need to add a correct subnet declaration for the same net as the IP 10.210.148.7 is in. But you should not do that without knowing exactly what you are doing and what ip address range may be allowed and dedicated for that. Otherwise you'll disturb network operation in your network by probably causing ip address conflicts with static assigned ip addresses which are the same as in your subnet declaration.
---
Another Guess:
Maybe this is not the dhcp server which is serving the ip address of serverX and there is another dhcp-server active? As far as I see this dhcp-service is doing completely nothing because of the line: Mar 7 16:19:30 trber dhcpd: exiting. .
You can check that by reviewing the system log of serverX and look for the ip/mac address of the dhcp-server serving the address.
You can also check with a packet sniffer(tcpdump) what's going on on the network and which ip-address is replying to dhcp-requests.(udp ports 67 & 68).
Is the subnet declaration supposed to be in same network as the IP 10.210.148.7 ? I dont think so. The DISCOVER is received via 172.17.126.195/194 and those IPs are in the defined network declaration in dhcpd.conf. A request is received from a defined network, so there should be an offer for it.
Mar 7 09:05:04 trber dhcpd: DHCPDISCOVER from XX:XX:XX:XX:45:06 via 172.17.126.195: unknown network segment
Mar 7 09:05:04 trber dhcpd: DHCPDISCOVER from XX:XX:XX:XX:45:06 via 172.17.126.194: unknown network segment
In the network, many devices will generate dhcp discover messages and all those messages will be relayed to the same server IP 10.210.148.7. According to the MACs in the received DISCOVER messages the 10.210.148.7 Server will give different IP addresses from different networks to each client.
Currently the subnet for the first MAC was entered in dhcpd.conf. At the end subnets for the others will be added too.
172.17.126.200 for MAC1
172.17.124.200 for MAC2
172.17.120.200 for MAC3
....
I'm not quite sure, but I would assume - according to the log entries - the listening interface should have at least an empty(=no leases) subnet declaration since the server is ignoring the interface and is exiting without one. Better check it yourself in the dhcpd manpage/documentation.
But if the dhcp server is actually getting the relayed dhcp/bootp requests my concern maybe not relevant.
--- Post updated at 02:04 PM ---
Maybe it is an option to run the dhcpd-server in foreground(-d) to check what configuration is active and what is going on. And to be sure the daemon is restarted at configuration changes.
After the subnet decleration is added for the interface which is an entry useless for my solution, the DHCPD is UP and running properly.
DHCP gives OFFER for the incoming relayed requests from different subnets.
I hope the dummy entry for my interface IP does not cause an impact.