The ACI fabric provides multiple attachment points that connect through leaf ports to various external entities such as bare-metal servers, virtual machine hypervisors, Layer 2 switches (for example, the Cisco UCS fabric interconnect), or Layer 3 routers (for example, Cisco Nexus 7000 Series switches). These attachment points can be physical ports, FEX ports, port channels, or a virtual port channel (vPC) on leaf switches.
An Attachable Entity Profile (AEP) represents a group of external entities with similar infrastructure policy requirements. The infrastructure policies consist of physical interface policies that configure various protocol options, such as Cisco Discovery Protocol (CDP), Link Layer Discovery Protocol (LLDP), or Link Aggregation Control Protocol (LACP).
An AEP is required to deploy VLAN pools on leaf switches. Encapsulation blocks (and associated VLANs) are reusable across leaf switches. An AEP implicitly provides the scope of the VLAN pool to the physical infrastructure.
The following AEP requirements and dependencies must be accounted for in various configuration scenarios, including network connectivity, VMM domains, and multi-pod configuration:
The AEP defines the range of allowed VLANs, but it does not provision them. No traffic flows unless an EPG is deployed on the port. Without defining a VLAN pool in an AEP, a VLAN is not enabled on the leaf port even if an EPG is provisioned.
A particular VLAN is provisioned on a leaf interface either through static port binding or based on VM events from external controllers such as VMware vCenter or Microsoft Azure Service Center Virtual Machine Manager.
Attached entity profiles can be associated directly with application EPGs, which deploy the associated application EPGs to all those ports associated with the attached entity profile. The AEP has a configurable generic function, which contains a relation to an EPG that is deployed on all interfaces that are part of the selectors that are associated with the attachable entity profile.
ACI Contract
A contract is the policy that an ACI administrator uses to control traffic flow within the ACI fabric and between endpoint groups. These contracts are built using a provider/consumer model where one endpoint group provides the services it wants to offer (the provider) and another endpoint group consumes them (the consumer). Contracts are assigned a scope of global, tenant, VRF, or application profile, which limits the accessibility of the contract.
Contracts consist of one or more subjects. Each subject contains one or more filters. Each filter contains one or more entries. Each entry is equivalent to a line in an access control list (ACL) that is applied on the leaf switch to which the endpoint within the endpoint group is attached.
Specifically, contracts are composed of the following items:
Subjects: A group of filters for a specific application or service.
Filters: Feature used to classify traffic based on Layer 2 to Layer 4 attributes (such as Ethernet type, protocol type, TCP flags, and ports).
Actions: Predefined act to be taken on the filtered traffic. The following actions are supported:
Permit the traffic (regular contracts, only).
Mark the traffic (DSCP/CoS) (regular contracts, only).
Redirect the traffic (regular contracts, only, through a service graph).
Copy the traffic (regular contracts, only, through a service graph or SPAN).
Block the traffic (taboo contracts, only).
Log the traffic (taboo contracts, only).
Labels: (Optional) Tags used to group objects such as subjects and endpoint groups for the purpose of increasing granularity in policy enforcement.
While different endpoint groups can only communicate with other endpoint groups based on the contract rules defined, there is no contract required for intra-endpoint group communication. Intra-endpoint group communication from endpoint to endpoint in the same endpoint group is allowed by default.
If a filter allows traffic from any consumer port to a provider port (for example, 8888), if reverse port filtering is enabled and the contract is applied in both directions (say for TCP traffic), either the consumer or the provider can initiate communication. The provider could open a TCP socket to the consumer using port 8888, whether the provider or consumer sent traffic first.
If you do not configure a contract, traffic is permitted only for the following types of packets as well as the types that are permitted by default for multicast traffic and class equal traffic. These packets must match specific IPv4 and IPv6 packets, identified by protocol type, protocol ID (prot), source port (sport) and destination port (dport):
