DHCP w/ FHRP and duplicate requests

Arran Cudbard-Bell a.cudbardb at freeradius.org
Wed Mar 12 16:46:23 CET 2014


On 12 Mar 2014, at 15:16, Phil Mayers <p.mayers at IMPERIAL.AC.UK> wrote:

> On 12/03/14 11:41, Arran Cudbard-Bell wrote:
> 
>>> It seems like rlm_cache would probably run "too late"?
>> 
>> Why do you think it would be run too late?
> 
> You've got to populate the cache *after* you've done lease lookup, which unless you set threadpool_size == 1, could lead to the following:
> 
> thread 1: check cache
> thread 1: sqlippool <suspended>
> thread 2: check cache
> thread 2: sqlippool
> thread 1: sqlippool <resumes>
> thread 1: populate cache
> thread 2: populate cache
> 
> The duplicate detection and "get in queue for pending lease lookup" logic needs to happen before you do any lease processing.

I guess as a short term solution we could add an rlm_mutex.

mutex dhcp_discover {
	key = "%{various dhcp attributes}"
}

%{dhcp_discover:lock}
%{dhcp_discover:unlock}

You prevent subsequent requests from progressing, until the first request completes. Then you know a cache entry will have been created.

That's fairly horrific, and you could easily use up the entire threadpool, but it probably going to be the only sensible way to do this in v3.0.x.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20140312/a2a9cd95/attachment.pgp>


More information about the Freeradius-Devel mailing list