Horizon View iApp - Big-IP 17.5
I have a client deploying an r4650 pair. The plan is for it to handle Exchange, LDAPS & Horizon View. I’m in the process of initial setup on the pair of boxes now. It’s been a long time since I've deployed Horizon View on F5. I see that the iApp is still maintained so yay! Question: is the current 1.5.9 version of the iApp supported in Big-IP 17.5? The KB article states 17.1 but the article hasn’t been updated in a while. F5 recommends the latest version of 17.5 but I don't want to hit any snags as we deploy. Thanks in advance, Matt
AS3 Limitations
Below are some limitations of AS3 as means of Automation. config deployment is locked down by Automation, no manual intervention possible for below use cases - incidents - new requirements/features need to wait for automation to be updated - Automation failures cause deployment to be stalled until automation is fixed - Operational issues, maybe require out-of-band changes outside of AS3 - Source of truth must be reconciled periodically with F5 device to check for config drift - 2 layers of failures during config deployment one is Automation and second is source of truth, therefore involves more troubleshooting effort - Reliance on an External Source of Truth management, non-native to F5 and not supported by F5 - AS3 is Less mature compared to iControl Rest, iControl Rest was introduced in TMOS 11.xBest Practice to Store AS3 State/Source of Truth ?
What is the best option to store AS3 state ? I have seen organisations using the below Terraform state files As repos on github/bitbuket NoSQL Databases S3 Storage on Amazon Which one of the above is scalable and best suited to store to AS3 state files ?
Unable to set 'Session Ticket' attribute in TLS_Server object using AS3
I am currently in the process of migrating our F5 config towards AS3. However, I am currently running into an issue while converting the 'Session Ticket' attribute of our clientssl profiles (TLS_Server in AS3) While the AS3 Schema reference allows to provide a sessionTickets attribute for TLS_CLIENT objects, there is no such option for TLS_Server objects that I am able to find. Does anybody know how to set this attribute for SERVER_TLS objects in AS3? Is it just not possible? Is there a different option I need to use with AS3? Thanks in advanceF5 Per applications AS3 Declarations via Terraform
F5 Per applications AS3 Declarations via Terraform. Good evening all, I would like to put together a proof of concept surrounding using Terraform (the clients preferred automation platform) to populate and manage AS3 declarations. I am attempting to follow the following F5 docs page in my lab, and it is not working as I would have expected. [https://clouddocs.f5.com/products/orchestration/terraform/latest/BIG-IP/per-app-as3.html#example2](https://clouddocs.f5.com/products/orchestration/terraform/latest/BIG-IP/per-app-as3.html#example2) I have two separate files such is suggested in the article. One with two applications (app1-2.json) that acts as the base line for the first push, then a second file (app3.json) with a third application that I would like to ADD to the existing AS3 deceleration leaving my F5 with 3 total applications. I have one file [main.tf](http://main.tf) that looks like the following: resource "bigip\_as3" "as3-example" { as3\_json = file("app1-2.json") tenant\_filter = var.tenant tenant\_name = "Tenant" } I use that [main.tf](http://main.tf) file to push the original app1-2 file to produce the initial declaration with two applications. Then, I edit that file to look like resource "bigip\_as3" "as3-example" { \# as3\_json = data.template\_file.init.rendered as3\_json = file("app3.json") tenant\_filter = var.tenant tenant\_name = "Tenant" } Since per-application declarations are enabled, I assumed editing this file and applying it would push the third application and leave the other two in tact. That is not the case. When I push this edited [main.tf](http://main.tf) file, it edits the existing declaration deleting app1 and app 2 and creating app3. Can anyone shed some light on how we are supposed to use Terraform in per application deployments? I feel like I have to be missing something silly.
F5 - AS3 - BIGIQ / BIGIP SchemaVersion Missunderstanding
Dear community, I was wondering about the AS3 version currently used in order to deploy my AS3 on my BIG-IP target through BIG-IQ. BIG-IQ should install this current AS3 version on F5 BIG-IP target when deploying AS3 declaration. Checking on my BIG-IQ, 3.44.0 curl -sk -H "Content-Type: application/json" -H "X-F5-Auth-Token: $TOKEN" -X GET "https://$BIGIQ/mgmt/shared/appsvcs/info" {"version":"3.44.0","release":"3","schemaCurrent":"3.44.0","schemaMinimum":"3.0.0"} Checking on my F5 BIG-IP, v 3.44.0 #pwd /var/config/rest/iapps/f5-appsvcs # cat version 3.44.0-3 My current AS3 declaration (I'm manually forcing schemaVersion) through BIG-IQ : { "class": "AS3", "action": "patch", "schemaVersion": "3.44.0", "patchBody": [ { "class": "ADC", "schemaVersion": "3.44.0", "target": { "address": "X.X.X.X" }, "op": "add", "path": "/Automation/APP_TEST_1.2.12.140_446", "value": { "class": "Application", "remark": "REFERENCE : NULL_REFERENCE_20241109215237", "schemaOverlay": "AS3-F5-HTTPS-PASSTHROUGH-lb-template-big-iq", .... etc } Application Deployment logs from my BIG-IQ : At the bottom : "schemaVersion": "3.12.0" I don't understand why it's using this older schemaVersion, it should use the current 3.44.0. Is there any policy on BIG-IQ that can enforce this weird behavior ? { "id": "autogen_a4c95a0f-13e3-4078-92c3-3a8e6ea6f10c", "class": "ADC", "controls": { "class": "Controls", "userAgent": "BIG-IQ/8.3 Configured by API" }, "Automation": { "class": "Tenant", "APP_TEST_1.2.12.140_446": { "class": "Application", "remark": "REFERENCE : NULL_REFERENCE_20241109215237", "template": "tcp", "serviceMain": { "pool": "/Automation/APP_TEST_1.2.12.140_446/HTTPS_443_pool", "class": "Service_TCP", "enable": true, "profileTCP": { "use": "/Automation/APP_TEST_1.2.12.140_446/HTTPS_443_tcp_profile" }, "virtualPort": 446, "virtualAddresses": [ "1.2.12.140" ], "persistenceMethods": [ "source-address" ], "profileAnalyticsTcp": { "use": "/Automation/APP_TEST_1.2.12.140_446/Analytics_TCP_Profile" } }, "HTTPS_443_pool": { "class": "Pool", "members": [ { "adminState": "enable", "shareNodes": true, "servicePort": 443, "serverAddresses": [ "1.2.12.13" ] } ], "monitors": [ { "use": "/Automation/APP_TEST_1.2.12.140_446/HTTPS_443_monitor" } ], "loadBalancingMode": "least-connections-member" }, "HTTPS_443_monitor": { "send": "GET /\r\n", "class": "Monitor", "receive": "none", "targetPort": 443, "monitorType": "http", "adaptiveWindow": 180, "adaptiveLimitMilliseconds": 1000, "adaptiveDivergencePercentage": 100 }, "Analytics_TCP_Profile": { "class": "Analytics_TCP_Profile", "collectCity": false, "collectRegion": true, "collectCountry": true, "collectNexthop": false, "collectPostCode": false, "collectContinent": true, "collectRemoteHostIp": false, "collectedByClientSide": true, "collectedByServerSide": true, "collectRemoteHostSubnet": true }, "HTTPS_443_tcp_profile": { "class": "TCP_Profile", "synMaxRetrans": 3, "finWaitTimeout": 5 } } }, "updateMode": "selective", "schemaVersion": "3.12.0" } Thanks in advance for your help !BIG-IP Next Automation: AS3 Basics
I need a little Mr. Miyagi right now to grab my face and intently look me in the eye and give me a "Concentrate! Focus power!" For those of you youngins' who don't know who that is, he's the OG Karate Kid mentor. Anyway, I have a thousand things I want to say about AS3 but in this article, I'll attempt to cut this down to a narrow BIG-IP Next-specific context to get you started. It helps that last December I did a five-part streaming series on AS3 in the BIG-IP classic context. If you haven't seen that, you have my blessing to stop right now, take some time to digest AS3 conceptually and practice against workloads and configurations in BIG-IP classic that you know and understand, before returning here to embrace all the newness of BIG-IP Next. AS3 is FOUNDATIONAL in BIG-IP Next In classic BIG-IP, you could edit the bigip.conf file directly, use tmsh commands, or iControlREST commands to imperatively create/modify/delete BIG-IP objects. With the exception of system configuration and shared configuration objects, this is not the case with BIG-IP Next. All application configuration is AS3 at its lowest state level. This doesn't mean you have to work primarily in AS3 configuration. If you utilize the migration utility in Central Manager, it will generate the AS3 necessary to get your apps up and running. Another option is to use the built-in http FAST template (we'll cover FAST in later articles) to build out an application from scratch in the GUI. But if you use features outside the purview of that template, or you need to edit your migration output, you'll need to work in the AS3 configuration declaration, even if just a little bit. Apples to Apples It's a fun card game, no? My family takes it to snarky absurd levels of sarcasm, to the point that when we play with "outsiders" we get lots of blank looks and stares as we're all rolling on the floor laughing. Oh well, to each his own. But we're here to talk about AS3, right? Well, in BIG-IP Next, there is a compatibility API for AS3, such that you can take a declaration from BIG-IP classic and as long as the features within that declaration are supported, it should "just work" via the Central Manager API. That's pretty cool, right? Let's start with a basic application declaration from the recent video posted by Mark_Dittmer exploring the API differences between classic and Next. { "class": "ADC", "schemaVersion": "3.0.0", "id": "generated-for-testing", "Tenant_1": { "class": "Tenant", "App_1": { "class": "Application", "Service_1": { "class": "Service_HTTP", "virtualAddresses": [ "10.0.0.1" ], "virtualPort": 80, "pool": "Pool_1" }, "Pool_1": { "class": "Pool", "members": [ { "servicePort": 80, "serverAddresses": [ "10.1.0.1", "10.1.0.2" ] } ] } } } } A simple VIP with a pool with two pool members. A toy config to be sure, but it is useful here to show the format (JSON) of an AS3 declaration and some of the schema as well. With the compatibility API, this same declaration can be posted to a classic BIG-IP like this: POST https://<BIG-IP IP Address>/mgmt/shared/appsvcs/declare Or a BIG-IP Next instance like this: POST https://<Central Manager IP Address>/api/v1/spaces/default/appsvcs/declare?target_address=<BIG-IP Next instance IP Address> For those already embracing AS3, this compatibility API in BIG-IP Next should make the transition easier. AS3 Workflow in BIG-IP Next With BIG-IP classic, you had to install the AS3 package (technically an iControl LX, or sometimes referenced as an iApps v2 package) onto each BIG-IP system you wanted to use the AS3 declarative configuration model on. Each BIG-IP was an island, and the configuration management of the overall system of BIG-IPs was reliant on an external system for source of truth. With BIG-IP Next, the Central Manager API has native AS3 support so there are no packages to install to prepare the environment. Also, Central Manager is the centralized AS3 interface for all Next instances. This has several benefits: A singular and centralized source of truth for your configuration management No external package management requirements Tremendous improvement in API performance management since most of the heavy lifting is offloaded from the instances and onto Central Manager and the control-plane functionality that remains on the instance is intentionally designed for API-first operations The general application deployment workflow introduced exclusively for Next, which I'll reference as the documents API, is twofold: Create an application service First, you create the application service on Central Manager. You can use the same JSON declaration from the section above here, only the API endpoint is different: POST https://<Central Manager IP Address>/api/v1/spaces/default/appsvcs/documents A successful transaction will result in an application service document on Central Manager. A couple notes on this at time of writing: Documents created through the API are not validated against the journeys migration tool that is available for use in the Central Manager GUI. Documents are not schema validated at the attribute level of classes, so whereas a class used in classic might be supported in Next, some of the attributes might not be. This means that whereas the document creation process can appear successful, the deployment will fail if classes and/or class attributes supported in classic BIG-IP are present in the AS3 declarations when an attempt to apply to an instance occurs. Deploy the application service Assuming, however, all your AS3 work is accurate to the Next-supported schema, you post the specified document by ID to the target BIG-IP Next instance, here as a JSON payload versus a query parameter on the compatibility API shown earlier. POST https://<Central Manager IP Address>/api/v1/spaces/default/appsvcs/documents/<Document ID>/deployments { "target": "<BIG-IP Next Instance IP Address>" } At this point, your service should be available to receive traffic on the instance it was deployed on. Next Up... Now that we have the theory in place, join me next time where we'll take a look at working with a couple application services through both approaches. Resources CM App Services Management AS3 Schema AS3 User Guide (classic, but useful) AS3 Reference Guide (classic, but useful) AS3 Foundations (streaming series)
