Cisco ACI expresses application connectivity through an object model rather than traditional interface-by-interface firewall rules. The 350-601 DCCOR scope includes ACI and data-center security because engineers need to understand how tenants, VRFs, bridge domains, endpoint groups, and contracts combine to create forwarding and policy behavior.
The broad Cisco ACI architecture is easiest to operate when each object has a clear role: the VRF defines the Layer 3 routing domain, bridge domains provide Layer 2/subnet context, EPGs classify endpoints, and contracts define permitted communication between policy groups. Confusing these roles leads to designs that technically forward traffic but are difficult to reason about or secure.
VRFs create the Layer 3 policy domain
An ACI VRF provides the tenant routing context and isolates Layer 3 forwarding state from other VRFs. Multiple bridge domains can attach to the same VRF, which lets endpoints in different subnets share a routing domain while remaining in separate Layer 2 segments. A design with too many VRFs can become operationally heavy; a design with too few can combine security domains that should be isolated.
VRF enforcement mode also matters. In the normal enforced model, inter-EPG communication requires contracts unless a feature such as preferred groups or vzAny changes the default behavior. Using unenforced mode may ease a migration, but it changes the security model fundamentally because endpoints inside the VRF can communicate without normal contract enforcement.
Bridge domains connect subnets to the VRF
A bridge domain defines Layer 2 forwarding behavior and can carry one or more subnets. It associates with a VRF and can connect to EPGs. The relationship between an EPG and a bridge domain is not simply a VLAN mapping: the bridge domain is the Layer 2 and gateway context, while the EPG is a policy classification of endpoints.
During troubleshooting, confirm that the endpoint is learned in the expected EPG and bridge domain, that the bridge-domain subnet/gateway is correct, and that the VRF contains the required route. A contract cannot fix a missing route, and a correct route cannot override a contract denial. Separating forwarding state from policy state is one of the most important ACI troubleshooting habits.
EPGs classify endpoints by policy role
Endpoint groups collect endpoints that should receive the same policy treatment. Classification can be based on static port/VLAN bindings, VMM integration, domains, or other mechanisms depending on the deployment. The EPG should represent a meaningful application or security role rather than simply mirroring every VLAN name from a legacy network.
Poor EPG design creates policy sprawl. If each individual server becomes its own EPG without a clear reason, contracts multiply and the policy model becomes difficult to audit. If unrelated applications are grouped into one EPG, microsegmentation is lost. The right granularity follows policy intent: endpoints that need the same allowed communication and operational lifecycle can usually share an EPG.
Contracts are allow-list relationships
ACI contracts define what traffic a provider EPG permits and what a consumer EPG may use. Filters describe protocol and port matches, subjects combine filters and actions, and the contract creates the relationship between groups. The default enforced model is therefore closer to an allow list than to a traditional network where all routed subnets communicate unless an ACL blocks them.
This policy model is central to ACI SDN concepts. A missing contract can make two endpoints with valid routes and healthy fabric reachability unable to communicate. Conversely, a very broad permit-any contract can undermine the segmentation that EPG design was intended to provide. Contract scope and filter specificity should be treated as security architecture, not merely connectivity troubleshooting.
Contract scope changes how widely policy can be used
Contract scope determines whether a contract is available within an application profile, tenant, VRF, or more broadly according to the supported model. Inter-VRF or cross-tenant designs require careful attention to scope, export/import relationships, and route leaking. A contract alone does not automatically create the Layer 3 reachability needed between separate VRFs.
When cross-VRF traffic fails, check both halves of the design: whether routes are leaked between the relevant VRFs and whether policy classification/contract enforcement permits the flow. Troubleshooting only the contract can miss a routing problem; troubleshooting only the route can miss the policy denial. The two mechanisms are intentionally separate so reachability and authorization can be controlled independently.
vzAny, preferred groups, and migration shortcuts
Features such as vzAny and preferred groups can reduce the number of point-to-point contracts in large tenants. vzAny represents the collection of EPGs in a VRF and can receive contracts that apply broadly. Preferred groups allow selected EPGs to communicate without explicit contracts while other EPGs remain subject to policy. These features can simplify migration or common-service access.
They also widen policy scope, so convenience must be balanced against least privilege. A broad vzAny contract can become the ACI equivalent of a permissive network ACL if filters are not carefully constrained. Preferred groups should not become a permanent bucket for every application that is difficult to model. Use them deliberately, document why they exist, and review whether a more explicit policy should replace them after migration.
Inter-EPG traffic and contract direction
Contracts are directional in terms of provider and consumer roles even though many application flows are bidirectional at the transport layer. A web EPG may provide HTTPS to an application EPG that consumes it. Response traffic for an allowed stateful flow is handled according to the fabric policy behavior, but initiating traffic in the opposite direction may require a separate relationship depending on the design.
Misunderstanding provider/consumer direction is a common cause of ACI policy confusion. Use the application transaction to decide who provides the service, not the physical packet direction observed in one capture. Then verify the endpoint classification and contract relationship from the controller object model before inspecting low-level zoning rules on a leaf.
Operational verification from APIC to leaf
Start with APIC health and endpoint visibility. Confirm both endpoints, their EPGs, bridge domains, and VRF. Verify route reachability if the flow crosses subnets. Then inspect consumed/provided contracts, filters, and subject rules. If the policy appears correct, use policy-resolution tools and leaf zoning-rule inspection to confirm that the expected permit rule was programmed in hardware.
Physical connectivity still matters. If an EPG uses static bindings or vPC-connected access, the underlying attachment must be healthy; the ACI vPC design can affect which leaf learns an endpoint and how traffic reaches dual-homed devices. ACI policy does not eliminate cabling, VLAN, MTU, or routing problems—it gives those problems a controller-driven context.
Design for policy readability
A maintainable ACI tenant uses names that reveal application intent, keeps VRF and bridge-domain boundaries purposeful, and avoids contract duplication. Common filters can be reused where semantics truly match, while application-specific contracts should remain explicit. The goal is that an engineer can look at a consumer EPG, provider EPG, and contract name and understand the business communication being allowed.
ACI troubleshooting across Cisco data-center certifications becomes much more predictable when each object has one clear responsibility: VRFs define the routing domain, bridge domains define the Layer 2/subnet context, EPGs group endpoints by policy, and contracts define permitted communication. Once those roles are explicit, advanced features such as inter-VRF contracts, vzAny, preferred groups, and service graphs can be added without turning the tenant into an opaque policy graph.
Endpoint classification is a critical diagnostic checkpoint because policy follows the endpoint’s class identity. A server attached to the wrong EPG can have valid IP addressing and still receive an entirely different contract set. During incidents, confirm the endpoint’s learned location, EPG, encapsulation, and class ID before changing filters. Otherwise, operators may broaden a contract when the real problem is misclassification.
Policy scale should also be considered in the object model. Reusing filters and sensible application groupings can reduce duplicated rules, while extremely granular EPG-to-EPG contracts can consume hardware policy resources and become difficult to review. That does not justify broad permits; it means segmentation should follow meaningful trust boundaries and application flows. ACI gives architects several ways to reduce policy repetition, but each has a security trade-off that must be documented.
Changes to contracts should be validated with representative traffic before and after deployment. A new filter may permit the expected TCP port but break related control traffic or a health check. Conversely, an expanded filter can expose more service than intended. Use endpoint-level tests, policy-resolution tools, and leaf counters to verify both the allowed flow and a flow that should remain denied. Negative testing is part of proving least-privilege policy.
Service insertion adds another layer when contracts redirect flows through a firewall or other L4-L7 device. In that design, the contract is not merely a permit rule; it can become the steering point for a service graph or policy-based redirect. Troubleshooting must then verify the contract match, redirection policy, service-node health, and return path. A healthy endpoint-to-endpoint route can still fail if the service node is unavailable or asymmetric. Architects should keep service insertion scoped to flows that actually need it and document failure behavior, including whether traffic fails closed or bypasses the service under specific conditions.
Brownfield migration deserves special care because temporary permissive constructs can become permanent. If unenforced VRFs, preferred groups, or broad vzAny contracts are used to keep applications working during migration, record the owner and removal condition at creation time. Otherwise, the fabric may preserve connectivity but never achieve the intended segmentation. Migration policy should have an exit plan just like migration routing.