dhcpd sporadically ignoring one of two "copies" of a DHCP request

[Phil Mayers]

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
>    show?

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.