XML Scripts to deploy 3-Tier Application with Cisco APIC and F5 BIG-IP LTM [End of Life]

As described in a previous article Under the hood of F5 BIG-IP LTM and Cisco ACI integration – Role of the device package , Cisco APIC provides the user with the ability to define a service graph to automate L4-L7 service insertion using F5 BIG-IP device package. In this article, learn how to deploy an application with Cisco APIC policy model and F5 BIG-IP LTM device package using Northbound APIs (XML) scripts. Let's look at the different APIC logical constructs before diving into the cookbooks of scripting.

Application Policy Infrastructure Controller (APIC) Policy Model

The Application Centric Infrastructure policy model provides a convenient way to specify application requirements, which the APIC then renders in the network infrastructure. The policy model consists of a number of constructs such as tenants, contexts, bridge domains, end point groups and service graphs. When a user or process initiates an administrative change to an object within the fabric, that change is first applied to the ACI policy model and then applied to the actual managed end point . All physical and logical components of the ACI fabric are represented as a hierarchical Management Information Tree (MIT). Some of the key components contained within the MIT are shown in the flow diagram

Tenant

A tenant is essentially a ‘container’, used to house other constructs and objects in the policy model (such as contexts, bridge domains, contracts, filters and application profiles). Tenants can be completely isolated from each other, or can share resources. A tenant can be used to define administrative boundaries – administrators can be given access to specific tenants only, resulting in other tenants being completely inaccessible to them

Learn how to Create Tenant SJC 

Learn how to Create Tenant LAX 

Contexts

A context is used to define a unique layer 3 forwarding domain within the fabric. One or more contexts can be created inside a tenant. A context is also known as a ‘private network’ and can be viewed as the equivalent of a VRF in the traditional networking world. As each context defines a separate layer 3 domain, IP addresses residing within a context can overlap with addresses in other contexts.

Bridge Domains and Subnets

A bridge domain is a construct used to define a layer 2 boundary within the fabric. A BD can be viewed as somewhat similar to regular VLANs in a traditional switching environment. BDs however are not subject to the same scale limitations as VLANs, and have a number of enhancements such as improved handling of ARP requests and no flooding behavior by default.

A subnet defines the gateway(s) that will be used within a given bridge domain. This gateway will typically be used by hosts associated with a bridge domain as their first hop gateway. Gateways defined within a bridge domain are pervasive across all leaf switches where that bridge domain is active.

End Point Groups (EPG)

The End Point Group (EPG) is one of the most important objects in the policy model and is used to define a collection of end points. An end point is a device connected to the fabric (either directly or indirectly) and has an address, a location and other attributes.  End points are grouped together into an EPG, where policy can be more easily applied consistently across the ACI fabric.

An end point may be classified into an EPG based on a number of criteria, including:

•    Virtual NIC
•    Physical leaf port
•    VLAN

Contracts

A contract is a policy construct used to define the communication between End Point Groups (EPGs). Without a contract between EPGs, no communication is possible between those EPGs. Within an EPG, a contract is not required to allow communication as this is always allowed. An EPG will provide or consume a contract (or provide and consume different contracts). For example, EPG “Web” in the XML scripts will provide a contract which EPG “App” will consume. Similarly, EPG “App” provides separate contracts which are consumable by the “Web” and “DB” EPGs.

Learn how to create contracts for Tenant SJC

Learn how to create contracts for Tenant LAX

Filters

A filter is a rule specifying fields such as TCP port, protocol type, etc. and is referenced within a contract to define the communication allowed between EPGs in the fabric. A filter contains one or more “filter entries” that actually specify the rule.

Subjects

A subject is a construct contained within a contract and which typically references a filter. For example, contract “Web” contains a subject named “Web-Subj”, which references a filter named “Web-filter”.

Application Profile

The Application Profile is the policy construct that ties multiple EPGs together with contracts that each EPG provides or consumes. An application profile contains as many EPGs as necessary that logically relate to the capabilities provided by an application.

Learn how to create Application Profile for Tenant SJC

Learn how to create Application Profile for Tenant LAX

Service Graph

A service graph is a chain of service functions such as Web application Firewall (WAF), Load balancer or network firewall including the sequence with which the service functions need to be applied. The graph defines these functions based on a user-defined policy for a particular application. One or more service appliances might be needed to render the services required by the service graph.

Learn how to create Service Graph "WebGraph" and how to attach the graph to contract in Tenant SJC

Learn how to create Service Graph "WebGraph" and how to attach the graph to contract in Tenant LAX

Creating a Device Cluster

Learn how to create Logical Device with device type Physical  under Tenant mgmt

Learn how to create F5 BIG-IP LTM concrete devices under the device cluster and confuring high availability

Learn how to bind the logical interfaces with physical interfaces of BIG-IP LTM

Exporting a Device Cluster to Tenant SJC and LAX from Tenant mgmt

Learn how to export the device cluster created in Tenant mgmt to Tenant SJC

Learn how to export the device cluster created in Tenant mgmt to Tenant LAX

Setting up the Fabric for service Insertion

Learn how to setup the VMM domain to integrate APIC with VMware VCenter environment to run BIG-IP LTM VE or Server VMs

Learn how to setup the physical domain and assigning the vlan namespace to enable datapath forwarding on leaf switches

Learn how to setup vlan namespace to dynamically assign the vlans to end points  

Wondering how to run these scripts ?

Here is the recipe, run the two scripts below within python environment and verify the configurations on Cisco APIC and F5 BIG-IP LTM. Make sure you have a device package downloaded from download.f5.com and saved in the same directory with the scripts

1. python request.py infra.cfg

2. python request.py tenant.cfg

Complete XML scripts directort can be downloaded from here . 

Video (showing the configuration through APIC Graphical User Interface)

The recorded video here shows how to configure the ACI policy model to deploy an application in Cisco APIC and BIG-IP LTM through graphical user interface.