What's new

IP lease-time best practices

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

ddaenen1

Very Senior Member
I have googled and read alot about it but there seems to be no alignment in the recommendations so i am turning my question to the forum:

I have had issues with my switch because the 24h lease renewal. Changed that over from 24 hours to 30 days fixed the problem permanently.

I was thinking the following policy:

- Fixed devices (access points, switches, PV inverter, servers, UPS) hard wired to the switch and always on - 14 days
- Fixed devices (Thermostat, fireplace wifi interface,...) wireless connected and always on - 14 days
- Fixed devices (desktop, Smart TV) hard wired, not always on - 24 hours
- Fixed devices (wifi printer, Wii U,..) wireless connected, not always on - 24 hours
- Mobile devices (phones, tablets, smart watches, Nintendo Switch,..) wireles connected, not always on - 12 hours

Thoughts, suggestions?

Dominique
 
Thought process is good. Problem is in the implementation.

Using Merlin's firmware on an ASUS router just allows you to specify a single lease time from the GUI. I use five days as normally the only devices connecting are devices I have assigned a static IP to that connect regularly to my LAN. The occasional guest that connects also gets a long lease but my pool size is 20 so I have never had an issue of running out of available IPs.

With tomato firmware you have an option for both static IPs assigned by the router and another for leases assigned from within the pool. With my tomato based router I assign short leases of 300 minutes for devices assigned from the pool and longer leases for static IPs.

To do what you want is going to require writing a script. Perhaps someone else on this forum can give you the basic framework for a script to start with.
 
Thought process is good. Problem is in the implementation.

Using Merlin's firmware on an ASUS router just allows you to specify a single lease time from the GUI. I use five days as normally the only devices connecting are devices I have assigned a static IP to that connect regularly to my LAN. The occasional guest that connects also gets a long lease but my pool size is 20 so I have never had an issue of running out of available IPs.

With tomato firmware you have an option for both static IPs assigned by the router and another for leases assigned from within the pool. With my tomato based router I assign short leases of 300 minutes for devices assigned from the pool and longer leases for static IPs.

To do what you want is going to require writing a script. Perhaps someone else on this forum can give you the basic framework for a script to start with.

I am not running an Asus router. I am running a Mikrotik RB3011. You can define lease time for every single DHCP connection. And all fixed devices are configured with a reserved IP within the DHCP pool.
 
You shouldn't need any "policy" for DHCP leases in a typical home setup. Provided you don't set it to something ridiculously small and you haven't misconfigured your network it shouldn't matter. If you have a problem with a particular client then that is a client issue not a DHCP issue.
 
DHCP lease time should have no impact on DHCP. The only thing I can think of if you are running out of CPU. I run DHCP out of my L3 switch so it definitely has no impact on my router.

Try running a different DHCP server as it will offload your router and see if it helps.

I have all my VLANs set to full class C IP address pools, so I do not need to recycle IPs.
 
I have had issues with my switch because the 24h lease renewal.
Can you be more specific about the "issue"? As others have pointed out, DHCP lease time should have little or no effect on most home networks. Basically, it just controls when the devices will request a renewal on their IP.

Providing details as to your actual issue may allow us to provide a better answer.
 
In general, it makes no difference.

If you have devices that "travel" outside your network, then it is slightly more secure to have short lease times. For static, wired devices, it makes no difference unless you have hundreds or thousands of systems. Setting a lease time of 1 hour vs 1 year will have no appreciable impact on a small home network.

IIRC at about 1/2 the lease time, the clients says to the server "is this IP still ok?" and the server responds "yes" or issues a new IP. That's it. If the server hasn't received a renewal request at the lease expiry, it simply drops it from the "in use" reserved list in memory and makes the IP available in the pool for other devices.

That is why the op needs to clarify the REAL original issue.
 
Can you be more specific about the "issue"? As others have pointed out, DHCP lease time should have little or no effect on most home networks. Basically, it just controls when the devices will request a renewal on their IP.

Providing details as to your actual issue may allow us to provide a better answer.

The issue with the switch was that it lost it's internet connection so NTP servers couldn't be accessed among other things that need the switch to be able to access the internet. Going from a 24h to a 30 day lease fixed this permanently. For the rest i have no other issues with my current config. It was merely an idea to optimize the system and as already stated, flush IP's from visitors faster.
 
Going from a 24h to a 30 day lease fixed this permanently.
I think there’s collective confusion on our part how this fixed it permanently. Have 30 days elapsed so you know for sure it won’t happen again at the next hard expiration date (even though dhcp renews at the halfway point of 15 days)?
 
The issue with the switch was that it lost it's internet connection so NTP servers couldn't be accessed among other things that need the switch to be able to access the internet. Going from a 24h to a 30 day lease fixed this permanently. For the rest i have no other issues with my current config. It was merely an idea to optimize the system and as already stated, flush IP's from visitors faster.

This makes no sense. It is unrelated to DHCP server.
 
This makes no sense. It is unrelated to DHCP server.
Agreed.
The issue with the switch was that it lost it's internet connection so NTP servers couldn't be accessed among other things that need the switch to be able to access the internet.
There are many reason why the switch may have "lost" internet access. One of the least likely is a DHCP issue. I assume you could still access the switch (to find that the NTP server stopped updating) therefore it still had an IP (presumably the assigned one).

More information is still required to get at the root of your problem. Did you try pinging the default gateway or other devices (if this is possible) from the switch? Did you view its runtime configuration to see what IP, mask and gateway it was trying to use?

The only way I see DHCP being involved is if the router (DHCP server) was rebooted and assigned the IP of the switch to another device. Typically, switches (and similar infrastructure devices) do not use DHCP but use static IPs. A happy middle ground is assigned IP addresses based on MAC handled from the DHCP server.

I'm only pushing the issue as your resolution doesn't really match with the problem so you are likely to run into it again, or it was simply a "one off" issue that you may never encounter again.
 
This makes no sense. It is unrelated to DHCP server.
Well, i do not have any other explanation for it as it happened when the router renewed the DHCP lease for the switch. Not always though, but frequently. Nevertheless, once i changed the lease time for the switch to 30 days, it never happened again and that has been more than 6 months ago.
 
Not to be brash, but just because there is no other explanation for it as far as you're aware, doesn't mean we can presume DHCP is at fault, unless you can demonstrate of course that you've systematically tested for and ruled out all other possibilities. And at layer 3, there can be plenty of them. This is what the others are essentially saying, and I agree.

If this is somehow related to DHCP, one way to at least circumvent the problem is to statically assign IP, netmask, gateway and DNS on the switch. Beyond just this instance, it's often good practice to statically assign your low-level networking gear, so it's always directly available via your main interconnects and not DHCP-dependent.

Also, a static assignment will remove questionable config alteration from happening to the switch on its own, so that you may troubleshoot upstream services and/or routing issues with confidence in knowing your switch config is solid. This will allow you to figure out what is likely the true source of your internet access issue.
 
Last edited:
Not to be brash, but just because there is no other explanation for it as far as you're aware, doesn't mean we can presume DHCP is at fault, unless you can demonstrate of course that you've systematically tested for and ruled out all other possibilities. And at layer 3, there can be plenty of them. This is what the others are essentially saying, and I agree.

Well, for all i know this could have been an issue with the switch that didn't deal well with the daily DHCP release/renew. Since i changed the lease time to 30 days, it never happened again.
 
I do 12 hour leases at home...

DHCP is low overhead.

At the office, I do 2 hour leases, mainly because we have a lot of phones/tablets.
 
The main reason to lower leases duration is if you have a lot of temporary clients, so you don't want these to waste pool entries once they leave your network. That bit me once as my old workshop used a fairly small pool with a fairly long lease, and I was building/configuring about a dozen new PCs for a customer at the moment. I was puzzled when suddenly the systems I was building were unable to access the Internet - until I checked the DHCP server, and realized the pool had simply dried up over the past couple of hours due to all the systems I had been temporarily connecting/disconnecting the past few days.

Otherwise, I generally just leave it to whatever default value the server/router offers.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top