Static IPs vs DHCP Reservation in a SMB network

[MrDudeMan]

I currently use SBS 2011 (soon to be 2012 R2) with the DHCP role as my DHCP server, but I want to move it to another piece of hardware. My thought is it would be more robust to have another piece of equipment giving out IP leases in case the DC goes down. Note: I forgot to mention the SBS 2011 machine is the DC, FS, DNS/AD, and DHCP server.

My firewall is a Cisco ASA5500, which apparently can't do DHCP reservations. I'm hesitant to move DHCP to a device that can't handle DHCP reservations because I don't want the overhead of assigning static IPs to every device. Is that worry unfounded? If not, how would you proceed?

Note: I'm installing a NAS with Storage Server 2012 R2 in the next few weeks and it can be the DHCP server, but I think assigning that role to it would be the same as leaving it on the DC, right?

What are my options? I've considered everything from buying a new server sooner than I expected to run a DHCP server in a VM to throwing something small and inexpensive like a Raspberry PI on the network to handle DHCP. I'm sure the rpi is a bad idea, but I don't know all of the reasons. The real concept there is to use some kind of Linux box to handle DHCP in lieu of upgrading the firewall, which I'm not especially excited about doing.

Thanks for any help you can offer.

 

[yinan]

Leave it on the DC, if the DC goes down you are screwed anyway.

 

[dave_the_nerd]

I'd generally go with static IPs for a few basic pieces of infrastructure (domain controller, dhcp server, switch management, stuff like that) and DHCP w/ or w/o reservations for everything else (depending on need.)

If it's all windows and you have an AD environment, DNS entries get updated or self-registered every time the IP's change, so fixed IP addresses aren't really all that necessary.

 

[sdifox]

DHCP is not much of a load so why would you need to dedicate hardware to it? How big is the site? Static for key hardware and reservation for the rest should be sufficient.

 

[mxnerd]

No need to set static IP or reserve IP for every device, only servers or devices that need to be managed. Client PCs do not require static IP addresses, assign client PC a static IP does not make much sense.

If you have 2 Windows 2012 servers, you can setup DHCP failovers. Many tutorials on youtube. Even if you don't use failover, you can still split DHCP scopes easily using 2 DHCP servers.

Like what sdifox said, DHCP is very lightweight service, absolutely no needs to dedicate a VM or PC for it.

 

[yinan]

I would at least put the clients on a separate VLAN, that way you do not have to let the servers access the Internet unless it is required.

 

[MrDudeMan]

I'd generally go with static IPs for a few basic pieces of infrastructure (domain controller, dhcp server, switch management, stuff like that) and DHCP w/ or w/o reservations for everything else (depending on need.)

If it's all windows and you have an AD environment, DNS entries get updated or self-registered every time the IP's change, so fixed IP addresses aren't really all that necessary.

For a reason that is unknown to me, I am constantly needing to manage Polycom VOIP phones remotely, so it's really annoying that they keep switching IPs on DHCP. What I want is pretty much what you said - static IPs for a few things and reservations for the rest below .100 with a true DHCP range from .100-.199 or something like that.

I guess I could leave all of this on the DC and just be screwed if it goes down, but that doesn't feel like a very robust solution. The network is coming out of the dark ages slowly, but surely, so I thought this might be a good time to appropriate network related services to devices that will perform better and have higher uptime (allegedly).

DHCP is not much of a load so why would you need to dedicate hardware to it? How big is the site? Static for key hardware and reservation for the rest should be sufficient.

I didn't mean to say it has to be on another piece of hardware. I phrased the situation and my questions quite poorly in my OP apparently. I'm fine with leaving it where it is if that's the right way to do it, but running a secondary DC (if I go that route) makes DHCP on the primary DC confusing, at least to me. It probably would have helped if I had mentioned that.

 

[MrDudeMan]

I would at least put the clients on a separate VLAN, that way you do not have to let the servers access the Internet unless it is required.

I love your signature.

I'm frequently remotely accessing the server, which maybe isn't the right thing to do. I live in a different state and I think it's my only choice, but now that my Dell NAS has iDRAC, maybe that will happen less and less. Setting up VLANs for workstations, phones, servers, etc. is beyond my capabilities in implementation even though I understand the concept.

 

[MrDudeMan]

No need to set static IP or reserve IP for every device, only servers or devices that need to be managed. Client PCs do not require static IP addresses, assign client PC a static IP does not make much sense.

If you have 2 Windows 2012 servers, you can setup DHCP failovers. Many tutorials on youtube. Even if you don't use failover, you can still split DHCP scopes easily using 2 DHCP servers.

Like what sdifox said, DHCP is very lightweight service, absolutely no needs to dedicate a VM or PC for it.

I missed this before I replied to the other posts.

I didn't know the name for it, but setting up DHCP failover is what I was trying to say in my previous posts. I'll look into that. Thanks.

 

[dave_the_nerd]

For a reason that is unknown to me, I am constantly needing to manage Polycom VOIP phones remotely, so it's really annoying that they keep switching IPs on DHCP. What I want is pretty much what you said - static IPs for a few things and reservations for the rest below .100 with a true DHCP range from .100-.199 or something like that.

I guess I could leave all of this on the DC and just be screwed if it goes down, but that doesn't feel like a very robust solution. The network is coming out of the dark ages slowly, but surely, so I thought this might be a good time to appropriate network related services to devices that will perform better and have higher uptime (allegedly).

I didn't mean to say it has to be on another piece of hardware. I phrased the situation and my questions quite poorly in my OP apparently. I'm fine with leaving it where it is if that's the right way to do it, but running a secondary DC (if I go that route) makes DHCP on the primary DC confusing, at least to me. It probably would have helped if I had mentioned that.

If the only DC goes down, nobody's really getting anything done until you get it back up (assuming you're using SSO for everything it can do, which is generally pretty freaking awesome), so DHCP being out would be kind of a moot point. (Especially if your leases are kinda long - set the lease to a few days or a week, and stuff will chug along with its existing IPs for a long while before leases start expiring.)

If you failover DC services to a secondary, then you will likewise have plenty of time to grab a couple beers and spin up a secondary DHCP server if you want, or just fix the primary. Like, whatever dude. :thumbsup: