Technical Articles
F5 SMEs share good practice.
cancel
Showing results for 
Search instead for 
Did you mean: 
Custom Alert Banner
JRahm
Community Manager
Community Manager

Early last year I blogged an update to the iRules HTTP event order that F5er John Alam put together. John is back with another update to the drawing, this time, however, including the access policy manager flow. This article will cover the APM events as well as a couple new standard events added back in 11.0.

APM Event Flow

There are a plethora of events and commands specific to the access policy manager in iRules, which you can find here on Clouddocs. I’ll focus on the events in this article. Of the eight events, there are only a few events triggered per request.

 

  • ACCESS_ACL_ALLOWED – triggered right after HTTP_REQUEST (and before CACHE_REQUEST, not included in this drawing) for a request that has been allowed by ACLs. ACCESS checks the request for a valid session, valid policy result, and then evaluates ACLs. If ACL allows a request, it raises ACCESS_ACL_ALLOWED before releasing the request to the upper layers.
  • ACCESS_ACL_DENIED – same process as ACCESS_ACL_ALLOWED, but triggered before the request is denied (by redirecting the request to access denied page)
  • REWRITE_REQUEST_DONE – triggered right after ACCESS_ACL_ALLOWED when a portal access resource is accessed.

 

The other events are only triggered at some specific processing for a user’s session and access policy. For the ACCESS_POLICY_* events, even though the user’s flow is utilized, the events are triggered in the context of the APM internal request as dictated by the policy.

 

  • ACCESS_SESSION_STARTED – triggered right after HTTP_REQUEST (before CACHE_REQUEST) when a request is received with no SID or an invalid SID.
  • ACCESS_SESSION_CLOSED – triggered from an internal timer when session is being deleted. This is not triggered in a traffic flow context.
  • ACCESS_POLICY_COMPLETED – triggered when access policy completes.
  • ACCESS_POLICY_AGENT_EVENT – triggered when during access policy execution, and iRule event agent is executed.
  • REWRITE_RESPONSE_DONE – only triggered if REWRITE::post_process is enabled in the REWRITE_REQUEST_DONE event.

 

A majority of the APM flows occur on the request side, as shown below:

 

0151T000003d4CcQAI.png

 

A little further down the processing path on the response flows is the final APM event:

 

0151T000003d4CdQAI.png

 

Hidden Events

For APM internal URIs, like /my.policy and /my.logout, the HTTP_REQUEST/HTTP_RESPONSE events don’t fire as you would expect beginning in v11.x. The traditional method to work around this (and other module complexities) is to use the vip targeting vip configuration, where you can have a backend or frontend (or both!) virtual in which to do your iRule processing and another virtual to host the module (APM/ASM/etc). However, with APM, if you require access in your iRules to these internal URIs, you can use the ACCESS::restrict_irule_events command in the CLIENT_ACCEPTED event to expose them. An example:

 

when CLIENT_ACCEPTED {
  ACCESS::restrict_irule_events disable
}
when HTTP_REQUEST {
  if { [HTTP::uri] ends_with "/my.logout.php3?errorcode=19" } {
    HTTP::redirect "/"
  }
}

 

New Events

The plugin architecture for TMOS that APM uses results in a lost view/inspection point at the iRules level of what exactly hits the wire when the request is released to the server or the client. However, two new events were added in v11.0 to provide these last chance inspection points, aptly named HTTP_REQUEST_RELEASE and HTTP_RESPONSE_RELEASE. On the serverside, you can now inspect what APM (or any other module) has done to the request before it hits the wire on the way to the server, and likewise, on the clientside, what APM has done to the response before it hits the wire on the way to the client.

 

Putting It All Together

Now that the pieces have been dissected, the diagram in its entirety should come together a little easier.

 

0151T000003d4CeQAI.png


Drawing: BIGIP_Events_Visio.pdf

 

Comments
René_Geile
Cirrus
Cirrus
In my testing on v11.4.1 HF3 it seems even without any ACL assigned always an "ACCESS_ACL_ALLOWED" is fired. This would mean the decision step "ACL defined" does not seem to exist. I checked this with logging like the following: when ACCESS_ACL_ALLOWED { log local0.info "Event fired in session [ACCESS::session sid] on URI [HTTP::uri], ACLs assigned: [ACCESS::acl lookup ] ACL matched: [ACCESS::acl matched]" } when ACCESS_ACL_DENIED { log local0.info "Event fired in session [ACCESS::session sid] on URI [HTTP::uri], ACLs assigned: [ACCESS::acl lookup ] ACL matched: [ACCESS::acl matched]" }
Walter_Kacynski
Cirrostratus
Cirrostratus
I have come to the same conclusion in my testing.
Walter_Kacynski
Cirrostratus
Cirrostratus
Where does the HTML_TAG_MATCHED event fall within this diagram?
MAG_114141
Nimbostratus
Nimbostratus
Hi, Looks like summary diagram has mistake."Connection Keepalive" "Yes" decision must be directed to decision "Valid HTTP request", not to EVENT "HTTP_REQUEST"?
Algebraic_Mirror
Cirrostratus
Cirrostratus

One thing this doesn't cover is APM's clientless mode. When in clientless mode, you don't do redirects to my.policy, which means the event flow would be much different than the picture above (the picture above shows you hitting ACCESS_SESSION_STARTED, then responding to the client, and you don't even start the VPE until the second request).

 

How exactly do the events flow when clientless mode is set?

 

Stanislas_Piro2
Cumulonimbus
Cumulonimbus

Hi Jason,

It's really a great drawing which helped me to understand how APM work and to write my own irules.

I have some comments about it :

  1. ACCESS_ACL_DENIED doesn't lead to
    Respond with session terminaison page
    but to
    Respond with denial page
  2. I don't understand
    VPE Allow condition
    . If VPE is not allowed after ACCESS_POLICY_COMPLETED, session is removed so this condition is always true as only valid session are going there.
  3. As René already said,
    ACL Defined
    and
    Evaluate ACL
    must be merge into one with
    Denied by ACL
    , if not denied, ACCESS_ACL_ALLOWED is evaluated even if no ACL is defined.
  4. ACCESS_POLICY_AGENT_EVENT may loop to
    VPE calls irule Event
    as VPE can raise this event multiple times
  5. ACCESS_SESSION_CLOSED is triggered outside of flow context. it doesn't lead to
    Respond with session terminaison page
  6. if
    Valid existing session
    and URI equals APM logout URI (/vdesk/hangup.php3 or /vdesk/my.logout.php3) --> leads to ACCESS_SESSION_CLOSED

Do you agree with these comments? If I am right, is it possible to update the drawing?

Walter_Kacynski
Cirrostratus
Cirrostratus

I am working on some updates for this. Jason, can I get the VSD so I don't have to draw from scratch?

 

JCohen
F5 Employee
F5 Employee

Links to the full size PDFs are broken

JRahm
Community Manager
Community Manager

i fixed the article links. I don't have the source visio, but I'll follow up with the author to see if there is an update to this file.

Walter_Kacynski
Cirrostratus
Cirrostratus

There is a communicaity maintained flowchart available at iRule Event Order Flowchart - DevCentral (f5.com)

Version history
Last update:
‎26-Jun-2012 12:29
Updated by:
Contributors