After going through this I would like to know if it is still a good practice to enable dhcp relay on a switch. Main thought behind it would be reducing network load / utilization as there would be less broadcast packets flying around.
My current config (192.168.2.1 is DHCP-Server):
My question is: does it actually help reduce network load / utilization / saturation? And if so is it a good practice?
Isn’t relay only needed if you have multiple subnets or vlans? I’m not sure that you’d have to enable it unless your network has specific need of it as a helper for the other subnets to find an address.
I know it’s used if you for some reason only have one dhcp-server and you want the client of a different subnet/vlan to get IP-adresses from the dhcp-server in the other subnet/vlan. That’s what the option “Relay Information Mode” is for.
But my question is: does it actually help reduce network load / utilization / saturation?
Workload is key in that decision for instance if you have devices that put out a bunch of chatter but really don’t move large amounts of packet data then the vlans or subnets don’t bring a lot of advantage or improvement to overall network performance. If you have a workload that puts a continuous package flow like streaming video or IP phones then moving those off of the main lan over to vlan will really help prevent lag on the main network. I’ve seen some switches that really don’t handle vlans well natively unless you have one that allows you to manage ports individually and assign them to a particular vlan. It may bring advantages if the switch is properly segregating or partioning your ports. Some switches advertise vlan support but rely completely on the tagging to split the traffic and not really provisioning the ports separately. I’d say it depends on the workload and switch as to how “worth it” your results would be.
I’ve only ever found DHCP relay to be useful when you want to centralize the DHCP configuration from multiple subnets onto a single machine.
It shouldn’t matter at all in terms of network performance.
Sorry for the late reply, I was away for a few days.
@backbone: what do you mean by workload is key? The amount of packets, the size of packets or even the priority?
Let’s say I have a reasonably big network (50-100 clients, 4-8 servers) and there are a lot of switches between clients and servers. Wouldn’t it reduce the network load even a small amount in the morning, when all the devices connect, startup etc. and request data from the servers?
Without having all the facts, I would argue that it makes no difference in terms of reduction.
All broadcasts will still go out - the response will still be sent. This is just as argued (and I agree) and ease of configuration point for centralised DHCP-servers, where the switch can assist in pointing the casts in the right direction.
Assuming your “network” is just a single subnet, DHCP relaying wouldn’t be relevant to this context, because it is only beneficial when you are dealing with a single site with multiple subnets, VLANs or networks. From what I read, a DHCP relaying agent just listens to a client’s request when they’re not on a subnet; that is the router, the server and the DHCP server doesn’t know what the client is. Then what would the agent do is send the client’s request tot eh DHCP server so that it can allocate the correct address for the client via the agent.
So really, DHCP relaying only works well in a multiple network environment. In your case, since you only have a single subnet, you could stick to the traditional “client requests the address from the server” thing. If you really want to reduce the load in a big network, it’s the case of allocating the clients to VLANs, assigning the correct settings to the switches and considering the right methodology of load balancing your entire topology.
DHCP relay is one of those things that isn’t nonsense but if you need it you need it… otherwise do not enable it.
The way DHCP works is basically the client sends an ethernet broadcast to find the DHCP server.
DHCP Broadcasts (well, all ethernet broacasts) do not normally cross VLANs (as a VLAN is a single broadcast domain), and as a result you need to have a DHCP server on every VLAN (or multi-home your DHCP server which is bad and joining networks together - defeating much of the purpose of running multiple VLANs for security isolation).
This is where DHCP relay comes in. The switch will forward DHCP packets to a machine in the other VLAN where your DHCP server is.
It’s to reduce management overhead. If you had say 10 VLANs with DHCP required, you’d need to manage 10 DHCP servers. Pay 10 OS licenses, etc. Your information will be scattered across 10 servers. You’d need to have 10 servers with permission to update DNS in active directory, etc.
FAR easier to just use DHCP helper on the switch.
If you aren’t doing any of that, leave it turned OFF. As per security best practice.
You will not reduce broadcast traffic by enabling DHCP relay. The switch doesn’t even see the traffic to relay until the broadcast is sent by the client. The replies aren’t broadcast - they are directed back to the source MAC.
Broadcasts will still be sent by the clients. All this does is forward them across VLANs to a server AFTER the broadcast is sent by the client and already on that VLAN.
No, it won’t.
Also, DHCP traffic is small and infrequent. Even if all 100 clients tried to do DHCP at exactly the same time, you’d be talking a few hundred kb of data. On a gigabit switch (or faster). Network load will not be a problem in that scenario.
Indeed. Any services that you’re not certain of its functionality, leave it or turn it off. All of my network classes had stressed us out couple of times for the best security and inevitably, performance of a networking device, turn off any unnecessary services. I believe the disadvantage of enabling DHCP relaying is that you are also open to potential DHCP-related attacks, if an attacker happens to be somewhere in your network.
So for the instance of a single subnet network, this is unnecessary. Besides, my guess is that if a client happens to transmit a broadcast constantly, something is wrong…
Yup.
As I understand it (note, i have not checked this, but it would make sense from a design perspective IMHO), the client will only try to refresh its lease either at the expiry of, or close to the expiry of the lease, or at reboot/nic re-initialization time.
So if your leases are for some sane duration (e.g., 8 days or whatever so that if someone takes a week off work, they come back and get the same IP to prevent un-necessary DNS record updates, etc.) - you’re only seeing a few kb per client in DHCP traffic once a week, or at most once a reboot.
Definitely, if you’re seeing large amounts of DHCP traffic then something is wrong - maybe a dodgy cable on the client, or something more malicious.