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.

Why Service Graphs Matter in Cisco ACI

Service graphs in Cisco ACI simplify network and security integration by offering several key benefits:

• Traffic Redirection Made Easy: Direct traffic to L4-L7 devices without complex designs.
• Automated VLAN Management: No manual VLAN assignments needed.
• Seamless vNIC Connectivity: Virtual NICs are automatically connected.
• Reusable Templates: Configure once, reuse multiple times.
• Logical & Application-Centric View: Gain clarity and better visibility of services.
• Shared Device Model: Efficiently share devices across departments.
• Health & Performance Insights: Collect health scores and statistics from devices.
• Dynamic Updates: ACLs and pools update automatically with endpoint discovery.

However, in Service Policy Mode:

• The model leans heavily on automation.
• Managing numerous configuration parameters can be overwhelming for frequent changes.

Bottom Line:
Service graphs offer a streamlined, application-focused approach compared to traditional designs—but choose wisely based on your operational needs.

Cisco ACI Service Graph Management Models Explained

Cisco ACI provides three distinct approaches to manage service graphs, each offering different levels of control and integration:

1. Network Policy Mode (Unmanaged)
   In this mode, ACI configures only the network aspects of the service graph within the fabric. No configuration changes are pushed to the L4-L7 device, making it suitable when device policies are managed externally.

2. Service Policy Mode (Managed)
   Here, ACI not only handles the fabric configuration but also manages VLAN settings on the L4-L7 device. The APIC administrator can directly input device-specific configurations through the APIC interface, ensuring centralized control.

3. Service Manager Mode
   This model allows the firewall or load balancer administrator to define L4-L7 policies. ACI takes care of the fabric and VLAN configurations, while the APIC administrator links these policies with the network policy, enabling a collaborative approach.

Choosing the Right Cisco ACI Service Graph Mode

When designing with Cisco ACI, selecting the right service graph mode depends on your operational needs:

• Dynamic Configuration Needs?
  If firewalls and load balancers must be configured dynamically through APIC, choose Service Policy Mode. If a separate administrator handles device configuration, opt for Network Policy Mode or Service Manager Mode.

• Frequent Commissioning Like Cloud Services?
  For environments where devices are frequently added or removed, Service Policy Mode or Service Manager Mode works best. If services remain static for long periods, Network Policy Mode or Service Manager Mode is more practical.

• Complex Multi-Leg Designs?
  If your design requires multiple interfaces or DMZ configurations, manual service insertion using EPGs and bridge domains may be more convenient than using a service graph.

Bottom Line:
Your choice should align with automation needs, operational flexibility, and design complexity.

Rogue Endpoint Detection in Cisco ACI

 🔐 Rogue Endpoint Detection in Cisco ACI

⚠️ Problem Addressed

Rogue endpoints or misconfigured devices can cause frequent MAC/IP moves across leaf switches, leading to:

• Network instability
• High CPU usage
• Crashes in endpoint mapper (EPM) and client (EPMC)
• Rapid log rollover, making debugging difficult

---

🛡️ How Rogue Endpoint Control Works

The feature helps mitigate these issues by:

• Detecting rapidly moving endpoints (MAC/IP)
• Quarantining them by making their entries static
• Deleting the unauthorized MAC/IP after a set interval
• Raising a fault for visibility
• Generating a host tracking packet to re-learn the endpoint

---

🔄 Behavior Based on Software Version

Version	Quarantine Behavior	Traffic Handling	Final Action
Before 3.2(6)	Endpoint is made static	Traffic is dropped during quarantine	MAC/IP is deleted after the interval
3.2(6) and later	Endpoint is made static	Traffic is allowed during quarantine	MAC/IP is deleted after the interval

✅ Improvement: From 3.2(6) onwards, the system is less disruptive, allowing traffic to continue while still monitoring rogue behavior.

---

📝 Rogue/COOP Exception List

✅ Purpose

Allows higher tolerance for endpoint movement before marking as rogue.

📋 Behavior

• Endpoints in the list are marked rogue only after 3,000 moves in 10 minutes
• Once marked:
• Endpoint is made static
• Deleted after 30 seconds

🆕 From APIC 6.0(3) Onwards

• You can:
• Create global exception lists
• Exclude MACs from rogue detection across all bridge domains or L3Outs
• Exclude all MACs for a specific bridge domain or L3Out

 

Cisco ACI Mis-Cabling Protocol (MCP) – Loop Detection Simplified

Cisco ACI uses Mis-Cabling Protocol (MCP) to detect and mitigate Layer 2 loops, replacing traditional STP participation. MCP sends special Layer 2 packets across access ports, VPCs, and virtual ports. If the fabric receives its own MCP packet, it identifies a loop and can either log the event or error-disable the port.

✅ Key Highlights:

• Global MCP policies are disabled by default; port-level policies are enabled.
• Global MCP Policy:
  This is the master switch that controls whether MCP is active across the entire fabric.
• Disabled by default: Even though individual ports may be configured to support MCP, no MCP packets are sent unless this global policy is explicitly enabled.
• Port-Level MCP Policy:
  These are the interface-specific settings that determine how each port behaves when MCP is active.
• Enabled by default: Ports are ready to participate in MCP loop detection, but they won’t actually send or process MCP packets unless the global policy is turned on.

• MCP works complementarily with STP on external switches.
• BPDU filtering or disabling loopguard on external switches helps prevent loop-related issues.
• Endpoint move loop detection is available but disabled by default.
• MCP supports native VLAN mode and per-VLAN mode (from APIC 2.0(2)) for granular loop detection.
• Faster detection introduced in APIC 3.2(1) with transmission intervals as low as 100 ms.
• Scalability limits: 256 VLANs per interface and 2000 logical ports per leaf switch. Per-VLAN MCP will only run on 256 VLANs per interface. If there are more than 256 VLANs, then the first numerical 256 VLANs are chosen.

🔐 MCP Modes:

• Non-Strict Mode: Allows traffic while monitoring for loops; default detection time is 7 seconds.
• Strict Mode (from APIC 5.2(4)):
• Performs early loop detection before allowing data traffic.
• Uses initial delay and grace period timers for STP convergence and aggressive MCP checks.
• Requires port flap to activate on already-up ports.

⚠️ Strict Mode Guidelines:

• Not supported on FEX or QinQ edge ports.
• Requires APIC 5.2(4) or later on all participating leaf switches.
• May impact vPC convergence time.
• Must be disabled before downgrading the fabric.
• Can cause both ports to error-disable if loops are detected simultaneously.

MCP Mode Comparison Table

Feature	Non-Strict Mode	Strict Mode
Traffic Acceptance	Accepts data and control traffic immediately	Initially blocks data traffic; only control packets allowed
Loop Detection Timing	MCP packets sent every 2 seconds; loop detection in ~7 seconds	Aggressive MCP packet transmission during grace period (default 3 sec)
Early Loop Detection	Not performed	Performed before allowing data traffic
Port Behavior on Loop Detection	Port is error-disabled	Port is error-disabled and shut down
Activation Requirement	Active immediately	Requires port flap to activate if port is already up
Timers Used	Global MCP instance policy	Initial delay timer + grace period timer
Default Initial Delay	Not applicable	0 seconds (can be set to 45–60 sec for STP convergence)
Default Grace Period	Not applicable	3 seconds
STP Compatibility	Works with STP	Accepts STP BPDUs even if VLAN is not enabled
Use Case	General loop detection	Early and aggressive loop prevention before traffic forwarding