DHCP Logic
-
@scottalanmiller said in DHCP Logic:
@g-i-jones said in DHCP Logic:
Anyway, he said even if there is a reservation, if that thing goes to sleep, then other things can still snatch up that IP address because it's in the pool.
That makes no sense at all. He's thinking of DHCP Preferences, not related to Reservations. The entire concept of a reservation doesn't mesh with this definition at all.
Imagine if you had a restaurant reservation that only worked if you were already at the restaurant waiting. No need for a reservation if you are already there and have the table, right? Completely nonsensical.
Reminds me of Seinfeld and his car reservation
-
@dustinb3403 said in DHCP Logic:
While it is bad practice to create a reservation within the scope, there are cases where you might want or need this. For example you have a trouble user who is doing something they shouldn't and to simplify the tracking process you reserve that users MAC address within the DHCP scope.
That MAC will always get that IP address, so when you talk to HR you have simple proof.
But still, reservations assign the IP address to the MAC address in which they are created.
It doesn't matter, I do that all the time. Mostly because it's easier to right click on what it gets automatically and set it as a reservation, and also ran out of excluded IPs.
They are all listed under reservations anyways, so still easy to find and manage.
-
@tonyshowoff said in DHCP Logic:
@scottalanmiller said in DHCP Logic:
@g-i-jones said in DHCP Logic:
Anyway, he said even if there is a reservation, if that thing goes to sleep, then other things can still snatch up that IP address because it's in the pool.
That makes no sense at all. He's thinking of DHCP Preferences, not related to Reservations. The entire concept of a reservation doesn't mesh with this definition at all.
Imagine if you had a restaurant reservation that only worked if you were already at the restaurant waiting. No need for a reservation if you are already there and have the table, right? Completely nonsensical.
Reminds me of Seinfeld and his car reservation
Oh this is one of my favorite scenes. Absolutely hilarious!
-
@zachary715 The video wouldn't play for me but yeah Seinfeld is great.
-
@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.
I have more experience than my coworker with DHCP, so I don't know why I let him try to convince me what I already knew was wrong. I think I forgot to take my B vitamins yesterday lol. Anyway, thanks for the reply's.
-
@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.
