DHCP Logic
-
@g-i-jones said in DHCP Logic:
@scottalanmiller Nah, you can set them outside the scope or in the scope. I prefer to put them outside the scope because i like to think i have my own little secret cubbyhole for IP's that no one can take, and I strive for super organization.
Reservation = no one can take.
Being in or out of scope has no bearing on that. If you have a reservation outside of the scope, that makes it part of the scope no matter how you look at it. Maybe you are using a DHCP GUI that says it is not in scope, but it's lying to you. You can't have a reservation outside of scope or the DHCP server can't set the reservation.
-
It's another question but it's debatable if DHCP reservations is a good idea in the first place. In general I would say no.
Better to use static IPs, at least for anything that is important. -
@pete-s said in DHCP Logic:
It's another question but it's debatable of DHCP reservations is a good idea in the first place. In general I would say no.
Better to use static IPs, at least for anything that is important.Static only makes sense if you plan on having that server come up on another network that does not have the reservation in place, and nobody can figure out why it's not reachable through the known IP. Otherwise, what's your reasoning for thinking DHCP reservations is a bad idea? In what ways?
-
@pete-s said in DHCP Logic:
It's another question but it's debatable if DHCP reservations is a good idea in the first place. In general I would say no.
Better to use static IPs, at least for anything that is important.A static IP and a reservation have nothing to do with each other.
For example you can assign a static IP address to your main file server, and while that server is online, it will continually use it. But if it goes offline and a client comes in, that client device could get that static address. When the server comes back online there would be an IP conflict and cause all sorts of issues.
A reservation doesn't mean you can't statically assign. It's literally just keeping that IP address for the MAC address.
-
@dustinb3403 said in DHCP Logic:
@pete-s said in DHCP Logic:
It's another question but it's debatable if DHCP reservations is a good idea in the first place. In general I would say no.
Better to use static IPs, at least for anything that is important.A static IP and a reservation have nothing to do with each other.
For example you can assign a static IP address to your main file server, and while that server is online, it will continually use it. But if it goes offline and a client comes in, that client device could get that static address. When the server comes back online there would be an IP conflict and cause all sorts of issues.
A reservation doesn't mean you can't statically assign. It's literally just keeping that IP address for the MAC address.
You're confusing DHCP reservation with DHCP exclusion. You make a reservation to make the DHCP client MAC address get the same IP, gateway etc info always. You make a DHCP exclusion if you have something not using DHCP occupying an address in the DHCP range.
-
@pete-s said in DHCP Logic:
@dustinb3403 said in DHCP Logic:
@pete-s said in DHCP Logic:
It's another question but it's debatable if DHCP reservations is a good idea in the first place. In general I would say no.
Better to use static IPs, at least for anything that is important.A static IP and a reservation have nothing to do with each other.
For example you can assign a static IP address to your main file server, and while that server is online, it will continually use it. But if it goes offline and a client comes in, that client device could get that static address. When the server comes back online there would be an IP conflict and cause all sorts of issues.
A reservation doesn't mean you can't statically assign. It's literally just keeping that IP address for the MAC address.
You're confusing DHCP reservation with DHCP exclusion. You make a reservation to make the DHCP client MAC address get the same IP, gateway etc info always. You make a DHCP exclusion if you have something not using DHCP occupying an address in the DHCP range.
No, Dustin is spot on.
-
@pete-s said in DHCP Logic:
It's another question but it's debatable if DHCP reservations is a good idea in the first place. In general I would say no.
Better to use static IPs, at least for anything that is important.I lean the other way, but it's mostly a preference thing. We use true static for things like routers, switches, and AD servers. I prefer reservations for basically everything else.
-
@obsolesce said in DHCP Logic:
@pete-s said in DHCP Logic:
It's another question but it's debatable of DHCP reservations is a good idea in the first place. In general I would say no.
Better to use static IPs, at least for anything that is important.Static only makes sense if you plan on having that server come up on another network that does not have the reservation in place, and nobody can figure out why it's not reachable through the known IP. Otherwise, what's your reasoning for thinking DHCP reservations is a bad idea? In what ways?
It's bad because you are dependent on the DHCP server to assign an address. So every server, VM whatever that get their DHCP reservation will fail if the DHCP server doesn't work. Basically the DHCP server becomes a single point of failure for a bunch of servers. Something you will find out after a power failure.
I think it's also bad practice to mix "clients" and "servers" in the same subnet, which is typically what has been done when you see DHCP reservations in use.
-
I like the idea of reservations because in theory everything could be managed and organized from the DHCP server. That being said, I have not really used reservations for this purpose yet, too many other things on my plate.
-
@pete-s said in DHCP Logic:
@obsolesce said in DHCP Logic:
@pete-s said in DHCP Logic:
It's another question but it's debatable of DHCP reservations is a good idea in the first place. In general I would say no.
Better to use static IPs, at least for anything that is important.Static only makes sense if you plan on having that server come up on another network that does not have the reservation in place, and nobody can figure out why it's not reachable through the known IP. Otherwise, what's your reasoning for thinking DHCP reservations is a bad idea? In what ways?
It's bad because you are dependent on the DHCP server to assign an address. So every server, VM whatever that get their DHCP reservation will fail if the DHCP server doesn't work. Basically the DHCP server becomes a single point of failure for a bunch of servers. Something you will find out after a power failure.
I think it's also bad practice to mix "clients" and "servers" in the same subnet, which is typically what has been done when you see DHCP reservations in use.
If there's a power failure, nothing will need an IP as they'll be turned off. When the power comes back on, the DHCP server comes up first (yes, the host is static, as well as DC like Scott mentioned).
If the DHCP server has some random failure, it's no issue at all, everything will keep using it's currently assigned address. It's not the issue you seem to think it is.
We have a separate subnet for servers and users, no issues there.
-
@obsolesce said in DHCP Logic:
@pete-s said in DHCP Logic:
@obsolesce said in DHCP Logic:
@pete-s said in DHCP Logic:
It's another question but it's debatable of DHCP reservations is a good idea in the first place. In general I would say no.
Better to use static IPs, at least for anything that is important.Static only makes sense if you plan on having that server come up on another network that does not have the reservation in place, and nobody can figure out why it's not reachable through the known IP. Otherwise, what's your reasoning for thinking DHCP reservations is a bad idea? In what ways?
It's bad because you are dependent on the DHCP server to assign an address. So every server, VM whatever that get their DHCP reservation will fail if the DHCP server doesn't work. Basically the DHCP server becomes a single point of failure for a bunch of servers. Something you will find out after a power failure.
I think it's also bad practice to mix "clients" and "servers" in the same subnet, which is typically what has been done when you see DHCP reservations in use.
If there's a power failure, nothing will need an IP as they'll be turned off. When the power comes back on, the DHCP server comes up first (yes, the host is static, as well as DC like Scott mentioned).
If the DHCP server has some random failure, it's no issue at all, everything will keep using it's currently assigned address. It's not the issue you seem to think it is.
We have a separate subnet for servers and users, no issues there.
If the DHCP server doesn't come up after power failure, the rest of the servers booting up will not use their last given ip address if that is what you think. They will not have an IP address at all.
-
@pete-s said in DHCP Logic:
@obsolesce said in DHCP Logic:
@pete-s said in DHCP Logic:
@obsolesce said in DHCP Logic:
@pete-s said in DHCP Logic:
It's another question but it's debatable of DHCP reservations is a good idea in the first place. In general I would say no.
Better to use static IPs, at least for anything that is important.Static only makes sense if you plan on having that server come up on another network that does not have the reservation in place, and nobody can figure out why it's not reachable through the known IP. Otherwise, what's your reasoning for thinking DHCP reservations is a bad idea? In what ways?
It's bad because you are dependent on the DHCP server to assign an address. So every server, VM whatever that get their DHCP reservation will fail if the DHCP server doesn't work. Basically the DHCP server becomes a single point of failure for a bunch of servers. Something you will find out after a power failure.
I think it's also bad practice to mix "clients" and "servers" in the same subnet, which is typically what has been done when you see DHCP reservations in use.
If there's a power failure, nothing will need an IP as they'll be turned off. When the power comes back on, the DHCP server comes up first (yes, the host is static, as well as DC like Scott mentioned).
If the DHCP server has some random failure, it's no issue at all, everything will keep using it's currently assigned address. It's not the issue you seem to think it is.
We have a separate subnet for servers and users, no issues there.
If the DHCP server doesn't come up after power failure, the rest of the servers booting up will not use their last given ip address if that is what you think. They will not have an IP address at all.
Same for desktops, phones, etc. DHCP is cheap and easy to make redundant. If it fails, you typically dont' care if the email server comes up or not, your network is down anyway.
-
@pete-s said in DHCP Logic:
If the DHCP server doesn't come up after power failure, the rest of the servers booting up will not use their last given ip address if that is what you think. They will not have an IP address at all.
Is that really a concern though. If your entire business infrastructure is offline due to a power outage, aren't there bigger items to address?
Like why in the hell did we lose power?!
Reservations would provide the same IP's to their respective clients once the DHCP server came up. Statically assigned on top of that would mean you don't even need the DHCP server. So long as the network itself is functional.
-
@donahue said in DHCP Logic:
I like the idea of reservations because in theory everything could be managed and organized from the DHCP server. That being said, I have not really used reservations for this purpose yet, too many other things on my plate.
That is another problem. It means that if you are replacing server hardware or a NIC you also have to have access and redo the dhcp reservation since you have new mac addresses.
-
@pete-s said in DHCP Logic:
@donahue said in DHCP Logic:
I like the idea of reservations because in theory everything could be managed and organized from the DHCP server. That being said, I have not really used reservations for this purpose yet, too many other things on my plate.
That is another problem. It means that if you are replacing server hardware or a NIC you also have to have access and redo the dhcp reservation since you have new mac addresses.
Why would you need a new mac address? You can easily change mac addresses on VM's all day long.
-
@pete-s said in DHCP Logic:
@donahue said in DHCP Logic:
I like the idea of reservations because in theory everything could be managed and organized from the DHCP server. That being said, I have not really used reservations for this purpose yet, too many other things on my plate.
That is another problem. It means that if you are replacing server hardware or a NIC you also have to have access and redo the dhcp reservation since you have new mac addresses.
Versus what? Redoing the static IP settings anyways? I'll rather re-enter a MAC than dick around in Windows network settings.
-
@obsolesce said in DHCP Logic:
@pete-s said in DHCP Logic:
@donahue said in DHCP Logic:
I like the idea of reservations because in theory everything could be managed and organized from the DHCP server. That being said, I have not really used reservations for this purpose yet, too many other things on my plate.
That is another problem. It means that if you are replacing server hardware or a NIC you also have to have access and redo the dhcp reservation since you have new mac addresses.
Versus what? Redoing the static IP settings anyways? I'll rather re-enter a MAC than dick around in Windows network settings.
Yeah, this would make sense if you had only a handful of clients that needed to be statically assigned. Nothing needs to be statically assigned. So long as your DHCP server is functional.
-
And this loops back to, if you lose your DHCP server (and nothing is statically assigned) why not have a redundant DHCP server?
Or restore from backup.
Lots of reasons to really question the whole argument.
-
It comes down to there being so many benefits to using DHCP reservations in most cases, versus a bunch of made up scenarios not to, that do not matter at all. This feels like the virtualize vs not virtualize servers discussion.
-
@obsolesce said in DHCP Logic:
This feels like the virtualize vs not virtualize servers discussion.
^ this.
