Cisco ACI Contracts and Filters: Policy Between EPGs

Cisco ACI does not use ACLs in the traditional sense. Traffic between endpoint groups is
governed by contracts — a contract is a named policy object containing one or
more subjects, each of which references a filter that
describes the permitted traffic. One EPG provides the contract, another consumes it, and the
fabric programs the rules. This model is where most engineers new to ACI lose time, because a
configured contract that nothing consumes does exactly nothing, and a filter with the wrong
direction semantics looks correct but blocks traffic.

The Objects, in Dependency Order

1. Tenant — the policy container. An EPG belongs to a tenant.
2. VRF — the routing and isolation domain. Inter-EPG traffic within a VRF is
   subject to contract enforcement; crossing VRFs requires an inter-VRF contract or an L3Out.
3. Bridge Domain (BD) — the Layer 2 domain; it provides the default gateway
   (SVI) for the EPG's subnet.
4. EPG — a collection of endpoints with the same policy requirements, mapped
   to the fabric through a static path binding or a VMM domain.
5. Filter — the matching rules: protocol, ports, and optionally TCP flags or
   ICMP type.
6. Contract — one or more subjects; each subject references filters and
   carries QoS or logging settings.

The dependency order matters because a contract with no filter has no effect, and a filter
that no contract references is dead configuration that looks alive in the GUI.

Step 1: Build the Filter

Tenant > Contracts > Filters > Create Filter
   Name: web-filters

   Filter Entry 1
     Name:            https
     Ethertype:       IP
     IP Protocol:     TCP
     Destination Port: 443
     Source Port:     (empty)
     TCP Session Rules: Acknowledgment

   Filter Entry 2
     Name:            http
     Ethertype:       IP
     IP Protocol:     TCP
     Destination Port: 80

ACI provides predefined filters in the common tenant — notably
default (permit all) and ICMP — which any tenant can reference. Use
the predefined default filter for initial connectivity testing, then replace it
with an explicit filter before you call the design finished.

Regarding direction: a filter entry typically specifies the destination port of the
connection as initiated. ACI programs the reverse direction automatically for established
sessions. This is why you write one entry for TCP/443 rather than two, and why writing both
directions explicitly can produce confusing rule counts. The filtering rules are not stateless
ACLs in the IOS sense.

Step 2: Create the Contract

Tenant > Contracts > Standard > Create Contract
   Name:  web-contract
   Scope: context      (VRF-scoped; use "tenant" or "global" deliberately)

   Subject: web-access
     Apply Both Directions:  yes
     Reverse Filter Ports:   enabled
     Filters: web-filters

   (optional) Subject settings
     QoS Class:             Level3
     Logging:               enabled for audit
     Action:                permit

Contract scope is a design decision with security implications:

• VRF (context) — the default and the most contained. Rules are programmed
  only within the VRF.
• Tenant — allows the contract to be consumed and provided by EPGs in
  different VRFs within one tenant.
• Global — allows the contract to program rules across any tenant in the
  fabric. Wide blast radius; use only for genuinely shared services.

For inter-VRF communication, ACI applies policy enforcement in the consumer's
VRF. That detail changes where you look when traffic is dropped, and it is worth writing down
in your design document.

Step 3: Bind the Contract to EPGs

# Provider side — the EPG that offers the service
Tenants > TENANT > Application Profiles > AP > EPG-WEB > Contracts
   Provided Contracts:   web-contract

# Consumer side — the EPG whose traffic needs access
Tenants > TENANT > Application Profiles > AP > EPG-APP > Contracts
   Consumed Contracts:   web-contract

A contract must be both provided and consumed for traffic to flow. Half-configured contracts
are the single most common reason "nothing works" in a new ACI tenant, and the fabric provides
no error message — the rules simply are not programmed.

# Verify from the CLI on the APIC
# Show EPG details including provided and consumed contracts
show epg EPG-WEB detail
show epg StaticEPG detail

# Show the tenant's configuration for a specific application
show running-config tenant TENANT application AP

Step 4: Intra-EPG Isolation

Endpoints within a single EPG talk freely by default. When an EPG is a flat
untrusted subnet — a guest network, an OT segment — enable intra-EPG isolation so endpoints in
the same EPG cannot reach each other.

Tenants > TENANT > AP > EPG > Intra EPG Isolation: Enforced

ACI implements this with a primary VLAN (PVLAN) tag. For VMM domains, the fabric creates an
isolated PVLAN port group on the vSwitch. Be aware that isolation is either enforced for all
network domains or none — it is not a per-domain setting.

Verifying That Policy Is Actually Programmed

# On the APIC
show epg EPG-APP detail
moquery -c vzBrCP -f 'vzBrCP.name=="web-contract"'
moquery -c vzFilter -f 'vzFilter.name=="web-filters"'
moquery -c fvRsCons -f 'fvRsCons.tnVzBrCPName=="web-contract"'

# Faults worth reading instead of ignoring
#   Fabric > Faults — contract and EPG faults
#   "Contract not provided/consumed" and "EPG not deployed" are the useful ones

# Endpoint and path information
show endpoint ip 10.10.90.15 detail
show interface ethernet 1/1 spanning-tree

The moquery commands are the fastest way to answer "is this object what I think
it is" without clicking through the GUI, and they expose relationships — fvRsCons
and fvRsProv objects are the actual bindings that make a contract work.

Design Habits

• One contract per directional intent, named for the service
  (web-contract, db-client-contract), not contract-01.
• Start with the predefined default filter for connectivity, then narrow to
  explicit filters. Ship the narrowed version, not the test version.
• Prefer VRF-scoped contracts. Reach for tenant or global scope only when the service
  genuinely spans VRFs or tenants.
• Keep an explicit deny philosophy at the application profile level by not providing
  contracts you do not intend — the fabric's default is deny between EPGs.
• Log the contracts that guard regulated traffic; ACI supports logging per contract subject.
• For the Layer 2 constructs behind all this — bridge domains, EPG types, static versus
  dynamic paths — the APIC Layer 2 configuration guide is the reference. On the overlay side,
  Arista EOS EVPN-VXLAN symmetric IRB is a useful contrast to ACI's policy-driven fabric, and Cisco Nexus 9000 ERSPAN configuration covers the packet-capture path when you need to prove what the fabric is actually doing.

原文链接：https://www.cisco.com/c/en/us/products/collateral/networking/cloud-networking/application-centric-infrastructure/contract-guide.html