DHCP w/ FHRP and duplicate requests
All, I haven't had the chance to try FR DHCP yet, but I ran into a problem with ISC yesterday and I thought I'd mention something worth considering. If you have something like VRRP/HSRP for first-hop resilience, both routers will forward the DHCP packet, and you'll get two copies that differ only in giaddr, very close together in time. For fixed IPs this isn't usually a problem, but if you're allocating a lease by DB lookup, I guess it would be possible for 2 DISCOVERs to get 2 different OFFERs, particularly if you're threaded. I'm wondering if the radius "duplicate packet detection" code could be re-used here? It seems like rlm_cache would probably run "too late"? Note that you do have to respond to both packets; if you don't, the one you do respond to might fail uRPF check because it might be routed by router A, but directed to router B, and will thus arrive at router B with an invalid source for the ingress interface. ISC sort-of does the right thing here unless you've got ping-check enabled and it's an initial lease allocation *or* you've got delayed-ack enabled for fsync performance. In that case it drops the 2nd duplicate and you run into uRPF problems. Anyway, just a thought.
On 12 Mar 2014, at 11:24, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
All,
I haven't had the chance to try FR DHCP yet, but I ran into a problem with ISC yesterday and I thought I'd mention something worth considering.
If you have something like VRRP/HSRP for first-hop resilience, both routers will forward the DHCP packet, and you'll get two copies that differ only in giaddr, very close together in time.
For fixed IPs this isn't usually a problem, but if you're allocating a lease by DB lookup, I guess it would be possible for 2 DISCOVERs to get 2 different OFFERs, particularly if you're threaded.
I'm wondering if the radius "duplicate packet detection" code could be re-used here?
It seems like rlm_cache would probably run "too late"?
Why do you think it would be run too late? Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
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.
On 12 Mar 2014, at 15:16, Phil Mayers <p.mayers@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@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 12/03/14 15:46, Arran Cudbard-Bell wrote:
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.
I'll be honest; it's looking increasingly unlikely I'll have time to play with FR DHCP in the near term, so don't do this on my account! I merely mention the issue for your info and as a chance to be superior to ISC ;o)
Phil Mayers wrote:
I'll be honest; it's looking increasingly unlikely I'll have time to play with FR DHCP in the near term, so don't do this on my account! I merely mention the issue for your info and as a chance to be superior to ISC ;o)
We'll definitely look into it. Alan DeKok.
Phil Mayers wrote:
I'm wondering if the radius "duplicate packet detection" code could be re-used here?
Not really. You'd need DHCP-specific duplicate detection. In addition, you want *two* responses sent, whereas for RADIUS, you suppress one of the responses. Arran and I have talked about some re-designs of the server core which would help this. It's one more step to gradually pulling RADIUS out of the core, and making the server protocol-agnostic.
It seems like rlm_cache would probably run "too late"?
Maybe. But it would also mean you'd be subject to race conditions, which is bad.
Note that you do have to respond to both packets; if you don't, the one you do respond to might fail uRPF check because it might be routed by router A, but directed to router B, and will thus arrive at router B with an invalid source for the ingress interface.
That's protocol-specific.
ISC sort-of does the right thing here unless you've got ping-check enabled and it's an initial lease allocation *or* you've got delayed-ack enabled for fsync performance. In that case it drops the 2nd duplicate and you run into uRPF problems.
The design Arran and I came up with means you should be able to do this kind of thing without too much code. But it will be a while before it's done. Alan DeKok.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Phil Mayers