"01020066:3: The requested Node (/Common/fqdn1) already exists in partition Common."
Hello, when trying to POST a new application in a tenant that uses an already shared FQDN across tenants in the same cluster, the AS3 POST response is: "01020066:3: The requested Node (/Common/fqdn1) already exists in partition Common." It is saying that fqdn1 already exists in /Common, which is true, as it can be seen in other pools as a member. Now, if I try a different FQDN (fqdn2), it works fine with no issues. Any suggestions on how to find the root cause and fix this without: deleting fqdn1 from everywhere, and redeploying it? Thank you J version running 3.56.0-10
BIG‑IQ: Adding rSeries/Velos Devices through the REST API
Hello, Is there a way to add F5OS devices (rSeries/Velos) to a BIG‑IQ instance using the REST API or an Ansible module? The latest API‑Reference version is 8.1.0, but the capability to add F5OS devices was introduced in later BIG‑IQ releases. Adding our devices manually is not an option for us. Could someone point me in the right direction, please? Cheers, IchnafiF5 Insight for ADSP - A Closer Look
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 key features and use cases addressed by F5 Insight. Demo Video Demo Video: F5 Insight for ADSP - A Closer Look The F5 Insight Home Screen The F5 Insight Home Screen provides comprehensive monitoring for your F5 infrastructure, applications, and security posture. It features intelligent anomaly detection and performance optimization tools, giving administrators and users a centralized view of their BIG-IP fleet health and operational status. System Report Cards The System Report Cards display health indicators ranked Good, Warning, and Critical for the following: Anomaly Detection Monitors the connection count, pool availability, CPU utilization, and memory usage. Application Performance Monitors application-level health based on response time, 4xx, and 5xx error codes. Security Monitors the expiration of SSL/TLS certificates and BIG-IP WAF events. BIG-IP Metrics Monitors for BIG-IP health issues with device resources and operational status. Fleet Status Displays a summary of all BIG-IP devices and their operational status. The Fleet Status shows all the BIG-IP devices with a status of Up, Down or Degraded. Ask AI Assistant Allows you to type queries in plain English to retrieve device statistics, configuration information, security events, device health, application performance and much more. The AI Assistant connects to a configurable Large Language Model (LLM) backend. Supported providers include OpenAI, Anthropic, or a customer provided LLM. An example query: Have there been any outages in the past 24 hours for all devices in all data centers? The AI Assistant understands the question and has identified all the data centers. The AI Assistant then checks the device statistics for any outages or issues. The AI Assistant compiles a detailed summary report of the query. Configuration of Large Language Model (LLM) Large language model (LLM) Insights bring natural language intelligence to F5 Insight, enabling you to query your BIG-IP configurations and logs conversationally. Instead of manually searching through configurations or parsing log files, you can ask questions like “Why is pool member X marked down?” or “Show me all virtual IPs (VIPs) with SSL offloading enabled” and receive immediate, contextualized, clear answers. In the toolbar on the left under Manage, select LLM Insights. Select your LLM Provider Enter your API Token/Key Enter your Enterprise API URL Click Test Connection to verify it’s working Click Save Configuration when the connection is validated. Conclusion F5 Insight for ADSP offers customizable visualizations and dashboards to help you surface metrics and KPIs tailored to your organization. It provides access to useful telemetry data for a deeper understanding of your environment, application behaviors, and complex BIG-IP deployments, all centralized in a single location. Identification of root causes during outages/tickets. Solves issues and struggles with Day 2 analysis of your BIG-IP Fleet and the applications therein. Mitigates the problem of a lack of detailed visual information on your BIG-IP Fleet. Set a foundation for the utilization of open-source tools and their benefits. Related Content Introducing F5 Insight for ADSP F5 Insight for ADSP Documentation F5 Insight Product Page
Building a Certificate Lifecycle Manager with F5 BIG-IP Support — Looking for iControl REST Feedback
GitHub: https://github.com/shankar0123/certctl Managing certificate renewals on BIG-IP is one of those tasks that's easy to forget until it breaks something. The typical workflow is generate a CSR, submit to a CA, wait for issuance, download the cert, upload through the GUI or push via iControl REST, bind it to the right virtual server. This has too many manual steps and no central visibility into what's expiring when. I'm building certctl, a self-hosted certificate lifecycle platform, and F5 BIG-IP is one of the target connectors I'm working on. The platform already handles certificate issuance (built-in Local CA and ACME/Let's Encrypt with HTTP-01 challenges), configurable renewal policies, agent-based key generation (ECDSA P-256, private keys never leave the agent), threshold-based expiry alerting, policy enforcement, and an immutable audit trail. The NGINX target connector is fully implemented. Agents deploy certs via file write, nginx -t validation, and reload. Where I need feedback — the F5 connector: The F5 target connector interface is built and the iControl REST flow is mapped out, but I'm looking for input from people who manage certs on BIG-IP day to day before shipping the implementation. The planned flow is: Authenticate via POST /mgmt/shared/authn/login Upload cert PEM via POST /mgmt/tm/ltm/certificate Update the SSL profile via PATCH /mgmt/tm/ltm/profile/client-ssl/{profile} Validate deployment by checking profile status Questions for the community: Is this the right iControl REST flow for cert deployment, or are there edge cases I'm missing (e.g., cert bundles, intermediate chain handling, partition scoping)? Do most environments use client-ssl profiles directly, or is there a layer of indirection I should account for? Any gotchas with token-based auth vs. basic auth on newer BIG-IP versions?F5 Config - API Access on servers
Hello,, Pl. be gentle as I am new to this and am asking this on behalf of someone as their networking resource is ooo on some emergency. There are two separate, identical server instances hosting identical API's e.g. here is a sample endpoint for one of those API's https://prod1.mydomain.com:8443/ne/curr/CheckInventory https://prod2.mydomain.com:8443/ne/curr/CheckInventory F5 has been configured Round-Robin mode Both Servers added to a new Pool VIP created with ssl enabled (default port 443) https://app.mydomain.com Questions: What additional config neeeds to happen so any request from an external client for CheckInventory endpoint is processed What will be the new endpoint for this API? https://app.mydomain.com/CheckInventory Can it be changed to something else Is there an API mapping that has to be created withing the F5 config that will translate the Request ( https://app.mydomain.com/CheckInventory) to what the server is expecting (https://prod1 (or prod2).mydomain.com:8443/ne/curr/CheckInventory) Thank you
RDP persistence with SNAT
Hi, rather than using an RDS broker service, is there a simpler way to persist and equally load balance traffic to an RDP vip which is a resource on APM? Our setup is: client connects to APM On APM there is a webtop using native RDP which points at the IP address of an LTM VIP on the same F5. LTM vip sees the F5 SNAT IP, I cannot pass any cookie, header, or even custom rdp parameter from APM to the LTM vip so there is no way to persist on anything unique. LTM cannot see the username, apparently if even a blank apm profile is bound to the LTM vip I can see things like sso username, however if I enabled apm then the vip makes ssl profile mandatory which then breaks rdp. Any other ways to do this or is it impossible?Struggling with web GUI usability with links in new tabs
Hi, there's thing thing with the web GUI for a BIG-IP that slows me down terribly, if I want, let's say, to open multiple tabs of different virtual servers, I have to do it slooooooowly, I can't open 10 tabs in like 2 seconds because the web GUI somehow needs to load everything before accepting a new link, if I open virtual server A in a new tab I have to wait for it to fully load before opening vs B because if I don't, it'll load vs B in both tabs, is there any way to prevent this from happening? It's pretty infuriating. Also is there a way to make the web GUI not work as an SPA? I know there's the "link to this page" thing in the gear icon for each page, but I just want to have my tabs with the absolute URL, not hxxps://host/xui. Thanks.
F5 i-series Guests to r-series tenants migration
Hi All, I have two i-series 11900 with 4 guests on each as: 1 LTM, 1 GTM, 1 WAF, and 1 APM. There is HA between the guests. I am working on a migration plan to r-series 10900 and have two options: Option 1: HA method: Here, I will replace the i-series device that has the standby guests with the r-series device. Then will establish the HA between the active i-series and the r-series and sync the configuration. Then will make the r-series active as active. Then will replace the newly bocming standby i-series device with the second r-series and establish the HA with the first r-series. this is a lengthy way but has a positive side of fast rollback in case I faced any issue, and there will be no changes on the management IPs. Option 2: UCS method: in this method I will create a replica of the existing guests on the r-series tenants using the UCS files from the iseries guests. This setup will be isolated from the production network. During the maintenance window, I will disconnect the cables from i-sereis and connect it to the r-series boxes. This way I need to use different management IPs while building the replica setup. and during the migration will change the management IPs and use the onse were on the i-series. Note that, existing devices are connected to cisco ACI. Let me here your thoughts and suggestions.
