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.

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.

Events

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/10.2.80.1:80 monitor status down" {
   exec command="tmsh generate sys icall event tcpdump context { { name ip value 10.2.80.1 } { name port value 80 } { name vlan value internal } { name count value 20 } }"
}

Handlers

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

Triggered

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
        }
    }
}
Periodic

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
}
Perpetual

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
}

Scripts

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
}

Resources

Updated Jun 06, 2023
Version 2.0

Was this article helpful?

10 Comments

  • Jason, can you elaborate a little more on the perpetual events options?

     

    When I look at this example "; I see "subscriptions" and "event-name FAILOVER_STATE".

     

    Is the there an exhaustive list on the options available somewhere? I have a hard time finding documentation for iCall and iScript. I got this feeling that this is a hidden gold mine for really some nice solutions. I would hate to let that go to waste :-)

     

  • The articles on DevCentral and the codeshare samples are the extent of the iCall documentation at this time.

     

    For a perpetual handler, the script often contains the event and the actions desired. The "daemon" behavior is a while loop in the script, made system efficient by utilizing the EVENT::get_next command to "sleep" between events.

     

    I'd be happy to add some additional iCall articles if you have some specific content inquiries, maybe a few example walk throughs of each type of handler?

     

  • Thanks for your reply Jason.

     

    What options exist under "subscriptions" and are there other possibilities other than that one?

     

    I lack imagination at the moment (enjoying my summer holidays) but I think I will keep iCall in the back of my head as it really seems like something that I could make use of down the road.

     

    Basically it would be a great start to just get a list of all the different option flags available under the different handlers. From that I might get some ideas to increase the F5 coolness even further ;-)

     

  • you can subscribe to one or more events with which to act on. There's an iCall lab I'll see about making public, will keep you posted.

     

  • Hi Jason, all,

     

    As inxgeek mentioned, would be anywhere list of the pre-defined system events, that can be used for the subscription? Particularly, I'd be interested in those related to pool member/node state changes...

     

    The only examples I've found use the FAILOVER_STATE event.

     

    Thanks in advance :)

     

  • Hi @sedas, it's less about having predefined events and more about "eventizing" whatever you deem to be worthy of an event that will report into iCall triggered handlers. The key is the

    tmsh generate sys icall event
    command, which can be used in the user_alert.conf file like this:

    alert pool_down_message_70 "Pool /Common/10.10.10.61 member /Common/10.10.10.70:80 monitor status down." {
      exec command="tmsh generate sys icall event pool_member_down_event context { { name ip value 10.10.10.70 } {name port value 80 } }"
    }
    

    Or could be used in your own { bash, perl, python, tmsh } scripts as well.

  • Hi Jason,

    Thanks for the reply. Ok, I understand the way you mentioned, my concern there is that if we need to pass the pool name (or even the member name) to the script, I need to create a special rule for each.

    We are about to have about 10 pools, 12 members each. It means at least 10 (basically the same) rules for each pool if we don't need to pass the member name to the script; or, 10*12 rules should both pool and member name be passed to the script, eventually.

    That's hardly manageable from operations point of view...

    An option would be if it's possible to include wildcard/regex patterns on the "alert" line, which could be referred to later on from the "exec" line, like for example below, but I understand that's not possible(?):

    alert POOL_MEMBER_UP "Pool (.*?) member (.*?):(.*?) monitor status up" {
          exec command="tmsh generate sys icall event NODE_UP context {
            { name poolname value &1 }
            { name memberip value &2 }
            { name memberport value &3 }
          }";
    }
    

    If you have an idea, how could we trigger a script and pass the affected pool/member name to it, please let me know. It would be appreciated 🙂

    Thanks a lot, Pavel

  • I think it would be better to write a tmsh script to check status and raise events as necessary, rather than relying on alertd. This codeshare script could be enhanced to include conditions for event raising.