Forum Discussion

Rene_C_'s avatar
Rene_C_
Icon for Nimbostratus rankNimbostratus
Sep 01, 2017

Policy evaluate in iRule and high load

Hi,

 

just wanted to get some opinions here, maybe other people are having similar issues.

 

We have many irules which do call access policies through access::policy evaluate (i.e. basic auth endpoints, which then do a simple ldap auth in the policy). We dont want the backend to handle auth itself, since the f5 should stay as the second line of defense (first one would be the perimeter fw).

 

Now, what i saw was that there is one apmd process per tmm process (in our case we have a vcmp guest with 2 cores -> 1 tmm -> 1 apmd). AND apmd / calls to apmd do not get queued in any way. That actually means, if there is a request to apmd while another policy is still executing, it doesnt get processed. Sometimes we get an exception back to the irule, sometimes we just get a timeout of the access session and an empty result.

 

Pretty bad, and i probably wouldnt have the solution designed that way with irules if i knew the limitations with apmd beforehand.

 

What i am now thinking of, is actually the access::policy evaluate in irules more to be seen as a gimmick than a useful feature? I mean, with erroring out if there are concurrent calls to apmd its far from being suited for a high load environment, which is why one would take a F5 in first place.

 

And, will the same issue happen with policies directly attached to virtuals, or do they have some pooling magic for apmd calls?

 

Thanks, Rene

 

1 Reply

  • Hi,

    ACCESS::policy evaluate
    goal is to evaluate an access policy to take a decision. the access policy will not have traffic through. I used it to convert a APM policy to a radius server (VS listening radius requests, then evaluate authentication by APM)

    If the irule evaluate HTTP_REQUEST event, use clientless mode instead of

    ACCESS::policy evaluate
    .