server vs. router for DHCP services ?

briangl

Why would a company prefer to use a server versus a router for DHCP services? DHCP services are provided by a server at a central location, miles from our remote location. We occasionally experience DHCP problems, due to problems with the server at the central location, that prevents us from accessing network resources, until I manually assign IP info. to everybody here. We also can not print to our local network printer, due to the fact that it acquires IP info. from the DHCP server. Wouldn’t it be more efficient to configure our local router as a DHCP server? What advantages are there to doing it centrally? If there are advantages, do they outweigh the inconvenience and loss of productivity that we experience here?

Daniel333

Sounds like you guys have more problems than just the location of your DHCP server there. As long as your VPN tunnel is clean, you shouldn ot have any trouble accessing the DHCP router. Alternate IP configuration set?

Being able to centrally have items register themselves with DHCP and Microsoft DNS is a great advantage for administrative overhead this is a feature talked a lot about in your 70-291. It also makes a little easier for troubleshooting to have all your addresses on the same screen.

Correct me, if I am wrong here, but I do believe the Cisco PIX doesn't have an option for reservations?

briangl

I’m not actually in the IT dept. here, they won’t let me in for some reason. I am trying to get my CCNA wrapped up and start looking elsewhere. I am trying to get some “real world” understanding and experience any little way I can. I haven’t studied 70-291 yet.

I have asked in the past why we had a DHCP problem here and was told that the hard drive on the DHCP server was full and some room had to be freed up. I don’t know if that was the problem we had a week or so ago, no one will reply to me emails about it.

dynamik

briangl wrote:

I have asked in the past why we had a DHCP problem here and was told that the hard drive on the DHCP server was full and some room had to be freed up.

That's hilarious.

As Daniel noted, there is some integration when using server-based DHCP. However, the benefits may not be worth having sites sporadically go down if the service is unreliable.

GT-Rob

I've seen a mix sometimes.

For example, a central dhcp service for the HQ and major sites, but then some of the smaller sites (the ones that like to add users/equipment without telling anyone), I have set up the router/switch to act as a DHCP server, as its usually easier for just a few people.


Enterprise networks are all about being centrally managed, and there can sometimes be a trade off for it (like in the OP example). However, imagine having 1000 different sites in different locations. Instead of having 1000 dchp pools to manage, you can just have 1 massive one that takes much less people to run.

briangl

Yeah, I was a little perplexed when I was told it was because of hard drive space. I was like, “huh”. I guess a new hard drive is too expensive.

I offered to configure the router for DHCP, but they won’t even respond to me.
I’m almost inclined to do a password recovery on the router and go in and do on my own. That might be frowned upon though. On the other hand, lack of a reply could be construed as tacit consent to proceed at will. I have been very curious about how the thing is configured anyway. I would love to be able to look at the running-config, not even change anything. Again, just to see how things are done in the “real world”.

Thanks for your input.

dynamik

briangl wrote:

Yeah, I was a little perplexed when I was told it was because of hard drive space. I was like, “huh”. I guess a new hard drive is too expensive.

I don't know how large your organization is, but more than likely, your DHCP data is going to be very small. They probably have something other things on that server that ate up all the space.

briangl wrote:

I’m almost inclined to do a password recovery on the router and go in and do on my own. That might be frowned upon though. On the other hand, lack of a reply could be construed as tacit consent to proceed at will.

I think you would seriously be asking for trouble if went about things like that. Some people are terrible with email; pick up a phone

jibbajabba

One other reason is also "option 60" I believe .. not sure if every router supports that ...

paintb4707

GT-Rob wrote:

Enterprise networks are all about being centrally managed, and there can sometimes be a trade off for it (like in the OP example). However, imagine having 1000 different sites in different locations. Instead of having 1000 dchp pools to manage, you can just have 1 massive one that takes much less people to run.

+1

I'd imagine the issue would lie with your VPN tunnel to the HQ, not necessarily DHCP itself.

tiersten

briangl wrote:

I’m almost inclined to do a password recovery on the router and go in and do on my own. That might be frowned upon though. On the other hand, lack of a reply could be construed as tacit consent to proceed at will. I have been very curious about how the thing is configured anyway. I would love to be able to look at the running-config, not even change anything.

Um yeah. If somebody did a password recovery on a router that they have no business touching then I'd smack them down really hard and really quickly. Getting in to just "have a look" is just as bad.

A lack of reply doesn't imply consent either.

The reasoning behind the massive DHCP pool is most likely what GT-Rob said. It is much easier to centrally manage this. I use DHCP even for some devices which have a static IP because its just easier to change it from 1 single location than to go to every device.

You said that you've been assigning people static IP addresses for when the tunnel to HQ is down. Do you revert these back to DHCP when it is up again?

paintb4707

tiersten wrote:

You said that you've been assigning people static IP addresses for when the tunnel to HQ is down. Do you revert these back to DHCP when it is up again?

Good point... This could cause some rather huge issues with other sites.

Turgon

briangl wrote:

Yeah, I was a little perplexed when I was told it was because of hard drive space. I was like, “huh”. I guess a new hard drive is too expensive.

I offered to configure the router for DHCP, but they won’t even respond to me.
I’m almost inclined to do a password recovery on the router and go in and do on my own. That might be frowned upon though. On the other hand, lack of a reply could be construed as tacit consent to proceed at will. I have been very curious about how the thing is configured anyway. I would love to be able to look at the running-config, not even change anything. Again, just to see how things are done in the “real world”.

Thanks for your input.

The IT Department are pulling your chain about lack of disk space for DHCP and probably having a good chuckle about that one. IT Departments are zealous about non IT staff not configuring devices and with good reason. I recommend you don't attempt to set up anything like that without verbal or written approval from the IT Manager at headquarters. We had someone once try and setup peer to peer networking from some HQ desktops to his remote site workgroup across the WAN for those users. Impressed those users no end as files could be dropped between sites. Problem was those users were knocked out of all connectivity locally to users at HQ. We cleaned this up followed by terse letter from Group IT Manager to the culprit.

The router may be monitored by numerous means and any access or changes logged. Don't touch it.

Luckycharms

--- +1 for the situation ---

Bandwidth cost + Staff Competency/Service Cost + Device TCO = Total Cost of Service
( honestly I don't feel like listing all the crap that goes along with this..) long day...


Since no one has mentioned this yet... Think Network Management ( PXE -WinPE/DosBoot... local PXE file's on the router... Now I know you can set you 60/150 options to go back to the router after getting DHCP info from the server... but really do you want to run accross your wan if you have too???)

And Central DHCP management is great is a small environment. but really when you get over 50 sites with more then 200 people at each site... it start's to be come a nightmare.. So you are back to the site based DHCP... Like i said before situational..

Slowhand

Yup, it definitely sounds like your company's IT department needs to sort out quite a few things that are at the root of the problem(s), not just the DHCP. Say, they're not looking for a consultant, are they. . .

Turgon

Luckycharms wrote:

--- +1 for the situation ---

Bandwidth cost + Staff Competency/Service Cost + Device TCO = Total Cost of Service
( honestly I don't feel like listing all the crap that goes along with this..) long day...


Since no one has mentioned this yet... Think Network Management ( PXE -WinPE/DosBoot... local PXE file's on the router... Now I know you can set you 60/150 options to go back to the router after getting DHCP info from the server... but really do you want to run accross your wan if you have too???)

And Central DHCP management is great is a small environment. but really when you get over 50 sites with more then 200 people at each site... it start's to be come a nightmare.. So you are back to the site based DHCP... Like i said before situational..

Yes I agree. Honestly I don't think it's usually a good idea to be reliant on WAN transported services unless they are absolutely essential.


On that note I recall the good old authentication across the WAN problem we used to see sometimes in NT 4.0. Even with a local BDC on the LAN authentication requests would head off down the WAN to the central PDC unless the PCs had loadbalance correctly flagged in the registry. The problem would prevent users logging on to the domain as the link would choke with the traffic.

I would rather keep WANs free for application bandwidth by keeping things like DHCP local and off the WAN. I'm all for using WANs to periodically replicate to remote sites to keep things consistent between remote and central sites for AD and such that needs to sync but going to the centre for everything is often a recipe for trouble. It's all about design choices and how they were made. Sometimes a tradeoff, sometimes just a lack of understanding. For reasons why ask the IT Department.