Forum Discussion

Kyle_S's avatar
Kyle_S
Icon for Nimbostratus rankNimbostratus
Sep 14, 2012

APM - Adding a working iRule to an APM iRule event

I have this iRule that works on sending requests to different pools based on URI keywords. It works great but i am now trying to incorporate it into the APM Access Policy. I am using the iRule editor but it doesn't like the format of the code. How do I trigger the ACCESS_POLICY_AGENT_EVENT for APM?

 

Here is the working iRule:

 

when HTTP_REQUEST {

 

switch -glob [string tolower [HTTP::uri]] {

 

"/" -

 

"/myabc/*" -

 

"/claims/*" -

 

"/client/*" -

 

"/claimsdesktop/*" {pool Pool_new}

 

"/services/*" {pool Pool_app}

 

"/infoapp/*" {pool Pool_bo}

 

default {pool Pool_legacy}

 

}

 

}

 

This is the ACCESS_POLICY_AGENT_EVENT i am trying to add:

 

when ACCESS_POLICY_AGENT_EVENT {

 

if {[ACCESS::policy agent_id] == "decide"} {

 

 

9 Replies

  • Using the iRule Event object in the VPE. That event will only fire when the connection is running through the policy and reaches the iRule Event object.

     

     

    Eric
  • Kyle_S's avatar
    Kyle_S
    Icon for Nimbostratus rankNimbostratus
    Yes. I am going to use the keyword "decide" as the iRule Event ID. I am going to add the iRule event into the Access Policy but how do I write the iRule? I can't just put the line" when ACCESS_POLICY_AGENT_EVENT " on top of the existing rule..can I? The editor didn't like that the "when" statement didn't have an action to it.

     

     

     

  • You wouldn't be able to use ACCESS_POLICY_AGENT_EVENT to do pool selection based on URI, since that event only fires one time as the policy is being evaluated. Once the allow or deny has occurred, the policy does not run through again.

     

     

    Eric
  • ACCESS_POLICY_AGENT_EVENT is regular event, so the following works:

     

     

    when ACCESS_POLICY_AGENT_EVENT {

     

    log local0. "do something..."

     

    }

     

     

    To amplify Eric's comments though, this event can actually be triggered multiple times inside the access policy. That's why you need to do the ACCESS::session agent_id check to make sure you're processing the right stuff at the right time. Now as far as pooling based on URI, understand that while the connection is inside the access policy process, no traffic is going to the application. There are potentially several 302 redirects that occur before the final redirect back to the application URI signalling the end of the policy. So you need to wait until after the access policy has completed. Probably one of the easiest places to do that is in the ACCESS_ACL_ALLOWED event, which fires on every request AFTER the policy has been completed.

     

  • Kyle_S's avatar
    Kyle_S
    Icon for Nimbostratus rankNimbostratus
    I thought that I could have used the iRule event before the Allow. I was hoping to complete the Access Policy by having the iRule Event forward the traffic to the appropriate pool. Currently the traffic goes through the APM and gets sent to the Default Pool selected in the Virtual Server resources tab. I have the iRule above working on a different VS directing to different pools by the URI keywords but I do not have an Access Policy used at this time. The Access Policy would be used for AD_AUTH, Logon page, and SSO credentials. I am alittle confused on using the ACCESS_ACL_ALLOWED event. I thought that was to use a L4 or L7 access list for permitting or denying; not directing to a certain pool.

     

     

    BTW, thanks for all the help
  • For what it's worth, APM now (11.1 I believe) sports a pool resource assignment in the VPE.

     

     

    Otherwise, you can use ACCESS_ACL_ALLOWED in very much the same way as HTTP_REQUEST. The thing to consider about these three events, ACCESS_ACL_ALLOWED, HTTP_REQUEST, and ACCESS_POLICY_AGENT_EVENT is *when* they are triggered.

     

     

    ACCESS_POLICY_AGENT_EVENT fires during the policy processing and before any traffic is directed to the application. In fact, it's not until the end of the access policy that a 302 redirect is issued back to the application path.

     

     

    HTTP_REQUEST fires on every request. It fires before the access policy starts, and on every request after the policy has ended. You can certainly do URI-based redirection in this event, but you have to be mindful of where you are in the access policy process. An easy way to do this is to first check for the presence of some access policy session variable.

     

     

    ACCESS_ACL_ALLOWED, as mentioned, behaves very much like HTTP_REQUEST, but only fires AFTER the policy is complete.

     

  • i created an irule and associated it with the virtual server using APM.

    when ACCESS_POLICY_AGENT_EVENT { set agentid [ACCESS::policy agent_id] switch $agentid : : }

    In the VPE I have constructed a flow that should trigger this iRule more than once with different event agent id's. I have a log local0. and see that the first one works fine, but it doesn't seem to trigger the iRule again when it flows to another iRule item.

    Start -> Logon Page -> iRule -> RADIUS Auth -> Success -> iRule Event1

                                                  Fallback -> iRule Event2
    

    I get the log for the first iRule but nothing for iRule Event1 or iRule Event2.

    what gives?

  • seems that if it is on the success side of the RADIUS Auth the iRule triggers. the iRule on the 'fallback' side does not trigger.

     

  • I just tried this on 11.3 HF5 and the iRule event is triggered on the fallback branch. If you put a message box on the fallback branch, do you see that when Radius Auth fails?