How to Set up F5 Application Connector

Last week we covered the basic overview of Application Connector and this week we’ll look at how to set it up.

Settle in, this is detailed. 😊

F5 Application Connector is made up of two components: The Proxy and the Service Center. 

Step one is to set up the Service Center on BIG-IP.

A brief overview of the Service Center steps:

• Download Service Center template (rpm) file
• Provision iRules LX
• Enable iApps LX
• Install and deploy the Service Center

First, let's go to the F5.Downloads.com site and download the template that we'll use to deploy the Service Center. It's an RPM file.

Now we’re going to log into the BIG-IP and under System Resource Provisioning>Provision, set iRules LX to at least nominal.

Now we're going to connect to the BIG-IP using SSH - in this example we’re using putty - and you're going to run this command to enable iApps LX.

Now back to the config utility, we're going to click iApps>Package Management LX and if you don't see this menu you're going to need to restart the BIG-IP and then you'll see it. Now import the RPM file that you downloaded and then upload it.

When it's done you go to Application Services>Applications LX. Now we're going to select the Application Connector Template...

...and here is the Service Center.

We’re going to scroll to the bottom and add an application name and then save it.

Now we're going to select the application and click Deploy. The ball next to the name should turn green.

Now on to Step 2 - Setting up the Proxy.

You can do this on a small Linux instance that's running in the cloud in the same virtual network as your application servers.

Here are the steps for The Proxy:

• Download and deploy the Docker container file
• Create virtual server for Proxy traffic
• Add virtual server in the Service Center
• Add virtual server in the Proxy
• Authorize the Proxy in the Service Center

Start by downloading the Docker container from downloads.f5.com. It's the one with the .tgz file extension and copy this tgz file to your proxy instance.

We’re running Windows and using WinSCP so we’ll just copy it from our local machine over to the proxy instance.

Now back on the proxy instance on the Linux instance, we’re going to load the file and run a command to deploy the Docker container. If you look at the command a little more closely you'll see that we need to tell it apart, which in this case we’re using port 8090 and we’ll give it a username and password.

Again, in the setup guide you'll find all the details on all the parameters that you can use in this command.

Now we can see that the deployment was successful and it's running.

We go back to the BIG-IP and create a Virtual Server so that BIG-IP can accept incoming traffic from the proxy. This has to be on port 443 and for testing we're going to use the default client SSL profile.

In the Service Center, we're going to add the Virtual Server like you're going to select it. Click Config Proxy Virtual Server and then pick the virtual server and Save.

If we go back and look at the Virtual Server, you can see that has an iRule associated with it. That's how you know it was successful.

Now we’ll going to log into the Proxy with the port we specified and if your Proxy is in the cloud, it is make sure that you have the security rules so that this port is open. Again, in this case we used port 8090. We login with the username and password that we gave it and then in the Service Center connections area we’re going to add the Proxy virtual servers’ public IP address.

One last step is going to go back into the Service Center to authorize the Proxy and now you can see the Proxy in here.

Now on to the final step of adding your cloud nodes.

Here are the steps for The Cloud Nodes:

• Create pool and virtual server for application traffic
• Add the virtual server in the Service Center
• Create AWS IAM role
• Add node to the pool

On the BIG-IP, we’re going to create a pool and select one of these application connector monitors.

For now, the pool is empty and we create a virtual server for the application traffic, pointing to that pool.

Now we go into the Service Center and we tell it. ‘hey this is my virtual server for application traffic.’

To automatically add notes to the Proxy - in the AWS example – we’re going to create an IAM role...

...and then associate it with the Proxy instance.

And then we’re going to need to restart the Proxy and now we can go into the Proxy and see that I was authenticated by AWS.

And there are the nodes! The list is showing both the Proxy instance and the application servers but they're all automatically published at BIG-IP.

If we go back to BIG-IP, we can see the nodes in the Service Center.

Then we can go to the pool and we can choose them from a list. They're displayed here but it's important to know that these nodes are not exposed to the Internet and it's as if the nodes are local to the BIG-IP for more details see

Congrats! You’ve configured and deployed F5’s Application Connector. You can watch the step through video here.

ps

Related:

• Application Connector Overview

Automatically Update your BIG-IP Pool Using the Service Discovery iApp

Let’s look at how to automatically add members to your BIG-IP pool by using the Service Discovery iApp. Whenever you deploy a BIG-IP Virtual Edition by using one of the templates on the F5 Github site, this iApp is installed on the BIG-IP.

The idea behind this iApp is you assign a tag to a virtual machine in the cloud and then BIG-IP automatically discovers it and adds it to the pool. By tagging instances in AWS and Azure, and configuring the iApp, the pool is updated based on an interval you specify. This is especially helpful if you auto-scale your application servers because they are then automatically added and removed.

Today, we’ll look how to do this in Azure but you can also do this in AWS.

First, we’re going to add a tag to the application sever in Azure. You can assign the tag to either the virtual machine or to the NIC. For auto-scaling you’d tag the scale set. This can we’ll simply add it to the virtual machine.

When you click through the virtual machine, on the left you’ll get the ‘Tags’ option.

This entry can be any name/value pair you want and for this we’ll use ‘mytag’ and ‘addme.’

And we’ll click Save.

 For this exercise, we have two application servers in the resource group and already added the tags for that one. So at this point, we’re ready to get into the BIG-IP and configure the iApp.

Once in, go to Application Services>Applications>Create.

Next, we give it a name and choose f5_service_discovery from the list.

Scroll down the same page and fill out the open fields. Under Cloud Provider, we select Azure. Depending on your provider, there are additional questions. Add the Azure resource group and the Subscription ID. The next 3 fields (for the Azure selection) are security related: Tenant ID, Client ID and Service Principal Secret. Rather than using your own credentials to create and modify resources in Azure, you can create an Azure Active Directory application and assign permissions to that. Details are included on the Github ReadMe or the Azure documentation about service Principal.

Under the Pool area, is where you enter the name/value pair that we used for the tags in Azure. We leave the rest default. In this instance, you may notice the update interval at 60 seconds. By default, 60 seconds is the interval that BIG-IP will query Azure to see if there is a resource with the tags you specified. Under Application Health, select ‘http’ as the health monitor. Click Finished.

When complete, we can see we got a pool with two active members in it.

If you take the tags off one of the instances, it’ll leave the pool. Of note however, there must be two members in the pool before you remove tags from an instance. If you remove the tags from all the application servers, the pool will not be updated. BIG-IP must see at least one set of tags to update the pool because it doesn’t want to leave you with an empty pool.

Here’s the before and after of removing a tag.

One final note. This example configuration has the BIG-IP in one resource group and the application servers in another resource group but they are all on the same Vnet. If you have separate networks in Azure, you’ll need to create a peering so they can communicate. Similarly, in AWS, you need to make sure the networking is set up so the BIG-IP can see the application servers. But, once the initial set up is working, there’s no manual intervention required.

You can use the Service Discovery method to add and remove application servers all day long without having to manually update the BIG-IP. Again, and as always, thanks to our Technical Communications team for the great material and watch the video demo here.

ps

Related:

• Onboarding F5 in Cloud Part 2 - Service Discovery
• Deploy the Service Discovery iApp on a BigIP Cluster across two Availability Zones

Create a BIG-IP HA Pair in Azure

Use an Azure ARM template to create a high availability (active-standby) pair of BIG-IP Virtual Edition instances in Microsoft Azure. When one BIG-IP VE goes standby, the other becomes active, the virtual server address is reassigned from one external NIC to another.

Today, let’s walk through how to create a high availability pair of BIG-IP VE instances in Microsoft Azure. When we’re done, we’ll have an active-standby pair of BIG-IP VEs.

To start, go to the F5 Networks Github repository.

Click F5-azure-arm-templates. Then go to Supported>ha-avset and there are two options. You can deploy into an existing stack when you already have your subnets and existing IP addresses defined but to see how it works, let’s deploy a new stack.

Click new stack and scroll down to the Deploy button. If you have a trial or production license from F5, you can use the BYOL option but in this case, we’re going to choose the PAYG option.

Click Deploy and the template opens in the Azure portal. Now we simply fill out the fields. We’ll create a new Resource Group and set a password for the BIG-IP VEs.

When you get to the questions:

The DNS label is used as part of the URL.

Instance Name is just the name of the VM in Azure.

Instance Type determines how much memory and CPU you’ll have.

Image Name determines how many BIG-IP modules you can run (and you can choose the latest BIG-IP version).

Licensed Bandwidth determines the maximum throughput of the traffic going through BIG-IP.
Select the Number of External IP addresses (we’ll start with one but can add more later). For instance, if you plan on running more than one application behind the BIG-IP, then you’ll need the appropriate external IP addresses.

Vnet Address Prefix is for the address ranges of you subnets (we’ll leave at default).

The next 3 fields (Tenant ID, Client ID, Service Principal Secret) have to do with security. Rather than using your own credentials to modify resources in Azure, you can create an Active Directory application and assign permissions to it.

The last two fields also go together. Managed Routes let you route traffic from other external networks through the BIG-IPs. The Route Table Tag means that anytime this tag is found in the route table, routes that have this destination are updated so that the next hop is the IP address of the active BIG-IP VE. This is useful if you want all outbound traffic to go through the BIG-IP or if you want to send traffic from a bunch of different Vnets through the BIG-IP.

We’ll leave the rest as default but the Restricted Src Address is good way to put IP addresses on my network – the ones that are allowed to connect to the BIG-IP.

We’ll agree to the terms and click Purchase.

We’re redirected to the Dashboard with the Deployment in Progress indicator. This takes about 15 minutes.

Once finished we’ll go check all the resources in the Resource Group.

Let’s find out where the virtual server address is located since this is associated with one of the external NICs, which have ‘ext’ in the name. Click the one you want.

Then click IP Configuration under Settings.

When you look at the IP Configuration for these NICs, whenever the NIC has two IP addresses that’s the NIC for the active BIG-IP. The Primary IP address is the BIG-IP Self IP and the Secondary IP is the virtual server address.

If we look at the other external NIC we’ll see that it only has one Self IP and that’s the Primary and it doesn’t have the Secondary virtual server address. The virtual server address is assigned to the active BIG-IP.

When we force the active BIG-IP to standby, the virtual server address is reassigned from one NIC to the other.

To see this, we’ll log into the BIG-IPs and on the active BIG-IP, we’ll click Force to Standby and the other BIG-IP becomes Active.

When we go back to Azure, we can see that the virtual server IP is no longer associated with the external NIC.

And if we wait a few minutes, we’ll see that the address is now associated with the other NIC.

Basically, how BIG-IP HA works in the Azure cloud is by reassigning the virtual server address from one BIG-IP to another. Thanks to our TechPubs group and check out the demo video.

ps