Run a sync-config from iCall
Hi, I am wrinting a iCall which modify the configuration with tmsh::modify. I have a cluster of Big-IP so after the command tmsh::modify change the configuration, I have to run a config-sync. My question is how to run a config-sync from a iCall? I can not find any command unless maybe with exec. Thank you. Regards,329Views0likes2CommentsiCall Script that only runs on Active member
Problem this snippet solves: I had a request to run an iCall script only on the active member in a pair. How to use this snippet: This won't work if you're using active/active via traffic-groups. Code : # Only execute if local BIG-IP is active in failover if {[exec cat /var/prompt/ps1] == "Active"} { tmsh::log "I LIKE SOUP!" } Tested this on version: 12.1705Views0likes2CommentsModifying iCall from TMSH
Hi, I've created an iCall script from TMSH, but now I have to modify it. Creating a script from TMSH is fine, no problem, but modifying is a bit more troublesome. (tmos)# modify /sys icall script myscript Syntax Error: one or more properties must be specified (tmos)# modify /sys icall script myscript definition Syntax Error: the script "definition" must be enclosed in { } I was hoping that the script would open in an editor like it does when you run "create /sys icall script". Which method is the best way to create and modify scripts? /eljaySolved554Views0likes2CommentsNot working my iCall script...
Problem this snippet solves: Hello~ I created iCall and generate event for working iCall's script. But.... It is not working. list sys icall script change_iRule2 sys icall script change_iRule2 { app-service none definition { tmsh::modify ltm virtual v_198.100__443 rules { vip_snatpool } tmsh::modify ltm virtual v_198.101__443 rules { vip_snatpool } } description none events none } list sys icall handler triggered change_iRule2{ script change_iRule2 subscriptions { change_iRule2 { event-name change_iRule2 } } } I gernerated event generate sys icall event change_iRule2 And I checked bellow status...... Sys::iCall::Event Triggered Handler: change_iRule2 Events matching filters 11 Events causing handler to run 11 Creation time 01/24/17 16:38:35 Current status active Time since last status change 01/24/17 16:38:35 But, Configuration(virtual server's iRule) is not change.... Plz help me. T..T Code : sys icall script change_iRule2 { app-service none definition { tmsh::modify ltm virtual v_198.100__443 rules { vip_snatpool } tmsh::modify ltm virtual v_198.101__443 rules { vip_snatpool } } description none events none } create sys icall handler triggered change_iRule2 script change_iRule2 subscriptions add { change_iRule2 { event-name change_iRule2 } }719Views0likes0Comments[icall] kill oldest sessions when reaching xx% of the APM license limit
Problem this snippet solves: When dealing with APM authentication, especially when the F5 device act as a SAML 2.0 IDP, the active sessions can increase considerably and easily reach the max access session limit of the license or the device. The following icall script allows an administrator to guarantee that new users can still authenticate through APM IDP under heavy load. The script will kill oldest active access sessions based on the access session consumption. This is a draft that need to be fine tuned. Warning: when using APM Guest on a vCMP host, we are not able to guarantee that the appliance limit is not reached as we just have knowledge of the active sessions within the guest context only. How to use this snippet: TMSH command to create an icall script create sys icall script apm_purge_sessions Then copy/paste the content of the icall script and save it. By default, the command create a script named "apm_purge_sessions". You can easily change the name of the script by modifying "apm_purge_sessions" in the command line. TMSH command to create the icall handler The following command trigger the script every 60 seconds. It can be changed to increase the frequency of the execution of the script. create sys icall handler periodic f5-apm-purge-session interval 60 script apm_purge_sessions Interesting tcl commands used in the script Retrieve the max_access_session variable in the license of the device: [string trim [lindex [split [exec /usr/bin/tmsh show /sys license detail | grep access] " "] 1] "\[\]"] retrieve the ordered list (oldest first) of active APM sessionIDs catch {set output [exec /usr/bin/sessiondump --allkeys | grep starttime | sort -k3 | cut -c1-8]} Use cases kill oldest sessions when reaching xx% of the APM license limit Evolution trigger the icall script based on a specific event (snmptrap, log, ...) sort APM sessions by Access Profile and kill sessions based on the criticity of each AP. Code : # retrieve the ordered list of active APM sessionIDs catch {set output [exec /usr/bin/sessiondump --allkeys | grep starttime | sort -k3 | cut -c1-8]} if {$output != ""} { # move the output to a list of sessionID set output [split $output "\n"] set count [llength $output] # determine the max_access_session allowed for the running platform set max_access [string trim [lindex [split [exec /usr/bin/tmsh show /sys license detail | grep access] " "] 1] "\[\]"] # determine acceptable threshold before triggering set access_threshold [expr round($max_access*0.85)] set diff [expr $count-$access_threshold] # kill oldest APM sessions until reaching 85% of active sessions in the APM device for {set i 0} {$i < $diff} {incr i} { catch { [exec /usr/bin/sessiondump --delete [lindex $output $i]] } } } Tested this on version: 11.6556Views0likes0CommentsWhat 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 iCall Codeshare Lightboard Lessons on iCall Threshold violation article highlighting periodic handler7.4KViews2likes10CommentsGenerate qkview or ucs on failover
Problem this snippet solves: This iCall script collects a qkview and a UCS after a failover event. It is hardcoded for traffic-group-1. How to use this snippet: Implementation Details This iCall script requires v11.4 or higher. The script can be loaded via: load sys config merge file /var/tmp/handle-failover.conf Code : sys icall script detect-failover { app-service none definition { # prime the iApp to assume it's standby so that it doesn't generate # a qkview+ucs on the initial run (which wouldn't be a state # transition) set old_status standby while { 1 } { # this will block until another event is present. As we only # subscribe to HA events, that means that whenever an event is # raised it represents a new message from SOD EVENT::get_next set new_status $EVENT::context(/Common/traffic-group-1) # detect if we just went standby if { $new_status eq "standby" && $old_status ne "standby" } { puts "failover detected - i am standby now!" set date [clock format [clock seconds] -format "%Y%m%d%H%M%S"] set settings [tmsh::get_config sys global-settings] set host [tmsh::get_field_value [lindex $settings 0] hostname] puts "generating qkview /var/tmp/$host-$date.qkview" exec /usr/bin/qkview -f /var/tmp/$host-$date.qkview 2> /dev/null & puts "generating UCS /var/local/ucs/$host-$date.ucs" tmsh::save sys ucs /var/local/ucs/$host-$date.ucs } # save the state set old_status $new_status } } description none events none } sys icall handler perpetual handle-failover { script detect-failover subscriptions { failover { event-name FAILOVER_STATE } } }492Views0likes2CommentsF5 LTM customized Packet cloning
Hello every body I have an application using SMPP, SMPP is TCP based protocol and it establish sessions to send traffic, SMPP has unique command IDs to Establish session and tear them up, below image is simple protocol flow: In below example in packet 8 in attached tcpdump, you will see under SMPP (Short Message Peer to Peer) layer a command ID: 0x00000009 which represent bind command (establish a connection/SMPP session). What I need to similar to customized clone pool concept but on pool member level and on certain condition, I need an iRule or may be an iCall procedure to check for SMPP bind command by scanning packet PDU, similar example is below: https://devcentral.f5.com/questions/balancing-smpp-traffic-based-on-recipient-address when CLIENT_ACCEPTED { set s_seq_idx 1 set first_bind_resp 1 set smsc1 set smsc2 TCP::collect } when CLIENT_DATA { while { [TCP::payload length] > 16 } { binary scan [TCP::payload] IH8IIa* len oper status seq p if { [TCP::payload length] < $len &&} // We need here to add check for bind command id as well { TCP::collect $len return } My challenge is to replicate SMPP bind packet to all available pool members in certain pool 😃 , Once SMPP Bind packet is replicated, as result we will get established SMPP sessions with all available pool members, and F5 LTM then will be able to load-balance other incoming traffic with all pool members as far as connection is established. If concept is OK, the rest is not challenging as we need to consider other bind command IDs to be replicated (0x00000001, 0x00000002 and 0x00000009), and of course we need to replicate unbind as well 0x00000006 if possible. Thank you so much in advance. Sincerely, SAM548Views0likes6CommentsiCall CRL update with Route Domains and Auto-Sync
Problem this snippet solves: iCall script to update CRL file within F5 BIG-IP when the HTTP request must run from a specific Route Domain and also uses logger to write logs to the default LTM location. The original was to also update an iFile of the CRL file for use within an iRule however I have removed that due to it being a very special case (I may add another snippet later to detail that one). Important point here is we update the CRL file located within a folder (or partition) that was linked to a Sync-Only Device Group with auto-sync enabled e.g. CRL files are created and saved to /Common/ crl / This way the iCall script does not need to trigger any sort sync and the rest of the configuration can be left as manual sync. Code : sys icall handler periodic /Common/someCrl-CrlUpdate { arguments { { name rd value 2 } { name url value https://172.31.0.1/somepath/to/crlUpdateFile.crl } { name host value somecrl.CADomein.com } { name folder value tempCrlDirectory } { name sslCrl value /Common/crl/someCrlFile.crl } } interval 600 script /Common/iCallCrlUpdate } sys icall script /Common/iCallCrlUpdate { app-service none definition { set logTag "iCallCrlUpdate" set logLevel "notice" # Getting handler provided arguments foreach arg { rd url host folder sslCrl ifileCrl } { set $arg $EVENT::context($arg) } # Create a directory to save files to disk set crlDir /var/tmp/$folder exec mkdir -p $crlDir exec /bin/logger -i -t $logTag -p local0.$logLevel "Running, CRL URL=$url, Host=$host, SSL CRL=$sslCrl, iFile CRL=$ifileCrl, Directory=$crlDir, rd=$rd" # Download CRL file from provided route domain (rd) and url arguments and save to temporary directory set status [exec /usr/bin/rdexec $rd /usr/bin/curl-apd -s -o $crlDir/LatestCRL.crl -w %{http_code} -H Host:$host $url] if {$status == 200} { # Update F5 SSL CRL file tmsh::modify sys file ssl-crl $sslCrl source-path file:$crlDir/LatestCRL.crl exec /bin/logger -t $logTag -p local0.$logLevel "F5 CRL files update complete." } else { exec /bin/logger -i -t $logTag -p local0.error "Command /usr/bin/rdexec $rd /usr/bin/curl-apd -s -o $crlDir/LatestCRL.crl -w '%{http_code}' -H 'Host: onsitecrl.trustwise.com' $url, failed with status=$status" } } description none events none } Tested this on version: 12.1751Views2likes0CommentsIcall, get availability status of gtm virtual server.
Hello everyone, I have an iCall script which checks the status of DNS VS and if the VS is offline the script will do something. Now I trying to check the status via next command: [tmsh::get_field_value [lindex [tmsh::get_status "/gtm server /Common/server virtual-servers { /Common/some_vs }"] 0] "status.availability-state"] But this command return the status of DNS server, not DNS VS. How I can take the status only DNS VS? Help needed! Thanks.270Views0likes1Comment