Cisco ACI Taboo Contract vs vzAny Contract: Complete Guide with Configuration Examples

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

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.