Getting Started with BIG-IP Next: Migrating an Application Workload
So far in this article series, the focus has been completely on the operational readiness of BIG-IP Next as a system. In this article, I'll walk through migrating an application currently supported by my classic BIG-IP running TMOS version 15.1.x. The application is just a simple instance of an NGINX web server fronted on LTM with basic load balancing, TLS offloading, and a basic WAF policy. There are a lot of screenshots in this article, which might seem overwhelming. Doing your own walkthrough, however, will put your mind at ease; it actually moves pretty quickly in realtime.
Existing Application Workload on TMOS
We'll start with the GUI representation of the application workload. It is secured with TLS, which is offloaded at the BIG-IP with a clientssl profile and not re-encrypted to the server. There are custom TCP and HTTP profiles defined as well as the aforementioned custom clientssl profile. Snat automap is enabled, and a specific VLAN is configured to allow connections. On the security tab, an application security policy is enabled, and the log illegal requests log profile is enabled as well. Finally, under resources, the default pool is defined and a policy is in place to map requests to the applied security policy.
On the CLI, that virtual server along with all the other referenced BIG-IP objects are defined in the tmsh version of that configuration.
ltm virtual nginx-vip-tls {
destination 172.16.101.50:https
ip-protocol tcp
mask 255.255.255.255
policies {
asm_auto_l7_policy__nginx-vip-tls { }
}
pool nginx-pool
profiles {
ASM_testpol { }
cssl.TestSuite {
context clientside
}
customHTTP { }
customTCP { }
websecurity { }
}
security-log-profiles {
"Log illegal requests"
}
source-address-translation {
type automap
}
vlans {
vlan.br1
}
vlans-enabled
}
ltm policy asm_auto_l7_policy__nginx-vip-tls {
controls { asm }
last-modified 2024-03-20:13:25:13
requires { http }
rules {
default {
actions {
1 {
asm
enable
policy /Common/testpol
}
}
ordinal 1
}
}
status legacy
strategy first-match
}
ltm pool nginx-pool {
members {
172.16.102.5:http {
address 172.16.102.5
session monitor-enabled
state up
}
}
monitor http
}
security bot-defense asm-profile ASM_testpol {
app-service none
clientside-in-use disabled
flags 0
inject-javascript disabled
persistent-data-validity-period 0
send-brute-force-challenge disabled
send-javascript-challenge disabled
send-javascript-efoxy disabled
send-javascript-fingerprint disabled
}
ltm profile client-ssl cssl.TestSuite {
app-service none
cert-key-chain {
default {
cert default.crt
key default.key
}
}
cipher-group cg_TLSv1.3
ciphers none
defaults-from clientssl
inherit-ca-certkeychain true
inherit-certkeychain true
options { dont-insert-empty-fragments }
}
ltm cipher group cg_TLSv1.3 {
allow {
cr_TLSv1.3 { }
}
}
ltm cipher rule cr_TLSv1.3 {
cipher TLSv1_3
dh-groups DEFAULT
signature-algorithms DEFAULT
}
ltm profile http customHTTP {
app-service none
defaults-from http
enforcement {
known-methods { PATCH DELETE GET POST PUT }
max-header-count 32
max-header-size 16384
rfc-compliance enabled
}
hsts {
mode enabled
}
insert-xforwarded-for enabled
proxy-type reverse
}
ltm profile tcp customTCP {
app-service none
congestion-control bbr
defaults-from f5-tcp-progressive
idle-timeout 600
ip-tos-to-client pass-through
keep-alive-interval 2100
pkt-loss-ignore-burst 3
pkt-loss-ignore-rate 10
proxy-options enabled
}
ltm profile web-security websecurity { }
You can see that I have some non-standard options in some of that configuration, such as specifying the congestion-control algorithm algorithm in the TCP profile, enabling HSTS in the HTTP profile, and setting cipher rules and groups for use in my SSL profile. Now that we have an idea of the workload we're going to migrate, let's create a UCS of the system for use in the migration. If you are already comfortable with this part on classic BIG-IP systems, you can skip down to the next section header. First, login to your classic BIG-IP and navigate to System->Archives and click Create.
Give it a name and click Finished. I named mine next-migration.
Click OK after the UCS has been generated and saved.
In the archive list, click the name of the UCS you created.
Click the Download button.
Migrating the Workload in Central Manager
Upload UCS and Analyze the Workloads
Armed with your UCS, login to Central Manager and on the welcome screen, click Go to Application Workspace.
If you have not added any applications yet, you'll see a screen like this with a Start Adding Apps button.
If you already have something defined, you'll see a list of applications. Click the + Add Application button instead.
On this screen, we'll bypass creating a new application service and select New Migration.
Name your session as you'll be able to come back to it to migrate other applications later if your intent is to just migrate a single application for now (as is the case with this walkthrough.) I added a description but it is not necessary. Click Next.
Here you'll select your UCS archive and group your application services by IP addresses OR by virtual server. I stuck with the recommended default. Click Next.
Your UCS will now upload and then Central Manager will analyze and group the package. An enhanced version of the JOURNEYS tool available in the f5devcentral organization on GitHub is used here.
Select Add Application.
Application 5 is the one we are interested in analyzing and migrating for this walkthrough, so I selected that one. Notice in the status column the applications that have warnings, and that ours is one of them. Hovering over the triangle icon it indicates the app can be migrated, but without some of the functionality from our classic iteration of this workload. Next, click Analyze at the top right so we can see what can't be migrated.
In the Configuration Analyzer screen, there are 3 files with areas of concern. First, that the websecurity profile is not supported. This is ok, the mechanisms to support attaching policies in Next are slightly different.
Next from what was the bigip_base.conf file, it's not supporting the vlan as defined. This is included in the migration analysis as the vlans are specified in my virtual server, but the mechanisms for doing so are different in Next. (Note: I don't fully grok this change yet. This article will be updated once I have confidence I'm communicating the functionality accurately.)
And finally, from the bigip.conf file, there are few areas of concern, shown in the animated gif below. Standalone bot-defense is not a thing in BIG-IP Next, it's part of the overall policy, so that object is not supported. Also not supported yet are local traffic policies and cipher groups. Note that even though these objects aren't supported, I can still migrate the application, and it should "just work." I guess we'll see later in this article, right? :)
At this point, select the </> Preview AS3 and copy that to a file. We'll compare that to the classic BIG-IP version of AS3 in a later section.
Add an Application Service
After closing the AS3 preview, select the application again and click Add.
Click Next
For this particular application, we need a couple shared objects: the certificate/key pair for the SSL profile and the WAF policy. Click Import.
After those are imported, click the numbered icon (2 in my case) under the Shared Objects column, which will open a listing of those objects that you imported.
Review the objects (optional) and click Exit.
At this step, if your existing application migration is accurate to the object level, you can deploy to an instance directly. But I have some changes to make to the IPs so I'm going to deploy as a draft instead.
After seeing that my deployment was successfully deployed as a draft in Central Manager, I click Finish.
Update the Draft and Deploy
In My Application Services, click the application we just migrated.
Here we can tweak the AS3 declaration. I need to update the vlan as my vlan.br1 from my TMOS BIG-IP system is not defined on my Next instance. I also have different client/server address ranges, so I updated the virtual server and pool member addresses as well. You will likely want to change your application name from the generically-migrated "application_5" but I left it as is for this exercise. Once I completed those changes, I clicked Save & Deploy.
I was then asked to select an instance to deploy the application server. I only have one currently, so I selected that.
This failed due to my vlan configuration. As I mentioned during the migration process, I don't yet fully grok the vlan referencing requirements in Next, so this is a point for me to be educated on and follow up with updates here in this article.
Instead, I removed the allowVlans attributed altogether (after another attempt) and then clicked Save & Deploy again and (after re-selecting the deploy location as shown above) found success.
Clicking on the application, you get a visual representation of the application objects.
Testing and Observing the Migrated Application
Now that we have an honest to goodness deployed application on BIG-IP Next (WOO HOO!!) let's test it to make sure things are working as expected. I have a ubuntu test server with connections into my external and internal traffic networks for my Next instance so it can be the client (curl) and the server (NGINX). First, a request that should work:
curl -sk https://10.0.2.50/
<!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>Huzzah! That's a successful test. I ran a simple bash script with repetitive wget calls to push just a little load to populate the instance traffic graph:
Now let's test the WAF policy by sending some nefarious traffic:
curl -sk --config requests.txt https://10.0.2.50/
<html>
<head>
<title>Request Rejected</title>
</head>
<body>The requested URL was rejected. Please consult with your administrator.<br><br>
Your support ID is: 16177875355615369771<br><br>
<a href='javascript:history.back();'>[Go Back]</a>
</body>
</html>Sweet! Exactly what we wanted to see. Now let's take a look at the WAF Dashboard for blocks.
Ok, that's a wrap on migrating the application. Functionally, it is a success!
Comparing BIG-IP classic AS3 with BIG-IP Next AS3
If you are moving from classic BIG-IP configuration to BIG-IP Next, you likely will not have any context for comparing AS3 and so you might miss that some of the features you configured in classic are not present in Next. Some of those features aren't there at all yet, and some of them are just not exposed yet. Under the hood, TMM is still TMM with BIG-IP Next, and all of that core functionality is there, it's just a matter of prioritizing what gets exposed and tested and ready to support. Despite a myriad of features in classic BIG-IP, a surprising number of features went either unused or under-used and maintaining support for those will depend on future use requirements.
Anyway, one way to build context for AS3 is to use Visual Studio Code and the F5 Extension to take your classic configuration and convert that to AS3 declarations with the AS3 configuration converter. In this section, I'm going to look at a few snippets to compare between classic and Next.
Declaration Header
The header for classic is a essentially a wrapper (lines 2-4) that isn't necessary in Next at all. That's because in classic, AS3 is not the only declaration class, you also have declarative onboarding and telemetry streaming.
Classic:
{
"$schema": "https://raw.githubusercontent.com/F5Networks/f5-appsvcs-extension/master/schema/latest/as3-schema.json",
"class": "AS3",
"declaration": {
"class": "ADC",
"schemaVersion": "3.37.0",
"id": "urn:uuid:4339ea7d-094b-4950-b029-ac6344b03a2b",
"label": "Converted Declaration",
}
}Next:
{
"class": "ADC",
"schemaVersion": "3.0.0",
"id": "urn:uuid:715aa8d8-c2b0-4890-9e77-5f6131ee9efd",
"label": "Converted Declaration",
}Profiles
One thing to keep in mind with migration is that the migration assistant currently provides detailed analysis to the class level, not the class attribute level. This means that some of the attributes that are supported in classic that are not supported in Next will fly under the radar and be removed with no notification. There is work underway in this regard, but you'll need to evaluate each of your applications as you migrate and plan accordingly. For the app I migrated here, this was evident in the following profiles.
ClientSSL
Here, the cipher groups and rules from classic are not yet available, and the ability to establish only TLSv1.3 seems to not be configurable at this time.
Classic:
"cssl.TestSuite": {
"certificates": [
{
"certificate": "foo.acmelabs.com"
}
],
"cipherGroup": {
"use": "cg_TLSv1.3"
},
"class": "TLS_Server",
"tls1_0Enabled": true,
"tls1_1Enabled": true,
"tls1_2Enabled": true,
"tls1_3Enabled": true,
"singleUseDhEnabled": false,
"insertEmptyFragmentsEnabled": false
},Next:
"cssl.TestSuite": {
"authenticationFrequency": "one-time",
"certificates": [
{
"certificate": "/tenant87f7bd9913a51/application_5/foo.acmelabs.com"
}
],
"class": "TLS_Server"
},TCP
In the TCP profile, the most notable changes are the loss of QoS settings and the ability to select the congestion control algorithm.
Classic:
"customTCP": {
"congestionControl": "bbr",
"idleTimeout": 600,
"ipTosToClient": "pass-through",
"keepAliveInterval": 2100,
"pktLossIgnoreBurst": 3,
"pktLossIgnoreRate": 10,
"proxyOptions": true,
"class": "TCP_Profile"
}
Next:
"customTCP": {
"idleTimeout": 600,
"pktLossIgnoreBurst": 3,
"pktLossIgnoreRate": 10,
"proxyBufferHigh": 262144,
"proxyBufferLow": 196608,
"proxyOptions": true,
"sendBufferSize": 262144,
"class": "TCP_Profile"
},HTTP
In my HTTP profile, it seems I lost all my personally-selected options, such that I'd likely be fine with the default profile. Also, since I'm using the WAF, I can manage the allowed request methods there, and whereas I can't auto-insert strict transport security in the profile directly yet, I can manage that in an iRule as well, so I do have a path to workarounds for both cases.
Classic:
"customHTTP": {
"knownMethods": [
"PATCH",
"DELETE",
"GET",
"POST",
"PUT"
],
"maxHeaderCount": 32,
"maxHeaderSize": 16384,
"hstsInsert": true,
"xForwardedFor": true,
"proxyType": "reverse",
"class": "HTTP_Profile"
},Next:
"customHTTP": {
"requestChunking": "sustain",
"responseChunking": "sustain",
"class": "HTTP_Profile"
}
Final Thoughts
I point out the differences in my before and after to show a complete picture of the migration process. Some things changed, some went away, but the bottom line is I have a working application service.
Before working on this article, I've done a migration in a couple step-by-step controlled labs and have played with but not finished deploying a working, tested, functional application in my own lab. Don't make that same mistake. Get your classic configurations migrated ASAP even if only as a draft in Central Manager, so you can start to evaluate and analyze
- What work you have on your end to tweak and tune where features have changed
- Where you need to start engaging your account team to inquire about your MUST HAVE features that may or may not be scoped currently.
Next time out, we'll take a look at creating a net-new application service. Until then, stay active out there community and start digging into BIG-IP Next!
