XML Scripts to deploy 3-Tier Application with Cisco APIC and F5 BIG-IP LTM [End of Life]
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. 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" andhow to attach the graph to contract in Tenant LAX Creating a Device Cluster Learn how to create Logical Device with device type Physicalunder Tenant mgmt Learn how to create F5 BIG-IP LTM concrete devices under the device clusterand 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.Accelerate and automate your application deployments with Cisco ACI and F5 [End Of Life]
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. Cisco Systems recently announced its strategy to address dynamically changing application requirements referred to as Application Centric Infrastructure (ACI) .ACI is a holistic architecture with centralized automation and policy-driven application profiles. It delivers software flexibility with the scalability of hardware performance and facilitates rapid systems integration and customization for network services, monitoring, management, and orchestration with visibility of both physical and virtual networks. It’s built upon a fabric foundation that delivers the best in class infrastructure by combining hardware, software, and ASIC innovations into an integrated system. The architecture provides a common management framework for network, application, security and virtualization teams making IT more agile while reducing application deployment time. It is also optimized for running today’s physical and virtual applications along with being ready for tomorrow’s emerging architectures that will be needed to support an “application anywhere” model with complete freedom of application movement and placement. The Architecture is built for multi-tenancy, ensuring proper isolation and detailed telemetry for SLAs across different consumers of the infrastructure while also providing a consistent security policy across both physical and virtual applications. Key characteristics of ACI include: Simplified automation by an application-driven policy model Centralized Management, Automation and Orchestration Mixed Workload and Migration Optimization Secure and scalable Multi-tenant Environment Extensibility and Openness – Open Source, Open APIs and Open software flexibility for Dev Ops teams and ecosystem partner integration Investment Protection (People and Infrastructure) F5 Synthesis is conceptually aligned with Cisco ACI Architecture F5's Synthesis architecture is a vision for delivering Software Defined Application Services. Its high performance services fabric enables organizations to rapidly provision, manage and orchestrate a rich catalog of services using simplified business models that dramatically changes the economy of scale for Layer 4-7 services. The joint Cisco ACI and F5 Synthesis solution enables IT to operationalize critical data center network and Layer 4 through 7 services to meet business and consumer demands for application performance, security, and reliability in a compliant, standard, and repeatable way. With the Cisco ACI and F5 solution’s fully programmable load-balancing services technology, customers can implement application-centric deployments with the Cisco ACI fabric, using contracts, filters, and service graphs to control traffic between application tiers. This model provides stateless load balancing for a three-tier application in the data center with agility and full automation. Traffic can be redirected to F5 BIG-IP LTM load-balancer devices (both physical and virtual) using an appropriate device package integrated into Cisco APIC. The APIC manages F5 BIG-IP LTM devices and its supported functions through the use of device packages, which are used to define, configure, and monitor service devices. A device package allows adding, modifying, or removing a network service on the APIC without interruption. The Device Package is a zip file that contains all the information needed for the APIC to integrate with BIG-IP LTM. Traditional Network Service Insertion Challenges Traditional approaches to inserting L4-L7 services into a network involve highly manual operations for example VLAN (Layer 2) or Virtual Routing and Forwarding (VRF) instance (Layer 3) stitching between network elements and service appliances, that takes days or even weeks to deploy an App. Likewise when an application is retired, removing a service device configuration, such as firewall rules, can be difficult. Cisco ACI will provide customers with an automated Service Insertion and Policy management model which is the evolution of the next generation Data Center architecture compared to the “traditional” model of services insertion. Cisco ACI controller (APIC) can automate service insertion while acting as a central point of policy control. APIC can also automatically configure the service according to the application’s requirements, which allows organizations to automate service insertion and eliminate the challenge of managing the complex techniques of traditional service insertion. F5 BIG-IP LTM integration with Cisco ACI F5 BIG-IP LTM integrates with Cisco APIC through well-established and open southbound APIs. This integration automates network and service provisioning across the F5 services fabric, providing end-to-end telemetry and visibility of applications and tenants. Cisco APIC acts as a central point of configuration management and automation for Layer 4 through 7 services and tightly coordinates service delivery, serving as the controller for network automation. Cisco APIC automates the insertion and provisioning of network services through the F5 BIG-IP platform: for example, SSL offload, server load balancing (SLB), and Microsoft SharePoint services. F5 announced its device package for Cisco APIC integration in early August 2014. Cisco ACI-F5 BIG-IP joint solution was also showcased at F5 Agility, 2014 in New York during breakout sessions, in solution labs, solutions Expo and in keynote panel. Cisco also recently published a jointly written technical whitepaper, a solutions brief and a Design guide with F5 The F5 Device Package for Cisco Application Policy Infrastructure Controller ™ (APIC) is now available. To download at no cost, please visit https://downloads.f5.com/esd/productlines.jsp Further Resources Cisco Alliance page - https://f5.com/partners/product-technology-alliances/cisco Cisco page on DevCentral - https://devcentral.f5.com/s/cisco Cisco Blog on Device Package – http://blogs.cisco.com/datacenter/f5-device-package-for-cisco-apic-goes-fcs/ Technical Solution Whitepaper - http://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-732413.pdf Device Package integration demo - https://www.youtube.com/watch?v=5Nw2vtid7Zs
