Environment
Novell Open Enterprise Server 2 (OES 2) Linux
Novell Open Enterprise Server 11 (OES 11) Linux
Novell Open Enterprise Server 11 (OES 11) Linux
Situation
Clients not getting IP addresses from the OES DHCP server.
Looking at the /var/log/messages file shows the DHCP server reporting that it is not authoritative to hand out addresses on the subnet.
In another case the clients may get an IP address but not get configured DHCP Options. See TID 7009129
Looking at the /var/log/messages file shows the DHCP server reporting that it is not authoritative to hand out addresses on the subnet.
In another case the clients may get an IP address but not get configured DHCP Options. See TID 7009129
Resolution
Add the authoritative statement at the top of the /etc/dhcpd.conf
file and restart the dhcp daemon.
The line to add is:
authoritative;
For a non-clustered (NCS) dhcp service, restart the daemon with: rcnovell-dhcpd restart
For a clustered dhcp service, restart the daemon by off-lining and on-lining the clustered resource.
For more information on a clustered dhcp service, please see TID 7011637.
The line to add is:
authoritative;
For a non-clustered (NCS) dhcp service, restart the daemon with: rcnovell-dhcpd restart
For a clustered dhcp service, restart the daemon by off-lining and on-lining the clustered resource.
For more information on a clustered dhcp service, please see TID 7011637.
Additional Information
From the man page for dhcpd.conf:
The authoritative statement
authoritative;
not authoritative;
The DHCP server will normally assume that the configuration information about a given network segment is not known to be correct and is not authoritative. This is so that if a naive user installs a DHCP server not fully understanding how to configure it, it does not send spurious DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the network.
Network administrators setting up authoritative DHCP servers for their networks should always write authoritative; at the top of their configuration file to indicate that the DHCP server should send DHCPNAK messages to misconfigured clients. If this is not done, clients will be unable to get a correct IP address after changing subnets until their old lease has expired, which could take quite a long time.
Usually, writing authoritative; at the top level of the file should be sufficient. However, if a DHCP server is to be set up so that it is aware of some networks for which it is authoritative and some networks for which it is not, it may be more appropriate to declare authority on a per-network-segment basis.
Note that the most specific scope for which the concept of authority makes any sense is the physical network segment - either a shared-network statement or a subnet statement that is not contained within a shared-network statement. It is not meaningful to specify that the server is authoritative for some subnets within a shared network, but not authoritative for others, nor is it meaningful to specify that the server is authoritative for some host declarations and not others.
The authoritative statement
authoritative;
not authoritative;
The DHCP server will normally assume that the configuration information about a given network segment is not known to be correct and is not authoritative. This is so that if a naive user installs a DHCP server not fully understanding how to configure it, it does not send spurious DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the network.
Network administrators setting up authoritative DHCP servers for their networks should always write authoritative; at the top of their configuration file to indicate that the DHCP server should send DHCPNAK messages to misconfigured clients. If this is not done, clients will be unable to get a correct IP address after changing subnets until their old lease has expired, which could take quite a long time.
Usually, writing authoritative; at the top level of the file should be sufficient. However, if a DHCP server is to be set up so that it is aware of some networks for which it is authoritative and some networks for which it is not, it may be more appropriate to declare authority on a per-network-segment basis.
Note that the most specific scope for which the concept of authority makes any sense is the physical network segment - either a shared-network statement or a subnet statement that is not contained within a shared-network statement. It is not meaningful to specify that the server is authoritative for some subnets within a shared network, but not authoritative for others, nor is it meaningful to specify that the server is authoritative for some host declarations and not others.