DHCP Relay agent not forwarding messages to the client

[Gero Palacio]

Hello.

I'm just done testing and can confirm that the problem was due to the
"secs" field (client) being greater than the "load balance max seconds"
(server) and they way I was conducting the tests.

The dhclient and dhcpd servers were started from moment 0, relay agent
would start 30 seconds later. When both servers reach the normal state, I'd
start the relay agent. That caused the client to increase his "secs" field
because it was not getting any answers as his messages were not being
forwarded from moment 0 (relay agent down).

So thanks Graham and  Peter for pointing that out and everyone else who was
involved in this! I've should read the definition for "load balance max
seconds" more carefully -_-

Cheers!

On Wed, Jun 17, 2015 at 5:20 AM, Flex Banana <flex.banana at bluewin.ch> wrote:

> Hi Graham,
>
> I’m very interested how you have setup your machines for the DHCP Failover.
>
> We have a big MAN in Switzerland with almost 600 subnets and 20’000
> computers. Now we have 1’400 static entries in our dhcpd.conf.
>
> Can you send me your config files ?
> And how many CPU/RAM/Disk you have for the machines ?
> Physical or Virtual machines ?
>
> Thank you so much for all
> Best regards
>
> Stefano
>
>
> > On 16 Jun 2015, at 21:58, Graham Clinch <g.clinch at lancaster.ac.uk>
> wrote:
> >
> > Hi Folks,
> >
> > On 16/06/2015 14:28, Friesen, Don MTIC:EX wrote:
> >> Yes, this is the expected and normal behavior.  Each server will reply
> >> with an address from its half of the pool. The machine that is receiving
> >> the offers will take the first offer to arrive and ignore the other.
> >
> > We have 'split 128' & 'load balance max seconds 5' parameters set, and
> so clients that discover with a low 'secs' field are only answered by one
> of the pair:
> >
> > ==
> > Jun 16 09:19:05 is-dhcp0 dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff
> (Kates-iPhone) via 10.32.176.8: load balance to peer schlep-failover
> > [and no OFFER]
> >
> > Jun 16 09:19:05 fa-dhcp0 dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff
> (Kates-iPhone) via 10.32.176.8
> > Jun 16 09:19:06 fa-dhcp0 dhcpd: DHCPOFFER on 10.32.186.98 to
> aa:bb:cc:dd:ee:ff (Kates-iPhone) via 10.32.176.8
> > ==
> >
> >
> > Some clients don't implement the secs field correctly (or appear to get
> their most/least significant bits muddled), so we do see some clients that
> receive two offers.  Perhaps there are some relay agents that are the same
> (although I'd be surprised if the ISC relay was broken in this regard).
> >
> > The idea here is that, on average, the load for unicast renews is split
> evenly between the pair of dhcp servers.
> >
> >
> > On 16/06/2015 20:16, Sean McMurray wrote:
> >> If they are both making offers, what is the point of configuring them in
> >> failover? You might as well set them up independent of each other and
> >> have them serve different pools.
> >
> > Even if all clients receive two offers, the benefit is that when one of
> the dhcp pair fails, clients don't suddenly renumber themselves into the
> remaining server's pool - they can continue to renew their current address
> (and that you don't need to run with two pools, each large enough to cover
> all clients).
> >
> > We're very happy with relay agents and failover - 1,150 networks, 17,300
> static 'host' addresses & 260,339 dynamic addresses.
> >
> > Graham
> >
> > PS: Any movements on failover for DHCPv6?  At least I don't feel bad for
> using twice the address space within a /64.. :)
> > _______________________________________________
> > dhcp-users mailing list
> > dhcp-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/dhcp-users
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150617/cc4e6a8f/attachment.html>