Cisco ACI - MoQuery command

Understanding moquery in Cisco ACI: Safe, Powerful & Zero Impact

When working with Cisco ACI, the moquery command is one of the most valuable troubleshooting tools. It allows engineers to query the Management Information Tree (MIT) and extract detailed information about ACI objects—tenants, VRFs, EPGs, BDs, contracts, endpoints, and more.

The best part?

moquery is completely safe.

It is 100% read‑only, meaning it does not modify, push, or impact any ACI policies or traffic. Running it has no effect on leaf/spine switches, and it produces only minimal overhead on the APIC—similar to refreshing a GUI page.

Why Engineers Love moquery

• Fetches deep fabric details instantly
• Helps troubleshoot contracts, mappings, scopes, and endpoints
• Works directly on the APIC without touching data-plane devices
• Safe to use even on busy production fabrics

Popular Examples

moquery -c fvBD # Bridge Domains

moquery -c fvCtx # VRFs

moquery -c fvAEPg # EPGs

moquery -c fvCEp # Endpoints

moquery -c fvRsProv # Provided contracts

Bottom Line If you need to inspect anything inside the ACI fabric, moquery is your safest and most powerful command. It gives you deep visibility without any operational risk—making it a must-have tool for every ACI engineer.

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.