The Three HTTP Routing Patterns You Should Know
HTTP is the de-facto application transport layer. The majority of applications and APIs today are delivered via HTTP, regardless of their content (HTML, JSON, XML). That means most of the scaling going on is focused on scaling HTTP-based apps. In fact, when I peek at our latest data from nearly 4 million virtual servers, 63% of them are HTTP/S. In MuleSoft’s latest Connectivity Benchmark, respondents reported an average of 1020 applications in their enterprise environments. Even if only 63% are HTTP/S, that’s still a lot of HTTP - with not a lot of IP space to give it. Most organizations aren’t lucky enough to own significant ranges of publicly accessible IP addresses. That’s one of the reasons why “virtual servers” exist in the realm of web serving. So that a single IP address can service multiple servers (or applications). Host-based (virtual) routing has been a go-to for the Internet for years. And though it’s the most commonly used (and best known) type of HTTP routing, there are actually three types of HTTP routing NetOps should get familiar with. That’s because increasingly the world of applications is clashing with that of the network, and many of the deployment patterns being used by DevOps rely on HTTP-based routing capabilities. 1. Host-based The old standard. Host-based routing is what enables virtual servers on web servers. It’s also used by application services like load balancing and ingress controllers to achieve the same thing. One IP address, many hosts. Host-based routing allows you to send a request for api.example.com and for web.example.com to the same endpoint with the certainty it will be delivered to the correct back-end application. 2. Path-based Increasingly common – particularly in the realm of scaling containers using ingress controllers – is path-based routing. Path-based routing requires visibility into the URI portion of an HTTP request. You can route based on the entire path (not advisable) or a portion of the path. For example, you could search for /getprofile in this path and route it to one application while routing all others to a different application. You can also search for /v1 in the path and use it to implement a type of API versioning. Because of the focus on API-only communication in modern apps (like mobile) and architectures (like microservices), the use of path-based routing is increasingly important to enabling not only scale but simple delivery. When everything you need to know is found in the URI (in the path), it becomes imperative that you can dissect that path into its composite pieces and make decisions on where that request needs to go. 3. Header-based Header-based is a broad category that includes some familiar routing patterns such as persistence (sticky sessions). Header-based routing simply means that you use an arbitrary HTTP header as the basis for determining how to route a request. This might be a standard header, like content-type or cookie, or it might be a custom header, like x-custom-header-for-my-app. The use of HTTP headers to route requests is a long-standing tradition of sorts. The concept of sticky sessions (persistence) is based on the use of Cookies to aid in scaling stateful applications. It’s also instrumental in maintaining secure sessions (SSL/TLS). Note that Header-based is usually separated from host-based routing even though host is technically one of the many HTTP headers. Many systems were able to perform host-based routing but not general header-based routing, though today it is hard to find a load balancer/proxy that cannot support routing based on any header. Despite the apparent simplicity of these routing patterns, their importance should not be underestimated. API Gateways, web application firewalls (particularly inspection capabilities), ingress controllers, and a robust set of other application services rely on being able to route based on this information.Acronyms
Acronyms, are used all the time and the author /presentor is usually convinced that everyone in the audience understands what they mean, but every once in a while you hear or read something that you are not sure of the meaning. We are all professionals, that do not want to look like we are the only one in the room who does not know. So after hearing a talk or reading an article we often find ourselves looking it up; this can become confusing because acronyms mean different things when we search outside our field. For example CE what does it mean? The letters "CE" are the abbreviation of French phrase "Conformité Européene" which literally means "European Conformity". In the dictionary you will probably find CE meaning Common Era or Christian Era. When looking for a more modern meaning, we will find it may mean Consumer Electronics. But here in our community, when someone writes CE, they mean Customer Edge. Here, you have, at your fingertips a list of acronyms, unconfused with other fields. Please let me know if I missed any acronyms so I can add them to our list. A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | A ACL - Access Control List ADC - Application Delivery Controller ADN - Application delivery network ADO - Application Delivery Optimization ALG - Application Layer Gateway AI - Artificial Intelligence AJAX - Asynchronous JavaScript and XML API - Application Programming Interface APM - Access Policy Manager ASM - Application Security Manager (F5’s Application Security Manager™ ASM is also known as BD) AWAF - Advanced Web Application Firewall AWS - Amazon Web Services B BaDos - Behaviour AniDDoS (Behaviour AniDDoS, an F5 product that is used against DDoS) BDM -- Business Decision Maker BGP - Border Gateway Protocol BOO - Build Once Only C CDN - Content Delivery Network CE - Customer Edge CGNAT - Carrier Grade NAT CIA triad - Confidentiality, Integrity,Availability (triad Security model) CIFS - Common Internet file system CRS - Core RuleSet CRUD - Create , Read, Update, Delete CSRF - Cross-Site Request Forgery, also known as XSRF CUPS - Control Plane and User Plane Separation CVE - Common Vulnerabilities and exposures CVSS - Common Vulnerability Scoring System D DAP - Digital Adoption Plateform DAST - Dynamic testing. (Examples of such tools Qualys and Nessus) DB - Database DC - Direct Communication / Direct Connect DDoS - Distributed Denial-of-Service DGW - Default Gateway Weight Settings Protocol (DGW) DHCP - Dynamic Host Configuration Protocol DIO - Distribution Initiated Opportunity DLP - Data Loss Protection DMZ - Demilitarized Zone [Demilitarized Zone DNS - Domain Name System DoH - DNS over HTTP DoT - DNS over TLS DPIAs - Data Protection Impact Assessment DRP - Disaster Recovery Plan DSR - Data Subject Rights E ELA - Enterprise License Agreement EDPB - European Data Protection Board EDR - Endpoint Detection and Response EPP - Endpoint Protection Platforms EUSA - End User Software Agreement F FIPS - Federal Information Processing Standards FPGA - field-programmable gate array FQDN - Fully Qualified Domain Name FRR - FRRouting G GDPR - General Data Protection Regulations GKE - Google Kubernetes Engine GPU - Graphic Processing Unit GSLB - Volterra’s Global Load Balancing gRPC - Google Remote Procedure Call H HIPAA - Health Insurance Portability & Accountability Act HMAC -Hash-based message authentication HSL - High-Speed Logging HTTP - Hypertext Transfer HTTPS - Hypertext Transfer Protocol I IANA - Internet Assigned Numbers Authority IBD - Integrated Bot Defense ICO - Information Commission Office IDS - Intrusion Detection System IIoT - Industrial Internet of Things ILM - Information Lifecycle Management IoT - Internet of Things IPAM - IP Address Management IPSec - Internet Protocol Security IR - Incidence Response ISO - Standardization Organization ISP - Internet Service Provider J JS - Javascript K KMS - Key Management Service / Key Management System KPI - Key Performance Indicator KV - Key Value k8s - Kubernetics L L7 - Layer 7 - The application layer LB - Load Balancer LBaaS - Load Balancing as a Service LDAP -Lightweight Directory Access Protocol LFI - Local File Exclusion attack LTM - Local Traffic Manager M MAM - Mobile Application Management MDM - Mobile Device Management MFA - Multi-Factor Authentication MitM - Man in the Middle ML - Machine Learning MSA - Master Service Agreement MSP - Managed Service Provider MT - Managed Tenant mTLS - Mutual Transport Layer Security MUD - Malicious User Detection MUM - Malicious User Mitigation N NAP - Network access point NAS - Network-Attached Storage NAT - Network Address Translation NIC - NetworkInterface Cards NFV - Network functions NFVI - Network functions virtualization NPU - Network Processing Units O OAS - OpenAPI Specification (Swagger) OPA - Open Policy Agent OT - Original Tenant OWASP - Open Web Application Security Project P PAAS - Platform as a service (PaaS PBD - Proactive Bot Defence. PCI DSS - Payment Card Industry Data Security Standard. PBD - Privacy by Design PE - Portable executable PFS - Perfect Forward Secrecy PIA - Privacy Impact Assessments PII - Personally identifiable information POP - Point of Presence Q QoS - Quality of Service R RBAC - Role based Access control RCE - Remote Code Execution RDP - Remote Desktop Protocol RE - Routing Engine, Regional Edges REST - Representational State Transfer *[[Rest API -Representational State Transfer]]* RFI - Request For Information OR Remote File Inclusion vulnerability attack RFP - Request for Proposal RPC - Remote Procedure Call RSA – (Rivest–Shamir–Adleman) is a public-key cryptosystem RTT - Round Trip Time S SAM - Security Accounts Manager SAML - Security Assertion Markup Language SCIM - System for Cross-domain Identity Management SCP - Secure Copy Protocol SCP - Server Communication Proxy SDC - F5 Security and Distributed Cloud SDK - Software Development Kit SDN - Software Defined Network SE - Solutions Engineer SIEM - Security Information & Event Management SLA - Service Level Availability SLED -State,Local Government and Education SLI - Service Level Indicator SNAT - Source Network Address Translation SOC - Security Operations Center SP - Service Provider SPK - Service Proxy for Kubernetes SRE - Site reliability engineering SRT - Security Research Team at F5 SSD - Solid State Drive SSL - Secure Sockets Layer SSO - Single Sign On SSRF - Server-side request forgery STRIDE - Spoofing, Tampering,Repudiation,Information Leakage, Denial of Service, Elevation of Privilege (a TMA Model) T TCL - Tool Command Language TCP - [Transmission Control Protocol TDM - Technical Decision Maker TLS - Transport layer Security TMA - Threat Model Assessment TO - Tenant Owner TOCTOU - Time of Check vs Time of Use TOI - Transfer of Information TTFB - Time to First Bit TTL - Time to Live U UAM - User Access Management UI - User Interface URI - Uniform Resource URL - Uniform Resource Locator UX - User Experience V VER - Volterra Edge Router VES - Volterra Edge Services VIF - virtual interface VIP - Virtual IP address VM - Virtual Machine Vnet - Virtual network VPC - Virtual Private Cloud VPN - Virtual Private Network VRS - Volterra Rules Set W WAAP - Web Application& API Protection WAF - Web application firewall WPA3 - Wi-Fi Alliance Access 3 X XML - Extensible Markup Language [XML - Wikipedia](https://en.wikipedia.org/wiki/XML) XSS - Cross Site Scripting XSRF - Cross-Site Request Forgery, also known as CSRF Y Z ZTNA -Zero Trust Network Access ZTP - Zero-Touch Provisioning ZTS - Zero Trust Security
Automate Application Delivery with F5 and HashiCorp Terraform and Consul
Written by HashiCorp guest author Lance Larsen Today, more companies are adopting DevOps approach and agile methodologies to streamline and automate the application delivery process. HashiCorp enables cloud infrastructure automation, providing a suite of DevOps tools which enable consistent workflows to provision, secure, connect, and run any infrastructure for any application. Below are a few you may have heard of: Terraform Consul Vault Nomad In this article we will focus on HashiCorp Terraform and Consul, and how they accelerate application delivery by enabling network automation when used with F5 BIG-IP (BIG-IP). Modern tooling, hybrid cloud computing, and agile methodologies have our applications iterating at an ever increasing rate. The network, however, has largely lagged in the arena of infrastructure automation, and remains one of the hardest areas to unbottleneck. F5 and HashiCorp bring NetOps to your infrastructure, unleashing your developers to tackle the increasing demands and scale of modern applications with self-service and resilience for your network. Terraform allows us to treat the BIG-IP platform “as code”, so we can provision network infrastructure automatically when deploying new services. Add Consul into the mix, and we can leverage its service registry to catalog our services and enable BIG-IPs service discovery to update services in real time. As services scale up, down, or fail, BIG-IP will automatically update the configuration and route traffic to available and healthy servers. No manual updates, no downtime, good stuff! When you're done with this article you should have a basic understanding of how Consul can provide dynamic updates to BIG-IP, as well as how we can use Terraform for an “as-code” workflow. I’d encourage you to give this integration a try whether it be in your own datacenter or on the cloud - HashiCorp tools go everywhere! Note: This article uses sample IPs from my demo sandbox. Make sure to use IPs from your environment where appropriate. What is Consul? Consul is a service networking solution to connect and secure services across runtime platforms. We will be looking at Consul through the lens of its service discovery capabilities for this integration, but it’s also a fully fledged service mesh, as well as a dynamic configuration store. Head over to the HashiCorp learn portal for Consul if you want to learn more about these other use cases. The architecture is a distributed, highly available system. Nodes that provide services to Consul run a Consul agent. A node could be a physical server, VM, or container. The agent is responsible for health checking the service it runs as well as the node itself. Agents report this information to the Consul servers, where we have a view of services running in the catalog. Agents are mostly stateless and talk to one or more Consul servers. The consul servers are where data is stored and replicated. A cluster of Consul servers is recommended to balance availability and performance. A cluster of consul servers usually serve a low latency network, but can be joined to other clusters across a WAN for multi-datacenter capability. Let’s look at a simple health check for a Nginx web server. We’d typically run an agent in client mode on the web server node. Below is the check definition in json for that agent. { "service": { "name": "nginx", "port": 80, "checks": [ { "id": "nginx", "name": "nginx TCP Check", "tcp": "localhost:80", "interval": "5s", "timeout": "3s" } ] } } We can see we’ve got a simple TCP check on port 80 for a service we’ve identified as Nginx. If that web server was healthy, the Consul servers would reflect that in the catalog. The above example is from a simple Consul datacenter that looks like this. $ consul members Node Address Status Type Build Protocol DC Segment consul 10.0.0.100:8301 alive server 1.5.3 2 dc1 <all> nginx 10.0.0.109:8301 alive client 1.5.3 2 dc1 <default> BIG-IP has an AS3 extension for Consul that allows it to query Consul’s catalog for healthy services and update it’s member pools. This is powerful because virtual servers can be declared ahead of an application deployment, and we do not need to provide a static set of IPs that may be ephemeral or become unhealthy over time. No more waiting, ticket queues, and downtime. More on this AS3 functionality later. Now, we’ll explore a little more below on how we can take this construct and apply it “as code”. What about Terraform? Terraform is an extremely popular tool for managing infrastructure. We can define it “as code” to manage the full lifecycle. Predictable changes and a consistent repeatable workflow help you avoid mistakes and save time. The Terraform ecosystem has over 25,000 commits, more than 1000 modules, and over 200 providers. F5 has excellent support for Terraform, and BIG-IP is no exception. Remember that AS3 support for Consul we discussed earlier? Let’s take a look at an AS3 declaration for Consul with service discovery enabled. AS3 is declarative just like Terraform, and we can infer quite a bit from its definition. AS3 allows us to tell BIG-IP what we want it to look like, and it will figure out the best way to do it for us. { "class": "ADC", "schemaVersion": "3.7.0", "id": "Consul_SD", "controls": { "class": "Controls", "trace": true, "logLevel": "debug" }, "Consul_SD": { "class": "Tenant", "Nginx": { "class": "Application", "template": "http", "serviceMain": { "class": "Service_HTTP", "virtualPort": 8080, "virtualAddresses": [ "10.0.0.200" ], "pool": "web_pool" }, "web_pool": { "class": "Pool", "monitors": [ "http" ], "members": [ { "servicePort": 80, "addressDiscovery": "consul", "updateInterval": 15, "uri": "http://10.0.0.100:8500/v1/catalog/service/nginx" } ] } } } } We see this declaration creates a partition named “Consul_SD”. In that partition we have a virtual server named “serviceMain”, and its pool members will be queried from Consul’s catalog using the List Nodes for Service API. The IP addresses, the virtual server and Consul endpoint, will be specific to your environment. I’ve chosen to compliment Consul’s health checking with some additional monitoring from F5 in this example that can be seen in the pool monitor. Now that we’ve learned a little bit about Consul and Terraform, let’s use them together for an end-to-end solution with BIG-IP. Putting it all together This section assumes you have an existing BIG-IP instance, and a Consul datacenter with a registered service. I use Nginx in this example. The HashiCorp getting started with Consul track can help you spin up a healthy Consul datacenter with a sample service. Let’s revisit our AS3 declaration from earlier, and apply it with Terraform. You can check out support for the full provider here. Below is our simple Terraform file. The “nginx.json” contains the declaration from above. provider "bigip" { address = "${var.address}" username = "${var.username}" password = "${var.password}" } resource "bigip_as3" "nginx" { as3_json = "${file("nginx.json")}" tenant_name = "consul_sd" } If you are looking for a more secure way to store sensitive material, such as your BIG-IP provider credentials, you can check out Terraform Enterprise. We can run a Terraform plan and validate our AS3 declaration before we apply it. $ terraform plan Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. ------------------------------------------------------------------------ An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # bigip_as3.nginx will be created + resource "bigip_as3" "nginx" { + as3_json = jsonencode( { + Consul_SD = { + Nginx = { + class = "Application" + serviceMain = { + class = "Service_HTTP" + pool = "web_pool" + virtualAddresses = [ + "10.0.0.200", ] + virtualPort = 8080 } + template = "http" + web_pool = { + class = "Pool" + members = [ + { + addressDiscovery = "consul" + servicePort = 80 + updateInterval = 5 + uri = "http://10.0.0.100:8500/v1/catalog/service/nginx" }, ] + monitors = [ + "http", ] } } + class = "Tenant" } + class = "ADC" + controls = { + class = "Controls" + logLevel = "debug" + trace = true } + id = "Consul_SD" + schemaVersion = "3.7.0" } ) + id = (known after apply) + tenant_name = "consul_sd" } Plan: 1 to add, 0 to change, 0 to destroy. ------------------------------------------------------------------------ Note: You didn't specify an "-out" parameter to save this plan, so Terraform can't guarantee that exactly these actions will be performed if "terraform apply" is subsequently run. That output looks good. Let’s go ahead and apply it to our BIG-IP. bigip_as3.nginx: Creating... bigip_as3.nginx: Still creating... [10s elapsed] bigip_as3.nginx: Still creating... [20s elapsed] bigip_as3.nginx: Still creating... [30s elapsed] bigip_as3.nginx: Creation complete after 35s [id=consul_sd] Apply complete! Resources: 1 added, 0 changed, 0 destroyed Now we can check the Consul server and see if we are getting requests. We can see log entries for the Nginx service coming from BIG-IP below. consul monitor -log-level=debug 2019/09/17 03:42:36 [DEBUG] http: Request GET /v1/catalog/service/nginx (104.222µs) from=10.0.0.200:43664 2019/09/17 03:42:41 [DEBUG] http: Request GET /v1/catalog/service/nginx (115.571µs) from=10.0.0.200:44072 2019/09/17 03:42:46 [DEBUG] http: Request GET /v1/catalog/service/nginx (133.711µs) from=10.0.0.200:44452 2019/09/17 03:42:50 [DEBUG] http: Request GET /v1/catalog/service/nginx (110.125µs) from=10.0.0.200:44780 Any authenticated client could make the catalog request, so for our learning, we can use cURL to produce the same response. Notice the IP of the service we are interested in. We will see this IP reflected in BIG-IP for our pool member. $ curl http://10.0.0.100:8500/v1/catalog/service/nginx | jq [ { "ID": "1789c6d6-3ae6-c93b-9fb9-9e106b927b9c", "Node": "ip-10-0-0-109", "Address": "10.0.0.109", "Datacenter": "dc1", "TaggedAddresses": { "lan": "10.0.0.109", "wan": "10.0.0.109" }, "NodeMeta": { "consul-network-segment": "" }, "ServiceKind": "", "ServiceID": "nginx", "ServiceName": "nginx", "ServiceTags": [], "ServiceAddress": "", "ServiceWeights": { "Passing": 1, "Warning": 1 }, "ServiceMeta": {}, "ServicePort": 80, "ServiceEnableTagOverride": false, "ServiceProxyDestination": "", "ServiceProxy": {}, "ServiceConnect": {}, "CreateIndex": 9, "ModifyIndex": 9 } ] The network map of our BIG-IP instance should now reflect the dynamic pool. Last, we should be able to verify that our virtual service actually works. Let’s try it out with a simple cURL request. $ curl http://10.0.0.200:8080 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> That’s it! Hello world from Nginx! You’ve successfully registered your first dynamic BIG-IP pool member with Consul, all codified with Terraform! Summary In this article we explored the power of service discovery with BIG-IP and Consul. We added Terraform to apply the workflow “as code” for an end-to-end solution. Check out the resources below to dive deeper into this integration, and stay tuned for more awesome integrations with F5 and Hashicorp! References F5 HashiCorp Terraform Consul Service Discovery Webinar HashiCorp Consul with F5 BIG-IP Learn Guide F5 BIG-IP Docs for Service Discovery Using Hashicorp Consul F5 provider for Terraform Composing AS3 DeclarationsF5 XC articles published in the Technical Article section lately March 7 , 2023
Here is a list of the F5 XC articles that were published lately on DevCentral in the Technical Articles section. If you find them useful, please give a Kudo. We appreciate it and we know the author would as well. F5 Hybrid Security Architectures (Part 1 - F5's Distributed Cloud WAF and BIG-IP Advanced WAF) F5 Hybrid Security Architectures (Part 2 - F5's Distributed Cloud WAF and NGINX App Protect WAF) End-to-End Fraud and Risk Detection with F5 Distributed Cloud Silverline DDoS capabilities are now available in F5 Distributed Cloud Using F5 Distributed Cloud AppStack & CE Site Survivability Easily Protect Your Applications from DDoS with F5 Distributed Cloud DDoS Auto-Mitigation Mitigation of OWASP API6: 2019 Mass Assignment vulnerability using F5 Distributed Cloud Platform Overview of Trusted Client IP Headers in F5 Distributed Cloud Platform Demo Guide & Video Series for F5 Distributed Cloud Network Connect (Multi-Cloud Networking) Prevention of OWASP API Security API2:2019 Broken Authentication using F5 Distributed Cloud Platform Mitigating OWASP Web App Top 10 2021 : A08-Software and Data Integrity Failures using F5 XC Platform Egress control for Kubernetes using F5 Distributed Cloud Services Comprehensive solution for OWASP Web App A09:2021 Security Logging & Monitoring Failures from F5 XC How To Protect Your Applications from Cross Site Request Forgery (CSRF) with F5 Distributed Cloud Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDK Deploy High-Availability and Latency-sensitive workloads with F5 Distributed Cloud Mitigation of OWASP Web Application Top 10 2021 A04:2021-Insecure Design using F5 XC platformF5 XC articles and videos published on DevCentral in the Technical Article lately - Sept-28-22
Here’s a list of F5 XC articles that were published on DevCentral in the Technical Article section lately. If you find them useful, give a Kudo, we’d appreciate it and we know the author would appreciate it too. F5 Distributed Cloud Web App and API Protection hybrid architecture for DevSecOps F5 Distributed Cloud WAF AI/ML Model to Suppress False Positives Introduction to OWASP API Security and F5 Distributed Cloud Web Application and API Protection Mitigation of OWASP TOP 10 A05:2021 Security Misconfiguration using F5 Distributed Cloud WAAP Mitigating OWASP API Security Top 10 API8:2019 Injection flaws using F5 Distributed Cloud WAAP Using a Kubernetes ServiceAccount for Service Discovery with F5 Distributed Cloud Services Per-app failover for Kubernetes-based services using F5 Distributed Cloud Services Protect an application exposed on Internet with F5 XC WAAP Protect an application spread across several locations with F5 XC WAAP and Multi-Cloud Networking Protect an application on-premises or in the cloud with F5 XC WAAP Customer Edge F5 Distributed Cloud Content Delivery Network: an overview and what's new Getting started with the F5 Distributed Cloud Web App and API Protection Demo Guide Part 1Welcome to the F5 XC Community User Group
Welcome to our new virtual community group within the F5 DevCentral. We want to build great products for you and you great solutions for your users. We cannot do that without discussion and partnership. We cannot do that unless we do it together. Please engage with us and each other as part of this open community. What is DevCentral? An online community (started in 2004 and 100% run by the F5 DevCentral team) for technical peers dedicated to learning, exchanging ideas, and solving problems together. Your access to the Distributed Cloud User Group also gives you access to the rest of DevCentral. We encourage you to check it out. What is the Distributed Cloud User Group? A public exclusive hub within the DevCentral community where you all can congregate and connect with your peers and the F5 XC team. This community group was created to ease knowledge-sharing and communication. To supply a frictionless forum to share and receive information that is critical to us all. Here customers and F5 employees alike can teach and share their best practices and learn from each other's experiences. To help us all understand the ins and outs of solutions and to gain the most value from them. Within the group you can: Start a new discussion [Forum] You can post anything (questions, observations, comments, etc.). Want to talk about Distributed Cloud, Security, WAAP (Web App and API) Protection), networking, CDN (Content Delivery Network), DDoS (Distributed Denial of Service), DNS (Domain Name System), application management services across public/private cloud, network edge compute or any other related topics? Ask questions about a current blog post, give advice on a new workaround, or get help from your peers with something? Use this type of post to do so. Feel free to give people kudos for posts, ask questions, and share comments on them too. Suggest an idea [Suggestions] No community is effective without conversation. Suggestions posts are our venue for building input together. Here you can float ideas to be hardened by the constructive input of your peers and driven to a resolution with us. We probably can’t do everything under the sun, but this will really help us hear your voices, coordinate, and prioritize. Interact with your peers Note: Please do not use the group to request product support. Instead log into your F5 XC Account. If you do not have an account, see Create an Account.F5 Distributed Cloud Services Simulator
You can explore F5 Distributed Cloud Services via the F5 interactive demo in the F5 Simulator. These interactive demos put you in the driver’s seat via a simulated GUI and command line interfaces. The F5XC simulators that at are currently available at the F5 Distributed Cloud Services Simulator are: F5 Distributed Cloud WAAP. Explore how quickly you can deploy robust app protection for your apps with Distributed Cloud WAAP. F5 Distributed Cloud Bot Defense. Explore how F5 Distributed Cloud provides robust protection against automated attacks and malicious Bots. F5 Distributed Cloud DDoS Mitigation. Explore the robust and rich mitigation capabilities for Layer 7 Denial of Service (DoS) and Layer 3/4 Distributed DoS attacks using Fast Access Control List (ACL) capabilities of the F5 Distributed Cloud. Multi Cloud Transit Gateway. Securely interconnect multiple clouds with low-latency backbone transit using F5 Distributed Cloud Multi-Cloud Transit Gateway. Multi-cluster app mesh. Securely connect and manage multi-cloud networking of multiple Kubernetes (K8s) clusters with Layer 7 networking via HTTP Load Balancer. Multi-Cloud Networking: Cloud-to-Cloud via HTTP Load Balancer. Connect seamlessly and secure applications between multiple cloud networks using the F5 Distributed Cloud Platform. Multi-cluster app mesh. Securely connect and manage multi-cloud networking of multiple Kubernetes (K8s) clusters with Layer 7 networking via HTTP Load Balancer. Multi-Cloud Networking: Cloud-to-Cloud via HTTP Load Balancer. Connect seamlessly and secure applications between multiple cloud networks using the F5 Distributed Cloud Platform. Multi-Cloud Networking: Cloud-to-Cloud via Sites. Connect seamlessly and secure applications between multiple cloud networks. Multi-Cloud Networking Brownfield: Cloud-to-Cloud via Sites. Connect seamlessly and secure applications between multiple cloud networks with existing virtual networks. Cluster to cluster AWS Azure HTTP Load Balancer. Layer 7 (HTTP) connectivity of Kubernetes clusters in two clouds: AWS EKS and Azure AKS with service discovery. Cluster to cluster AWS Azure TCP Load Balancer. Layer 4 (TCP) connectivity of Kubernetes clusters in two clouds: AWS EKS and Azure AKS with service discovery. Deliver modern apps at the edge (CLI with kubectl). Use Kubectl in a Command Line Interface (CLI) to deploy your distributed apps on the F5 Global Network for increased performance, faster time-to-market, and global availability. Deliver modern apps at the edge (via Cloud Console). Improve time-to-market, performance, and global availability of your distributed apps on the F5 Global Network. Simulation via F5 Distributed Cloud Console
