The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
A tenant is a logical container for application policies that enables you to exercise domain-based access control by isolating the resources such as applications, databases, web servers, network-attached storage, virtual machines, firewalls, Layer 4 to Layer 7 services, and so on. Tenants can represent a customer in a service provider setting, an organization or domain in an enterprise setting, or just a convenient grouping of policies.
A fabric can contain anywhere from one tenant, which may be useful for a small commercial environment, to 64,000+ tenants, for a cloud service provider in which case you assign each company their own tenant. Another use case would be to have a Dev tenant and a Production tenant. In this case, you create network constructs, EPGs, and policies in Dev tenant first and then simply copy it to the Production tenant. It ensures that the dev and prod are the exact same and takes away the human error that comes along with manual copying of these objects.
Note | Configure a tenant before you can deploy any Layer 4 to Layer 7 services. |
The system provides the following four kinds of tenants:
User tenant—Defined by the administrator according to the needs of users. It contains policies that govern the operation of resources such as applications, databases, web servers, network-attached storage, virtual machines, and so on.
Common tenant—Provided by the system but can be configured by the fabric administrator. It contains policies that govern the operation of resources accessible to all tenants, such as firewalls, load balancers, Layer 4 to Layer 7 services, intrusion detection appliances, and so on.
Infrastructure tenant—It contains policies that govern the operation of infrastructure resources such as the fabric VXLAN overlay.
Management tenant—It contains policies that govern the operation of fabric management functions used for in-band and out-of-band configuration of fabric nodes.
Tenants can be isolated from one another or can share resources.
Tenants do not represent a private network.
Entities in the tenant inherit its policies.
The primary elements that the tenant contains are filters, contracts, outside networks, bridge domains, Virtual Routing and Forwarding (VRF) instances, and application profiles that contain endpoint groups (EPGs).
Note | In the APIC GUI under the tenant navigation path, a VRF (context) is called a private network. |
This procedure provides an overview of how to set up a tenant for an APIC account in Cisco UCS Director.You can also use the workflows provided in Cisco UCS Director Orchestration to complete a guided setup of tenants for various use cases. For more information, see Cisco UCS Director Orchestration Guide.
This procedure assumes that you have already completed the following prior to creating tenants:
The Day 0 setup of ACI fabric.
The nodes in ACI fabric are connected and discovered.
The APIC controller cluster has been configured.
Cisco UCS Director is configured and the ACI pod has been set up.
Step 1 | Create a Tenant.
See Creating a Tenant. |
Step 2 | Create a Virtual Routing and Forwarding (VRF) (also known as Private Network).
See Creating a VRF. |
Step 3 | Add Bridge Domain to the VRF. |
Step 4 | Create Application Profiles. |
Step 5 | Create EPGs.
See Adding an EPG. |
Step 6 | Add domain to EPGs. |
Step 7 | Add Static path to EPGs. |
Step 8 | Create Contracts.
See Creating Contracts. |
Step 9 | Add contracts to EPGs. |
Verify that Tags, monitoring policy, and security domains for the objects in the APIC account are configured before adding a tenant.
Create users in ACI and assign a security domain to the users or user groups. See User Access, Authentication, and Accounting chapter in Cisco APIC Basic Configuration Guide.
After creating a tenant, create a VRF (also known as a private network) for the tenant.
You can view a list of tenants that are onboarded in Cisco UCS Director and its details.
A Virtual Routing and Forwarding (VRF) is similar to a virtual router that defines a Layer 3 address domain. It is an IP technology that allows multiple instances of a routing table to coexist on the same router at the same time. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflict. For example, a production VRF could be on the same network as the development VRF but the two have different default gateways.
A tenant can have multiple VRFs (also known as private network). One or more bridge domains are associated with a VRF. There are several policies you can associate with a private network, including OSPF and BGP timers, as well as how long end points should be retained.
The following guidelines and limitations apply for virtual routing and forwarding (VRF) instances:
Within a single VRF instance, IP addresses must be unique. Between different VRF instances, you can have overlapping IP addresses.
If shared services are used between VRF instances or tenants, make sure that there are no overlapping IP addresses.
Any VRF instances that are created in common tenant is seen in other user-configured tenants.
VRF supports enforced mode or unenforced mode. By default, a VRF instance is in enforced mode, which means all endpoint groups within the same VRF instance cannot communicate to each other unless there is a contract in place.
Switching from enforced to unenforced mode (or the opposite way) is disruptive.
For more in-depth information, see the Cisco Application Centric Infrastructure Fundamentals Guide.
A Virtual Routing and Forwarding (VRF) object (also known as private layer 3 network in ACI) contains the Layer 2 and Layer 3 forwarding configuration, and IP address space isolation for tenants. Each tenant can have one or more VRFs, or share one default VRF with other tenants as long as there is no overlapping IP addressing being used in the ACI fabric.
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Private Networks. |
Step 7 | Click Add. |
Step 8 | On the Add Tenant Private Network screen, complete the following fields: |
After creating a private network, you create a bridge domain and link it to this VRF.
A bridge domain represents a Layer 2 forwarding construct within the fabric. It helps you to constrain broadcast and multicast traffic. It is a logical container for subnets.
A bridge domain must have at least one subnet associated with it but can contain multiple subnets. When you configure a bridge domain with multiple subnets, the first subnet added becomes the primary IP address on the SVI interface. Subsequent subnets are configured as secondary IP addresses. When the switch reloads, the primary IP address can change unless it is marked explicitly.
One or more EPGs can be associated with each bridge domain. EPGs within the same bridge domain may be configured to talk to each other, but they do not have layer 2 adjacency enabled by default.
Bridge domains in Cisco Application Centric Infrastructure (ACI) have several configuration options to allow the administrator to tune the operation in various ways. To learn more about the various options, see Cisco Application Centric Infrastructure Fundamentals Guide.
Note | Once a bridge domain is configured, its mode cannot be switched. A bridge domain must be linked to a Virtual Routing and Forwarding (VRF). |
A subnet defines the IP address range that can be used within the bridge domain. A bridge domain can contain multiple subnets, but a subnet is contained within a single bridge domain. The scope of a subnet can be public, private, or shared under a bridge domain or an EPG. See Adding a Subnet to a Bridge Domain.
DHCP Relay is required only when the DHCP server is in a different EPG or private network than the clients. DHCP label associates the provider DHCP server with the bridge domain. The DHCP label object also specifies the owner. If your infrastructure requires DHCP relay labels, see Adding a DHCP Relay Label to a Bridge Domain.
Note | The bridge domain DHCP label must match the DHCP Relay name. Label matching enables the bridge domain to consume the DHCP Relay. |
A bridge domain is a unique Layer 2 forwarding domain that contains one or more subnets. Each bridge domain must be linked to a VRF.
Create a Tenant for your customer, organization, or domain and configure your private network.
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Bridge Domains. |
Step 7 | Click Add. |
Step 8 | On the Add Tenant Bridge Domain screen, complete the following fields: |
Step 9 | Click Submit. |
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Bridge Domains. |
Step 7 | On the Bridge Domains page, choose the row with the domain to which you want to add the subnet and click View Details. |
Step 8 | Click Subnet. |
Step 9 | On the Subnet page, click Add. |
Step 10 | On the Add Subnet to Tenant Bridge Domain screen, complete the following fields: |
DHCP Relay is required when the DHCP server is in a different EPG or private network than the clients. A DHCP relay label contains a name for the label, the scope, and a DHCP option policy. The scope is the owner of the relay server and the DHCP option policy supplies DHCP clients with configuration parameters such as domain, nameserver, and subnet router addresses.
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Bridge Domains. |
Step 7 | Click the row with the domain to which you want to add the DHCP label and click View Details. |
Step 8 | Click DHCP Relay Label. |
Step 9 | On the DHCP Relay Label page, click Add. |
Step 10 | On the Add DHCP Label To Tenant Bridge Domain screen, complete the following fields: |
Application profiles are logical containers that define the policies, services, and relationships between End Point Groups (EPGs). Each application profile contains one or more EPG that can communicate with the other EPGs in the same application profile, and with EPGs in other application profiles according to the contract rules. At minimum, associate one application profile with one EPG.
Modern applications contain multiple components. An application profile models the requirements of an application. For example, an e-commerce application could require a web server, a database server, data located in a storage area network, and access to outside resources that enable financial transactions. The application profile contains as many (or as few) EPGs as necessary that are logically related for the e-commerce application.
EPGs can be organized according to one of the following:
The application they provide (such as sap in the example in Appendix A).
The function they provide (such as infrastructure).
Where they are in the structure of the data center (such as DMZ).
Whatever organizing principle that a fabric or tenant administrator chooses to use.
The application profile is a set of requirements that an application instance has on the virtualized fabric. The policy regulates connectivity and visibility among endpoints within the scope of the policy.
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Application Profile. |
Step 7 | Click Add. |
Step 8 | On the Add Tenant Application Profile screen, complete the following fields: |
Step 9 | Click Submit. |
An End Point Group (EPG) is a logical container of endpoints that have common policy requirements such as security, virtual machine mobility (VMM), QoS, or Layer 4 to Layer 7 services. They have an address (identity), a location, attributes (such as version or patch level), and can be physical or virtual. Knowing the address of an endpoint enables access to all its other identity details. Rather than configure and manage endpoints individually, they are placed in an EPG and are managed as a group.
The ACI fabric can contain the following types of EPGs:
Application endpoint group
Layer 2 external outside network instance
Layer 3 external outside network instance
Management endpoint groups for out-of-band or in-band access
By default, all endpoints in the same endpoint group can talk to each other without requiring a contract. Intra-endpoint group (intra-EPG) isolation prevents all endpoints in an EPG from talking to each other but inter-EPG communication is still permitted if there is a contract. This is similar to a private VLAN. For example, assume that you have three endpoints: two are in the client endpoint group, while the other endpoint is in the Web endpoint group. If there is a contract between endpoint groups, they can talk to each other.
Regardless of how an EPG is configured, EPG policies are applied only to the endpoints they contain. For example, to configure a WAN router connectivity to the fabric, you configure an EPG that includes any endpoints within the associated WAN subnet. The fabric learns of the endpoints through a discovery process and applies the policies accordingly.
After creating an EPG, add a static path to the EPG to determine the port and leaf/node for the traffic. See Adding a Static Path to EPG.
You can also add static nodes (leaf, spine, or APIC), and domains (physical, VMM, L3, or L3 external - see examples) to EPGs and define how and when they are deployed. See Adding a Static Node to EPG and Adding a Domain to an EPG.
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Application Profile. |
Step 7 | Click the row with the profile that you want to update and click View Details. |
Step 8 | Click EPG. |
Step 9 | Click Add. |
Step 10 | On the Add Tenant EPG screen, complete the required fields including the following: |
An EPG is associated with domains by being linked to a domain profile, which can be a VMM, physical, Layer 2 external, or Layer 3 external domain.
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Application Profile. |
Step 7 | Click the row with the profile that you want to update and click View Details. |
Step 8 | Click EPG. |
Step 9 | Click the row with the EPG that you want to update and click View Details. |
Step 10 | Click Domain. |
Step 11 | Click Add. |
Step 12 | On the Add Domain To EPG screen, complete the required fields, including the following: |
Static path policies provide a summary of the configured properties of the policy, fault counts, and history for the static path. Configure the static path to the destination EPG.
Note | When an EPG uses a static binding path, the encapsulation VLAN associated with this EPG must be part of a static VLAN pool. |
Contracts must be configured.
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Application Profile. |
Step 7 | Click the row with the profile that you want to update and click View Details. |
Step 8 | Click EPG. |
Step 9 | Click the row with the EPG that you want to update and click View Details. |
Step 10 | Click Static Path. |
Step 11 | Click Add. |
Step 12 | On the Add Static Path To EPG screen, complete the following fields: |
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Application Profile. |
Step 7 | Click the row with the profile that you want to update and click View Details. |
Step 8 | Click EPG. |
Step 9 | Click the row with the EPG that you want to update and click View Details. |
Step 10 | Click Static Node. |
Step 11 | Click Add. |
Step 12 | On the Add Static Node To EPG screen, complete the following fields: |
EPGs can only communicate with other EPGs according to contract rules. Contracts determine the type of traffic that can pass between EPGs, including the protocols and ports allowed. If there is no contract, inter-EPG communication is disabled by default. There is no contract required for intra-EPG communication. A contract contains one or more subjects.
An EPG can both provide and consume the same contract. An EPG can also provide and consume multiple contracts simultaneously.
A subject is a sub-application running behind an endpoint group. A contract can encapsulate multiple subjects. An EPG associates with a subject and defines rules under the association for consuming, providing, or for peer-to-peer communications to that subject. Subjects contain filters and optional labels.
Export Contract feature enables you to export the XML or JSON code for later use with the REST API.
Contracts can contain multiple communication rules and multiple endpoint groups. The relationship between an EPG and a contract can be either a provider or consumer. When an EPG provides a contract, communication with that EPG can be initiated from other EPGs as long as the communication complies with the provided contract. When an EPG consumes a contract, the endpoints in the consuming EPG may initiate communication with any endpoint in an EPG that is providing that contract.
Filters enable you to specify the protocols you want to permit for traffic management between two EPGs. For example, you may want to permit only https traffic. There are several types of filters.
Permit—It allows traffic.
Deny (Taboo)—For specific use cases. You may specify to allow all traffic in a contract, but set up taboos to deny certain traffic.
Redirect—Useful to send traffic from an EPG to a layer 4-7 device such as a firewall, load balancer, or IPS/IDS.
Mark—To mark traffic for Quality of Service reasons.
You can add filters to a contract by adding filter chains (consumer or provider) to contract subjects.
Labels are optional advanced identifiers. When you use labels, you can specify more complex relationships between EPGs. Labels allow for control over which subjects and filters to apply when communicating between a specific pair of endpoint groups. Without labels, a contract applies every subject and filter between consumer and provider endpoint groups. You can use labels to represent a complex communication scenario, within the scope of a single contract, then reuse this contract while specifying only a subset of its policies across multiple endpoint groups.
A Taboo contract provides a way for an EPG to specify the subjects on which communication is not allowed.
Without a contract, the default forwarding policy is to not allow any communication between EPGs but all communication within an EPG is allowed.
Note | If two tenants are participating in same contract, ensure that they are not able to see each other and that their endpoint groups are not able to communicate. |
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Contracts. |
Step 7 | Click Add. |
Step 8 | On the Add Tenant Contract page, complete the following fields: |
Step 9 | Click Submit. |
Create contract subjects to specify the information that can be communicated and the mechanism of communication.
A subject is a sub-application running behind an endpoint group. A contract can encapsulate multiple subjects. An endpoint group always associates with a subject and defines rules under the association for consuming, providing, or for peer-to-peer communications to that subject.
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Contracts. |
Step 7 | Click the row with the contract that you want to update and click View Details. |
Step 8 | Click Contract Subjects. |
Step 9 | Click Add. |
Step 10 | On the Add Tenant Contract Subject page, complete the required fields, including the following: |
Step 11 | Click Submit. |
Create consumer and provider contracts.
Adding Contracts to EPGs
EPGs can only communicate with other EPGs according to contract rules. Contracts determine the types of traffic that can pass between EPGs, including the protocols and ports allowed.
The relationship between an EPG and a contract can be either a provider or consumer. When an EPG provides a contract, communication with that EPG can be initiated from other EPGs as long as the communication complies with the provided contract. When an EPG consumes a contract, the endpoints in the consuming EPG may initiate communication with any endpoint in an EPG that is providing that contract.
An EPG can both provide and consume the same contract. An EPG can also provide and consume multiple contracts simultaneously.
You can associate contracts that were created earlier to create policy relationships between the EPGs. A provided contract is a contract for which the EPG is a provider.
Note | Verify that both provided and consumed contracts have the same name. |
Contracts must be configured.
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Application Profile. |
Step 7 | Click the row with the profile that you want to update and click View Details. |
Step 8 | Click EPG. |
Step 9 | Click the row with the EPG that you want to update and click View Details. |
Step 10 | Click Consumed Contract. |
Step 11 | Click Add. |
Step 12 | On the Add Provided Contract To EPG screen, complete the fields including the following: |
Also need to look into Taboo Contract and Filters.
You can associate contracts that were created earlier to create policy relationships between the EPGs. A consumed contract is a contract for which the EPG is a consumer.
Note | Verify that both provided and consumed contracts have the same name. |
Contracts must be configured.
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Application Profile. |
Step 7 | Click the row with the profile that you want to update and click View Details. |
Step 8 | Click EPG. |
Step 9 | Click the row with the EPG that you want to update and click View Details. |
Step 10 | Click Consumed Contract. |
Step 11 | Click Add. |
Step 12 | On the Add Consumed Contract To EPG screen, complete the fields including the following: |
Contracts must be configured.
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Application Profile. |
Step 7 | Click the row with the profile that you want to update and click View Details. |
Step 8 | Click EPG. |
Step 9 | Click the row with the EPG that you want to update and click View Details. |
Step 10 | Click Consumed Contract Interface. |
Step 11 | Click Add. |
Step 12 | On the Add Consumed Contract Interface To EPG screen, complete the fields including the following: |
Contract Labels
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Contracts. |
Step 7 | Click the row with the contract that you want to update and click View Details. |
Step 8 | Click Contract Subjects. |
Step 9 | Click the row with the contract subject that you want to update and click View Details. |
Step 10 | Click Consumed Label. |
Step 11 | Click Add. |
Step 12 | On the Add Consumed Label to Contract To Contract Subject screen, complete the following fields: |
Step 1 | Choose . |
Step 2 | On the Network page, choose the account under Multi-Domain Managers. |
Step 3 | Click the row with the APIC account and click View Details. |
Step 4 | Click Tenant(s). |
Step 5 | Click the row with the tenant that you want to update and click View Details. |
Step 6 | Click Contracts. |
Step 7 | Click the row with the contract that you want to update and click View Details. |
Step 8 | Click Contract Subjects. |
Step 9 | Click the row with the contract subject that you want to update and click View Details. |
Step 10 | Click Provided Label. |
Step 11 | Click Add. |
Step 12 | On the Add Provided Label to Contract To Contract Subject screen, complete the following fields: |