The Cisco ACI Workflow (work in progress)


This post will list all ACI elements and how they are connected each others.

The draggable diagram has been moved here.


  • What: A tenant is a logical container for application policies that enable an administrator to exercise domain-based access control.
  • Why: 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. Tenants can be isolated from one another or can share resources. Tenants are logical containers for application policies. The fabric can contain multiple tenants.
  • Naming Convention (examples): ACME, or PROD, DEV
  • Mandatories: Name (tenant name)
  • Optionals: Alias, Description, Tags, GUID, Monitoring Policy, Security Domains, VRF Name
  • Limits: 1000 to 3000


  • What: A VRF is a unique Layer 3 forwarding and application policy domain.
  • Why: A VRF defines a Layer 3 address domain. One or more bridge domains are associated with a VRF. All of the endpoints within the Layer 3 domain must have unique IP addresses because it is possible to forward packets directly between these devices if the policy allows it. A tenant can contain multiple VRFs.
  • Naming Convention (examples): Trusted, Untrusted, Production, Development
  • Where: Tenants/<tenant name>/Networking/VRFs
  • Mandatories: Name, Policy Control Enforcement Preference, Policy Control Enforcenment Direction
  • Optionals: BD Enforcement Status, Endpoint Retention Policy, Monitoring Policy, DNS Labels, Route Tag Policy, Create A Bridge Domain, Configure BGP Policies, Configure OSPF Policies Configure EIGRP Policies
  • Limits: 3000 (400 per tenant)

Application Profile

  • Scope: inside a tenant
  • What: An application profile defines the policies, services and relationships between endpoint groups (EPGs).
  • Why: Application profiles contain one or more EPGs. Modern applications contain multiple components. 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 to providing the capabilities of an application.
  • Naming Convention (examples): SAP, Exchange, vSphere
  • Where: Tenants/<tenant name>/Application Profiles
  • Mandatories: Name
  • Optionals: Alias, Description, Tags, Monitoring Policy, EPGs

End Point Group

  • What: An EPG is a managed object that is a named logical entity that contains a collection of endpoints. Endpoints are devices that are connected to the network directly or indirectly.
  • Why: EPGs contain endpoints that have common policy requirements such as security, virtual machine mobility (VMM), QoS, or Layer 4 to Layer 7 services. Rather than configure and manage endpoints individually, they are placed in an EPG and are managed as a group. An EPG can be linked to a BD from the EPG itself. Rememer that a same VLAN cannot be shared between different EPGs in the same leaf.
  • Naming Convention (examples): Web, App, App-Tier1, App-Tier2
  • Where: Tenants/<tenant name>/Application Profiles/<application profile name>/Application EPGs
  • Mandatories: Name, Intra EPG Isolation, Preferred Group Member, Flood on EncapsulationBridge Domain,
  • Optionals: Alias, Description, Tags, QoS class, Custom QoS, Data-Plane Policer, Monitoring Policy, FHS Trust Control Policy, Associate to VM Domain Profiles, Statically Link with Leaves/Paths, EPG Contract Master
  • Limits: 15000 (500 per tenant, 4000 in a single tenant in a fabric)


  • What: A contract defines select the type(s) of traffic that can pass between EPGs.
  • Why: If there is no contract, inter-EPG communication is disabled by default. There is no contract required for intra-EPG communication; intra-EPG communication is always implicitly allowed by default. Inter-EPF communication can be also filtered.
  • Naming Convention (examples): Web_to_App
  • Where: Tenants/<tenant name>/Contracts/Standard
  • Mandatories: Name, Scope
  • Optionals: Alias, QoS Class, Target DSCP, Description, Tags, Subjects
  • Limits: 2000


  • What: A set of filters with same properties (directions, service graph, QoS).
  • Why: Subjects are contained in contracts. One or more subjects within a contract use filters to specify the type of traffic that can be communicated and how it occurs. Subjects determine if filters are unidirectional or bidirectional.
  • Naming Convention (examples): WebTraffic
  • Where: Tenants/<tenant name>/Contracts/Standard/<contract name>
  • Mandatories: Name
  • Optionals: Alias, Description, Target DSCP, Apply Both Directions, Reverse Filter Ports, Filter Chain


  • What: A simple ACL.
  • Why: Filters are Layer 2 to Layer 4 fields, TCP/IP header fields such as Layer 3 protocol type, Layer 4 ports, and so forth. According to its related contract, an EPG provider dictates the protocols and ports in both the in and out directions. Contract subjects contain associations to the filters (and their directions) that are applied between EPGs that produce and consume the contract.
  • Naming Convention (examples): HTTP
  • Where: Tenants/<tenant name>/Contracts/Filters
  • Mandatories: Name
  • Optionals: Alias, Description, Entries
  • Limits: 10000
  • Best Practices: When a contract filter match type is All, best practice is to use the VRF unenforced mode. Under certain circumstances, failure to follow these guidelines results in the contract not allowing traffic among EPGs in the VRF.

Bridge Domain

  • What: A bridge domain represents a Layer 2 forwarding construct within the fabric.
  • Why: The BD defines the unique Layer 2 MAC address space and a Layer 2 flood domain if such flooding is enabled. If unicast routing is enabled, it must have at least one subnet associated with it. A Bridge Domain can be linked to a VRF from the BD itself.
  • Naming Convention (examples): Web, App, App-Tier1, App-Tier2
  • Where: Tenants/<tenant name>/Networking/Bridge Domains
  • Mandatories: Name<, Type
  • Optionals: Alias, Description, VRF, Forwarding, Endpoint Retention Policy, IGMP Snoop Policy
  • Limits: 15000 (21000 in a L2 Fabric)


  • What: A subnet is an IP address with mask associated to a bridge domain.
  • Why: It’s optional, because a pure L2 ACI Fabric doesn’t need any IP addresses, but it’s suggested because it’s a prerequisite to enable IP learning. Multiple subnet can be associated to a single bridge domain, one is set as primary, others are secondaries. Primary subnet affects DHCP relay only.
  • Naming Convention (examples): Web, App, App-Tier1, App-Tier2
  • Where: Tenants/<tenant name>/Networking/Bridge Domains/<BD name>/Subnets
  • Mandatories: Name, Type
  • Optionals: Alias, Description, VRF, Forwarding, Endpoint Retention Policy, IGMP Snoop Policy
  • Limits: 1000 (not all under a single BD)

External Bridged Network

  • Where: Tenants/<tenant name>/Networking/External Bridged Networks

External Routed Network

  • Where: Tenants/<tenant name>/Networking/External Routed Networks

External Network

  • Where: Tenants/<tenant name>/Networking/External Routed Networks/<routed outside>/Networks

Logical Node Profile

  • Where: Tenants/<tenant name>/Networking/External Routed Networks/<routed outside>/Logical Node Profiles
Logical Interface Profile
  • Where: Tenants/<tenant name>/Networking/External Routed Networks/<routed outside>/Logical Node Profiles/<node name>/Logical Interface Profiles”



  • What: the representation for internal or external physical links with a set of common VLANs
  • Why: a domain is a group of AAEP (which, in the end, groups individual links, port-channels and virtual port-channels) with a set of common VLANs. If a set of VLANs from a single link must be imported into ACI, they must be both of the same type (for example physical internal domain, or physical external domain). We cannot have a single trunk carrying a VLAN defined as internal, and another VLAN defined as external. By the way end-host devices (like servers or firewall) should be attached to a physical domain, L2 devices (like switches) should be attached to an external bridged domains (even if physical domains can be used for both hosts and switches).
  • Naming Convention (examples): L2Out_to_DC1_internal, L2Out_to_DC2_customer
  • Where: Fabric/Access Policies/Physical and External Domains


  • Where: Fabric/Access Policies/Pools/VLAN


  • What: a set of policy groups attached to a domain
  • Why: an AAEP is a group of links, port-channels and virtual port-channels (at the end, a policy groups is a group of physical links). All links grouped by the AAEP must share the same physical domain. In other words, all links can be (for example) configured as a physical domain or physical external domain, but not both. Just consider an AAEP as a subgroup for a specific domain. A single AAEP could be used for a single customer configuration with a single VLAN pool allowing all VLANs. Installation with more customers and/or more VLAN pools could requires more AAEP.
  • Naming Convention (examples): depending on VLAN pools, tenants, L2 internal and external devices…
  • Where: Fabric/Access Policies/Global Policies/Attachable Access Entity Profiles

Interface Policy Group

  • What: defines a single PC/vPC or a set of individual interfaces
  • Why: a policy groups one or more interfaces together and apply the same interface policies (CDP, LLDP…). Individual interfaces with same policies, can share the same policy group. Each port-channel or virtual port-channel must have it’s own policy groups, because the policy group, at the and, define the ID of the port-channel into the leafs.
  • Naming Convention (examples): individualports_to_ESXis, vPC_to_Firewall1, PC_to_Switch1
  • Where: Fabric/Access Policies/Interface Policies/Policy Groups

Interface Policy

  • What: a specific configuration for a protocol/feature
  • Why: each interface can be configured to enable or disable many specific protocols or features. For example LLDP could be active, while CDP no. A set of policies can be grouped in a interface policy group.
  • Naming Convention (examples): CDP_on, LLDP_on, LACP_active, BPDU_guard, BPDU_filter
  • Where: Fabric/Access Policies/Interface Policies/Policies

Interface Profile

  • What: a set of physical interfaces with the same configuration
  • Why: it should contains the interfaces used for a specific purpose (connected to a single ESXi server for example) and facing the same set of leaves.
  • Naming Convention (examples): ports_to_ESXi01, ports_to_Switch1A
  • Where: Fabric/Access Policies/Interface Policies/Profiles/Leaf Profiles

Interface Selector

  • What: a sub-configuration of interface profiles to select one or more interfaces and associate them to a policy group
  • Why: an interface profile can use contiguous or non contiguous ports. Each group is associated to a specific policy group.
  • Naming Convention (examples): ports_1_13, ports_1_13-15
  • Where: Fabric/Access Policies/Interface Policies/Profiles/Leaf Profiles/<leaf profile name>

Switch Profile

  • What: a group of one or more switch associated to a set of interfaces
  • Why: a switch profile associates a set of switches (configured via switch policy group) to a set of groups of interfaces (interface profiles). Each group of interfaces is configured with a specific policy group. In other words, a switch profile configures some leafs and can be shared among multiple interfaces even if interfaces are dedicated to differents devices. Switch profiles can be shared between entities.
  • Naming Convention (examples): LeafsA, LeafsA1, LeafsA1, LeafsA1_FCOE
  • Where: Fabric/Access Policies/Switch Policies/Profiles/Leaf Profiles

Switch Selector

  • What: a sub-configuration of switch profiles to select one or more switches and associate them to a switch policy group
  • Why: a switch profile (partitioned switch) can use ports from one or more leafs, each leaf can be configured with a specific switch policy group.
  • Naming Convention (examples): LeafsA, LeafsA1, LeafsA2
  • Where: Fabric/Access Policies/Switch Policies/Profiles/Leaf Profiles/<leaf profile name>

Switch Policy Group

  • Where: Fabric/Access Policies/Switch Policies/Policy Group

Switch Policy

  • Where: Fabric/Access Policies/Switch Policies/Policies

Defined as global or as local

DHCP Relay Policy

  • What: A DHCP Relay Policy configures the DHCP servers and the associated EPG so they can be used by the relay server.
  • Why: DHCP Relay policies can be defined as global or local (inside a tenant) and are referenced by bridge domains.
  • Naming Convention (examples): Tenant:DHCPServer1, DHCPServer1
  • Where:
    • Fabric/Global Policies/DHCP Relay
    • Tenants/<tenant name>/Policies/Protocol/DHCP Relay
  • Mandatories: Name
  • Optionals: Providers
Posted on 20 Mar 2018 by Andrea.
  • Gmail icon
  • Twitter icon
  • Facebook icon
  • LinkedIN icon
  • Google+ icon