dhcpd sporadically ignoring one of two "copies" of a DHCP request
p.mayers at imperial.ac.uk
Tue Mar 11 16:43:11 UTC 2014
On 11/03/14 16:31, Niall O'Reilly wrote:
> We have a similar network, without Juniper, and with HSRP running
> between paired routers. We had a similar problem with clients not
> getting leases. Once we had our OSPF costs aligned with the HSRP
> priorities, we didn't see the problem any more. That's to say, our
> particular way of looking at the problem led us to treat it as a
> routing problem, not an ignored DISCOVER problem.
Well, it's arguably both. In principle the routing problem could be
addressed via costs (not an option for us) or uRPF override ACLs (many,
many caveats on the hardware platforms) but it's undeniable that dhcpd
is ignoring a DISCOVER in some cases.
In our case, tweaking routing metrics is not an option, but I would
anyway not want to do it, as the topology is deliberately designed to
have ECMP paths, for fast failover on link loss.
> I wonder whether the missing DISCOVER is actually reaching the
> server where it's being ignored, or rather has taken a path
> where it falls foul of some uRPF check. What does packet capture
I think I mentioned this in the original mail - the DISCOVER packet is,
most definitely, arriving at the DHCP server and not being processed.
What's really odd is that further investigation suggests there is some
link to the "seconds" field in the bootp header; if secs==0, the 2nd
DISCOVER is ignored. If secs!=0, it's answered.
In the two cases (secs == / != 0) the log messages have different
formats as well, so I suspect different code paths are being followed.
All very strange.
More information about the dhcp-users