15

I've discovered a subnet with two "ip helper-address" statements. This is not our normal configuration.

interface Vlan300
 ip address 10.1.3.2 255.255.255.0
 ip helper-address 10.2.1.10
 ip helper-address 10.3.1.10

Looking at our DHCP servers, it seems that there are leases coming from both of them.

I realize this is not recommended, and the two DHCP servers might not be aware of each other's lease assignments (I'm pretty sure they don't).

The question is, how is this handled by the Cisco switch (4510 Sup7 12.2)?

  • Is it the first DHCP server to respond?
  • Is it the first one, then the second one if the first one times out?
  • Is it round robin?
Peter
  • 1,351
  • 12
  • 28
Pseudocyber
  • 887
  • 4
  • 8
  • 15

4 Answers4

12

The ip helper-address command designates an address which broadcasts are forwarded to; it will send the original packet to each of those listed addresses.

If both reply, both replies are forwarded back to LAN.

Matt
  • 160
  • 9
ytti
  • 9,776
  • 42
  • 53
  • 1
    So, the host would take an IP from whichever DHCP server answered first - odds are the one closer will win, if the other is over a WAN? – Pseudocyber May 23 '13 at 14:22
  • 2
    Ordinarily yes. One reason to do this would be for failover/HA of DHCP (eg, ISC DHCPD supports this) – LapTop006 May 23 '13 at 14:24
  • 2
    ACK LapTop006 is right. DHCP client will handle this double offer situation by design gracefully, no specific implementation is required. – ytti May 23 '13 at 14:26
6

Your ip-helper is the correct way to do this for redundancy and is the recommended method.

The DHCPDiscovery (broadcast) gets picked up by the ip-helper and then unicasts to each DHCP server with the relay-agent (the router) in the request.

Usually the first DHCP server to respond wins. Both DHCP servers can (and should) make DCHPOffers to the client. It's the client that decides which one to keep and then sends a DHCPRequest (unicast) to the server that offered it for the IP it wants to use. The server needs to DHCPAck that request to complete the process.

For redundancy, but to not violate the DHCP rule of not having overlapping scopes defined for your IP pools, you need two ip-helpers. Since the DHCP servers are not aware of one another, the IP pools must be unique. A common method for DHCP redundancy is to take your typical /24 subnet and divide it into two /25s for your scopes (one per server).

Example: 192.0.2.0/24 is your actual network, so you divide it into 192.0.2.0/25 and 192.0.2.128/25. So the roughly 256 addresses are cut into two pools of 128 addresses and assigned to each DHCP scope. Now you have no overlapping addresses + redundancy.

Since cutting your scope pool in half, make sure the servers can support your entire network if one DHCP server were to fail. Consider the lease-time to be the duration that clients can retain their addresses where you won't exhaust your pool if you have many rotating clients, yet be able to give you enough time to detect and fixed a failed DHCP server.

generalnetworkerror
  • 7,094
  • 6
  • 32
  • 65
  • 1
    Actually you don't want to divide them, but rather configure a identical scope on all dhcp servers and set up unique exclusion ranges on each one. This way you'll have better agility if one server should go down for a while. – pauska May 23 '13 at 22:18
  • 1
    The exclusions tend to get buried in the configuration and I prefer to see the two scopes easily identified with their separate pools so there's no question what each DHPC server is doing. As long as the design can handle a failed DHCP server for some period of time, I see no issue with this, but I agree that going the exclusions route is a better option for some. (These comments are with respect to Windows DHCP's GUI which buries some of the details.) – generalnetworkerror May 23 '13 at 22:24
2

IIRC, it sends to both configured helpers and the fastest one wins.

1

with regard to your concern about the DHCP not being aware of the others leases, before a DHCPOFFER is sent to the host, the DHCP Server sends an ICMP message to the IP address, if the DHCP server receives a ICMP Echo Reply message, the DHCP server chooses a different IP address, and sends another ICMP message to that IP address until a ICMP Echo Reply message is not received, then the DHCP server sends the IP address in the DHCPOFFER to the host.

dave
  • 11
  • 1
  • If so configured. One can configure their DHCP server to not "guard" assignments like that. – Ricky May 23 '13 at 18:14
  • I would go a little further than Ricky and say this is not a common practice anymore in many larger networks as it can create a performance issue on the DHCP server(s). Most stations now run a local firewall and often do not respond to ping requests, but the server still has to wait for some timeout period per request. This also makes the feature less useful (station with firewall won't respond, the server had to wait for the request to timeout, and an IP conflict still results). – YLearn May 23 '13 at 18:25