Contracts in ACI

Contracts in ACI

Contracts provide a way for the Cisco ACI administrator to control traffic flow within the Cisco ACI fabric between EPGs. Contracts are built using a provider-consumer model, where one EPG provides the services that it wants to offer, and another EPG consumes the services.
Basically, 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 an Access Control Entry (ACE) in an access control list (ACL) that is applied between EPGs.

Hence, the contract filters are typically to allow a certain type of traffic instead of deny. However, just like a normal ACL, deny filter can also be created if needed.

The following are the core principles of contracts:

• Define the policies using subjects and filters (type of traffic to allow or deny) between EPGs.

• By default, communication between EPGs is not allowed without a contract.

• Direction of the traffic is based on how contract is attached to EPGs (provider/consumer).

Contract Provider-Consumer Model

The figure shows the basic three-tiered web application that was used previously, with two additional EPGs that you may likely have in the real world.

In this example, only HTTP/HTTPs is allowed by a contract from EPG Client to EPG Web since that’s the only service EPG Web needs to provide to clients. Based on the client’s request via HTTPS, EPG Web needs to access to back-end (EPG App). Between EPG Web and App, only TCP Port X is required for this service. Hence, a contract for TCP Port X is “provided” by EPG App and “consumed” by EPG Web. Same thing goes for EPG App and EPG DB.

Structure of Contracts

Contracts define the relationship between application tiers such as L3–L4 traffic filters and L4–L7 services.

Contracts contain the following items:

• Subjects: It manages the direction of traffic type defined by filters. For example, if the filter is TCP port src-any to dst-22, a subject decides src is the consumer and DST is the provider, or vice versa. It typically bundles multiple filters required for a specific application or service with the same need of the direction and the following options:

  1. Apply Both Direction (directly related to the direction of filters)

  2. Reverse Filter Ports (directly related to the direction of filters)

  3. Layer 4 to Layer 7 Service Graph

  4. QoS

• Filters: Define a traffic type used in a contract such as destination TCP ports.

• Actions: Define permit or deny for each filter (traffic type). Typically only permit is used as other traffic type will be denied due to allow list model.

Contracts have an attribute called scope (Global, Tenant, VRF, or Application Profile). The scope attribute decides the scope of provider and consumer. For example, if the contract scope is VRF with the provider EPG in VRF1 and the consumer EPG in VRF2, each EPG will not recognize the other end of contract and traffic will not be allowed since the contract scope is within VRF. In VRF Route Leaking, the scope needs to be Tenant or Global to allow the contract to be applied across VRF.

Subjects

Subjects bundle filters and decide in which direction (consumer -- provider or provider -- consumer) the filters should be applied.

Subjects determine if filters are unidirectional or bidirectional. A unidirectional filter presented above is used in one direction; you specify the source port (any) and destination port (X in the example). Traffic from consumer EPG to provider EPG will be allowed if destination TCP port is equal to X. Traffic from EPG App back to EPG Web is not allowed in the example above.Regarding the direction of traffic, subjects offer two options to minimize the configuration, which is enabled by default.