ABOUT DEVCENTRAL

DevCentral News Technical Forum Technical Articles Technical CrowdSRC Community Guidelines DevCentral EULA Get a Developer Lab License Become a DevCentral MVP

RESOURCES

Product Documentation White Papers Glossary Customer Stories Webinars Free Online Courses F5 Certification LearnF5 Training

SUPPORT

Manage Subscriptions Professional Services Professional Services Create a Service Request Software Downloads Support Portal

PARTNERS

Find a Reseller Partner Technology Alliances Become an F5 Partner Login to Partner Central

---

©2024 F5, Inc. All rights reserved.

iCall is BIG-IP's all new (as of BIG-IP version 11.4) event-based automation system for the control plane. Previously, I wrote up the iCall system overview, as well as an article on the use of a periodic handler for automating backups. This article will feature the use of the triggered iCall handler to allow a user to submit a http request to invalidate the cache served up for an application managed by the Application Acceleration Manager.

Starting at the End

Before we get to the solution, I'd like to address the use case for invalidating cache. In many cases, the team responsible for an application's health is not the network services team which is the typical point of access to the BIG-IP. For large organizations with process overhead in generating tickets, invalidating cache can take time. A lot of time. So the request has come in quite frequently...\"How can I invalidate cache remotely?\" Or even more often, \"Can I invalidate cache from an iRule?\" Others have approached this via script, and it has been absolutely possible previously with iRules, albeit through very ugly and very-not-recommended ways. In the end, you just need to issue one TMSH command to invalidate the cache for a particular application:

\n

tmsh::modify wam application content-expiration-time now

\n

So how do we get signal from iRules to instruct BIG-IP to run a TMSH command? This is where iCall trigger handlers come in. Before we hope back to the beginning and discuss the iRule, the process looks like this:

Back to the Beginning

The iStats interface was introduced in BIG-IP version 11 as a way to make data accessible to both the control and data planes. I'll use this to pass the data to the control plane. In this case, the only data I need to pass is to set a key. To set an iStats key, you need to specify :

• Class
• Object
• Measure type (counter, gauge, or string)
• Measure name

I'm not measuring anything, so I'll use a string starting with \"WA policy string\" and followed by the name of the policy. You can be explicit or allow the users to pass it in a query parameter as I'm doing in this iRule below:

\nwhen HTTP_REQUEST {\n  if { [HTTP::path] eq \"/invalidate\" } {\n    set wa_policy [URI::query [HTTP::uri] policy]\n    if { $wa_policy ne \"\" } {\n      ISTATS::set \"WA policy string $wa_policy\" 1\n      HTTP::respond 200 content \"App $wa_policy cache invalidated.\"\n    } else { HTTP::respond 200 content \"Please specify a policy /invalidate?policy=policy_name\" }\n  }\n}\n\n

Setting the key this way will allow you to create as many triggers as you have policies. I'll leave it as an exercise for the reader to make that step more dynamic.

Setting the Trigger

With iStats-based triggers, you need linkage to bind the iStats key to an event-name, wacache in my case. You can also set thresholds and durations, but again since I am not measuring anything, that isn't necessary.

\nsys icall istats-trigger wacache_trigger_istats {\n    event-name wacache\n    istats-key \"WA policy string wa_policy_name\"\n}

Creating the Script

The script is very simple. Clear the cache with the TMSH command, then remove the iStats key.

\nsys icall script wacache_script {\n    app-service none\n    definition {\n      tmsh::modify wam application dc.wa_hero content-expiration-time now\n      exec istats remove \"WA policy string wa_policy_name\"\n    }\n    description none\n    events none\n}

Creating the Handler

The handler is the glue that binds the event I created in the iStats trigger. When the handler sees an event named wacache, it'll execute the wacache_script iCall script.

\nsys icall handler triggered wacache_trigger_handler {\n    script wacache_script\n    subscriptions {\n        messages {\n            event-name wacache\n        }\n    }\n}\n\n

Notes on Testing

1. Add this command to your arsenal - tmsh generate sys icall event <event-name> context none</event-name> where event-name in my case is wacache. This allows you to troubleshoot the handler and script without worrying about the trigger.
2. And this one - tmsh modify sys db log.evrouted.level value Debug. Just note that the default is Notice when you're all done troubleshooting.

iCall is BIG-IP's all new (as of BIG-IP version 11.4) event-based automation system for the control plane. Previously, I wrote up the iCall system overview, as well as an article on the use of a periodic handler for automating backups. This article will feature the use of the triggered iCall handler to allow a user to submit a http request to invalidate the cache served up for an application managed by the Application Acceleration Manager.

Starting at the End

Before we get to the solution, I'd like to address the use case for invalidating cache. In many cases, the team responsible for an application's health is not the network services team which is the typical point of access to the BIG-IP. For large organizations with process overhead in generating tickets, invalidating cache can take time. A lot of time. So the request has come in quite frequently...\"How can I invalidate cache remotely?\" Or even more often, \"Can I invalidate cache from an iRule?\" Others have approached this via script, and it has been absolutely possible previously with iRules, albeit through very ugly and very-not-recommended ways. In the end, you just need to issue one TMSH command to invalidate the cache for a particular application:

\n

tmsh::modify wam application content-expiration-time now

\n

So how do we get signal from iRules to instruct BIG-IP to run a TMSH command? This is where iCall trigger handlers come in. Before we hope back to the beginning and discuss the iRule, the process looks like this:

Back to the Beginning

The iStats interface was introduced in BIG-IP version 11 as a way to make data accessible to both the control and data planes. I'll use this to pass the data to the control plane. In this case, the only data I need to pass is to set a key. To set an iStats key, you need to specify :

• Class
• Object
• Measure type (counter, gauge, or string)
• Measure name

I'm not measuring anything, so I'll use a string starting with \"WA policy string\" and followed by the name of the policy. You can be explicit or allow the users to pass it in a query parameter as I'm doing in this iRule below:

\nwhen HTTP_REQUEST {\n  if { [HTTP::path] eq \"/invalidate\" } {\n    set wa_policy [URI::query [HTTP::uri] policy]\n    if { $wa_policy ne \"\" } {\n      ISTATS::set \"WA policy string $wa_policy\" 1\n      HTTP::respond 200 content \"App $wa_policy cache invalidated.\"\n    } else { HTTP::respond 200 content \"Please specify a policy /invalidate?policy=policy_name\" }\n  }\n}\n\n

Setting the key this way will allow you to create as many triggers as you have policies. I'll leave it as an exercise for the reader to make that step more dynamic.

Setting the Trigger

With iStats-based triggers, you need linkage to bind the iStats key to an event-name, wacache in my case. You can also set thresholds and durations, but again since I am not measuring anything, that isn't necessary.

\nsys icall istats-trigger wacache_trigger_istats {\n    event-name wacache\n    istats-key \"WA policy string wa_policy_name\"\n}

Creating the Script

The script is very simple. Clear the cache with the TMSH command, then remove the iStats key.

\nsys icall script wacache_script {\n    app-service none\n    definition {\n      tmsh::modify wam application dc.wa_hero content-expiration-time now\n      exec istats remove \"WA policy string wa_policy_name\"\n    }\n    description none\n    events none\n}

Creating the Handler

The handler is the glue that binds the event I created in the iStats trigger. When the handler sees an event named wacache, it'll execute the wacache_script iCall script.

\nsys icall handler triggered wacache_trigger_handler {\n    script wacache_script\n    subscriptions {\n        messages {\n            event-name wacache\n        }\n    }\n}\n\n

Notes on Testing

1. Add this command to your arsenal - tmsh generate sys icall event <event-name> context none</event-name> where event-name in my case is wacache. This allows you to troubleshoot the handler and script without worrying about the trigger.
2. And this one - tmsh modify sys db log.evrouted.level value Debug. Just note that the default is Notice when you're all done troubleshooting.

From tmsh

type create sys icall and hit question mark.

Step one: Make an irule-I can do that.

Step two: Setting the trigger-I don't understand where this is created/how it is created. And same issues with the other steps, as well. Can you guide me on those details? We're on 12.1.2.

Hi, thanks for your wonderful explanations on this. In a case, for example, if would like to pass the variable of $wa_policy_name to the script, how can I implement this?

~ tmsh::modify wam application $wa_policy_name content-expiration-time now

Cheers.

Ok I've tried, but how would you make it more dynamic? How do you pass the policy to the trigger and onwards?