DHCP Management Across a Diversified Network?

ET Admin writes "I work for a small Wireless ISP, where we are deploying new network hardware to allow for growth and contain broadcast traffic. All routing/switching equipment is Cisco. We use Linux stand-alone boxes and VMs (running on Win 2003 boxes). We have decided on a hybrid VLAN layout where we have certain VLANs limited by location, and other VLANs that are global across the network. And I want DHCP served across it all. Does anyone have experience with IPAM software that handles multiple DHCP servers? Our network is small so spending a couple grand is overkill at this point. Any recomendations to help me decide between serving DHCP from the Nix boxes, or from the Cisco gear? Knowing that a single DHCP server will handle from 100-500 hosts."

Comments

DHCP Relaying

[Anonymous Coward]

setup DHCP Relaying on the switches to forward/relay all dhcp request across the vlans and subnets to one (or two) dhcp servers

Re:DHCP Relaying

[TaliesinWI]

Done in one. You can even train ISC DHCP to give out different pools based on the primary IP address of the gateway for a particular VLAN. At that point all you have to worry about are keeping the pools "fed".

Re:DHCP Relaying

[Anonymous Coward]

DHCP Relay Agent in Cisco Routers

Cisco Routers support DHCP Relay Agents with ip helper-address command. To enable the ip helper-address on an interface that will receive client BOOTP/DHCP broadcasts.

From the Global configuration mode,

Router(config)# interface fa 0/0

Router(config-if)# ip helper-addres 10.10.10.1

Router(config-if)# ip helper-addres 10.10.10.2

Re:DHCP Relaying

[cr0nj0b]

Or two dhcp servers. Just in case the path to the first dhcp server is unavailable

http://www.madboa.com/geek/dhcp-failover/

Re:DHCP Relaying

[Curien]

One of my main goals in this design is to limit broadcasts outside of each subnet, and ip helper obviously punches a hole in that philosophy.

ip helper doesn't forward as broadcasts. When the router on the host's segment detects the broadcast DHCP request, it forwards it directly to the next hop (just like any router does with a non-broadcast packet).

I have the solution you need...

[poptix_work]

http://lmgtfy.com/?q=cisco+dhcp+relay&l=1

You can easily run hundreds of thousands of hosts off a single DHCP server. It is not cpu intensive particularly if you have a decent lease duration.

Re:I have the solution you need...

[poptix_work]

Also, here's a small sample config for serving a particular pool on a particular interface (which would be the vlan "interface" on the Cisco), easily found on Google:

class "vlan1234"
{
                match if
                (
                                (binary-to-ascii(16, 8, ".", option agent.remote-id) = "0.15.63.ab.52.16") # This is the MAC of the switch
                                and
                                (binary-to-ascii (10,8, ".", option agent.circuit-id) = "0.0.0.47") # This is the interface number
                );
}

pool {
                range 192.168.100.5 192.168.100.254;
                max-lease-time 300;

                option subnet-mask 255.255.255.0;
                option routers 192.168.100.1;
                allow members of "vlan1234";
}

phpdhcpadmin

[Anonymous Coward]

Someone in house here created it, and we use it across multiple vlans from a Gentoo box. It uses the ISC DHCPD server.

http://phpdhcpadmin.sourceforge.net

Use the Unix/Linux boxes....

[Fallen Kell]

Seriously, do not use the Cisco gear to handle the DHCP. There are several ways to handle this, either have a system with an interface on all the networks, or setup your Cisco gear to forward the HDCP requests to the one subnet that does have your system.

With using Unix/Linux you can setup failover servers so that if one does not respond, the other will take over the requests and that way you will not lose DHCP across your entire network due to hardware/software issues on a single system. Go read up on dhcpd, it is not too difficult to understand, and is really probably your best low cost solution.

You need Cisco gear

[Anonymous Coward]

You need to use DHCP snooping to block rogue DHCP servers and block packets with forged MAC addresses on untrusted interfaces

You need IP source guard to block forced IP addresses on untrusted interfaces

Otherwise, you are at risk of DOS and/or compromise from malicious users, and at risk of instability and insanity caused by users who plug a rogue DHCP server (even something as simple as the LAN side of a Linksys gateway) into your gear.

Re:You need Cisco gear

[mysidia]

That's not an absolute. You should use VLAN segmentation (and possibly private VLANs) to separate untrusted networks.

That way if there is a rogue DHCP server, its effects are isolated to the untrusted LAN it came from.

The L2 filtering features you are thinking of are actually inadequate to stop a sophisticated attacker, because those features can be defeated, or don't address all possible Layer 2 spoofing and traffic hijacking tricks.

Re:Go IPV6 and leave DHCP in the dust

[Imagix]

Ahem... never heard of RFC 3315? DHCPv6 still has a place in an IPv6 network.

DNSMasq

[TheRealMindChild]

DNSMasq. Nuff said.

Nice answer Slashdotters.

[bluephone]

To everyone who tagged this "domyjobforme", I hope every single one of you gets the same response the next time you ask for help doing you job. At least this guy had the sense to say, "Hey, there's a community of people that contains a multitude of experts in many fields, I bet someone might have some good suggestions." And guess what else? Maybe some readers will find the suggestions helpful too. Ask Slashdot is for questions that the general community might find interesting and helpful, not just one guy. It's not just about the submitter, and it's certainly not about your need to be snide to those who recognize their shortcomings and try to expand their base of knowledge.

Re:Nice answer Slashdotters.

[Anonymous Coward]

You sound like the idiot, for not realizing that people get stuck with jobs all the time for which they have not been fully trained. For myself, I'm an engineer who was asked to 'setup your own lab'. I'm not an IT type, I'm an electrical engineer specializing in circuit design. Yet, I've been handed the job of configuring 40 linux servers, DNS, DHCP, Cisco switches, multiple VLANs, and so forth simply because 'there's no one else to do it and no one is hiring anyone'. Sure, my company might be cheap for not providing IT services for my lab, but they're on a budget and extra employees are expensive. Only when the expense of having me configure my own DHCP services exceeds the expense of hiring someone to do it for me will they consider hiring someone external. And only then if they know the new hire will be used elsewhere.

So guess what? This guy's question is exactly the kind of information I can use to help me overcome my own problems. Ask Slashdot seems to be doing its job quite nicely in this respect.

Carnegie Mellon's NetReg

[vitroth]

Carnegie Mellon's NetReg is an open source system that provides a pretty complete IP Address Management toolset, including management of DNS & DHCP configurations for ISC bind/dhcpd. It can manage ISC dhcpd's failover configuration, and multiple server groups, etc.

Rather then just repeating what I've said before when the subject of IP Address Management came up on slashdot, I'll just link to it.

Note: While the project has been pretty quiet for quite some time now, thats mostly because its the system is very stable and there hasn't been a lot of major new development in the last couple of years. I used to be one of the core developers of the system before I moved on to another job, but its still in active use by many sites.