Help me make DHCP's documentation better.

[Patrick Schoo]

On Monday 28 August 2006 19:56, David W. Hankins wrote:
> Thanks to all of you for the feedback.  I've written a second pass
> at this, collapsing it all into one (related) section.
>
> On Fri, Aug 18, 2006 at 03:11:38PM +0200, Patrick Schoo wrote:
> > I think MAC Affinity is not a proper description for what it is used for.
> > If I understand the function correctly Lease Affinity would be a better
> > description. A lease either has affinity to 'reside' on the primary, or
> > it has affinity to 'reside' on the secondary. This is an extra property
> > apart from the 'binding state'. For example a lease can have 'binding
> > state active' and also 'affinity secondary'. Once the lease expires it
> > will move to the FREE status, while keeping the 'affinity secondary'
> > property. The lease rebalancer only needs to touch the affinity property,
> > once a misbalance is detected.
>
> That's an interesting distinction, but the property of the affinity
> remains the client identification - be that MAC or client identifier
> option.  So the lease's state has an affinity to its identifier.
>

IMHO the concept of MAC address affinity (or call it client identifier 
affinity) is not a useful property when load balancing the pools. Suppose a 
client enters your network that it has visited before. In this case there is 
a free lease in the leases database that contains the client identifier. When 
a DHCPDISCOVER is broadcasted on the network both servers can find the lease 
in the database and hand out the IP address that belongs to this lease. Even 
when one of the DHCP partners is down the other can hand out the lease, no 
matter whether the lease is in free of backup state. In other words, the 
primary can hand out the lease even if it is in 'backup' state. The secondary 
can hand out the lease even it is in the 'free' state.

Let us look at another scenario where a client enters the network that it has 
never visited before. There is no lease in the database that contains the 
client identifier. The two DHCP servers have to determine whether to allocate 
a lease from the 'free' pool or from the 'backup' pool. Here the split 
parameter comes into play. Assuming the split value is set to 128, in half of 
the cases the primary will hand out a lease from its pool, in the other half 
the secondary will hand out the lease. In failover mode the split value is 
discarded. The only remaining partner will hand out a lease from its 
designated pool. 

So my conclusion is that you need to spread your free leases equally over the 
two pools to cater for outage of one of the servers. But since this is only 
relevant for clients that you have never seen before, balancing the pools 
using the client identifier is not useful.

Please correct me if I am wrong.

Patrick Schoo.
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.