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

    Can't make static lease within range?

    DHCP and DNS
    6
    13
    7.3k
    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.
    • R
      r5a
      last edited by

      Using
      2.0.1-RELEASE (i386)
      built on Mon Dec 12 17:53:52 EST 2011

      It seems I am not able to make a static reservation with an IP thats in the DHCP range?

      That seems a little weird. Almost any other DHCP server I've used lets me do that.

      Doesn't really make much sense to do that either.

      1 Reply Last reply Reply Quote 0
      • P
        podilarius
        last edited by

        Well … other DHCP servers do allow this, but iirc, they are not supposed to. Just shorten your range a bit so that you can make the reservations you want.

        1 Reply Last reply Reply Quote 0
        • M
          Metu69salemi
          last edited by

          There was also "hack" mentioned on this forum. use google search to find it

          1 Reply Last reply Reply Quote 0
          • R
            r5a
            last edited by

            So I see the reasons behind from reading a few threads.

            Times have changed. If you make a static reservation for something on any newer device (I can vouch for these, Windows DHCP, SonicWall, Watchguard, NetGear, D-Link & Linksys) that IP will NOT be assigned to anything but that programmed MAC. Regardless if it's on or not. If the machine is off, no device can take that IP (unless you spoof the mac)

            What happens is that it will take the next IP above it, for example

            range: .100 - .120
            ips: .100 - .105 in use
            .106 is static reserved - but machine is off
            new user comes in and is assigned .107 since .106 is considered taken

            even in windows dhcp you will see inactive/active depending on if the machine the static mapping belonged too is on or off.

            in real world scenarios where this is common some users machines will be assigned in the middle of near the end of the scope, we assign them that static IP and then program a port forward for their service (typically RDP) with it is now I would have to rework the entire scope to accommodate one user - in certain setups .2-.254 is dhcpd)

            1 Reply Last reply Reply Quote 0
            • P
              podilarius
              last edited by

              It not a bad rework … set the range to .3 -.254 and give the reservation .2 and then assign from there (use a release/renew to get the new IP). And then go on from there. Also I don't use that wide of a scope. I usually save 10 for reservations and 10 for servers or other statics (network admin PCs and such, troubleshooting). If I need to go more than that I would use a /23 network to have 2 times the range so I can accommodate the DHCP range I need along with the statics and reservation I might need.
              It is frustrating, but not unmanageable.

              1 Reply Last reply Reply Quote 0
              • N
                NOYB
                last edited by

                Yup.  Adhering to a standard just for the sake of the standard when there is a more desirable de facto standard (what nearly everyone else is implementing) is senseless.

                http://en.wikipedia.org/wiki/De_facto_standard

                Maybe someone should add an "Official or De Facto Standard Adherence" option.

                1 Reply Last reply Reply Quote 0
                • D
                  dhatz
                  last edited by

                  @NOYB:

                  Yup.  Adhering to a standard just for the sake of the standard when there is a more desirable de facto standard (what nearly everyone else is implementing) is senseless.

                  I understand that this limitation is due to the behavior of the underlying software, i.e. ISC dhcpd … it's not by choice and it's not as simple as removing the bounds check in php code.

                  But perhaps one should check if ISC dhcpd still has this limitation, or has added this feature in recent versions.

                  1 Reply Last reply Reply Quote 0
                  • N
                    NOYB
                    last edited by

                    @dhatz:

                    @NOYB:

                    Yup.  Adhering to a standard just for the sake of the standard when there is a more desirable de facto standard (what nearly everyone else is implementing) is senseless.

                    I understand that this limitation is due to the behavior of the underlying software, i.e. ISC dhcpd … it's not by choice and it's not as simple as removing the bounds check in php code.

                    But perhaps one should check if ISC dhcpd still has this limitation, or has added this feature in recent versions.

                    Don't know where the enforcement is taking place but they should relax a little.  ;)

                    1 Reply Last reply Reply Quote 0
                    • C
                      cmb
                      last edited by

                      Wrong place to complain, we have nothing to do with dhcpd, just are enforcing sane practices with it. Take it to ISC.

                      http://doc.pfsense.org/index.php/Why_can't_I_have_static_mappings_inside_my_DHCP_range%3F

                      1 Reply Last reply Reply Quote 0
                      • N
                        NOYB
                        last edited by

                        Complaining to ISC wouldn’t help either.  Even if they made the change, by the time pfSense upgraded to a version of FreeBSD that used it, IPv6 would be a distant footnote in internet history.  ;)

                        1 Reply Last reply Reply Quote 0
                        • D
                          dhatz
                          last edited by

                          What about the infinite-is-reserved directive?

                          infinite-is-reserved flag;

                          ISC DHCP now supports 'reserved' leases.  See the  sec-
                                             tion on RESERVED LEASES below.  If this flag is on, the
                                             server will automatically reserve leases  allocated  to
                                             clients which requested an infinite (0xffffffff) lease-
                                             time.

                          The default is off.

                          https://lists.isc.org/pipermail/dhcp-users/2007-January/002723.html

                          1 Reply Last reply Reply Quote 0
                          • C
                            cmb
                            last edited by

                            @dhatz:

                            What about the infinite-is-reserved directive?

                            AFAIK the clients must request an indefinite lease, which isn't related.

                            1 Reply Last reply Reply Quote 0
                            • D
                              dhatz
                              last edited by

                              @NOYB:

                              Complaining to ISC wouldn’t help either.  Even if they made the change, by the time pfSense upgraded to a version of FreeBSD that used it, IPv6 would be a distant footnote in internet history.   ;)

                              LOL, funny but not entirely accurate. Actually just in the past few months pfSense has upgraded several packages (e.g. the above mentioned ISC dhcpd, or lighttpd) to their very latest stable version, mostly to address vulnerability issues.

                              Anyway, I know what you meant, but it's a direct consequence of the development model. Unless someone is willing to fund a certain pfSense feature, it might take years before it's implemented (just look at how long it took for the Snort package).

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.