Using Infrastructure as Code to deploy F5 Application Delivery and Cisco ACI Service Chaining

Every data center is built to host applications and provide the required infrastructure for the applications to run, communicate with each other, be accessed by their users from anywhere, and scale on demand.

To achieve this, your data center network must be able to provide different types of connectivity to different applications. This includes east-west connectivity between application tiers, as well as north-south connectivity between users and applications. Both rely on additional application delivery Layer 4 to Layer 7 services like load balancers and web application firewalls.

Cisco ACI and F5 BIG-IP Service Insertion

Cisco ACI’s powerful L4-L7 services redirection capabilities will allow you to insert services and redirect traffic from the source to the destination anywhere in your fabric without needing to change any of the existing cabling. This is where you can insert F5 BIG-IP load balancer, to provide application availability, access control, and security.

Read More: 500-440: Designing Cisco Unified Contact Center Enterprise (UCCED)

This is possible using the Policy Based Redirection (PBR) capabilities of the Cisco ACI fabric by configuring a Service Graph in APIC.

But PBR policy and Service Graphs entail a series of manual configurations. This can be tedious, error prone, and inefficient especially if the same configuration happens very often. On top of that, the configuration of the BIG-IP service itself requires information from the Cisco ACI Service Graph.

Simplified Service Insertion with Cisco and F5

This is why Cisco partnered with F5—a leader in the application delivery and web application firewall space around the Cisco ACI and the F5 BIGIP solutions—to simplify the deployment of F5-powered L4-L7 services using the F5 ACI ServiceCenter App for APIC.

This integration simplifies management of Virtual sever configuration on F5 BIG-IP and Service Graph configuration on Cisco ACI by providing a simple user-friendly UI.

In this blog, we will discuss an evolution of this integration for customers looking at Infrastructure as Code as the means to automatically deploy both Cisco ACI network infrastructure configuration and BIG-IP L4-L7 services for their applications and looking for opportunities to start progressing in their IaC journey.

End-to-End Service Insertion Automation with Infrastructure as Code

As a reminder, Infrastructure as Code is a journey that you can embark at different stages depending on your existing automation knowledge and needs. The goal of this journey is to translate manual tasks into reusable, robust distributable code and apply software development techniques such as version control (git), automated testing and CI/CD to achieve those goals.

The first step in an Infrastructure as Code journey is to start by selecting a language or a toolset to express our intent for our Infrastructure as actual code. For this integration, we decided to join forces with HashiCorp, the leader in infrastructure automation and a shared partner of Cisco and F5 and chose HashiCorp Terraform as the Infrastructure provisioning tool and using HCL (HashiCorp Configuration Language) to define service configuration as our code.

F5 and Cisco both have verified HashiCorp Terraform providers, making it easy to create the needed configuration on both sides using HCL (HashiCorp Configuration Language) as our code.

To further simplify automation of the numerous configuration items, Cisco and F5 have worked together on a set of Terraform modules which provide best practices defaults for most of the configuration items and allow users to override specific items of the configuration.

By providing a single workflow, all the dependencies are taken care of, and the usage of the overall solution is simplified. Modules also defines outputs that can be passed from one module to the next and modules can depend on each other to represent the dependency relationship they have with each other.

As part of this solution, a simple workflow with 3 Terraform modules has been created:

◉ The Cisco ACI Service Graph Terraform module allow the user to create and deploy a complete service graph for Policy-Based Redirection (PBR) with the required bridge domains and other necessary constructs as documented in the Cisco ACI Policy-Based Redirect Service Graph Design white paper

◉ The F5 BIG IP VLAN Self IP Terraform module configures the interfaces of the BIG-IP (physical or virtual) facing the ACI fabric with the correct VLANs, and Self-Ips configuration.

◉ The F5 BIG IP AS3 HTTP Service Terraform module configures an HTTP Service using F5 Application Services 3 extension (AS3) to provide a load balancing function with a specific Virtual server (VIP) and the recommended configuration when used in conjunction with Cisco ACI PBR.

Instantiation of the modules allows the user to pass the parameters necessary and use default parameters for the rest of the configuration hiding all their internal complexity to the user. The following is an example of the instantiation of the different modules and their dependencies:

module "cisco-aci-service-graph" {

    source = "./modules/service-graph-lb-pbr"

    tenant              = var.aci_tenant

    vmm_provider_dn     = var.aci_vmm_provider_dn

    vmm_domain_name     = var.aci_vmm_domain_name

    vmm_controller_name = var.aci_vmm_controller_name

    vm_name             = var.aci_bigip_vm_name

    vnic                = var.aci_bigip_vnic

    device_name         = var.aci_bigip_device_name

    device_mac_address  = var.aci_bigip_provider_mac

    device_ip_address   = var.selfip_int

    provider_bd_subnets         = var.aci_provider_bd_subnets

    consumer_bd_subnets         = var.aci_consumer_bd_subnets

    provider_service_bd_subnets = var.aci_provider_service_bd_subnets

    consumer_service_bd_subnets = var.aci_consumer_service_bd_subnets

}

module "bigip_vlan_selfip" {

    source       = "./modules/vlan_selfip"

    vlan_int_tag = replace(module. cisco-aci-service-graph.internal_vlan, "vlan-", "")

    vlan_ext_tag = replace(module. cisco-aci-service-graph.external_vlan, "vlan-", "")

    selfip_int   = var.selfip_int

    selfip_ext   = var.selfip_ext

}

module "as3_http_app" {

    source      = "./modules/as3http"

    server1     = var.server1

    server2     = var.server2

    vip_address = var.vip_address

    snat        = var.snat

}

You can see that the “bigip_vlan_selfip” module uses the output of the cisco-aci-service-graph module to pass the VLAN automatically derived from the ACI VMM domain integration. This removes the need to statically define a VLAN and allow the reuse of this plan over and over. You can also see that the module definition uses a lot of variables creating a reusable piece of code that can be instantiated multiple times with different sets of variables.

With this joint solution, deploying BIG-IP application services on an ACI network infrastructure with a Terraform workflow and applying Infrastructure as Code principles, can greatly simplify, automate, optimizes, and accelerate the entire application deployment lifecycle in turn improving time to value.

To better collaborate with other members of your organization on provisioning this solution, HashiCorp Terraform Cloud can be used to provide remote state storage allowing your state file (which provides a system of record for what you have provisioned) to be stored securely and remotely.