How I did It #2 - “Assigning Multiple Public IPs to an Azure-hosted BIG-IP”

As I mentioned in the previous post, this series, (“How I Did It”), we’ll take a customer request/challenge and implement a solution.  So, here’s the request:  “Can I deploy multiple applications behind the same F5 BIG-IP, (or BIG-IP cluster) in Azure?”

For the seasoned BIG-IP administrator this may seem trivial.  Historically, enterprise customers would use an F5 BIG-IP, (or pair of BIG-IPs) in the datacenter to publish several, if not all, of their Internet facing applications.  After all, a BIG-IP can certainly support multiple applications and well, …let’s just agree, the BIG-IP is not the cheapest tool in the shed.  Yep; took a little liberty with the metaphor.  However, there are some significant limitations within the Azure environment that makes a multi-app deployment somewhat challenging.

Ok, maybe a little more than “somewhat”.

Currently, you are limited to one public-facing IP, (VIP) per VM deployment.  What this means from an F5 BIG-IP perspective is you are limited to one public-facing virtual server, (per port) which greatly limits your deployment options.  For example, I want to deploy two separate Azure-hosted web applications behind a single BIG-IP VE.  What can I do? 

Well, I can publish both applications using the same public IP and unique ports, (see Figure A).  This is undesirable from and end-user perspective as it would require the user to specify the destination port number, (ex: https://app2.f5demo.net:444).

 

Another alternative is to use one virtual server for both applications, (see Figure B).  This would require and iRule to redirect incoming connections to the correct backend application pool based on the host header, (i.e. app1.f5demo.net & app2.f5demo.net).  A challenge with this approach, (aside from not scaling well) will come into play with SSL encrypted virtuals, (HTTPS).  Since you are limited to one client SSL profile per virtual server you will likely need to purchase either a SAN or wildcard certificate to accommodate multiple host names.

So with that said, let’s take a look at how I did it.

Consolidating While Scaling Out

Since its not currently possible to attach more than one public IP to a virtual machine instance,  I’ll make use of an Azure Load Balancer, (ALB) resource. 

An ALB resource can have up to five frontend IP configurations* , each with its own public IP.  All public IPs associated will be load balanced to the same backend pool of private IP address(es) on a specific port, (see example at right).

* It is possible to increase this number on a per request basis.

Of course, seeing as how I’m using a load balancing resource, might as well have it load balance across a pair of BIG-IPs.  Add in an Availability Set, and I have now scaled out my application with an active/active pair of BIG-IPs and provided an additional layer of HA to my application deployments. 

Side Note:  Check out the next post in this series where we tackle configuration synchronization and failover.

Unfortunately, there is no GUI method to initially configure and associate multiple public IPs on an ALB resource.  Rather than go through all the configuration steps and options, here’s a link to additional official guidance on configuring multiple IP addresses on an ALB resource. 

Alas dear readers, fear not though for I’m here to help.  The link below will trigger an ARM template deployment of an application infrastructure similar to Figure C at right.  While this may not fit your specific needs, it’s a good place to start.

 

The ARM template will help you deploy a multiple application infrastructure including:

  • Virtual Network with 2 subnets, (external & internal);
  • Storage account;
  • 1-2 BIG-IP instances, (BEST edition) and associated availability set; and
  • Azure Load Balancer, (ALB) resource with:
    • 1-5 Public IPs and associated ALB frontend IP configurations;
    • Inbound NAT rules for connecting to individual BIG-IPs via HTTPS and SSH;
    • Load Balancing rules, (two per ALB frontend) providing external access and port translation for both HTTP and HTTPS; and
    • Health monitor probes, (2-per public IP deployed).

Note:  You may need to accept the license agreement by deploying a BIG-IP out of the marketplace prior to running this template the first time.

Once the BIG-IPs are deployed and initially setup; its simply a matter of deploying applications.  A virtual server will be created for each application listening on the same IP address and unique port, (refer to Figure C).  In my example, I have created four virtual servers, (see below).

 

Additional Links

F5 Now Available in Microsoft AzureHow I did It - “Integrating Azure MFA with the BIG-IP”

Azure Load Balancer Overview

Get started creating an Internet facing load balancer in Resource Manager using PowerShell

Multiple VIPs per cloud service

Published Jun 03, 2016
Version 1.0

Was this article helpful?

5 Comments

  • Hi Greg. For second option you can use LTM Policy and match on value of HOST header. It's better than have one big complicated iRule in case you need to have tens or hundreds different customers since with Policy you can forward traffic to VS and each VS can have its iRules. You can also assign multiple certificates to the same VIP, but client will have to support SNI. That's what I've done in one of our AWS deployments.
  • I've also made scalable use of the following iRule for one VIP to many backend pools...

    when HTTP_REQUEST {
        set hostpool [string tolower [HTTP::host]]_pool
        pool $hostpool
    }
    

    You would need to add a catch or something to handle requests where $hostpool doesn't match a valid pool but that wouldn't be too cumbersome.

  • Nice post, Greg! I ran into the same issue when I was testing LTM in Azure - well solved :)

     

    -Josh