This post will list all ACI elements and how they are connected each others.
The draggable diagram has been moved here.
A tenant is a logical container for application policies that enable an administrator to exercise domain-based access control. 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, ACME.Dev or PROD, DEV
- Limits: 1000 to 3000
A VRF is a unique Layer 3 forwarding and application policy domain. 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-VRF, Untrusted-VRF, Production-VRF, Development-VRF, DMZ-VRF
- Where: Tenants/<tenant name>/Networking/VRFs
- Limits: 3000 (400 per tenant)
An application profile defines the policies, services and relationships between endpoint groups (EPGs). Application profiles contain one or more EPGs. Modern applications contain multiple components (web server, database server…). 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-AP, Exchange-AP, vSphere-AP
- Where: Tenants/<tenant name>/Application Profiles
End Point Group
An EPG contains a collection of endpoints. Endpoints are devices that are connected to the network directly or indirectly. EPGs contain endpoints that have common policy requirements (security, VM mobility, QoS, L4-L7 services).
- Warning: a VLAN cannot be shared between different EPGs in the same leaf. And cannot have a mix of tagged and untagged ports.
- Naming Convention (examples): WebServers-EPG, SAP.Servers-EPG, App.FE-EPG, App.BE-EPG
- Where: Tenants/<tenant name>/Application Profiles/<application profile name>/Application EPGs
- Limits: 15000 (500 per tenant, 4000 in a single tenant in a fabric)
A contract defines select the type(s) of traffic that can pass between EPGs. Inter-EPG communication is disabled by default. Intra-EPG communication is always implicitly allowed by default. Intra-EPG communication can be filtered using micro-segmentation.
- Naming Convention (examples): WebServices-Ct, Monitor-Ct, AD.Replication-Ct, AD.Client-Ct
- Where: Tenants/<tenant name>/Contracts/Standard
- Limits: 2000
A set of filters with same properties (directions, service graph, QoS). 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): WebServices-Subj, HTTP-Subj, SSH-Subj
- Where: Tenants/<tenant name>/Contracts/Standard/<contract name>
A filter is a simple ACL defined using L2-L4 fields.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. ACLs can be stateful if TCP is used (default is stateless).
- Warning: don’t use “permit any”, prefer the VRF unenforced mode. Otherwise contract could block traffic between EPGs.
- Naming Convention (examples): HTTP-Fltr, AD-Fltr
- Where: Tenants/<tenant name>/Contracts/Filters
- Limits: 10000
A bridge domain represents a Layer 2 forwarding construct within the fabric. 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): WebServers-BD, NAS-BD, VLAN100-BD (for brownfield installation)
- Where: Tenants/<tenant name>/Networking/Bridge Domains
- Limits: 15000 (21000 in a L2 Fabric)
A subnet is an IP address with mask associated to a bridge domain. 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.
- 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
- 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”
A domain is a group of AEP (which, in the end, groups individual links, port-channels and virtual port-channels) configured in the same way (example: a physical domain is a group of AEPs that share the same VLAN pools). End-host devices (servers or firewall) should be attached to a physical domain, L2 devices (switches) should be attached to an external bridged domains (even if physical domains can be used in both cases).
- Warning: a single trunk cannot carry internal (AVE) and external (default) VLANs.
- Naming Convention (examples): L2Out_to_DC1_internal, L2Out_to_DC2_customer
- Where: Fabric/Access Policies/Physical and External Domains
A set of VLANs associated to one or more domains. Each VLAN pool defines one or more VLAN range. Each VLAN range can be either static or dynamic (used with VMM), external (default) or internal (used with AVE).
- Where: Fabric/Access Policies/Pools/VLAN
A set of policy groups attached to a domain. An AEP is a group of links, port-channels and virtual port-channels attached to a domain. All links grouped by the AAEP must share the same domain (VMM, Physical or External). AEP is not simply “the glue”.
- 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
Defines a single PC/vPC or a set of individual interfaces. A policy group groups one or more interfaces together and apply the same interface policies (CDP, LLDP…). Dedicate a policy group to servers managed by VMM.
- Warning: 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
A specific configuration for a protocol/feature. 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
Leaf (or Spine) Interface Profile
A set of physical interfaces with the same switch profile. 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
Leaf (or Spine) Interface Selector
A sub-configuration of interface profiles to select one or more interfaces and associate them to a policy group. 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>
Leaf (or Spine) Switch Profile
A group of one or more switches associated to a set of interfaces (Interface Profile).
- Naming Convention (examples): LeafsA, LeafsA1, LeafsA1, LeafsA1_FCOE
- Where: Fabric/Access Policies/Switch Policies/Profiles/Leaf Profiles
Leaf (or Spine) Switch Selector
A sub-configuration of switch profiles to select one or more switches and associate them to a switch policy group. A switch profile (partitioned switch) can use ports from one or more leaves, 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>
Leaf (or Spine) Switch Policy Group
Defines a set of switch policies to be associated with one or more switches.
- Where: Fabric/Access Policies/Switch Policies/Policy Group
A specific configuration for a protocol/feature. Each switch can be configured to enable or disable many specific protocols or features (VPC timers, BFD, NetFlow…). A set of policies can be grouped in a switch policy group.
- 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
- Fabric/Global Policies/DHCP Relay
- Tenants/<tenant name>/Policies/Protocol/DHCP Relay
- Mandatories: Name
- Optionals: Providers