Sync error because Default logging profile and Custom profile both use local logging.
Hi. I am trying to setup a custom logging profile for bot manager because the default logging profile does not cover all the logging options that I need. I detached the default profile from the virtual server and attached my profile but it wont sync because of the error in the title. What are my options ? I can't setup remote logging at the moment.
Layered ASM for APM login page protection
Has anyone successfully implemented https://my.f5.com/manage/s/article/K000149701 Full VPN clinets stop working after this implementation. I can see below errors Client machines interface IPs are not falling under a private subnet or exception subnet ranges provided by the APM server The connected network is vulnerable of tunnel crack as LocalIP falls under the public IPs
Need BIG-IP VE Lab License for Personal Study/Learning
Hi F5 Community, I am setting up a personal home lab to learn. F5 BIG-IP for certification preparation. I have deployed BIG-IP VE but need a lab license. to access the management GUI. Could anyone help me get a free lab/evaluation? license for personal learning purposes? Thank you.F5 VELOS Backplane Inter-Tenants Communication
Hello, I’m looking for official documentation confirming whether inter-tenant communication between different tenants within the same chassis partition over the VELOS backplane is supported without requiring an external routing device. I haven’t been able to find clear guidance on this, so any assistance would be helpful. Regards
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?
Big IP licensed with wrong Base Registration Key
A Standalone big IP(APM) already in use; after Upgrade was unable to be licensed and it was discovered it was initially deployed and licensed with the base reg key meant for another big IP(LTM), F5 support assisted to get the correct Base Keys. However i was told i will have to manually reconfigure the Big ip after i license it and UCS restore wont work. is there a way i can reconfigure with the help of UCS.Migrate HW GTM 2600
Hi, I need to migrate 2 cluster Active/Passive frrom serie i to serie r. They are LTM (active standby) and GTM-DNS. I was thinking about adding two new members to the cluster and temporarily expanding it to a 6-node cluster. Then, on the day of the intervention, we could bring them online and remove two of the i-series nodes. To do this i have to ask for new SELF-IPS, new cables.....etc Anyone knows the best procedure to replacement these GTM/LTM nodes?F5 BIG-IP PEM telling the Service Provider's traffic story
A fundamental issue with Service Provider networks isn’t too much traffic. It’s that the network has no idea who is generating that traffic, what they’re doing, or what service plan they’re on. Without that context, every policy decision is blunt. F5 BIG-IP Policy Enforcement Manager (PEM) answers that problem for service providers. This article walks through how it works, and then gets into the specific use cases where it changes what’s operationally possible. How BIG-IP PEM builds subscriber context BIG-IP PEM sits inline between your subscribers and the network, between the GGSN/PGW and the internet or IMS core. Its first job is identity: before applying any policy, it needs to know who the subscriber is. It does this by intercepting RADIUS authentication and accounting packets when a subscriber logs onto the network, pulling the IMSI, IP address, username, and device type from those packets. That session binding (subscriber identity mapped to an IP address) is what makes every downstream decision context-aware. Once identity is established, BIG-IP PEM talks to the PCRF over a Gx interface to pull that subscriber’s policy. What plan are they on? Do they have any active add-ons or QoS entitlements? What usage thresholds apply? The PCRF answers, and BIG-IP PEM stores that configuration for the duration of the session. On top of identity, BIG-IP PEM classifies traffic at layers 4–7, using a combination of deep packet inspection and machine learning to identify over 4,000 applications, including encrypted OTT video that classic DPI tools can’t classify. The combination of who (subscriber) + what (application) + what plan (PCRF policy) is what makes fine-grained enforcement possible. Use case 1: Tiered service plans In practice, a subscriber on a premium plan gets priority queuing and higher guaranteed throughput. A basic plan subscriber hits a rate limiter when the network is congested. A business subscriber might get DSCP marking that carries their traffic with higher priority through downstream QoS domains. None of this is visible to the subscriber as a degraded experience it's just the service they signed up for, behaving as advertised. Bandwidth control in BIG-IP PEM operates at three levels: per subscriber, per-subscriber-group, and per application-type. That last one is particularly useful as you can rate-limit peer-to-peer traffic globally without touching the video or web browsing experience for anyone. The upside here isn’t just enforcing what subscribers already pay for. It’s giving your team the confidence to design genuinely differentiated tiers, knowing the network will actually enforce the difference. Use case 2: ABR video optimization Video traffic is now the majority of mobile network load, and most of it is encrypted adaptive bitrate (ABR), the same protocol that makes Netflix or YouTube automatically adjust quality based on available bandwidth. The challenge for operators is that encrypting video traffic means traditional inspections can’t see it clearly enough to manage it intelligently. BIG-IP PEM uses machine learning to detect and classify encrypted ABR flows, including QUIC-based streams without needing to decrypt them. Once identified, protocol-agnostic bandwidth controls are applied per flow. The practical use here is protecting RAN capacity. A single 4K stream can consume spectrum that would otherwise serve several standard-definition subscribers. BIG-IP PEM lets you cap 4K delivery during congestion periods, or apply it only to subscribers on plans that include HD streaming, without the subscriber experiencing a hard cutoff just a graceful step down in resolution. Preserving RAN capacity during peak hours has a direct effect on network investment cycles and subscriber satisfaction scores. Use case 3: Value-added service steering and service chaining Most SPs run a range of value-added services (VAS) ( video optimization servers, security inspection platforms, parental controls, web caching, anti-spam), but the traditional approach to using them is blunt: route all traffic through all services, or build a static linear chain. Both approaches waste resources and add latency where it isn’t needed. BIG-IP PEM enables selective steering: only send traffic to a VAS platform when it’s relevant, based on the combination of subscriber identity and traffic classification. A subscriber on a basic plan doesn’t need to hit the video optimization server. A business subscriber who hasn’t opted into the security bundle doesn’t need an anti-virus inspection. Service chaining goes a step further, allowing you to construct ordered service graphs that vary by subscriber type. For example: a subscriber requesting video content goes first to URL filtering (to check parental control settings), then to the video optimization server, then out to the network. Another subscriber browsing web content skips both. The chain is dynamic. It’s assembled based on what BIG-IP PEM learns from the PCRF. The infrastructure efficiency gain here is real: VAS platforms are expensive to run at scale, and right-sizing them to the traffic that actually needs them reduces both cost and latency. Use case 4: Tethering detection and policy Unauthorized tethering, where a subscriber shares their mobile data plan with other devices via a personal hotspot. This is a consistent headache for mobile operators. It puts additional load on the network under a plan that wasn’t priced for it, and it creates asymmetric capacity consumption that impacts other users in the same cell. BIG-IP PEM can detect tethering behavior through a combination of TTL analysis, user-agent inspection, and traffic pattern recognition. Once detected, it can enforce whatever policy you’ve defined: a hard cap on tethered traffic, a redirect to a tethering add-on purchase page, or an automatic upgrade to a multi-device plan. Use case 5: Parental controls as a managed service This one tends to get underestimated. URL filtering inside BIG-IP PEM lets service providers offer parental controls as a managed, network-level service that works regardless of which device or browser the subscriber uses, because the filtering happens on the network itself, not on the endpoint. Subscribers opt in (or you offer it as a default for certain plan types), and the SP maintains category lists that are enforced per subscriber. The commercial framing is straightforward: it’s a value-add that reduces churn among family plan subscribers and creates a natural differentiation from OTT competitors who can’t offer network-level enforcement. From an operational standpoint, category updates and custom block lists are managed centrally through BIG-IP PEM and pushed across the subscriber base with no endpoint agent deployment, and no device compatibility issues. Conclusion Putting it all together: BIG-IP PEM lives at the policy enforcement function (PEF) layer in 3GPP architecture. It’s inline on the Gi/SGi or N6 interface, sees all subscriber traffic, and acts as the enforcement point for whatever your PCRF has decided. The PCRF handles policy decisions; BIG-IP PEM handles policy execution. A few things worth calling out for anyone architecting this: BIG-IP PEM integrates with BIG-IP AFM for inline DDoS and network firewall, which means you can consolidate subscriber-facing security and policy enforcement on the same platform rather than running separate appliances for each. For operators running moving to 5G or 6G, BIG-IP PEM’s CNF deployment option means you don’t have to maintain two separate PEF architectures during the transition. Related Content BIG-IP Policy Enforcement Manager: Implementations F5BigPemPolicy Reference PEM: Subscriber-Aware Policy and Why Every Large Network Needs One | DevCentral PEM: Key Component of the Next Generation University Network | DevCentral
Functionality 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!where to download older F5 OS versions
Good day to F5 DevCentral Community, Is there any (F5) website from which we may download older F5 OS versions? i.e. OS versions that are older than the ones that are currently available in the F5 Downloads webpage. I'm specifically looking for where to download these F5 OS versions: 1. 12.1.2 Hotfix HF2 2.0.276 2. 12.1.4 Final 0.0.8
