• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Dhcp server leases and their behaviour

Scheduled Pinned Locked Moved General pfSense Questions
6 Posts 3 Posters 1.1k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • D
    digiteltlc
    last edited by Jul 29, 2016, 3:25 PM

    I'm experiencing the number of dhcp leases reach the maximum allowed on the range thus no more available for further clients.
    The leases are mostly "offline"
    Default lease time is set to 86400 (perhaps wrong)
    Maximum lease time is blank

    Is there anyone explaining me how dhcp server works with leases and these timers ??
    What are the suggested values ?

    Thank you very much

    1 Reply Last reply Reply Quote 0
    • H
      heper
      last edited by Jul 29, 2016, 8:10 PM

      It's basically what it says.

      Default lease time is what  clients get when they don't request a longer or shorter time

      If you have many devices that only connect for short periods then you can put max at 7200(2h)en default at 3600(1h)

      1 Reply Last reply Reply Quote 0
      • D
        digiteltlc
        last edited by Aug 2, 2016, 6:19 AM

        But, what happens to client side when lease time expires ??
        Let's say I'm using my device and lease time expires, do I loose connectivity while device re-negotiates a new ip address ??
        Or lease expires only when device is inactive ?

        Thank you

        1 Reply Last reply Reply Quote 0
        • H
          heper
          last edited by Aug 2, 2016, 6:36 AM

          Devices apply for a new lease right before the lease expires. (Renew)
          This means there is no connectivity loss.

          1 Reply Last reply Reply Quote 0
          • D
            dotOne
            last edited by Aug 2, 2016, 5:00 PM

            If a client doesn't have an IP address it will send a DHCP discover, this is a broadcast message.
            The server will reply with a 'DHCP offer' this is also a broadcast with an IP address that the client can use.

            The client will then send a 'DHCP request' with the IP address offered by the server. Again this is a broadcast frame since the IP address still isn't comitted to this client.

            As an answer to this request the server can send either a 'DHCP ack' message telling the client that the IP address is committed and the client can use it.
            Or the server can send a 'DHCP nack' denying the requested IP address and then the whole story starts over again.

            If thc client has its IP address it will send a 'DHCP request' to the server to prolong the usage of the current IP address. This happens when half the lease time has expired.
            The server can reply with an ACK, keep using it, or with an Nack, release the IP and start requesting a new address.

            Finally, the client can send a 'DHCP release' message to the server telling the server to release it and he can use it for another client.

            Usually this doesn't happen very often. The client gets powered down and the lease time will expire.
            When the client starts up again it will send a 'DHCP discover' which the server recognizes as coming from the same mac address as before and it will hand out the same IP adress.

            If there is a DHCP forwarder in between the procedure is a bit different on the server and forwarder side. For the client it remains the same.

            Andre

            1 Reply Last reply Reply Quote 0
            • D
              digiteltlc
              last edited by Aug 4, 2016, 2:07 PM

              Thank you both for clarifying  !

              1 Reply Last reply Reply Quote 0
              1 out of 6
              • First post
                1/6
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                This community forum collects and processes your personal information.
                consent.not_received