The first post covered the fabric itself: the three planes, the underlay, VXLAN and COOP. This one covers the part people actually mean when they say “ACI is different”. Tenants, VRFs, bridge domains, EPGs, contracts.
The object hierarchy is not the hard part. It’s a tree, it’s documented, and after a week it stops feeling foreign. The hard part is that the physical plumbing is configured in a completely separate tree from the tenant, and the two only meet at one point. Get that join wrong and you end up with a configuration that looks entirely correct and passes no traffic at all.
I’ll build up to that, because it lands better once the tenant side is clear.
Why the hierarchy matters beyond tidiness
Parent and child relationships in ACI aren’t just organisational. They determine what can be reused, what can be stretched across sites, and where a change takes effect.
A contract defined in the common tenant is available to every tenant. The same contract defined inside a tenant is not. A bridge domain can be stretched across sites in Multi-Site, but the decision is made per bridge domain, and it’s a decision with real consequences. Learn the tree properly and a lot of later questions answer themselves.
Tenant, VRF, bridge domain
A tenant is the top-level container providing administrative and policy isolation. Tenants typically represent a customer, a business unit, or an environment such as production and development. Three system tenants exist from the start: common, infra and mgmt.
A VRF is a routing and forwarding instance within a tenant, defining a unique Layer 3 address space. Policy enforcement direction and enforcement mode are set at VRF level, which is worth remembering because it means you’re setting them for everything in that VRF at once. That comes back in post four.
A bridge domain is the Layer 2 forwarding domain within a VRF.
A bridge domain is not a VLAN. I’ll say it again because it takes a while to stick: a bridge domain is not a VLAN. It can hold one or more subnets, and its gateway is an anycast address present on every leaf where the bridge domain is deployed. There’s no spanning tree root to place, no HSRP priority to set, no active gateway to fail over.
The settings on a bridge domain do more work than their names suggest.
| Setting | Behaviour | Typical use |
|---|---|---|
| Hardware proxy | Unknown unicast is sent to the spine proxy rather than flooded | Default, and what I’d want on a greenfield fabric |
| Flood unknown unicast | Unknown unicast is flooded within the bridge domain | Silent hosts, active/standby clusters, some appliances |
| ARP flooding | ARP requests are flooded rather than resolved by the fabric | Endpoints relying on gratuitous ARP or floating addresses |
| Unicast routing | Enables the anycast gateway and endpoint IP learning | Disable where the fabric is Layer 2 only and an external device is the gateway |
| Limit IP learning to subnet | Prevents learning endpoint IPs outside the configured subnets | Recommended, avoids surprise endpoint entries |
Hardware proxy is the one that makes ACI feel different from a traditional network. Instead of flooding traffic for a destination it doesn’t know, the ingress leaf hands it to the spine, which looks up COOP and forwards it. Flooding becomes the exception rather than the default.
Then you meet a clustered appliance that relies on unsolicited ARP, or a silent host that never speaks until spoken to, and you turn flooding back on for that bridge domain. That’s fine. Just do it deliberately and per bridge domain, rather than turning it on everywhere because one thing broke once.
EPG and application profile
An endpoint group is a collection of endpoints sharing the same policy. An EPG maps to exactly one bridge domain. A bridge domain can host several EPGs, but never the reverse.
Endpoints are classified into an EPG by port and VLAN, by VMM integration, by IP, or by MAC. Application profiles group related EPGs, which is organisational rather than functional.
There are three ways people approach EPG design, and it’s worth being honest about which one you’re actually doing.
Network centric means one EPG per bridge domain, mirroring the VLANs you already have. It’s the fastest migration path and the usual starting point for brownfield. You get ACI’s operational model without changing your security posture.
Application centric means multiple EPGs per bridge domain reflecting application tiers. This is where the segmentation benefit lives, and it requires knowing how the application actually works, which is often the blocker.
Hybrid means network centric for legacy workloads and application centric for new or high value applications. This is the most common outcome in practice, and I’d rather see a design that says so up front than one that promises application centric everywhere and quietly delivers hybrid eighteen months later.
Endpoint security groups
An ESG decouples security grouping from the bridge domain. Endpoints are matched into an ESG by IP, tag, EPG membership or other selectors, and contracts are applied to the ESG.
That sounds like a minor refinement. It isn’t. The EPG-to-bridge-domain constraint means your security grouping is tied to your forwarding topology, which is exactly the coupling ACI was supposed to remove. ESGs break it. You can build a security group spanning multiple bridge domains without redesigning your Layer 2.
The place this pays off most obviously is VRF route leaking, where the ESG approach separates leaking from filtering and removes the most error-prone part of the older method. Post five covers that in detail.
Contracts
The fabric operates a whitelist model. Traffic between EPGs is denied unless a contract permits it. Traffic within an EPG is permitted by default.
The mechanics:
- A contract contains one or more subjects. Each subject references filters, which hold the actual protocol and port entries.
- One EPG provides the contract, another consumes it. Direction matters and determines which side initiates.
- Contract scope controls reach: application profile, VRF, tenant or global. Scope has to be right for inter-VRF and inter-tenant communication, and getting it wrong is a common cause of “the contract is there but nothing works”.
- vzAny represents all EPGs in a VRF. It cuts policy TCAM consumption significantly where a common service is consumed by many EPGs.
- Preferred groups let a set of EPGs talk freely without contracts, with everything outside the group still requiring them. Useful during migration.
The constraint to design around is policy TCAM on the leaf switches. Contract rules consume it, and a full mesh of contracts between many EPGs scales badly. Ten EPGs all talking to each other is ninety directional relationships, and the hardware notices.
vzAny, preferred groups and contract inheritance exist to manage this. Use them deliberately, as part of the design, rather than reaching for them at the point where you’ve run out of TCAM and need something to fix it. By then your options are worse.
Access policies, and why they catch people
Everything so far lives under Tenants. Access policies live under Fabric, in a separate tree, and they’re the plumbing that connects a physical port to the policy model.
This is the part that causes the most confusion, and I don’t think that’s because it’s badly designed. It’s because it’s a chain of six objects where each one references the next, none of them are named in a way that hints at the chain, and a break anywhere produces the same symptom: nothing works, and nothing tells you why.
| Object | Purpose |
|---|---|
| VLAN pool | The range of VLAN identifiers available. Static allocation for physical domains, dynamic for VMM |
| Domain | Physical, external routed, external bridged or VMM. Associates a VLAN pool with a type of connectivity |
| AAEP | Attachable Access Entity Profile. Binds one or more domains to a set of interfaces |
| Interface policy group | The collection of interface level policies: CDP, LLDP, LACP and so on |
| Interface profile | Maps port selectors to interface policy groups |
| Switch profile | Maps leaf switches or vPC pairs to interface profiles |
Read the chain from the bottom up and it makes sense. A switch profile says which switches. An interface profile says which ports on those switches. A policy group says how those ports behave. An AAEP says which domains are allowed on them. A domain says which VLAN pool applies. And then the tenant EPG binds to that same domain and picks a specific VLAN from that pool.
The join is the domain. The tenant side and the fabric side meet there and nowhere else.
A mismatch anywhere along that chain, and traffic doesn’t flow. The VLAN isn’t in the pool. The domain isn’t attached to the AAEP. The AAEP isn’t on the interface policy group. The EPG binds to a different domain than the one the port can reach. Every one of those looks fine in isolation. The GUI won’t stop you, and it won’t tell you afterwards.
When ACI isn’t passing traffic and the config looks right, the fault is almost always a missing relationship rather than a missing feature. Walk the chain in both directions. It’s tedious and it works, and it beats staring at the EPG wondering what’s wrong with it.
Service graphs and VMM domains, briefly
Two things worth naming now, both of which get proper treatment later.
A service graph inserts a firewall, load balancer or other appliance into the path between two EPGs as part of the contract, rather than through manual VLAN stitching. Policy-based redirect steers traffic to the device without making it the default gateway, which is the point. PBR supports one arm and two arm designs, appliance clusters with symmetric hashing, and go-to, go-through or one arm deployment modes. In multi-location designs, service node placement is one of the harder decisions, and post six deals with it.
A VMM domain integrates the fabric with a hypervisor or container platform manager: vCenter, SCVMM, Kubernetes, OpenShift, OpenStack. EPGs are pushed to the virtualisation layer as port groups, and VLANs are allocated dynamically from the pool as virtual machines attach.
What I’d take from this
The tenant hierarchy is learnable and mostly behaves as you’d expect once you accept that a bridge domain is not a VLAN.
Decide your EPG approach honestly. Hybrid is a legitimate answer and it’s what most estates end up with, so design for it rather than discovering it.
Treat policy TCAM as a design constraint from the start. Contracts are cheap to write and not cheap to program.
And learn the access policy chain properly, because you will be walking it at some point, probably under time pressure, probably while somebody asks whether ACI was the right choice.
The next post moves outside the fabric: the L3Out, border leaf design, and the floating L3Out.