DHCP Reservations not working?
-
unrelated to your problem but:
The DHCP server is using the full 10.0.0.0/8 range
you need more then 16million ip's in the same broadcast range ?
-
unrelated to your problem but:
The DHCP server is using the full 10.0.0.0/8 range
you need more then 16million ip's in the same broadcast range ?
Why limit yourself unnecessarily? (Also, considering my wife has given me the go-ahead to take over the whole basement as a server room… maybe?)
-
"Why limit yourself unnecessarily?"
Because it is MORONIC to think you could ever in bajillion years need that many addresses..
And it makes you look completely foolish to use such addressing on a local network.. And trying to put even a small fraction of that space on the same broadcast domain would never work anyway..
Why don't you actually use a realistic mask on your interface.. If you feel you might get crazy with devices - hey use a /23 vs /24 – do you think you could fill your basement with 500+ devices using IP?
Once you have a realistic mask set, lets see how your dhcp works.. Also why not just sniff and see what is happening..
-
Alright, lets limit ourselves.
I rerouted a vast majority of our network away from this machine, so this is just the test workstations now.
I dropped the range to a class D.
I dropped and refreshed the ip config on the windows test box.
I'm getting the same results.
(This machine is going to be servicing a lot more than my house, that was a joke, but hey…)
-
I don't care if going to serve your whole freaking city… You would never use a /8 for single segment.. You might use it in a summary route.. But its not something you put on an interface.. Because you could never expect to have anywhere even remotely close to that on the same network.
Nobody uses classes to state networks anymore.. class D?? So you put a multicast address on your interface now??
-
Reimaged the box to 2.2.6, setup configuration identically, worked flawlessly.
I'll just stick there until this has been tested more.
-
Reimaged the box to 2.2.6, setup configuration identically, worked flawlessly.
I'll just stick there until this has been tested more.
i just added some fixed ip's to my lan's dhcpd. it worked as expected.
without further debugging on your end, it'll be difficult to find out what goes wrong. If (for whatever reason) nobody can replicate this, then its unlikely to get fixed. -
Reimaged the box to 2.2.6, setup configuration identically, worked flawlessly.
I'll just stick there until this has been tested more.
i just added some fixed ip's to my lan's dhcpd. it worked as expected.
without further debugging on your end, it'll be difficult to find out what goes wrong. If (for whatever reason) nobody can replicate this, then its unlikely to get fixed.I'll spin up a VM and play with it once my project is complete, see if I can discover the root cause.
Thank you for your assistance.
-
I just came to the forum looking for someone else with the same problem. There's a major problem with DHCP reservations, indeed!
-
I just came to the forum looking for someone else with the same problem. There's a major problem with DHCP reservations, indeed!
ok. post screenshots of the configuration & packet-captures when a clients asks/receives a lease
-
Running latest 2.3
2.3-RC (amd64)
built on Sun Apr 03 14:24:26 CDT 2016On esxi 6u2
My boxes don't seem to be having any issues with reservations..
I just deleted my reservation, got a new ip in my pool 192.168.9.225… I then created a reservation for .100, released and renewed my lease on the client and big bang zoom got my 192.168.9.100 as I had setup.. As the correct domain, everything..
If you say your not even getting the correct domain - sure you don't just have another dhcp server running on your network..
-
Everything here works fine. Sounds like the usual expecting a client renewing its existing lease to not have that lease renewed. That's not how dhcpd functions, if a machine asks for its existing lease to be renewed, it'll be renewed. A release and renew on the client will obtain its reservation.
-
unrelated to your problem but:
The DHCP server is using the full 10.0.0.0/8 range
you need more then 16million ip's in the same broadcast range ?
Why limit yourself unnecessarily?
Tell the truth I set my network mask to /8 as well, felt having no limits "EVER, lol" was the way to go. After all I plan on running multi WAN and hosting, but 16 million is a bit excessive lol. But I am running 2.3 in Proxmox-VE and no DHCP issues at all.
-
The main reason not to do it is address space collisions. If you set up a VPN into your network, it'll be broken from any location using 10/8, 10.x/16 and 10.x.x/24. That's a LOT of places.
But other than that it really doesn't matter what the subnet size is in a broadcast domain. It only matters how many actual hosts are on it.
(No DHCP issues here either.)
-
The main reason not to do it is address space collisions. If you set up a VPN into your network, it'll be broken from any location using 10/8, 10.x/16 and 10.x.x/24. That's a LOT of places.
But other than that it really doesn't matter what the subnet size is in a broadcast domain. It only matters how many actual hosts are on it.
(No DHCP issues here either.)
Wait so if my home is 10.0.0.1/8 and work is the same VPN wont work?
-
Not without Herculean effort and much added complication.
-
Yep - if home is 10.0.0.1/8 (LAN IP) and thus all your home devices are in 10.0.0.0/8 somewhere, then when they want to send to anything else with a "10" address they will deduce that the target system (e.g. at 10.20.30.40) lies in the same subnet. So the home device will just do ARP locally to try and find the target system. pfSense (or any router) won't even get a chance to see anything.
If you are VPNing to work directly from a VPN client on a home device, then you might get lucky if it gives itself a route through the VPN to the work subset of "10" (e.g. 10.20.30.0/24) and then the local device network stack works out to send stuff in 10.20.30.0/24 across the VPN, even though it is part of the local LAN also. But of course if you have an actual device on your LAN at 10.20.30.40 then you can never get to both!
You are much better off choosing a "random" bit of private address space, of the size you reasonably need, so as to minimize the chance of a conflict if you have incoming or outgoing VPN links to/from pfSense or local client laptops…
-
Yep - if home is 10.0.0.1/8 (LAN IP) and thus all your home devices are in 10.0.0.0/8 somewhere, then when they want to send to anything else with a "10" address they will deduce that the target system (e.g. at 10.20.30.40) lies in the same subnet. So the home device will just do ARP locally to try and find the target system. pfSense (or any router) won't even get a chance to see anything.
If you are VPNing to work directly from a VPN client on a home device, then you might get lucky if it gives itself a route through the VPN to the work subset of "10" (e.g. 10.20.30.0/24) and then the local device network stack works out to send stuff in 10.20.30.0/24 across the VPN, even though it is part of the local LAN also. But of course if you have an actual device on your LAN at 10.20.30.40 then you can never get to both!
You are much better off choosing a "random" bit of private address space, of the size you reasonably need, so as to minimize the chance of a conflict if you have incoming or outgoing VPN links to/from pfSense or local client laptops…
Well Thank You! I have not tried a VPN yet but used XRDP plenty and that worked fine, still a novice on VPN's and VLAN's tell the truth. But learning new stuff everyday. Who said you can't teach an old dog huh?? lol. Thank you for the advice guys. Back on topic now, (But Thank you, very much)
-
"It only matters how many actual hosts are on it."
Agreed, but come on - using a /8 on any interface anywhere is just nonsense… You for sure could never actually put that many hosts on the same broadcast domain and expect it to work.
And yup for sure its most likely going to cause problems if you try and vpn.. No matter how you look at it is not a realistic mask to place on an interface anywhere..
-
Just to get this back on the topic of DHCP reservations… I've not had any issues with DHCP reservations functioning. I have at least 12 of them set on my home network and all work just fine.
I even tried DHCPv6 reservations for a bit and those work too.