The F5 and Cisco APIC integration based on the device package and iWorkflow is End Of Life.
The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’.
Visit https://f5.com/cisco for updated information on the integration.
The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’.
Visit https://f5.com/cisco for updated information on the integration.
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 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 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.
