In network parlance, contracts are a mechanism to create access-lists between two groups of devices.
This function was originally developed in the network via network devices using access-lists and then
eventually managed by firewalls of various types depending on the need for deeper packet inspection.
As the datacenter evolved the complexity of access-lists increased to the point that it was difficult to
maintain. Adding devices to the network that required new access-list modification could become increasingly
more complex to the point that it slowed down changes to the network or the simplification at the edge with
a device that could handle such activities via automation.
As we discussed in ACI devices are grouped into end point groups. This grouping makes it possible to create
policy enforcements of various types, including access-control. Let's dig a little into the world
of Contracts in ACI and how these relate to old access-control of the past.
Contracts
As a general rule always remember that contracts are provided and consumed by EPGs. When you think about these
from a service point of view it becomes more logical to understand. When you look at the following
diagram you can see that the DB EPG is providing a service to the rest of the application. This service is the DB
service and that service is exposed in port 3306.
The EPG is defined with providing a contract to the other devices in the network that are going to use the
database. In this case we can say that they consume the service that is provided
by the database. In a traditional firewall sense, then the configuration could be defined as a
service group that then points to a specific IP address.
object-group service mysql
port-object 3306
!
access-list OUTSIDE-IN extended permit tcp host 1.1.1.1 object-group mysql
But ACI does something very interesting and useful for you as the network administrator. It builds
that access-list under the hood for you in a way that is easier. By defining the policy, in this
case what we call a filter, ACI then uses its EPG device maps and creates the all the matching filters. As
a network administrator, you only have to place devices inside of specific EPGs and they inherit the policies
defined. So, if you add more servers that are providing the service on port 3306, they will be exposed properly
by default when placed in that EPG.
To show this, let's take a more in-depth look at how the external internet traffic can reach the front end
of a web application inside the ACI fabric. Traffic will arrive destined to port 80 or 443
for a secure encrypted connection.
The WEB servers EPG is providing a contract to whoever wants to consume it that says it can be reached
on port 80 or 443. Traffic arrives into the fabric with a source port X but with a destination port
of the web service.
When the external connection of the ACI fabric consumes that contract, then the fabric builds
the policies in the hardware of the fabric for traffic flow. If you look carefully at the diagram, you will see
that there is directionality in the contract that translates directly into how the underlying
access controls are built! As the traffic that arrives is destined to port 80/443, the filters are built
in such a way that it works.
The filters defined in the hardware of the switch will contain the ports and IP addresses as defined in the
policy, simplifying for you the access control policies in the datacenter.
Contract Structure
Contracts are composed of various object elements.
| Component |
Description |
| Subject |
The subject is the highest level object of the contract and it contains all the
filters that determine what traffic flows between the EPGs. |
| Filters |
Filters are the defined objects that specify exactly what port definitions are
to be allowed. These are defined with a complete look into the packet itself. These
include information like Ethertype, IP Protcol, Fragmentation and port ranges. |
|
Duplicate direction
|
When selected, it automatically adds the reverse path access rule.
|
|
Reverse Filter Ports
|
Flips the filter ports for the reverse path access rule.
|
| L4/L7 Service Graph |
Service graphs are a mechanism to "stitch" connectivity between
different network componenets. These make it possible to provide a particular
service and the fabric "route" packets into the service entry point.
|
| QoS |
Define Qos definitions between end point groups.
|
Contract Scope
Contracts have scope in the fabric. This means as to where the contract can apply. These can be:
-
VRF - This contract will be applied for endpoint groups associated with the same context
-
Application Profile - This contract will be applied for endpoint groups in the same application profile
-
Tenant - This contract will be applied for endpoint groups within the same tenant
-
Global - This contract will be applied for endpoint groups throughout the fabric
These scopes provide more granularization with regards to hardware resources and how they are constructed.
It is best practice to configure contracts in the scopes they require. A Global contract makes sense when
creating a contract to a shared resource that is presented or exists in the COMMON tenant.
