If you've been working
with Cisco ACI contracts and wondering when to use a Taboo Contract versus
a vzAny Contract, you're not alone. These two policy constructs are
among the most misunderstood concepts in ACI — and using the wrong one in a
production environment can lead to unexpected traffic flows, TCAM exhaustion,
or even serious security gaps.
In this guide, I'll
break down both contract types from the ground up, explain exactly when to use
each one, walk through configuration steps in APIC, and share real-world
lessons from 10 years of deploying and troubleshooting Cisco ACI and Nexus
environments (CCIE DC #XXXXX).
Table of Contents
- What
are ACI Contracts?
- What
is a Taboo Contract?
- What
is a vzAny Contract?
- Taboo
vs vzAny: Full Comparison Table
- Configuring
a Taboo Contract in APIC
- Configuring
vzAny in APIC
- TCAM
Impact: What You Need to Know
- Real-World
Use Cases
- Which
One Should You Choose?
- Common
Mistakes to Avoid
- FAQ
1. What are ACI
Contracts?
Before diving into
Taboo and vzAny, it's worth quickly grounding ourselves in ACI's policy model.
In Cisco ACI, contracts are the mechanism that controls
traffic between Endpoint Groups (EPGs). By default, ACI operates on an
implicit-deny model — no traffic flows between EPGs unless a contract
explicitly permits it.
A standard ACI
contract consists of:
- Subjects — a grouping of filters applied to a traffic flow
- Filters — define the traffic (protocol, port, direction)
- Provider EPG — the EPG offering the service
- Consumer EPG — the EPG consuming the service
Taboo Contracts and
vzAny Contracts are special variations of this model that serve very different
purposes — one is designed to deny traffic, and the other
to simplify large-scale policy across an entire VRF.
2. What is a Taboo
Contract?
A Taboo
Contract is a special ACI contract type used to explicitly
deny specific traffic for an EPG. Think of it as a blacklist — you use
it when you want to block a particular type of traffic that would otherwise be
permitted by a broader "permit-all" contract or contract preferred
group.
The name
"Taboo" reflects its intent: traffic matched by a Taboo Contract
is forbidden. It operates at the EPG level and is typically used
alongside other contracts that permit broader access.
Key characteristics
of Taboo Contracts:
- Applied directly to an EPG (not a VRF)
- Works as a deny override —
takes precedence over permit contracts
- Requires manually creating filters for the
traffic you want to block (e.g., TCP port 23 for Telnet, TCP port 80 for
HTTP)
- Generates TCAM entries per filter — the
more granular your filters, the more TCAM it consumes
- Cisco generally discourages Taboo
Contracts unless absolutely necessary, because misconfiguration can cause
unintended outages
Important: Taboo Contracts were designed for
specific use cases — primarily to block cleartext or insecure protocols
(Telnet, FTP, HTTP) when a broader permit contract is already in place. They
are not a general-purpose security tool and should be used
sparingly.
Typical Taboo
Contract use case:
Imagine your security
policy mandates that no EPG should ever communicate over Telnet (TCP 23) or
unencrypted HTTP (TCP 80), even if a broader "permit-all" contract
exists. Rather than modifying every single contract across your fabric, you apply
a Taboo Contract directly to the EPGs in question, creating a deny entry that
overrides any existing permits for those specific ports.
3. What is a vzAny
Contract?
vzAny is a special managed object in Cisco ACI
that represents all EPGs within a VRF. When you associate a
contract with vzAny, that contract automatically applies to every EPG in that
VRF — both as a provider and as a consumer simultaneously.
In practical terms,
vzAny is ACI's way of saying "apply this policy to everything in this VRF
at once." It is the most efficient way to enable intra-VRF communication
or to apply a common policy across a large number of EPGs without creating individual
contract relationships for every pair.
Key characteristics
of vzAny:
- Operates at the VRF level —
affects all EPGs inside that VRF
- Acts as both provider and consumer
simultaneously, creating a "wildcard" relationship
- Dramatically reduces the number of
contract relationships needed in large environments
- Optimises TCAM — instead of n² contract entries for
n EPGs, vzAny creates a single group-level entry
- Must be used carefully in multi-tenant
environments to avoid unintended traffic leaks between tenants
- Recommended for large-scale deployments
where many EPGs need common policy
Pro tip: vzAny is especially powerful when
combined with the "prefer" option for intra-EPG isolation. You can
allow broad intra-VRF communication via vzAny while still enforcing stricter
policies between specific EPGs using targeted contracts.
Typical vzAny use
case:
In a large enterprise
environment with 50+ EPGs across a VRF, you want all EPGs to communicate freely
with a shared set of services (DNS, NTP, monitoring). Without vzAny, you'd need
to create individual provider/consumer relationships for every EPG — that's
potentially hundreds of contract associations. With vzAny, you create one
contract, associate it with vzAny as the consumer, and the shared-service EPG
as the provider. Done.
4. Taboo vs vzAny:
Full Comparison Table
|
Aspect
|
Taboo Contract
|
vzAny Contract
|
|
Primary Purpose
|
Explicitly deny
specific traffic types for an EPG
|
Apply contracts to
all EPGs within a VRF simultaneously
|
|
How It Works
|
Acts as a deny filter — overrides permit contracts
for matched traffic
|
Acts as a wildcard — represents every EPG in the VRF
as both provider and consumer
|
|
Scope of
Application
|
Individual EPG level
|
Entire VRF level —
all EPGs inside it
|
|
Primary Use Case
|
Block insecure protocols (Telnet, FTP, HTTP) or
specific ports
|
Enable free intra-VRF communication or simplify
many-to-one service consumption
|
|
Configuration
Complexity
|
Higher — requires
manual filter creation per protocol/port to deny
|
Lower — one contract
association covers all EPGs automatically
|
|
TCAM Usage
|
Can be high — each filter creates additional TCAM
entries per leaf
|
Optimised — single group-level entry significantly
reduces TCAM consumption
|
|
Traffic Direction
Impact
|
Affects only the
specific EPG it is applied to
|
Affects all EPGs in
the VRF — bidirectional impact
|
|
Multi-tenant Safety
|
Safe — scoped to specific EPG
|
Risky if misconfigured — can cause unintended
cross-tenant traffic leaks
|
|
Best Practice
|
Use sparingly — only
when a specific deny is required and cannot be achieved by restructuring
contracts
|
Recommended for
large-scale environments with shared services or open intra-VRF communication
needs
|
|
Cisco Recommendation
|
Generally discouraged unless absolutely necessary
|
Recommended for efficient policy management at scale
|
|
Interaction with
Other Contracts
|
Overrides permit
contracts — deny takes precedence
|
Works alongside
EPG-specific contracts — EPG contracts take precedence where defined
|
|
Limitations
|
Not suitable for inter-EPG communication control at
scale; increases TCAM pressure
|
Must follow strict guidelines to avoid unintended
traffic leaks across EPGs or tenants
|
5. Configuring a
Taboo Contract in APIC
Here's a step-by-step
walkthrough of configuring a Taboo Contract to block Telnet (TCP 23) traffic
from an EPG:
Step 1 — Create the
Filter
- In APIC, navigate to Tenants →
[Your Tenant] → Contracts → Filters
- Right-click Filters and
select Create Filter
- Name it something descriptive: deny-telnet-filter
- Add a Filter Entry:
- Name: block-tcp-23
- EtherType: IP
- IP Protocol: TCP
- Destination Port From: 23
- Destination Port To: 23
- Click Submit
Step 2 — Create the
Taboo Contract
- Navigate to Tenants → [Your
Tenant] → Contracts → Taboo Contracts
- Right-click and select Create
Taboo Contract
- Name it: block-insecure-protocols
- Under Subjects, add a Subject:
- Name: deny-telnet
- Associate the filter: deny-telnet-filter
- Click Submit
Step 3 — Apply the
Taboo Contract to an EPG
- Navigate to Tenants → [Your
Tenant] → Application Profiles → [Your AP] → [Your EPG]
- Under the EPG, find Taboo
Contracts
- Right-click and select Add Taboo
Contract
- Select block-insecure-protocols
- Click Submit
Caution: Always verify the Taboo Contract is
working as expected in a lab or lower environment before applying it to
production EPGs. Use the APIC Troubleshoot → Traffic Map tool
or show zoning-rule on the leaf switches to confirm the deny rules
are programmed correctly.
6. Configuring
vzAny in APIC
Here's how to
configure vzAny to allow all EPGs within a VRF to consume a shared DNS service:
Step 1 — Create the
Contract (standard contract, not Taboo)
- Navigate to Tenants → [Your
Tenant] → Contracts
- Right-click and select Create
Contract
- Name it: shared-dns-contract
- Add a Subject with a filter permitting UDP
port 53
- Click Submit
Step 2 — Set the
DNS EPG as Provider
- Navigate to your DNS EPG
- Under Provided Contracts,
add shared-dns-contract
Step 3 — Associate
vzAny as Consumer
- Navigate to Tenants → [Your
Tenant] → Networking → VRFs → [Your VRF]
- Click on the VRF and find the EPG
Collection for VRF (vzAny) section
- Under Consumed Contracts,
add shared-dns-contract
- Click Submit
With this
configuration, every EPG inside the VRF automatically becomes a consumer of the
DNS service — no individual contract relationships needed.
# REST API call to
associate contract with vzAny { "vzAny": {
"attributes": { "dn":
"uni/tn-MyTenant/ctx-MyVRF/any", "prefGrMemb":
"disabled" }, "children": [{ "vzRsAnyToCons": {
"attributes": { "tnVzBrCPName":
"shared-dns-contract" } } }] } }
7. TCAM Impact:
What You Need to Know
TCAM (Ternary Content
Addressable Memory) is one of the most critical hardware resources in ACI leaf
switches. Running out of TCAM space causes contract rules to fail to program,
which means traffic silently drops. Understanding how Taboo and vzAny affect
TCAM is essential for any production deployment.
Taboo Contract —
TCAM behaviour:
- Each filter entry in a Taboo Contract
creates a separate TCAM entry per EPG per leaf where that
EPG has endpoints
- If you have granular filters (e.g.,
blocking 10 different ports), you get 10 TCAM entries per EPG per leaf
- In large fabrics with many EPGs and many
leaves, Taboo Contracts can consume TCAM rapidly
- Always check leaf TCAM utilisation
with: show system internal eltmc info policy brief
vzAny — TCAM
behaviour:
- vzAny uses a group-level TCAM
entry instead of per-EPG entries
- Instead of creating N entries for N EPGs
in the VRF, vzAny creates a single entry representing the entire VRF class
- This makes vzAny dramatically more
TCAM-efficient in environments with many EPGs
- The trade-off is less granular control —
you cannot easily apply vzAny selectively to only some EPGs
TCAM rule of thumb: If you have more than 20 EPGs in a VRF
and need a common policy, vzAny will almost always be more TCAM-efficient than
individual contracts or Taboo Contracts applied per EPG.
8. Real-World Use
Cases
When Taboo Contract
makes sense:
- Compliance-driven blocking: Your security team mandates no
Telnet or FTP anywhere, even if ops teams have existing
"permit-all" contracts. A Taboo Contract enforces this without
restructuring all existing policies.
- Temporary traffic block during
maintenance: You
need to block a specific port to an EPG temporarily during an upgrade
without removing the existing contract.
- Protocol enforcement: Forcing all communication to be
encrypted — block HTTP (80) and enforce HTTPS (443) only for specific
EPGs.
When vzAny makes
sense:
- Shared services access: DNS, NTP, syslog, monitoring —
services that every EPG in the VRF should be able to reach.
- Development/test environments: Where you want all EPGs to
communicate freely with each other without managing individual contracts.
- Large-scale deployments: 30+ EPGs that all need the same
baseline policy — vzAny avoids an explosion of contract relationships.
- Migration from traditional networking: When converting a flat network to
ACI and initially needing open intra-VRF communication while policy is
refined.
9. Which One Should
You Choose?
|
Your Situation
|
Recommended Choice
|
|
Need to block a
specific port or protocol for one or a few EPGs
|
Taboo Contract
|
|
Need all EPGs in a VRF to access a shared service
(DNS, NTP, monitoring)
|
vzAny (consumer) + standard contract
|
|
Want open
communication between all EPGs in a VRF (dev/test)
|
vzAny with
permit-all contract
|
|
Concerned about TCAM exhaustion with many EPGs
|
vzAny — always more TCAM-efficient at scale
|
|
Need to enforce a
security deny that overrides existing permits
|
Taboo Contract
|
|
Multi-tenant environment needing strict isolation
|
Avoid vzAny — use targeted contracts per EPG
|
|
Migrating from flat
network, need temporary open access
|
vzAny with a plan to
tighten policy over time
|
My recommendation
from the field: In 10
years of ACI deployments, the most common mistake I've seen is over-relying on
Taboo Contracts as a security tool. Taboo Contracts should be your last resort
— a scalpel, not a hammer. If you find yourself adding many Taboo Contracts
across multiple EPGs, that's usually a sign your contract design needs to be
re-architected. On the other hand, vzAny is underutilised — most environments
with 20+ EPGs sharing common services would benefit enormously from vzAny, yet
many engineers avoid it because they don't fully understand it. Used correctly,
vzAny is one of the most powerful simplification tools in the entire ACI policy
model.
10. Common Mistakes
to Avoid
Taboo Contract
mistakes:
- Applying Taboo to the wrong EPG direction: Remember Taboo Contracts only affect
the EPG they're applied to — not the EPG on the other side of the
communication.
- Using Taboo instead of fixing contract
design: If you need
many Taboo Contracts, your underlying contract architecture probably needs
to be redesigned.
- Not testing in a lab first: A misconfigured Taboo Contract can
block legitimate traffic and cause outages. Always validate with traffic
tests before production rollout.
- Ignoring TCAM utilisation: Adding many granular Taboo filters
across many EPGs can silently exhaust TCAM and cause rule programming
failures.
vzAny mistakes:
- Using vzAny in multi-tenant environments
without careful scoping: If
your VRF spans multiple tenants, vzAny can unintentionally allow
cross-tenant traffic. Always scope VRFs carefully before applying vzAny.
- Applying vzAny with permit-all in
production: Fine for
dev/test, but dangerous in production. Always use vzAny with a specific
contract that permits only required traffic.
- Forgetting that vzAny affects endpoint
discovery too: vzAny
contracts can affect how COOP (Council of Oracle Protocol) handles
endpoint learning. Test thoroughly after applying vzAny changes.
11. Frequently
Asked Questions
Can I use Taboo
Contract and vzAny together?
Yes. A common pattern
is to use vzAny to allow broad intra-VRF communication, and then apply a Taboo
Contract to specific EPGs to block particular protocols within that open
policy. The Taboo deny takes precedence over the vzAny permit for the matched
traffic.
Does vzAny work
with the Contract Preferred Group?
Yes, but with
important caveats. When Contract Preferred Group is enabled on a VRF, EPGs
within the preferred group communicate freely without contracts. vzAny can
still be used alongside preferred groups to apply contracts to EPGs outside the
preferred group. See our post on Contract
Preferred Groups in ACI for more detail.
What happens to
TCAM if I apply both Taboo and vzAny?
The vzAny entry
remains efficient (group-level). The Taboo Contract adds per-EPG entries only
for the specific EPGs it is applied to. As long as you keep Taboo Contracts
minimal and targeted, the TCAM impact remains manageable.
Can vzAny be used
as a provider instead of a consumer?
Yes. vzAny can be
configured as a provider, consumer, or both. When used as a provider, all EPGs
in the VRF provide the contract — useful for making all EPGs accessible to a
specific external consumer (like a monitoring system) without configuring each
EPG individually.
How do I verify
Taboo Contract rules are programmed on the leaf?
SSH to the leaf switch
and run:
leaf# show
zoning-rule scope [vrf-vnid] # Look for entries with action
"deny" — these are your Taboo Contract rules # Also check: show
system internal policy-mgr stats
Summary
Key takeaways
- Taboo Contract = EPG-level explicit deny. Use it
sparingly to block specific protocols. Increases TCAM consumption per EPG.
- vzAny = VRF-level wildcard. Use it to apply contracts to all EPGs
at once. Much more TCAM-efficient at scale.
- They can be used together — vzAny for
broad policy, Taboo for specific overrides.
- In multi-tenant environments, use vzAny
with caution to avoid cross-tenant traffic leaks.
- If you find yourself creating many Taboo
Contracts, it's time to redesign your contract architecture.
