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.

What is a Contract Preferred Group in ACI?

 🔷 What is a Contract Preferred Group in ACI?

In Cisco ACI, Endpoint Groups (EPGs) typically require contracts to communicate with each other. This follows the “allow list” model, where communication is explicitly permitted only if a contract exists.

The Preferred Group (PG) feature simplifies this by allowing certain EPGs within the same VRF to communicate freely without contracts.

---

✅ Key Concepts

Term	Description
Included EPGs	EPGs that are part of the preferred group and can communicate with each other without contracts.
Excluded EPGs	EPGs outside the preferred group that still require contracts to communicate.
VRF PG Setting	Must be enabled for the preferred group to work. Without this, even included EPGs won’t communicate freely.

---

🛠️ Configuration Steps

1. Enable Preferred Group on VRF:
• Go to the VRF settings in APIC or Nexus Dashboard Orchestrator (NDO).
• Check the Preferred Group box.
2. Add EPGs to the Preferred Group:
• In the EPG properties, check Include in Preferred Group.
• Save the configuration.
3. Verify Membership:
• You can view all EPGs in the preferred group under the VRF’s properties.

---

🌐 Multi-Site Considerations

• In a stretched VRF across multiple sites, preferred group EPGs are shadowed in other sites to enable inter-site communication.
• This allows, for example, a web EPG in Site 1 to communicate with an app EPG in Site 2 without contracts.

---

⚠️ Limitations

• Preferred Groups are not supported for L3Out external EPGs.
• If vzAny is already consuming/providing a contract in the VRF, you should not configure preferred groups.
• All EPGs in a preferred group must be managed consistently (either all via APIC or all via NDO).

 

ACI Contracts Components - Contacts Vs Filters Vs Aliases Vs Labels

 In Cisco ACI (Application Centric Infrastructure), Contracts are a key component of the policy model, used to define how endpoints (EPGs) communicate with each other. Within contracts, the terms Labels, Filters, Aliases, and Subjects each play distinct roles. Here's a breakdown of each:

---

🔹 1. Filters

• Purpose: Define the actual traffic (protocols, ports) that is allowed or denied.
• Details:
• Filters are composed of entries specifying Layer 4 information like TCP/UDP ports and protocols.
• They are reusable across multiple contracts.
• Example: A filter might allow TCP traffic on port 80 (HTTP).

---

🔹 2. Subjects

• Purpose: Act as containers within a contract that reference filters and define directionality.
• Details:
• A contract can have multiple subjects.
• Each subject can reference one or more filters.
• You can specify whether the traffic is unidirectional or bidirectional.
• Example: A subject might define that HTTP traffic is allowed from EPG A to EPG B.

---

🔹 3. Aliases

• Purpose: Provide a way to abstract or alias filters for reuse or simplification.
• Details:
• Aliases are less commonly used and are more relevant in complex policy models.
• They can help in referencing filters indirectly, making policy definitions more modular.

---

🔹 4. Labels

• Purpose: Used for categorization and policy enforcement.
• Details:
• Labels can be applied to contracts, EPGs, and other objects.
• They help in grouping and applying policies based on tags.
• Useful in large environments for automation and policy scaling.

---

🧩 How They Work Together in a Contract

• A Contract contains one or more Subjects.
• Each Subject references one or more Filters (or Aliases to filters).
• Labels can be used to tag contracts or EPGs for organizational or policy purposes.

 

Concept of vPC in ACI

Concept of vPC in ACI

In Cisco ACI, a Virtual Port Channel (vPC) enables two separate leaf switches to present a unified port channel to a connected endpoint—such as a server, firewall, or another switch that supports link aggregation protocols like LACP.

In this setup, two ACI leaf nodes (e.g., Leaf201 and Leaf202) act as vPC peers, forming a logical construct known as a vPC domain. One of these peers is elected as the primary, while the other assumes the secondary role.

---

ACI’s MCT-Based Architecture

Unlike traditional vPC implementations that rely on a dedicated peer-link, ACI leverages the fabric itself to manage synchronization and control-plane communication. This architecture is referred to as Multichassis EtherChannel Trunk (MCT).

🔧 Key Characteristics:

• No physical peer-link is required between Leaf201 and Leaf202.
• Instead, the ACI fabric handles all peer communication and synchronization.
• ZMQ (Zero Message Queue) replaces traditional CFS (Cisco Fabric Services) for messaging between vPC peers.

---

How Peer Communication Works in ACI

• ZMQ, a high-performance messaging library using TCP, is embedded as libzmq on each switch.
• Applications that require peer communication (like the vPC manager) use this library to exchange messages.

🔄 Peer Reachability Mechanism:

• The vPC manager subscribes to routing updates via URIB.
• When IS-IS discovers a route to the peer (e.g., Leaf202 sees Leaf201), URIB notifies the vPC manager.
• The manager then attempts to establish a ZMQ socket with the peer.
• If the route is withdrawn (e.g., due to link failure), the vPC manager is notified and the MCT link is brought down accordingly.

---

Upgrade Best Practices with vPC

To ensure high availability during fabric upgrades, it's recommended to divide switches into at least two upgrade groups. For example:

• Group A: Leaf201, Leaf203, Spine101
• Group B: Leaf202, Leaf204, Spine102

This strategy ensures that at least one vPC peer remains active during the upgrade, preventing service disruption for connected endpoints.

---

Glossary

Term	Description
ACI	Application Centric Infrastructure
vPC	Virtual Port Channel
MCT	Multichassis EtherChannel Trunk
ZMQ	Zero Message Queue
URIB	Unicast Routing Information Base
IS-IS	Intermediate System to Intermediate System
LACP	Link Aggregation Control Protocol

---

 VPC Design Options:-

Option 1 -VPC with SAME Leaf interfaces across two leafs with Combined Profiles

Option 2 -  VPC with SAME Leaf interfaces across two leafs with Individual Profiles.

Option 3 -  VPC with DIFFERENT Leaf interfaces across two leafs with Individual Profiles

Complete Steps to Create vPC in Cisco ACI (via APIC GUI)

 Understanding vPC in Cisco ACI: A Modern Approach to High Availability

In the evolving landscape of data center networking, Virtual Port Channel (vPC) stands out as a cornerstone of high availability and link redundancy. While traditional NX-OS environments rely on CLI-driven configurations, Cisco ACI reimagines vPC through a policy-driven, intent-based model that aligns with the fabric’s overarching design philosophy.

Unlike legacy setups, ACI abstracts physical connectivity into logical constructs, allowing administrators to define vPC behavior through interface policy groups, switch profiles, and attachable access entity profiles (AAEPs). This not only simplifies deployment but also ensures consistency across the fabric.

At its core, a vPC in ACI enables two leaf switches to present a unified uplink to a downstream device—be it a server, firewall, or load balancer—without relying on spanning tree protocols. The result is active-active forwarding, improved bandwidth utilization, and seamless failover.

In this guide, we’ll walk through the step-by-step configuration of vPC in Cisco ACI, demystifying each component and highlighting best practices to ensure a robust and scalable deployment.

Note:- In Cisco ACI, a Fabric Extender (FEX) can be integrated using a port channel in a straight-through topology, where each FEX connects directly to a leaf switch. While vPCs can be established between hosts and the FEX for redundancy and load balancing, the FEX itself does not support vPC connectivity to multiple leaf switches.

 Complete Steps to Create vPC in Cisco ACI (via APIC GUI)

Step 1: Leaf Onboarding (One-by-One)

🔍 Monitor Discovery in APIC

1. Log in to the APIC GUI
2. Navigate to:
   Fabric → Inventory → Fabric Membership → Nodes Pending Registration
3. Wait for Leaf101 to appear
• You’ll see its Serial Number
• Node Role: Leaf
• Status: Blank / Not Registered

---

📝 Register Leaf101

1. Right-click on Leaf101’s serial number
2. Click Register
3. In the registration window, enter:
• Node ID: 101
• Node Name: Leaf101
• Click Register
• Wait for it to appear in Registered Nodes

---

📝 Register Leaf102

1. Repeat the same steps for Leaf102:
• Wait for it to appear in Nodes Pending Registration
• Right-click → Register
• Enter:
• Node ID: 102
• Node Name: Leaf102
• Click Register
• Wait for it to appear in Registered Nodes

---

🔢 Step-by-Step ACI Configuration Flow

2. VLAN Pool (VLAN 113)

• Navigate to:
  Fabric → Access Policies → Pools → Right Click on VLAN and click Create Vlan Pool
• Create VLAN Pool:
• Name: VLAN_113_Pool
• Mode: Static
• Click + under Encap Blocks

Ø  Range:  113 – 113

Ø  Allocation mode: Static

• Click Ok - >Submit

---

3. Domain (Physical Domain)

• Go to:
  Fabric → Access Policies → Physical and External Domains ->Right Click on Physical domain ->
• Create Physical Domain:
• Name: PhysDom_VLAN113
• VLAN Pool: VLAN_113_Pool
• Click Submit

---

4. AEP (Attachable Access Entity Profile)

• Navigate to:
  Fabric → Access Policies → Policies-> Global → Right Click on Attachable Access Entity Profiles -> Click Create Attachable Access Entity Profiles
• Create AEP:
• Name: AEP_VLAN113
• Click + under Domains and Associated Domain: PhysDom_VLAN113
• Click Update ->Next -> Finish

---

5. Interface Policy Group (vPC)

• Go to:
  Fabric → Access Policies → Interface → Leaf Interfaces - >Policy Groups->Right click on VPC Interfaces - >Create VPC Interfaces
• Create VPC Interface Policy Group:
• Name:  vPC_LF101_LF102_1_1
• AEP: AEP_VLAN113
• Port Channel Policy: system-lacp-Active
• Link Level Policy: system-link-level-XG-Auto
• Click Next > Finish

6. Create vPC Policy (Your Mentioned Step)

• Go to:
  Fabric → Access Policies → Policies → Switch
• Right-click on Virtual Port Channel Default

Name:VPC_101_102

ID:10

VPC Domain Policy: Default

Switch1: Leaf101

Switch2: Leaf102

This step ensures the vPC behavior is defined at the switch policy level.

7. Interface Profile

• Navigate to:
  Fabric → Access Policies → Interface → Leaf Interface -> Profiles
• Right click on the interface profile and click Create Interface Profile:
• Name: IntProf_Leaf101_102
• Click + under Interface Selector:
• Name: Eth1_4
• Interface ID: 1/4
• Policy Group: vPC_LF101_LF102_1_1
• Click Ok - > Submit

 

8. Switch Profile

• Go to:
  Fabric → Access Policies → Switches → Profiles
• Right Click on Profile and click Create Leaf Profile:
• Name: LeafProf_101_102
• Click + under Leaf Selector:
• Name: Leaf101_102
• Node Block: From 101 to 102
• Click Update -> Next
• Attach Interface Profile:
• IntProf_Leaf101_102

---

9. Create Tenant

• Navigate to:
  Tenants
• Click Add Tenant
• Name: Tenant_WebApp
• Click Submit

10. Create VRF

• Navigate to:
  Tenants
• Click Networking -> VRF -> Right click on VRF -> click Create VRF
• Name: WebApp_VRF
• Uncheck Create A Bridge Domain
• Click Finish

11 Create BD

• Navigate to:
  Tenants
• Click Networking -> Bridge Domain -> Right click on Bridge Domain-> click Create Bridge Domain
• Name: WebApp_BD
• VRF: WebApp_VRF
• Click Next
• Click + under Subnet

Ø  Gateway IP: 10.1.1.1/24

Ø  Check “Make this IP address Primary”

Ø  Scope: check “Advertised Externally”

• Click OK -> Next-> Finish

 

12. Create Application Profile (AP)

• Inside Tenant_WebApp, go to:
  Application Profiles
• Right Click on Application Profile  and Create Application Profile:
• Name: WebApp_AP
• Click Submit

13. Create Endpoint Group (EPG)

• Inside WebApp_AP, go to:
  EPGs
• Right Click on Application EPG and click Create Application EPG:
• Name: WebApp_EPG
• Bridge Domain: WebApp_BD
• Click Finish
• Right Click on WebApp_EPG and click ADD Physical Domain Association:
• Domain Association: PhysDom_VLAN113
• Click Submit

---

14. Create Contract (Allow TCP Port 80)

• Go to:
  Tenant_WebApp → Contracts -> Standard
• Right Click on Standard -> Click Create Contract:
• Name: Allow_HTTP
• Click + under Subject:
• Name: HTTP_Subject
• Filter: Click + under Filter
• Click + Under Name
• Name: HTTP_Filter
• Click + under Entries
• Name: HTTP_Entry
• EtherType: IP
• IP Protocol: TCP
• Destination Port: From http – To http
• Click Update-> Submit
• Click Update -> Ok -> Submit
• Provide contract to/from EPG as needed

---

15. Static Binding of EPG to Port

• Go to Tenant WebApp_EPG-> Application Profiles -> WebApp_AP ->  Application EPGs -> WebApp_EPGs
• Right Click on WebApp_EPGs -> Click Deploy Static EPG on PC,VPC, or Interface
• Path Type: Virtual Port Channel
•  Path: Leaf101/eth1/4 and Leaf102/eth1/4
• Mode: Trunk
• Encapsulation: vlan-113