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. When we click on the Virtual BIG-IP we can get the IP address and using a browser through port 443, we can connect either with the DNS name or the IP address to the config utility. 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 AzureRepo for Azure VMSS deployment
Hello, For a deployment of an autoscaling (F5 Advanced WAF) model in Azure, I'm searching an ARM template which will fit some requirements. Which existing ARM template can be used in order to create a custom one with the below characteristics: Advanced WAF module Autoscale (VMSS 2 min & 3 max) Existing network 2-NIC version 15 BYOL Internal LB (front of the VMSS - unlike external LB) without public IP (F5 NICs) One more questions regarding existing templates: The 'appContainerName' parameter is set to "f5devcentral/f5-demo-app:latest": ==> is there an impact for rolling update capabilities on the VMSS, when wanted to push a new image? Thanks in advance Regards Fatih
Azure Payg 3nic - Existing Stack Azure template extension failed
Hi all. Need your help to know why is this failing. When I deploy the PAYG template the extension installation fails with "**_Status Message: VM has reported a failure when processing extension 'start'. Error message: "Enable failed: failed to execute command: command terminated with exit status=1 [stdout] [stderr] /bin/sh: -c: line 109: unexpected EOF while looking for matching `'' /bin/sh: -c: line 110: syntax error: unexpected end of file " More information on troubleshooting is available at https://aka.ms/VMExtensionCSELinuxTroubleshoot (Code:VMExtensionProvisioningError)_**" I´m running this version: "f5CloudLibsTag": "v4.27.1", "f5CloudLibsAzureTag": "v2.17.1", "f5NetworksTag": "v10.2.0.0", Many thanks!
Enabling ARM on Viprion C2400 with VCMP guests
Use case: We're in the middle of an effort to enable the Advanced Routing Module (ARM) with OSPFv2 so that we can essentially employ route advertisement on virtual addresses, and be able to remove them via dynamic routing when any of the services become unavailable. We appear to be having issues properly enabling them on specific LTM guests that reside on VCMP-enabled Viprion hosts. While I do have a support case open, I thought I would try devcentral. So, enabling OSPFv2 is done at the route domain level, and I have tried two ways - 1)enable ospfv2 on route domain 0 at the vcmp guest level -- OR -- 2)enable ospfv2 on route domain 0 at the host level -- OR -- 3) BOTH None of these options appear to work. taking traces, I do see the OSPFv2 Hello packets from the adjacent routers (which are also the default gateways being sent via multicast, but I don't see the F5s send their OSPFv2 Hello packets. So, no ospf neighbor info is getting across between Cisco routers and F5 BIGIPs. Am I missing something on the OSPF configuration side? I did follow instructions given in this article: https://support.f5.com/kb/en-us/solutions/public/14000/400/sol14490.html Looking for anyone else out there who may have done this successfully before. Thanks!
