Introducing the F5 Application Study Tool (AST)
In the ever-evolving world of application delivery and security, gaining actionable insights into your infrastructure and applications has become more critical than ever. The Application Study Tool (AST) is designed to help technical teams and administrators leverage the power of open-source telemetry and visualization tools to enhance their monitoring, diagnostics, and analysis workflows.Mitigating OWASP Web Application Risk: Vulnerable and Outdated Components using F5 BIG-IP
This article provides information on the Struts 2 vulnerability (CVE-2017-5638) , one of the dangers posed by vulnerable and outdated components. It highlights how a single unpatched vulnerability in a widely used framework can lead to catastrophic consequences, including data breaches, server compromise, and damage to an organisation's reputation and how we can protect it using F5 BIG-IP Advanced WAF.Mitigating OWASP Web App Risks: Software and Data Integrity Failures using BIG-IP Advanced WAF
This article gives detailed information of OWASP top 10 Web Application security series, providing an in-depth knowledge on OWASP Software and Data Integrity attacks and mitigate methods using F5 BIG-IP Advanced WAF.F5 BIG-IP deployment with Red Hat OpenShift - keeping client IP addresses and egress flows
Controlling the egress traffic in OpenShift allows to use the BIG-IP for several use cases: Keeping the source IP of the ingress clients Providing highly scalable SNAT for egress flows Providing security functionalities for egress flowsHow to get a F5 BIG-IP VE Developer Lab License
(applies to BIG-IP TMOS Edition) To assist operational teams teams improve their development for the BIG-IP platform, F5 offers a low cost developer lab license. This license can be purchased from your authorized F5 vendor. If you do not have an F5 vendor, and you are in either Canada or the US you can purchase a lab license online: CDW BIG-IP Virtual Edition Lab License CDW Canada BIG-IP Virtual Edition Lab License Once completed, the order is sent to F5 for fulfillment and your license will be delivered shortly after via e-mail. F5 is investigating ways to improve this process. To download the BIG-IP Virtual Edition, log into my.f5.com (separate login from DevCentral), navigate down to the Downloads card under the Support Resources section of the page. Select BIG-IP from the product group family and then the current version of BIG-IP. You will be presented with a list of options, at the bottom, select the Virtual-Edition option that has the following descriptions: For VMware Fusion or Workstation or ESX/i: Image fileset for VMware ESX/i Server For Microsoft HyperV: Image fileset for Microsoft Hyper-V KVM RHEL/CentoOS: Image file set for KVM Red Hat Enterprise Linux/CentOS Note: There are also 1 Slot versions of the above images where a 2nd boot partition is not needed for in-place upgrades. These images include _1SLOT- to the image name instead of ALL. The below guides will help get you started with F5 BIG-IP Virtual Edition to develop for VMWare Fusion, AWS, Azure, VMware, or Microsoft Hyper-V. These guides follow standard practices for installing in production environments and performance recommendations change based on lower use/non-critical needs for development or lab environments. Similar to driving a tank, use your best judgement. Deploying F5 BIG-IP Virtual Edition on VMware Fusion Deploying F5 BIG-IP in Microsoft Azure for Developers Deploying F5 BIG-IP in AWS for Developers Deploying F5 BIG-IP in Windows Server Hyper-V for Developers Deploying F5 BIG-IP in VMware vCloud Director and ESX for Developers Note: F5 Support maintains authoritative Azure, AWS, Hyper-V, and ESX/vCloud installation documentation. VMware Fusion is not an official F5-supported hypervisor so DevCentral publishes the Fusion guide with the help of our Field Systems Engineering teams.
APM Configuration to Support Duo MFA using iRule
Overview BIG-IP APM has supported Duo as an MFA provider for a long time with RADIUS-based integration. Recently, Duo has added support for Universal Prompt that uses Open ID Connect (OIDC) protocol to provide two-factor authentication. To integrate APM as an OIDC client and resource server, and Duo as an Identity Provider (IdP), Duo requires the user’s logon name and custom parameters to be sent for Authentication and Token request. This guide describes the configuration required on APM to enable Duo MFA integration using an iRule. iRules addresses the custom parameter challenges by generating the needed custom values and saving them in session variables, which the OAuth Client agent then uses to perform MFA with Duo. This integration procedure is supported on BIG-IP versions 13.1, 14.1x, 15.1x, and 16.x. To integrate Duo MFA with APM, complete the following tasks: 1. Choose deployment type: Per-request or Per-session 2. Configure credentials and policies for MFA on the DUO web portal 3. Create OAuth objects on the BIG-IP system 4. Configure the iRule 5. Create the appropriate access policy/policies on the BIG-IP system 6. Apply policy/policies and iRule to the APM virtual server Choose deployment type APM supports two different types of policies for performing authentication functions. Per-session policies: Per-session policies provide authentication and authorization functions that occur only at the beginning of a user’s session. These policies are compatible with most APM use cases such as VPN, Webtop portal, Remote Desktop, federation IdP, etc. Per-request policies: Per-request policies provide dynamic authentication and authorization functionality that may occur at any time during a user’s session, such as step-up authentication or auditing functions only for certain resources. These policies are only compatible with Identity Aware Proxy and Web Access Management use cases and cannot be used with VPN or webtop portals. This guide contains information about setting up both policy types. Prerequisites Ensure the BIG-IP system has DNS and internet connectivity to contact Duo directly for validating the user's OAuth tokens. Configure credentials and policies for MFA on Duo web portal Before you can protect your F5 BIG-IP APM Web application with Duo, you will first need to sign up for a Duo account. 1. Log in to the Duo Admin Panel and navigate to Applications. 2. Click Protect an application. Figure 1: Duo Admin Panel – Protect an Application 3. Locate the entry for F5 BIG-IP APM Web in the applications list and click Protect to get the Client ID, Client secret, and API hostname. You will need this information to configure objects on APM. Figure 2: Duo Admin Panel – F5 BIG-IP APM Web 4. As DUO is used as a secondary authentication factor, the user’s logon name is sent along with the authentication request. Depending on your security policy, you may want to pre-provision users in Duo, or you may allow them to self-provision to set their preferred authentication type when they first log on. To add users to the Duo system, navigate to the Dashboard page and click the Add New... -> Add User button. A Duo username should match the user's primary authentication username. Refer to the https://duo.com/docs/enrolling-users link for the different methods of user enrollment. Refer to Duo Universal Prompt for additional information on Duo’s two-factor authentication. Create OAuth objects on the BIG-IP system Create a JSON web key When APM is configured to act as an OAuth client or resource server, it uses JSON web keys (JWKs) to validate the JSON web tokens it receives from Duo. To create a JSON web key: 1. On the Main tab, select Access > Federation > JSON Web Token > Key Configuration. The Key Configuration screen opens. 2. To add a new key configuration, click Create. 3. In the ID and Shared Secret fields, enter the Client ID and Client Secret values respectively obtained from Duo when protecting the application. 4. In the Type list, select the cryptographic algorithm used to sign the JSON web key. Figure 3: Key Configuration screen 5. Click Save. Create a JSON web token As an OAuth client or resource server, APM validates the JSON web tokens (JWT) it receives from Duo. To create a JSON web token: 1. On the Main tab, select Access > Federation > JSON Web Token > Token Configuration. The Token Configuration screen opens. 2. To add a new token configuration, click Create. 3. In the Issuer field, enter the API hostname value obtained from Duo when protecting the application. 4. In the Signing Algorithms area, select from the Available list and populate the Allowed and Blocked lists. 5. In the Keys (JWK) area, select the previously configured JSON web key in the allowed list of keys. Figure 4: Token Configuration screen 6. Click Save. Configure Duo as an OAuth provider APM uses the OAuth provider settings to get URIs on the external OAuth authorization server for JWT web tokens. To configure an OAuth provider: 1. On the Main tab, select Access > Federation > OAuth Client / Resource Server > Provider. The Provider screen opens. 2. To add a provider, click Create. 3. In the Name field, type a name for the provider. 4. From the Type list, select Custom. 5. For Token Configuration (JWT), select a configuration from the list. 6. In the Authentication URI field, type the URI on the provider where APM should redirect the user for authentication. The hostname is the same as the API hostname in the Duo application. 7. In the Token URI field, type the URI on the provider where APM can get a token. The hostname is the same as the API hostname in the Duo application. Figure 5: OAuth Provider screen 8. Click Finished. Configure Duo server for APM The OAuth Server settings specify the OAuth provider and role that Access Policy Manager (APM) plays with that provider. It also sets the Client ID, Client Secret, and Client’s SSL certificates that APM uses to communicate with the provider. To configure a Duo server: 1. On the Main tab, select Access > Federation > OAuth Client / Resource Server > OAuth Server. The OAuth Server screen opens. 2. To add a server, click Create. 3. In the Name field, type a name for the Duo server. 4. From the Mode list, select how you want the APM to be configured. 5. From the Type list, select Custom. 6. From the OAuth Provider list, select the Duo provider. 7. From the DNS Resolver list, select a DNS resolver (or click the plus (+) icon, create a DNS resolver, and then select it). 8. In the Token Validation Interval field, type a number. In a per-request policy subroutine configured to validate the token, the subroutine repeats at this interval or the expiry time of the access token, whichever is shorter. 9. In the Client Settings area, paste the Client ID and Client secret you obtained from Duo when protecting the application. 10. From the Client's ServerSSL Profile Name, select a server SSL profile. Figure 6: OAuth Server screen 11. Click Finished. Configure an auth-redirect-request and a token-request Requests specify the HTTP method, parameters, and headers to use for the specific type of request. An auth-redirect-request tells Duo where to redirect the end-user, and a token-request accesses the authorization server for obtaining an access token. To configure an auth-redirect-request: 1. On the Main tab, select Access > Federation > OAuth Client / Resource Server > Request. The Request screen opens. 2. To add a request, click Create. 3. In the Name field, type a name for the request. 4. For the HTTP Method, select GET. 5. For the Type, select auth-redirect-request. 6. As shown in Figure 7, specify the list of GET parameters to be sent: request parameter with value depending on the type of policy For per-request policy: %{subsession.custom.jwt_duo} For per-session policy: %{session.custom.jwt_duo} client_id parameter with type client-id response_type parameter with type response-type Figure 7: Request screen with auth-redirect-request (Use “subsession.custom…” for Per-request or “session.custom…” for Per-session) 7. Click Finished. To configure a token-request: 1. On the Main tab, select Access > Federation > OAuth Client / Resource Server > Request. The Request screen opens. 2. To add a request, click Create. 3. In the Name field, type a name for the request. 4. For the HTTP Method, select POST. 5. For the Type, select token-request. 6. As shown in Figure 8, specify the list of POST parameters to be sent: client_assertion parameter with value depending on the type of policy For per-request policy: %{subsession.custom.jwt_duo_token} For per-session policy: %{session.custom.jwt_duo_token} client_assertion_type parameter with value urn:ietf:params:oauth:client-assertion-type:jwt-bearer grant_type parameter with type grant-type redirect_uri parameter with type redirect-uri Figure 8: Request screen with token-request (Use “subsession.custom…” for Per-request or “session.custom…” for Per-session) 7. Click Finished. Configure the iRule iRules gives you the ability to customize and manage your network traffic. Configure an iRule that creates the required sub-session variables and usernames for Duo integration. Note: This iRule has sections for both per-request and per-session policies and can be used for either type of deployment. To configure an iRule: 1. On the Main tab, click Local Traffic > iRules. 2. To create an iRules, click Create. 3. In the Name field, type a name for the iRule. 4. Copy the sample code given below and paste it in the Definition field. Replace the following variables with values specific to the Duo application: <Duo Client ID> in the getClientId function with Duo Application ID. <Duo API Hostname> in the createJwtToken function with API Hostname. For example, https://api-duohostname.com/oauth/v1/token. <JSON Web Key> in the getJwkName function with the configured JSON web key. Note: The iRule ID here is set as JWT_CREATE. You can rename the ID as desired. You specify this ID in the iRule Event agent in Visual Policy Editor. when ACCESS_POLICY_AGENT_EVENT { if { [ACCESS::policy agent_id] eq "JWT_CREATE" } { set duo_uname [ACCESS::session data get "session.logon.last.username"] # Inline logic for creating JWT set header "{\"alg\":\"HS512\",\"typ\":\"JWT\"}" set exp [expr {[clock seconds] + 900}] set client_id "<Duo Client ID>" set redirect_uri "https://[ACCESS::session data get session.server.network.name]/oauth/client/redirect" set payload "{\"response_type\": \"code\",\"scope\":\"openid\",\"exp\":${exp},\"client_id\":\"${client_id}\",\"redirect_uri\":\"${redirect_uri}\",\"duo_uname\":\"${duo_uname}\"}" set jwt_duo [ACCESS::oauth sign -header $header -payload $payload -alg HS512 -key "<JSON Web Key>"] ACCESS::session data set session.custom.jwt_duo $jwt_duo # JWT Token creation set aud "<Duo API Hostname>" set jti [string range [clock seconds] 0 31] set token_payload "{\"sub\": \"${client_id}\",\"iss\":\"${client_id}\",\"aud\":\"${aud}\",\"exp\":${exp},\"jti\":\"${jti}\"}" set jwt_duo_token [ACCESS::oauth sign -header $header -payload $token_payload -alg HS512 -key "<JSON Web Key>"] ACCESS::session data set session.custom.jwt_duo_token $jwt_duo_token } } when ACCESS_PER_REQUEST_AGENT_EVENT { if { [ACCESS::perflow get perflow.irule_agent_id] eq "JWT_CREATE" } { set duo_uname [ACCESS::session data get "session.logon.last.username"] set header "{\"alg\":\"HS512\",\"typ\":\"JWT\"}" set exp [expr {[clock seconds] + 900}] set client_id "<Duo Client ID>" set redirect_uri "https://[ACCESS::session data get session.server.network.name]/oauth/client/redirect" set payload "{\"response_type\": \"code\",\"scope\":\"openid\",\"exp\":${exp},\"client_id\":\"${client_id}\",\"redirect_uri\":\"${redirect_uri}\",\"duo_uname\":\"${duo_uname}\"}" set jwt_duo [ACCESS::oauth sign -header $header -payload $payload -alg HS512 -key "<JSON Web Key>"] ACCESS::perflow set perflow.custom $jwt_duo # JWT Token creation set aud "<Duo API Hostname>" set jti [string range [clock seconds] 0 31] set token_payload "{\"sub\": \"${client_id}\",\"iss\":\"${client_id}\",\"aud\":\"${aud}\",\"exp\":${exp},\"jti\":\"${jti}\"}" set jwt_duo_token [ACCESS::oauth sign -header $header -payload $token_payload -alg HS512 -key "<JSON Web Key>"] ACCESS::perflow set perflow.scratchpad $jwt_duo_token } } Note: iRule updated 11/27/2024 to eliminate CMP demotion. Figure 9: iRule screen 5. Click Finished. Create the appropriate access policy/policies on the BIG-IP system Per-request policy Skip this section for a per-session type deployment The per-request policy is used to perform secondary authentication with Duo. Configure the access policies through the access menu, using the Visual Policy Editor. The per-request access policy must have a subroutine with an iRule Event, Variable Assign, and an OAuth Client agent that requests authorization and tokens from an OAuth server. You may use other per-request policy items such as URL branching or Client Type to call Duo only for certain target URIs. Figure 10 shows a subroutine named duosubroutine in the per-request policy that handles Duo MFA authentication. Figure 10: Per-request policy in Visual Policy Editor Configuring the iRule Event agent The iRule Event agent specifies the iRule ID to be executed for Duo integration. In the ID field, type the iRule ID as configured in the iRule. Figure 11: iRule Event agent in Visual Policy Editor Configuring the Variable Assign agent The Variable Assign agent specifies the variables for token and redirect requests and assigns a value for Duo MFA in a subroutine. This is required only for per-request type deployment. Add sub-session variables as custom variables and assign their custom Tcl expressions as shown in Figure 12. subsession.custom.jwt_duo_token = return [mcget {perflow.scratchpad}] subsession.custom.jwt_duo = return [mcget {perflow.custom}] Figure 12: Variable Assign agent in Visual Policy Editor Configuring the OAuth Client agent An OAuth Client agent requests authorization and tokens from the Duo server. Specify OAuth parameters as shown in Figure 13. In the Server list, select the Duo server to which the OAuth client directs requests. In the Authentication Redirect Request list, select the auth-redirect-request configured earlier. In the Token Request list, select the token-request configured earlier. Some deployments may not need the additional information provided by OpenID Connect. You could, in that case, disable it. Figure 13: OAuth Client agent in Visual Policy Editor Per-session policy Configure the Per Session policy as appropriate for your chosen deployment type. Per-request: The per-session policy must contain at least one logon page to set the username variable in the user’s session. Preferably it should also perform some type of primary authentication. This validated username is used later in the per-request policy. Per-session: The per-session policy is used for all authentication. A per-request policy is not used. Figures 14a and 14b show a per-session policy that runs when a client initiates a session. Depending on the actions you include in the access policy, it can authenticate the user and perform actions that populate session variables with data for use throughout the session. Figure 14a: Per-session policy in Visual Policy Editor performs both primary authentication and Duo authentication (for per-session use case) Figure 14b: Per-session policy in Visual Policy Editor performs primary authentication only (for per-request use case) Apply policy/policies and iRule to the APM virtual server Finally, apply the per-request policy, per-session policy, and iRule to the APM virtual server. You assign iRules as a resource to the virtual server that users connect. Configure the virtual server’s default pool to the protected local web resource. Apply policy/policies to the virtual server Per-request policy To attach policies to the virtual server: 1. On the Main tab, click Local Traffic > Virtual Servers. 2. Select the Virtual Server. 3. In the Access Policy section, select the policy you created. 4. Click Finished. Figure 15: Access Policy section in Virtual Server (per-request policy) Per-session policy Figure 16 shows the Access Policy section in Virtual Server when the per-session policy is deployed. Figure 16: Access Policy section in Virtual Server (per-session policy) Apply iRule to the virtual server To attach the iRule to the virtual server: 1. On the Main tab, click Local Traffic > Virtual Servers. 2. Select the Virtual Server. 3. Select the Resources tab. 4. Click Manage in the iRules section. 5. Select an iRule from the Available list and add it to the Enabled list. 6. Click Finished.
F5 Distributed Cloud Security Service Insertion With BIG-IP Advanced WAF
In this article we will show you how to quickly deploy and operate external services of your choice across multiple public clouds. For this article I will select the BIG-IP Advanced WAF (PAYG), future articles will cover additional solutions. Co-Author: Anitha Mareedu, Sr. Security Engineer, F5 Introduction F5’s Distributed Cloud Securtiy Service Insertion solution allows enterprises to deploy and operate external services of their choice across multiple public clouds. Let's start by looking at a real-world customer example. The enterprise has standardized on an external firewall in their private data center. Their network and security team are very familiar with using BIG-IP AWAF. They want to deploy the same security firewall solution that they use in the private datacenter in the public cloud. The requirements are: a simple operational model to deploy these services a unified security policy consistency across different clouds simple deployments unified logging Challenges Customers have identified several challenges in moving to the cloud. Initallly, teams that are very familiar with supporting services in their private data center usually do not have the expertise in designing, deploying and supporting in public clouds. If the same team then is tasked with deploying to multiple clouds the gap widens, terminology, archtitecture tools and constructs are all unique. Second, the operational models are different across different clouds. In AWS, you use either a VPC or a transit gateway (TGW), in Azure you use a VNET and Google has VPC’s. Solution Description Let's look at how F5’s Distributed Cloud Security Service insertion solution helps simplify and unify security solution deployments in multi-cloud and hybrid cloud environments: Infrastructure-as-code: Implementation and policy configuration can be automated and run as infrastructure-as-code across clouds and regions, allowing policies to be repeatable in any major public or private cloud. Easy setup and management: This simplified setup and management extends across AWS, Azure, and other clouds, as the F5 Distributed Cloud Platform supports AWS Transit Gateway, virtual network peering in Azure, and use of VPC attachments. Define once and replicate models: No extra handcrafting is needed for consistent, straightforward operations and deployment. Unified traffic steering rules: With the Distributed Cloud Platform, traffic is rerouted from networks through the security service using the same steering rules across different public and private clouds. Using F5 Distributed Cloud Console, IT pros get granular visibility and single-pane-of-glass management of traffic across clouds and networks. Optional policy deployment routes: Policies can be deployed at either or both the network layer (using IP addresses) or the application layer (using APIs). Diagram Step by Step Process This walk thru assumes you already have an AWS VPC deployed. Have handy the VPC id. Log into the F5 Distributed Cloud Dashboard You are presented with the Dashboard where you can choose which deployment option you want to work with. We will be working with Cloud and Edge Sites. Select Cloud and Edge Sites > Manage > Site Management > AWS TWG Sites Click Add the AWS Transit Gateway (TWG) Under Metadata give your TWG site a Name, Label and Description Click on Configure under AWS Configuration This brings up the Services VPC Configuration Page Select your AWS region Select Services VPC, leave as New, let it genetrate a name or choose your own name and give the Primary CIDR block you want to assign to the VPC. Leave Transit Gateway as New TWG Leave BGP as Automatic Under Site Node Parameters, Ingress/ Egress select “Add Item” Move slider on upper right corner to Show Advanced Fields Fill in required configuration, AWS AZ Name and CIDR Blocks for each of the the subnets and click the “Add Item” You can let the system autogenerate these or assign the desired range. This will take you back to the last screen, where you need to either create or select your cloud credentials. These are Programmatic Access Credentials allowing API access. Click Apply This takes you to the previous screen where we connect your current VPC to the Service VPC we are creating. (have VPC id available) Click Configure under VPC attachments Click Add Item Supply VPC id Click Apply This takes you back once again to the AWS TWG Site Screen. Finish with clicking Save and Exit. In the UI you will then click Apply. You are now deploying your new Security VPC via Terraform. While that is deploying we will move on to the External Services. Manage > Site Management > External Services > Add External Service Give your Service a name, add a label and description. Click “Configure” under Select NFV Service Provider. For this article we will select the F5 BIG-IP Advanced WAF (PAYG), future articles will cover additional solutions. Provide the Admin Password Admin Username public SSH Key that you will use to access your BIG-IP deployment. Select the TWG site you created above. Finally click “Add Item“ under Service Nodes. Service nodes Enter a Node name and the Avilibilty Zones you wish to delpoy into. Then click “Add Item” This will take you back to the original screen. Enable HTTPS Management of Nodes, supply a delegated doman that will issue a Certificate. Under Select Service Type” Keep Inside VIP at Automatic and Set the Outside VIP to “Advertise On Outside Network”. Finally Click “Save and Exit” At the end, the External Security Service is deployed, and you are taken to all the External Services. Click the name of the External Service you deployed to expand the details From this screen you are able to access several items, the two I want to point out are the TGW stats and the BIG-IP you deployed by clicking the Management Dashboard URL. Click under Site the TWG Service you deployed Here you are able to see fine grained stats under all the tabs. System Metrics Application Metrics Site Status Nodes Interfaces Alerts Requests Top Talkers Connections TWG Flow tables DHCP Status Objects Tools Going back click the hyperlink to the BIG-IP if you wish to look at the configuration. F5 Distributed Cloud Service Insertion automatically configured your BIG-IP with the following information: • Interfaces • Self IPs • Routes • Management and credentials • VLANs • IPoIP tunnel SI<-> BIG-IP • VIP The following two items will need to be configured on your BIG-IP. This configuration Configure AWAF policies SecOps can access familiar BIG-IP UI using management link provided in F5 Cloud Console and set up and configure AWAF ploicies Define a Traffic Steering Policy Network traffic to define traffic steering policy at Network (L3/L4) layer Service policy to define traffic steering policy at App(L7) level. Below are the traffic steering control methods available: Network level – Ip address, port, etc App level – API, Method, etc At the end of this step, you can see traffic getting diverted to BIG-IP and getting inspected by BIG-IP. Summary As you can see, F5 Distributed Cloud Security Service Insertion dramatically reduces the operation complexity for deploying external services in public clouds, it greatly enhances the security posture and it vastly improves productivity for all the operations teams such as NetOps, SecOps or DevOps.Mastering Imperative and Declarative Automation with F5 BIG-IP – AppWorld 2025
At AppWorld 2025, Anton Varkalevich and I will be hosting a hands-on lab, "Mastering Imperative and Declarative Automation with F5 BIG-IP." I'm Matt Mabis, a Senior Solutions Architect in the Business Development/Technical Alliances department at F5. I specialize in solution integrations with our partnerships with Red Hat (Ansible and OpenShift), VMware, and Omnissa Horizon. Anton Varkalevich is a Solutions Engineer III for Financial Services at F5, specializing in ensuring financial customers have the right solutions to meet their unique needs. Automation plays a critical role in financial institutions, enabling them to serve their customers quickly and effectively. This lab is the result of years of experience working with customers to streamline application deployments on F5 BIG-IP. We’ll use Ansible Automation Platform to demonstrate both imperative and declarative automation approaches. Participants will first deploy common use cases—such as HTTPS and SSL-delivered applications—using imperative automation with individual Ansible modules. Then, we’ll achieve the same outcomes using declarative automation, offering a side-by-side comparison to help attendees choose the best approach for their needs. By the end of this lab, you’ll have a solid understanding of both automation styles and how to apply them effectively in your environment. Join us at AppWorld 2025—we look forward to sharing our knowledge with you!External Monitor Information and Templates
This article is written by, and published on behalf of, DevCentral MVP Leonardo Souza. --- Introduction External monitors have been in use on F5 devices for a long time, and you can find a lot of code and articles about them here on DevCentral. However, most of those articles and code samples are very old and outdated. So, I think is a good time to update that with new information and new templates. In this article, I will provide some information about external monitors and templates you can use to build your own external monitor script and how you setup an external monitor. External Monitor The external monitor is a script that the F5 device will run to determine the status of a pool member (note: you can’t assign an external monitor to a node). The script runs the code and indicates if it was successful or not. The script indicates success outputting something to the standard output, and failure if nothing was outputted. The external monitor is your last resource in relation to monitoring, only to be used if there is no built-in monitoring that could be used to perform the monitoring. Built-in monitors are generally faster and easier to support as they do not require programming skills. External monitors run on Linux, while some built-in monitors can run on Linux or TMM. Linux is the kernel that CentOS uses, and CenOS is the base system that F5 uses, also known as the host system. TMM is the Kernel that F5 uses on TMOS, which is the F5 system. Running a built-in monitor in TMM is faster than in Linux. TMM monitors were introduced in version 13.1.0, for more information read this solution: https://support.f5.com/csp/article/K11323537 Configuration Steps Note: Instructions are for version 15.1.0, but should be similar in other versions, and you only need to setup this configuration in one device if you have an HA pair, as the configuration is shared during the config sync. Let’s create a simple external monitor to ping a pool member. You can do via tmsh, but it is simpler via GUI. Download the following file: https://raw.githubusercontent.com/leonardobdes/External_Monitor_Templates/master/bash_external_monitor_template.sh In the GUI go to System > File Management > External Monitor Program File List > Click Import. Select the file and give a name “simple_script” to the script, and import. That will import the file to the system, and make it available in the GUI. Now create a new monitor that points to the script file. In the GUI go to Local Traffic > Monitor > Click Create. Give the name “simple_monitor”, and select type as External. In the External Program select simple_script, click Finished. Now apply the new monitor to a pool member or pool. Here is the full configuration created: sys file external-monitor simple_script { checksum SHA1:817:01e135449c710e21dd090fdd688d940e319f97f5 create-time 2020-04-23:17:45:25 created-by admin last-update-time 2020-04-23:17:45:25 mode 33261 revision 1 size 817 source-path none updated-by admin } ltm monitor external simple_monitor { defaults-from external interval 5 run /Common/simple_script time-until-up 0 timeout 16 } ltm pool pool_asm { members { LABServerPHP:http { address 172.16.0.14 session monitor-enabled state up } test_server:http { address 172.16.0.19 session monitor-enabled state down } } monitor simple_monitor } The first part is the script imported to the system. Next, the monitor that was created. Lastly, a pool using that monitor, also showing that one pool member is up and another one is down. Templates You can write the script to be used in the external monitor in any language that is supported by the F5 devices. I created a template for each of the following languages: Bash Perl Python Tcl For the templates go to this codeshare link: External Monitor Templates | DevCentral On my speed tests, I got these times with the templates: Bash - 0.014 seconds Perl - 0.020 seconds Tcl - 0.021 seconds Python - 0.084 seconds As you can see, Bash is definitely the fastest. Perl and Tcl are very close, and Python is the slowest. But, you may need to use something that works very well in Python, so it might be your only option. Bash Template I will explain the Bash template, but the logic is the same for other programming languages. Each script has 2 versions, one with debug and one without, as indicated in their filename. I will explain the one with debug. This tells the system what to use to run the script. #!/bin/bash The script will be called with 2 arguments, first is the IP, and second the port. The IP is passed in IPv6 format, example “::ffff:172.16.0.14”, so you need to remove “::ffff:” Old scripts, and also the sample_monitor script that comes in the system, use “sed 's/::ffff://'`” that are very slow compared with the above. ip=${1:7} port=$2 This will create a log line in the file /var/log/ltm. logger -p local0.notice "$MON_TMPL_NAME - PID: $$ Name: $NODE_NAME IP: $ip Port: $port" This is where you add your code to test the pool member. This example is just a ping against the IP, and the “-c1” means a single packet. The script then saves the result to know if it failed or not. Next, it will log another line to /var/log/ltm. ping -c1 $ip &> /dev/null result=$? logger -p local0.notice "$MON_TMPL_NAME - PID: $$ Result: $result" Lastly, the scripts check if the result was successful. If successful, it will send up to the standard output. [ $result -eq 0 ] && echo "up" The log lines will be similar to these ones. Apr 24 13:59:15 LABBIGIP1.lab.local notice logger[5178]: /Common/simple_monitor - PID: 5177 Name: /Common/test_server IP: 172.16.0.19 Port: 80 Apr 24 13:59:18 LABBIGIP1.lab.local notice logger[5201]: /Common/simple_monitor - PID: 5200 Name: /Common/LABServerPHP IP: 172.16.0.14 Port: 80 Apr 24 13:59:18 LABBIGIP1.lab.local notice logger[5203]: /Common/simple_monitor - PID: 5200 Result: 0 Apr 24 13:59:18 LABBIGIP1.lab.local notice logger[5209]: /Common/simple_monitor - PID: 5177 Result: 1 Note that the monitoring tests can run in parallel, so the lines will not be sequential. Use the PID number (Process ID), to match the lines. Old scripts, and also the sample_monitor script that comes in the system, have multiple lines of code to check if the same monitor is still running. If running, the new process kills the old one, before performing the monitoring. I tested this behavior in version 11.3.0 and 15.1.0, and this is not necessary. Before starting the new process for the script, the system will kill the old one, so any code in the script to control that is unnecessary as it will not be used. I assume this was necessary for old versions, as I never tested, but is not necessary for currently supported versions. Arguments and Variables The external monitor has multiple settings, including the ones you will find in any other monitor, like interval and timeout. However, it has 2 extra settings, those are arguments and variables. Arguments are passed when calling the script, for example: bash simple_script.sh IP port argument3 Variables are set as environment variables. You can then access that variable in the script. Be aware that the system will add the variables from the monitor first, and then add some extra variables. The environment variables for version 11.3.0 are, with values as an example: MON_TMPL_NAME=/Common/bash_external_monitor_template ARGS_I=2 3 abc X=b PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/contrib/bin:/usr/local/bin:/usr/contrib/sbin:/usr/local/sbin:/usr/libexec NODE_PORT=80 PWD=/var/run SHLVL=1 NODE_IP=::ffff:172.16.0.19 NODE_NAME=/Common/test_server RUN_I=/Common/bash_external_monitor_template _=/bin/env ARGS_I will include the arguments you set in the monitor configuration, in this case, I have “2 3 abc”. X is the variable I added in the monitor configuration, with value “b”. That means you can use those variables in your script. Also, if you set the variable $PATH in your script as an example, it will get reset by the system, as the system variables are set after the monitor configuration variables. Let’s expand that with examples. Here is a monitor configuration with one argument and one variable. ltm monitor external simple_monitor { args 2 defaults-from external interval 5 run /Common/simple_script time-until-up 0 timeout 16 user-defined debug 1 } Here is the part of the script that changed: ping -c${3} $ip &> /dev/null result=$? [[ $debug -eq 1 ]] && logger -p local0.notice "$MON_TMPL_NAME - PID: $$ Result: $result Ping: ${3}" Now the script is using the argument 3 for the ping command, and the variable debug to define if log should occur. Let’s see the logs created: Apr 24 12:18:04 LABBIGIP1.lab.local notice logger[8179]: /Common/simple_monitor - PID: 8178 Name: /Common/test_server IP: 172.16.0.19 Port: 80 Apr 24 12:18:06 LABBIGIP1.lab.local notice logger[8196]: /Common/simple_monitor - PID: 8195 Name: /Common/LABServerPHP IP: 172.16.0.14 Port: 80 Apr 24 12:18:07 LABBIGIP1.lab.local notice logger[8206]: /Common/simple_monitor - PID: 8178 Result: 1 Ping: 2 Apr 24 12:18:07 LABBIGIP1.lab.local notice logger[8208]: /Common/simple_monitor - PID: 8195 Result: 0 Ping: 2 Ping is done with 2 packets, and the second log line still logged. Testing the Script External scripts are saved in this location: /config/filestore/files_d/Common_d/external_monitor_d That is for the Common partition, replace Common to the name of the partition if you import the script in another partition. The file will have an ID number (100479), and also a version number that changes when you update the file (19): :Common:simple_script_100479_19 That means you can go to that directory and run the script from there, and troubleshoot the errors. Don’t forget that when testing this way, you will not have the environment variables the system setup, you will have the environment variables from the shell where you run the command. Let’s test the simple simple_monitor discussed above. First, create the environment variables: export debug=1 MON_TMPL_NAME='/Common/simple_monitor' NODE_NAME='/Common/test_server' Run the script: ./\:Common\:simple_script_100479_22 '::ffff:172.16.0.14' 80 2 You will get the following log lines: Apr 24 16:03:48 LABBIGIP1.lab.local notice root[12206]: /Common/simple_monitor - PID: 12205 Name: /Common/test_server IP: 172.16.0.14 Port: 80 Apr 24 16:03:49 LABBIGIP1.lab.local notice root[12224]: /Common/simple_monitor - PID: 12205 Result: 0 Ping: 2 You need to escape the “:” with \. After you do the tests, delete the environment variables created: unset debug MON_TMPL_NAME NODE_NAME Conclusion I hope this article provides you all the information you need to create your own external monitor. After you understand how it works, it is very simple to use. Just don’t forget, no “echo down”, only output something when the monitor was successful, and make sure you suppress any command output.
