migrate from serie I to R. Cluster LTM-GTM
We currently need to carry out a migration of six 2600i devices to 6 new 2600r models. There are three Active-Standby clusters at the LTM level. In addition, four of these devices form a cluster for GTM-DNS. I would like to know whether you have any specific procedure for this type of migration. We would also like your recommendation on whether to perform the migration of the four devices within the same maintenance window, or to migrate them in pairs, allowing two devices from the i series and two from the r series to coexist in the same DNS cluster. Additional information: The source and target version will be the same: 17.5.1.3 We will use Journeys for the configuration conversion. On the other hand, would you keep the management IP addresses of the I series on the R Series chassis or tenants, or would you request new IP addresses for all? What steps would you follow during the migration window?.Automating F5 ADSP — Part 1: F5 XC and BIG-IP for Delivery and Security
What this use case demonstrates This use case covers three of the four ADSP areas: Delivery, Security, and Deployment. Delivery — F5 Distributed Cloud (XC) load balancer at the edge, F5 BIG-IP LTM handling traffic management inside the VPC. Security — XC WAF at the edge, BIG-IP Advanced WAF (AWAF) applying in-path policy before traffic reaches the application servers. Deployment — XC consumed as SaaS, BIG-IP deployed as a Virtual Edition in GCP. Same article, two deployment models, both provisioned from code. You get two layers of delivery and two layers of WAF, across a SaaS edge and a self-managed VE. The whole stack, VPC through XC load balancer, comes up from a single git push. Architecture What gets deployed: A GCP VPC with management, external, internal, and application subnets BIG-IP with AWAF in a single-NIC configuration OWASP Juice Shop and crAPI as target applications F5 Distributed Cloud HTTP load balancer, origin pool, and WAF policy pointing at the BIG-IP The vulnerabilities in the apps are deliberate. They let you exercise the WAF stack against real attack signatures and API abuse patterns. Without them, you only know the controls deployed, not that they work. DevSecOps in practice The lead-in covers the approach. For UC1, that means: Terraform handles infrastructure, BIG-IP configuration, and 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 same bucket carries the AS3 declaration BIG-IP pulls on boot, so the runner never needs network access to BIG-IP. 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 F5 XC API certificate lives in GitHub Actions secrets, not the repo. The pipeline Pushing to a branch runs the workflow. There is no manual terraform to apply. Action Branch Validate, plan, and apply deploy-adsp-uc1 Validate only (no apply) test-adsp-uc1 Destroy all resources destroy-adsp-uc1 This keeps intent visible in git, makes destroy as easy as deploying, and gives reviewers a real PR to look at when something changes. What's in the repo f5devcentral/F5-ADSP-Automation: Directory Purpose infra/gcp/ VPC, subnets, firewall rules compute/gcp/ Juice Shop and crAPI f5/ BIG-IP base config and AWAF policy config/uc1/gcp/env.json GCP project, region, prefix config/uc1/xc/env.json F5 Distributed Cloud config .github/workflows/ CI/CD workflows Demo Try it Prerequisites, secrets, and troubleshooting are in the Use Case Deployment Guide. Contribute Issues and PRs welcome at f5devcentral/F5-ADSP-Automation/Issues. Resources: F5 Application Delivery and Security Platform GitHub Repo and Automation Guide ADSP Architecture Article Series: Automating F5 ADSP Deployments (Intro) Automating F5 ADSP Deployments (Part 1 - F5 XC WAF and BIG-IP Adv. WAF) Automating F5 ADSP Deployments (Part 2 - F5 XC WAF and NGINX App Protect) Automating F5 ADSP Deployments (Part 3 - F5 XC API Protection and NGINX Ingress) Automating F5 ADSP Deployments (Part 4 - F5 XC BOT Defense and BIG-IP AdvWAF) Automating F5 ADSP Deployments (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress) Minimizing Security Complexity: Managing Distributed WAF Policies
OpenID Connect as Client and Resource server
Hi All I am hoping some here can help me ... I am setting up a F5 to act as both OpenID Connect as Client and Resource server however I am now stuck in a auth loop. My session is being deleted before its handed over to to the authoisation server .. "If the session ID is still changing (4a3b8e96 -> 76933e5c) and the logs show Session deleted (oauth_finished), the F5 is essentially "forgetting" the session because it is failing to hand off the MRHSession cookie, or the policy is explicitly configured to terminate upon finishing the OAuth transaction." I have tried many variations of using iRule to stop the session ID's changing between the auth server and the authorisation server to ni avail .. I am at my wits end :( Anyone anble to help? I have logs I will need to sanitise them first that I can upload. These just show that the Auth-ID is created and then the session is deleted before its handed over to VPE that should then send it to sharepoint point app .. help anyoneFunctionality questions regarding commands that we're using in a DNS_REQUEST related iRule
I opened a ticket w/F5 regarding this but they recommended I try DevCentral instead, so here we are :) We're currently in the process of creating and testing an iRule/configuration in a test environment with the intent of eventually applying it to the listeners in our F5 DNS/GTM production environment that will forward DNS requests made to our production F5 DNS/GTM environment with only specific criteria to a separate Windows DNS server to answer back through our production F5 DNS/GTM environment. What we have so far which appears to be working: when DNS_REQUEST { # Check if the query is for a TXT record and matches a specific FQDN if { ([DNS::question type] equals "TXT") and ([string tolower [DNS::question name]] contains "_acme-challenge") } { # Forward to a specific pool of DNS servers DNS::disable dns-express snat automap translate address enable pool /Common/dns_fwdtxttest_pool } } In order for us to get it to work we had to add the following commands to the iRule that we found online: DNS::disable dns-express snat automap translate address enable In both our test and production F5 DNS/GTM environments we: -Do use dns-express -Have source address translation set to none on our listeners -Have address translation disabled on our listeners My questions are in regard to how those 3 commands may/may not affect other requests/traffic made to our production F5 DNS/GTM environment NOT being processed by the iRule when it gets triggered during and post completion. Will the features/settings affected by those commands only apply to the request/traffic that triggers and is processed by the iRule, or all traffic? Will the features/settings affected by those commands automatically revert back to how they are currently set/functioning prior to implementation in our production F5 DNS/GTM environment (DNS Express - enabled, source address translation - none, address translation - disabled) again once the iRule completes processing the triggered request/traffic, or do they need to be toggled back manually at the end of the iRule in some way again as well? We're just trying to make sure we have all our bases covered and are accounting for as much as we can before going live with it and potentially running into other unexpected issues with production requests/traffic upon implementation. All that being said - is there anything else that we may be missing/overlooking? Anyone out there have any thoughts/suggestions/guidance at all? Thanks in advance and hope all is well!
Prodcut compatabilty with F5 OSS vs F5 NGINX Plus
I have configured my product using F5 NGINX OSS Ingress Controller, leveraging resources such as GlobalConfiguration, TransportServer, and Ingress. The product is working as expected with F5 OSS and uses both HTTP and TCP communication. However, I have not yet been able to validate it with F5 NGINX Plus. Do you foresee any reason it would not work with F5 NGINX Plus?Deploying an NGINX App across Kubernetes Multi-clusters with F5 BIG-IP Container Ingress Services
This tutorial simulates orchestrating multiple clusters using a single Kubernetes control plane with separate kubeconfig contexts, the same F5 CIS configuration patterns apply to genuinely separate Kubernetes clusters across different networks, cloud regions, or data centers. The simulation approach allows configuration testing without requiring multiple physical or cloud infrastructure environments.Disentangling the questions of resilience, data sovereignty, and data residency
The hyper-connected digital spaces we occupy grant immense scale and flexibility, streamlining business flows and user experiences. But this interconnectivity also sets the stage for a web of nuanced regulations that govern the storage, transportation, and handling of different types of data. Understanding what these regulations impact, and how application delivery and security teams should build networks to interact with them can be an extremely daunting task. A good first step is to break data management in this framework into three clear buckets. Data Residency (the technical or architectural response): This is a commitment or requirement governing where data physically resides at rest, frequently established through customer contracts rather than explicit localization laws; for example: a German enterprise mandating EU-only data storage. Data residency is more concerned with storage location rather than processing. Under data privacy laws, organizations may need to store certain data within the country or region from which it originates. This is why localization requirements lead to Data Residency compliance in most cases. Localization laws typically impose residency as a condition, but residency requirements do not necessarily originate explicitly from localization law. Data Localization (the regulatory requirement): Some laws require data to be stored and, in some cases, processed within a defined country or region; for example, the General Data Protection Regulation’s (GDPR) restrictions on cross-border transfers in the EU, Russia’s requirements that personal data on Russian citizens be stored domestically (i.e. Federal Law No. 149-FZ & Federal Law No. 152-FZ), or China’s localization rules for important data and personal information. They can take the form of hard localization, requiring data to stay in country; soft localization, requiring that a copy of the data must be kept in country, with transfers abroad allowed under certain conditions; and conditional export regimes, where data can only leave a country or region if specific safeguards exist. Localization can most easily be thought of as the policy lever that governments use to enforce sovereignty. Data Sovereignty (the legal principle): This is authority over data: who can access it, govern it, and compel its disclosure as defined by local law. These legal nuances create complexities when data flows across multiple entities across multiple countries. The CLOUD Act is the canonical example: if your data resides in an EU-based data center operated by a US hyperscaler, US law enforcement can compel that provider to turn over the data in question. Thus, data sovereignty asks: whose laws govern this data, regardless of where it sits? Sovereignty can apply to provider access, admin access, and lawful access, not just storage location. This is the concept that breaks the naive assumption that residency equals sovereignty. This trio of topics is a defining concern for regulated institutions, driven by questions of jurisdiction, control, and accountability in addition to geography. Add resilience-focused regulations like the Digital Operational Resilience Act (DORA) into the mix, and institutions find themselves under growing pressure to demonstrate where data is stored, where digital services run, who governs them, and what happens to that data during an outage or service disruption. And while it is unlikely that any of us will have control over national or regional legislation, we can influence our strategies to adopt resilient systems and tools to help address challenges of sovereignty and residency. The impacts of these regulatory frameworks don’t exist by themselves. Indeed, one of their ripple effects is exposure of weak sovereignty and residency assumptions from hyperscaler and edge providers. Most narratives address sovereignty and residency indirectly. In practice, the market often over-indexes on regional presence or sovereign clouds while positioning sovereignty‑friendly overlays. They often stop short of addressing jurisdiction‑aware control, accountability during incidents, or how sovereignty constraints interact with resilience testing and regulatory evidence. A region-boundary is not the same thing as jurisdiction-aware control of data flows. From this perspective, sovereignty, residency, and resilience intersect where architectures make these controls explicit. Navigating traffic through various jurisdictions especially matters during outages, when data‑in‑motion is inspected or constrained across borders, when incident response requires rapid intervention, or when exit strategies must be executed without compromising data residency and sovereignty. Architecture strategy determines whether sovereignty constraints become operational blockers or remain compatible with regulatory expectations. F5’s role in this discussion is not to redefine sovereignty or promise compliance by design. It is to provide architectural control points that allow institutions to enable sovereignty without isolating themselves, and to retain operational authority without binding resilience to a single provider. By separating application connectivity, traffic control, and security policy from provider‑native constructs, institutions gain a more governable, portable, and inspectable operating model. This is why organizations that approach resilience, data sovereignty, and residency as architectural disciplines, rather than simply a group of tools under a location claim, are better positioned to satisfy both sovereignty expectations and regulatory demands for resilience, without over‑promising on either. This shift addresses the gap between how tools to facilitate residency are marketed and how they are evaluated and deployed in practice. Cloud providers highlight regional footprints, certifications, and internal safeguards. Edge and networking platforms emphasize neutral overlays that “work everywhere.” Yet neither position fully addresses the institutional reality regulators care about: whether control of the systems that retain user data remains with the entity itself, especially when outages or security incidents occur, dependencies fail, or exit strategies need to be executed under pressure. Data residency conversations need to evolve away from infrastructure claims, and toward control points. These are the places in digital architecture where policy, authority, and accountability are exercised when it matters most. Two dimensions that most resilience strategies underweight are disaster recovery and data sovereignty. Getting both right determines whether an organization survives the next outage intact. What this could look like: sovereignty- and resilience-ready control points A data sovereignty strategy is only as good as the tools as the tools used to enact it. What regulators will increasingly test is not where a primary stack runs on a good day, but what happens to data and control when conditions degrade. During an outage, a failover, a provider-side incident, or a forced migration, data-in-motion patterns change quickly, often faster than governance processes can react. That’s when residency assumptions break, when cross-border inspection becomes ambiguous, and when accountability becomes hard to demonstrate. What may appear to be a robust strategy could easily fall apart – not to mention run afoul of regulators – when an outage hits if the responsible team does not have a complete set of tools at their disposal to ensure sensitive data stays where it needs to stay. Some of those tools may include: Jurisdiction-aware data paths (normal + degraded modes) You can intentionally route traffic to keep data in motion within approved boundaries, and you can show what changes during failover. Boundary-respecting resiliency (DR that doesn’t break residency/localization) Recovery patterns are designed so that backup, replication, and emergency operations don’t silently export regulated data or shift it into a different legal reach. Consistent policy enforcement across environments The same access controls, encryption expectations, and security policies follow the application across cloud, on‑prem, and edge—so migrations and incidents don’t create policy gaps. Inspectable, ownable control points for data in motion You can inspect, log, and constrain sensitive flows (including east‑west traffic) without relying exclusively on provider-native visibility. Evidence you can produce on demand You can answer “where did the data go, who accessed it, what controls were applied, and what changed during the incident?” with audit-ready artifacts. Credible exit and substitution paths You can shift workloads/providers under pressure without losing control of routing, policy, and telemetry, supporting third‑party risk requirements and resilience testing. The practical answer is to design around control points - places in the architecture where you can consistently enforce routing constraints, apply security and access policies, and generate evidence across environments. When these controls are independent of any single provider’s native constructs, organizations can meet sovereignty and residency obligations and satisfy resilience expectations like tested recovery, third‑party risk management, and credible exit strategies. This is the gap many “sovereign region” narratives don’t address: geography is necessary, but operational control under stress is what makes sovereignty and residency real.CPU load when Prometheus is scraping metrics from F5 BIG-IP LTM
We are experiencing an issue where Prometheus is scraping metrics from F5 BIG-IP LTM, causing high CPU and memory utilization on the F5 device. Initial step, we have adjusted the scraping interval to 1 minute, but the issue still. Are there any recommended tuning options or best practices?
