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.

Basic Networking Questions - Interview

1.      1. Should we configure the speed and duplex setting on interface or on port-channel?

Answer: Speed and duplex should be configured on the physical interfaces.

2.     2.  Should the switchport command be configured on physical interfaces or on port-channel?

Answer: The switchport command should be configured on both the physical interfaces and the port-channel.

BGP

Difference between soft-reconfiguration inbound and soft-reconfiguration inbound always.

Feature	soft-reconfiguration inbound	soft-reconfiguration inbound always
Purpose	Enables reprocessing of inbound policies without resetting the BGP session.	Same as above, but ensures routes are always stored for reprocessing.
Storage	Stores routes only when explicitly triggered.	Always stores all received routes in adj-RIB-in.
Memory Impact	Lower memory usage.	Higher memory usage (routes duplicated in memory).
Dependency	Relies on neighbor supporting Route Refresh capability.	Works even if neighbor does not support Route Refresh.
Use Case	Modern networks where Route Refresh is supported.	Legacy peers or environments where Route Refresh is unavailable.

Cisco ACI MoQuery – Advanced Commands for Day‑to‑Day Operations

Cisco ACI provides a powerful graphical interface through APIC, but experienced ACI engineers rarely rely only on the GUI during daily operations. In real production environments, engineers prefer moquery because it offers fast, accurate, and read‑only access to the Cisco ACI Management Information Tree (MIT).

Moquery is safe to use in production, does not impact traffic, and does not program hardware. It exposes the real‑time state of the fabric and eliminates guesswork during troubleshooting. For day‑to‑day ACI operations, moquery is often the first tool engineers reach for.

---

What Is MoQuery in Cisco ACI?

Moquery is a command‑line utility available directly on the APIC that allows engineers to query managed objects (MOs) stored in the ACI database. Unlike the APIC GUI, moquery does not hide relationships or simplify outputs. It shows raw and authoritative information exactly as it exists in the fabric.

Moquery is commonly used for:

• Endpoint troubleshooting
• Contract and policy validation
• VRF and bridge domain verification
• Fault analysis
• Fabric and node health checks

---

Endpoint Troubleshooting Using MoQuery

Endpoint‑related issues are the most common problems in Cisco ACI environments. When endpoints are not reachable or behave unexpectedly, moquery provides immediate visibility.

To display all learned endpoints:

moquery -c fvCEp

This command shows:

• MAC address
• IP address
• EPG association
• Bridge Domain
• Leaf and interface where the endpoint is learned

To find a specific IP address:

moquery -c fvCEp | grep 10.10.10.25

To find a specific MAC address:

moquery -c fvCEp | grep 00:50:56

These commands are used daily to identify incorrect endpoint learning, endpoint mobility events, duplicate IPs, and static path misconfigurations.

---

Validating Application Profiles and EPGs

To list all Endpoint Groups (EPGs) in a tenant:

moquery -c fvAEPg

This command is helpful when:

• EPGs do not appear in the GUI
• Verifying naming conventions
• Confirming EPG existence during migrations

To identify which application profile an EPG belongs to:

moquery -c fvAEPg | grep dn

This is especially useful in environments with many application profiles and similarly named EPGs.

---

Contract Troubleshooting Using MoQuery

Contracts are one of the most frequent causes of traffic drops in Cisco ACI. Moquery allows engineers to validate contract relationships without relying on GUI assumptions.

To list all contracts:

moquery -c vzBrCP

To check which EPGs are providers of a contract:

moquery -c fvRsProv

To check which EPGs are consumers of a contract:

moquery -c fvRsCons

These commands confirm whether the correct EPGs are actually providing and consuming the intended contracts.

---

Validating Contract Subjects and Filters

Many contract issues occur not because the contract is missing, but because the filter is wrong.

To inspect contract subjects:

moquery -c vzSubj

To list filters:

moquery -c vzFilter

To validate filter entries (ports, protocol, and direction):

moquery -c vzEntry

These commands remove ambiguity and clearly show whether the contract allows the required traffic.

---

Taboo Contract Verification

Taboo Contracts explicitly deny traffic and override permit contracts. They should be used sparingly, as misconfiguration can cause outages.

To list all Taboo Contracts:

moquery -c vzTaboo

To inspect Taboo contract subjects:

moquery -c vzTSubj

If traffic is unexpectedly denied, these commands should always be checked early in troubleshooting.

---

Validating vzAny and VRF‑Level Policies

vzAny represents all EPGs within a single VRF and is commonly used for shared services or broad policy application.

To list all VRFs:

moquery -c fvCtx

To confirm vzAny configuration:

moquery -c vzAny

This is critical in environments using:

• Shared‑services architectures
• Permit‑all designs
• Contract Preferred Groups

Many production incidents occur because engineers are unaware of an existing vzAny contract.

---

Bridge Domain Troubleshooting

Bridge Domain issues can silently break connectivity.

To list all bridge domains:

moquery -c fvBD

To display bridge domain subnets:

moquery -c fvSubnet

To validate Bridge Domain to VRF mapping:

moquery -c fvRsCtx

These commands help identify:

• Missing gateways
• Incorrect VRF bindings
• Wrong subnet scope

---

L3Out and External Connectivity Validation

To list all Layer‑3 Outs:

moquery -c l3extOut

To view external EPGs:

moquery -c l3extInstP

To check external subnets:

moquery -c l3extSubnet

These are essential when troubleshooting:

• North‑south traffic issues
• Firewall integration
• Route advertisement problems

---

Fault and Fabric Health Troubleshooting

To display all active faults:

moquery -c faultInst

To see only critical faults:

moquery -c faultInst | grep critical

To find operational faults:

moquery -c faultInst | grep oper

These commands are faster and often more actionable than navigating the APIC fault dashboard.

---

Fabric and Node Health Validation

To list all fabric nodes:

moquery -c fabricNode

To check fabric health scores:

moquery -c fabricHealth

These commands are commonly used before and after production changes to ensure stability.

---

Interface and Path Troubleshooting

To list physical interfaces:

moquery -c ethpmPhysIf

To check interface operational state:

moquery -c ethpmPhysIf | grep operSt

To validate static path bindings:

moquery -c fvRsPathAtt

These commands explain many partial connectivity issues, link‑state problems, and unexpected traffic drops.

---

Best Practices for Daily MoQuery Usage

• Use moquery during incidents, not after
• Save outputs for RCA and audits
• Combine moquery with grep for faster analysis
• Learn common managed object classes such as fvCEp, fvAEPg, fvBD, fvCtx, and faultInst

---

Why Every ACI Engineer Should Master MoQuery

Moquery significantly reduces MTTR, increases confidence during incidents, and exposes the actual state of the fabric. Engineers who master moquery troubleshoot faster, avoid mistakes, and operate more effectively in large ACI environments.

---

Conclusion

Moquery is one of the most powerful yet underutilized tools in Cisco ACI. While the APIC GUI is excellent for visualization, moquery provides the facts. For serious ACI operations, moquery should be part of every engineer’s daily workflow.

VRF Enforced Mode - Cisco ACI

 Understanding Cisco ACI VRF Enforced Mode (Simple & Secure Explanation)

In Cisco ACI, VRF Enforced Mode is the default and most secure policy model. It follows a strict white‑list approach, meaning EPGs cannot communicate with each other unless a contract explicitly allows that traffic. Even if two EPGs exist in the same VRF, they still need a contract for inter‑EPG communication.

Why VRF Enforced Mode Matters

• Secure by default: All inter‑EPG traffic is denied until permitted by a contract.
• Controlled micro-segmentation: Only required communication paths are opened.
• Intra‑EPG traffic allowed: Endpoints inside the same EPG can talk freely unless isolation is configured.

Other Policy Modes

• Unenforced Mode:
  All traffic inside the VRF is allowed without contracts. Used rarely—mainly for testing or troubleshooting.
• Preferred Group:
  A flexible option where selected EPGs can communicate freely, while others still require contracts. Useful during migrations or gradual policy tightening.

How to Configure VRF Enforced Mode

Navigate to:
Tenants → [Tenant Name] → Networking → VRFs

Under Policy Control Enforcement Preference, choose:
🔒 Enforced

Once enabled, contracts become mandatory for any EPG-to-EPG communication.

Switching from Unenforced to Enforced

If you’re tightening security from an unenforced setup, you can enable Preferred Groups to avoid breaking existing traffic flows during the transition. This allows a smooth shift while still moving toward full policy enforcement.

A Beginner’s Guide to Ansible Roles for Network Automation

 Understanding Ansible Roles: The Smart Way to Organize Your Automation

When your automation projects start growing, keeping playbooks clean and reusable becomes essential. That’s where Ansible roles step in—providing a structured, scalable way to organize your automation logic.

An Ansible role bundles together everything your playbook needs, such as:

• Variables
• Tasks
• Templates
• Files
• Handlers
• Custom modules

This modular approach not only keeps your work tidy but also makes it effortless to reuse and maintain automation across multiple projects.

Creating an Ansible Role

Ansible offers a built‑in utility called ansible-galaxy to generate a ready‑to-use role structure. This creates a fully structured directory containing all folders required for your role.

Key Directories You’ll Use Most in Network Automation

While a role contains multiple folders, a few are especially important for network engineers:

1. defaults/

This folder holds baseline default values for your variables. If your playbook does not pass a variable, Ansible uses the value defined here.

2. tasks/

The heart of any role.
All reusable task logic lives here—allowing you to write shorter playbooks and maintain your automation in one central place.

3. templates/

Used to store Jinja2 templates that your tasks render dynamically during execution.

4. vars/

This is where you define variables used within tasks or templates.
Defaults can be kept in the defaults/ directory, but if a variable has no fallback value, it must be defined here for the role to work properly.

Why Use Roles?

Ansible roles bring clarity, modularity, and reusability to your automation workflows. Whether you're building network configs or managing large infrastructure deployments, roles ensure consistency while drastically reducing repetitive work.

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.