This blog is a joint collaboration between Ravi Balakrishnan (Cisco) and Payal Singh (F5). It is the third in a series.
APIC EndPoints and EndPoint Groups
When dealing with the Cisco ACI environment you may have wondered about using an Application-Centric Design or a Network-Centric Design. Both are valid designs. Regardless of the strategy, the ultimate goal is to have an accessible and secure application/workload in the ACI environment. An application is comprised of several servers; each one performing a function for the application (web server, DB server, app server etc.). Each of these servers may be physical or virtual and are treated as endpoints on the ACI fabric. Endpoints are devices connected to the network directly or indirectly. They have an address , attributes and can be physical or virtual. Endpoint examples include servers, virtual machines, network-attached storage, or clients on the Internet. An EPG (EndPoint Group) is an object that contains a collection of endpoints, which can be added to an EPG either dynamically or statically. Take a look at the relationship between different objects on the APIC.
More details are available in the EPG chapter of the Cisco APIC Layer 2 Networking Configuration Guide.
Relationship between Endpoints and Pool members
If an application is being served by web servers with IPs having address’s in the range 192.168.56.*, then these IP addresses will be present, as an endpoint in an endpoint group (EPG) on the APIC. From the perspective of BIG-IP these web servers are pool members on a particular pool.
The F5 ACI ServiceCenter is an application developed on the Cisco ACI App Center platform designed to run on the APIC controller. It has access to both APIC and BIG-IP and can correlate existing information on both to provide a mapping as follows.
| BIG-IP | APIC |
| VIP: Pool: Pool Members(s) | Tenant: Application Profile: End Point group |
This gives an administrator a view of how the APIC workload is associated with the BIG-IP and what all applications and virtual IP’s are tied to a tenant. View more details on the F5 ACI ServiceCenter visibility dashboard and learn more on how and under what situations the dashboard can be helpful.
In this article we are going to see how the F5 ACI ServiceCenter can take advantage of
the endpoints learned by the ACI fabric to dynamically grow/shrink pool members.
Dynamic EndPoint Attach and Detach
Lets think back to our application which is say being hosted on 100’s of servers, these servers could be added to an APIC EPG statically by a network admin or they could be added dynamically through a vCenter or openstack APIC integration. In either case there endpoints ALSO need to be added to the BIG-IP where the endpoints can be protected by malicious attacks and/or load-balanced. This can be a very tedious task for a APIC or a BIG-IP administrator.
Using the dynamic EndPoint attach and detach feature on the F5 ACI ServiceCenter this burden can be reduced. The application has the ability to adjust the pool members on the BIG-IP based on the server farm on the APIC. On APIC when an endpoint is attached, it is learned by the fabric and added to a particular tenant, application profile and EPG on the APIC. The F5 ACI ServiceCenter provides the capability to map an EPG on the APIC to a pool on the BIG-IP. The application relies on the attach/detach notifications from the APIC to add/delete the BIG-IP pool-members.
There are different ways in which the dynamic mapping can be leveraged using the F5 ACI ServiceCenter based on the L4-L7 configuration. In all the scenarios described below the L4-L7 configuration is deployed on the BIG-IP using AS3 (flexible, low-overhead mechanism for managing application-specific configurations on a BIG-IP system).
Scenario 1: Declare L4-L7 configuration using F5 ServiceCenter
Scenario 2: L4-L7 configuration already exists on the BIG-IP
Scenario 3: Use dynamic mapping but do not declare the L4-L7 configuration using the F5 ServiceCenter
Scenario 4: Use the F5 ServiceCenter API’s to define the mapping along with the L4-L7 configuration
Let’s take a look at each one in detail:
Scenario 1: Declare L4-L7 configuration using F5 ServiceCenter
Let’s assume there is no existing configuration on the BIG-IP, a new application needs to be deployed which is front ended by a VIP/Pool/Pool members. The F5 ACI ServiceCenter provides a UI that can be used to deploy the L4-L7 configuration and create a mapping between Pool <-> EPG
Step 1: Define an application using one of the in-built templates
Step 2: Click on the Manage Endpoint mappings button to create a mapping
Scenario 2: L4-L7 configuration already exists on the BIG-IP
If L4-L7 configuration using AS3 already exists on the BIG-IP, the F5 ACI ServiceCenter will detect all partitions and application that in compatible with AS3. Configuration for a particular partition/application on BIG-IP can then be updated to create a Pool <-> EPG mapping. However there is one condition that the pool can either have static or dynamic members so if the pool already has existing members those will have to be deleted before a dynamic mapping can be created. To maintain the dynamic mapping , any future changes to the L4-L7 configuration on the BIG-IP should be done via the ServiceCenter.
Scenario 3: Use dynamic mapping but do not declare the L4-L7 configuration using the F5 ServiceCenter
The F5 ACI ServiceCenter can be used just for the dynamic mapping and pool sizing and not for defining the L4-L7 configuration. For this method the entire AS3 declaration along with the mapping will be directly send to the BIG-IP using AS3.
Sample declaration (The members and constants section creates the mapping between Pool<->EPG)
Since the declaration is AS3, the F5 ACI ServiceCenter will automatically detect a Pool <-> EPG mapping which can be viewable from the inventory tab.
Scenario 4: Use the F5 ServiceCenter API’s to define the mapping along with the L4-L7 configuration
Finally if the UI is not appealing and automation all the way is the goal, then the F5 ServiceCenter has an API call where the mapping as well as the L4-L7 configuration which was done in Scenario 1 can be completely automated. Here the declaration is being passed to the F5 ACI ServiceCenter through the APIC controller and NOT directly to the BIG-IP.
URI:https://<apic_controller_ip>>/appcenter/F5Networks/F5ACIServiceCenter/updateas3data.json
Body/declaration
Having knowledge on how AS3 works is essential since it is a declarative API and using it incorrectly can result in incorrect configuration. Either method mentioned above works, the decision on which method to use is influenced on the operational model that works the best in your environment.
References
ACI Fabric Endpoint Learning White Paper
Download the F5 ACI ServiceCenter
F5 ACI ServiceCenter API documentation
Application Services 3 (AS3 extension)
Useful operational insight. Thanks