AWS

133 Topics

Get Started with BIG-IP and BIG-IQ Virtual Edition (VE) Trial
Welcome to the BIG-IP and BIG-IQ trials page! This will be your jumping off point for setting up a trial version of BIG-IP VE or BIG-IQ VE in your environment. As you can see below, everything you’ll need is included and organized by operating environment — namely by public/private cloud or virtualization platform. To get started with your trial, use the following software and documentation which can be found in the links below. Upon requesting a trial, you should have received an email containing your license keys. Please bear in mind that it can take up to 30 minutes to receive your licenses. Don't have a trial license? Get one here. Or if you're ready to buy, contact us. Looking for other Resources like tools, compatibility matrix... BIG-IP VE and BIG-IQ VE When you sign up for the BIG-IP and BIG-IQ VE trial, you receive a set of license keys. Each key will correspond to a component listed below: BIG-IQ Centralized Management (CM) — Manages the lifecycle of BIG-IP instances including analytics, licenses, configurations, and auto-scaling policies BIG-IQ Data Collection Device (DCD) — Aggregates logs and analytics of traffic and BIG-IP instances to be used by BIG-IQ BIG-IP Local Traffic Manager (LTM), Access (APM), Advanced WAF (ASM), Network Firewall (AFM), DNS — Keep your apps up and running with BIG-IP application delivery controllers. BIG-IP Local Traffic Manager (LTM) and BIG-IP DNS handle your application traffic and secure your infrastructure. You’ll get built-in security, traffic management, and performance application services, whether your applications live in a private data center or in the cloud. Select the hypervisor or environment where you want to run VE: AWS CFT for single NIC deployment CFT for three NIC deployment BIG-IP VE images in the AWS Marketplace BIG-IQ VE images in the AWS Marketplace BIG-IP AWS documentation BIG-IP video: Single NIC deploy in AWS BIG-IQ AWS documentation Setting up and Configuring a BIG-IQ Centralized Management Solution BIG-IQ Centralized Management Trial Quick Start Azure Azure Resource Manager (ARM) template for single NIC deployment Azure ARM template for three NIC deployment BIG-IP VE images in the Azure Marketplace BIG-IQ VE images in the Azure Marketplace BIG-IQ Centralized Management Trial Quick Start BIG-IP VE Azure documentation Video: BIG-IP VE Single NIC deploy in Azure BIG-IQ VE Azure documentation Setting up and Configuring a BIG-IQ Centralized Management Solution VMware/KVM/Openstack Download BIG-IP VE image Download BIG-IQ VE image BIG-IP VE Setup BIG-IQ VE Setup Setting up and Configuring a BIG-IQ Centralized Management Solution Google Cloud Google Deployment Manager template for single NIC deployment Google Deployment Manager template for three NIC deployment BIG-IP VE images in Google Cloud Google Cloud Platform documentation Video: Single NIC deploy in Google Other Resources AskF5 Github community (f5devcentral, f5networks) Tools to automate your deployment BIG-IQ Onboarding Tool F5 Declarative Onboarding F5 Application Services 3 Extension Other Tools: F5 SDK (Python) F5 Application Services Templates (FAST) F5 Cloud Failover F5 Telemetry Streaming Find out which hypervisor versions are supported with each release of VE. BIG-IP Compatibility Matrix BIG-IQ Compatibility Matrix Do you have any comments or questions? Ask here
RomanJ
Jan 24, 2017 Place Technical Articles
70KViews
8likes
24Comments
BIG-IP integration with AWS Gateway Load Balancer - Overview
Introduction With the release of TMOS version 16.1, BIG-IP now supports AWS Gateway Load Balancer (GWLB). With this integration we are making it much easier and simpler to insert BIG-IP security services into an AWS environment while maintaining high availability and supporting elastic scalability of the BIG-IP's. When to use GWLB? F5 BIG-IP delivers a wide range of application and security services. Depending on the service and other requirements the BIG-IP's are typically deployed in one of two modes: Network mode or Proxy mode. Important: GWLB is only applicable today with Network deployment mode. First, you should identify which deployment mode is relevant for you: Network (GWLB Supported) Common use cases: Network firewall, DDoS protection, Transparent WAF Flow transparency is maintained (no source or destination NAT) Directing traffic to the BIG-IP's is done using routing by the network, making sure traffic goes back to the same BIG-IP in order to maintain traffic symmetry is also based on routing Proxy (Not GWLB Supported) Providing ingress services to the application (WAF, LB, L7 DDoS, Bot protection), services are applied to an application specific virtual server on the BIG-IP The BIG-IP SNAT (source NAT) manages the traffic to ensure that the return traffic arrives at the same BIG-IP thus maintaining traffic symmetry Directing user's traffic to the BIG-IP's is usually done using DNS. A FQDN will map to a specific virtual server on the BIG-IP. Important: GWLB does not support proxy devices in the inspection zone. Traffic flow must remain unchanged by the inspection device, for more details see: https://aws.amazon.com/blogs/networking-and-content-delivery/integrate-your-custom-logic-or-appliance-with-aws-gateway-load-balancer/ ). Existing challenges of BIG-IP Network deployment without GWLB Let's examine two scenarios in which we use the BIG-IP for inspecting network traffic: Ingress/Egress protection: In this scenario, we want to inspect all traffic coming into and going out of the AWS network. The security services that are most relevant for this scenario are: Firewall, DDOS protection, WAF and IPS. East west (Inter VPC / networks) protection: In this scenario we want to inspect all traffic between VPC's and between on-prem to VPC's. The most common security services used are Firewall and IPS. In the two scenarios mentioned above, we need to ensure the relevant flows are routed to the BIG-IP. We will also need to verify that traffic is symmetric – meaning any flow that was sent to the BIG-IP must also return from the same BIG-IP. Today, without GWLB, our method of getting traffic to the BIG-IP is to manipulate the routing tables accordingly. AWS's routing tables accepts an ENI (Elastic Network Interface, a Network interface of an EC2 instance running a BIG-IP) as the 'gateway' for a specific route. Since routing tables only accepts a single ENI, we can only send traffic to a single BIG-IP instance - which of course creates a single point of failure. We can further improve this design by leveraging F5's Cloud Failover Extension (CFE) which allows us to create an active/standby pair. The CFE will automatically manipulate the route tables to always point traffic at the ENI of the active device. You can read more on this design here: https://clouddocs.f5.com/products/extensions/f5-cloud-failover/latest/userguide/aws.html?highlight=route In summary, the network deployment of the BIG-IP in AWS has the following challenges: Limited scale - Throughput, concurrent connections etc. as only a single device processes the traffic Unoptimized compute – Passive device sits idle Mixed admin domains – BIG-IP's are deployed in the same VPC as the workloads it is protecting, routing table changes are controlled by F5's CFE which is not always wanted or possible How GWLB works with BIG-IP To understand how AWS GWLB works, let's start by taking a closer look at the GWLB. We can break down the GWLB functionality into two main elements: On the frontend: GWLB presents itself as a next-hop L3 Gateway to manage traffic transparently. GWLB uses a new component: GWLB endpoint. This endpoint acts as an ENI (Elastic Network Interface) of the GWLB. The only way of sending traffic to GWLB is through this endpoint, therefore it is deployed in a VPC that consumes the security services (i.e. the Consumer VPC). Admin domain separation: The GWLB and BIG-IP fleet are deployed in their own VPC (Security VPC). One GWLB can receive and inspect traffic from many VPC's (find more detail on design patterns in the 'Deployments' section) On the backend: GWLB is like a L4 Load Balancer, very similar to NLB (Network Load Balancer) Provides traffic distribution across a fleet of BIG-IP instances. Routes flows and assigns them to specific BIG-IP for stateful inspection. Performs health-checks of the BIG-IP's, and routes traffic to healthy BIG-IP's only. Traffic is sent over a L3 tunnel using the GENEVE protocol (Requires BIG-IP version 16.1 and above) BIG-IP integration details: Requirements: BIG-IP version 16.1 and above BIG-IP traffic flow: The BIG-IP must be deployed in the same VPC as the GWLB. BIG-IP receives traffic from GWLB over a GENEVE tunnel that uses the BIG-IPs private ip address. Next, we create a virtual server that is enabled on the new tunnel. The new tunnel gets the traffic from GWLB, decapsulates it and then it gets processed by the inspection virtual server. After the virtual server processes the packet and applies the defined security profiles, it needs to forward the packet back to the tunnel. The way to 'Force' traffic back into the tunnel is to create a fake node that 'lives' inside the tunnel and use it as the target pool of the virtual server. Once the tunnel interface receives the packets from the virtual server, it encapsulates them with GENEVE and forwards it back to GWLB. The following diagram describes the traffic flow within a specific BIG-IP device: Considerations and known issues: Traffic flows inside the 'inspection zone' must remain unchanged. i.e, no change in the packet's 5 tuple is allowed. All virtual servers are supported as long as the 5 tuple of the packet is maintained. That might require changing some configurations, for example Disable the default 'address translation' feature of a 'standard' virtual server. Set the 'source port' setting to 'Preserve strict' Payload manipulation is supported as long as the packet's 5 tuple is maintained Some examples: HTTP rewrites AWAF blocking responses – AWAF responds with a 'blocking page' High Availability When a BIG-IP instance fails in the target group, GWLB continue to send existing flows to the failed instance. Only new connections will be directed to a new instance. Deploy BIG-IP instances across availability zones according to the desired AZ availability requirements. The Default behavior for GWLB is to keep traffic in the same AZ, meaning traffic that was received on an endpoint in AZ1 will only forward traffic to instances in AZ1. That behavior is controlled by the 'CrossZoneLoadBalancing' flag https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-crosszone-lb.html If you do change the 'CrossZoneLoadBalancing' flag, keep in mind that GWLB will distribute traffic across AZ's even when all instances are healthy and will incur cross-AZ traffic costs. Flow timeout GWLB has its own protocol timeouts (350 seconds for TCP, 120 for UDP). the timeout values on the BIG-IP must be smaller then the ones on GWLB - BIG-IP uses 300 seconds for TCP and 60 for UDP by default. With the GWLB integration you can now create an elastic group of BIG-IP's that will be exposed to the rest of the AWS network using AWS native networking constructs. GWLB is responsible for distributing the traffic evenly between the group while maintaining flow affinity so that each flow will always be routed to the same BIG-IP in the group and thus solving the symmetric flows without requiring any SNAT. The security inspection zone can be deployed in its own VPC, allowing better administrative separation. Exposing the inspection service is done using VPC endpoints, those endpoints are tied to the GWLB and can be used as the target of different routing tables (TGW, Ingress, subnets). Summary The BIG-IP and GWLB integration enables the industry leading BIG-IP security services with the following benefits: Elastic scalability: Scale your deployment based on your actual usage. Horizontally scale your BIG-IP's. Simplified connectivity: Leverage AWS native networking constructs to 'insert' BIG-IP security services in different traffic flows (North-South, East-West) Cost effectiveness: Consolidate BIG-IP's deployments and size the deployment based on actual usage Next steps: Check out the next articles in this series - Ingress/Egress VPC inspection with BIG-IP and GWLB deployment pattern Ingress/Egress and inter VPC inspection with BIG-IP and GWLB deployment pattern Test the integration yourself - Check out our self-service lab that you can deploy in your own AWS account (Fully automated deployment using Terraform): https://github.com/f5devcentral/f5-digital-customer-engagement-center/tree/main/solutions/security/ingress-egress-fw https://github.com/f5devcentral/f5-digital-customer-engagement-center/tree/main/solutions/security/ingress-egress-inter-vpc-fw-gwlb
Yossi_Rosenboi1
Jul 29, 2021 Place Technical Articles
11KViews
6likes
2Comments
Deploy BIG-IP in AWS with HA across AZ’s - without using EIP’s
Background: The CloudFormation templates that are provided and supported by F5 are an excellent resource for customers to deploy BIG-IP VE in AWS. Along with these templates, documentation guiding your F5 deployment in AWS is an excellent resource. And of course, DevCentral articles are helpful. I recommend reading about HA topologies in AWS to start. I hope my article today can shed more light on an architecture that will suit a specific set of requirements: No Elastic IP's (EIP’s), High Availability (HA) across AZ’s, and multiple VPC’s. Requirements behind this architecture choice: I recently had a requirement to deploy BIG-IP appliances in AWS across AZ’s. I had read the official deployment guide, but I wasn’t clear on how to achieve failover without EIP’s. I was given 3 requirements: HA across AZ’s. In this architecture, we required a pair of BIG-IP devices in Active/Standby, where each device was in a different AZ. I needed to be able to fail over between devices. No EIP’s. This requirement existed because a 3 rd party firewall was already exposed to the Internet with a public IP address. That firewall would forward inbound requests to the BIG-IP VE in AWS, which in turn proxied traffic to a pair of web servers. Therefore, there was no reason to associate an EIP (a public IP address) with the BIG-IP interface. In my demo below I have not exposed a public website through a 3 rd party firewall, but to do so is a simple addition to this demo environment. Multiple VPC’s. This architecture had to allow for multiple VPC’s in AWS. There was already a “Security VPC” which contained firewalls, BIG-IP devices, and other devices, and I had to be able to use these devices for protecting applications that were across 1 or more disparate VPC’s. Meeting the requirements: HA across AZ’s This is the easiest of the requirements to meet because F5 has already provided templates to deploy these in AWS. I personally used a 2-nic device, with a BYOL license, deployed to an existing VPC, so that meant my template was this one. After this deployment is complete, you should have a pair of devices that will sync their configuration. At time of failover The supported F5 templates will deploy with the Advanced HA iApp. It is important that you configure this iApp after you have completed your AWS deployments. The iApp uses IAM permissions deployed with the template to make API calls to AWS at the time of failover. The API calls will update the route tables that you specify within the iApp wizard. Because this iApp is installed on both devices, either device can update the route in your route tables to point to its own interface. Update as of Dec 2019 This article was first written Feb 2019, and in Dec 2019 F5 released the Cloud Failover Extension (CFE), which is a cloud-agnostic, declarative way to configure failover in multiple public clouds. You can use the CFE instead of the Advanced HA iApp to achieve high availability between BIG-IP devices in cloud. Update as of Apr 2020 Your API calls will typically be sent to the public Internet endpoints for AWS EC2 API calls. Optionally, you can use AWS VPC endpoints to keep your API calls out to AWS EC2 from traversing the public Internet. My colleague Arnulfo Hernandez has written an article explaining how to do this. No EIP’s Configure an “alien IP range” I’m recycling another DevCentral solution here. You will need to choose an IP range for your VIP network that does not fall within the CIDR that is assigned to your VPC. Let’s call it an “alien range” because it “doesn’t belong” in your VPC and you couldn’t assign IP addresses from this range to your AWS ENI’s. Despite that, now create a route table within AWS that points this “alien range” to your Active BIG-IP device’s ENI (if you’re using a 2+ nic device, point it to the correct data plane NIC, not the Mgmt. interface). Don’t forget to associate the route table with specific subnets, per your design. Alternatively, you could add this route to the default VPC route table. Create a VIP on your active device Now create a VIP on your active device and configure the IP address as an IP within your alien range. Ensure the config replicates to your standby device. Ensure that source/destination checking is disabled on the ENI’s that your AWS routes are pointing to (on both Standby and Active devices). You should now have a VIP that you can target from other hosts in your VPC, provided that the route you created above is applied to the traffic destined to the VIP. Multiple VPC’s For extra credit, we’ll set up a Transit Gateway. This will allow other VPCs to route traffic to this “alien range” also, provided that the appropriate routes exist in the remote VPC’s, and also are applied to the appropriate Transit Gateway Route Table. Again, I’m recycling ideas that have already been laid out in other DevCentral posts. I won’t re-hash how to set up a transit gateway in AWS, because you can follow the linked post above. Sufficed to say, this is what you will need to set up if you want to route between multiple VPC’s using a transit gateway: 2 or more VPC’s A transit gateway in AWS Multiple transit gateway attachments that attach the transit gateway and each VPC you would like to route between. You will need one attachment per VPC. A transit gateway route table that is associated with each attachment. I will point out that you need to add a route for your “alien range” in your transit gateway route table, and in your remote VPC’s. That way, hosts in your remote VPC’s will forward traffic destined to your alien range (VIP network) to the transit gateway, and the transit gateway will forward it to your VPC, and the route you created in Step A will forward that traffic to your active BIG-IP device. Completed design: After the above configuration, you should have an environment that looks like the diagram below: Tips Internet access for deployments: When you deploy your BIG-IP devices, they will need Internet access to pull down some resources, including the iApp. So if you are deploying devices into your existing VPC, make sure you have a reachable Internet Gateway in AWS so that the devices have Internet access through both their management interface, and their data plane interface(s). Internet access for failover: Remember that an API call to AWS will still use an outbound request to the Internet. Make sure you allow the BIG-IP devices to make outbound connections over HTTPS to the Internet. If this is not available, you will find that your route tables are not updated at time of failover. (If you have a hard requirement that your devices should not have outbound access to internet, you can follow Arnulfo's guide linked to above and use VPC endpoints to keep this traffic on your local VPC) iApp logs: you can enable this in the iApp settings. I have used the logs (in /var/ltm/log) to troubleshoot issues that I have created myself. That’s how I learned not to accidentally cut off Internet access for your devices! Don’t forget about return routes if SNAT is disabled: Just like on-prem environments, if you disable SNAT, the pool member will need to route return traffic back to the BIG-IP device. You will commonly set up a default route (0.0.0.0/0) in AWS, point it at the ENI of the active BIG-IP device, and associate this route table with the subnet containing the pool members. If the pool members are in a remote VPC, you will need to create this route on the transit gw route table also. Don’t accidentally cut off internet access: When you configure the default route of 0.0.0.0/0 to point to eth1 of the BIG-IP device, don’t apply this route to every subnet in your Security VPC. It may be easy to do so accidentally, but remember that it could cause the API calls to update route tables to fail when the Standby device becomes Active. Don’t forget to disable source/dest check on your ENI’s. This is configured by the template, but if you have other devices that require it, remember to check this setting.
MichaelOLeary
Feb 21, 2019 Place Technical Articles
8.4KViews
5likes
27Comments
Easy demo: Protect container traffic to EKS with BIG-IP
Intro EKS (Elastic Kubernetes Service) is popular! It allows you to deploy apps without managing the Kubernetes mgmt plane yourself. If you're planning to run an app using EKS, you will likely need to consider ingress security along with that app. Securing traffic into Kubernetes is a topic we love to talk about at F5. Why would you want a demo securing traffic into EKS? It's fully automated! Since most people are new to Kubernetes (k8s for short), I find myself in need of a quick demo that's totally open for anyone to run. This way after I demo, the audience can go back to run it on their own, decompose it for themselves, and take their own time to understand it all. Here's what we will automatically deploy: Prerequisites In short, you'll need an AWS demo account, a workstation with Terraform installed, your AWS creds configured, and the aws-iam-authenticator installed. Here's a VM with all of your prerequisites: If you don't have a workstation with Terraform installed, don't worry! You can easily set up the client workstation you need by deploying this demo workstation, which will have all the required tools. Then, configure your AWS IAM credentials. Side note: When building a cloud solution example, I try to stay as "vendor neutral" as practical and avoid using 3rd party tools when possible. For example, I have written a demo using AWS Lambda functions, instead of a 3rd party automation tool, for post-deployment configuration. This might be preferred if you do not (or cannot) use a particular 3rd party tool. So I originally started down the path of following this article to completely build an EKS demo via CFT. I planned to extend the quickstart demo to include an ingress controller and security policy, along with an app to protect. I guess I planned to use Lambda functions again. However, after talking about this with colleagues, the workarounds came to seem silly: nobody would do this in real life, so constraining myself to only using a CFT seemed unnecessary. Instead I chose to use the ubiquitous tool Terraform. This is easier to use and also saves me from requiring a user to have a few other tools, like kubectl, helm, and aws-iam-authenticator, etc. So, for better or worse, Terraform is a pre-req here. The workstation I've used is Ubuntu 18.04. Now, for the demo To deploy: You'll need Terraform set up and your AWS credentials configured. Optionally, deploy a demo workstation by following the ReadMe guide here. Configure your AWS credentials in a demo account. Remember, this demo will deploy AWS resources that will cost you money via your AWS bill. Don't forget to destroy all resources at the end of your demo. If you choose to skip this step, proceed with your own client workstation. But if you hit failures, I recommend using this demo workstation, since it is what I used when building this demo. Connect to your workstation and run these commands. When prompted for confirmation, type "yes" as instructed. git clone https://github.com/mikeoleary/aws-eks-bigip-terraform cd aws-eks-bigip-terraform/vpc terraform init terraform plan terraform apply You've deployed! You will need to wait around 20 mins for everything to deploy: a VPC, EKS, a BIG-IP, and then an application in EKS to be protected by BIG-IP. To see your finished product: Once your Terraform commands have completed, you should see output values. If not, type this and take a note of the output values: terraform output Now, open a web browser and visit http://<public_ip_app>. If you want to inspect the configuration of BIG-IP, visit https://<public_dns> and login with username admin and password <password>. If you want to see the pods, service, or configmap running in EKS, run: mkdir ~/.kube terraform output kubeconfig > ~/.kube/config kubectl describe po kubectl describe svc kubectl describe configmap Don't stop here! Remember, you'll need to follow the steps to destroy your AWS resources, otherwise you'll be charged for running these AWS resources. Coincidentally you can use Terraform to limit this kind of rogue AWS spend, so don't be this guy: Delete this demo To destroy this demo in full, type: terraform destroy What just happened? Let's review what just happened. First, Terraform deployed a VPC and subnets, using the AWS provider. Then, Terraform deployed some more resources in AWS: an EKS cluster an EC2 instance to be the k8s worker node a BIG-IP VM Then, Terraform deployed some resources to EKS using the Kubernetes provider: a k8s deployment using the f5devcentral/helloworld image a k8s service to expose this deployment a k8s secret, a service account, and a cluster role binding, all to be used later in the helm deployment a k8s configMap resource, which is read by CIS and populates a pool in a partition with IP addresses of pods in a given service. Then, Terraform deployed F5 Container Ingress Services to k8s using the helm provider: a helm chart that deploys F5 CIS using helm the helm deployment was configured so that F5 CIS will point at the BIG-IP mgmt address, and use the secret generated earlier. After all this, the components are all in place. We have an app in k8s that is exposed to ingress traffic, which is routed via the BIG-IP and automatically updated. Our app is protected! Call to Action To summarize: Please use this demo to teach yourself and show your colleagues: how critical it is to secure traffic into your container environment how you can automate this process by using the tools you wish, and F5's extensive API's for automation. Please leave me a note with feedback if you are able to use this demo. I would like it to be useful for you. Let me know how I can make it more useful, or feel free to contribute to the repo yourself. Thanks!
MichaelOLeary
Jan 27, 2020 Place Technical Articles
1.8KViews
5likes
5Comments
Use AWS Lambda functions in a CFT
Problem statement: You have an existing VPC and you want to deploy Big-IP, and you want to add a default route to steer traffic to the ENI of the Big-IP after it's created. We can easily use F5’s supported templates to deploy Big-IP in AWS with a CloudFormation Template (CFT) into this VPC, but what if you want to add some automation after the Big-IP is deployed? For example, what if you wanted to add a default route to steer traffic to the ENI of the Big-IP that was just created? You might think of these options: You could create the RouteTable(s) as part of your CFT and associate it with the subnet(s) you deploy your Big-IP into. But what if the route already exists in your VPC? You can’t edit a route via a CFT - only create one. You could use a tool to automate your deployment, like Ansible or Jenkins. This is a fantastic demonstration of these tools. You could deploy Big-IP, then use a CFT output to get the ENI id of the Big-IP interface, get the route table id, and make your update via the replace-route API call . But, you might be required to make your entire deployment in 1 CFT, or maybe you’re looking to ensure your CFT doesn’t rely on other tasks after deployment? So, what if you cannot use a 3rd party tool? You could write your automation into a Lambda function, then create and execute that Lambda function as part of your CFT. This gives you the ability to run tasks in AWS as part of your CFT deployment. This article explains option #3. Modify the automation for your other use cases. Solution: The steps to follow when you need Lambda functionality as part of your CFT are: Create an IAM role in your CFT for your Lambda function to execute. Create a Lambda function Create a Custom Resource that is backed by the Lambda function. This will execute your Lambda function with parameters you can specify, and report back a Success or Failure to CloudFormation. I’ll explain how to do each of these and provide an example CFT at the end. Create an IAM role Include code such as below to create an IAM role that is appropriate for your Lambda function. Do not provide more permission than required to this role. Very public breaches have occurred as a result of mis-use of IAM roles, so by keeping your IAM roles limited in scope, you decrease your risk if it is mis-used. (In fact, I wrote some best practices to decrease this risk.) In our case, we’re allowing my Lambda function permissions over EC2 service. Create a Lambda function Here’s where you’ll need to define the data you’ll pass to your Lambda function (if any), what you want Lambda to do, and what it should return (if anything). Then write your function in a supported language. I’ve chosen Python. In this case, we’re updating a route in AWS, so we’re passing 3 things to the function: a CIDR range, an ENI id, and a RouteTable id. Upon creation, this Lambda function will update the specified route (CIDR) in the specified RouteTable, to point at the specified ENI. The Lambda function will also reference the IAM role we are creating. Create a Custom Resource. Custom Resources can be used to represent things we cannot define with AWS CFT types normally, like EC2 instances and VPC’s. A Lambda-backed Custom Resource is just one example of this. Our Custom Resource will pass an Event Type to the Lambda function (either Create, Update, or Delete), and then we’ll pass Resource Properties that will provide the function with the CIDR, ENI id, and RouteTable id required. In our case, the Lambda function returns the output of the API call upon Create, but returns nothing upon Delete. Still with me? String these together, and you have a Lambda function that is executed as part of your CFT. CloudFormation is smart enough to know that these depend upon values from other resources in the template, so they will be created after the EC2 instance is created. You could use a DependsOn statement to ensure this behavior, if you had other reasons to wait for something before Lambda execution. Demo Attached to this article is a ZIP file containing 2 CFT templates. First, deploy CFT #1, which is a file called "vpc.json". This will create a VPC that pre-exists your BigIP deployment. It is extremely simple: a single VPC, with a single subnet, which has an associated Route Table, with a default route of 0.0.0.0/0 pointing to an Internet Gateway. Take a note of the Outputs. There will be a RouteTableId and a SubnetId. You will need these Id's on the next step. Notice: the Route Table you created has a default route pointing toward an Internet Gateway. Then, deploy CFT #2, which is a file called "route-update.json". You will need to enter 2 parameters: the RouteTableId and SubnetId that were outputs from step #1. It will deploy an ENI (network interface) into the subnet, and then update the RouteTable that you have specified in your input parameters to point 0.0.0.0/0 at this ENI. Notice again: the Route Table's default route has been updated to point at the ENI, not the Internet Gateway. Obviously you'll want to modify these to point at the ENI of a Big-IP device, but I've kept these templates very simple to show you just the updating of a route via Lambda. You may even want to modify the code of the Lambda function to do other things - go for it! Enjoy. Use this article as a starting point, then think of cool use cases for Lambda functions. Prove them out and leave a comment to share your experience. And don’t forget - Your own role within the AWS account matters. You cannot create an IAM role that has permissions greater than you have yourself. (And if you’re deploying this with a service account using another IAM role, consider that) Credit goes to this article, which I used to learn about Lambda-backed Custom Resources and then modified for this use case. Demo Cloud Formation Template Files
MichaelOLeary
Aug 20, 2019 Place Technical Articles
1.4KViews
5likes
0Comments
Getting the Most out of Amazon EC2 Autoscale Groups with F5 BIG-IP
An Introduction to Amazon EC2 Auto Scaling One of the core tenets of cloud computing is elasticity, or the ability to scale cloud resources as needed to meet organizational or user needs. Amazon EC2 Auto Scaling is a feature within AWS focused on facilitating the provisioning and deprovisioning of elastic cloud computing resources to meet user demand. This article will cover how F5 BIG-IP can embrace elasticity and leverage the various features of Auto Scaling to manage steps of the F5 BIG-IP lifecycle, such as provisioning, licensing, configuration management, and upgrades. The Architecture In a typical F5 BIG-IP architect leveraging Amazon EC2 Auto Scaling, there are two key components. The first key component is the Auto Scaling group itself that contains one to many F5 BIG-IP VE instances as part of a managed group. As the name suggests, the power of an Auto Scaling group is its ability to introduce and remove F5 BIG-IP VE instances in the group based on a specified number of required instances or configured monitoring threshold reflecting user demand. The second key component is the AWS NLB or Network Load Balancer. While limited in its features compared to an F5 BIG-IP, the NLB plays a critical role in distributing traffic evenly across the F5 BIG-IP VEs within the Auto Scaling group. The NLB also tracks F5 BIG-IP instances added and removed from the Auto Scaling group and load balances only to active instances within the group. Brought together, an Auto Scaling group containing F5 BIG-IPs and NLB brings the benefits of elasticity and scaling of F5 BIG-IP functionality by provisioning and deprovisioning BIG-IP instances to match organizational capacity needs. Additionally, this architecture has the potential benefit of simplifying maintenance of F5 BIG-IPs by enabling engineers to remove instances from service to perform tasks such as upgrades. While this architecture brings many new benefits to scaling and maintenance, it also introduces new unique challenges: How do you ensure a consistent configuration is applied when a new F5 BIG-IP is provisioned? If you are using BYOL licensing with BIG-IQ, how do you ensure licenses are being applied during provisioning and revoked during termination? How do you ensure the F5 BIG-IP you just provisioned is tested and fully functioning before going into service? These are all challenges where Lifecycle Hooks become our secret weapon. Meet Lifecycle Hooks A powerful feature contained within Amazon EC2 Auto Scaling is Lifecycle Hooks. Lifecycle Hooks are event-driven triggers executed as instances are added or removed from an Auto Scaling group. Lifecycle Hooks enable the ability to put EC2 instances in a wait state at various steps of the instance's lifecycle and execute external actions such as an AWS Lambda function. The power of Lifecycle Hooks in the context of F5 BIG-IP is it enables the ability to execute external AWS Lambda-driven code to perform management tasks such as applying a list of AS3 declarations from an S3 bucket at the time of provisioning or revoking a BYOL license at the time of termination. This feature simplifies the management of F5 BIG-IP Auto Scaling groups by ensuring any newly provisioned F5 BIG-IPs have the needed configurations to match other instances in the group. Additionally, this feature provides the benefit of immediately revoking F5 BIG-IP BYOL licenses when an instance is being deprovisioned, ensuring an organization is maximizing its F5 spend. In addition to F5 BIG-IP lifecycle management tasks, Lifecycle Hooks can perform initial testing of F5 BIG-IP instances before being placed inside the Auto Scaling group to accept new user traffic. These tests can include use cases such as ensuring a group of VIPs is correctly processing traffic or a WAF policy is blocking a known attack. If the F5 BIG-IP fails the test, the Lifecycle Hook can terminate the failing instance and spin up a new one until the test criteria are met. This workflow automatically reduces the risk of a failing F5 BIG-IP instance receiving user traffic and ensuring a standard level of quality control for F5 BIG-IP instances entering the Auto Scaling group. The power of Lifecycle Hooks combined with the flexibility AWS Lambda provides for an almost near endless number of possibilities as part of the F5 BIG-IP provisioning and deprovisioning lifecycle. Lifecycle hooks empower cloud engineers and F5 administrators to programmatically trigger event-driven code to perform repetitive management and testing tasks common for scaling F5 BIG-IP deployments. An example of an AWS Lambda function used to perform the lifecycle tasks mentioned above can be found here. Rolling Updates with Instance Refresh In addition to Lifecycle Hooks, Amazon EC2 Auto Scaling provides a feature to simplify the ability to upgrade F5 BIG-IPs called Instance Refresh. Instance Refresh enables the ability to incrementally replace one version of an F5 BIG-IP's machine image with another version of the image in the form of a rolling deployment. Integrated with Lifecycle Hooks, Instance Refresh can upgrade, configure, and replace instances running an older version of BIG-IP with a new version. Additionally, Instance Refresh by default integrates with NLB to gradually drain connections of the old F5 BIG-IP images before removal, making the service impact of performing an upgrade little to nonexistent. The combined benefit of Instance Refresh with Lifecycle Hooks is an automated upgrade process with the potential of minimal user impact. Speedier Scaling with Warm Pools The final helpful feature of Amazon EC2 Auto Scaling when managing F5 BIG-IPs is warm pools. A warm pool is a newly added feature within Auto Scaling that allows for the creation of pre-initialized F5 BIG-IPs that live in a stopped state until the additional capacity is needed. The benefit of using a warm pool in an F5 BIG-IP Auto Scale group is that it enables the ability to perform many of the time-consuming tasks performed when initializing a virtual appliance ahead of when the BIG-IP is needed. These tasks include licensing, module provisioning, and other onboarding tasks. When tested, the use of a warm pool on average nearly halved the amount of time to add a new BIG-IP into service. The cost of maintaining a warm pool is also relatively small compared to paying for an overprovisioned Auto Scaling group, as AWS does not charge for compute for stopped instances and only charges for storage. When examining the architectural considerations for using Auto Scaling F5 BIG-IP instance, warm pools enable the ability to quickly add new F5 BIG-IP instances in scenarios where user demand may be unpredictable. Conclusion and Next Steps In this article, we have covered the many ways Amazon EC2 Auto Scaling can be leveraged to improve the management of F5 BIG-IP instances inside AWS. For further information and a full Terraform example of how the concepts detailed in this article can be implemented, check out this GitHub repository: https://github.com/tylerhatton/f5-warm-pool-demo
Tyler_Hatton
Jun 15, 2021 Place Technical Articles
1.4KViews
5likes
0Comments
F5 High Availability - Public Cloud Guidance
This article will provide information about BIG-IP and NGINX high availability (HA) topics that should be considered when leveraging the public cloud. There are differences between on-prem and public cloud such as cloud provider L2 networking. These differences lead to challenges in how you address HA, failover time, peer setup, scaling options, and application state. Topics Covered: Discuss and Define HA Importance of Application Behavior and Traffic Sizing HA Capabilities of BIG-IP and NGINX Various HA Deployment Options (Active/Active, Active/Standby, auto scale) Example Customer Scenario What is High Availability? High availability can mean many things to different people. Depending on the application and traffic requirements, HA requires dual data paths, redundant storage, redundant power, and compute. It means the ability to survive a failure, maintenance windows should be seamless to user, and the user experience should never suffer...ever! Reference: https://en.wikipedia.org/wiki/High_availability So what should HA provide? Synchronization of configuration data to peers (ex. configs objects) Synchronization of application session state (ex. persistence records) Enable traffic to fail over to a peer Locally, allow clusters of devices to act and appear as one unit Globally, disburse traffic via DNS and routing Importance of Application Behavior and Traffic Sizing Let's look at a common use case... "gaming app, lots of persistent connections, client needs to hit same backend throughout entire game session" Session State The requirement of session state is common across applications using methods like HTTP cookies, F5 iRule persistence, JSessionID, IP affinity, or hash. The session type used by the application can help you decide what migration path is right for you. Is this an app more fitting for a lift-n-shift approach...Rehost? Can the app be redesigned to take advantage of all native IaaS and PaaS technologies...Refactor? Reference: 6 R's of a Cloud Migration Application session state allows user to have a consistent and reliable experience Auto scaling L7 proxies (BIG-IP or NGINX) keep track of session state BIG-IP can only mirror session state to next device in cluster NGINX can mirror state to all devices in cluster (via zone sync) Traffic Sizing The cloud provider does a great job with things like scaling, but there are still cloud provider limits that affect sizing and machine instance types to keep in mind. BIG-IP and NGINX are considered network virtual appliances (NVA). They carry quota limits like other cloud objects. Google GCP VPC Resource Limits Azure VM Flow Limits AWS Instance Types Unfortunately, not all limits are documented. Key metrics for L7 proxies are typically SSL stats, throughput, connection type, and connection count. Collecting these application and traffic metrics can help identify the correct instance type. We have a list of the F5 supported BIG-IP VE platforms on F5 CloudDocs. F5 Products and HA Capabilities BIG-IP HA Capabilities BIG-IP supports the following HA cluster configurations: Active/Active - all devices processing traffic Active/Standby - one device processes traffic, others wait in standby Configuration sync to all devices in cluster L3/L4 connection sharing to next device in cluster (ex. avoids re-login) L5-L7 state sharing to next device in cluster (ex. IP persistence, SSL persistence, iRule UIE persistence) Reference: BIG-IP High Availability Docs NGINX HA Capabilities NGINX supports the following HA cluster configurations: Active/Active - all devices processing traffic Active/Standby - one device processes traffic, others wait in standby Configuration sync to all devices in cluster Mirroring connections at L3/L4 not available Mirroring session state to ALL devices in cluster using Zone Synchronization Module (NGINX Plus R15) Reference: NGINX High Availability Docs HA Methods for BIG-IP In the following sections, I will illustrate 3 common deployment configurations for BIG-IP in public cloud. HA for BIG-IP Design #1 - Active/Standby via API HA for BIG-IP Design #2 - A/A or A/S via LB HA for BIG-IP Design #3 - Regional Failover (multi region) HA for BIG-IP Design #1 - Active/Standby via API (multi AZ) This failover method uses API calls to communicate with the cloud provider and move objects (IP address, routes, etc) during failover events. The F5 Cloud Failover Extension (CFE) for BIG-IP is used to declaratively configure the HA settings. Cloud provider load balancer is NOT required Fail over time can be SLOW! Only one device actively used (other device sits idle) Failover uses API calls to move cloud objects, times vary (see CFE Performance and Sizing) Key Findings: Google API failover times depend on number of forwarding rules Azure API slow to disassociate/associate IPs to NICs (remapping) Azure API fast when updating routes (UDR, user defined routes) AWS reliable with API regarding IP moves and routes Recommendations: This design with multi AZ is more preferred than single AZ Recommend when "traditional" HA cluster required or Lift-n-Shift...Rehost For Azure (based on my testing)... Recommend using Azure UDR versus IP failover when possible Look at Failover via LB example instead for Azure If API method required, look at DNS solutions to provide further redundancy HA for BIG-IP Design #2 - A/A or A/S via LB (multi AZ) Cloud LB health checks the BIG-IP for up/down status Faster failover times (depends on cloud LB health timers) Cloud LB allows A/A or A/S Key difference: Increased network/compute redundancy Cloud load balancer required Recommendations: Use "failover via LB" if you require faster failover times For Google (based on my testing)... Recommend against "via LB" for IPSEC traffic (Google LB not supported) If load balancing IPSEC, then use "via API" or "via DNS" failover methods HA for BIG-IP Design #3 - Regional Failover via DNS (multi AZ, multi region) BIG-IP VE active/active in multiple regions Traffic disbursed to VEs by DNS/GSLB DNS/GSLB intelligent health checks for the VEs Key difference: Cloud LB is not required DNS logic required by clients Orchestration required to manage configs across each BIG-IP BIG-IP standalone devices (no DSC cluster limitations) Recommendations: Good for apps that handle DNS resolution well upon failover events Recommend when cloud LB cannot handle a particular protocol Recommend when customer is already using DNS to direct traffic Recommend for applications that have been refactored to handle session state outside of BIG-IP Recommend for customers with in-house skillset to orchestrate (Ansible, Terraform, etc) HA Methods for NGINX In the following sections, I will illustrate 2 common deployment configurations for NGINX in public cloud. HA for NGINX Design #1 - Active/Standby via API HA for NGINX Design #2 - Auto Scale Active/Active via LB HA for NGINX Design #1 - Active/Standby via API (multi AZ) NGINX Plus required Cloud provider load balancer is NOT required Only one device actively used (other device sits idle) Only available in AWS currently Recommendations: Recommend when "traditional" HA cluster required or Lift-n-Shift...Rehost Reference: Active-Passive HA for NGINX Plus on AWS HA for NGINX Design #2 - Auto Scale Active/Active via LB (multi AZ) NGINX Plus required Cloud LB health checks the NGINX Faster failover times Key difference: Increased network/compute redundancy Cloud load balancer required Recommendations: Recommended for apps fitting a migration type of Replatform or Refactor Reference: Active-Active HA for NGINX Plus on AWS, Active-Active HA for NGINX Plus on Google Pros & Cons: Public Cloud Scaling Options Review this handy table to understand the high level pros and cons of each deployment method. Example Customer Scenario #1 As a means to make this topic a little more real, here is a common customer scenario that shows you the decisions that go into moving an application to the public cloud. Sometimes it's as easy as a lift-n-shift, other times you might need to do a little more work. In general, public cloud is not on-prem and things might need some tweaking. Hopefully this example will give you some pointers and guidance on your next app migration to the cloud. Current Setup: Gaming applications F5 Hardware BIG-IP VIRPIONs on-prem Two data centers for HA redundancy iRule heavy configuration (TLS encryption/decryption, payload inspections) Session Persistence = iRule Universal Persistence (UIE), and other methods Biggest app 15K SSL TPS 15Gbps throughput 2 million concurrent connections 300K HTTP req/sec (L7 with TLS) Requirements for Successful Cloud Migration: Support current traffic numbers Support future target traffic growth Must run in multiple geographic regions Maintain session state Must retain all iRules in use Recommended Design for Cloud Phase #1: Migration Type: Hybrid model, on-prem + cloud, and some Rehost Platform: BIG-IP Retaining iRules means BIG-IP is required Licensing: High Performance BIG-IP Unlocks additional CPU cores past 8 (up to 24) extra traffic and SSL processing Instance type: check F5 supported BIG-IP VE platforms for accelerated networking (10Gb+) HA method: Active/Standby and multi-region with DNS iRule Universal persistence only mirrors to only next device, keep cluster size to 2 scale horizontally via additional HA clusters and DNS clients pinned to a region via DNS (on-prem or public cloud) inside region, local proxy cluster shares state This example comes up in customer conversations often. Based on customer requirements, in-house skillset, current operational model, and time frames there is one option that is better than the rest. A second design phase lends itself to more of a Replatform or Refactor migration type. In that case, more options can be leveraged to take advantage of cloud-native features. For example, changing the application persistence type from iRule UIE to cookie would allow BIG-IP to avoid keeping track of state. Why? With cookies, the client keeps track of that session state. Client receives a cookie, passes the cookie to L7 proxy on successive requests, proxy checks cookie value, sends to backend pool member. The requirement for L7 proxy to share session state is now removed. Example Customer Scenario #2 Here is another customer scenario. This time the application is a full suite of multimedia content. In contrast to the first scenario, this one will illustrate the benefits of rearchitecting various components allowing greater flexibility when leveraging the cloud. You still must factor in-house skill set, project time frames, and other important business (and application) requirements when deciding on the best migration type. Current Setup: Multimedia (Gaming, Movie, TV, Music) Platform BIG-IP VIPRIONs using vCMP on-prem Two data centers for HA redundancy iRule heavy (Security, Traffic Manipulation, Performance) Biggest App: oAuth + Cassandra for token storage (entitlements) Requirements for Success Cloud Migration: Support current traffic numbers Elastic auto scale for seasonal growth (ex. holidays) VPC peering with partners (must also bypass Web Application Firewall) Must support current or similar traffic manipulating in data plane Compatibility with existing tooling used by Business Recommended Design for Cloud Phase #1: Migration Type: Repurchase, migration BIG-IP to NGINX Plus Platform: NGINX iRules converted to JS or LUA Licensing: NGINX Plus Modules: GeoIP, LUA, JavaScript HA method: N+1 Autoscaling via Native LB Active Health Checks This is a great example of a Repurchase in which application characteristics can allow the various teams to explore alternative cloud migration approaches. In this scenario, it describes a phase one migration of converting BIG-IP devices to NGINX Plus devices. This example assumes the BIG-IP configurations can be somewhat easily converted to NGINX Plus, and it also assumes there is available skillset and project time allocated to properly rearchitect the application where needed. Summary OK! Brains are expanding...hopefully? We learned about high availability and what that means for applications and user experience. We touched on the importance of application behavior and traffic sizing. Then we explored the various F5 products, how they handle HA, and HA designs. These recommendations are based on my own lab testing and interactions with customers. Every scenario will carry its own requirements, and all options should be carefully considered when leveraging the public cloud. Finally, we looked at a customer scenario, discussed requirements, and design proposal. Fun! Resources Read the following articles for more guidance specific to the various cloud providers. Advanced Topologies and More on Highly Available Services Lightboard Lessons - BIG-IP Deployments in Azure Google and BIG-IP Failing Faster in the Cloud BIG-IP VE on Public Cloud High-Availability Load Balancing with NGINX Plus on Google Cloud Platform Using AWS Quick Starts to Deploy NGINX Plus NGINX on Azure
Jeff_Giroux_F5
May 04, 2020 Place Technical Articles
5.8KViews
5likes
2Comments
Using F5 Application Security and DoS Solutions with AWS Global Accelerator Part 1
How do you secure applications that are not a good fit for a CDN? In Part 1 of the series we cover how using F5 security solutions combined with AWS Global Accelerator can solve for performance and security concerns from L3 to L7. In the overall series we will explore WAF, BOT, DOS vectors applying cloud concepts of elasticity, declarative interfaces and as code practices.
Heath_Parrott
Nov 28, 2022 Place Technical Articles
2.5KViews
4likes
0Comments
How does F5 AS3 really work under the hood?
Put it simple, AS3 is a way to configure a BIG-IP once a BIG-IP is already provisioned. Full stop! We can also use AS3 to maintain that configuration over time. The way it works is we as a client send a JSON declaration via REST API and AS3 engine is supposed to work out how to configure BIG-IP the way it's been declared. AS3 internal components (parser and auditor) are explained further ahead. For non-DEV audience, AS3 is simply the name we give to an intelligent listener which acts as an interpreter that reads our declaration and translate it to proper commands to be issued on the BIG-IP. AS3 engine may or may not reside on BIG-IP (more on that on section entitled "3 ways of using AS3"). Yes, AS3 is declared in a structured JSON file and there are many examples on how to configure your regular virtual server, profiles, pools, etc, on clouddocs. AS3 uses common REST methods to communicate such as GET, POST and DELETE under the hood. For example, when we send our AS3 declaration to BIG-IP, we're sending an HTTP POST with the AS3 JSON file attached. AS3 is part of the Automation Toolchain which includes Declarative Onboarding and Telemetry Steaming. What AS3 is NOT Not a Mechanism for Role-Based Access Control (RBAC) AS3 doesn't support RBAC in a way that you can allow one user to configure certain objects and another user to configure other objects. AS3 has to use admin username/password with full access to BIG-IP resources. Not a GUI There's currently no native GUI built on top of AS3. Not an orchestrator AS3 won't and doesn't work out how to connect to different BIG-IPs and automatically figure out which box it needs to send which configuration to. All it does is receive a declaration, forwards it on and configure BIG-IP. Not for converting BIG-IP configuration We can't currently use AS3 to pull BIG-IP configuration and generate an AS3 configuration but I hope this functionality should be available in the future. Not for licensing or other onboarding functions We can't use AS3 for doing things like configuring VLANs or NTP servers. We use AS3 to configure BIG-IP once it's been already initially provisioned. For BIG-IP's initial set up, we use Declarative Onboarding. Why should we use AS3? To configure and maintain BIG-IPs across multiple versions using the same automated workflow. A simple JSON declaration becomes the source of Truth with AS3, where configuration edits should only be made to the declaration itself. If multiple BIG-IP boxes use the same configuration, a single AS3 declaration can be used to configure the entire fleet. It can also be easily integrated with external automation tools such as Ansible and Terraform. What I find really REALLY cool about AS3 AS3 targets and supports BIG-IP version 12.1 and higher. Say we have an AS3 declaration that was previously used to configure BIG-IP v12.1, right? Regardless if we're upgrading or moving config to another box, we can still use the same declaration to configure BIG-IP v15.1 box in the same way. I'm not joking! Back in the F5 Engineering Services days, I still remember when I used to grab support tickets where the issue was a configuration from an earlier version that was incompatible with newer version, e.g. a profile option was moved to a different profile, or new feature was added that requires some other option to be selected, etc. This is supposed to be a thing of the past with AS3. AS3 Key Features Transactional If you're a DBA, you've certainly heard of the term ACIDIC (atomicity, consistency, isolation, and durability). Let's say we send an AS3 declaration with 5 objects. AS3 will either apply the entire declaration or not apply at all. What that means is that if there's one single error, AS3 will never apply part of the configuration and leave BIG-IP in an unknown/inconsistent state. There's no in-between state. Either everything gets configured or nothing at all. It's either PASS or FAIL. Idempotent Say we send a declaration where there's nothing to configure on BIG-IP. In that case, AS3 will come back to client and inform that there's nothing for it to do. Essentially, AS3 won't remove BIG-IP's entire config and then re-apply it. It is smart enough to determine what work it needs to do and it will always do as little work as possible. Bounded AS3 enforces multi-tenancy by default, i.e. AS3 only creates objects in partitions (known as "tenants" in AS3 jargon) other than /Common. If we look at the AS3 declaration examples, we can see that a tenant (partition) is specified before we declare our config. AS3 does not create objects in the /Common partition. The exception to that is /Common/Shared when objects are supposed to be shared among multiple partitions/tenants. An example is when we create a pool member and a node gets automatically created on BIG-IP. Such node is created on /Common/Shared partition because that node might be a pool member in another partition, for example. Nevertheless, AS3 scope is and must always be bounded. The 3 ways of using AS3 Using AS3 through BIG-IP In this case here, we install AS3 RPM on each BIG-IP. BIG-IP is the box that has the "AS3 listener" waiting for us to send our AS3 JSON config file. All we need to do is to download AS3's binary and install it locally. There's a step by step guide for babies (with screenshots) here using BIG-IP's GUI. There's also a way to do it using curl if you're a geek like me here. Using AS3 through BIG-IQ In this case, we don't need to manually install AS3 RPM on each BIG-IP box like in previous step. BIG-IQ does it for us. BIG-IQ v6.1.0+ supports AS3 and we can directly send declarations through BIG-IQ. Apart from installing, BIG-IQ also upgrades AS3 in the target box (or boxes) if they're using an older version. Analytics and RBAC are also supported. Using AS3 through Docker container This is where AS3 is completely detached from BIG-IP. In the Docker container set up, AS3 engine resides within a Docker container decoupled from BIG-IP. Say your environment have Docker containers running, which is not something uncommon nowadays. We can install AS3 in a Docker container and use that container as the entry-point to send our AS3 declaration to BIG-IP. Yes, we as Cluent send our AS3 JSON file to where the Docker container is running and as long as the Docker container can reach our BIG-IP, then it will connect and configure it. Notice that in this case our AS3 engine runs outside of BIG-IP so we don't have to install AS3 on our BIG-IP fleet here. Docker container communicates with BIG-IP using iControl REST sending tmsh commands directly. AS3 Internal Components AS3 engine is comprised of an AS3 parser and AS3 auditor: AS3 Parser This is the front-end part of AS3 that communicates with the client and is responsible for client's declaration validation. AS3 Auditor After receiving validated declaration from AS3 parser, AS3 auditor's job is to compare desired validated declaration with BIG-IP's current configuration. It then determines what needs to be added/removed and forwards the changes to BIG-IP. AS3 in Action The way it works is Client sends a declaration to AS3 parser and config validation process kicks in. If declaration is not valid, it throws an error back to client along with an error code. If valid, declaration is forwarded on to AS3 auditor which then compares declaration with current BIG-IP's config and determines what needs to change. Only the configuration changes are supposed to be sent to BIG-IP, not the whole config. AS3 auditor then converts AS3 declaration to tmsh commands and send converted tmsh config to BIG-IP via iControl REST. BIG-IP then pushes the changes via tmsh commands and returns success/error to AS3 auditor. If changes are not successful, an error is returned all the way to the client. Otherwise, successful code is returned to client and changes are properly applied to BIG-IP. Here's the visual description of what I've just said: Debugging AS3 AS3 schema validation errors are returned in HTTP Response with a message pointing to the specific error: This includes typos in property names and so on. Logs on BIG-IP are stored on /var/log/restnoded/restnoded.log and by default only errors are logged. Log level can be changed through the Controls object in AS3 declaration itself. AS3 vs Declarative Onboarding This is usually source of confusion so I'd like to clarify that a bit. AS3 is the way we configure BIG-IP once it's already up and running. Declarative Onboarding (DO) is for the initial configuration of BIG-IP, i.e. setting up licence, users, DNS, NTP and even provisioning modules. Just like AS3, DO is API-only so no GUI on top of it. We can also have AS3 and DO in the same BIG-IP, so that's not a problem at all. Currently, there's no option to run it in a container like AS3 so as far as I'm concerned, it's only RPM based. Resources AS3 CloudDocs GitHub Repo Releases Declarative Onboarding (DO) CloudDocs GitHub Repo Releases I'd like to thank F5 Software Engineers Steven Chadwick and Garrett Dieckmann from AS3 team for providing a brilliant reference material.
Rodrigo_Albuque
Feb 07, 2020 Place Technical Articles
2.1KViews
4likes
2Comments
Using F5 Application Security and DOS Solutions with AWS Global Accelerator - Part 2 Building a Lab
Have you ever wanted to test AWS Global Accelerator with F5 Security solutions? Do you want to know how to protect applicaitons that cannot use a CDN but required an optimized experience? We will do that and more in this blog series. In Part 2 we will build our lab by deploying our VPC, BIG-IPS, Global Accelerator and an example application.
Heath_Parrott
Nov 28, 2022 Place Technical Articles
2.3KViews
3likes
0Comments

"}},"componentScriptGroups({\"componentId\":\"custom.widget.Beta_MetaNav\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"component({\"componentId\":\"custom.widget.Beta_Footer\"})":{"__typename":"Component","render({\"context\":{\"component\":{\"entities\":[],\"props\":{}},\"page\":{\"entities\":[],\"name\":\"TagPage\",\"props\":{},\"url\":\"https://community.f5.com/tag/AWS\"}}})":{"__typename":"ComponentRenderResult","html":"

Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information

"}},"componentScriptGroups({\"componentId\":\"custom.widget.Beta_Footer\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"component({\"componentId\":\"custom.widget.Tag_Manager_Helper\"})":{"__typename":"Component","render({\"context\":{\"component\":{\"entities\":[],\"props\":{}},\"page\":{\"entities\":[],\"name\":\"TagPage\",\"props\":{},\"url\":\"https://community.f5.com/tag/AWS\"}}})":{"__typename":"ComponentRenderResult","html":" "}},"componentScriptGroups({\"componentId\":\"custom.widget.Tag_Manager_Helper\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"component({\"componentId\":\"custom.widget.Consent_Blackbar\"})":{"__typename":"Component","render({\"context\":{\"component\":{\"entities\":[],\"props\":{}},\"page\":{\"entities\":[],\"name\":\"TagPage\",\"props\":{},\"url\":\"https://community.f5.com/tag/AWS\"}}})":{"__typename":"ComponentRenderResult","html":"

"}},"componentScriptGroups({\"componentId\":\"custom.widget.Consent_Blackbar\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"components/community/NavbarDropdownToggle\"]})":[{"__ref":"CachedAsset:text:en_US-components/community/NavbarDropdownToggle-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/common/OverflowNav\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/common/OverflowNav-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageView/MessageViewInline\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageView/MessageViewInline-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/common/Pager/PagerLoadMore\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/common/Pager/PagerLoadMore-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"components/customComponent/CustomComponent\"]})":[{"__ref":"CachedAsset:text:en_US-components/customComponent/CustomComponent-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"components/users/UserLink\"]})":[{"__ref":"CachedAsset:text:en_US-components/users/UserLink-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageSubject\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageSubject-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageBody\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageBody-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageTime\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageTime-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/nodes/NodeIcon\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/nodes/NodeIcon-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageUnreadCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageUnreadCount-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageViewCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageViewCount-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"components/kudos/KudosCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/kudos/KudosCount-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageRepliesCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageRepliesCount-1744046273800"}],"cachedText({\"lastModified\":\"1744046273800\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/users/UserAvatar\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/users/UserAvatar-1744046273800"}]},"CachedAsset:pages-1743758882900":{"__typename":"CachedAsset","id":"pages-1743758882900","value":[{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.GetInvolved.MvpProgram","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved/mvp-program","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"BlogViewAllPostsPage","type":"BLOG","urlPath":"/category/:categoryId/blog/:boardId/all-posts/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"CasePortalPage","type":"CASE_PORTAL","urlPath":"/caseportal","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"CreateGroupHubPage","type":"GROUP_HUB","urlPath":"/groups/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"CaseViewPage","type":"CASE_DETAILS","urlPath":"/case/:caseId/:caseNumber","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"InboxPage","type":"COMMUNITY","urlPath":"/inbox","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.GetInvolved.AdvocacyProgram","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved/advocacy-program","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.GetHelp.NonCustomer","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/non-customer","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HelpFAQPage","type":"COMMUNITY","urlPath":"/help","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.GetHelp.F5Customer","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/f5-customer","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"IdeaMessagePage","type":"IDEA_POST","urlPath":"/idea/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"IdeaViewAllIdeasPage","type":"IDEA","urlPath":"/category/:categoryId/ideas/:boardId/all-ideas/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"LoginPage","type":"USER","urlPath":"/signin","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"BlogPostPage","type":"BLOG","urlPath":"/category/:categoryId/blogs/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.GetInvolved","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.Learn","type":"COMMUNITY","urlPath":"/c/how-do-i/learn","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1739501996000,"localOverride":null,"page":{"id":"Test","type":"CUSTOM","urlPath":"/custom-test-2","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ThemeEditorPage","type":"COMMUNITY","urlPath":"/designer/themes","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"TkbViewAllArticlesPage","type":"TKB","urlPath":"/category/:categoryId/kb/:boardId/all-articles/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"OccasionEditPage","type":"EVENT","urlPath":"/event/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"OAuthAuthorizationAllowPage","type":"USER","urlPath":"/auth/authorize/allow","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"PageEditorPage","type":"COMMUNITY","urlPath":"/designer/pages","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"PostPage","type":"COMMUNITY","urlPath":"/category/:categoryId/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ForumBoardPage","type":"FORUM","urlPath":"/category/:categoryId/discussions/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"TkbBoardPage","type":"TKB","urlPath":"/category/:categoryId/kb/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"EventPostPage","type":"EVENT","urlPath":"/category/:categoryId/events/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"UserBadgesPage","type":"COMMUNITY","urlPath":"/users/:login/:userId/badges","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"GroupHubMembershipAction","type":"GROUP_HUB","urlPath":"/membership/join/:nodeId/:membershipType","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"MaintenancePage","type":"COMMUNITY","urlPath":"/maintenance","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"IdeaReplyPage","type":"IDEA_REPLY","urlPath":"/idea/:boardId/:messageSubject/:messageId/comments/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"UserSettingsPage","type":"USER","urlPath":"/mysettings/:userSettingsTab","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"GroupHubsPage","type":"GROUP_HUB","urlPath":"/groups","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ForumPostPage","type":"FORUM","urlPath":"/category/:categoryId/discussions/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"OccasionRsvpActionPage","type":"OCCASION","urlPath":"/event/:boardId/:messageSubject/:messageId/rsvp/:responseType","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"VerifyUserEmailPage","type":"USER","urlPath":"/verifyemail/:userId/:verifyEmailToken","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"AllOccasionsPage","type":"OCCASION","urlPath":"/category/:categoryId/events/:boardId/all-events/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"EventBoardPage","type":"EVENT","urlPath":"/category/:categoryId/events/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"TkbReplyPage","type":"TKB_REPLY","urlPath":"/kb/:boardId/:messageSubject/:messageId/comments/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"IdeaBoardPage","type":"IDEA","urlPath":"/category/:categoryId/ideas/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"CommunityGuideLinesPage","type":"COMMUNITY","urlPath":"/communityguidelines","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"CaseCreatePage","type":"SALESFORCE_CASE_CREATION","urlPath":"/caseportal/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"TkbEditPage","type":"TKB","urlPath":"/kb/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ForgotPasswordPage","type":"USER","urlPath":"/forgotpassword","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"IdeaEditPage","type":"IDEA","urlPath":"/idea/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"TagPage","type":"COMMUNITY","urlPath":"/tag/:tagName","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"BlogBoardPage","type":"BLOG","urlPath":"/category/:categoryId/blog/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"OccasionMessagePage","type":"OCCASION_TOPIC","urlPath":"/event/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ManageContentPage","type":"COMMUNITY","urlPath":"/managecontent","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ClosedMembershipNodeNonMembersPage","type":"GROUP_HUB","urlPath":"/closedgroup/:groupHubId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.GetHelp.Community","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/community","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"CommunityPage","type":"COMMUNITY","urlPath":"/","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.GetInvolved.ContributeCode","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved/contribute-code","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ForumMessagePage","type":"FORUM_TOPIC","urlPath":"/discussions/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"IdeaPostPage","type":"IDEA","urlPath":"/category/:categoryId/ideas/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"BlogMessagePage","type":"BLOG_ARTICLE","urlPath":"/blog/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"RegistrationPage","type":"USER","urlPath":"/register","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"EditGroupHubPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ForumEditPage","type":"FORUM","urlPath":"/discussions/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ResetPasswordPage","type":"USER","urlPath":"/resetpassword/:userId/:resetPasswordToken","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"TkbMessagePage","type":"TKB_ARTICLE","urlPath":"/kb/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.Learn.AboutIrules","type":"COMMUNITY","urlPath":"/c/how-do-i/learn/about-irules","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"BlogEditPage","type":"BLOG","urlPath":"/blog/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.GetHelp.F5Support","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/f5-support","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ManageUsersPage","type":"USER","urlPath":"/users/manage/:tab?/:manageUsersTab?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ForumReplyPage","type":"FORUM_REPLY","urlPath":"/discussions/:boardId/:messageSubject/:messageId/replies/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"PrivacyPolicyPage","type":"COMMUNITY","urlPath":"/privacypolicy","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"NotificationPage","type":"COMMUNITY","urlPath":"/notifications","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"UserPage","type":"USER","urlPath":"/users/:login/:userId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HealthCheckPage","type":"COMMUNITY","urlPath":"/health","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"OccasionReplyPage","type":"OCCASION_REPLY","urlPath":"/event/:boardId/:messageSubject/:messageId/comments/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ManageMembersPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId/manage/:tab?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"SearchResultsPage","type":"COMMUNITY","urlPath":"/search","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"BlogReplyPage","type":"BLOG_REPLY","urlPath":"/blog/:boardId/:messageSubject/:messageId/replies/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"GroupHubPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"TermsOfServicePage","type":"COMMUNITY","urlPath":"/termsofservice","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.GetHelp","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI.GetHelp.SecurityIncident","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/security-incident","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"CategoryPage","type":"CATEGORY","urlPath":"/category/:categoryId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"ForumViewAllTopicsPage","type":"FORUM","urlPath":"/category/:categoryId/discussions/:boardId/all-topics/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"TkbPostPage","type":"TKB","urlPath":"/category/:categoryId/kbs/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"GroupHubPostPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1743758882900,"localOverride":null,"page":{"id":"HowDoI","type":"COMMUNITY","urlPath":"/c/how-do-i","__typename":"PageDescriptor"},"__typename":"PageResource"}],"localOverride":false},"CachedAsset:text:en_US-components/context/AppContext/AppContextProvider-0":{"__typename":"CachedAsset","id":"text:en_US-components/context/AppContext/AppContextProvider-0","value":{"noCommunity":"Cannot find community","noUser":"Cannot find current user","noNode":"Cannot find node with id {nodeId}","noMessage":"Cannot find message with id {messageId}"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/Loading/LoadingDot-0":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/Loading/LoadingDot-0","value":{"title":"Loading..."},"localOverride":false},"User:user:-1":{"__typename":"User","id":"user:-1","uid":-1,"login":"Former Member","email":"","avatar":null,"rank":null,"kudosWeight":1,"registrationData":{"__typename":"RegistrationData","status":"ANONYMOUS","registrationTime":null,"confirmEmailStatus":false,"registrationAccessLevel":"VIEW","ssoRegistrationFields":[]},"ssoId":null,"profileSettings":{"__typename":"ProfileSettings","dateDisplayStyle":{"__typename":"InheritableStringSettingWithPossibleValues","key":"layout.friendly_dates_enabled","value":"false","localValue":"true","possibleValues":["true","false"]},"dateDisplayFormat":{"__typename":"InheritableStringSetting","key":"layout.format_pattern_date","value":"dd-MMM-yyyy","localValue":"MM-dd-yyyy"},"language":{"__typename":"InheritableStringSettingWithPossibleValues","key":"profile.language","value":"en-US","localValue":null,"possibleValues":["en-US"]}},"deleted":false},"Theme:customTheme1":{"__typename":"Theme","id":"customTheme1"},"CachedAsset:theme:customTheme1-1743758882444":{"__typename":"CachedAsset","id":"theme:customTheme1-1743758882444","value":{"id":"customTheme1","animation":{"fast":"150ms","normal":"250ms","slow":"500ms","slowest":"750ms","function":"cubic-bezier(0.07, 0.91, 0.51, 1)","__typename":"AnimationThemeSettings"},"avatar":{"borderRadius":"50%","collections":["custom"],"__typename":"AvatarThemeSettings"},"basics":{"browserIcon":{"imageAssetName":"JimmyPackets-512-1702592938213.png","imageLastModified":"1702592945815","__typename":"ThemeAsset"},"customerLogo":{"imageAssetName":"f5_logo_fix-1704824537976.svg","imageLastModified":"1704824540697","__typename":"ThemeAsset"},"maximumWidthOfPageContent":"1600px","oneColumnNarrowWidth":"800px","gridGutterWidthMd":"30px","gridGutterWidthXs":"10px","pageWidthStyle":"WIDTH_OF_PAGE_CONTENT","__typename":"BasicsThemeSettings"},"buttons":{"borderRadiusSm":"5px","borderRadius":"5px","borderRadiusLg":"5px","paddingY":"5px","paddingYLg":"7px","paddingYHero":"var(--lia-bs-btn-padding-y-lg)","paddingX":"12px","paddingXLg":"14px","paddingXHero":"42px","fontStyle":"NORMAL","fontWeight":"400","textTransform":"NONE","disabledOpacity":0.5,"primaryTextColor":"var(--lia-bs-white)","primaryTextHoverColor":"var(--lia-bs-white)","primaryTextActiveColor":"var(--lia-bs-white)","primaryBgColor":"var(--lia-bs-primary)","primaryBgHoverColor":"hsl(var(--lia-bs-primary-h), var(--lia-bs-primary-s), calc(var(--lia-bs-primary-l) * 0.85))","primaryBgActiveColor":"hsl(var(--lia-bs-primary-h), var(--lia-bs-primary-s), calc(var(--lia-bs-primary-l) * 0.7))","primaryBorder":"1px solid transparent","primaryBorderHover":"1px solid transparent","primaryBorderActive":"1px solid transparent","primaryBorderFocus":"1px solid var(--lia-bs-white)","primaryBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","secondaryTextColor":"var(--lia-bs-gray-900)","secondaryTextHoverColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.95))","secondaryTextActiveColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.9))","secondaryBgColor":"var(--lia-bs-gray-400)","secondaryBgHoverColor":"hsl(var(--lia-bs-gray-400-h), var(--lia-bs-gray-400-s), calc(var(--lia-bs-gray-400-l) * 0.96))","secondaryBgActiveColor":"hsl(var(--lia-bs-gray-400-h), var(--lia-bs-gray-400-s), calc(var(--lia-bs-gray-400-l) * 0.92))","secondaryBorder":"1px solid transparent","secondaryBorderHover":"1px solid transparent","secondaryBorderActive":"1px solid transparent","secondaryBorderFocus":"1px solid transparent","secondaryBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","tertiaryTextColor":"var(--lia-bs-gray-900)","tertiaryTextHoverColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.95))","tertiaryTextActiveColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.9))","tertiaryBgColor":"transparent","tertiaryBgHoverColor":"transparent","tertiaryBgActiveColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.04)","tertiaryBorder":"1px solid transparent","tertiaryBorderHover":"1px solid hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","tertiaryBorderActive":"1px solid transparent","tertiaryBorderFocus":"1px solid transparent","tertiaryBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","destructiveTextColor":"var(--lia-bs-danger)","destructiveTextHoverColor":"hsl(var(--lia-bs-danger-h), var(--lia-bs-danger-s), calc(var(--lia-bs-danger-l) * 0.95))","destructiveTextActiveColor":"hsl(var(--lia-bs-danger-h), var(--lia-bs-danger-s), calc(var(--lia-bs-danger-l) * 0.9))","destructiveBgColor":"var(--lia-bs-gray-300)","destructiveBgHoverColor":"hsl(var(--lia-bs-gray-300-h), var(--lia-bs-gray-300-s), calc(var(--lia-bs-gray-300-l) * 0.96))","destructiveBgActiveColor":"hsl(var(--lia-bs-gray-300-h), var(--lia-bs-gray-300-s), calc(var(--lia-bs-gray-300-l) * 0.92))","destructiveBorder":"1px solid transparent","destructiveBorderHover":"1px solid transparent","destructiveBorderActive":"1px solid transparent","destructiveBorderFocus":"1px solid transparent","destructiveBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","__typename":"ButtonsThemeSettings"},"border":{"color":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","mainContent":"NONE","sideContent":"NONE","radiusSm":"3px","radius":"5px","radiusLg":"9px","radius50":"100vw","__typename":"BorderThemeSettings"},"boxShadow":{"xs":"0 0 0 1px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.08), 0 3px 0 -1px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.08)","sm":"0 2px 4px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.06)","md":"0 5px 15px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.15)","lg":"0 10px 30px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.15)","__typename":"BoxShadowThemeSettings"},"cards":{"bgColor":"var(--lia-panel-bg-color)","borderRadius":"var(--lia-panel-border-radius)","boxShadow":"var(--lia-box-shadow-xs)","__typename":"CardsThemeSettings"},"chip":{"maxWidth":"300px","height":"30px","__typename":"ChipThemeSettings"},"coreTypes":{"defaultMessageLinkColor":"var(--lia-bs-primary)","defaultMessageLinkDecoration":"none","defaultMessageLinkFontStyle":"NORMAL","defaultMessageLinkFontWeight":"400","defaultMessageFontStyle":"NORMAL","defaultMessageFontWeight":"400","forumColor":"#0C5C8D","forumFontFamily":"var(--lia-bs-font-family-base)","forumFontWeight":"var(--lia-default-message-font-weight)","forumLineHeight":"var(--lia-bs-line-height-base)","forumFontStyle":"var(--lia-default-message-font-style)","forumMessageLinkColor":"var(--lia-default-message-link-color)","forumMessageLinkDecoration":"var(--lia-default-message-link-decoration)","forumMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","forumMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","forumSolvedColor":"#62C026","blogColor":"#730015","blogFontFamily":"var(--lia-bs-font-family-base)","blogFontWeight":"var(--lia-default-message-font-weight)","blogLineHeight":"1.75","blogFontStyle":"var(--lia-default-message-font-style)","blogMessageLinkColor":"var(--lia-default-message-link-color)","blogMessageLinkDecoration":"var(--lia-default-message-link-decoration)","blogMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","blogMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","tkbColor":"#C20025","tkbFontFamily":"var(--lia-bs-font-family-base)","tkbFontWeight":"var(--lia-default-message-font-weight)","tkbLineHeight":"1.75","tkbFontStyle":"var(--lia-default-message-font-style)","tkbMessageLinkColor":"var(--lia-default-message-link-color)","tkbMessageLinkDecoration":"var(--lia-default-message-link-decoration)","tkbMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","tkbMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","qandaColor":"#4099E2","qandaFontFamily":"var(--lia-bs-font-family-base)","qandaFontWeight":"var(--lia-default-message-font-weight)","qandaLineHeight":"var(--lia-bs-line-height-base)","qandaFontStyle":"var(--lia-default-message-link-font-style)","qandaMessageLinkColor":"var(--lia-default-message-link-color)","qandaMessageLinkDecoration":"var(--lia-default-message-link-decoration)","qandaMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","qandaMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","qandaSolvedColor":"#3FA023","ideaColor":"#F3704B","ideaFontFamily":"var(--lia-bs-font-family-base)","ideaFontWeight":"var(--lia-default-message-font-weight)","ideaLineHeight":"var(--lia-bs-line-height-base)","ideaFontStyle":"var(--lia-default-message-font-style)","ideaMessageLinkColor":"var(--lia-default-message-link-color)","ideaMessageLinkDecoration":"var(--lia-default-message-link-decoration)","ideaMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","ideaMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","contestColor":"#FCC845","contestFontFamily":"var(--lia-bs-font-family-base)","contestFontWeight":"var(--lia-default-message-font-weight)","contestLineHeight":"var(--lia-bs-line-height-base)","contestFontStyle":"var(--lia-default-message-link-font-style)","contestMessageLinkColor":"var(--lia-default-message-link-color)","contestMessageLinkDecoration":"var(--lia-default-message-link-decoration)","contestMessageLinkFontStyle":"ITALIC","contestMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","occasionColor":"#EE4B5B","occasionFontFamily":"var(--lia-bs-font-family-base)","occasionFontWeight":"var(--lia-default-message-font-weight)","occasionLineHeight":"var(--lia-bs-line-height-base)","occasionFontStyle":"var(--lia-default-message-font-style)","occasionMessageLinkColor":"var(--lia-default-message-link-color)","occasionMessageLinkDecoration":"var(--lia-default-message-link-decoration)","occasionMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","occasionMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","grouphubColor":"#491B62","categoryColor":"#949494","communityColor":"#FFFFFF","productColor":"#949494","__typename":"CoreTypesThemeSettings"},"colors":{"black":"#000000","white":"#FFFFFF","gray100":"#F7F7F7","gray200":"#F7F7F7","gray300":"#E8E8E8","gray400":"#D9D9D9","gray500":"#CCCCCC","gray600":"#949494","gray700":"#707070","gray800":"#545454","gray900":"#333333","dark":"#545454","light":"#F7F7F7","primary":"#0C5C8D","secondary":"#333333","bodyText":"#222222","bodyBg":"#F5F5F5","info":"#1D9CD3","success":"#62C026","warning":"#FFD651","danger":"#C20025","alertSystem":"#FF6600","textMuted":"#707070","highlight":"#FFFCAD","outline":"var(--lia-bs-primary)","custom":["#C20025","#081B85","#009639","#B3C6D7","#7CC0EB","#F29A36"],"__typename":"ColorsThemeSettings"},"divider":{"size":"3px","marginLeft":"4px","marginRight":"4px","borderRadius":"50%","bgColor":"var(--lia-bs-gray-600)","bgColorActive":"var(--lia-bs-gray-600)","__typename":"DividerThemeSettings"},"dropdown":{"fontSize":"var(--lia-bs-font-size-sm)","borderColor":"var(--lia-bs-border-color)","borderRadius":"var(--lia-bs-border-radius-sm)","dividerBg":"var(--lia-bs-gray-300)","itemPaddingY":"5px","itemPaddingX":"20px","headerColor":"var(--lia-bs-gray-700)","__typename":"DropdownThemeSettings"},"email":{"link":{"color":"#0069D4","hoverColor":"#0061c2","decoration":"none","hoverDecoration":"underline","__typename":"EmailLinkSettings"},"border":{"color":"#e4e4e4","__typename":"EmailBorderSettings"},"buttons":{"borderRadiusLg":"5px","paddingXLg":"16px","paddingYLg":"7px","fontWeight":"700","primaryTextColor":"#ffffff","primaryTextHoverColor":"#ffffff","primaryBgColor":"#0069D4","primaryBgHoverColor":"#005cb8","primaryBorder":"1px solid transparent","primaryBorderHover":"1px solid transparent","__typename":"EmailButtonsSettings"},"panel":{"borderRadius":"5px","borderColor":"#e4e4e4","__typename":"EmailPanelSettings"},"__typename":"EmailThemeSettings"},"emoji":{"skinToneDefault":"#ffcd43","skinToneLight":"#fae3c5","skinToneMediumLight":"#e2cfa5","skinToneMedium":"#daa478","skinToneMediumDark":"#a78058","skinToneDark":"#5e4d43","__typename":"EmojiThemeSettings"},"heading":{"color":"var(--lia-bs-body-color)","fontFamily":"Inter","fontStyle":"NORMAL","fontWeight":"600","h1FontSize":"30px","h2FontSize":"25px","h3FontSize":"20px","h4FontSize":"18px","h5FontSize":"16px","h6FontSize":"16px","lineHeight":"1.2","subHeaderFontSize":"11px","subHeaderFontWeight":"500","h1LetterSpacing":"normal","h2LetterSpacing":"normal","h3LetterSpacing":"normal","h4LetterSpacing":"normal","h5LetterSpacing":"normal","h6LetterSpacing":"normal","subHeaderLetterSpacing":"2px","h1FontWeight":"var(--lia-bs-headings-font-weight)","h2FontWeight":"var(--lia-bs-headings-font-weight)","h3FontWeight":"var(--lia-bs-headings-font-weight)","h4FontWeight":"var(--lia-bs-headings-font-weight)","h5FontWeight":"var(--lia-bs-headings-font-weight)","h6FontWeight":"var(--lia-bs-headings-font-weight)","__typename":"HeadingThemeSettings"},"icons":{"size10":"10px","size12":"12px","size14":"14px","size16":"16px","size20":"20px","size24":"24px","size30":"30px","size40":"40px","size50":"50px","size60":"60px","size80":"80px","size120":"120px","size160":"160px","__typename":"IconsThemeSettings"},"imagePreview":{"bgColor":"var(--lia-bs-gray-900)","titleColor":"var(--lia-bs-white)","controlColor":"var(--lia-bs-white)","controlBgColor":"var(--lia-bs-gray-800)","__typename":"ImagePreviewThemeSettings"},"input":{"borderColor":"var(--lia-bs-gray-600)","disabledColor":"var(--lia-bs-gray-600)","focusBorderColor":"var(--lia-bs-primary)","labelMarginBottom":"10px","btnFontSize":"var(--lia-bs-font-size-sm)","focusBoxShadow":"0 0 0 3px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","checkLabelMarginBottom":"2px","checkboxBorderRadius":"3px","borderRadiusSm":"var(--lia-bs-border-radius-sm)","borderRadius":"var(--lia-bs-border-radius)","borderRadiusLg":"var(--lia-bs-border-radius-lg)","formTextMarginTop":"4px","textAreaBorderRadius":"var(--lia-bs-border-radius)","activeFillColor":"var(--lia-bs-primary)","__typename":"InputThemeSettings"},"loading":{"dotDarkColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.2)","dotLightColor":"hsla(var(--lia-bs-white-h), var(--lia-bs-white-s), var(--lia-bs-white-l), 0.5)","barDarkColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.06)","barLightColor":"hsla(var(--lia-bs-white-h), var(--lia-bs-white-s), var(--lia-bs-white-l), 0.4)","__typename":"LoadingThemeSettings"},"link":{"color":"var(--lia-bs-primary)","hoverColor":"hsl(var(--lia-bs-primary-h), var(--lia-bs-primary-s), calc(var(--lia-bs-primary-l) - 10%))","decoration":"none","hoverDecoration":"underline","__typename":"LinkThemeSettings"},"listGroup":{"itemPaddingY":"15px","itemPaddingX":"15px","borderColor":"var(--lia-bs-gray-300)","__typename":"ListGroupThemeSettings"},"modal":{"contentTextColor":"var(--lia-bs-body-color)","contentBg":"var(--lia-bs-white)","backgroundBg":"var(--lia-bs-black)","smSize":"440px","mdSize":"760px","lgSize":"1080px","backdropOpacity":0.3,"contentBoxShadowXs":"var(--lia-bs-box-shadow-sm)","contentBoxShadow":"var(--lia-bs-box-shadow)","headerFontWeight":"700","__typename":"ModalThemeSettings"},"navbar":{"position":"FIXED","background":{"attachment":null,"clip":null,"color":"var(--lia-bs-white)","imageAssetName":null,"imageLastModified":"0","origin":null,"position":"CENTER_CENTER","repeat":"NO_REPEAT","size":"COVER","__typename":"BackgroundProps"},"backgroundOpacity":0.8,"paddingTop":"15px","paddingBottom":"15px","borderBottom":"1px solid var(--lia-bs-border-color)","boxShadow":"var(--lia-bs-box-shadow-sm)","brandMarginRight":"30px","brandMarginRightSm":"10px","brandLogoHeight":"30px","linkGap":"10px","linkJustifyContent":"flex-start","linkPaddingY":"5px","linkPaddingX":"10px","linkDropdownPaddingY":"9px","linkDropdownPaddingX":"var(--lia-nav-link-px)","linkColor":"var(--lia-bs-body-color)","linkHoverColor":"var(--lia-bs-primary)","linkFontSize":"var(--lia-bs-font-size-sm)","linkFontStyle":"NORMAL","linkFontWeight":"400","linkTextTransform":"NONE","linkLetterSpacing":"normal","linkBorderRadius":"var(--lia-bs-border-radius-sm)","linkBgColor":"transparent","linkBgHoverColor":"transparent","linkBorder":"none","linkBorderHover":"none","linkBoxShadow":"none","linkBoxShadowHover":"none","linkTextBorderBottom":"none","linkTextBorderBottomHover":"none","dropdownPaddingTop":"10px","dropdownPaddingBottom":"15px","dropdownPaddingX":"10px","dropdownMenuOffset":"2px","dropdownDividerMarginTop":"10px","dropdownDividerMarginBottom":"10px","dropdownBorderColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","controllerBgHoverColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.1)","controllerIconColor":"var(--lia-bs-body-color)","controllerIconHoverColor":"var(--lia-bs-body-color)","controllerTextColor":"var(--lia-nav-controller-icon-color)","controllerTextHoverColor":"var(--lia-nav-controller-icon-hover-color)","controllerHighlightColor":"hsla(30, 100%, 50%)","controllerHighlightTextColor":"var(--lia-yiq-light)","controllerBorderRadius":"var(--lia-border-radius-50)","hamburgerColor":"var(--lia-nav-controller-icon-color)","hamburgerHoverColor":"var(--lia-nav-controller-icon-color)","hamburgerBgColor":"transparent","hamburgerBgHoverColor":"transparent","hamburgerBorder":"none","hamburgerBorderHover":"none","collapseMenuMarginLeft":"20px","collapseMenuDividerBg":"var(--lia-nav-link-color)","collapseMenuDividerOpacity":0.16,"__typename":"NavbarThemeSettings"},"pager":{"textColor":"var(--lia-bs-link-color)","textFontWeight":"var(--lia-font-weight-md)","textFontSize":"var(--lia-bs-font-size-sm)","__typename":"PagerThemeSettings"},"panel":{"bgColor":"var(--lia-bs-white)","borderRadius":"var(--lia-bs-border-radius)","borderColor":"var(--lia-bs-border-color)","boxShadow":"none","__typename":"PanelThemeSettings"},"popover":{"arrowHeight":"8px","arrowWidth":"16px","maxWidth":"300px","minWidth":"100px","headerBg":"var(--lia-bs-white)","borderColor":"var(--lia-bs-border-color)","borderRadius":"var(--lia-bs-border-radius)","boxShadow":"0 0.5rem 1rem hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.15)","__typename":"PopoverThemeSettings"},"prism":{"color":"#000000","bgColor":"#f5f2f0","fontFamily":"var(--font-family-monospace)","fontSize":"var(--lia-bs-font-size-base)","fontWeightBold":"var(--lia-bs-font-weight-bold)","fontStyleItalic":"italic","tabSize":2,"highlightColor":"#b3d4fc","commentColor":"#62707e","punctuationColor":"#6f6f6f","namespaceOpacity":"0.7","propColor":"#990055","selectorColor":"#517a00","operatorColor":"#906736","operatorBgColor":"hsla(0, 0%, 100%, 0.5)","keywordColor":"#0076a9","functionColor":"#d3284b","variableColor":"#c14700","__typename":"PrismThemeSettings"},"rte":{"bgColor":"var(--lia-bs-white)","borderRadius":"var(--lia-panel-border-radius)","boxShadow":" var(--lia-panel-box-shadow)","customColor1":"#bfedd2","customColor2":"#fbeeb8","customColor3":"#f8cac6","customColor4":"#eccafa","customColor5":"#c2e0f4","customColor6":"#2dc26b","customColor7":"#f1c40f","customColor8":"#e03e2d","customColor9":"#b96ad9","customColor10":"#3598db","customColor11":"#169179","customColor12":"#e67e23","customColor13":"#ba372a","customColor14":"#843fa1","customColor15":"#236fa1","customColor16":"#ecf0f1","customColor17":"#ced4d9","customColor18":"#95a5a6","customColor19":"#7e8c8d","customColor20":"#34495e","customColor21":"#000000","customColor22":"#ffffff","defaultMessageHeaderMarginTop":"14px","defaultMessageHeaderMarginBottom":"10px","defaultMessageItemMarginTop":"0","defaultMessageItemMarginBottom":"10px","diffAddedColor":"hsla(170, 53%, 51%, 0.4)","diffChangedColor":"hsla(43, 97%, 63%, 0.4)","diffNoneColor":"hsla(0, 0%, 80%, 0.4)","diffRemovedColor":"hsla(9, 74%, 47%, 0.4)","specialMessageHeaderMarginTop":"14px","specialMessageHeaderMarginBottom":"10px","specialMessageItemMarginTop":"0","specialMessageItemMarginBottom":"10px","__typename":"RteThemeSettings"},"tags":{"bgColor":"var(--lia-bs-gray-200)","bgHoverColor":"var(--lia-bs-gray-400)","borderRadius":"var(--lia-bs-border-radius-sm)","color":"var(--lia-bs-body-color)","hoverColor":"var(--lia-bs-body-color)","fontWeight":"var(--lia-font-weight-md)","fontSize":"var(--lia-font-size-xxs)","textTransform":"UPPERCASE","letterSpacing":"0.5px","__typename":"TagsThemeSettings"},"toasts":{"borderRadius":"var(--lia-bs-border-radius)","paddingX":"12px","__typename":"ToastsThemeSettings"},"typography":{"fontFamilyBase":"Atkinson Hyperlegible","fontStyleBase":"NORMAL","fontWeightBase":"400","fontWeightLight":"300","fontWeightNormal":"400","fontWeightMd":"500","fontWeightBold":"700","letterSpacingSm":"normal","letterSpacingXs":"normal","lineHeightBase":"1.3","fontSizeBase":"15px","fontSizeXxs":"11px","fontSizeXs":"12px","fontSizeSm":"13px","fontSizeLg":"20px","fontSizeXl":"24px","smallFontSize":"14px","customFonts":[],"__typename":"TypographyThemeSettings"},"unstyledListItem":{"marginBottomSm":"5px","marginBottomMd":"10px","marginBottomLg":"15px","marginBottomXl":"20px","marginBottomXxl":"25px","__typename":"UnstyledListItemThemeSettings"},"yiq":{"light":"#ffffff","dark":"#000000","__typename":"YiqThemeSettings"},"colorLightness":{"primaryDark":0.36,"primaryLight":0.74,"primaryLighter":0.89,"primaryLightest":0.95,"infoDark":0.39,"infoLight":0.72,"infoLighter":0.85,"infoLightest":0.93,"successDark":0.24,"successLight":0.62,"successLighter":0.8,"successLightest":0.91,"warningDark":0.39,"warningLight":0.68,"warningLighter":0.84,"warningLightest":0.93,"dangerDark":0.41,"dangerLight":0.72,"dangerLighter":0.89,"dangerLightest":0.95,"__typename":"ColorLightnessThemeSettings"},"localOverride":false,"__typename":"Theme"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/Loading/LoadingDot-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/Loading/LoadingDot-1744046273800","value":{"title":"Loading..."},"localOverride":false},"CachedAsset:text:en_US-components/common/EmailVerification-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/common/EmailVerification-1744046273800","value":{"email.verification.title":"Email Verification Required","email.verification.message.update.email":"To participate in the community, you must first verify your email address. The verification email was sent to {email}. To change your email, visit My Settings.","email.verification.message.resend.email":"To participate in the community, you must first verify your email address. The verification email was sent to {email}. Resend email."},"localOverride":false},"CachedAsset:text:en_US-pages/tags/TagPage-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-pages/tags/TagPage-1744046273800","value":{"tagPageTitle":"Tag:\"{tagName}\" | {communityTitle}","tagPageForNodeTitle":"Tag:\"{tagName}\" in \"{title}\" | {communityTitle}","name":"Tags Page","tag":"Tag: {tagName}"},"localOverride":false},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bi0zNC0xM2k0MzE3N0Q2NjFBRDg5NDAy\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bi0zNC0xM2k0MzE3N0Q2NjFBRDg5NDAy","mimeType":"image/png"},"Category:category:Articles":{"__typename":"Category","id":"category:Articles","entityType":"CATEGORY","displayId":"Articles","nodeType":"category","depth":1,"title":"Articles","shortTitle":"Articles","parent":{"__ref":"Category:category:top"},"categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:top":{"__typename":"Category","id":"category:top","displayId":"top","nodeType":"category","depth":0,"title":"Top"},"Tkb:board:TechnicalArticles":{"__typename":"Tkb","id":"board:TechnicalArticles","entityType":"TKB","displayId":"TechnicalArticles","nodeType":"board","depth":2,"conversationStyle":"TKB","title":"Technical Articles","description":"F5 SMEs share good practice.","avatar":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bi0zNC0xM2k0MzE3N0Q2NjFBRDg5NDAy\"}"},"profileSettings":{"__typename":"ProfileSettings","language":null},"parent":{"__ref":"Category:category:Articles"},"ancestors":{"__typename":"CoreNodeConnection","edges":[{"__typename":"CoreNodeEdge","node":{"__ref":"Community:community:zihoc95639"}},{"__typename":"CoreNodeEdge","node":{"__ref":"Category:category:Articles"}}]},"userContext":{"__typename":"NodeUserContext","canAddAttachments":false,"canUpdateNode":false,"canPostMessages":false,"isSubscribed":false},"boardPolicies":{"__typename":"BoardPolicies","canPublishArticleOnCreate":{"__typename":"PolicyResult","failureReason":{"__typename":"FailureReason","message":"error.lithium.policies.forums.policy_can_publish_on_create_workflow_action.accessDenied","key":"error.lithium.policies.forums.policy_can_publish_on_create_workflow_action.accessDenied","args":[]}},"canReadNode":{"__typename":"PolicyResult","failureReason":null}},"tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"shortTitle":"Technical Articles","tagPolicies":{"__typename":"TagPolicies","canSubscribeTagOnNode":{"__typename":"PolicyResult","failureReason":{"__typename":"FailureReason","message":"error.lithium.policies.labels.action.corenode.subscribe_labels.allow.accessDenied","key":"error.lithium.policies.labels.action.corenode.subscribe_labels.allow.accessDenied","args":[]}},"canManageTagDashboard":{"__typename":"PolicyResult","failureReason":{"__typename":"FailureReason","message":"error.lithium.policies.labels.action.corenode.admin_labels.allow.accessDenied","key":"error.lithium.policies.labels.action.corenode.admin_labels.allow.accessDenied","args":[]}}}},"CachedAsset:quilt:f5.prod:pages/tags/TagPage:board:TechnicalArticles-1744046276811":{"__typename":"CachedAsset","id":"quilt:f5.prod:pages/tags/TagPage:board:TechnicalArticles-1744046276811","value":{"id":"TagPage","container":{"id":"Common","headerProps":{"removeComponents":["community.widget.bannerWidget"],"__typename":"QuiltContainerSectionProps"},"items":[{"id":"tag-header-widget","layout":"ONE_COLUMN","bgColor":"var(--lia-bs-white)","showBorder":"BOTTOM","sectionEditLevel":"LOCKED","columnMap":{"main":[{"id":"tags.widget.TagsHeaderWidget","__typename":"QuiltComponent"}],"__typename":"OneSectionColumns"},"__typename":"OneColumnQuiltSection"},{"id":"messages-list-for-tag-widget","layout":"ONE_COLUMN","columnMap":{"main":[{"id":"messages.widget.messageListForNodeByRecentActivityWidget","props":{"viewVariant":{"type":"inline","props":{"useUnreadCount":true,"useViewCount":true,"useAuthorLogin":true,"clampBodyLines":3,"useAvatar":true,"useBoardIcon":false,"useKudosCount":true,"usePreviewMedia":true,"useTags":false,"useNode":true,"useNodeLink":true,"useTextBody":true,"truncateBodyLength":-1,"useBody":true,"useRepliesCount":true,"useSolvedBadge":true,"timeStampType":"conversation.lastPostingActivityTime","useMessageTimeLink":true,"clampSubjectLines":2}},"panelType":"divider","useTitle":false,"hideIfEmpty":false,"pagerVariant":{"type":"loadMore"},"style":"list","showTabs":true,"tabItemMap":{"default":{"mostRecent":true,"mostRecentUserContent":false,"newest":false},"additional":{"mostKudoed":true,"mostViewed":true,"mostReplies":false,"noReplies":false,"noSolutions":false,"solutions":false}}},"__typename":"QuiltComponent"}],"__typename":"OneSectionColumns"},"__typename":"OneColumnQuiltSection"}],"__typename":"QuiltContainer"},"__typename":"Quilt"},"localOverride":false},"CachedAsset:quiltWrapper:f5.prod:Common:1743758793809":{"__typename":"CachedAsset","id":"quiltWrapper:f5.prod:Common:1743758793809","value":{"id":"Common","header":{"backgroundImageProps":{"assetName":"header.jpg","backgroundSize":"COVER","backgroundRepeat":"NO_REPEAT","backgroundPosition":"LEFT_CENTER","lastModified":"1702932449000","__typename":"BackgroundImageProps"},"backgroundColor":"transparent","items":[{"id":"custom.widget.Beta_MetaNav","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"},{"id":"community.widget.navbarWidget","props":{"showUserName":false,"showRegisterLink":true,"style":{"boxShadow":"var(--lia-bs-box-shadow-sm)","linkFontWeight":"700","controllerHighlightColor":"hsla(30, 100%, 50%)","dropdownDividerMarginBottom":"10px","hamburgerBorderHover":"none","linkFontSize":"15px","linkBoxShadowHover":"none","backgroundOpacity":0.4,"controllerBorderRadius":"var(--lia-border-radius-50)","hamburgerBgColor":"transparent","linkTextBorderBottom":"none","hamburgerColor":"var(--lia-nav-controller-icon-color)","brandLogoHeight":"48px","linkLetterSpacing":"normal","linkBgHoverColor":"transparent","collapseMenuDividerOpacity":0.16,"paddingBottom":"10px","dropdownPaddingBottom":"15px","dropdownMenuOffset":"2px","hamburgerBgHoverColor":"transparent","borderBottom":"0","hamburgerBorder":"none","dropdownPaddingX":"10px","brandMarginRightSm":"10px","linkBoxShadow":"none","linkJustifyContent":"center","linkColor":"var(--lia-bs-primary)","collapseMenuDividerBg":"var(--lia-nav-link-color)","dropdownPaddingTop":"10px","controllerHighlightTextColor":"var(--lia-yiq-dark)","background":{"imageAssetName":"","color":"var(--lia-bs-white)","size":"COVER","repeat":"NO_REPEAT","position":"CENTER_CENTER","imageLastModified":""},"linkBorderRadius":"var(--lia-bs-border-radius-sm)","linkHoverColor":"var(--lia-bs-primary)","position":"FIXED","linkBorder":"none","linkTextBorderBottomHover":"2px solid #0C5C8D","brandMarginRight":"30px","hamburgerHoverColor":"var(--lia-nav-controller-icon-color)","linkBorderHover":"none","collapseMenuMarginLeft":"20px","linkFontStyle":"NORMAL","linkPaddingX":"10px","paddingTop":"10px","linkPaddingY":"5px","linkTextTransform":"NONE","dropdownBorderColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","controllerBgHoverColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.1)","linkDropdownPaddingX":"var(--lia-nav-link-px)","linkBgColor":"transparent","linkDropdownPaddingY":"9px","controllerIconColor":"#0C5C8D","dropdownDividerMarginTop":"10px","linkGap":"10px","controllerIconHoverColor":"#0C5C8D"},"links":{"sideLinks":[],"mainLinks":[{"children":[{"linkType":"INTERNAL","id":"migrated-link-1","params":{"boardId":"TechnicalForum","categoryId":"Forums"},"routeName":"ForumBoardPage"},{"linkType":"INTERNAL","id":"migrated-link-2","params":{"boardId":"WaterCooler","categoryId":"Forums"},"routeName":"ForumBoardPage"}],"linkType":"INTERNAL","id":"migrated-link-0","params":{"categoryId":"Forums"},"routeName":"CategoryPage"},{"children":[{"linkType":"INTERNAL","id":"migrated-link-4","params":{"boardId":"codeshare","categoryId":"CrowdSRC"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"migrated-link-5","params":{"boardId":"communityarticles","categoryId":"CrowdSRC"},"routeName":"TkbBoardPage"}],"linkType":"INTERNAL","id":"migrated-link-3","params":{"categoryId":"CrowdSRC"},"routeName":"CategoryPage"},{"children":[{"linkType":"INTERNAL","id":"migrated-link-7","params":{"boardId":"TechnicalArticles","categoryId":"Articles"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"article-series","params":{"boardId":"article-series","categoryId":"Articles"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"security-insights","params":{"boardId":"security-insights","categoryId":"Articles"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"migrated-link-8","params":{"boardId":"DevCentralNews","categoryId":"Articles"},"routeName":"TkbBoardPage"}],"linkType":"INTERNAL","id":"migrated-link-6","params":{"categoryId":"Articles"},"routeName":"CategoryPage"},{"children":[{"linkType":"INTERNAL","id":"migrated-link-10","params":{"categoryId":"CommunityGroups"},"routeName":"CategoryPage"},{"linkType":"INTERNAL","id":"migrated-link-11","params":{"categoryId":"F5-Groups"},"routeName":"CategoryPage"}],"linkType":"INTERNAL","id":"migrated-link-9","params":{"categoryId":"GroupsCategory"},"routeName":"CategoryPage"},{"children":[],"linkType":"INTERNAL","id":"migrated-link-12","params":{"boardId":"Events","categoryId":"top"},"routeName":"EventBoardPage"},{"children":[],"linkType":"INTERNAL","id":"migrated-link-13","params":{"boardId":"Suggestions","categoryId":"top"},"routeName":"IdeaBoardPage"},{"children":[],"linkType":"EXTERNAL","id":"Common-external-link","url":"https://community.f5.com/c/how-do-i","target":"SELF"}]},"className":"QuiltComponent_lia-component-edit-mode__lQ9Z6","showSearchIcon":false},"__typename":"QuiltComponent"},{"id":"community.widget.bannerWidget","props":{"backgroundColor":"transparent","visualEffects":{"showBottomBorder":false},"backgroundImageProps":{"backgroundSize":"COVER","backgroundPosition":"CENTER_CENTER","backgroundRepeat":"NO_REPEAT"},"fontColor":"#222222"},"__typename":"QuiltComponent"},{"id":"community.widget.breadcrumbWidget","props":{"backgroundColor":"var(--lia-bs-primary)","linkHighlightColor":"#FFFFFF","visualEffects":{"showBottomBorder":false},"backgroundOpacity":60,"linkTextColor":"#FFFFFF"},"__typename":"QuiltComponent"}],"__typename":"QuiltWrapperSection"},"footer":{"backgroundImageProps":{"assetName":null,"backgroundSize":"COVER","backgroundRepeat":"NO_REPEAT","backgroundPosition":"CENTER_CENTER","lastModified":null,"__typename":"BackgroundImageProps"},"backgroundColor":"var(--lia-bs-body-color)","items":[{"id":"custom.widget.Beta_Footer","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"},{"id":"custom.widget.Tag_Manager_Helper","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"},{"id":"custom.widget.Consent_Blackbar","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"}],"__typename":"QuiltWrapperSection"},"__typename":"QuiltWrapper","localOverride":false},"localOverride":false},"CachedAsset:text:en_US-components/common/ActionFeedback-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/common/ActionFeedback-1744046273800","value":{"joinedGroupHub.title":"Welcome","joinedGroupHub.message":"You are now a member of this group and are subscribed to updates.","groupHubInviteNotFound.title":"Invitation Not Found","groupHubInviteNotFound.message":"Sorry, we could not find your invitation to the group. The owner may have canceled the invite.","groupHubNotFound.title":"Group Not Found","groupHubNotFound.message":"The grouphub you tried to join does not exist. It may have been deleted.","existingGroupHubMember.title":"Already Joined","existingGroupHubMember.message":"You are already a member of this group.","accountLocked.title":"Account Locked","accountLocked.message":"Your account has been locked due to multiple failed attempts. Try again in {lockoutTime} minutes.","editedGroupHub.title":"Changes Saved","editedGroupHub.message":"Your group has been updated.","leftGroupHub.title":"Goodbye","leftGroupHub.message":"You are no longer a member of this group and will not receive future updates.","deletedGroupHub.title":"Deleted","deletedGroupHub.message":"The group has been deleted.","groupHubCreated.title":"Group Created","groupHubCreated.message":"{groupHubName} is ready to use","accountClosed.title":"Account Closed","accountClosed.message":"The account has been closed and you will now be redirected to the homepage","resetTokenExpired.title":"Reset Password Link has Expired","resetTokenExpired.message":"Try resetting your password again","invalidUrl.title":"Invalid URL","invalidUrl.message":"The URL you're using is not recognized. Verify your URL and try again.","accountClosedForUser.title":"Account Closed","accountClosedForUser.message":"{userName}'s account is closed","inviteTokenInvalid.title":"Invitation Invalid","inviteTokenInvalid.message":"Your invitation to the community has been canceled or expired.","inviteTokenError.title":"Invitation Verification Failed","inviteTokenError.message":"The url you are utilizing is not recognized. Verify your URL and try again","pageNotFound.title":"Access Denied","pageNotFound.message":"You do not have access to this area of the community or it doesn't exist","eventAttending.title":"Responded as Attending","eventAttending.message":"You'll be notified when there's new activity and reminded as the event approaches","eventInterested.title":"Responded as Interested","eventInterested.message":"You'll be notified when there's new activity and reminded as the event approaches","eventNotFound.title":"Event Not Found","eventNotFound.message":"The event you tried to respond to does not exist.","redirectToRelatedPage.title":"Showing Related Content","redirectToRelatedPageForBaseUsers.title":"Showing Related Content","redirectToRelatedPageForBaseUsers.message":"The content you are trying to access is archived","redirectToRelatedPage.message":"The content you are trying to access is archived","relatedUrl.archivalLink.flyoutMessage":"The content you are trying to access is archived View Archived Content"},"localOverride":false},"CachedAsset:component:custom.widget.Beta_MetaNav-en-1743758898386":{"__typename":"CachedAsset","id":"component:custom.widget.Beta_MetaNav-en-1743758898386","value":{"component":{"id":"custom.widget.Beta_MetaNav","template":{"id":"Beta_MetaNav","markupLanguage":"HANDLEBARS","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"MetaNav menu at the top of every page.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Beta_MetaNav","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"CUSTOM","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"MetaNav menu at the top of every page.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:component:custom.widget.Beta_Footer-en-1743758898386":{"__typename":"CachedAsset","id":"component:custom.widget.Beta_Footer-en-1743758898386","value":{"component":{"id":"custom.widget.Beta_Footer","template":{"id":"Beta_Footer","markupLanguage":"HANDLEBARS","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"DevCentral´s custom footer.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Beta_Footer","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"CUSTOM","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"DevCentral´s custom footer.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:component:custom.widget.Tag_Manager_Helper-en-1743758898386":{"__typename":"CachedAsset","id":"component:custom.widget.Tag_Manager_Helper-en-1743758898386","value":{"component":{"id":"custom.widget.Tag_Manager_Helper","template":{"id":"Tag_Manager_Helper","markupLanguage":"HANDLEBARS","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"Helper widget to inject Tag Manager scripts into head element","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Tag_Manager_Helper","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"CUSTOM","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"Helper widget to inject Tag Manager scripts into head element","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:component:custom.widget.Consent_Blackbar-en-1743758898386":{"__typename":"CachedAsset","id":"component:custom.widget.Consent_Blackbar-en-1743758898386","value":{"component":{"id":"custom.widget.Consent_Blackbar","template":{"id":"Consent_Blackbar","markupLanguage":"HTML","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Consent_Blackbar","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"TEXTHTML","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:text:en_US-components/community/Breadcrumb-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/community/Breadcrumb-1744046273800","value":{"navLabel":"Breadcrumbs","dropdown":"Additional parent page navigation"},"localOverride":false},"CachedAsset:text:en_US-components/tags/TagsHeaderWidget-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/tags/TagsHeaderWidget-1744046273800","value":{"tag":"{tagName}","topicsCount":"{count} {count, plural, one {Topic} other {Topics}}"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageListForNodeByRecentActivityWidget-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageListForNodeByRecentActivityWidget-1744046273800","value":{"title@userScope:other":"Recent Content","title@userScope:self":"Contributions","title@board:FORUM@userScope:other":"Recent Discussions","title@board:BLOG@userScope:other":"Recent Blogs","emptyDescription":"No content to show","MessageListForNodeByRecentActivityWidgetEditor.nodeScope.label":"Scope","title@instance:1706288370055":"Content Feed","title@instance:1743095186784":"Most Recent Updates","title@instance:1704317906837":"Content Feed","title@instance:1743095018194":"Most Recent Updates","title@instance:1702668293472":"Community Feed","title@instance:1743095117047":"Most Recent Updates","title@instance:1704319314827":"Blog Feed","title@instance:1743095235555":"Most Recent Updates","title@instance:1704320290851":"My Contributions","title@instance:1703720491809":"Forum Feed","title@instance:1743095311723":"Most Recent Updates","title@instance:1703028709746":"Group Content Feed","title@instance:VTsglH":"Content Feed"},"localOverride":false},"Category:category:Forums":{"__typename":"Category","id":"category:Forums","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Forum:board:TechnicalForum":{"__typename":"Forum","id":"board:TechnicalForum","forumPolicies":{"__typename":"ForumPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Forum:board:WaterCooler":{"__typename":"Forum","id":"board:WaterCooler","forumPolicies":{"__typename":"ForumPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:DevCentralNews":{"__typename":"Tkb","id":"board:DevCentralNews","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:GroupsCategory":{"__typename":"Category","id":"category:GroupsCategory","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:F5-Groups":{"__typename":"Category","id":"category:F5-Groups","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:CommunityGroups":{"__typename":"Category","id":"category:CommunityGroups","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Occasion:board:Events":{"__typename":"Occasion","id":"board:Events","boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"occasionPolicies":{"__typename":"OccasionPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Idea:board:Suggestions":{"__typename":"Idea","id":"board:Suggestions","boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"ideaPolicies":{"__typename":"IdeaPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:CrowdSRC":{"__typename":"Category","id":"category:CrowdSRC","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:codeshare":{"__typename":"Tkb","id":"board:codeshare","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:communityarticles":{"__typename":"Tkb","id":"board:communityarticles","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:security-insights":{"__typename":"Tkb","id":"board:security-insights","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:article-series":{"__typename":"Tkb","id":"board:article-series","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Conversation:conversation:286051":{"__typename":"Conversation","id":"conversation:286051","topic":{"__typename":"TkbTopicMessage","uid":286051},"lastPostingActivityTime":"2022-07-29T10:07:23.043-07:00","solved":false},"User:user:354968":{"__typename":"User","uid":354968,"login":"RomanJ","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS0zNTQ5NjgtMTcwNTdpOTg0NDJCOUFBMzc2NTIxMw"},"id":"user:354968"},"TkbTopicMessage:message:286051":{"__typename":"TkbTopicMessage","subject":"Get Started with BIG-IP and BIG-IQ Virtual Edition (VE) Trial","conversation":{"__ref":"Conversation:conversation:286051"},"id":"message:286051","revisionNum":3,"uid":286051,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:354968"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":69532},"postTime":"2017-01-24T02:50:00.000-08:00","lastPublishTime":"2022-03-09T13:59:09.248-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Welcome to the BIG-IP and BIG-IQ trials page! This will be your jumping off point for setting up a trial version of BIG-IP VE or BIG-IQ VE in your environment. \n As you can see below, everything you’ll need is included and organized by operating environment — namely by public/private cloud or virtualization platform. \n To get started with your trial, use the following software and documentation which can be found in the links below. \n Upon requesting a trial, you should have received an email containing your license keys. Please bear in mind that it can take up to 30 minutes to receive your licenses. \n Don't have a trial license? Get one here. Or if you're ready to buy, contact us. \n Looking for other Resources like tools, compatibility matrix... \n BIG-IP VE and BIG-IQ VE \n When you sign up for the BIG-IP and BIG-IQ VE trial, you receive a set of license keys. Each key will correspond to a component listed below: \n \n BIG-IQ Centralized Management (CM) — Manages the lifecycle of BIG-IP instances including analytics, licenses, configurations, and auto-scaling policies \n BIG-IQ Data Collection Device (DCD) — Aggregates logs and analytics of traffic and BIG-IP instances to be used by BIG-IQ \n BIG-IP Local Traffic Manager (LTM), Access (APM), Advanced WAF (ASM), Network Firewall (AFM), DNS — Keep your apps up and running with BIG-IP application delivery controllers. BIG-IP Local Traffic Manager (LTM) and BIG-IP DNS handle your application traffic and secure your infrastructure. You’ll get built-in security, traffic management, and performance application services, whether your applications live in a private data center or in the cloud. \n \n Select the hypervisor or environment where you want to run VE: \n AWS \n \n CFT for single NIC deployment \n CFT for three NIC deployment \n BIG-IP VE images in the AWS Marketplace \n BIG-IQ VE images in the AWS Marketplace \n \n \n \n BIG-IP AWS documentation \n BIG-IP video: Single NIC deploy in AWS \n BIG-IQ AWS documentation \n Setting up and Configuring a BIG-IQ Centralized Management Solution \n BIG-IQ Centralized Management Trial Quick Start \n \n Azure \n \n Azure Resource Manager (ARM) template for single NIC deployment \n Azure ARM template for three NIC deployment \n BIG-IP VE images in the Azure Marketplace \n BIG-IQ VE images in the Azure Marketplace \n BIG-IQ Centralized Management Trial Quick Start \n \n \n \n BIG-IP VE Azure documentation \n Video: BIG-IP VE Single NIC deploy in Azure \n BIG-IQ VE Azure documentation \n Setting up and Configuring a BIG-IQ Centralized Management Solution \n \n VMware/KVM/Openstack \n \n Download BIG-IP VE image \n Download BIG-IQ VE image \n \n \n \n BIG-IP VE Setup \n BIG-IQ VE Setup \n Setting up and Configuring a BIG-IQ Centralized Management Solution \n \n Google Cloud \n \n Google Deployment Manager template for single NIC deployment \n Google Deployment Manager template for three NIC deployment \n BIG-IP VE images in Google Cloud \n \n \n \n Google Cloud Platform documentation \n Video: Single NIC deploy in Google \n \n Other Resources \n \n AskF5 \n Github community (f5devcentral, f5networks) \n Tools to automate your deployment \n BIG-IQ Onboarding Tool \n F5 Declarative Onboarding \n F5 Application Services 3 Extension \n \n Other Tools: \n \n F5 SDK (Python) \n F5 Application Services Templates (FAST) \n F5 Cloud Failover \n F5 Telemetry Streaming \n \n Find out which hypervisor versions are supported with each release of VE. \n \n BIG-IP Compatibility Matrix \n BIG-IQ Compatibility Matrix \n \n \n Do you have any comments or questions? Ask here ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"3628","kudosSumWeight":8,"repliesCount":24,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:290821":{"__typename":"Conversation","id":"conversation:290821","topic":{"__typename":"TkbTopicMessage","uid":290821},"lastPostingActivityTime":"2022-09-02T06:54:34.191-07:00","solved":false},"User:user:321467":{"__typename":"User","uid":321467,"login":"Yossi_Rosenboi1","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/m_assets/avatars/default/avatar-4.svg?time=0"},"id":"user:321467"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtMTA3ODZpRDhFNjYxNUUxNjBBRTE2Qg?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtMTA3ODZpRDhFNjYxNUUxNjBBRTE2Qg?revision=1","title":"0151T0000040jAWQAY.png","associationType":"BODY","width":3201,"height":1536,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtNDM5OWlFNjM0QTc0NUQ1MTc2N0JB?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtNDM5OWlFNjM0QTc0NUQ1MTc2N0JB?revision=1","title":"0151T0000040jAgQAI.png","associationType":"BODY","width":2662,"height":1423,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtMTA3NDFpRTY5ODNFMzczNDM5QTFCQQ?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtMTA3NDFpRTY5ODNFMzczNDM5QTFCQQ?revision=1","title":"0151T0000040jAiQAI.png","associationType":"BODY","width":2550,"height":2195,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtMTM1NTVpRDVGRjlFQ0NCNTk4M0JGQQ?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtMTM1NTVpRDVGRjlFQ0NCNTk4M0JGQQ?revision=1","title":"0151T0000040jAqQAI.png","associationType":"BODY","width":2570,"height":3352,"altText":null},"TkbTopicMessage:message:290821":{"__typename":"TkbTopicMessage","subject":"BIG-IP integration with AWS Gateway Load Balancer - Overview","conversation":{"__ref":"Conversation:conversation:290821"},"id":"message:290821","revisionNum":1,"uid":290821,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:321467"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":10779},"postTime":"2021-07-29T08:03:22.000-07:00","lastPublishTime":"2021-07-29T08:03:22.000-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Introduction With the release of TMOS version 16.1, BIG-IP now supports AWS Gateway Load Balancer (GWLB). With this integration we are making it much easier and simpler to insert BIG-IP security services into an AWS environment while maintaining high availability and supporting elastic scalability of the BIG-IP's. When to use GWLB? F5 BIG-IP delivers a wide range of application and security services. Depending on the service and other requirements the BIG-IP's are typically deployed in one of two modes: Network mode or Proxy mode. Important: GWLB is only applicable today with Network deployment mode. First, you should identify which deployment mode is relevant for you: Network (GWLB Supported) Common use cases: Network firewall, DDoS protection, Transparent WAF Flow transparency is maintained (no source or destination NAT) Directing traffic to the BIG-IP's is done using routing by the network, making sure traffic goes back to the same BIG-IP in order to maintain traffic symmetry is also based on routing Proxy (Not GWLB Supported) Providing ingress services to the application (WAF, LB, L7 DDoS, Bot protection), services are applied to an application specific virtual server on the BIG-IP The BIG-IP SNAT (source NAT) manages the traffic to ensure that the return traffic arrives at the same BIG-IP thus maintaining traffic symmetry Directing user's traffic to the BIG-IP's is usually done using DNS. A FQDN will map to a specific virtual server on the BIG-IP. Important: GWLB does not support proxy devices in the inspection zone. Traffic flow must remain unchanged by the inspection device, for more details see: https://aws.amazon.com/blogs/networking-and-content-delivery/integrate-your-custom-logic-or-appliance-with-aws-gateway-load-balancer/ ). Existing challenges of BIG-IP Network deployment without GWLB Let's examine two scenarios in which we use the BIG-IP for inspecting network traffic: Ingress/Egress protection: In this scenario, we want to inspect all traffic coming into and going out of the AWS network. The security services that are most relevant for this scenario are: Firewall, DDOS protection, WAF and IPS. East west (Inter VPC / networks) protection: In this scenario we want to inspect all traffic between VPC's and between on-prem to VPC's. The most common security services used are Firewall and IPS. In the two scenarios mentioned above, we need to ensure the relevant flows are routed to the BIG-IP. We will also need to verify that traffic is symmetric – meaning any flow that was sent to the BIG-IP must also return from the same BIG-IP. Today, without GWLB, our method of getting traffic to the BIG-IP is to manipulate the routing tables accordingly. AWS's routing tables accepts an ENI (Elastic Network Interface, a Network interface of an EC2 instance running a BIG-IP) as the 'gateway' for a specific route. Since routing tables only accepts a single ENI, we can only send traffic to a single BIG-IP instance - which of course creates a single point of failure. We can further improve this design by leveraging F5's Cloud Failover Extension (CFE) which allows us to create an active/standby pair. The CFE will automatically manipulate the route tables to always point traffic at the ENI of the active device. You can read more on this design here: https://clouddocs.f5.com/products/extensions/f5-cloud-failover/latest/userguide/aws.html?highlight=route In summary, the network deployment of the BIG-IP in AWS has the following challenges: Limited scale - Throughput, concurrent connections etc. as only a single device processes the traffic Unoptimized compute – Passive device sits idle Mixed admin domains – BIG-IP's are deployed in the same VPC as the workloads it is protecting, routing table changes are controlled by F5's CFE which is not always wanted or possible How GWLB works with BIG-IP To understand how AWS GWLB works, let's start by taking a closer look at the GWLB. We can break down the GWLB functionality into two main elements: On the frontend: GWLB presents itself as a next-hop L3 Gateway to manage traffic transparently. GWLB uses a new component: GWLB endpoint. This endpoint acts as an ENI (Elastic Network Interface) of the GWLB. The only way of sending traffic to GWLB is through this endpoint, therefore it is deployed in a VPC that consumes the security services (i.e. the Consumer VPC). Admin domain separation: The GWLB and BIG-IP fleet are deployed in their own VPC (Security VPC). One GWLB can receive and inspect traffic from many VPC's (find more detail on design patterns in the 'Deployments' section) On the backend: GWLB is like a L4 Load Balancer, very similar to NLB (Network Load Balancer) Provides traffic distribution across a fleet of BIG-IP instances. Routes flows and assigns them to specific BIG-IP for stateful inspection. Performs health-checks of the BIG-IP's, and routes traffic to healthy BIG-IP's only. Traffic is sent over a L3 tunnel using the GENEVE protocol (Requires BIG-IP version 16.1 and above) BIG-IP integration details: Requirements: BIG-IP version 16.1 and above BIG-IP traffic flow: The BIG-IP must be deployed in the same VPC as the GWLB. BIG-IP receives traffic from GWLB over a GENEVE tunnel that uses the BIG-IPs private ip address. Next, we create a virtual server that is enabled on the new tunnel. The new tunnel gets the traffic from GWLB, decapsulates it and then it gets processed by the inspection virtual server. After the virtual server processes the packet and applies the defined security profiles, it needs to forward the packet back to the tunnel. The way to 'Force' traffic back into the tunnel is to create a fake node that 'lives' inside the tunnel and use it as the target pool of the virtual server. Once the tunnel interface receives the packets from the virtual server, it encapsulates them with GENEVE and forwards it back to GWLB. The following diagram describes the traffic flow within a specific BIG-IP device: Considerations and known issues: Traffic flows inside the 'inspection zone' must remain unchanged. i.e, no change in the packet's 5 tuple is allowed. All virtual servers are supported as long as the 5 tuple of the packet is maintained. That might require changing some configurations, for example Disable the default 'address translation' feature of a 'standard' virtual server. Set the 'source port' setting to 'Preserve strict' Payload manipulation is supported as long as the packet's 5 tuple is maintained Some examples: HTTP rewrites AWAF blocking responses – AWAF responds with a 'blocking page' High Availability When a BIG-IP instance fails in the target group, GWLB continue to send existing flows to the failed instance. Only new connections will be directed to a new instance. Deploy BIG-IP instances across availability zones according to the desired AZ availability requirements. The Default behavior for GWLB is to keep traffic in the same AZ, meaning traffic that was received on an endpoint in AZ1 will only forward traffic to instances in AZ1. That behavior is controlled by the 'CrossZoneLoadBalancing' flag https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-crosszone-lb.html If you do change the 'CrossZoneLoadBalancing' flag, keep in mind that GWLB will distribute traffic across AZ's even when all instances are healthy and will incur cross-AZ traffic costs. Flow timeout GWLB has its own protocol timeouts (350 seconds for TCP, 120 for UDP). the timeout values on the BIG-IP must be smaller then the ones on GWLB - BIG-IP uses 300 seconds for TCP and 60 for UDP by default. With the GWLB integration you can now create an elastic group of BIG-IP's that will be exposed to the rest of the AWS network using AWS native networking constructs. GWLB is responsible for distributing the traffic evenly between the group while maintaining flow affinity so that each flow will always be routed to the same BIG-IP in the group and thus solving the symmetric flows without requiring any SNAT. The security inspection zone can be deployed in its own VPC, allowing better administrative separation. Exposing the inspection service is done using VPC endpoints, those endpoints are tied to the GWLB and can be used as the target of different routing tables (TGW, Ingress, subnets). Summary The BIG-IP and GWLB integration enables the industry leading BIG-IP security services with the following benefits: Elastic scalability: Scale your deployment based on your actual usage. Horizontally scale your BIG-IP's. Simplified connectivity: Leverage AWS native networking constructs to 'insert' BIG-IP security services in different traffic flows (North-South, East-West) Cost effectiveness: Consolidate BIG-IP's deployments and size the deployment based on actual usage Next steps: Check out the next articles in this series - Ingress/Egress VPC inspection with BIG-IP and GWLB deployment pattern Ingress/Egress and inter VPC inspection with BIG-IP and GWLB deployment pattern Test the integration yourself - Check out our self-service lab that you can deploy in your own AWS account (Fully automated deployment using Terraform): https://github.com/f5devcentral/f5-digital-customer-engagement-center/tree/main/solutions/security/ingress-egress-fw https://github.com/f5devcentral/f5-digital-customer-engagement-center/tree/main/solutions/security/ingress-egress-inter-vpc-fw-gwlb ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"10005","kudosSumWeight":6,"repliesCount":2,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtMTA3ODZpRDhFNjYxNUUxNjBBRTE2Qg?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtNDM5OWlFNjM0QTc0NUQ1MTc2N0JB?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtMTA3NDFpRTY5ODNFMzczNDM5QTFCQQ?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTA4MjEtMTM1NTVpRDVGRjlFQ0NCNTk4M0JGQQ?revision=1\"}"}}],"totalCount":4,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:291221":{"__typename":"Conversation","id":"conversation:291221","topic":{"__typename":"TkbTopicMessage","uid":291221},"lastPostingActivityTime":"2023-09-07T08:24:55.936-07:00","solved":false},"User:user:242856":{"__typename":"User","uid":242856,"login":"MichaelOLeary","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS0yNDI4NTYtMjA2NzVpMjAwQzU1OUQzMEFFMDM2RQ"},"id":"user:242856"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTEyMjEtNjk3M2k0NDMwQUU4RjVBNDgyM0Ez?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTEyMjEtNjk3M2k0NDMwQUU4RjVBNDgyM0Ez?revision=1","title":"0151T000003d7JkQAI.JPG","associationType":"BODY","width":1226,"height":873,"altText":null},"TkbTopicMessage:message:291221":{"__typename":"TkbTopicMessage","subject":"Deploy BIG-IP in AWS with HA across AZ’s - without using EIP’s","conversation":{"__ref":"Conversation:conversation:291221"},"id":"message:291221","revisionNum":1,"uid":291221,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:242856"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":8425},"postTime":"2019-02-21T05:00:00.000-08:00","lastPublishTime":"2019-02-21T05:00:00.000-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Background: \n\n The CloudFormation templates that are provided and supported by F5 are an excellent resource for customers to deploy BIG-IP VE in AWS. Along with these templates, documentation guiding your F5 deployment in AWS is an excellent resource. \n\n And of course, DevCentral articles are helpful. I recommend reading about HA topologies in AWS to start. I hope my article today can shed more light on an architecture that will suit a specific set of requirements: No Elastic IP's (EIP’s), High Availability (HA) across AZ’s, and multiple VPC’s. \n\n Requirements behind this architecture choice: \n\n I recently had a requirement to deploy BIG-IP appliances in AWS across AZ’s. I had read the official deployment guide, but I wasn’t clear on how to achieve failover without EIP’s. I was given 3 requirements: \n\n HA across AZ’s. In this architecture, we required a pair of BIG-IP devices in Active/Standby, where each device was in a different AZ. I needed to be able to fail over between devices. No EIP’s. This requirement existed because a 3 rd party firewall was already exposed to the Internet with a public IP address. That firewall would forward inbound requests to the BIG-IP VE in AWS, which in turn proxied traffic to a pair of web servers. Therefore, there was no reason to associate an EIP (a public IP address) with the BIG-IP interface. In my demo below I have not exposed a public website through a 3 rd party firewall, but to do so is a simple addition to this demo environment. Multiple VPC’s. This architecture had to allow for multiple VPC’s in AWS. There was already a “Security VPC” which contained firewalls, BIG-IP devices, and other devices, and I had to be able to use these devices for protecting applications that were across 1 or more disparate VPC’s. \n\n Meeting the requirements: \n\n HA across AZ’s \n\n This is the easiest of the requirements to meet because F5 has already provided templates to deploy these in AWS. I personally used a 2-nic device, with a BYOL license, deployed to an existing VPC, so that meant my template was this one. After this deployment is complete, you should have a pair of devices that will sync their configuration. \n\n At time of failover\n The supported F5 templates will deploy with the Advanced HA iApp. It is important that you configure this iApp after you have completed your AWS deployments. The iApp uses IAM permissions deployed with the template to make API calls to AWS at the time of failover. The API calls will update the route tables that you specify within the iApp wizard. Because this iApp is installed on both devices, either device can update the route in your route tables to point to its own interface. Update as of Dec 2019 This article was first written Feb 2019, and in Dec 2019 F5 released the Cloud Failover Extension (CFE), which is a cloud-agnostic, declarative way to configure failover in multiple public clouds. You can use the CFE instead of the Advanced HA iApp to achieve high availability between BIG-IP devices in cloud. Update as of Apr 2020 Your API calls will typically be sent to the public Internet endpoints for AWS EC2 API calls. Optionally, you can use AWS VPC endpoints to keep your API calls out to AWS EC2 from traversing the public Internet. My colleague Arnulfo Hernandez has written an article explaining how to do this. \n\n No EIP’s \n\n Configure an “alien IP range” \n\n I’m recycling another DevCentral solution here. You will need to choose an IP range for your VIP network that does not fall within the CIDR that is assigned to your VPC. Let’s call it an “alien range” because it “doesn’t belong” in your VPC and you couldn’t assign IP addresses from this range to your AWS ENI’s. Despite that, now create a route table within AWS that points this “alien range” to your Active BIG-IP device’s ENI (if you’re using a 2+ nic device, point it to the correct data plane NIC, not the Mgmt. interface). Don’t forget to associate the route table with specific subnets, per your design. Alternatively, you could add this route to the default VPC route table. \n\n Create a VIP on your active device \n\n Now create a VIP on your active device and configure the IP address as an IP within your alien range. Ensure the config replicates to your standby device. Ensure that source/destination checking is disabled on the ENI’s that your AWS routes are pointing to (on both Standby and Active devices). You should now have a VIP that you can target from other hosts in your VPC, provided that the route you created above is applied to the traffic destined to the VIP. \n\n Multiple VPC’s \n\n For extra credit, we’ll set up a Transit Gateway. This will allow other VPCs to route traffic to this “alien range” also, provided that the appropriate routes exist in the remote VPC’s, and also are applied to the appropriate Transit Gateway Route Table. Again, I’m recycling ideas that have already been laid out in other DevCentral posts. \n\n I won’t re-hash how to set up a transit gateway in AWS, because you can follow the linked post above. Sufficed to say, this is what you will need to set up if you want to route between multiple VPC’s using a transit gateway: \n\n 2 or more VPC’s A transit gateway in AWS Multiple transit gateway attachments that attach the transit gateway and each VPC you would like to route between. You will need one attachment per VPC. A transit gateway route table that is associated with each attachment. \n\n \n\n I will point out that you need to add a route for your “alien range” in your transit gateway route table, and in your remote VPC’s. That way, hosts in your remote VPC’s will forward traffic destined to your alien range (VIP network) to the transit gateway, and the transit gateway will forward it to your VPC, and the route you created in Step A will forward that traffic to your active BIG-IP device. \n\n Completed design: \n\n After the above configuration, you should have an environment that looks like the diagram below: \n\n \n\n Tips \n\n Internet access for deployments: When you deploy your BIG-IP devices, they will need Internet access to pull down some resources, including the iApp. So if you are deploying devices into your existing VPC, make sure you have a reachable Internet Gateway in AWS so that the devices have Internet access through both their management interface, and their data plane interface(s). \n\n Internet access for failover: Remember that an API call to AWS will still use an outbound request to the Internet. Make sure you allow the BIG-IP devices to make outbound connections over HTTPS to the Internet. If this is not available, you will find that your route tables are not updated at time of failover. (If you have a hard requirement that your devices should not have outbound access to internet, you can follow Arnulfo's guide linked to above and use VPC endpoints to keep this traffic on your local VPC) \n\n iApp logs: you can enable this in the iApp settings. I have used the logs (in /var/ltm/log) to troubleshoot issues that I have created myself. That’s how I learned not to accidentally cut off Internet access for your devices! \n\n Don’t forget about return routes if SNAT is disabled: Just like on-prem environments, if you disable SNAT, the pool member will need to route return traffic back to the BIG-IP device. You will commonly set up a default route (0.0.0.0/0) in AWS, point it at the ENI of the active BIG-IP device, and associate this route table with the subnet containing the pool members. If the pool members are in a remote VPC, you will need to create this route on the transit gw route table also. \n\n Don’t accidentally cut off internet access: When you configure the default route of 0.0.0.0/0 to point to eth1 of the BIG-IP device, don’t apply this route to every subnet in your Security VPC. It may be easy to do so accidentally, but remember that it could cause the API calls to update route tables to fail when the Standby device becomes Active. \n\n Don’t forget to disable source/dest check on your ENI’s. This is configured by the template, but if you have other devices that require it, remember to check this setting. ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"8203","kudosSumWeight":5,"repliesCount":27,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTEyMjEtNjk3M2k0NDMwQUU4RjVBNDgyM0Ez?revision=1\"}"}}],"totalCount":1,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:291173":{"__typename":"Conversation","id":"conversation:291173","topic":{"__typename":"TkbTopicMessage","uid":291173},"lastPostingActivityTime":"2020-07-21T15:27:19.000-07:00","solved":false},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTExNzMtMTIzOTJpMTgzQUI2NzJDNDc4NTA2Mg?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTExNzMtMTIzOTJpMTgzQUI2NzJDNDc4NTA2Mg?revision=1","title":"0151T000003lSzBQAU.png","associationType":"BODY","width":1168,"height":709,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTExNzMtMzg0aTRGNzVBNTI2ODY3MDczM0Y?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTExNzMtMzg0aTRGNzVBNTI2ODY3MDczM0Y?revision=1","title":"0151T000003lO9pQAE.jpg","associationType":"BODY","width":258,"height":243,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTExNzMtNTI4MGk3QkY4QkI0MzNDMkY5RDA1?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTExNzMtNTI4MGk3QkY4QkI0MzNDMkY5RDA1?revision=1","title":"0151T000003lGBYQA2.jpg","associationType":"BODY","width":255,"height":250,"altText":null},"TkbTopicMessage:message:291173":{"__typename":"TkbTopicMessage","subject":"Easy demo: Protect container traffic to EKS with BIG-IP","conversation":{"__ref":"Conversation:conversation:291173"},"id":"message:291173","revisionNum":1,"uid":291173,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:242856"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":1822},"postTime":"2020-01-27T11:22:11.000-08:00","lastPublishTime":"2020-01-27T11:22:11.000-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Intro EKS (Elastic Kubernetes Service) is popular! It allows you to deploy apps without managing the Kubernetes mgmt plane yourself. If you're planning to run an app using EKS, you will likely need to consider ingress security along with that app. Securing traffic into Kubernetes is a topic we love to talk about at F5. Why would you want a demo securing traffic into EKS? It's fully automated! Since most people are new to Kubernetes (k8s for short), I find myself in need of a quick demo that's totally open for anyone to run. This way after I demo, the audience can go back to run it on their own, decompose it for themselves, and take their own time to understand it all. Here's what we will automatically deploy: Prerequisites In short, you'll need an AWS demo account, a workstation with Terraform installed, your AWS creds configured, and the aws-iam-authenticator installed. Here's a VM with all of your prerequisites: If you don't have a workstation with Terraform installed, don't worry! You can easily set up the client workstation you need by deploying this demo workstation, which will have all the required tools. Then, configure your AWS IAM credentials. Side note: When building a cloud solution example, I try to stay as \"vendor neutral\" as practical and avoid using 3rd party tools when possible. For example, I have written a demo using AWS Lambda functions, instead of a 3rd party automation tool, for post-deployment configuration. This might be preferred if you do not (or cannot) use a particular 3rd party tool. So I originally started down the path of following this article to completely build an EKS demo via CFT. I planned to extend the quickstart demo to include an ingress controller and security policy, along with an app to protect. I guess I planned to use Lambda functions again. However, after talking about this with colleagues, the workarounds came to seem silly: nobody would do this in real life, so constraining myself to only using a CFT seemed unnecessary. Instead I chose to use the ubiquitous tool Terraform. This is easier to use and also saves me from requiring a user to have a few other tools, like kubectl, helm, and aws-iam-authenticator, etc. So, for better or worse, Terraform is a pre-req here. The workstation I've used is Ubuntu 18.04. Now, for the demo To deploy: You'll need Terraform set up and your AWS credentials configured. Optionally, deploy a demo workstation by following the ReadMe guide here. Configure your AWS credentials in a demo account. Remember, this demo will deploy AWS resources that will cost you money via your AWS bill. Don't forget to destroy all resources at the end of your demo. If you choose to skip this step, proceed with your own client workstation. But if you hit failures, I recommend using this demo workstation, since it is what I used when building this demo. Connect to your workstation and run these commands. When prompted for confirmation, type \"yes\" as instructed. git clone https://github.com/mikeoleary/aws-eks-bigip-terraform\ncd aws-eks-bigip-terraform/vpc\nterraform init\nterraform plan\nterraform apply\n You've deployed! You will need to wait around 20 mins for everything to deploy: a VPC, EKS, a BIG-IP, and then an application in EKS to be protected by BIG-IP. To see your finished product: Once your Terraform commands have completed, you should see output values. If not, type this and take a note of the output values: terraform output\n Now, open a web browser and visit http://<public_ip_app>. If you want to inspect the configuration of BIG-IP, visit https://<public_dns> and login with username admin and password <password>. If you want to see the pods, service, or configmap running in EKS, run: mkdir ~/.kube\nterraform output kubeconfig > ~/.kube/config\nkubectl describe po\nkubectl describe svc\nkubectl describe configmap\n Don't stop here! Remember, you'll need to follow the steps to destroy your AWS resources, otherwise you'll be charged for running these AWS resources. Coincidentally you can use Terraform to limit this kind of rogue AWS spend, so don't be this guy: Delete this demo To destroy this demo in full, type: terraform destroy\n What just happened? Let's review what just happened. First, Terraform deployed a VPC and subnets, using the AWS provider. Then, Terraform deployed some more resources in AWS: an EKS cluster an EC2 instance to be the k8s worker node a BIG-IP VM Then, Terraform deployed some resources to EKS using the Kubernetes provider: a k8s deployment using the f5devcentral/helloworld image a k8s service to expose this deployment a k8s secret, a service account, and a cluster role binding, all to be used later in the helm deployment a k8s configMap resource, which is read by CIS and populates a pool in a partition with IP addresses of pods in a given service. Then, Terraform deployed F5 Container Ingress Services to k8s using the helm provider: a helm chart that deploys F5 CIS using helm the helm deployment was configured so that F5 CIS will point at the BIG-IP mgmt address, and use the secret generated earlier. After all this, the components are all in place. We have an app in k8s that is exposed to ingress traffic, which is routed via the BIG-IP and automatically updated. Our app is protected! Call to Action To summarize: Please use this demo to teach yourself and show your colleagues: how critical it is to secure traffic into your container environment how you can automate this process by using the tools you wish, and F5's extensive API's for automation. Please leave me a note with feedback if you are able to use this demo. I would like it to be useful for you. Let me know how I can make it more useful, or feel free to contribute to the repo yourself. Thanks! ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"5865","kudosSumWeight":5,"repliesCount":5,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTExNzMtMTIzOTJpMTgzQUI2NzJDNDc4NTA2Mg?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTExNzMtMzg0aTRGNzVBNTI2ODY3MDczM0Y?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTExNzMtNTI4MGk3QkY4QkI0MzNDMkY5RDA1?revision=1\"}"}}],"totalCount":3,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:291172":{"__typename":"Conversation","id":"conversation:291172","topic":{"__typename":"TkbTopicMessage","uid":291172},"lastPostingActivityTime":"2019-08-20T03:03:31.000-07:00","solved":false},"TkbTopicMessage:message:291172":{"__typename":"TkbTopicMessage","subject":"Use AWS Lambda functions in a CFT","conversation":{"__ref":"Conversation:conversation:291172"},"id":"message:291172","revisionNum":1,"uid":291172,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:242856"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":1427},"postTime":"2019-08-20T03:03:31.000-07:00","lastPublishTime":"2019-08-20T03:03:31.000-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Problem statement: \n\n You have an existing VPC and you want to deploy Big-IP, and you want to add a default route to steer traffic to the ENI of the Big-IP after it's created. \n\n We can easily use F5’s supported templates to deploy Big-IP in AWS with a CloudFormation Template (CFT) into this VPC, but what if you want to add some automation after the Big-IP is deployed? For example, what if you wanted to add a default route to steer traffic to the ENI of the Big-IP that was just created? You might think of these options: \n\n You could create the RouteTable(s) as part of your CFT and associate it with the subnet(s) you deploy your Big-IP into. But what if the route already exists in your VPC? You can’t edit a route via a CFT - only create one. You could use a tool to automate your deployment, like Ansible or Jenkins. This is a fantastic demonstration of these tools. You could deploy Big-IP, then use a CFT output to get the ENI id of the Big-IP interface, get the route table id, and make your update via the replace-route API call . But, you might be required to make your entire deployment in 1 CFT, or maybe you’re looking to ensure your CFT doesn’t rely on other tasks after deployment? So, what if you cannot use a 3rd party tool? You could write your automation into a Lambda function, then create and execute that Lambda function as part of your CFT. This gives you the ability to run tasks in AWS as part of your CFT deployment. \n\n \n\n This article explains option #3. Modify the automation for your other use cases. \n\n Solution: \n\n The steps to follow when you need Lambda functionality as part of your CFT are: \n\n Create an IAM role in your CFT for your Lambda function to execute. Create a Lambda function Create a Custom Resource that is backed by the Lambda function. This will execute your Lambda function with parameters you can specify, and report back a Success or Failure to CloudFormation. \n\n \n\n I’ll explain how to do each of these and provide an example CFT at the end. \n\n Create an IAM role \n\n Include code such as below to create an IAM role that is appropriate for your Lambda function. Do not provide more permission than required to this role. Very public breaches have occurred as a result of mis-use of IAM roles, so by keeping your IAM roles limited in scope, you decrease your risk if it is mis-used. (In fact, I wrote some best practices to decrease this risk.) In our case, we’re allowing my Lambda function permissions over EC2 service. \n\n Create a Lambda function \n\n Here’s where you’ll need to define the data you’ll pass to your Lambda function (if any), what you want Lambda to do, and what it should return (if anything). Then write your function in a supported language. I’ve chosen Python. \n\n In this case, we’re updating a route in AWS, so we’re passing 3 things to the function: a CIDR range, an ENI id, and a RouteTable id. Upon creation, this Lambda function will update the specified route (CIDR) in the specified RouteTable, to point at the specified ENI. The Lambda function will also reference the IAM role we are creating. \n\n Create a Custom Resource. \n\n Custom Resources can be used to represent things we cannot define with AWS CFT types normally, like EC2 instances and VPC’s. A Lambda-backed Custom Resource is just one example of this. Our Custom Resource will pass an Event Type to the Lambda function (either Create, Update, or Delete), and then we’ll pass Resource Properties that will provide the function with the CIDR, ENI id, and RouteTable id required. In our case, the Lambda function returns the output of the API call upon Create, but returns nothing upon Delete. \n\n Still with me? String these together, and you have a Lambda function that is executed as part of your CFT. CloudFormation is smart enough to know that these depend upon values from other resources in the template, so they will be created after the EC2 instance is created. You could use a DependsOn statement to ensure this behavior, if you had other reasons to wait for something before Lambda execution. \n\n Demo \n\n Attached to this article is a ZIP file containing 2 CFT templates. First, deploy CFT #1, which is a file called \"vpc.json\". This will create a VPC that pre-exists your BigIP deployment. It is extremely simple: a single VPC, with a single subnet, which has an associated Route Table, with a default route of 0.0.0.0/0 pointing to an Internet Gateway. Take a note of the Outputs. There will be a RouteTableId and a SubnetId. You will need these Id's on the next step. Notice: the Route Table you created has a default route pointing toward an Internet Gateway. Then, deploy CFT #2, which is a file called \"route-update.json\". You will need to enter 2 parameters: the RouteTableId and SubnetId that were outputs from step #1. It will deploy an ENI (network interface) into the subnet, and then update the RouteTable that you have specified in your input parameters to point 0.0.0.0/0 at this ENI. Notice again: the Route Table's default route has been updated to point at the ENI, not the Internet Gateway. \n\n \n\n Obviously you'll want to modify these to point at the ENI of a Big-IP device, but I've kept these templates very simple to show you just the updating of a route via Lambda. You may even want to modify the code of the Lambda function to do other things - go for it! \n\n Enjoy. Use this article as a starting point, then think of cool use cases for Lambda functions. Prove them out and leave a comment to share your experience. And don’t forget - \n\n Your own role within the AWS account matters. You cannot create an IAM role that has permissions greater than you have yourself. (And if you’re deploying this with a service account using another IAM role, consider that) \n\n \n\n Credit goes to this article, which I used to learn about Lambda-backed Custom Resources and then modified for this use case. Demo Cloud Formation Template Files ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"5975","kudosSumWeight":5,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:288760":{"__typename":"Conversation","id":"conversation:288760","topic":{"__typename":"TkbTopicMessage","uid":288760},"lastPostingActivityTime":"2021-06-15T08:12:03.000-07:00","solved":false},"User:user:303065":{"__typename":"User","uid":303065,"login":"Tyler_Hatton","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/m_assets/avatars/default/avatar-10.svg?time=0"},"id":"user:303065"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTE5NTBpMzBFNEY2MkNFNzAyM0VCRQ?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTE5NTBpMzBFNEY2MkNFNzAyM0VCRQ?revision=1","title":"0EM1T000002dAhD.png","associationType":"BODY","width":624,"height":334,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtNjg3N2k2NTMyRUM5Njk5NTFGMTRC?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtNjg3N2k2NTMyRUM5Njk5NTFGMTRC?revision=1","title":"0EM1T000002dAhE.png","associationType":"BODY","width":1263,"height":689,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTY1NGk2M0FDRTE4QzA4RUFENTE4?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTY1NGk2M0FDRTE4QzA4RUFENTE4?revision=1","title":"0EM1T000002dAhF.png","associationType":"BODY","width":1385,"height":689,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTI3ODRpOTdGNjA4QTlCNzBBOEQwRA?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTI3ODRpOTdGNjA4QTlCNzBBOEQwRA?revision=1","title":"0EM1T000002dAhG.png","associationType":"BODY","width":453,"height":485,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTU2MjRpMTRDRUI0Qjg1MUU2OEIyQQ?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTU2MjRpMTRDRUI0Qjg1MUU2OEIyQQ?revision=1","title":"0EM1T000002dAhH.png","associationType":"BODY","width":468,"height":430,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTA1OTNpRDdBREE3NzU2NzQwQUEzRQ?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTA1OTNpRDdBREE3NzU2NzQwQUEzRQ?revision=1","title":"0EM1T000002dAhI.png","associationType":"BODY","width":1445,"height":680,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtNTQ3MGk0RUI2QTBCNTI3M0IyMDU4?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtNTQ3MGk0RUI2QTBCNTI3M0IyMDU4?revision=1","title":"0EM1T000002dAhJ.png","associationType":"BODY","width":1660,"height":787,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtNDU2aUEyOEJDM0Y5QjM1MTJFMzA?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtNDU2aUEyOEJDM0Y5QjM1MTJFMzA?revision=1","title":"0EM1T000002dAhK.png","associationType":"BODY","width":624,"height":334,"altText":null},"TkbTopicMessage:message:288760":{"__typename":"TkbTopicMessage","subject":"Getting the Most out of Amazon EC2 Autoscale Groups with F5 BIG-IP","conversation":{"__ref":"Conversation:conversation:288760"},"id":"message:288760","revisionNum":1,"uid":288760,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:303065"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":1428},"postTime":"2021-06-15T08:12:03.000-07:00","lastPublishTime":"2021-06-15T08:12:03.000-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" An Introduction to Amazon EC2 Auto Scaling \n\n \n\n One of the core tenets of cloud computing is elasticity, or the ability to scale cloud resources as needed to meet organizational or user needs. Amazon EC2 Auto Scaling is a feature within AWS focused on facilitating the provisioning and deprovisioning of elastic cloud computing resources to meet user demand. This article will cover how F5 BIG-IP can embrace elasticity and leverage the various features of Auto Scaling to manage steps of the F5 BIG-IP lifecycle, such as provisioning, licensing, configuration management, and upgrades. \n\n \n\n The Architecture \n\n In a typical F5 BIG-IP architect leveraging Amazon EC2 Auto Scaling, there are two key components. The first key component is the Auto Scaling group itself that contains one to many F5 BIG-IP VE instances as part of a managed group. As the name suggests, the power of an Auto Scaling group is its ability to introduce and remove F5 BIG-IP VE instances in the group based on a specified number of required instances or configured monitoring threshold reflecting user demand. \n\n \n\n The second key component is the AWS NLB or Network Load Balancer. While limited in its features compared to an F5 BIG-IP, the NLB plays a critical role in distributing traffic evenly across the F5 BIG-IP VEs within the Auto Scaling group. The NLB also tracks F5 BIG-IP instances added and removed from the Auto Scaling group and load balances only to active instances within the group. \n\n Brought together, an Auto Scaling group containing F5 BIG-IPs and NLB brings the benefits of elasticity and scaling of F5 BIG-IP functionality by provisioning and deprovisioning BIG-IP instances to match organizational capacity needs. Additionally, this architecture has the potential benefit of simplifying maintenance of F5 BIG-IPs by enabling engineers to remove instances from service to perform tasks such as upgrades. \n\n While this architecture brings many new benefits to scaling and maintenance, it also introduces new unique challenges: \n\n How do you ensure a consistent configuration is applied when a new F5 BIG-IP is provisioned? If you are using BYOL licensing with BIG-IQ, how do you ensure licenses are being applied during provisioning and revoked during termination? How do you ensure the F5 BIG-IP you just provisioned is tested and fully functioning before going into service? \n\n These are all challenges where Lifecycle Hooks become our secret weapon. \n\n \n\n Meet Lifecycle Hooks \n\n A powerful feature contained within Amazon EC2 Auto Scaling is Lifecycle Hooks. Lifecycle Hooks are event-driven triggers executed as instances are added or removed from an Auto Scaling group. Lifecycle Hooks enable the ability to put EC2 instances in a wait state at various steps of the instance's lifecycle and execute external actions such as an AWS Lambda function. \n\n \n\n \n\n The power of Lifecycle Hooks in the context of F5 BIG-IP is it enables the ability to execute external AWS Lambda-driven code to perform management tasks such as applying a list of AS3 declarations from an S3 bucket at the time of provisioning or revoking a BYOL license at the time of termination. This feature simplifies the management of F5 BIG-IP Auto Scaling groups by ensuring any newly provisioned F5 BIG-IPs have the needed configurations to match other instances in the group. Additionally, this feature provides the benefit of immediately revoking F5 BIG-IP BYOL licenses when an instance is being deprovisioned, ensuring an organization is maximizing its F5 spend. \n\n \n\n In addition to F5 BIG-IP lifecycle management tasks, Lifecycle Hooks can perform initial testing of F5 BIG-IP instances before being placed inside the Auto Scaling group to accept new user traffic. These tests can include use cases such as ensuring a group of VIPs is correctly processing traffic or a WAF policy is blocking a known attack. If the F5 BIG-IP fails the test, the Lifecycle Hook can terminate the failing instance and spin up a new one until the test criteria are met. This workflow automatically reduces the risk of a failing F5 BIG-IP instance receiving user traffic and ensuring a standard level of quality control for F5 BIG-IP instances entering the Auto Scaling group. \n\n \n\n The power of Lifecycle Hooks combined with the flexibility AWS Lambda provides for an almost near endless number of possibilities as part of the F5 BIG-IP provisioning and deprovisioning lifecycle. Lifecycle hooks empower cloud engineers and F5 administrators to programmatically trigger event-driven code to perform repetitive management and testing tasks common for scaling F5 BIG-IP deployments. An example of an AWS Lambda function used to perform the lifecycle tasks mentioned above can be found here. \n\n \n\n Rolling Updates with Instance Refresh \n\n In addition to Lifecycle Hooks, Amazon EC2 Auto Scaling provides a feature to simplify the ability to upgrade F5 BIG-IPs called Instance Refresh. Instance Refresh enables the ability to incrementally replace one version of an F5 BIG-IP's machine image with another version of the image in the form of a rolling deployment. \n\n \n\n Integrated with Lifecycle Hooks, Instance Refresh can upgrade, configure, and replace instances running an older version of BIG-IP with a new version. Additionally, Instance Refresh by default integrates with NLB to gradually drain connections of the old F5 BIG-IP images before removal, making the service impact of performing an upgrade little to nonexistent. The combined benefit of Instance Refresh with Lifecycle Hooks is an automated upgrade process with the potential of minimal user impact. \n\n \n\n Speedier Scaling with Warm Pools \n\n The final helpful feature of Amazon EC2 Auto Scaling when managing F5 BIG-IPs is warm pools. A warm pool is a newly added feature within Auto Scaling that allows for the creation of pre-initialized F5 BIG-IPs that live in a stopped state until the additional capacity is needed. \n\n \n\n The benefit of using a warm pool in an F5 BIG-IP Auto Scale group is that it enables the ability to perform many of the time-consuming tasks performed when initializing a virtual appliance ahead of when the BIG-IP is needed. These tasks include licensing, module provisioning, and other onboarding tasks. When tested, the use of a warm pool on average nearly halved the amount of time to add a new BIG-IP into service. The cost of maintaining a warm pool is also relatively small compared to paying for an overprovisioned Auto Scaling group, as AWS does not charge for compute for stopped instances and only charges for storage. When examining the architectural considerations for using Auto Scaling F5 BIG-IP instance, warm pools enable the ability to quickly add new F5 BIG-IP instances in scenarios where user demand may be unpredictable. \n\n \n\n Conclusion and Next Steps \n\n In this article, we have covered the many ways Amazon EC2 Auto Scaling can be leveraged to improve the management of F5 BIG-IP instances inside AWS. For further information and a full Terraform example of how the concepts detailed in this article can be implemented, check out this GitHub repository: https://github.com/tylerhatton/f5-warm-pool-demo ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"7330","kudosSumWeight":5,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTE5NTBpMzBFNEY2MkNFNzAyM0VCRQ?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtNjg3N2k2NTMyRUM5Njk5NTFGMTRC?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTY1NGk2M0FDRTE4QzA4RUFENTE4?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTI3ODRpOTdGNjA4QTlCNzBBOEQwRA?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTU2MjRpMTRDRUI0Qjg1MUU2OEIyQQ?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtMTA1OTNpRDdBREE3NzU2NzQwQUEzRQ?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDc","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtNTQ3MGk0RUI2QTBCNTI3M0IyMDU4?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDg","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODg3NjAtNDU2aUEyOEJDM0Y5QjM1MTJFMzA?revision=1\"}"}}],"totalCount":8,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:284381":{"__typename":"Conversation","id":"conversation:284381","topic":{"__typename":"TkbTopicMessage","uid":284381},"lastPostingActivityTime":"2024-03-19T16:01:54.998-07:00","solved":false},"User:user:49688":{"__typename":"User","uid":49688,"login":"Jeff_Giroux_F5","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS00OTY4OC0xNjQzMGlBMjE3NkNDMzVDOUUwOTEw"},"id":"user:49688"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMTlpQzVCODdDMjhCN0I3NzQ4RQ?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMTlpQzVCODdDMjhCN0I3NzQ4RQ?revision=8","title":"cfe-diagram.gif","associationType":"BODY","width":941,"height":728,"altText":"cfe-diagram.gif"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtNTIzMmlDMTk3QTEyQUEwQkEwMDRB?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtNTIzMmlDMTk3QTEyQUEwQkEwMDRB?revision=8","title":"0151T000003WGPAQA4.png","associationType":"BODY","width":1295,"height":731,"altText":"0151T000003WGPAQA4.png"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMjBpNzU1MkZBQzJEQ0VDRkNGOA?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMjBpNzU1MkZBQzJEQ0VDRkNGOA?revision=8","title":"regional-failover.png","associationType":"BODY","width":3516,"height":1874,"altText":"regional-failover.png"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTEzMDBpRjUyNDYwNDQ3N0EwNzE5QQ?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTEzMDBpRjUyNDYwNDQ3N0EwNzE5QQ?revision=8","title":"0151T000003WGPKQA4.png","associationType":"BODY","width":1024,"height":502,"altText":"0151T000003WGPKQA4.png"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTIzN2kyMDMyM0I2NDZFN0RDQTY0?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTIzN2kyMDMyM0I2NDZFN0RDQTY0?revision=8","title":"0151T000003WGOeQAO.png","associationType":"BODY","width":1024,"height":577,"altText":"0151T000003WGOeQAO.png"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMzRpMEFBQUY5NjYyNDUwNEU5Rg?revision=8\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMzRpMEFBQUY5NjYyNDUwNEU5Rg?revision=8","title":"public-cloud-scaling-pros-cons.png","associationType":"BODY","width":1234,"height":516,"altText":"public-cloud-scaling-pros-cons.png"},"TkbTopicMessage:message:284381":{"__typename":"TkbTopicMessage","subject":"F5 High Availability - Public Cloud Guidance","conversation":{"__ref":"Conversation:conversation:284381"},"id":"message:284381","revisionNum":8,"uid":284381,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:49688"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":5837},"postTime":"2020-05-04T11:01:37.000-07:00","lastPublishTime":"2024-03-19T16:01:54.998-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" \n This article will provide information about BIG-IP and NGINX high availability (HA) topics that should be considered when leveraging the public cloud. There are differences between on-prem and public cloud such as cloud provider L2 networking. These differences lead to challenges in how you address HA, failover time, peer setup, scaling options, and application state. \n Topics Covered: \n \n Discuss and Define HA \n Importance of Application Behavior and Traffic Sizing \n HA Capabilities of BIG-IP and NGINX \n Various HA Deployment Options (Active/Active, Active/Standby, auto scale) \n Example Customer Scenario \n \n What is High Availability? \n High availability can mean many things to different people. Depending on the application and traffic requirements, HA requires dual data paths, redundant storage, redundant power, and compute. It means the ability to survive a failure, maintenance windows should be seamless to user, and the user experience should never suffer...ever! \n Reference: https://en.wikipedia.org/wiki/High_availability \n So what should HA provide? \n \n Synchronization of configuration data to peers (ex. configs objects) \n Synchronization of application session state (ex. persistence records) \n Enable traffic to fail over to a peer \n Locally, allow clusters of devices to act and appear as one unit \n Globally, disburse traffic via DNS and routing \n \n Importance of Application Behavior and Traffic Sizing \n Let's look at a common use case... \n \"gaming app, lots of persistent connections, client needs to hit same backend throughout entire game session\" \n Session State \n The requirement of session state is common across applications using methods like HTTP cookies, F5 iRule persistence, JSessionID, IP affinity, or hash. The session type used by the application can help you decide what migration path is right for you. Is this an app more fitting for a lift-n-shift approach...Rehost? Can the app be redesigned to take advantage of all native IaaS and PaaS technologies...Refactor? \n Reference: 6 R's of a Cloud Migration \n \n Application session state allows user to have a consistent and reliable experience \n Auto scaling L7 proxies (BIG-IP or NGINX) keep track of session state \n BIG-IP can only mirror session state to next device in cluster \n NGINX can mirror state to all devices in cluster (via zone sync) \n \n Traffic Sizing \n The cloud provider does a great job with things like scaling, but there are still cloud provider limits that affect sizing and machine instance types to keep in mind. BIG-IP and NGINX are considered network virtual appliances (NVA). They carry quota limits like other cloud objects. \n \n Google GCP VPC Resource Limits \n Azure VM Flow Limits \n AWS Instance Types \n \n Unfortunately, not all limits are documented. Key metrics for L7 proxies are typically SSL stats, throughput, connection type, and connection count. Collecting these application and traffic metrics can help identify the correct instance type. We have a list of the F5 supported BIG-IP VE platforms on F5 CloudDocs. \n F5 Products and HA Capabilities \n BIG-IP HA Capabilities \n BIG-IP supports the following HA cluster configurations: \n \n Active/Active - all devices processing traffic \n Active/Standby - one device processes traffic, others wait in standby \n Configuration sync to all devices in cluster \n L3/L4 connection sharing to next device in cluster (ex. avoids re-login) \n L5-L7 state sharing to next device in cluster (ex. IP persistence, SSL persistence, iRule UIE persistence) \n \n Reference: BIG-IP High Availability Docs \n NGINX HA Capabilities \n NGINX supports the following HA cluster configurations: \n \n Active/Active - all devices processing traffic \n Active/Standby - one device processes traffic, others wait in standby \n Configuration sync to all devices in cluster \n Mirroring connections at L3/L4 not available \n Mirroring session state to ALL devices in cluster using Zone Synchronization Module (NGINX Plus R15) \n \n Reference: NGINX High Availability Docs \n HA Methods for BIG-IP \n In the following sections, I will illustrate 3 common deployment configurations for BIG-IP in public cloud. \n \n HA for BIG-IP Design #1 - Active/Standby via API \n HA for BIG-IP Design #2 - A/A or A/S via LB \n HA for BIG-IP Design #3 - Regional Failover (multi region) \n \n HA for BIG-IP Design #1 - Active/Standby via API (multi AZ) \n This failover method uses API calls to communicate with the cloud provider and move objects (IP address, routes, etc) during failover events. The F5 Cloud Failover Extension (CFE) for BIG-IP is used to declaratively configure the HA settings. \n \n Cloud provider load balancer is NOT required \n Fail over time can be SLOW! \n Only one device actively used (other device sits idle) \n Failover uses API calls to move cloud objects, times vary (see CFE Performance and Sizing) \n \n Key Findings: \n \n Google API failover times depend on number of forwarding rules \n Azure API slow to disassociate/associate IPs to NICs (remapping) \n Azure API fast when updating routes (UDR, user defined routes) \n AWS reliable with API regarding IP moves and routes \n \n Recommendations: \n \n This design with multi AZ is more preferred than single AZ \n Recommend when \"traditional\" HA cluster required or Lift-n-Shift...Rehost \n For Azure (based on my testing)... \n \n Recommend using Azure UDR versus IP failover when possible \n Look at Failover via LB example instead for Azure \n If API method required, look at DNS solutions to provide further redundancy \n \n \n \n HA for BIG-IP Design #2 - A/A or A/S via LB (multi AZ) \n \n Cloud LB health checks the BIG-IP for up/down status \n Faster failover times (depends on cloud LB health timers) \n Cloud LB allows A/A or A/S \n \n Key difference: \n \n Increased network/compute redundancy \n Cloud load balancer required \n \n Recommendations: \n \n Use \"failover via LB\" if you require faster failover times \n For Google (based on my testing)...\n \n Recommend against \"via LB\" for IPSEC traffic (Google LB not supported) \n If load balancing IPSEC, then use \"via API\" or \"via DNS\" failover methods \n \n \n \n HA for BIG-IP Design #3 - Regional Failover via DNS (multi AZ, multi region) \n \n BIG-IP VE active/active in multiple regions \n Traffic disbursed to VEs by DNS/GSLB \n DNS/GSLB intelligent health checks for the VEs \n \n Key difference: \n \n Cloud LB is not required \n DNS logic required by clients \n Orchestration required to manage configs across each BIG-IP \n BIG-IP standalone devices (no DSC cluster limitations) \n \n Recommendations: \n \n Good for apps that handle DNS resolution well upon failover events \n Recommend when cloud LB cannot handle a particular protocol \n Recommend when customer is already using DNS to direct traffic \n Recommend for applications that have been refactored to handle session state outside of BIG-IP \n Recommend for customers with in-house skillset to orchestrate (Ansible, Terraform, etc) \n \n HA Methods for NGINX \n In the following sections, I will illustrate 2 common deployment configurations for NGINX in public cloud. \n \n HA for NGINX Design #1 - Active/Standby via API \n HA for NGINX Design #2 - Auto Scale Active/Active via LB \n \n HA for NGINX Design #1 - Active/Standby via API (multi AZ) \n \n NGINX Plus required \n Cloud provider load balancer is NOT required \n Only one device actively used (other device sits idle) \n Only available in AWS currently \n \n Recommendations: \n \n Recommend when \"traditional\" HA cluster required or Lift-n-Shift...Rehost \n \n Reference: Active-Passive HA for NGINX Plus on AWS \n HA for NGINX Design #2 - Auto Scale Active/Active via LB (multi AZ) \n \n NGINX Plus required \n Cloud LB health checks the NGINX \n Faster failover times \n \n Key difference: \n \n Increased network/compute redundancy \n Cloud load balancer required \n \n Recommendations: \n \n Recommended for apps fitting a migration type of Replatform or Refactor \n \n Reference: Active-Active HA for NGINX Plus on AWS, Active-Active HA for NGINX Plus on Google \n Pros & Cons: Public Cloud Scaling Options \n Review this handy table to understand the high level pros and cons of each deployment method. \n Example Customer Scenario #1 \n As a means to make this topic a little more real, here is a common customer scenario that shows you the decisions that go into moving an application to the public cloud. Sometimes it's as easy as a lift-n-shift, other times you might need to do a little more work. In general, public cloud is not on-prem and things might need some tweaking. Hopefully this example will give you some pointers and guidance on your next app migration to the cloud. \n Current Setup: \n \n Gaming applications \n F5 Hardware BIG-IP VIRPIONs on-prem \n Two data centers for HA redundancy \n iRule heavy configuration (TLS encryption/decryption, payload inspections) \n Session Persistence = iRule Universal Persistence (UIE), and other methods \n Biggest app \n 15K SSL TPS \n 15Gbps throughput \n 2 million concurrent connections \n 300K HTTP req/sec (L7 with TLS) \n \n Requirements for Successful Cloud Migration: \n \n Support current traffic numbers \n Support future target traffic growth \n Must run in multiple geographic regions \n Maintain session state \n Must retain all iRules in use \n \n Recommended Design for Cloud Phase #1: \n \n Migration Type: Hybrid model, on-prem + cloud, and some Rehost \n Platform: BIG-IP \n Retaining iRules means BIG-IP is required \n Licensing: High Performance BIG-IP \n Unlocks additional CPU cores past 8 (up to 24) \n extra traffic and SSL processing \n Instance type: check F5 supported BIG-IP VE platforms for accelerated networking (10Gb+) \n HA method: Active/Standby and multi-region with DNS \n iRule Universal persistence only mirrors to only next device, keep cluster size to 2 \n scale horizontally via additional HA clusters and DNS \n clients pinned to a region via DNS (on-prem or public cloud) \n inside region, local proxy cluster shares state \n \n This example comes up in customer conversations often. Based on customer requirements, in-house skillset, current operational model, and time frames there is one option that is better than the rest. A second design phase lends itself to more of a Replatform or Refactor migration type. In that case, more options can be leveraged to take advantage of cloud-native features. For example, changing the application persistence type from iRule UIE to cookie would allow BIG-IP to avoid keeping track of state. Why? With cookies, the client keeps track of that session state. Client receives a cookie, passes the cookie to L7 proxy on successive requests, proxy checks cookie value, sends to backend pool member. The requirement for L7 proxy to share session state is now removed. \n Example Customer Scenario #2 \n Here is another customer scenario. This time the application is a full suite of multimedia content. In contrast to the first scenario, this one will illustrate the benefits of rearchitecting various components allowing greater flexibility when leveraging the cloud. You still must factor in-house skill set, project time frames, and other important business (and application) requirements when deciding on the best migration type. \n Current Setup: \n \n Multimedia (Gaming, Movie, TV, Music) Platform \n BIG-IP VIPRIONs using vCMP on-prem \n Two data centers for HA redundancy \n iRule heavy (Security, Traffic Manipulation, Performance) \n Biggest App: oAuth + Cassandra for token storage (entitlements) \n \n Requirements for Success Cloud Migration: \n \n Support current traffic numbers \n Elastic auto scale for seasonal growth (ex. holidays) \n VPC peering with partners (must also bypass Web Application Firewall) \n Must support current or similar traffic manipulating in data plane \n Compatibility with existing tooling used by Business \n \n Recommended Design for Cloud Phase #1: \n \n Migration Type: Repurchase, migration BIG-IP to NGINX Plus \n Platform: NGINX \n iRules converted to JS or LUA \n Licensing: NGINX Plus \n Modules: GeoIP, LUA, JavaScript \n HA method: N+1 \n Autoscaling via Native LB \n Active Health Checks \n \n This is a great example of a Repurchase in which application characteristics can allow the various teams to explore alternative cloud migration approaches. In this scenario, it describes a phase one migration of converting BIG-IP devices to NGINX Plus devices. This example assumes the BIG-IP configurations can be somewhat easily converted to NGINX Plus, and it also assumes there is available skillset and project time allocated to properly rearchitect the application where needed. \n Summary \n OK! Brains are expanding...hopefully? We learned about high availability and what that means for applications and user experience. We touched on the importance of application behavior and traffic sizing. Then we explored the various F5 products, how they handle HA, and HA designs. These recommendations are based on my own lab testing and interactions with customers. Every scenario will carry its own requirements, and all options should be carefully considered when leveraging the public cloud. Finally, we looked at a customer scenario, discussed requirements, and design proposal. Fun! \n Resources \n Read the following articles for more guidance specific to the various cloud providers. \n \n Advanced Topologies and More on Highly Available Services \n Lightboard Lessons - BIG-IP Deployments in Azure \n Google and BIG-IP Failing Faster in the Cloud \n BIG-IP VE on Public Cloud \n High-Availability Load Balancing with NGINX Plus on Google Cloud Platform \n Using AWS Quick Starts to Deploy NGINX Plus \n NGINX on Azure \n \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"13591","kudosSumWeight":5,"repliesCount":2,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMTlpQzVCODdDMjhCN0I3NzQ4RQ?revision=8\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtNTIzMmlDMTk3QTEyQUEwQkEwMDRB?revision=8\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMjBpNzU1MkZBQzJEQ0VDRkNGOA?revision=8\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTEzMDBpRjUyNDYwNDQ3N0EwNzE5QQ?revision=8\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTIzN2kyMDMyM0I2NDZFN0RDQTY0?revision=8\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODQzODEtMTkxMzRpMEFBQUY5NjYyNDUwNEU5Rg?revision=8\"}"}}],"totalCount":6,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:302844":{"__typename":"Conversation","id":"conversation:302844","topic":{"__typename":"TkbTopicMessage","uid":302844},"lastPostingActivityTime":"2022-11-28T09:45:27.447-08:00","solved":false},"User:user:215984":{"__typename":"User","uid":215984,"login":"Heath_Parrott","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS0yMTU5ODQtMjA5NTdpRkU1NkVFOUZDRDE4RTAyQw"},"id":"user:215984"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjAxMzZpMUJCNjhGQTlGMDgzMTQ1Mw?revision=17\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjAxMzZpMUJCNjhGQTlGMDgzMTQ1Mw?revision=17","title":"Screen Shot 2022-10-14 at 12.59.16 PM.png","associationType":"BODY","width":718,"height":492,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjAxMzdpOEUxRjU2NzlBMTQyMTBDQg?revision=17\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjAxMzdpOEUxRjU2NzlBMTQyMTBDQg?revision=17","title":"Screen Shot 2022-10-14 at 1.10.13 PM.png","associationType":"BODY","width":702,"height":472,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjAxMzhpNkYzRjA3RDQ4MzI2OTIzNg?revision=17\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjAxMzhpNkYzRjA3RDQ4MzI2OTIzNg?revision=17","title":"Screen Shot 2022-10-14 at 1.23.51 PM.png","associationType":"BODY","width":1138,"height":495,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjA3ODNpNjUyRDBFNzI3NkU2M0U3Mw?revision=17\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjA3ODNpNjUyRDBFNzI3NkU2M0U3Mw?revision=17","title":"Untitled Diagram-Page-1.drawio-4.png","associationType":"BODY","width":844,"height":696,"altText":null},"TkbTopicMessage:message:302844":{"__typename":"TkbTopicMessage","subject":"Using F5 Application Security and DoS Solutions with AWS Global Accelerator Part 1","conversation":{"__ref":"Conversation:conversation:302844"},"id":"message:302844","revisionNum":17,"uid":302844,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:215984"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":" How do you secure applications that are not a good fit for a CDN? In Part 1 of the series we cover how using F5 security solutions combined with AWS Global Accelerator can solve for performance and security concerns from L3 to L7. In the overall series we will explore WAF, BOT, DOS vectors applying cloud concepts of elasticity, declarative interfaces and as code practices. ","introduction":"","metrics":{"__typename":"MessageMetrics","views":2484},"postTime":"2022-11-28T05:00:00.033-08:00","lastPublishTime":"2022-11-28T09:45:27.447-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" \n F5 Security Services and AWS Global Accelerator \n Many applications require network optimization and security services and are not optimized for caching. For these applications it is common to see them deployed with few to no optimization services and limited security. Let's examine the benefits of a network architecture that is optimized for security and performance and apply that context to how F5 and AWS Global Accelerator can address these applications. \n \n We will explore how users can: \n \n Increase network performance by minimizing loss, latency and jitter \n Detect and prevent L3/L4 volumetric attacks such as connection floods, reflections, and TCP/UDP protocol validation \n Detect and prevent malicious BOT attacks \n Leverage signature and behavioral signals to prevent application attacks \n Prevent L7 DoS attacks \n \n \n \n A Brief Overview Networking Performance and how AWS Global Accelerator Helps \n \n \n \n \n When two systems communicate they, generally, determine if they are going to use TCP or UDP. Independent of which transport protocol the majority of applications behave in a request and response pattern where a client requests something of a server and the server provides a response. This pattern means that variables of capacity, distance and network conditions will have material impact to how the user perceives application performance. By many measures this will be a leading factor in how on what user judges performance on. \n AWS Global Accelerator provides many of the same benefits. \n \n More than 104+ POPs globally, each able to present your accelerator to the Internet, providing endpoint diversity and proximity. \n For TCP applications the initial termination points is moved closer to the user, increasing the network performance for TCP based applications. \n Optimal network path to AWS Regions. By using the AWS backbone between the edge and the application much of the latency and jitter present the Internet is removed increasing network performance. \n \n Click here more information on AWS Global Accelerator. \n Attacking the Network and Transport Layers \n \n \n When we architect an application to withstand a network layer attacks the most vectors will be amplifications (network) and transport layer (protocol). An attacker is looking to exhaust the system resources related to the network bandwidth, memory or processing of the targets network stack such as application servers, reverse proxies and firewalls. To address this attack we need to think about horizontal scale across multiple dimensions. \n \n \n \n \n \n \n Defensive Measure \n Description \n How we will meet the challenge \n \n \n \n \n Scale the application servers horizontally. \n \n \n This can be achieved with use of a load balancing system. Normally load balancing systems are combined functionality with reverse proxies. \n \n \n Global Accelerator provides abstraction of regions, availability zones, and application servers providing basic load balancing and simple persistence. Our security services will leverage Application layer constructs as necessary. \n \n \n \n \n \n \n Scale the number network connection points \n \n \n \n \n Increase the number of places our endpoint IP address is presented to the Internet. This may be referred to as IP anycast. \n \n \n \n \n Global Accelerator provides BGP peering and a presents the network ranges at 104+ POPs globally \n \n \n \n \n \n \n Increase network bandwidth \n \n \n \n \n The amount of network bandwidth do we have to deal with reflections, floods and other traffic that can saturate traffic coming to our endpoint. \n \n \n \n \n Each of the Global Accelerator POPs has large volumes of bandwidth to the Internet and on the AWS backbone connecting to our security services \n \n \n \n \n \n \n \n \n TCP/IP protocol validation \n \n \n \n \n \n \n \n \n Malformed transport protocols such as SYN floods and other half open connections consume memory on our network devices \n \n \n \n \n \n \n \n \n Global Accelerator provides TCP/UDP endpoints that will validate the protocol characteristics and the POP diversity make resource exhaustion and bypass extremely complex \n \n \n \n \n \n \n \n High Level AWS Global Accelerator Architecture \n AWS Global Accelerator attracts traffic and passes it to the following objects inside of AWS such as EC2 Instances, ELB, or Elastic IPs. \n \n For EC2 endpoints behind Global Accelerator F5 provides a Layer7 DDoS Solution to optimize your deployment for security and performance. Below are questions to consider. \n \n \n \n Do I have a security solution? \n Does my security only address known threats (IE based on signatures)? \n Will my security solution detect BOTs? \n What about malicious behavior? \n \n \n Do I have the ability to mitigate by creating dynamic signatures? \n Can I create stepped mitigation such as CAPTCHA, Rate Limit and Block? \n Can my security solution learn my application? \n Does my security solution evaluate threats on multiple vectors such as signature, behavior, protocol compliance? \n \n \n How do I prevent credential stuffing attacks? \n How do I mitigate AI, Automated CAPTCHA solving and Human attacker farms? \n How do I prevent fraud? \n How do I deal with the ever changing landscape of IP's that have attack reputations? \n \n \n What can I do about emerging Threat Campaigns (current attack trends)? \n Does my security solution help me score traffic for False Positive and False Negatives? \n Does my security solution support web, mobile and API traffic? \n Does my security solution support as code management and deployment? \n \n \n \n At this point you will have two choices: \n 1. Build all of these services into each and every application endpoint \n 2. Deploy an automated, reusable, blueprinted solution that is focused on security \n The choice that cannot be made is to do nothing and hope you do not become a story in the evening news. \n Introducing Application Security and Application DOS Insertion Architecture \n Most organizations do not want to keep reinventing the wheel when it comes to security, authentication, zero trust or other critical services for each application they must deploy. To address the challenge you will need to insert security into the data path. While the picture does not change much, it will allow us to answer yes to the questions above and more. \n \n The security insertion point can be BIG-IP platforms or NGINX+ platforms. The correct choice will be a decision based on your needs around the security stack and influenced by the team(s) that own the cloud platform. \n Putting the End to End Security Path Together \n If we line up the traffic path we will see a pattern like this: Clients connect to the closes Global Accelerator Endpoint. The Global Accelerator will mitigate the volumetric and L4 protocol attacks passing common L7 traffic to the configured endpoints. F5 BIG-IP or NGINX endpoints will parse that L7 traffic based on security policy, traffic attributes and make a decision to permit, deny or rate limit traffic to the application endpoints. \n \n Agility, Elasticity and Service Discovery \n For an organization to the most value from public cloud agility is a requirement. Solutions that require repeated manual configuration steps, deployments that are static, or require other human intervention are an anti-patterns. This solution supports dynamic scale at the security layer, service discover at the application layer and the ability to use common cloud or enterprise logging targets such as CloudWatch, Splunk or ELK (to name a few). We will look at logs and graphs later in the series. \n Elasticity of the Security Layer \n Yes. Yes. Yes. Elasticity is supported at the security layer. To properly address this solution we need to address this question at the security layer and at the Global Accelerator layer. \n F5 has supported AutoScale solutions for years. With the release of our CloudFormation V2 solutions we have leveraged the F5 Automation Tool chain and their declarative interfaces to build solutions that support large scale horizontal deployments. When users deploy an F5 AutoScale group in AWS instances leverage template files to create the configuration. Every instance in the group will receive the same configuration. When users want to update the configuration they simply created a revision of the file and perform a CloudFormation stack update. You can read more about F5 AutoScaling here. \n AWS Global Accelerator does not have a native integration to read AWS AutoScale groups. The good news is that this problem has already been solved and documented by AWS. Enter using EC2 lifecycle hooks and AWS Lambda. If we look at the following blog we can see that instances can be added to target groups based on scale in and scale out events. Cool. We will explore AutoScaling in more detail in later parts of the article series. \n What about Service Discovery of My Application? \n Important question. TL;DR - yes. Both the BIG-IP and NGINX platforms support service discovery of all different types of AWS resources. The diagram above depicts applications on EC2 instances, EKS, ECS and Fargate. We could go one step further and simply say if the network can connect to it we can protect it and you can use it for you application. \n \n \n \n Platform \n Service Discovery Option \n \n \n BIG-IP \n DNS A Records \n \n \n BIG-IP \n AWS Instance Tags (example autoscalegroup tag) \n \n \n BIG-IP \n ENI Tag \n \n \n BIG-IP Event Listener/API \n Third party pushes pool information to BIG-IP \n \n \n BIG-IP Container Ingress \n Listens for containers and updates BIG-IP \n \n \n NGINX \n DNS A and SRV records \n \n \n NGINX \n AWS AutoScale groups \n \n \n \n We will use service discovery of our demo application later in the article series. \n Wrapping up \n Now that we have an idea of why we need to do take action on security when using AWS Global Accelerator and we know what we are going to do we need to get our hands on experience and put things to the test. We will do that in part 2 of the series Here is a sneak peek at what we will build in the next session: \n \n \n \n \n \n \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"10575","kudosSumWeight":4,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjAxMzZpMUJCNjhGQTlGMDgzMTQ1Mw?revision=17\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjAxMzdpOEUxRjU2NzlBMTQyMTBDQg?revision=17\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjAxMzhpNkYzRjA3RDQ4MzI2OTIzNg?revision=17\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NDQtMjA3ODNpNjUyRDBFNzI3NkU2M0U3Mw?revision=17\"}"}}],"totalCount":4,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:280994":{"__typename":"Conversation","id":"conversation:280994","topic":{"__typename":"TkbTopicMessage","uid":280994},"lastPostingActivityTime":"2020-02-12T17:19:01.000-08:00","solved":false},"User:user:115030":{"__typename":"User","uid":115030,"login":"Rodrigo_Albuque","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/m_assets/avatars/default/avatar-6.svg?time=0"},"id":"user:115030"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtMTM0MTFpMDY5MjMzQzUzNTQxMEM5Qg?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtMTM0MTFpMDY5MjMzQzUzNTQxMEM5Qg?revision=1","title":"0151T000003lbNpQAI.png","associationType":"BODY","width":1424,"height":604,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtMTg4aTY1NUQ0NDQzRTM1ODJEMjc?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtMTg4aTY1NUQ0NDQzRTM1ODJEMjc?revision=1","title":"0151T000003lbh6QAA.png","associationType":"BODY","width":1728,"height":728,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtMTE1NDBpNkNCNzJEQUY1MkE3Q0RDMg?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtMTE1NDBpNkNCNzJEQUY1MkE3Q0RDMg?revision=1","title":"0151T000003lbNzQAI.png","associationType":"BODY","width":1600,"height":896,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtNzM5Mmk2Qjk2RUM5QTE2ODVBOTQy?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtNzM5Mmk2Qjk2RUM5QTE2ODVBOTQy?revision=1","title":"0151T000003lbO4QAI.png","associationType":"BODY","width":818,"height":226,"altText":null},"TkbTopicMessage:message:280994":{"__typename":"TkbTopicMessage","subject":"How does F5 AS3 really work under the hood?","conversation":{"__ref":"Conversation:conversation:280994"},"id":"message:280994","revisionNum":1,"uid":280994,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:115030"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":2141},"postTime":"2020-02-07T01:26:50.000-08:00","lastPublishTime":"2020-02-07T01:26:50.000-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Put it simple, AS3 is a way to configure a BIG-IP once a BIG-IP is already provisioned. Full stop! We can also use AS3 to maintain that configuration over time. The way it works is we as a client send a JSON declaration via REST API and AS3 engine is supposed to work out how to configure BIG-IP the way it's been declared. AS3 internal components (parser and auditor) are explained further ahead. For non-DEV audience, AS3 is simply the name we give to an intelligent listener which acts as an interpreter that reads our declaration and translate it to proper commands to be issued on the BIG-IP. AS3 engine may or may not reside on BIG-IP (more on that on section entitled \"3 ways of using AS3\"). Yes, AS3 is declared in a structured JSON file and there are many examples on how to configure your regular virtual server, profiles, pools, etc, on clouddocs. AS3 uses common REST methods to communicate such as GET, POST and DELETE under the hood. For example, when we send our AS3 declaration to BIG-IP, we're sending an HTTP POST with the AS3 JSON file attached. AS3 is part of the Automation Toolchain which includes Declarative Onboarding and Telemetry Steaming. What AS3 is NOT Not a Mechanism for Role-Based Access Control (RBAC) AS3 doesn't support RBAC in a way that you can allow one user to configure certain objects and another user to configure other objects. AS3 has to use admin username/password with full access to BIG-IP resources. Not a GUI There's currently no native GUI built on top of AS3. Not an orchestrator AS3 won't and doesn't work out how to connect to different BIG-IPs and automatically figure out which box it needs to send which configuration to. All it does is receive a declaration, forwards it on and configure BIG-IP. Not for converting BIG-IP configuration We can't currently use AS3 to pull BIG-IP configuration and generate an AS3 configuration but I hope this functionality should be available in the future. Not for licensing or other onboarding functions We can't use AS3 for doing things like configuring VLANs or NTP servers. We use AS3 to configure BIG-IP once it's been already initially provisioned. For BIG-IP's initial set up, we use Declarative Onboarding. Why should we use AS3? To configure and maintain BIG-IPs across multiple versions using the same automated workflow. A simple JSON declaration becomes the source of Truth with AS3, where configuration edits should only be made to the declaration itself. If multiple BIG-IP boxes use the same configuration, a single AS3 declaration can be used to configure the entire fleet. It can also be easily integrated with external automation tools such as Ansible and Terraform. What I find really REALLY cool about AS3 AS3 targets and supports BIG-IP version 12.1 and higher. Say we have an AS3 declaration that was previously used to configure BIG-IP v12.1, right? Regardless if we're upgrading or moving config to another box, we can still use the same declaration to configure BIG-IP v15.1 box in the same way. I'm not joking! Back in the F5 Engineering Services days, I still remember when I used to grab support tickets where the issue was a configuration from an earlier version that was incompatible with newer version, e.g. a profile option was moved to a different profile, or new feature was added that requires some other option to be selected, etc. This is supposed to be a thing of the past with AS3. AS3 Key Features Transactional If you're a DBA, you've certainly heard of the term ACIDIC (atomicity, consistency, isolation, and durability). Let's say we send an AS3 declaration with 5 objects. AS3 will either apply the entire declaration or not apply at all. What that means is that if there's one single error, AS3 will never apply part of the configuration and leave BIG-IP in an unknown/inconsistent state. There's no in-between state. Either everything gets configured or nothing at all. It's either PASS or FAIL. Idempotent Say we send a declaration where there's nothing to configure on BIG-IP. In that case, AS3 will come back to client and inform that there's nothing for it to do. Essentially, AS3 won't remove BIG-IP's entire config and then re-apply it. It is smart enough to determine what work it needs to do and it will always do as little work as possible. Bounded AS3 enforces multi-tenancy by default, i.e. AS3 only creates objects in partitions (known as \"tenants\" in AS3 jargon) other than /Common. If we look at the AS3 declaration examples, we can see that a tenant (partition) is specified before we declare our config. AS3 does not create objects in the /Common partition. The exception to that is /Common/Shared when objects are supposed to be shared among multiple partitions/tenants. An example is when we create a pool member and a node gets automatically created on BIG-IP. Such node is created on /Common/Shared partition because that node might be a pool member in another partition, for example. Nevertheless, AS3 scope is and must always be bounded. The 3 ways of using AS3 Using AS3 through BIG-IP In this case here, we install AS3 RPM on each BIG-IP. BIG-IP is the box that has the \"AS3 listener\" waiting for us to send our AS3 JSON config file. All we need to do is to download AS3's binary and install it locally. There's a step by step guide for babies (with screenshots) here using BIG-IP's GUI. There's also a way to do it using curl if you're a geek like me here. Using AS3 through BIG-IQ In this case, we don't need to manually install AS3 RPM on each BIG-IP box like in previous step. BIG-IQ does it for us. BIG-IQ v6.1.0+ supports AS3 and we can directly send declarations through BIG-IQ. Apart from installing, BIG-IQ also upgrades AS3 in the target box (or boxes) if they're using an older version. Analytics and RBAC are also supported. Using AS3 through Docker container This is where AS3 is completely detached from BIG-IP. In the Docker container set up, AS3 engine resides within a Docker container decoupled from BIG-IP. Say your environment have Docker containers running, which is not something uncommon nowadays. We can install AS3 in a Docker container and use that container as the entry-point to send our AS3 declaration to BIG-IP. Yes, we as Cluent send our AS3 JSON file to where the Docker container is running and as long as the Docker container can reach our BIG-IP, then it will connect and configure it. Notice that in this case our AS3 engine runs outside of BIG-IP so we don't have to install AS3 on our BIG-IP fleet here. Docker container communicates with BIG-IP using iControl REST sending tmsh commands directly. AS3 Internal Components AS3 engine is comprised of an AS3 parser and AS3 auditor: AS3 Parser This is the front-end part of AS3 that communicates with the client and is responsible for client's declaration validation. AS3 Auditor After receiving validated declaration from AS3 parser, AS3 auditor's job is to compare desired validated declaration with BIG-IP's current configuration. It then determines what needs to be added/removed and forwards the changes to BIG-IP. AS3 in Action The way it works is Client sends a declaration to AS3 parser and config validation process kicks in. If declaration is not valid, it throws an error back to client along with an error code. If valid, declaration is forwarded on to AS3 auditor which then compares declaration with current BIG-IP's config and determines what needs to change. Only the configuration changes are supposed to be sent to BIG-IP, not the whole config. AS3 auditor then converts AS3 declaration to tmsh commands and send converted tmsh config to BIG-IP via iControl REST. BIG-IP then pushes the changes via tmsh commands and returns success/error to AS3 auditor. If changes are not successful, an error is returned all the way to the client. Otherwise, successful code is returned to client and changes are properly applied to BIG-IP. Here's the visual description of what I've just said: Debugging AS3 AS3 schema validation errors are returned in HTTP Response with a message pointing to the specific error: This includes typos in property names and so on. Logs on BIG-IP are stored on /var/log/restnoded/restnoded.log and by default only errors are logged. Log level can be changed through the Controls object in AS3 declaration itself. AS3 vs Declarative Onboarding This is usually source of confusion so I'd like to clarify that a bit. AS3 is the way we configure BIG-IP once it's already up and running. Declarative Onboarding (DO) is for the initial configuration of BIG-IP, i.e. setting up licence, users, DNS, NTP and even provisioning modules. Just like AS3, DO is API-only so no GUI on top of it. We can also have AS3 and DO in the same BIG-IP, so that's not a problem at all. Currently, there's no option to run it in a container like AS3 so as far as I'm concerned, it's only RPM based. Resources AS3 CloudDocs GitHub Repo Releases Declarative Onboarding (DO) CloudDocs GitHub Repo Releases I'd like to thank F5 Software Engineers Steven Chadwick and Garrett Dieckmann from AS3 team for providing a brilliant reference material. ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"9399","kudosSumWeight":4,"repliesCount":2,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtMTM0MTFpMDY5MjMzQzUzNTQxMEM5Qg?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtMTg4aTY1NUQ0NDQzRTM1ODJEMjc?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtMTE1NDBpNkNCNzJEQUY1MkE3Q0RDMg?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODA5OTQtNzM5Mmk2Qjk2RUM5QTE2ODVBOTQy?revision=1\"}"}}],"totalCount":4,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:302866":{"__typename":"Conversation","id":"conversation:302866","topic":{"__typename":"TkbTopicMessage","uid":302866},"lastPostingActivityTime":"2022-11-28T09:23:05.279-08:00","solved":false},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NjYtMjA3ODRpQzU5QzgwNjU0MzczRjY0Mw?revision=16\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NjYtMjA3ODRpQzU5QzgwNjU0MzczRjY0Mw?revision=16","title":"Untitled Diagram-Page-1.drawio-4.png","associationType":"BODY","width":844,"height":696,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NjYtMjA0MzhpNzlGRjM5MUY5MDFDREI2Ng?revision=16\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NjYtMjA0MzhpNzlGRjM5MUY5MDFDREI2Ng?revision=16","title":"Screen Shot 2022-11-04 at 1.20.00 PM.png","associationType":"BODY","width":985,"height":491,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NjYtMjA2NTdpQzg4QzA0NDYwNkFFNjlFNQ?revision=16\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NjYtMjA2NTdpQzg4QzA0NDYwNkFFNjlFNQ?revision=16","title":"Screen Shot 2022-11-15 at 5.59.07 PM.png","associationType":"BODY","width":1323,"height":148,"altText":null},"TkbTopicMessage:message:302866":{"__typename":"TkbTopicMessage","subject":"Using F5 Application Security and DOS Solutions with AWS Global Accelerator - Part 2 Building a Lab","conversation":{"__ref":"Conversation:conversation:302866"},"id":"message:302866","revisionNum":16,"uid":302866,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:215984"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":" Have you ever wanted to test AWS Global Accelerator with F5 Security solutions? Do you want to know how to protect applicaitons that cannot use a CDN but required an optimized experience? We will do that and more in this blog series. In Part 2 we will build our lab by deploying our VPC, BIG-IPS, Global Accelerator and an example application. ","introduction":"","metrics":{"__typename":"MessageMetrics","views":2308},"postTime":"2022-11-28T05:05:00.019-08:00","lastPublishTime":"2022-11-28T09:23:05.279-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" \n Alright! You have spent time understanding the information in part 1 of the series and you are ready to build your test bed. Here is a diagram of what we will build. \n \n We will use the F5 CloudFormation v2 templates to deploy our VPC, AutoScale BIG-IPs and our example application. After we have deployed our basic environment we will then deploy AWS Global Accelerator, it's associated components and we will finish our deployment by using the AWS provided example of using Lambda to populate the Global Accelerator target groups. My examples will use the AWS CLI for these actions but for those that are more WebUI inclined that is an option. \n In this lab we will use the following: \n 1. F5 Autoscale Quickstart Cloud Fomration Template \n 2. F5 BIG-IP BEST 25MB from AWS Marketplace \n 3. AWS Global Accelerator \n Before proceeding you will need to subscribe to the BIG-IP offer in the AWS marketplace. \n What We Will Build \n We will build a topology that supports the following traffic flow: \n \n Clients traffic is attracted to the closest AWS POP and traverses the AWS Backbone to the deployed region \n BIG-IP, acting as an EC2 target to Global Accelerator, will intercept the traffic process the security policy and send the traffic to an application instance \n Instance responds to the BIG-IP \n BIG-IP responds to the Client IP address \n Traffic egress the Global Accelerator infrastructure out of the POP that it entered \n \n \n \n Accessing AWS \n For our examples we will need a system with the AWS CLI installed. You can use your local system or you can use the AWS CloudShell instance from the AWS console. \n \n Deploying BIG-IP, VPC and an Application \n The F5 AutoScale template includes an option to deploy an example application, VPC, BIG-IP AutoScale group and an object called the Disaggregater (DAG). In F5 deployments in the public cloud a DAG can be an Elastic IP (EIP), or Elastic Load Balancer (ELB) this objects function to attract traffic from the Internet via a public IP address and distribute it to one or more instances deployed in AWS. When a user wants to use an AutoScale function the most commonly selected option in AWS is the Network Load Balancer (NLB) variant from the ELB family. We will use the AWS Global Accelerator as our DAG when we deploy the template we will set the DAG option to false. \n Prior to deploying our CloudFormation stack please ensure that you have generated an AWS Key Pair, subscribed to the BIG-IP offering, and documented the public IP address from your location. Your BIG-IP instances will be monitored by AWS for use as Global Accelerator targets. If you do not use 0.0.0.0/0 for \"ParameterKey=restrictedSrcAddressApp,ParameterValue=<0.0.0.0/0 or MY IP> \\\" you will need to edit the AWS security group to allow traffic from Route53 health checks. \n \n \naws cloudformation create-stack --region <REGION> --stack-name <MY NAME> \\\n--template-url https://f5-cft-v2.s3.amazonaws.com/f5-aws-cloudformation-v2/v2.6.0.0/examples/autoscale/payg/autoscale.yaml \\\n--parameters ParameterKey=sshKey,ParameterValue=<KEY PAIR> \\\nParameterKey=restrictedSrcAddressMgmt,ParameterValue=<MY IP> \\\nParameterKey=restrictedSrcAddressApp,ParameterValue=<0.0.0.0/0 or MY IP> \\\nParameterKey=uniqueString,ParameterValue=<MY UNIQUE STRING> \\\nParameterKey=provisionExternalBigipLoadBalancer,ParameterValue=false \\\nParameterKey=notificationEmail,ParameterValue=<MY EMAIL> \\\n --capabilities CAPABILITY_NAMED_IAM \n \n Creating an AWS Global Accelerator \n Now we will deploy our Global Accelerator. Many of the Global Accelerator API calls need to be sent to us-west-2 region and some of the CLI examples may requrie that argument even if you are deploying into another region. \n In this step we will create an AWS Global Accelerator deployment. The end result of this will be that we will have two IPv4 and / or two IPv6 addresses that will be presented to the Internet via the 110+ POPs. Each IP is aligned to an AWS fault domain and unlike ELB addresses these are static for the life of your Global Accelerator deployment. \n aws globalaccelerator create-accelerator --name <my-test-waf-global-accelerator> --ip-address-type IPV4 --enabled --region us-west-2 \n When you command completes you will see information about the created object including it's ARN. Please make a note of it. You can also log all of the output via standard Linux redirect such as > or >> filename.txt (I recommend doing this) \n Creating Listeners for your Global Accelerator \n A listener is a combination of IP Address(es) associated with your Global Accelerator , Port and Protocol (TCP or UDP). We will need to create listener on our Global Accelerator that will allows us to process and forward the traffic that is attracted to the IP addresses. \n In the command below we ill create a listener that uses SOURCE IP affinity to the targets (our security layer) and will map ports 80 to 80 and 443 to 443 attracting traffic for TCP. These listeners will be created globally in the 110+ POPs. \n aws globalaccelerator create-listener --accelerator-arn <ACCELERATOR ARN> --client-affinity SOURCE_IP --port-ranges FromPort=80,ToPort=80 FromPort=443,ToPort=443 --protocol TCP --region us-west-2 \n \n Creating Endpoints for your Global Accelerator \n Now we will create our endpoints for the Global Accelerator. Endpoints are the targets (in our case EC2 instances performing the security function) of traffic that is attracted onto the network. In the following command you will see two regions. The first is the region we are creating the endpoint group in. The second is the region (us-west-2) that hosts the Global Accelerator API, and is only requried if you are not running the CLI from a us-west-2 cloudshell (our you default region is not us-west-2). \n aws globalaccelerator create-endpoint-group --listener-arn <LISTENER ARN> --endpoint-group-region <REGION> --region us-west-2 \n \n Global Accelerator supports endpoint groups in multiple regions allowing you to steer traffic to the closest region that has resources to serve the application. For example let's say your application has users in the US, EU, and APCJ. A single Global Accelerator deployment could leverage AWS regions in all of them ensuring that users have the best experience possible. To add endpoint groups you simple repeat the process. \n At this point we are not yet ready to test traffic. We have an IP address(s) for our Global Accelerator, Listners, and one or more endpoint groups. We will now need to populate an endpoint group to respond to our HTTP requests. \n Populating Endpoint Groups \n If you remember Part 1 there was a brief discussion about Global Accelerator and AutoScale. TL;DR is Global Accelerator does not have native integration with AutoScale and human intervention may be required. We will not use the antipattern of humans doing work that does not add value. Enter AWS Lambda and EC2 lifecycle hooks. Once we deploy this you will be able to spend your time doing more important work. \n You can get the CloudFormation Template (CFT) for this solution from the AWS blog or the attached file (due to file type limits copy the text in the PDF to a .yaml file). Either way I recommend that you read the blog to understand how it works. The template file will need to be on the system you are running the CLI commands from. \n Step 1 - Get our BIG-IP AutoScale group name \n aws autoscaling describe-auto-scaling-groups --region <REGION> | grep bigip\n \"AutoScalingGroupName\": \"mywaf-bigip-autoscaling-group\", \n Step 2 - Deploy the template \n aws cloudformation create-stack --stack-name GlobalAcceleratorAndAutoScaling --template-body file://asg_aga.yaml --parameters ParameterKey=EndpointGroupARN,ParameterValue= <OUR-ENDPOINT-GROUP-ARN> ParameterKey=AutoscalingGroupName,ParameterValue=<bigip-autoscaling-group-name> --region <REGION> --capabilities CAPABILITY_IAM\n \n Once the template completes we will need to generate AutoScale events since the population of the endpoints requires EC2 lifecycle events. (remember --region us-west-2 is only required if your default region is not us-west-2 or if you cloudshell instance is not in us-west-2) \n \naws autoscaling update-auto-scaling-group \\\n --auto-scaling-group-name <ASG-Group-Name> \\\n --min-size 0 --desired-capacity 0\n\naws autoscaling update-auto-scaling-group \\\n --auto-scaling-group-name <ASG-Group-Name> \\\n --min-size 1 --desired-capacity 1\n\naws globalaccelerator describe-endpoint-group \\\n --endpoint-group-arn <YourEndpointGroupARN> \\\n --region us-west-2 \n At this point you should have an endpoint group that is populated by one or more instances of BIG-IP. Here is the output of the last command above \n aws globalaccelerator describe-endpoint-group --endpoint-group-arn arn:aws:globalaccelerator::711213608975:accelerator/e6eb780d-90d1-48d8-a85c-f6f8899e3e10/listener/c35f4fbb/endpoint-group/80fcf0d7d002 \n{\n\"EndpointGroup\": {\n\"EndpointGroupArn\": \"arn:aws:globalaccelerator::711213608975:accelerator/e6eb780d-90d1-48d8-a85c-f6f8899e3e10/listener/c35f4fbb/endpoint-group/80fcf0d7d002\",\n\"EndpointGroupRegion\": \"us-east-1\",\n\"EndpointDescriptions\": [\n{\n\"EndpointId\": \"i-0881a10b4512cf96b\",\n\"Weight\": 128,\n\"HealthState\": \"HEALTHY\",\n\"ClientIPPreservationEnabled\": true\n}\n],\n\"TrafficDialPercentage\": 100.0,\n\"HealthCheckPort\": 80,\n\"HealthCheckProtocol\": \"TCP\",\n\"HealthCheckIntervalSeconds\": 30,\n\"ThresholdCount\": 3\n}\n} \n Testing your Global Accelerator \n Now we need the IP addresses of your global accelerator, the listeners and endpoint groups we can start testing our application. \n Getting the Accelerator IPs from the AWS CLI \n aws globalaccelerator list-accelerators --region us-west-2\n…\n \"AcceleratorArn\": \"<ARN>\",\n \"IpFamily\": \"IPv4\",\n \"IpAddresses\": [\n \"IP\",\n \"IP\"\n \n \n Example of a request rejected by BIG-IP Advanced WAF: \n curl -vvv -X DELETE http://<IP>\n\n* Trying IP:80...\n…\n \n* Closing connection 0\n<html><head><title>Request Rejected</title></head><body>The requested URL was rejected. Please consult with your administrator.<br><br>Your support ID is: <F5_generated_support_id><br><br><a href='javascript&colon;history.back();'>[Go Back]</a></body></html>% \n \n Example of a request allowed by BIG-IP Advanced WAF: \n curl -vvv http://<IP>\n\n* Trying IP:80...\n…\nBIGipServer~Tenant_1~Shared~shared_pool=3171024906.20480.0000; path=/; Httponly\n< Set-Cookie: <cookie_value>; Path=/\n<\n* Connection #0 to host IP left intact\n<!DOCTYPE html><html><head><title>Demo App (default)</title><link\n \n \n Wrapping Up \n Today we covered how to setup the topology and test traffic. In part 3 we will cover the following: 1. Infrastructure as code - publishing new security policies \n 2. Logging and Visibility \n 3. Differences between our lab and a production deployment \n \n \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"11687","kudosSumWeight":3,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NjYtMjA3ODRpQzU5QzgwNjU0MzczRjY0Mw?revision=16\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NjYtMjA0MzhpNzlGRjM5MUY5MDFDREI2Ng?revision=16\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDI4NjYtMjA2NTdpQzg4QzA0NDYwNkFFNjlFNQ?revision=16\"}"}}],"totalCount":3,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"CachedAsset:text:en_US-components/community/Navbar-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/community/Navbar-1744046273800","value":{"community":"Community Home","inbox":"Inbox","manageContent":"Manage Content","tos":"Terms of Service","forgotPassword":"Forgot Password","themeEditor":"Theme Editor","edit":"Edit Navigation Bar","skipContent":"Skip to content","migrated-link-9":"Groups","migrated-link-7":"Technical Articles","migrated-link-8":"DevCentral News","migrated-link-1":"Technical Forum","migrated-link-10":"Community Groups","migrated-link-2":"Water Cooler","migrated-link-11":"F5 Groups","Common-external-link":"How Do I...?","migrated-link-0":"Forums","article-series":"Article Series","migrated-link-5":"Community Articles","migrated-link-6":"Articles","security-insights":"Security Insights","migrated-link-3":"CrowdSRC","migrated-link-4":"CodeShare","migrated-link-12":"Events","migrated-link-13":"Suggestions"},"localOverride":false},"CachedAsset:text:en_US-components/community/NavbarHamburgerDropdown-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/community/NavbarHamburgerDropdown-1744046273800","value":{"hamburgerLabel":"Side Menu"},"localOverride":false},"CachedAsset:text:en_US-components/community/BrandLogo-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/community/BrandLogo-1744046273800","value":{"logoAlt":"Khoros","themeLogoAlt":"Brand Logo"},"localOverride":false},"CachedAsset:text:en_US-components/community/NavbarTextLinks-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/community/NavbarTextLinks-1744046273800","value":{"more":"More"},"localOverride":false},"CachedAsset:text:en_US-components/authentication/AuthenticationLink-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/authentication/AuthenticationLink-1744046273800","value":{"title.login":"Sign In","title.registration":"Register","title.forgotPassword":"Forgot Password","title.multiAuthLogin":"Sign In"},"localOverride":false},"CachedAsset:text:en_US-components/nodes/NodeLink-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/nodes/NodeLink-1744046273800","value":{"place":"Place {name}"},"localOverride":false},"CachedAsset:text:en_US-components/tags/TagSubscriptionAction-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/tags/TagSubscriptionAction-1744046273800","value":{"success.follow.title":"Following Tag","success.unfollow.title":"Unfollowed Tag","success.follow.message.followAcrossCommunity":"You will be notified when this tag is used anywhere across the community","success.unfollowtag.message":"You will no longer be notified when this tag is used anywhere in this place","success.unfollowtagAcrossCommunity.message":"You will no longer be notified when this tag is used anywhere across the community","unexpected.error.title":"Error - Action Failed","unexpected.error.message":"An unidentified problem occurred during the action you took. Please try again later.","buttonTitle":"{isSubscribed, select, true {Unfollow} false {Follow} other{}}","unfollow":"Unfollow"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageListTabs-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageListTabs-1744046273800","value":{"mostKudoed":"{value, select, IDEA {Most Votes} other {Most Likes}}","mostReplies":"Most Replies","mostViewed":"Most Viewed","newest":"{value, select, IDEA {Newest Ideas} OCCASION {Newest Events} other {Newest Topics}}","newestOccasions":"Newest Events","mostRecent":"Most Recent","noReplies":"No Replies Yet","noSolutions":"No Solutions Yet","solutions":"Solutions","mostRecentUserContent":"Most Recent","trending":"Trending","draft":"Drafts","spam":"Spam","abuse":"Abuse","moderation":"Moderation","tags":"Tags","PAST":"Past","UPCOMING":"Upcoming","sortBymostRecent":"Sort By Most Recent","sortBymostRecentUserContent":"Sort By Most Recent","sortBymostKudoed":"Sort By Most Likes","sortBymostReplies":"Sort By Most Replies","sortBymostViewed":"Sort By Most Viewed","sortBynewest":"Sort By Newest Topics","sortBynewestOccasions":"Sort By Newest Events","otherTabs":" Messages list in the {tab} for {conversationStyle}","guides":"Guides","archives":"Archives"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/QueryHandler-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/QueryHandler-1744046273800","value":{"title":"Query Handler"},"localOverride":false},"CachedAsset:text:en_US-components/community/NavbarDropdownToggle-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/community/NavbarDropdownToggle-1744046273800","value":{"ariaLabelClosed":"Press the down arrow to open the menu"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/OverflowNav-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/OverflowNav-1744046273800","value":{"toggleText":"More"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageView/MessageViewInline-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageView/MessageViewInline-1744046273800","value":{"bylineAuthor":"{bylineAuthor}","bylineBoard":"{bylineBoard}","anonymous":"Anonymous","place":"Place {bylineBoard}","gotoParent":"Go to parent {name}"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/Pager/PagerLoadMore-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/Pager/PagerLoadMore-1744046273800","value":{"loadMore":"Show More"},"localOverride":false},"CachedAsset:text:en_US-components/customComponent/CustomComponent-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/customComponent/CustomComponent-1744046273800","value":{"errorMessage":"Error rendering component id: {customComponentId}","bannerTitle":"Video provider requires cookies to play the video. Accept to continue or {url} it directly on the provider's site.","buttonTitle":"Accept","urlText":"watch"},"localOverride":false},"CachedAsset:text:en_US-components/users/UserLink-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/users/UserLink-1744046273800","value":{"authorName":"View Profile: {author}","anonymous":"Anonymous"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageSubject-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageSubject-1744046273800","value":{"noSubject":"(no subject)"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageBody-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageBody-1744046273800","value":{"showMessageBody":"Show More","mentionsErrorTitle":"{mentionsType, select, board {Board} user {User} message {Message} other {}} No Longer Available","mentionsErrorMessage":"The {mentionsType} you are trying to view has been removed from the community.","videoProcessing":"Video is being processed. Please try again in a few minutes.","bannerTitle":"Video provider requires cookies to play the video. Accept to continue or {url} it directly on the provider's site.","buttonTitle":"Accept","urlText":"watch"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageTime-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageTime-1744046273800","value":{"postTime":"Published: {time}","lastPublishTime":"Last Update: {time}","conversation.lastPostingActivityTime":"Last posting activity time: {time}","conversation.lastPostTime":"Last post time: {time}","moderationData.rejectTime":"Rejected time: {time}"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/nodes/NodeIcon-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/nodes/NodeIcon-1744046273800","value":{"contentType":"Content Type {style, select, FORUM {Forum} BLOG {Blog} TKB {Knowledge Base} IDEA {Ideas} OCCASION {Events} other {}} icon"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageUnreadCount-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageUnreadCount-1744046273800","value":{"unread":"{count} unread","comments":"{count, plural, one { unread comment} other{ unread comments}}"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageViewCount-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageViewCount-1744046273800","value":{"textTitle":"{count, plural,one {View} other{Views}}","views":"{count, plural, one{View} other{Views}}"},"localOverride":false},"CachedAsset:text:en_US-components/kudos/KudosCount-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/kudos/KudosCount-1744046273800","value":{"textTitle":"{count, plural,one {{messageType, select, IDEA{Vote} other{Like}}} other{{messageType, select, IDEA{Votes} other{Likes}}}}","likes":"{count, plural, one{like} other{likes}}"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageRepliesCount-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageRepliesCount-1744046273800","value":{"textTitle":"{count, plural,one {{conversationStyle, select, IDEA{Comment} OCCASION{Comment} other{Reply}}} other{{conversationStyle, select, IDEA{Comments} OCCASION{Comments} other{Replies}}}}","comments":"{count, plural, one{Comment} other{Comments}}"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/users/UserAvatar-1744046273800":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/users/UserAvatar-1744046273800","value":{"altText":"{login}'s avatar","altTextGeneric":"User's avatar"},"localOverride":false}}}},"page":"/tags/TagPage/TagPage","query":{"messages.widget.messagelistfornodebyrecentactivitywidget-tab-main-messages-list-for-tag-widget-0":"mostKudoed","nodeId":"board:TechnicalArticles","tagName":"AWS"},"buildId":"q_bLpq2mflH0BeZigxpj6","runtimeConfig":{"buildInformationVisible":false,"logLevelApp":"info","logLevelMetrics":"info","openTelemetryClientEnabled":false,"openTelemetryConfigName":"f5","openTelemetryServiceVersion":"25.2.0","openTelemetryUniverse":"prod","openTelemetryCollector":"http://localhost:4318","openTelemetryRouteChangeAllowedTime":"5000","apolloDevToolsEnabled":false,"inboxMuteWipFeatureEnabled":false},"isFallback":false,"isExperimentalCompile":false,"dynamicIds":["./components/customComponent/CustomComponent/CustomComponent.tsx","./components/community/Navbar/NavbarWidget.tsx","./components/community/Breadcrumb/BreadcrumbWidget.tsx","./components/tags/TagsHeaderWidget/TagsHeaderWidget.tsx","./components/messages/MessageListForNodeByRecentActivityWidget/MessageListForNodeByRecentActivityWidget.tsx","./components/tags/TagSubscriptionAction/TagSubscriptionAction.tsx","./components/customComponent/CustomComponentContent/TemplateContent.tsx","../shared/client/components/common/List/ListGroup/ListGroup.tsx","./components/messages/MessageView/MessageView.tsx","./components/messages/MessageView/MessageViewInline/MessageViewInline.tsx","../shared/client/components/common/Pager/PagerLoadMore/PagerLoadMore.tsx","./components/customComponent/CustomComponentContent/HtmlContent.tsx","./components/customComponent/CustomComponentContent/CustomComponentScripts.tsx"],"appGip":true,"scriptLoader":[]}