ACI Tenant: What Do You Need To Know About It?

In my recent engagement with a Cisco Business-Critical Services (BCS) project, I encountered a fascinating scenario that underscored the importance of understanding the fundamentals of ACI tenants. The client, operating in a non-service provider environment, had created an astonishing 900+ tenants within their ACI fabric. This excessive number hinted at a potential misunderstanding of the purpose and function of ACI Tenants.

In the following sections, we will explore what ACI tenants are and what their role is within the ACI fabric.

What is a Tenant in ACI?


An ACI tenant refers to a set of configurations owned by a specific entity. This allows for the management of those configurations to be kept separate from those of other tenants. Entities can be customers, departments, organizations, …etc.

  • Tenants provide the separation of management and data-processing functions inside ACI.
  • Tenant is a container for policies, analogous to a Sub-Org in Cisco UCS.
  • In addition, the tenant provides a data-plane isolation function using VRF instances (contexts) and bridge domains (BDs).
  • Resources such as L3 and L2 connections in and out of the fabric can be given to individual tenants, as well as access and control to L4-7 services.
  • Tenant object class [fvTenant].

What are the Tenant’s Main Components?

  • Virtual Routing and Forwarding (VRFs).
    • Same concept as in regular NX-OS and IOS.
    • By default, there is no communication between VRFs.
    • Used to define a non-overlapping IP address space within the tenant. Furthermore, we can have overlapping IP space between VRFs but not within the same VRF.
    • We either need to create a new custom VRF in the tenant or refer to a VRF in the common tenant.
    • In ACI, each VRF has a unique VXLAN VNID value that we call Segment ID, which is a fabric-wide numerical representation of the VRF, and it is important for L3 forwarding.
    • VRF object class [fvCtx].
  • Bridge Domains (BDs).
    • It is NOT a VLAN; it’s simply a layer-2 boundary and a container for IP subnets.
    • Used to define an L2 boundary (Flooding Domain) and impose additional constraints (such as no broadcast) within that L2 boundary.
    • For each bridge domain, we must link it to one VRF.
    • EPGs can only be members of a single BD.
    • A Bridge Domain (BD) can span across switch nodes, pods, or even sites.
    • MAC addresses must be unique within the Bridge Domain. Otherwise, ACI sees it as a MAC move (flapping).
    • In ACI, each BD has a unique VXLAN VNID value, which is a fabric-wide numerical representation of the VRF, and it is important for L2 forwarding.
    • BD object class [fvBD].
  • Application Profiles (AP).
    • It is a container (Folder) for multiple EPGs. We use it to include all application-related configurations.
    • Each AP represents a customer application where we define a group of EPGs and their contracts (policies).
    • AP object class [fvAP].
  • Endpoint Groups (EPG).
    • It is a logical entity that contains a collection of end-points with common policy requirements (treatment).
    • The ACI Fabric uses an 802.1Q VLAN tag to represent the EPG. EPG is most commonly determined by ingress VLAN ID and switch port ID.
    • Objects in different EPGs cannot communicate with each other by default (require contracts).
    • EPG object class [fvAEPg].
  • IP Subnets.
    • In ACI, subnets are the distributed Anycast layer-3 gateway. I.e., the Anycast default gateway for your servers (Pervasive Gateway).
    • Subnets automatically create SVIs on leafs where endpoints appear.
    • Each subnet is a child of one bridge domain. But a BD may have more than one subnet. (The DHCP relay only works on the primary subnet)
    • Subnets must have unique IP addresses within their context “VRF”.
    • Subnets can span multiple EPGs.
    • Subnet object class [fvSubnet].
  • Contracts, Subjects, & Filters
    • A contract is a policy definition that defines how an EPG communicates with other EPGs.
    • Contracts [vzBrCP] are groups of subjects that define communication between source and destination EPGs.
    • We use Subjects [vzSubj] to build definitions of contracts (ACLs) for communication between EPGs, containing Filters, actions, and optional labels.
    • Filters [vzFilter] are identifiers for a subject, i.e., the traffic you want to take action on. (e.g., TCP destination port 80).
  • Layer-3 Outside (L3Out)
    •  An L3Out is simply a collection of policies configuring interfaces, IP addresses, routing protocols, etc., for connectivity to L3 devices outside the ACI fabric.
    • An L3Out connection is always associated with a VRF. Each L3Out connection is associated with one VRF instance only.
    • Leaf(s) that are associated with an L3Out called Border Leaf (BL).
    • L3Out object class [l3extOut].

Tenant Components Logical Polices


The figure below shows that the ACI Tenant is considered a logical entity in the ACI fabric, and it is associated with the physical part through the EPGs.

ACI Logical and Physical Policies

Tenant Components Relationships


The figure below shows the ACI components’ relationships. For example, the EPG to Contract relationship is N-to-N, meaning a given EPG can have multiple contracts and a given Contract can be used in multiple EPGs.

Tenant Policies Diagram

ACI Default Tenants

  • Infra Tenant:
    • The infrastructure tenant is used for all internal fabric communications, such as tunnels and policy deployment, including switch-to-switch (leaf, spine, Application Virtual Edge (AVE), and switch-to-APIC communications.
    • The infra tenant is not exposed to the user space (tenants), and it has its own VRF and bridge domains.
    • Fabric discovery, image management, and DHCP for fabric functions are all handled within this tenant.

  • mgmt Tenant:
    • The management tenant provides a convenient means to configure access policies for fabric nodes.
    • Although fabric nodes are accessible and configurable through the APIC, they can also be accessed directly using in-band and out-of-band connections.

  • Common Tenant:
    • 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.
    • Here are some examples of common services:
      • Shared L3out.
      • Private networks (VRF).
      • Bridge domains (BD).
      • Application services such as DNS, DHCP, and Active Directory.
      • L4-7 services.

Conclusion

An ACI Tenant is the highest-level object within the ACI object model and can be seen as an administrative container. It encapsulates all objects that belong to a specific tenant, organization, or department. This includes VRFs, Endpoint Groups (EPGs), Bridge Domains (BDs), Subnets, L3Outs, and contracts.

I hope this article was useful. Feel free to leave a comment or a question.

5 2 votes
Article Rating
Subscribe
Notify of
guest

1 Comment
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
Biswajit Sarkar
Biswajit Sarkar
9 months ago

Very Good Explanation!

Scroll to Top