Correct Failover / DHCPOFFER functionality

[Robert Hille]

Thanks for the reply Claus and David,

Actually, Claus is half right about the log. I went back to confirm that 
I might have miss-anonymized to log :)

I didn't, both dhcp-07 and dhcp-08 tried to reply via the same IP to 
start with. However, the log went on a a bit. Here is the extended, less 
anonymized version:

Jun 29 06:08:32 ns-dhcp-07 dhcpd: DHCPDISCOVER from 00:1d:4f:xx:xx:xx 
via xx.xx.87.254
Jun 29 06:08:32 ns-dhcp-08 dhcpd: DHCPDISCOVER from 00:1d:4f:xx:xx:xx 
via xx.xx.87.253
Jun 29 06:08:33 ns-dhcp-08 dhcpd: DHCPOFFER on 10.144.150.154 to 
00:1d:4f:xx:xx:xx (iPod-96) via xx.xx.87.253
Jun 29 06:08:33 ns-dhcp-07 dhcpd: DHCPOFFER on 10.144.150.32 to 
00:1d:4f:xx:xx:xx (iPod-96) via xx.xx.87.254
Jun 29 06:08:34 ns-dhcp-07 dhcpd: uid lease 10.144.150.32 for client 
00:1d:4f:xx:xx:xx is duplicate on shared-wireless
Jun 29 06:08:34 ns-dhcp-07 dhcpd: uid lease 10.144.150.32 for client 
00:1d:4f:xx:xx:xx is duplicate on shared-wireless
Jun 29 06:08:36 ns-dhcp-08 dhcpd: DHCPREQUEST for 10.144.150.154 
(10.136.20.4) from 00:1d:4f:xx:xx:xx (iPod-96) via xx.xx.87.253
Jun 29 06:08:36 ns-dhcp-08 dhcpd: DHCPACK on 10.144.150.154 to 
00:1d:4f:xx:xx:xx (iPod-96) via xx.xx.87.253
Jun 29 06:08:36 ns-dhcp-07 dhcpd: DHCPREQUEST for 10.144.150.154 
(10.136.20.4) from 00:1d:4f:xx:xx:xx via xx.xx.87.253
Jun 29 06:08:36 ns-dhcp-07 dhcpd: DHCPACK on 10.144.150.154 to 
00:1d:4f:xx:xx:xx (iPod-96) via xx.xx.87.253
Jun 29 06:08:37 ns-dhcp-08 dhcpd: DHCPREQUEST for 10.144.150.154 
(10.136.20.4) from 00:1d:4f:xx:xx:xx (iPod-96) via xx.xx.87.253
Jun 29 06:08:37 ns-dhcp-08 dhcpd: DHCPACK on 10.144.150.154 to 
00:1d:4f:xx:xx:xx (iPod-96) via xx.xx.87.253
Jun 29 06:08:37 ns-dhcp-07 dhcpd: DHCPREQUEST for 10.144.150.154 
(10.136.20.4) from 00:1d:4f:xx:xx:xx (iPod-96) via xx.xx.87.254
Jun 29 06:08:37 ns-dhcp-07 dhcpd: DHCPACK on 10.144.150.154 to 
00:1d:4f:xx:xx:xx (iPod-96) via xx.xx.87.254
Jun 29 06:08:38 ns-dhcp-08 dhcpd: DHCPREQUEST for 10.144.150.154 
(10.136.20.4) from 00:1d:4f:xx:xx:xx (iPod-96) via xx.xx.87.254
Jun 29 06:08:38 ns-dhcp-08 dhcpd: DHCPACK on 10.144.150.154 to 
00:1d:4f:xx:xx:xx (iPod-96) via xx.xx.87.254

So I get a DISCOVER from both x.x.87.253 and x.x.87.254
So I OFFER an IP to back to both x.x.87.253 and x.x.87.254
There is some uid stuff
dhcp-08 gets a REQUEST from x.x.87.253 and ACKs
dhcp-07 gets a REQUEST from x.x.87.253 and ACK (same IP)
dhcp-08 gets a REQUEST from x.x.87.253 and ACKs (same IP)(again!)
dhcp-07 gets a REQUEST from x.x.87.254 and ACK (same IP)
dhcp-07 gets a REQUEST from x.x.87.254 and ACK (same IP)

So I'm seeing multiple REQUEST/ACKs after the fact.

So what is the normal behavior in failover? Should I see a matched pair 
of DISCOVER, OFFER, REPLY, ACK on both severs, or should only the 
DISCOVERS be duplicated?

Thanks again,
Rchille

Claus Holm Christensen wrote:
> Robert Hille skrev:
>> The entire DHCPDISCOVER->DHCPOFFER->DCHPREQUEST->DHCPACK is duplicated.
> 
> Please note the "via x.x.x.x" extension of the log message.  It shows 
> that one DISCOVER was forwarded by the .254 router, the other DISCOVER 
> by the .253 router.  The OFFER is returned to the client through both 
> routers.
> 
> Since the client don't have an IP address yet, the REQUEST goes out by 
> broadcast as well, both routers forward the request and the server 
> answer through both routers as well.  This isn't exactly correct from 
> your logs, but I have a feeling that you may have anonymized the log a 
> little and made a small mistake on the last two lines :-)
> 
> Later the client will try to renew the lease with unicast REQUEST/ACK 
> messages, but this time the exchange shouldn't be duplicated in the logs.
> 
>> This doesn't occur on all subnets, and from the reading I'm doing I'm 
>> beginning to wonder if it might be network related, maybe something 
>> with the helper addresses on the routers?
> 
> I think you're right on suspecting the network, I have exactly the same 
> pattern in my logs, and this always happend on the VLANs with two 
> routers attached, running some sort of failover.  I don't remember it on 
> the VLANs with only one router alone.
> 
>