on 26-Jun-2012 12:29
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.
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.
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.
A majority of the APM flows occur on the request side, as shown below:
A little further down the processing path on the response flows is the final APM event:
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 "/" } }
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.
Now that the pieces have been dissected, the diagram in its entirety should come together a little easier.
Drawing: BIGIP_Events_Visio.pdf
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?
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 :
Respond with session terminaison page
but to Respond with denial page
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.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.VPE calls irule Event
as VPE can raise this event multiple timesRespond with session terminaison page
Valid existing session
and URI equals APM logout URI (/vdesk/hangup.php3 or /vdesk/my.logout.php3) --> leads to ACCESS_SESSION_CLOSEDDo you agree with these comments? If I am right, is it possible to update the drawing?
I am working on some updates for this. Jason, can I get the VSD so I don't have to draw from scratch?
There is a communicaity maintained flowchart available at iRule Event Order Flowchart - DevCentral (f5.com)