I will take a different tack in answering your question than Arvind did. I will start by saying that whether it is advisable or not depends on your local situation and what set of requirements you are trying to achieve. Arvind's response is based on the assumption that you are forwarding to 2 DHCP server (which may or may not be the case). I worked, at one time, with a customer who was very concerned about providing redundancy and eliminating single points of failure. They deployed 2 DHCP server serving addresses for each subnet in their network. In that situation having 2 helper-address configured is possible AND desirable. (Arvind is correct that there is some additional overhead in having 2 DHCP servers for a subnet - but there is a trade off of overhead and the advantage of eliminating single points of failure, where would your organization be in balancing those aspects?)
And there is the situation to consider where the 2 helper-address may not be both for DHCP. Perhaps you have an environment where some devices send requests for TFTP to the local broadcast but the TFTP server is not on the local subnet. In that case you might have a helper-address for the DHCP server and another helper-address for the TFTP server. So you might have this configured:
! helper for the DHCP
ip helper-address 172.16.1.51
! helper for TFTP
ip helper-address 172.16.2.45
So - is it possible to have 2 helper-address configured? Certainly it is. Is it desirable to have 2 helper-address configured? That depends on your local situation.
I would perhaps go a little further than Rick on this. If you have a redundant network setup then i cannot see a reason not to run more than one DHCP server because otherwise you have spent quite a bit of money in making your network redundant only to have it become almost dependant on the failure of one server.
If however you don't have a redundant network topology then you coud run with one DHCP server although again in my experience i have found switches/routers to have better reliability than the average windows server.
It is only a broadcast from the client on the local segment and becomes unicast from there so the traffic really is quite minimal and i would not be too concerned with the additional overhead of 2 requests going over your network rather than one.
One point that should be made is if you do have 2 DHCP servers then any scope you run from both cannot overlap so if for example you have 192.168.5.0/24 and you wanted to run this on both DHCP servers then you would need to advertise half from one and half from the other (or some variation on that).
>> f you do have 2 DHCP servers then any scope you run from both cannot overlap so if for example you have 192.168.5.0/24 and you wanted to run this on both DHCP servers then you would need to advertise half from one and half from the other
We have two Cisco Network Registrar servers in two different towns: they have the same configuration in all scopes and they complain if they are different.
They run some form of communication between them.
Our release is a little too old and we need to make changes on both, but about the process of DHCP leases in each scope they keep each other informed and don't cause conflicts.
On all router interfaces we have both ip helper-address.
In some cases we add on demand a third/fourth ip helper-address command(s) for RIS servers (MS servers used to install OS images on new or rebuilt PCs)
Having a double ip helper-address is not a so big overhead for router and can make effective the DHCP server redundancy.
"Having a double ip helper-address is not a so big overhead for router and can make effective the DHCP server redundancy."
Agreed, which is why i wrote that in my previous answer.
I have never used CNR but i like the idea of the same scope on both machines. A lot depends on who controls the network services in an IT dept - network services in the sense of DNS/DHCP/NTP etc. In big companies it often comes more down to politics than any technical reasons.
What i have done in the past is split the scope between 2 machines but never have more than half the scope actually used, not a big deal with private addressing. That way if a single server fails there are still enough IP's from the other server per scope.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...