APM Local DB multiple groups
Hi, I'm using APM with localdb authentication and performing a group lookup and resource assign ACLs based on the localdb group. It works well with one group and one set of ACLs per group. But what if I want a user to have ACLs from more than one group? do I assign multiple groups to the user? I've sort of tried this but it did not work. Only ACL from one group are applied. Is this sort of functionality supported or is the group field in localdb meant for only one group?
Order of resource assignment when user assigned multiple network access resources
Good day, What logic or method is used by the F5 APM to choose which network access resource takes affect when a user is assigned multiple network access resources? In my environment (BIG IP Virtual Edition APM+LTM 16.1.4 two node cluster) we are assigning different network access resources based on group membership. Some users are members of multiple groups that are being assigned different resources, which often is resulting them in having the "general user" settings and address pool take affect instead of the Executive settings and pool, to which they are also assigned. I haven't been able to determine the logic that APM is applying to determine which resources take precedence. It doesn't appear to be the order in the Advanced Resource assignment. It almost looks alphabetical. Thanks Chris
cant access to management interface after vpn using apm established
i had configured network access vpn using APM module, i tried to split tunneling the network of my management access, but unfortunately when the vpn established i cant connect to my f5 management interface. i tried to add VS with my pool member is my f5 management ip address, where VS ip address is 1 network with my VPN user, the service is https, and the pool member is my f5 management ip address with service port is 443. and then the result is i can ping my VS but i cant connect to my VS which have the pool member is my f5 management ip address with port 443 any idea how can i access to my F5 after vpn using APM established? really appreciate your help thank you
[APM] ACL Interest
Hi, I'm integrating VPNSSL F5 by using APM since many week. Our users population are susceptible to use the following elements : Portal Access RDP Access Network Access My questions are about Network Access. Today, I use Network Access to allocate the same IP address inside and outside the entreprise (F5 has in interface in all my entreprise LAN). After that I have as many Forwading VS than Entreprise LAN. On each forwarding IP I've I this irule : when CLIENT_ACCEPTED { if { [IP::addr [IP::client_addr] equals 192.168.160.0/255.255.254.0] } { node 192.168.160.1 } else { log local0. "[IP::client_addr] access problem" reject } } This Irule send to gateway 192.168.160.1 if the Network Access IP is in 192.168.160.0/23 range. This system works perfectly but i've questions about that : I've have an ACL that looks like this : Src : 192.168.160.0/23 Destination : 0.0.0.0 Port : Any Allow My firewall are here to do filtering, not APM. Since this morning I realized that if I remove this ACL, nothing change, all works perfectly too. My F5 is not supposed to filter if there is no ACL ? In this case, what is intereset off ACL (only portal mode) ? Thanks a lot for yours answers
APM - Network Access issue solved after policy re-apply
Hello All, we registered a weird behavior with an APM (11.4.2 HF7) guest: users can login correctly into logon page and AD Auth is fine. Then users starts networks access clicking on the "na_icon". It worked for few weeks (a couple of months) with more or less 100 ccu. Suddenly na stopped to work and no one can access to vpn. After a restart of the service apmd the users can start na for few minutes (about 15, half an hour) and then the service fails again. We tried upgrading the APM to 11.5.1 but the issue come up again after few minutes, so we rollback to the 11.4.2 HF7. We set the APM log to debug, test the issue and get the qkview. When the issue arises the only logs you can find are the following (some sensible data has been masqueraded): Apr 16 09:36:33 slot1/*******-*** notice tmm[25747]: 01490549:5: ea787267: Assigned PPP IPv4: "ip_address" Tunnel Type: VPN_TUNNELTYPE_TLS NA Resource: /Common/"policy_name" - Reconnect Apr 16 09:36:33 slot1/*******-*** notice tmm[25747]: 01490505:5: ea787267: PPP tunnel 0x570000fdfa00 started. Apr 16 09:36:34 slot1/*******-*** notice tmm[25747]: 01490505:5: ea787267: PPP tunnel 0x570000fdfa00 closed. After analyzing the qkview without understanding what the problem was, we re-apply the policy and the vpn started to work fine. It's about 3 weeks that the vpn (network access) are working fine. I'm wondering if anyone else had a similar issue with na, solving a huge problem just re-applying the policy without making any changes. Thank you.F5 Access 2018 app shows "Unable to retrieve network access configuration" on iPhone 7 with iOS 12 (beta)
F5 Access 2018 app shows "Unable to retrieve network access configuration" on iPhone 7 with iOS 12 (beta) when we use Web Logon for authentication (for OTP codes). If we choose Native authentication (and remove the requirement for OTP), the VPN establishes just fine. On the server side, "Session deleted due to user logout request." when the user receives the error message. We're using split-tunnel VPN. A user reported getting the above error after upgrading to iOS 12 Beta and installing the F5 Access 2018 app. I have replicated this on a brand new iPhone 7 after upgrading it to iOS 12. Am suspecting this is an iOS 12 Beta bug, but it is a problem nonetheless. See below for the relevant part of the client logs. I also saw this old thread which refers to the exact same "Error 111" message on iOS as seen in the F5 Access client log: https://stackoverflow.com/questions/20454853/nsxmlparsererrordomain-111 Excerpt from client log: PacketTunnelProvider.swift, 477, startTunnel(options:completionHandler:), Session has been established VpnFavoriteListOperation.swift, 110, main(), VPN Favorites failed: Error Domain=NSXMLParserErrorDomain Code=111 "(null)" PacketTunnelProvider.swift, 484, startTunnel(options:completionHandler:), Network parameters have been received PacketTunnelProvider.swift, 487, startTunnel(options:completionHandler:), Failed to get NA settings Internal Error: VPN resource was not found PacketTunnelProvider.swift, 334, displayMessage(_:completionHandler:), Unable to retrieve network access configuration Full log: 2018-07-09,13:23:07:672, 264,7683,PacketTunnel, 48, PacketTunnelProvider.swift, 368, startTunnel(options:completionHandler:), ------------------------------------------------------------ 2018-07-09,13:23:07:684, 264,7683,PacketTunnel, 48, PacketTunnelProvider.swift, 369, startTunnel(options:completionHandler:), Release Version: 3.0.0 2018-07-09,13:23:07:698, 264,7683,PacketTunnel, 48, PacketTunnelProvider.swift, 370, startTunnel(options:completionHandler:), Bundle Version: 3.0.0.224 2018-07-09,13:23:07:704, 264,7683,PacketTunnel, 48, PacketTunnelProvider.swift, 371, startTunnel(options:completionHandler:), Build Date: Fri Mar 2 13:20:26 PST 2018 2018-07-09,13:23:07:709, 264,7683,PacketTunnel, 48, PacketTunnelProvider.swift, 372, startTunnel(options:completionHandler:), Build Type: CM 2018-07-09,13:23:07:712, 264,7683,PacketTunnel, 48, PacketTunnelProvider.swift, 373, startTunnel(options:completionHandler:), Changelist: 2509912 2018-07-09,13:23:07:715, 264,7683,PacketTunnel, 48, PacketTunnelProvider.swift, 374, startTunnel(options:completionHandler:), Locale: engelsk (Norge) 2018-07-09,13:23:07:718, 264,7683,PacketTunnel, 48, PacketTunnelProvider.swift, 375, startTunnel(options:completionHandler:), ------------------------------------------------------------ 2018-07-09,13:23:07:727, 264,7683,PacketTunnel, 48, PacketTunnelProvider.swift, 382, startTunnel(options:completionHandler:), Connection Parameters: Optional("serverAddress: https://fjerntilgang.tine.no,password: ,ignorePassword: false,passwordExpirationTimeStamp: -1,passwordReference: not-set,passwordExpired: falseidentityReference: not-set,postLaunchUrl: ,webLogon: true,launchedByUriScheme: false,vpnScope: device,startType: manual,deviceIdentity: assignedId: ,instanceId: ,udid: ,macAddress: ,serialNumber: ") 2018-07-09,13:23:42:181, 264,7947,PacketTunnel, 48, PacketTunnelProvider.swift, 166, checkForConfigurationUpdate, Request update configuration with "{ "savePasswordEnabled" : false, "weblogonAutoPopulateEnabled" : true, "clearPassword" : false, "enforceWebLogon" : false, "enforceLogonMode" : false, "launchedByUriScheme" : false, "timeStamp" : -1, "logonSucceed" : true }" 2018-07-09,13:23:42:222, 264,7947,PacketTunnel, 48, PacketTunnelProvider.swift, 477, startTunnel(options:completionHandler:), Session has been established (Session ID: c47c4cf6) 2018-07-09,13:23:42:446, 264,12807,PacketTunnel, 1, VpnFavoriteListOperation.swift, 110, main(), VPN Favorites failed: Error Domain=NSXMLParserErrorDomain Code=111 "(null)" 2018-07-09,13:23:42:454, 264,12807,PacketTunnel, 48, PacketTunnelProvider.swift, 484, startTunnel(options:completionHandler:), Network parameters have been received 2018-07-09,13:23:42:459, 264,12807,PacketTunnel, 1, PacketTunnelProvider.swift, 487, startTunnel(options:completionHandler:), Failed to get NA settings Internal Error: VPN resource was not found 2018-07-09,13:23:42:487, 264,12807,PacketTunnel, 1, PacketTunnelProvider.swift, 334, displayMessage(_:completionHandler:), Unable to retrieve network access configurationBIG-IP network access option "Register this connection's addresses in DNS" registers two addresses
Hello, I have enabled the BIG-IP network access option "Register this connection's addresses in DNS" to register the VPN client IP in our companies DNS. The same option is also enabled on all network adapters of our windows machines. The issue I am now expecting is that not only the client IP gets registed but also the physical IP of the network adapter which is in most cases a private IP and useless. Due to this it is luck to get the correct IP when doing a name resolution but i cannot uncheck the box on the physical adapters as the machines would populate the LAN/WiFi IP to the DNS and this would cause problems. Thanks Martin
Part 3: Monitoring the health of BIG-IP APM network access PPP connections with a periodic iCall handler
In this part, you monitor the health of PPP connections on the BIG-IP APM system by monitoring the frequency of a particular log message in the/var/log/apmfile. In this log file, when the system is under high CPU load, you may observe different messages indicating users' VPN connections are disconnecting. For example: You observe multiple of the following messages where the PPP tunnel is started and closed immediately: Mar 13 13:57:57 hostname.example notice tmm3[16095]: 01490505:5: /Common/accessPolicy_policy:Common:ee6e0ce7: PPP tunnel 0x5604775f7000 (ID: 2c4507ea) started. Mar 13 13:57:57 hostname.example notice tmm3[16095]: 01490505:5: /Common/accessPolicy_policy:Common:ee6e0ce7: PPP tunnel 0x560478482000 (ID: acf63e47) closed. You observe an unusually high rate of log messages indicating users' APM sessions terminated due to various reasons in a short span of time. Mar 13 14:01:10 hostname.com notice tmm3[16095]: 01490567:5: /Common/AccessPolicy_policy:Common:a7cf25d9: Session deleted due to user inactivity. You observe an unusually high rate of log messages indicating different user apm session IDs are attempting to reconnect to network access, VPN. Mar 13 12:18:13 hostname notice tmm1[16095]: 01490549:5: /Common/AP_policy:Common:2c321803: Assigned PPP Dynamic IPv4: 10.10.1.20 ID: 033d0635 Tunnel Type: VPN_TUNNELTYPE_TLS NA Resource: /Common/AP_policy_na_res Client IP: 172.2.2.2 – Reconnect In this article, you monitor theReconnectmessage in the last example because it indicates that the VPN connection terminated and the client system still wants to reconnect. When this happens for several users and repeatedly, it usually indicates that the issue is not related to the client side. The next question is, what is an unusually high rate of reconnect messages, taking into account the fact that some reconnects may be due to reasons on the client side and not due to high load on the system. You can create a periodic iCall handler to run a script once every minute. Each time the script runs, it uses grep to find the total number of Reconnect log messages that happened over the last 3 minutes for example. When the average number of entries per minute exceeds a configured threshold, the system can take appropriate action. The following describes the procedures: Creating an iCall script to monitor the rate of reconnect messages Creating a periodic iCall handler to run the iCall script once a minute Testing the implementation using logger 1. Creating an iCall script to monitor the rate of reconnect messages The example script uses the following values: Periodic handler interval 1 minute: This runs the script once a minute to grep the number of reconnect messages logged in the last 3.0 minutes. Period 3.0 minutes: The script greps for the Reconnect messages logged in the last three minutes. Critical threshold value 4: When the average number of Reconnect messages per minute exceeds four or a total of 12 in the last three minutes, the system logs a critical message in the/var/log/apmfile. Alert threshold value 7: When the average number of Reconnect messages per minute exceeds seven or a total of 21 in the last three minutes, the system logs an alert message and requires immediate action. Emergency threshold 10: When the BIG-IP system is logging 10 Reconnect messages or more every minute for the last three minutes or a total of 30 messages, the system logs an emergency message, indicating the system is unusable. You should reconfigure these values at the top of the script according to the behavior and set up of your environment. By performing the count over an interval of three minutes or longer, it reduces the possibility of high number of reconnects due to one-off spikes. Procedure Perform the following procedure to create the script to monitor CPU statistics and log an alert message in the/var/log/ltmfile when traffic exceeds a CPU threshold value. To create an iCall script, perform the following procedure: Log in to tmsh. Enter the following command to create the script in the vi editor: create sys icall script vpn_reconnect_script 3. Enter the following script into the definition stanza in the editor: This script counts the average number of entries/min the Reconnect message is logged in /var/log/apm over a period of 3 minutes. definition { #log file to grep errormsg set apm_log "/var/log/apm" #This is the string to grep for. set errormsg "Reconnect" #num of entries = grep $errormsg $apm_log | grep $hourmin | wc -l #When (num of entries < crit_threshold), no action #When (crit_threshold <= num of entries < alert_threshold), log crtitical message. #When (alert_threshold <= num of entries < emerg_threshold), log alert message. #When (emerg_threhold <= num of entries log emerg message set crit_threshold 4 set alert_threshold 7 set emerg_threshold 10 #Number of minutes to take average of. E.g. Every 1.0, 2.0, 3.0, 4.0... minutes set period 3.0 #Set this to 1 to log to /var/tmp/scriptd.out. Set to 0 to disable. set DEBUG 0 set total 0 puts "\n[clock format [clock seconds] -format "%b %e %H:%M:%S"] Running script..." for {set i 1} {$i <= $period} {incr i} { set hourmin [clock format [clock scan "-$i minute"] -format "%b %e %H:%M:"] set errorcode [catch {exec grep $errormsg $apm_log | grep $hourmin | wc -l} num_entries] if{$errorcode} { set num_entries 0 } if {$DEBUG} {puts "DEBUG: $hourmin \"$errormsg\" logged $num_entries times."} set total [expr {$total + $num_entries}] } set average [expr $total / $period] set average [format "%.1f" $average] if{$average < $crit_threshold} { if {$DEBUG} {puts "DEBUG: $hourmin \"$errormsg\" logged $average times on average. Below all threshold. No action."} exit } if{$average < $alert_threshold} { if {$DEBUG} {puts "DEBUG: $hourmin \"$errormsg\" logged $average times on average. Reached critical threshold $crit_threshold. Log Critical msg."} exec logger -p local1.crit "01490266: \"$errormsg\" logged $average times on average in last $period mins. >= critical threshold $crit_threshold." exit } if{$average < $emerg_threshold} { if {$DEBUG} {puts "DEBUG: $hourmin \"$errormsg\" logged $average times on average. Reached alert threshold $alert_threshold. Log Alert msg."} exec logger -p local1.alert "01490266: \"$errormsg\" logged $average times on average in last $period mins. >= alert threshold $alert_threshold." exit } if {$DEBUG} {puts "DEBUG: $hourmin \"$errormsg\" logged $average times on average in last $period mins. Log Emerg msg"} exec logger -p local1.emerg "01490266: \"$errormsg\" logged $average times on average in last $period mins. >= emerg threshold $emerg_threshold." exit } 4. Configure the variables in the script as needed and exit the editor by entering the following command: :wq! y 5. Run the following command to list the contents of the script: list sys icall script vpn_reconnect_script 2. Creating a periodic iCall handler to run the script In this example, you create the iCall handler to run the script once a minute. You can increase this interval to once every two minutes or longer. However, you should consider this value together with theperiodvalue of the script in the previous procedure to ensure that you're notified on any potential issues early. Procedure Perform the following procedure to create the periodic handler that runs the script once a minute. To create an iCall periodic handler, perform the following procedure: Log in to tmsh. Enter the following command to create a periodic handler: create sys icall handler periodic vpn_reconnect_handler interval 60 script vpn_reconnect_script 3. Run the following command to list the handler: list sys icall handler periodic vpn_reconnect_handler 4. You can start and stop the handler by using the following command syntax: <start|stop> sys icall handler periodic vpn_reconnect_handler 3. Testing the implementation using logger You can use theloggercommand to log test messages to the/var/log/apmfile to test your implementation. To do so, run the following command the required number of times to exceed the threshold you set: Note: The following message must contain the keyword that you are searching for in the script. In this case, the keyword is Reconnect. logger -p local1.notice "01490549:5 Assigned PPP Dynamic IPv4: 10.10.1.20 ID: 033d0635 Tunnel Type: VPN_TUNNELTYPE_TLS NA Resource: /Common/AP_policy_na_res Client IP: 172.2.2.2 - Reconnect" Follow the/var/tmp/scriptd.outand/var/log/apm file entries to verify your implementation is working correctly. Conclusion This article lists three use cases for using iCall to monitor the health of your BIG-IP APM system. The examples mainly log the appropriate messages in the log files. You can extend the examples to monitor more parameters and also perform different kinds of actions such as calling another script (Bash, Perl, and so on) to send an email notification or perform remedial action.Part 2: Monitoring the CPU usage of the BIG-IP system using a periodic iCall handler
In this part series, you monitor the CPU usage of the BIG-IP system with a periodic iCall handler. The specific CPU statistics you want to monitor can be retrieved from either Unix or tmsh commands. For example, if you want to monitor the CPU usage of the tmm process, you can monitor the values from the output of the tmsh show sys proc-info tmm.0 command. An iCall script can iterate and retrieve a list of values from the output of a tmsh command. To display the fields available from a tmsh command that you can iterate from an iCall Tcl script, run the tmsh command with thefield-fmtoption. For example: tmsh show sys proc-info tmm.0 field-fmt You can then use a periodic iCall handler which runs an iCall script periodically every interval to check the value of the output of the tmsh command. When the value exceeds a configured threshold, you can have the script perform an action; for example, an alert message can be logged to the/var/log/ltmfile. The following describes the procedures: Creating an iCall script to monitor the required CPU usage values Creating a periodic iCall handler to run the iCall script once a minute 1. Creating an iCall script to monitor the required CPU usage values There are different Unix and tmsh commands available to display CPU usage. To monitor CPU usage, this example uses the following: tmsh show sys performance system detail | grep CPU: This displays the systemCPU Utilization (%). The script monitors CPU usage from theAveragecolumn for each CPU. tmsh show sys proc-info apmd: Monitors the CPU usage System Utilization (%) Last5-minsvalue of the apmd process. tmsh show sys proc-info tmm.0: Monitors the CPU usage System Utilization (%) Last5-minsvalue of the tmm process. This is the sum of the CPU usage of all threads of thetmm.0process divided by the number of CPUs over five minutes. You can display the number of TMM processes and threads started, by running different commands. For example: pstree -a -A -l -p | grep tmm | grep -v grep grep Start /var/log/tmm.start You can also create your own script to monitor the CPU output from other commands, such astmsh show sys cpuortmsh show sys tmm-info. However, a discussion on CPU usage on the BIG-IP system is beyond the scope of this article. For more information, refer toK14358: Overview of Clustered Multiprocessing (11.3.0 and later)andK16739: Understanding 'top' output on the BIG-IP system. You need to set some of the variables in the script, specifically the threshold values:cpu_perf_threshold, tmm.0_threshold, apmd_thresholdrespectively. In this example, all the CPU threshold values are set at 80%. Note that depending on the set up in your specific environment, you have to adjust the threshold accordingly. The threshold values also depend on the action you plan to run in the script. For example, in this case, the script logs an alert message in the/var/log/ltmfile. If you plan to log an emerg message, the threshold values should be higher, for example, 95%. Procedure Perform the following procedure to create the script to monitor CPU statistics and log an alert message in the/var/log/ltmfile when traffic exceeds a CPU threshold value. To create an iCall script, perform the following procedure: Log in to tmsh. Enter the following command to create the script in the vi editor: create sys icall script cpu_script 3. Enter the following script into the definition stanza of the editor. The 3 threshold values are currently set at 80%. You can change it according to the requirements in your environment. definition { set DEBUG 0 set VERBOSE 0 #CPU threshold in % from output of tmsh show sys performance system detail set cpu_perf_threshold 80 #The name of the process from output of tmsh show sys proc-info to check. The name must match exactly. #If you would like to add another process, append the process name to the 'process' variable and add another line for threshold. #E.g. To add tmm.4, "set process apmd tmm.0 tmm.4" and add another line "set tmm.4_threshold 75" set process "apmd tmm.0" #CPU threshold in % for output of tmsh show sys proc-info set tmm.0_threshold 80 set apmd_threshold 80 puts "\n[clock format [clock seconds] -format "%b %d %H:%M:%S"] Running CPU monitoring script..." #Getting average CPU output of tmsh show sys performance set errorcode [catch {exec tmsh show sys performance system detail | grep CPU | grep -v Average | awk {{ print $1, $(NF-4), $(NF-3), $(NF-1) }}} result] if {[lindex $result 0] == "Blade"} { set blade 1 } else { set blade 0 } set result [split $result "\n"] foreach i $result { set cpu_num "[lindex $i 1] [lindex $i 2]" if {$blade} {set cpu_num "Blade $cpu_num"} set cpu_rate [lindex $i 3] if {$DEBUG} {puts "tmsh show sys performance->${cpu_num}: ${cpu_rate}%."} if {$cpu_rate > $cpu_perf_threshold} { if {$DEBUG} {puts "tmsh show sys performance->${cpu_num}: ${cpu_rate}%. Exceeded threshold ${cpu_perf_threshold}%."} exec logger -p local0.alert "\"tmsh show sys performance\"->${cpu_num}: ${cpu_rate}%. Exceeded threshold ${cpu_perf_threshold}%." } } #Getting output of tmsh show sys proc-info foreach obj [tmsh::get_status sys proc-info $process] { if {$VERBOSE} {puts $obj} set proc_name [tmsh::get_field_value $obj proc-name] set cpu [tmsh::get_field_value $obj system-usage-5mins] set pid [tmsh::get_field_value $obj pid] set proc_threshold ${proc_name}_threshold set proc_threshold [set [set proc_threshold]] if {$DEBUG} {puts "tmsh show sys proc-info-> Average CPU Utilization of $proc_name pid $pid is ${cpu}%"} if { $cpu > ${proc_threshold} } { if {$DEBUG} {puts "$proc_name process pid $pid at $cpu% cpu. Exceeded ${proc_threshold}% threshold."} exec logger -p local0.alert "\"tmsh show sys proc-info\" $proc_name process pid $pid at $cpu% cpu. Exceeded ${proc_threshold}% threshold." } } } 4. Configure the variables in the script as needed and exit the editor by entering the following command: :wq! y 5. Run the following command to list the contents of the script: list sys icall script cpu_script 2. Creating a periodic iCall handler to run the iCall script once a minute Procedure Perform the following procedure to create the periodic handler that runs the script once a minute. To create an iCall periodic handler, perform the following procedure: Log in to tmsh Enter the following command to create a periodic handler: create sys icall handler periodic cpu_handler interval 60 script cpu_script 3. Run the following command to list the handler: list sys icall handler periodic cpu_handler 4. You can start and stop the handler by using the following command syntax: <start|stop> sys icall handler periodic cpu_handler Follow the /var/tmp/scriptd.out and /var/log/ltm file entries to verify your implementation is working correctly.Using iCall to monitor BIG-IP APM network access VPN
Introduction During peak periods, when a large number of users are connected to network access VPN, it is important to monitor your BIG-IP APM system's resource (CPU, memory, and license) usage and performance to ensure that the system is not overloaded and there is no impact on user experience. If you are a BIG-IP administrator, iCall is a tool perfectly suited to do this for you. iCall is a Tcl-based scripting framework that gives you programmability in the control plane, allowing you to script and run Tcl and TMOS Shell (tmsh) commands on your BIG-IP system based on events. For a quick introduction to iCall, refer to iCall - All New Event-Based Automation System. Overview This article is made up of three parts that describe how to use and configure iCall in the following use cases to monitor some important BIG-IP APM system statistics: Part 1: Monitoring access sessions and CCU license usage of the system using a triggered iCall handler Part 2: Monitoring the CPU usage of the system using a periodic iCall handler. Part 3: Monitoring the health of BIG-IP APM network access VPN PPP connections with a periodic iCall handler. In all three cases, the design consists of identifying a specific parameter to monitor. When the value of the parameter exceeds a configured threshold, an iCall script can perform a set of actions such as the following: Log a message to the /var/log/apm file at the appropriate severity: emerg: System is unusable alert: Action must be taken immediately crit: Critical conditions You may then have another monitoring system to pick up these messages and respond to them. Perform a remedial action to ease the load on the BIG-IP system. Run a script (Bash, Perl, Python, or Tcl) to send an email notification to the BIG-IP administrator. Run the tcpdump or qkview commands when you are troubleshooting an issue. When managing or troubleshooting iCall scripts and handler, you should take into consideration the following: You use the Tcl language in the editor in tmsh to edit the contents of scripts and handlers. For example: create sys icall script <name of script> edit sys icall script <name of script> The puts command outputs entries to the /var/tmp/scriptd.out file. For example: puts "\n[clock format [clock seconds] -format "%b %d %H:%M:%S"] Running script..." You can view the statistics for a particular handler using the following command syntax: show sys icall handler <periodic | perpetual | triggered> <name of handler> Series 1: Monitoring access sessions and CCU license usage with a triggered iCall handler You can view the number of currently active sessions and current connectivity sessions usage on your BIG-IP APM system by entering the tmsh show apm license command. You may observe an output similar to the following: -------------------------------------------- Global Access License Details: -------------------------------------------- total access sessions: 10.0M current active sessions: 0 current established sessions: 0 access sessions threshold percent: 75 total connectivity sessions: 2.5K current connectivity sessions: 0 connectivity sessions threshold percent: 75 In the first part of the series, you use iCall to monitor the number of current access sessions and CCU license usage by performing the following procedures: Modifying database DB variables to log a notification when thresholds are exceed. Configuring user_alert.conf to generate an iCall event when the system logs the notification. Creating a script to respond when the license usage reaches its threshold. Creating an iCall triggered handler to handle the event and run an iCall script Testing the implementation using logger 1. Modifying database variables to log a notification when thresholds are exceeded. The tmsh show apm license command displays the access sessions threshold percent and access sessions threshold percent values that you can configure with database variables. The default values are 75. For more information, refer to K62345825: Configuring the BIG-IP APM system to log a notification when APM sessions exceed a configured threshold. When the threshold values are exceeded, you will observe logs similar to the following in /var/log/apm: notice tmm1[<pid>]: 01490564:5: (null):Common:00000000: Global access license usage is 1900 (76%) of 2500 total. Exceeded 75% threshold of total license. notice tmm2[<pid>]: 01490565:5: 00000000: Global concurrent connectivity license usage is 393 (78%) of 500 total. Exceeded 75% threshold of total license. Procedure: Run the following commands to set the threshold to 95% for example: tmsh modify /sys db log.alertapmaccessthreshold value 95 tmsh modify /sys db log.alertapmconnectivitythreshold value 95 Whether to set the alert threshold at 90% or 95%, depends on your specific environment, specifically how fast the usage increases over a period of time. 2. Configuring user_alert.conf to generate an iCall event when the system logs the notification You can configure the /config/user_alert.conf file to run a command or script based on a syslog message. In this step, edit the user_alert.conf file with your favorite editor, so that the file contains the following stanza. alert <name> "<string in syslog to match to trigger event>" { <command to run> } For more information on configuring the /config/user_alert.conf file, refer to K14397: Running a command or custom script based on a syslog message. In particular, it is important to read the bullet points in the Description section of the article first; for example, the system may not process the user_alert.conf file after system upgrades. In addition, BIG-IP APM messages are not processed by the alertd SNMP process by default. So you will also have to perform the steps described in K51341580: Configuring the BIG-IP system to send BIG-IP APM syslog messages to the alertd process as well. Procedure: Perform the following procedure: Edit the /config/user_alert.conf file to match each error code and generate an iCall event named apm_threshold_event. Per K14397 Note: You can create two separate alerts based on both error codes or alternatively use the text description part of the log message common to both log entries to capture both in a single alert. For example "Exceeded 75% threshold of total license" # cat /config/user_alert.conf alert apm_session_threshold "01490564:" { exec command="tmsh generate sys icall event apm_threshold_event" } alert apm_ccu_threshold "01490565:" { exec command="tmsh generate sys icall event apm_threshold_event" } 2. Run the following tmsh command: edit sys syslog all-properties 3. Replace the include none line with the following: Per K51341580 include " filter f_alertd_apm { match (\": 0149[0-9a-fA-F]{4}:\"); }; log { source(s_syslog_pipe); filter(f_alertd_apm); destination(d_alertd); }; " 3. Creating a script to respond when the license usage reaches its threshold. When the apm session or CCU license usage exceeds your configured threshold, you can use a script to perform a list of tasks. For example, if you had followed the earlier steps to configure the threshold values to be 95%, you can write a script to perform the following actions: Log a syslog alert message to the /var/log/apm file. If you have another monitoring system, it can pick this up and respond as well. Optional: Run a tmsh command to modify the Access profile settings. For example, when the threshold exceeds 95%, you may want to limit users to one apm session each, decrease the apm access profile timeout or both. Changes made only affect new users. Users with existing apm sessions are not impacted. If you are making changes to the system in the script, it is advisable to run an additional tmsh command to stop the handler. When you have responded to the alert, you can manually start the handler again. Note: When automating changes to the system, it is advisable to err on the side of safety by making minimal changes each time and only when required. In this case, after the system reaches the license limit, users cannot login and you may need to take immediate action. Procedure: Perform the following procedure to create the iCall script: 1. Log in to tmsh. 2. Run the following command: create sys icall script threshold_alert_script 3. Enter the following in the editor: Note: The tmsh commands to modify the access policy settings have been deliberately commented out. Uncomment them when required. sys icall script threshold_alert_script { app-service none definition { exec logger -p local1.alert "01490266: apm license usage exceeded 95% of threshold set." #tmsh::modify apm profile access exampleNA max-concurrent-sessions 1 #tmsh::modify apm profile access exampleNA generation-action increment #tmsh::stop sys icall handler triggered threshold_alert_handler } description none events none } 4. Creating an iCall triggered handler to handle the event and run an iCall script In this step, you create a triggered iCall handler to handle the event triggered by the tmsh generate sys icall event command from the earlier step to run the script. Procedure: Perform the following: 1. Log in to tmsh. 2. Enter the following command to create the triggered handler. create sys icall handler triggered threshold_alert_handler script threshold_alert_script subscriptions add { apm_threshold_event { event-name apm_threshold_event } } Note: The event-name field must match the name of the event in the generate sys icall command in /config/user_alert.conf you configured in step 2. 3. Enter the following command to verify the configuration of the handler you created. (tmos)# list sys icall handler triggered threshold_alert_handler sys icall handler triggered threshold_alert_handler { script threshold_alert_script subscriptions { apm_threshold_event { event-name apm_threshold_event } } } 5. Testing the implementation using logger You can use theloggercommand to log test messages to the/var/log/apmfile to test your implementation. To do so, run the following command: Note: The message below must contain the keyword that you are searching for in the script. In this example, the keyword is01490564or01490565. logger -p local1.notice "01490564:5: (null):Common:00000000: Global access license usage is 1900 (76%) of 2500 total. Exceeded 75% threshold of total license." logger -p local1.notice "01490565:5: 00000000: Global concurrent connectivity license usage is 393 (78%) of 500 total. Exceeded 75% threshold of total license." Follow the /var/log/apm file to verify your implementation is working correctly.
