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

Updating an Auto-Scaled BIG-IP VE WAF in AWS

Update servers while continuing to process application traffic.

Recently we've been showing how to deploy BIG-IP (and F5 WAF) in various clouds like Azure and AWS.

Today, we’ll take a look at how to update an AWS auto-scaled BIG-IP VEweb application firewall (WAF) that was initially created by using this F5 github template. This solution implements auto-scaling of BIG-IP Virtual Edition (VE) Web Application Firewall (WAF) systems in Amazon Web Services. The BIG-IP VEs have the Local Traffic Manager (LTM) and Application Security Manager (ASM) modules enabled to provide advanced traffic management and web application security functionality. As traffic increases or decreases, the number of BIG-IP VE WAF instances automatically increases or decreases accordingly.

Prerequisites:

• BIG-IP VE version 13.0.0
• You created your WAF using the F5 Cloud Formation Template or CFT from Github.

So, let’s assume you used the CFT to create a BIG-IP WAF in front of your application servers…and your business is so successful that you need to be able to process more traffic. You do not need to tear down your deployment and start over – you can make changes to your current deployment while the WAF is still running and protecting your environment.

For this article, a few examples of things you can change include increasing the throughput limit. For instance, When you first configured the WAF, you choose a specific throughput limit for BIG-IP. You can update that. You may also have selected a smaller AWS instance size and now want to choose a larger AWS instance type and add more CPU. Or, you may have set up your auto-scaling group to launch a maximum of two instances and now you want to be able to update the auto-scaling group attributes and add three.

This is all possible so let’s check it out.

The first thing we want to do is connect to one of the BIG-IP VE instances and save the latest configuration. We open putty, login and run the TMSH command (save /sys ucs /var/tmp/original.ucs) to save the UCS config file.

Then we use WinSCP to copy the UCS files to the desktop. You can use whatever application you like and copy the file wherever you like as this is just a temporary location.

Once that’s done, open the AWS Management Console and go to the S3 bucket. This bucket was created when you first deployed the CFT and locate yours.

When you find your file, click it and then click the Backup folder.

Once there, now upload the UCS file into that folder.

The USC is now in the folder.

The last step is to redeploy the CFT and change the selected options. From the main AWS Management Console, click CloudFormation, select your Stack and under Actions, click Update Stack.

Next, you can see the template we originally deployed and to update, click Next.

Scroll down the page to Instance Configuration to change the instance type size.

Right under that is Maximum Throughput to update the throughput limit.

And a little further down under Auto Scaling Configuration is where you can update the max number of instances. When done click Next at the bottom of the page.

It’ll ask you to review and confirm the changes. Click Update.

You can watch the progress and if your current BIG-IP VE instance is actively processing traffic, it will remain active until the new instance is ready.  Give it a little time to ensure the new instance is up and added to the auto scaling group before we terminate the other instance.

When it is done, we’ll confirm a few things.

Go to the EC2 Dashboard and check the running instances. We can see the old instance is terminated and the new instance is now available. You can also check the instance size and within the auto scaling group you can see the new maximum for number of instances.

And we’re deployed.

You can follow this same workflow to update other attributes of your F5 WAF. This allows you to update your servers while continuing to process traffic.

Thanks to our TechPubs group, you can also watch the video demo.

ps

Related:

• Deploy BIG-IP VE in AWS
• Deploy BIG-IP VE in Microsoft Azure Using an ARM Template
• Deploying F5’s Web Application Firewall in Microsoft Azure Security Center

Deploy BIG-IP VE in Microsoft Azure Using an ARM Template

Azure Resource Manager (ARM) templates allow you to repeatedly deploy applications with confidence. The resources are deployed in a consistent state and you can easily manage and visualize resources for your application.

ARM templates take the guesswork out of creating repeatable applications and environments. Deploy and deploy again, consistently.

Let’s walk through how to deploy a simple, single-NIC configuration of BIG-IP VE in Microsoft Azure using an ARM template.


First, go to the F5 Networks Github site where we keep our supported templates. There are other community-based templates at www.github.com/f5devcentral if needed but for F5 supported templates, go to the F5 Networks site. 

To view Azure templates, click f5-azure-arm-templates. In that folder you’ll see experimental and right under that is supported (the one you want). 

Then click on the standalone folder and then the 1nic folder, which is the simplest deployment. 

And as you scroll through and review the ‘Read Me,’ you’ll see the Deploy to Azure button under Installation. Select either Bring Your Own License (BYOL) or Pay As You Go (PAYG), depending on your situation. 

This will launch the Azure Portal and the only thing you’ll really need is a license key if you chose BYOL. Then simply fill out the template.

In this case, we’re going to use an existing resource group that already contains an application. 

Important: In the Settings section under Admin UN/PW, enter the credentials you want to use to log in to BIG-IP VE. The DNS Label (where you see REQUIRED) will be used to access your BIG-IP VE, for example, if you enter mybigip, the address will be something like  ‘mybigip.westus.cloudapp.azure.com.’ Give the Instance Name something familiar for easy finding. 

There are different Azure Instance Types, which determine CPU and memory for your VM, and F5 licensing (Good/Better/Best), which determines the BIG-IP modules you can deploy. Then, if needed, enter your BYOL license key.

In addition, to be more secure, you should enter a range of IP addresses on your network in the Restricted Src Addresses field so it’s locked to your address range. This setting determines who gets access to the BIG-IP instance in Azure, so you’ll want to lock it down.

After the tag values, agree to the terms and conditions and click Purchase. 

Next, you can monitor progress on the deploy status. Keep hitting refresh and you’ll start seeing resources getting populated along with the top blue ‘Deploying’ indicator. When the Deploying bar disappears, you know you’re done. 

Once complete, you get the notification that the BIG-IP VE was deployed successfully. Next, we’ll navigate to the resource group we selected at the top and then the security group for the BIG-IP. 

You can see that within the security rules we’ve allowed ports 443 (HTTPS) and 22 (SSH). 22 allows access to the management port; this is the way we’d connect to the BIG-IP to configure and administer.

 Going back to the resources, the BIG-IP itself is listed at the top.

Here you would enter the Azure credentials you specified in the template.

And that’s all there is to it. Now you can configure your virtual servers, pool, profiles and anything you’d normally do on BIG-IP VE for your unique requirements.

Thanks to Suzanne Selhorn for the basis of this article and catch a video demo here.

ps

Related:

• Azure on DevCentral
• Azure Setup Guide
• Enabling Azure Active Directory Tenant Restrictions with F5
• Securing your applications with F5 Virtual Editions in Microsoft Azure