Help me make DHCP's documentation better.
Patrick Schoo
Patrick.Schoo at nl.compuware.com
Tue Aug 29 09:36:01 UTC 2006
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.
More information about the dhcp-users
mailing list