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?
2. What is a Taboo Contract?
3. What is a vzAny Contract?
4. Taboo vs vzAny: Full Comparison Table
5. Configuring a Taboo Contract in APIC
6. Configuring vzAny in APIC
7. TCAM Impact: What You Need to Know
8. Real-World Use Cases
9. Which One Should You Choose?
10. Common Mistakes to Avoid
11. 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

1. In APIC, navigate to Tenants → [Your Tenant] → Contracts → Filters
2. Right-click Filters and select Create Filter
3. Name it something descriptive: deny-telnet-filter
4. Add a Filter Entry:
• Name: block-tcp-23
• EtherType: IP
• IP Protocol: TCP
• Destination Port From: 23
• Destination Port To: 23
5. Click Submit

Step 2 — Create the Taboo Contract

1. Navigate to Tenants → [Your Tenant] → Contracts → Taboo Contracts
2. Right-click and select Create Taboo Contract
3. Name it: block-insecure-protocols
4. Under Subjects, add a Subject:
• Name: deny-telnet
• Associate the filter: deny-telnet-filter
5. Click Submit

Step 3 — Apply the Taboo Contract to an EPG

1. Navigate to Tenants → [Your Tenant] → Application Profiles → [Your AP] → [Your EPG]
2. Under the EPG, find Taboo Contracts
3. Right-click and select Add Taboo Contract
4. Select block-insecure-protocols
5. 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)

1. Navigate to Tenants → [Your Tenant] → Contracts
2. Right-click and select Create Contract
3. Name it: shared-dns-contract
4. Add a Subject with a filter permitting UDP port 53
5. Click Submit

Step 2 — Set the DNS EPG as Provider

1. Navigate to your DNS EPG
2. Under Provided Contracts, add shared-dns-contract

Step 3 — Associate vzAny as Consumer

1. Navigate to Tenants → [Your Tenant] → Networking → VRFs → [Your VRF]
2. Click on the VRF and find the EPG Collection for VRF (vzAny) section
3. Under Consumed Contracts, add shared-dns-contract
4. 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.