Simon Hobson wrote:
> You would need to see what the clients are doing - eg packet capture on the network.
> I would hazard a guess that in example 1, the client broadcast the request and so it was picked up by both servers - this is likely when the client connects to the network and without further tests (which some clients do) cannot know before doing the DHCP request whether it is still on the same network where it got it's lease from.
> In example 2, I suspect the client has unicast it's request to the server it got it's lease from. This is normal where the client already has a working network connection and just wants to renew it's currently active lease. The other server will never see the unicast packet, so it will neither respond to the client nor log anything.
> I don't think this is possible since each server will not see requests unicast to the other server.
I see - I had assumed that the duplicate log messages between the two servers (like in example 1) were due to the dhcpd daemons communicating to keep their logs in sync, rather than the DHCP server simply seeing the exchange on the network. I'll do some wiresharking to confirm this, but ultimately if I shouldn't rely on the syslog file for up-to-date information between peers, my main question is answered.
> Since both servers have a copy of the lease, I guess both are replying - I don't know if that's correct behaviour as I'm not familiar enough with failover.
I agree definitely that this is what it looks like, but from what I understand, the `split 128;` should evenly load balance the client between the two servers, and ultimately only one would reply (which is why I assumed the duplicate DHCPACKs were just the servers logging each other's transactions through the daemon or something).
Niall O'Reilly wrote:
> Static DHCP leases are defined in host { ... } declarations.
> As you probably know, a common method for ensuring resilience is
> to provision the same host { ... } declarations in the configuration
> of each of a number of servers.
> Dynamic leases are assigned from pools defined in pool { ... } declarations.
> Failover peer relationships are also defined in pool { ... } declarations.
> The host { ... } and pool { ... } declarations don't (or shouldn't)
> intersect, as the former are in global scope, and the latter in subnet scope.
Right - our `host { ... }` declarations are the same between servers, as well as the pools (which I believe should be evenly load balanced given our configuration), which don't intersect.
> then I think you may be wishing for something which is not available.
> Consequently, even identifying the appropriate failover peer to notify when
> a static lease is (re-)assigned (let alone delivering the notification) is
> not possible.
> I hope I've not misunderstood, and that this helps.
This makes sense (and goes along with the shared transaction logs being due to multicast packets), since I see static leases aren't held in the dhcpd.leases file. Thanks for the input.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Locked
