XML Scripts to deploy 3-Tier Application with Cisco
APIC and F5 BIG-IP LTM
Faraz, 2014-26-09
As described in a previous article Under the hood of F5 BIGIP 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)
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 “WebSubj”, which references a filter named “Webfilter”.
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
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 BIGIP LTM through graphical user interface.
F5 Networks, Inc. | 401 Elliot Avenue West, Seattle, WA 98119 | 888-882-4447 | wwww.f5.com
F5 Networks, Inc.
Corporate Headquarters
[email protected]
F5 Networks
Asia-Pacific
[email protected]
F5 Networks Ltd.
Europe/Middle-East/Africa
[email protected]
F5 Networks
Japan K.K.
[email protected]
©2014 F5 Networks, Inc. All rights reserved. F5, F5 Networks, and the F5 logo are trademarks of F5 Networks, Inc. in the U.S. and in certain other countries. Other F5
trademarks are identified at f5.com. Any other products, services, or company names referenced herein may be trademarks of their respective owners with no endorsement or
affiliation, express or implied, claimed by F5. CS04-00015 0113