For my home network I have Verizon FiOS which I have directly connected to my CCR2004. No Verizon router required or utilized. Everything works outstanding as far as my IPV4 and IPv6 connectivity is concerned. However, I am seeing a large number of dhcp client “lease stopped locally” messages on ether1_WAN. I have done a packet capture based on a similar thread I found on the forum in which Sindy I believe outlined what filters to use in order to log the DCHP processes as they run. I have done so and, if I have understood the pcap results, am at a loss to explain what is going on. In a number of instances, I can see the discovery request, followed by the ACK from the provider, then the request from the CCR2004 and the ACK from the provider again. Yet, within a small window of time, definitely less than the 2 hour lease time, the “lease stopped locally” message shows again and the router again initiates discovery. I see this back to back in one instance at 1455 and then again at 1503 and then again at 1508 on 25 September, for example. Just doesn’t make sense. I have attached a pcap file (delete the .txt extension), as well as the output of my router log. YES YES YES, I know overzealous mods…my WAN IP is exposed. I could not care less as it is dynamic AND I wasn’t going to sanitize lines and lines of log entries and pcap output. It’s ok. No need to hyperventilate. Very warmly welcome anyone who can help me understand what is happening and why so that I can either put in a bug report with Mikrotik or start bugging Verizon. Chances are, you are smarter than I am and there is something I am missing. Thanks in advance! dhcp.pcap.txt (111 KB) DHCPweirdness.log.txt (78.6 KB)
It’s not hard to work out, is it?
09-22 08:07:51 interface,info ether1_WAN link down
09-22 08:07:51 dhcp,info dhcp-client on ether1_WAN lost IP address 70.106.192.220 - lease stopped locally
Device is given the same IP again though and has had the same one for days now. My understanding of DHCP is that the device should request an IP in advance of the lease expiration at which point it will be either reassigned the old one or given a new one. With the current situation, my device is losing connectivity for a moment so something in the expected DHCP process is not working right as the device should not be losing its WAN IP.
This is something that I have seen with some ISP and mikrotik.
you can run a script every 15mins or whatever to force renew the lease. But this may upset the DHCP server
/ip/dhcp-client renew 0
OR
something like this to check if DHCP Lease is less than 14mins and only then force a renew.
Run this every 5mins or something.
:foreach i in=[/ip/dhcp-client find expires-after < [:totime "14m"]] do={
/ip/dhcp-client renew $i
:log info "DHCP renewed by script (not by DHCP itself)"
}
I appreciate the response and the script. I can certainly try it. However, as I point out in my OP, there are instances of this happening multiple times in succession just a few minutes after a new lease is acquired. Why would my router be reaching out to the DHCP server a mere number of minutes after renewing the IP when the lease is good for 2 hours? This is what makes no sense at all.
Just to close the loop on this. I did a bit more exploring and discovered that someone had previously joined two Cat5e cables with a female to female keystone jack. This cable run is the one that feeds my CCR2004 WAN. I went ahead and turned a trusty Hex into a switch, removed the keystone, and plugged the two individual Cat5e into the Hex. Since doing so, I’ve not had one locally stopped lease event. So, as always boys and girls, poor signal on the cable was the source of my problem. I’m embarrassed it took me this long to figure it out.