Devcentral Basics - What is iCall

tl;dr - iCall is BIG-IP’s event-based granular automation system that enables comprehensive control over configuration and other system settings and objects.

The main programmability points of entrance for BIG-IP are the data plane, the control plane, and the management plane. My bare bones description of the three:

  • Data Plane - Client/server traffic on the wire and flowing through devices
  • Control Plane - Tactical control of local system resources
  • Management Plane - Strategic control of distributed system resources

You might think iControl (our SOAP and REST API interface) fits the description of both the control and management planes, and whereas you’d be technically correct, iControl is better utilized as an external service in management or orchestration tools. The beauty of iCall is that it’s not an API at all—it’s lightweight, it’s built-in via tmsh, and it integrates seamlessly with the data plane where necessary (via iStats.) It is what we like to call control plane scripting.

Data plane control plane

Do you remember relations and set theory from your early pre-algebra days? I thought so!  Let me break it down in a helpful way:

P = {(data plane, iRules), (control plane, iCall), (management plane, iControl)}

iCall allows you to react dynamically to an event at a system level in real time. It can be as simple as generating a qkview in the event of a failover or executing a tcpdump on a server with too many failed logins. One use case I’ve considered from an operations perspective is in the event of a core dump to have iCall generate a qkview, take checksums of the qkview and the dump file, upload the qkview and generate a support case via the iHealth API, upload the core dumps to support via ftp with the case ID generated from iHealth, then notify the ops team with all the appropriate details. If I had a solution like that back in my customer days, it would have saved me 45 minutes easy each time this happened!

iCall Components

Three are three components to iCall: events, handlers, and scripts.


An event is really what drives the primary reason to use iCall over iControl. A local system event (whether it’s a failover, excessive interface or application errors, too many failed logins) would ordinarily just be logged or from a system perspective, ignored altogether. But with iCall, events can be configured to force an action. At a high level, an event is "the message," some named object that has context (key value pairs), scope (pool, virtual, etc), origin (daemon, iRules), and a timestamp. Events occur when specific, configurable, pre-defined conditions are met. Example (placed in /config/user_alert.conf)

alert local-http-10-2-80-1-80-DOWN "Pool /Common/my_pool member /Common/ monitor status down" {
   exec command="tmsh generate sys icall event tcpdump context { { name ip value } { name port value 80 } { name vlan value internal } { name count value 20 } }"


Within the iCall system, there are three types of handlers: triggered, periodic, and perpetual.


A triggered handler is used to listen for and react to an event. Example (goes with the event example from above:)

sys icall handler triggered tcpdump {
    script tcpdump
    subscriptions {
        tcpdump {
            event-name tcpdump

A periodic handler is used to react to an interval timer. Example:

sys icall handler periodic poolcheck {
    first-occurrence 2017-07-14:11:00:00
    interval 60
    script poolcheck

A perpetual handler is used under the control of a deamon. Example:

handler perpetual core_restart_watch
sys icall handler perpetual core_restart_watch {
    script core_restart_watch


And finally, we have the script! This is simply a tmsh script moved under the /sys icall area of the configuration that will “do stuff" in response to the handlers. Example (continuing the tcpdump event and triggered handler from above:)

modify script tcpdump {
    app-service none
    definition {
        set date [clock format [clock seconds] -format "%Y%m%d%H%M%S"]
        foreach var { ip port count vlan } {
            set $var $EVENT::context($var)
        exec tcpdump -ni $vlan -s0 -w /var/tmp/${ip}_${port}-${date}.pcap -c $count host $ip and port $port
    description none
    events none