Forum Discussion
NimbostratusHTTP profile and an ACCESS profile in the same virtual server for 11.x iRule
Hi everyone, I have a question which I think would be simple to solve if I knew how to ask it better.
I've upgraded from 10.2.4 to 11.4.0 and it broke my iRule as F5 stated "By default from 11.0.0 onward, HTTP and higher layer iRule events are not raised for the internal access control URIs" which is here: https://devcentral.f5.com/wiki/iRules.ACCESS__restrict_irule_events.ashx No big deal because that same page has an iRule almost exactly like what I'm using and it just has you disable restrict_irule_events by adding when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } to the top of your iRule. So my iRule would look like this: when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when HTTP_REQUEST { if { [HTTP::uri] contains "/nbbs5/tr69" }{ pool Conversation-Router-Pool } else { pool nBBS5-Pool } }
But it won't save because the load balancer wants an ACCESS profile set up in my Virtual Server. So my problem is I already have an HTTP profile set up and I need to figure out how to use an HTTP profile and an ACCESS profile in the same virtual server. Whew!
2 Replies
- Kevin_Stewart
Employee
Access profiles are controlled by the Access Policy Manager (APM) module. If you have that module licensed and provisioned, you'll see options near the bottom of the virtual server properties page to set an access profile. APM profiles require an HTTP profile to also be applied.
By the way, you can actually skip the whole ACCESS::restrict_irule_events thing by moving your HTTP request logic to the ACCESS_ACL_ALLOWED event. It's mostly synonymous with HTTP_REQUEST but is triggered after access policy evaluation. Doing HTTP evaluation in the HTTP_REQUEST event with an acces profile applied can get dicey as the HTTP_REQUEST will get triggered before the access policy starts (and potentially disrupt the access policy processing), and after the access policy completes. The ACCESS::restrict_irule_events command allows you to see the HTTP events that happen inside policy evaluation, but that too can be dangerous depending on what you're trying to do.
Skip_01_134365Thank you Kevin! I'm reading about ACCESS_ACL_ALLOWED right after I send this. That looks like the better choice for what I'm doing.
