ACI Tenancy Models
ACME Inc. will be using tenancy for a couple of use cases. They will be using tenant constructs for the application lifecycle of their current deployment, maintaining a separate tenant for the resources that developers will be using to build the application, a tenant that will be used for the automated testing, and finally a production tenant. Additionally, as mentioned in the introduction, they are also looking to build an infrastructure which can be leveraged for similar initiatives in the future. Tenants will be used to draw virtual boundaries for different lines of business. The information security team will be able to integrate this into the corporate LDAP system, and prevent changes which would impact other groups.
Cisco Application Centric Infrastructure (ACI) has been designed from the beginning to be "multi-tenant". This means different things to different people (much like the term Cloud) based on their perspective. In the case of a classic service provider, a tenant is a unique customer, while in a typical end-customer environment a tenant could be an operating group, business unit, application owner, and so on.
The decision on how to leverage tenancy models is driven by a number of factors:
- Overall IT operations and support models in your organization to manage application, networking, servers, security, and so on.
- Separation of environments from a software development lifecycle perspective: development, quality assurance, and production.
- Separation of duties by domain owner, such as web, app, and database owners.
- Fault domain size and scope to limit the impact of failures, such as different business units.
In traditional networking environments, making a routing protocol change on a router or Layer 3 switch could potentially affect hundreds of unique VLANs/subnets. This introduces a warranted level of caution around change control and application impact. Leveraging the ACI policy model, the physical hardware is abstracted from the logical constructs. The tenant object gives us the ability to draw a box around the logical and concrete objects that we use to provide a unified view of the configuration dependencies for underlay and overlay networks.
A tenant in the ACI object model represents the highest-level object. Inside, you can differentiate between the objects that define the tenant networking, such as private networks (VRFs), bridge domains and subnets; and the objects that define the tenant policies such as application profiles and endpoint groups.
In ACI, the tenant policies are where you define applications. An application could consist of a combination of physical servers or virtual machines that we will call servers from now on. For example, a website could use a 3-tier application model, comprised of web servers, application servers and database servers. When a user browses the web site, they might actually be communicating with a virtual IP address on a load balancer that in turn can distribute the web request to a number of different web servers. The web servers in turn communicate with core applications that can be divided amongst several application servers for load balancing or high availability purposes. Finally, the application servers communicate with the database which could also be a cluster of servers.
Each server is referred to as an endpoint in ACI. Endpoints are classified in ACI to apply policies. You create endpoint groups with endpoints that share the same type of policies, such as with whom are they going to communicate and what type of communication or restrictions are required. Therefore, an application can be formed by several endpoint groups and they are grouped in an application profile.
The tenant networking is used to define networking policies and will be applied to the underlying hardware in a transparent way thanks to the layer of abstraction provided by ACI using private networks, bridge domains and subnets. In the next sections of this chapter, these concepts will be covered in detail. Below you can find an illustration with the different objects that compound a tenant and how they are related.
Although the tenant networking and the tenant policies are defined separately, the networking policies used by an application are defined with a relationship between the endpoint groups and the bridge domain.
The following image shows all of the components that can be configured within a tenant. In the following sections each diagram shows the progress of how ACME Inc. adds each component.

There are 3 tenants that are preconfigured in the system by default:
-
Common—A special tenant with the purpose of providing "common" services to other tenants in the ACI fabric. Global reuse is a core principle in the common tenant. Some examples of common services are:
-
Shared L3 out
- Shared private networks
- Shared bridge domains
- DNS
- DHCP
- Active directory
-
- Infra—The Infrastructure tenant that is used for all internal fabric communications, such as tunnels and policy deployment. This includes switch to switch (leaf, spine, Application Virtual Switch (AVS)) and switch to Application Policy Infrastructure Controller (APIC). The Infra tenant does not get exposed to the user space (tenants) and it has its own private network space and bridge domains. Fabric discovery, image management, and DHCP for fabric functions are all handled within this tenant.
-
Mgmt—The management tenant provides convenient means to configure access policies for fabric nodes. While fabric nodes are accessible and configurable through the APIC, they can also be accessed directly using in-band and out-of band connections. In-band and out-of-band policies are configured under the mgmt tenant: