DHCP server stopped working

[Tuneday]

Dear All,

help from you would be appreciated, I have a Cisco 891 model with ios version c890-universalk9-mz.152-4.M3.bin. everything has been fine until recently it stopped giving out IP address to the host attached to it via a switch.pls note the Router is configure among other things as a DHCP server, had been giving out ip address from its pool to the connected nodes until recently when it suddenly stopped giving out IP. However other services are still running fine, NAT, VPN all working fine save DHCP. anyone experience such before, what could be the cause and remedy. 

[marce1000]

 - Have a look at the logs (show logging) , preferably use a syslog server too, watchout for any error messages concerning DHCP.

M.

[Tuneday]

Thank you marce, would do that and revert

[Richard Burts]

Checking the logs is certainly a good place to start. You might also want to check on the DHCP pool. How big is the pool? How many addresses have been assigned? How many addresses are available for assignment?

It would also be helpful to know if anything has changed recently. Have there been any config changes? Any change in version of software? etc

It might also be helpful if you would post the config of the router so that we can look for potential issues.

HTH

Rick

[Tuneday]

Thank you Richard, I,m sorry ive been offsite for days and have not been able to check the log. However from previous logs, no ip address have been assigned to any host of recent, so all address are still available, infact I had to manually assigned ip address to hosts in the network since they cant obtained ip, the statically assigned ip works without any conflict.. attached is the config file

[Richard Burts]

Thank you for posting the configuration. I do not see anything in it that would explain your symptoms. I would like to know what is in the logs of the router. Since it appears to be using default values for logging the log is probably pretty small. It might be beneficial to configure logging buffer to increase the size of the buffer and to be sure that it is logging at level of debug.

If we do not find much in the log then it might be the next step to enable debug for dhcp and see what that tells us.

I will also observe that masking off octets of addresses in 10.x.x.x and in 192.168.x.x seems a bit of over kill. These are private addresses. They are not routable over the Internet and so I do not see how it benefits your network security to hide which of those private addresses you are using.

HTH

Rick

[Tuneday]

Thanks Richard for the quick response, sorry for the masking of my private ip, they,re actually full classful subnet /24 for the 192.168.7.0 and /30 for 10. subnet. I can resend if need be.

No any configuration change has been effected before the problem start.

I,ll do as you suggest for the logging, and post same once I get back to base..

Thanks for the attention.

[Richard Burts]

Thanks for the additional information. No need to resend. In this case hiding those details did not impact our understanding of the issue. There have been some discussions in the community where people did hide details that did turn out to be important. I wanted to make the point so that you (and other participants in the community) for the next time that you create a new post will think about what makes sense to hide and what does not make sense to hide.

I will be interested to find what you learn from logs or from debug.

HTH

Rick

[Tuneday]

Morning Richard, Marcee  and everyone. ive issued show logging on the router, the log output is attached herewith.

[Tuneday]

this log is better than former as it shows dhcp server event, I got this log after enabling debug dhcp server.. the new log has been attached.

[Tuneday]

Here is debug log of another client request from the same router

DHCPREQUEST received from client 0100.238b.9e88.38.
*Feb 6 10:06:37.887: DHCPD: Sending notification of ASSIGNMENT:
*Feb 6 10:06:37.887: DHCPD: address 192.168.7.40 mask 255.255.255.0
*Feb 6 10:06:37.887: DHCPD: htype 1 chaddr 0023.8b9e.8838
*Feb 6 10:06:37.887: DHCPD: Using hostname 'CONLFAC002.abcd.net' for dynamic update (from FQDN option)
*Feb 6 10:06:37.887: DHCPD: Sending DHCPACK to client 0100.238b.9e88.38 (192.168.7.40).
*Feb 6 10:06:37.887: DHCPD: client's VPN is .
*Feb 6 10:06:37.887: DHCPD: No option 125
*Feb 6 10:06:37.887: DHCPD: DHCPREQUEST received from client 0100.238b.9e88.38.
*Feb 6 10:06:37.887: DHCPD: Sending notification of ASSIGNMENT:
*Feb 6 10:06:37.887: DHCPD: address 192.168.7.40 mask 255.255.255.0
*Feb 6 10:06:37.887: DHCPD: htype 1 chaddr 0023.8b9e.8838
*Feb 6 10:06:37.887: DHCPD: Using hostname 'CONLFAC002.abcd.net' for dynamic update (from FQDN option)
*Feb 6 10:06:37.887: DHCPD: Sending DHCPACK to client 0100.238b.9e88.38 (192.168.7.40).
*Feb 6 10:06:39.191: DHCPD: client's VPN is .
*Feb 6 10:06:39.191: DHCPD: No option 125
*Feb 6 10:06:39.191: DHCPD: Sending notification of DISCOVER:
*Feb 6 10:06:39.191: DHCPD: htype 1 chaddr 0800.2706.417b
*Feb 6 10:06:39.191: DHCPD: remote id 020a0000c0a8070100000001
*Feb 6 10:06:39.191: DHCPD: circuit id 00000000
*Feb 6 10:06:39.191: DHCPD: DHCPDISCOVER received from client 0800.2706.417b on interface Vlan1.
*Feb 6 10:06:39.191: DHCPD: Seeing if there is an internally specified pool class:
*Feb 6 10:06:39.191: DHCPD: htype 1 chaddr 0800.2706.417b
*Feb 6 10:06:39.191: DHCPD: remote id 020a0000c0a8070100000001
*Feb 6 10:06:39.191: DHCPD: circuit id 00000000

[Richard Burts]

Thank you for the log output. At this point I am focused on this message which appears multiple times in both logs that contain DHCP debug output

*Feb 6 10:06:39.191: DHCPD: client's VPN is .

I am puzzled about this and do not see anything in the posted config that associates vpn with DHCP. But I wonder if this is an issue and is related to a message in the first set of log messages that mentions an SSL VPN license expiration.

There is also this message

*Feb 6 10:06:37.887: DHCPD: No option 125

I do not see anything in the config that would seem to relate to this.

HTH

Rick

[Tuneday · Accepted solution]

Thank you Richard, eventually I've been able to resolve it, your comments and advise are so instrumental in the solution. After running the show logging and enabling debugging, I also show clock, I found out the router date has jumped to 2035 and time incorrect, after setting correct time and date, and removing and recreating the dhcp pool it was resolved. Once again thank You.

[Richard Burts]

Thanks for the update. I am glad to know that you have resolved the issue. And I am quite surprised that the issue turned out to be incorrect setting of clock. I am glad that my suggestions helped point you in the right direction. Congratulations on finding the solution.

HTH

Rick

[Tuneday]

Thank you Marce, I did all you suggest, and go a bit further, it's now resolved. Thank you.