Filters & Contracts Configuration

Filters & Contracts Configuration

Contract

A contracts is a rule or policy which defines how EPGs will communicate to each other. By default all communication is stopped between EPGs, to allow communication between EPGs , a contracts must be defined or unless the VRF instance is configured as “unenforced”. But a communication within EPG contracts is not required.

Below diagram defines the relationship between EPGs and contracts.

In above figure, the WEB EPG is consuming the contracts whereas APP EPG is providing the same Contracts. Similarly the DB EPG provides the separate contracts that APP EPG consumes.

Contracts have following use or goals in ACI:

• Define an ACL to allow communication between security zones as filters
• Provides the route leaking between VRFs or tenants.

Below figure shows how contracts are configured between EPGs

Contracts are just like security ACL that is configured between EPGs. Forwarding of traffic between endpoints is based on routing as defined by VRF configuration and BD, whereas endpoints communication between EPGs depends upon filtering rules defines by contracts.

Below figure defines the above said statements.

Filters & Subjects

Filters are rules which includes fields such as source Port, Dest Port, Source IP, Dest IP, Protocol types which are then further attached to contracts that defines communication between EPS in fabric. A filter can contain more than one rules. A subject is a construct contained within contracts and typically referenced a filter.

Contracts that contain filters rule must have direction. Example: consumer-to-provider or provider-to-consumer

In Contracts rule don’t include IP address because traffic is filtered based on EPG definition.

Below are Some Configuration items that are used while creating Contracts.

• Filter: It is used to define Source & Destination IP, Port, Protocol and its relation between them to allow traffic or deny traffic.
• Deny (taboo): When we want to allow all ACI traffic in a contract but to deny certain traffic. Example: used during migration from Legacy network to ACI.
• Redirect: This is used when there is a requirement to send the traffic from EPG to layer 4 through Layer 7 device such as Firewall, LB, and IPS/IDS.
• Mark: used to mark traffic for QOS
• Label: It is an identifier in a filter, to specify a complex relationship between endpoints.
• Subjects: It contains a filter with an action.

Contract Preferred Groups

Contract preferred groups enable greater control of communication between EPGs in a VRF instance. If most of the EPGs in a VRF instance should have open communication but a few should have only limited communication with the other EPGs, you can configure a combination of a contract preferred group and contracts with filters to control inter-EPG communication precisely.

Two types of policy enforcements in a VRF instance are available for EPGs with a contract preferred group configured:

• Included EPGs: EPGs can freely communicate with each other without contracts if they have membership in a contract preferred group. This is based on the source-any-destination-any-permit default rule.
• Excluded EPGs: EPGs that are not members of preferred groups require contracts to communicate with each other. Otherwise, the default source-any-destination-any-deny rule applies.

EPGs that are excluded from the preferred group can communicate with other EPGs only if there is a contract in place to override the source-any-destination-any-deny default rule

How Contracts works in ACI

Service Graph uses the Contrast to stitch the Traffic between two EPG with a service node in between.

When an EPG is created, it is represented by a numeric value called as Policy Control tag or PCTag and also as soon as any VRF is created, APIC assigns a scope or Segment ID, as shown in below figure

Source EPG is assigned a PCTag and is represented by sClass, whereas destination EPG by PCTag. When a Source EPG wants to talk to destination EPG, a proper filter configuration (Permit/ Deny) and its related Contracts must be in place. As soon as Contracts are configuration is done on APIC and ACI fabric realizes the traffic matching to the EPG, It applies policies related to these EPG via these PCTags on Leaf Switch

This can be very well described in above figure where Web EPG (16387) wants to talk to Destination DB EPG (16388) under VRF Scope 2785280. Contracts related to this communication permits the traffic.

vzANY

The vzAny managed object allows you to efficiently associate all EPGs in a VRF instance to one or more contracts (vzBrCP) instead of creating a separate contract object relationship for each EPG.

In the Cisco ACI fabric, EPGs can only communicate with other EPGs according to contract rules in Enforced mode. A relationship between an EPG and a contract specifies whether the EPG provides the communications defined by the contract rules, consumes them, or both.

By dynamically applying contract rules to all EPGs in a VRF, vzAny automates the process of configuring EPG contract relationships. Whenever a new EPG is added to a VRF, vzAny contract rules automatically apply and control the traffic forwarding.

 The vzAny contract consumes less TCAM memory of fabric physical infrastructure and is the most efficient way of applying security policies in ACI. TCAM entries are generally specific to each EPG pair. In other words, even if the same contract is reused, new TCAM entries are installed for every EPG pair group that requires restrictive communication.

Bidirectional & Reverse Filter Options

When a contracts are configured, there are two options which are typically selected by default.

• Apply Both Direction
• Reverse Filter Ports

The below figure defines the relationship of communication between EPGs, where EPG-1 is consumer and EPG-2 is provider and EPG-1 wants to talk to EPG-2 on destination port 80.

If you enable apply both direction as shown in fig below , it will program two TCAM entries : One that allow source port unspecified to talk to destination port 80 in consumer-to-provider direction, and second  for provider-to-consumer direction where source port is unspecified to talk to destination port 80.

But as per configuration, it is not correct, because provider (EPG-2) would generate traffic from port 80 and not to port 80.