Why Origin Pool Health Monitors Prevent Outages
A single unhealthy origin can quietly turn into application errors, failed connections, and customer-facing outages. Health monitors help prevent that by continuously checking whether backend services are available and routing traffic only to origins that can successfully serve requests. For production deployments, configuring health monitors is one of the simplest ways to improve application availability, reduce operational risk, and protect the end-user experience. In short: if an origin matters to your application, it should be monitored.What’s new in F5 Insight for ADSP v1.2?
Introduction F5 Insight for ADSP, a key component of the F5 Application Delivery and Security Platform (ADSP), helps teams monitor and secure apps that are spread across hybrid, multi-cloud and AI environments. In this article, I’ll highlight some of the new features introduced in F5 Insight v1.2. Demo Video Fleet Management F5 Insight v1.2 supports software patching of your BIG-IP instances. From the web UI navigate to Manage > Software > Images. Click Upload to add a BIG-IP software image. Click Upload File Select the software image you want to update to, 17.5.1.6 in this example NOTE: The sig and pem files are not required to upgrade but are recommended so F5 Insight can verify the software image. The files will be uploaded automatically and will look like this when done. Click the X to close the dialog box. The Software page should now look like this. NOTE: Additional details about the Product, Version and Status are available here Next go to Manage > Automation > Jobs > Add Job > Software Distribution Fill in the Job Name and add a Description if desired Select the BIG-IP Instance(s) you wish to distribute to, then click Back to Job Settings Click Add Software Select the version you wish to distribute then Apply Click Check Instances if needed Set the Distribution Type to Serial or Parallel Click Execute Job Confirm the Job Execution by entering a Change Request then click Execute Job The Job is now running Click the number under Executions to view the progress. When the software image has been distributed to the BIG-IP Instances it will look like the following: Click Add Job > Software Installation to create an Install job Under General Settings give the job a Name, add a Description if desired Under Installation Type select HA Pair or Standalone, Standalone in this example Set the Execution Type to Serial or Parallel, Serial in this example Select the Software Target Version Select the Instance to install the software Click Back to Job Settings Set the Target Volume option as needed, Next Sequential in this example Choose the Target Volume, HD1.2 in this example Under Readiness Checks click Run Check A successful Readiness Check should look like the following: Click Execute Job Enter the Change Request, type BEGIN INSTALLATION then click Execute Job You can see that the Job is Running Click the number under Executions to view the progress The BIG-IP will be rebooted automatically and the Jobs screen will look like the following when done: Administrator Authentication – RBAC, LDAP & SAML F5 Insight v1.2 now supports external authentication, enabling enterprise customers to integrate with their existing identity infrastructure for centralized user management and secure access control. External authentication is supported via LDAP and SAML providers like Ping and Okta. Support for Role Based Access Control (RBAC) allows customers to choose from 3 predefined roles: Admin gives full system access including user management, device configuration, and all settings. Operator gives device configuration and troubleshooting. Viewer gives read-only access for monitoring and observation Configuring an LDAP Provider From the F5 Insight UI navigate to System Management > User Administration > SSO/Identity Providers. Under Add provider click LDAP Give it a name, “LDAP” in this example. Specify the LDAP URL, Base DN, Bind DN and Bind Password. NOTE: Click the plus sign next to the red arrow to add additional LDAP URLs Specify the User binding settings and LDAP attributes. You can also enable Start TLS for the connection to the LDAP server. Click Create when done. Role Mapping determines which F5 Insight role an external user receives upon login. Roles are assigned based on group attributes configured on the LDAP or SAML identity provider. Navigate to System Management > User Administration > Roles > Role Mapping. Select the Provider, either LDAP or SAML. Specify the Grouped Resource Attribute to map to. Click Save. You have successfully mapped the LDAP Grouped Resource Attribute to the Admin Role. Configuring a SAML Provider From the F5 Insight UI navigate to System Management > User Administration > SSO/Identity Providers. Click SAML under Add provider. To add a SAML Provider give it a name. Specify the Metadata XML, URL and Binding. Click Create when done. NOTE: The Role Mapping procedure is the same for SAML Refer to the F5 Insight Documentation for more details on configuring RBAC, LDAP and SAML. Audit Logging F5 Insight v1.2 added support for AI Assistant Chat Logging as well as Audit Logging of AI Events. The AI Assistant Chat History saves your interactions with the AI Assistant The AI Audit Console provides an audit log of all the different AI Assistant Event Types. It contains many options for filtering Events as well as the option to Mask Sensitive Data. When Sensitive Data Masking is turned off you can see the Source IP and User Agent F5 Insight Backup / Restore F5 Insight v1.2 added support for backing up & restoring an F5 Insight configuration. From the web UI navigate to System Management > Backup & Restore > Backup > Create Backup Select the Backup Type > Storage Target. Enter the Encryption Passphrase and optionally specify a Backup Name. Click Submit Creation It should look like the following when complete: NOTE: You can download a copy of the backup file by clicking the icon on the right Click the Restore icon on the right to Restore the Config Backup Select the options you want restored and enter the Decryption Passphrase. Click Start Restore When the Restore process is complete it will look like the following: Click Create Scheduled Backup to configure a recurring Backup Schedule Configure the Schedule Name, Frequency, Day of Week, Time, Backup Type, Storage Location, and Encryption Passphrase. Click Submit Creation when done When complete It should look like the following: To configure Backup Settings navigate to Backup & Restore > Settings To add external storage click Add Storage Location Specify the Location Name, Storage Type (NFS or SMB), Host / Server, and Path. Click Save Location when done Conclusion The latest version of F5 Insight for ADSP offers expanded functionality with F5 Fleet Management. It also provides powerful management features like RBAC, LDAP and SAML authentication, Audit Logging capabilities, and F5 Insight Backup / Restore options. Upgrade today to the latest version of F5 Insight for ADSP and enjoy the following benefits: Manage BIG-IP software upgrade RBAC, LDAP & SAML authentication Audit Logging Configuration Backup & Restore Related Content Introducing F5 Insight for ADSP F5 Insight for ADSP – Initial Setup in VMware F5 Insight for ADSP - A Closer Look F5 Insight for ADSP Documentation F5 Insight Product Page
Automating F5 ADSP — Part 4: F5 XC and NGINX Gateway Fabric for Delivery and Security
What this use case demonstrates This use case deploys NGINX Gateway Fabric (NGF) on the Kubernetes Gateway API as the in-cluster data plane, running NGINX Plus. WAF and API protection are provided by F5 Distributed Cloud (XC) at the edge. It covers all four ADSP areas: Delivery, Security, Deployment, and xOps. Delivery: F5 Distributed Cloud HTTP load balancer at the edge, NGF (running NGINX Plus) handling in-cluster delivery via the Gateway API. Security: XC WAF in blocking mode, XC API protection built from an OpenAPI spec, with validation and fall-through both in report mode by default. Deployment: XC consumed as SaaS, GKE Standard with private nodes, NGF installed via OCI Helm chart, the application deployed via a separate OCI Helm chart and exposed through a Gateway API HTTPRoute. xOps: The OpenAPI spec lives in the repo at config/uc4/app/oas/openapi.json. The OAS is the source of truth for API protection policy, change the spec, push, and enforcement follows. Architecture What gets deployed: A GCP VPC with a dedicated k8s subnet (with secondary ranges for pods and services), management subnet, and NAT for private nodes A GKE Standard zonal cluster with private nodes and a control plane locked down by authorized networks NGINX Gateway Fabric running NGINX Plus, installed from oci://ghcr.io/nginx/charts/nginx-gateway-fabric. The NGF control plane provisions a data plane Deployment and a LoadBalancer Service when the Gateway is created. Comfy Capybara deployed via oci://ghcr.io/knowbase/charts/comfy-capybara, exposed through a Gateway API HTTPRoute attached to the NGF Gateway An F5 Distributed Cloud HTTP load balancer with WAF and API protection. The origin pool is resolved from the NGF data plane LoadBalancer IP via Terraform remote state. The HTTPRoute splits traffic two ways: /api to the API service with a URL rewrite that strips the prefix, / to the frontend. DevSecOps in practice for UC4 The lead-in covers the approach. For UC4, that means: Terraform handles infrastructure, the GKE cluster, NGF, the application Helm release, and all F5 Distributed Cloud objects. No click-ops. State lives in a GCS bucket the workflow creates on the first run, with a separate state file per module. The XC origin pool reads the NGF data plane LoadBalancer IP from state/uc4/ngf, so no IP is ever pasted between configs. GitHub Actions runs the pipeline. Branch names trigger deployments, so git history shows what was meant to happen. GCP Workload Identity Federation replaces static service account keys. The XC API certificate, NGINX Plus JWT, and NGINX registry credentials live in GitHub Actions secrets, not the repo. The OpenAPI spec at config/uc4/app/oas/openapi.json is the source of truth for API protection. The workflow uploads it to the XC object store and binds it to the API definition. The pipeline Pushing to a branch runs the workflow. There is no manual terraform apply or helm install. Action Branch Validate, plan, and apply deploy-adsp-uc4 Validate only (no apply) test-adsp-uc4 Destroy all resources destroy-adsp-uc4 Modules deploy sequentially: state bucket - infra - GKE - NGF - app - XC. Destroy runs in reverse. What's in the repo f5devcentral/F5-ADSP-Automation: Directory Purpose infra/gcp/ VPC, subnets with pod/service secondary ranges, NAT, firewall k8s/gcp/ GKE Standard cluster and node pool f5/ngf/gcp/ NGINX Gateway Fabric, Gateway API CRDs, Gateway, secrets f5/xc/ F5 Distributed Cloud HTTP LB, WAF, API definition (shared with other XC use cases) app/gcp/ Comfy Capybara Helm release and HTTPRoute config/uc4/gcp/env.json GCP, GKE, and NGF config config/uc4/app/env.json Application chart and route config config/uc4/app/oas/openapi.json OpenAPI spec the XC API definition is built from config/uc4/xc/env.json XC tenant, LoadBalancer, WAF and API feature flags .github/workflows/ CI/CD workflows Prerequisites, secrets, and troubleshooting are in the UC4 deployment guide. Demo Try it Fork f5devcentral/F5-ADSP-Automation, set the secrets and tfvars from the deployment guide, and push to deploy-adsp-uc4. Push to destroy-adsp-uc4 to tear it down. Contribute Issues and PRs welcome at f5devcentral/F5-ADSP-Automation.Dynamic import of data groups
Hello. We use data groups for various kind of black lists, such as undesirable user agents, for instance. That's really efficient, but requires a BigIP administrator intervention for any update. We'd like to switch authoritative origin for those lists to an external location, such as an internal git repository, in order to allow trusted people without access to the administration interface to update those lists in auditable manner, as we do for instance with our firewalls using "dynamic list" feature. There seems to be no such native fonctionality in BigIPs, as even "external" dynamic lists actually relies on files hosted on local filesystem, not to arbitrary URLs. We could probably use a cron task to implement a pull-based update mechanism, or use the API to periodically push changes, but I'm not sure of the reliability of such ad-hoc mechanism, and the potential consequences in case of failure. Is there any alternative for such kind of configuration delegation ? Regards, Guillaume
APM Policy Migration Between Standalone TMOS 17.1.3 Systems
Hi everyone, We're migrating a single production APM policy from an i4600 to an r4600 appliance. Both systems are running TMOS 17.1.3, and the new appliance will not be part of the existing DSC cluster. We tried exporting/importing only the APM policy, but the import fails because referenced objects are missing on the target system. A full UCS restore would also migrate many unused objects that we don't want. Is there a supported way to: Analyze an APM policy and list all required dependencies before import? Export/import only the APM Customization GUI (HTML/CSS/JavaScript templates)? Migrate a single APM policy without restoring the entire APM configuration? Any recommended best practices for this scenario would be appreciated. Thanks in advanced!
How to safely purge logs on BIG-IP (disk usage high)
Hi All, I would like to ask for the best practice to purge/clean log files on BIG-IP system. Current situation: - Disk usage is getting high due to log files - Logs located in /var/log (e.g. ltm, asm, audit, etc.) Questions: What is the recommended way to purge or rotate logs safely? Can we manually delete logs under /var/log ? Is there any tmsh command or utility tool to manage this? How to configure log rotation properly? Thanks in advance!
Local-Only in your browser BIG-IP Report Generator
Leveraging my f5query engine and the Python interface to it, along with my Tcl-LSP Tcl/iRule compiler and analyser, I built a report generator. You can run it locally yourself, it's a single HTML file that embeds all the WASM to do the work, makes no requests to the outside world. I don't have good lab devices to use for demo content anymore so I had to use some SCF files I found on GitHub for the demo. Example Report Report Generator - nothing is ever uploaded, there's no telemetry, the only external URL in it is in the footer pointing to my GitHub. It should have somewhat decent print output. If you have feature requests, bug reports, please open issues on GitHub This work only exists in the rust branch and 2.x pre-releases if you're interested in the code.
Migration doubt
Scenario is: 4 serie i2600 forming sync-group GTM. Being two diferent cluster HA active/standby LTM. First ill change one pair and another day the another. My idea for migrating an LTM/GTM pair from the iSeries platform to the rSeries platform is as follows: We used same cables from i series and same names and IPs to do it easier to customer First, I disconnect all the cables from the standby iSeries unit. The active iSeries unit will remain active in standalone mode. Next, I connect the interfaces used for the synchronization and failover network from both iSeries appliances to the new rSeries appliances. The HA pair has already been configured on the new rSeries units, so one will be active and the other will be in standby. Once the standby rSeries node is in place, I connect all the service cables to it. After all the service cables have been connected and I have verified that everything looks correct (ARP entries, pools, etc.), I proceed to run the bigip_add and gtm_add commands against the active iSeries node. It is important to note that the iSeries and rSeries appliances will never form an HA cluster with each other. After running both commands, I verify that everything is operating correctly before forcing the active iSeries node offline and allowing the rSeries node to become active. If I face any issues while running the bigip_add or gtm_add commands, since the new rSeries nodes use the same hostnames and IP addresses as the previous iSeries appliances, I may need to remove the trusted certificates associated with the old appliances from the other BIG-IP devices before attempting the commands again. Anything to keep in mind? or any potencial issie doing like that?? Would it be necessary or recommended to temporarily take the GTM cluster being migrated out of service, or is there no significant risk in keeping it operational? Its my first GTM migration in a bit lost.Doubt adding F5 in sync-group
I need to replace an LTM-GTM cluster. I will replace the standby node first. The sync-group are 4 devices. My question is about adding it to the GTM sync group. Should I run only the gtm_add command, or do I also need to run the bigip_add command? I'm not sure whether joining a sync group requires both commands or just one of them. I'd also like to know where each command should be executed. I understand that gtm_add is run on the new node being added, but is bigip_add also run on the new node? how can i delete the old nodes for the sync-group when its donde the change?
