Elevate Your Skills - Register for AppWorld 2025
AppWorld 2025 is set for February 25-27 in Las Vegas. Focusing on application security and delivery, this three-day event is packed with expert-led sessions, hands-on labs, and networking opportunities for practitioners and experts from around the world. F5 Academy is at the Heart of AppWorld 2025. Ideal for those working towards certification. You’ll engage with F5's latest products through hands-on labs, sharpen your skills, and earn digital badges. One free certification practice exam will be available before the event. You can earn (ISC)2 CPE credits for certain security-focused labs, and F5 will handle credit submission for you. --------------------------------------- UPDATE Nov 11. --------------------------------------- Labs and Briefings To Attend Find the full list of labs and briefingson the F5 Academy at AppWorld 25 page. F5 in the AI Era: For users who are new to AI, this briefing explores how F5 technology can help organizations with their AI journeys. F5 NGINX One: Learn how the NGINX One console provides visibility into a global fleet of NGINX instances, both NGINX Plus and NGINX Open Source (OSS). F5 Distributed Cloud: Discovering & Securing APIs: Get hands-on experience with the API Discovery and Security capabilities of F5 Web Application and API Protection (WAAP) within F5 Distributed Cloud. -------------------------------------------------------------------------------------------------- Why Attend? Learn: Access a year's worth of knowledge in three days through keynotes, solution-focused breakouts, product deep-dives, and roundtables. Connect: Network with professionals from DevCentral, NGINX, and F5 Insiders communities. Influence: Share your experiences with BIG-IP, Distributed Cloud, and NGINX to influence F5’s technology direction. Elevate your technical skills and connect with peers at AppWorld 2025; a must-attend event. Register for AppWorld 2025 today and join us in Las Vegas!Introducing F5 BIG-IP Next CNF Solutions for Red Hat OpenShift
5G and Red Hat OpenShift 5G standards have embraced Cloud-Native Network Functions (CNFs) for implementing network services in software as containers. This is a big change from previous Virtual Network Functions (VNFs) or Physical Network Functions (PNFs). The main characteristics of Cloud-Native Functions are: Implementation as containerized microservices Small performance footprint, with the ability to scale horizontally Independence of guest operating system,since CNFs operate as containers Lifecycle manageable by Kubernetes Overall, these provide a huge improvement in terms of flexibility, faster service delivery, resiliency, and crucially using Kubernetes as unified orchestration layer. The later is a drastic change from previous standards where each vendor had its own orchestration. This unification around Kubernetes greatly simplifies network functions for operators, reducing cost of deploying and maintaining networks. Additionally, by embracing the container form factor, allows Network Functions (NFs) to be deployed in new use cases like far edge. This is thanks to the smaller footprint while at the same time these can be also deployed at large scale in a central data center because of the horizontal scalability. In this article we focus on Red Hat OpenShift which is the market leading and industry reference implementation of Kubernetes for IT and Telco workloads. Introduction to F5 BIG-IP Next CNF Solutions F5 BIG-IP Next CNF Solutions is a suite of Kubernetes native 5G Network Functions, implemented as microservices. It shares the same Cloud Native Engine (CNE) as F5 BIG-IP Next SPK introduced last year. The functionalities implemented by the CNF Solutions deal mainly with user plane data. User plane data has the particularity that the final destination of the traffic is not the Kubernetes cluster but rather an external end-point, typically the Internet. In other words, the traffic gets in the Kubernetes cluster and it is forwarded out of the cluster again. This is done using dedicated interfaces that are not used for the regular ingress and egress paths of the regular traffic of a Kubernetes cluster. In this case, the main purpose of using Kubernetes is to make use of its orchestration, flexibility, and scalability. The main functionalities implemented at initial GA release of the CNF Solutions are: F5 Next Edge Firewall CNF, an IPv4/IPv6 firewall with the main focus in protecting the 5G core networks from external threads, including DDoS flood protection and IPS DNS protocol inspection. F5 Next CGNAT CNF, which offers large scale NAT with the following features: NAPT, Port Block Allocation, Static NAT, Address Pooling Paired, and Endpoint Independent mapping modes. Inbound NAT and Hairpining. Egress path filtering and address exclusions. ALG support: FTP/FTPS, TFTP, RTSP and PPTP. F5 Next DNS CNF, which offers a transparent DNS resolver and caching services. Other remarkable features are: Zero rating DNS64 which allows IPv6-only clients connect to IPv4-only services via synthetic IPv6 addresses. F5 Next Policy Enforcer CNF, which provides traffic classification, steering and shaping, and TCP and video optimization. This product is launched as Early Access in February 2023 with basic functionalities. Static TCP optimization is now GA in the initial release. Although the CGNAT (Carrier Grade NAT) and the Policy Enforcer functionalities are specific to User Plane use cases, the Edge Firewall and DNS functionalities have additional uses in other places of the network. F5 and OpenShift BIG-IP Next CNF Solutions fully supportsRed Hat OpenShift Container Platform which allows the deployment in edge or core locations with a unified management across the multiple deployments. OpenShift operators greatly facilitates the setup and tuning of telco grade applications. These are: Node Tuning Operator, used to setup Hugepages. CPU Manager and Topology Manager with NUMA awareness which allows to schedule the data plane PODs within a NUMA domain which is aligned with the SR-IOV NICs they are attached to. In an OpenShift platform all these are setup transparently to the applications and BIG-IP Next CNF Solutions uniquely require to be configured with an appropriate runtimeClass. F5 BIG-IP Next CNF Solutions architecture F5 BIG-IP Next CNF Solutions makes use of the widely trusted F5 BIG-IP Traffic Management Microkernel (TMM) data plane. This allows for a high performance, dependable product from the start. The CNF functionalities come from a microservices re-architecture of the broadly used F5 BIG-IP VNFs. The below diagram illustrates how a microservices architecture used. The data plane POD scales vertically from 1 to 16 cores and scales horizontally from 1 to 32 PODs, enabling it to handle millions of subscribers. NUMA nodes are supported. The next diagram focuses on the data plane handling which is the most relevant aspect for this CNF suite: Typically, each data plane POD has two IP address, one for each side of the N6 reference point. These could be named radio and Internet sides as shown in the diagram above. The left-side L3 hop must distribute the traffic amongst the lef-side addresses of the CNF data plane. This left-side L3 hop can be a router with BGP ECMP (Equal Cost Multi Path), an SDN or any other mechanism which is able to: Distribute the subscribers across the data plane PODs, shown in [1] of the figure above. Keep these subscribers in the same PODs when there is a change in the number of active data plane PODs (scale-in, scale-out, maintenance, etc...) as shown in [2] in the figure above. This minimizes service disruption. In the right side of the CNFs, the path towards the Internet, it is typical to implement NAT functionality to transform telco's private addresses to public addresses. This is done with the BIG-IP Next CG-NAT CNF. This NAT makes the return traffic symmetrical by reaching the same POD which processed the outbound traffic. This is thanks to each POD owning part of this NAT space, as shown in [3] of the above figure. Each POD´s NAT address space can be advertised via BGP. When not using NAT in the right side of the CNFs, it is required that the network is able to send the return traffic back to the same POD which is processing the same connection. The traffic must be kept symmetrical at all times, this is typically done with an SDN. Using F5 BIG-IP Next CNF Solutions As expected in a fully integrated Kubernetes solution, both the installation and configuration is done using the Kubernetes APIs. The installation is performed using helm charts, and the configuration using Custom Resource Definitions (CRDs). Unlike using ConfigMaps, using CRDs allow for schema validation of the configurations before these are applied. Details of the CRDs can be found in this clouddocs site. Next it is shown an overview of the most relevant CRDs. General network configuration Deploying in Kubernetes automatically configures and assigns IP addresses to the CNF PODs. The data plane interfaces will require specific configuration. The required steps are: Create Kubernetes NetworkNodePolicies and NetworkAttchment definitions which will allow to expose SR-IOV VFs to the CNF data planes PODs (TMM). To make use of these SR-IOV VFs these are referenced in the BIG-IP controller's Helm chart values file. This is described in theNetworking Overview page. Define the L2 and L3 configuration of the exposed SR-IOV interfaces using the F5BigNetVlan CRD. If static routes need to be configured, these can be added using the F5BigNetStaticroute CRD. If BGP configuration needs to be added, this is configured in the BIG-IP controller's Helm chart values file. This is described in the BGP Overview page. It is expected this will be configured using a CRD in the future. Traffic management listener configuration As with classic BIG-IP, once the CNFs are running and plumbed in the network, no traffic is processed by default. The traffic management functionalities implemented by BIG-IP Next CNF Solutions are the same of the analogous modules in the classic BIG-IP, and the CRDs in BIG-IP Next to configure these functionalities are conceptually similar too. Analogous to Virtual Servers in classic BIG-IP, BIG-IP Next CNF Solutions have a set of CRDs that create listeners of traffic where traffic management policies are applied. This is mainly the F5BigContextSecure CRD which allows to specify traffic selectors indicating VLANs, source, destination prefixes and ports where we want the policies to be applied. There are specific CRDs for listeners of Application Level Gateways (ALGs) and protocol specific solutions. These required several steps in classic BIG-IP: first creating the Virtual Service, then creating the profile and finally applying it to the Virtual Server. In BIG-IP Next this is done in a single CRD. At time of this writing, these CRDs are: F5BigZeroratingPolicy - Part of Zero-Rating DNS solution; enabling subscribers to bypass rate limits. F5BigDnsApp - High-performance DNS resolution, caching, and DNS64 translations. F5BigAlgFtp - File Transfer Protocol (FTP) application layer gateway services. F5BigAlgTftp - Trivial File Transfer Protocol (TFTP) application layer gateway services. F5BigAlgPptp - Point-to-Point Tunnelling Protocol (PPTP) application layer gateway services. F5BigAlgRtsp - Real Time Streaming Protocol (RTSP) application layer gateway services. Traffic management profiles and policies configuration Depending on the type of listener created, these can have attached different types of profiles and policies. In the case of F5BigContextSecure it can get attached thefollowing CRDs to define how traffic is processed: F5BigTcpSetting - TCP options to fine-tune how application traffic is managed. F5BigUdpSetting - UDP options to fine-tune how application traffic is managed. F5BigFastl4Setting - FastL4 option to fine-tune how application traffic is managed. and the following policies for security and NAT: F5BigDdosPolicy - Denial of Service (DoS/DDoS) event detection and mitigation. F5BigFwPolicy - Granular stateful-flow filtering based on access control list (ACL) policies. F5BigIpsPolicy - Intelligent packet inspection protects applications from malignant network traffic. F5BigNatPolicy - Carrier-grade NAT (CG-NAT) using large-scale NAT (LSN) pools. The ALG listeners require the use of F5BigNatPolicy and might make use for the F5BigFwPolicyCRDs.These CRDs have also traffic selectors to allow further control over which traffic these policies should be applied to. Firewall Contexts Firewall policies are applied to the listener with best match. In addition to theF5BigFwPolicy that might be attached, a global firewall policy (hence effective in all listeners) can be configured before the listener specific firewall policy is evaluated. This is done with F5BigContextGlobal CRD, which can have attached a F5BigFwPolicy. F5BigContextGlobal also contains the default action to apply on traffic not matching any firewall rule in any context (e.g. Global Context or Secure Context or another listener). This default action can be set to accept, reject or drop and whether to log this default action. In summary, within a listener match, the firewall contexts are processed in this order: ContextGlobal Matching ContextSecure or another listener context. Default action as defined by ContextGlobal's default action. Event Logging Event logging at high speed is critical to provide visibility of what the CNFs are doing. For this the next CRDs are implemented: F5BigLogProfile - Specifies subscriber connection information sent to remote logging servers. F5BigLogHslpub - Defines remote logging server endpoints for the F5BigLogProfile. Demo F5 BIG-IP Next CNF Solutions roadmap What it is being exposed here is just the begin of a journey. Telcos have embraced Kubernetes as compute and orchestration layer. Because of this, BIG-IP Next CNF Solutions will eventually replace the analogous classic BIG-IP VNFs. Expect in the upcoming months that BIG-IP Next CNF Solutions will match and eventually surpass the features currently being offered by the analogous VNFs. Conclusion This article introduces fully re-architected, scalable solution for Red Hat OpenShift mainly focused on telco's user plane. This new microservices architecture offers flexibility, faster service delivery, resiliency and crucially the use of Kubernetes. Kubernetes is becoming the unified orchestration layer for telcos, simplifying infrastructure lifecycle, and reducing costs. OpenShift represents the best-in-class Kubernetes platform thanks to its enterprise readiness and Telco specific features. The architecture of this solution alongside the use of OpenShift also extends network services use cases to the edge by allowing the deployment of Network Functions in a smaller footprint. Please check the official BIG-IP Next CNF Solutions documentation for more technical details and check www.f5.com for a high level overview.Upcoming Action Required: F5 NGINX Plus R33 Release and Licensing Update
Hello community! The upcoming release of NGINX Plus R33 is scheduled for this quarter. This release brings changes to our licensing process, aligning it with industry best practices and the rest of the F5 licensing programs. These updates are designed to better serve our commercial customers by providing improved visibility into usage, streamlined license tracking, and enhanced customer service. Key Changes in NGINX Plus R33 Release: Q4, 2024 New Requirement: All commercial NGINX Plus instances will now require the placement of a JSON Web Token (JWT). This JWT file can be downloaded from your MyF5 account. License Validation: NGINX Plus instances will regularly validate their license status with the F5 licensing endpoint for connected customers. Offline environments can manage this through the NGINX Instance Manager. Usage Reporting: NGINX Plus R33 introduces a new requirement for commercial product usage reporting. NGINX's adoption of F5's standardized approach ensures easier and more precise license and usage tracking. Once our customers are utilizing R33 together with NGINX’s management options, tasks such as usage reporting and renewals will be much more streamlined and straightforward. Additionally, NGINX instance visibility and management will be much easier. Action Required To ensure a smooth transition and uninterrupted service, please take the following steps: Install the JWT: Make sure to install the JWT on all your commercial NGINX Plus instances. This is crucial to avoid any interruptions. Additional Steps: Refer to our detailed guide for any other necessary steps.See here for additional required next steps. IMPORTANT: Failure to followthese steps will result in NGINX Plus R33 and subsequent release instances not functioning. Critical Notes JWT Requirement: JWT files are essential for the startup of NGINX Plus R33. NGINX Ingress Controller: Users of NGINX Ingress Controller should not upgrade to NGINX Plus R33 until the next version of the Ingress Controller is released. No Changes for Earlier Versions: If you are using a version of NGINX Plus prior to R33, no action is required. Resources We are preparing a range of resources to help you through this transition: Support Documentation: Comprehensive support documentation will be available upon the release of NGINX Plus R33. Demonstration Videos: We will also provide demonstration videos to guide you through the new processes upon the release of NGINX Plus R33. NGINX Documentation: For more detailed information, visit our NGINX documentation. Need Assistance? If you have any questions or concerns, please do not hesitate to reach out: F5 Representative: Contact your dedicated representative for personalized support. MyF5 Account: Support is readily available through your MyF5 account. Stay tuned for more updates. Thank you for your continued partnership.DevCentral ICYMI - September 2024
DevCentral publishes new content constantly, and it’s easy to miss the latest from F5’s technical user community with all that turnover. So here’s a monthly round-up of DevCentral news, content, and events—in case you missed it! New and Notable Share Your Expertise at F5 AppWorld 2025! CFP is now open. F5 and NetApp partnership for Large Language Model AI deployments - F5 and NetApp have teamed up to improve enterprise AI capabilities by using F5’s secure multicloud networking solutions with NetApp’s data management tools. Experience the power of F5 NGINX One with feature demos - Introducing F5 NGINX One, a powerful solution designed to significantly enhance business operations with its high-performance data plane and user-friendly SaaS-based console, offering robust traffic management and critical monitoring features. Content Round-Up AI/LLM F5 BIG-IP and NetApp StorageGRID - Providing Fast and Scalable S3 API for AI apps - F5 BIG-IP's advanced load balancing improves HTTPS server performance. It ensures high availability and optimal storage node utilization when used with NetApp's StorageGRID S3 compatible object storage. How to Prepare Your Network Infrastructure to Add HPC Clusters for AI to Your Data Center - HPC AI cluster integration in enterprise data centers brings challenges, such as network segmentation, security, and high costs. Learn how to overcome these challenges. F5 Distributed Cloud: How I Did it - Migrating Applications to Nutanix NC2 with F5 Distributed Cloud Secure Multicloud Networking - Enterprises struggle to scale and migrate applications while maintaining consistent security and user experience. F5 Distributed Cloud Services (XC) simplifies extending and migrating applications from on-premises environments to Nutanix NC2 clusters, backed by Nutanix's comprehensive hyper-converged infrastructure. Security Insights What is Web Cache Exploitation? - Explore insights from a recent BlackHat/DefCon 2024 presentation on Web Cache Exploitation, which reveals how discrepancies in HTTP server and proxy behaviors can lead to vulnerabilities like Web Cache Poisoning and Web Cache Deception. (HTTP) Redirection via Arbitrary Host Header - In this article, we delve into the importance of the Host header in web requests, its role in enabling multiple-domain hosting, and the potential security risks associated with improper handling. How to Identify and Manage Scrapers (Pt. 1) and How to Identify and Manage Scrapers (Pt. 2) - Here are different ways to find and manage web scraping activities. This includes: scrapers that identify themselves, identifying using IP address, more advanced techniques for finding scrapers that don't identify themselves. We will also talk about the challenges caused by pretending to be someone else and the increase in scraping done by AI. Exploring the Zero Trust Models of AWS, Microsoft, and Google - In response to distributed workforces and advanced cyber threats, the Zero Trust Model enforces strict identity verification, granular access control, and continuous monitoring for users, devices, and resources. Major cloud providers like AWS, Microsoft, and Google have their own versions. Scanning for CVE-2017-9841 Drops Precipitously - The July 2024 Sensor Intelligence Series reports a significant drop in scanning activities for vulnerabilities CVE-2017-9841 and CVE-2023-1389, despite their previous high levels. This highlights the importance of ongoing cybersecurity vigilance. Scuba Gear from CISA, ROBLOX Malware Campaign, and RUST backdoo-rs This Week in Security Leaks & breaches, memory-safe C++, cryptominers and bridging the air-gap This Week in Security GC Document AI Transitive Access Abuse, make-me-root holes in VMWare fixed and more - This Week in Security BIG-IP Next: How to secure egress with F5 Service Proxy for Kubernetes (Japanese language version: 次世代のBIG-IP SPKとK8s コンテナの外部アクセス制御) - Securing Kubernetes egress traffic can be challenging. F5's Service Proxy for Kubernetes (SPK) offers a solution. It dynamically manages egress through its Calico egress gateway. This allows for central control, consistent network policies, and source NAT translation. BIG-IP Next Installation Guides - These resources will walk you through the initial steps of getting Central Manager and instances installed on the various platforms for labs and production. F5 Distributed Cloud: How I Did it - Migrating Applications to Nutanix NC2 with F5 Distributed Cloud Secure Multicloud Networking -Enterprises face challenges with scaling and migrating applications. F5 Distributed Cloud Services (XC) helps by enabling seamless application extension and migration, as shown with Nutanix NC2 clusters. Architecture Options for Kubernetes Service Discovery in Distributed Cloud - F5 Distributed Cloud (XC) Virtual Edition Customer Edge increases service discovery in Kubernetes clusters, allowing easy connectivity in dynamic microservices environments. Cascading Configs Tool for F5 Distributed Cloud Managed Service Provider (MSP) and Delegated Access Customers - The new XC-Cascading-Configs tool simplifies configuration management for F5 Distributed Cloud customers. It allows efficient push and maintenance of shared configurations across multiple tenants. NGINX: Deploying F5 NGINX Plus Graviton-powered Containers as AWS ECS Fargate Tasks - Amazon's Graviton4 chip offers great price-performance for cloud architects. NGINX Plus works with ARM64, ECS, and ECS Fargate. It's easy to set up, use, and scale within AWS. Announcing F5 NGINX Gateway Fabric 1.4.0 with IPv6 and TLS Passthrough - NGINX Gateway Fabric 1.4.0 features IPv6 support, TLS passthrough, server zone metrics, custom pod annotations, and improved testing automation. It ensures stability and performance for Kubernetes clusters. BIG-IP: F5 BIG-IP deployment with Red Hat OpenShift - keeping client IP addresses and egress flows - OpenShift 4.14's AdminPolicyBasedExternalRoute improves control of egress traffic by utilizing F5 BIG-IP as the default gateway for certain namespaces. This feature ensures client IP preservation and integrates security functions. BIG-IP VE in Red Hat OpenShift Virtualization - Running BIG-IP VE in Red Hat OpenShift Virtualization connects virtual machines and Kubernetes. This simplifies management and operations by using OpenShift's KubeVirt and QEMU+KVM Linux virtualization layers. VMware to Red Hat OpenShift Virtualization Migration - Seamlessly migrate workloads and BIG-IP Virtual Editions from VMware to OpenShift Virtualization. Our comprehensive guide will streamline your transition and unify your application infrastructure. F5 Cloud Failover Extension (CFE), private endpoints, and custom DNS - Using the F5 Cloud Failover Extension (CFE) for API-based failover in public cloud environments can cause issues with API calls being blocked. This is due to custom DNS settings and private endpoints. To resolve this, configure DNS settings to properly resolve private IP addresses.
