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.

Difference between Aliases and Labels - Aliases VS Labels - Cisco ACI

 

Feature	Aliases	Labels
Purpose	Abstract reference to filters for modular contract design	Tagging mechanism for categorization and automation
Used In	Subjects within Contracts	EPGs, Contracts, Bridge Domains, Application Profiles, etc.
Functionality	Indirectly reference filters to simplify reuse	Group and organize objects; used in automation workflows
Visibility	Internal, technical use	Administrative, visible in UI and automation tools
Example Use Case	Reuse a common filter across multiple subjects	Tag all web-tier contracts with web-tier for easy grouping
Impact on Policy	Affects how filters are applied in traffic rules	Helps in applying policies based on tags or roles
Automation Role	Minimal	Significant (used in scripts, templates, etc.)

 

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

 

Static Binding Deployment Options in ACI - Immediate Vs On demand

 🔧 Static Binding Deployment Options in ACI

When you statically bind an EPG to a port (interface), you’ll see a Deployment Immediacy setting. This determines when the configuration is pushed to the fabric.

1. Immediate

• Definition: The configuration is deployed to the switch as soon as you save it.
• Use Case: Use this when the endpoint is already connected or expected to connect soon.
• Behavior: The policy is applied to the interface regardless of whether an endpoint is present.

2. On-Demand

• Definition: The configuration is deployed only when an endpoint is detected on the interface.
• Use Case: Useful for reducing unnecessary configuration on interfaces until needed.
• Behavior: The policy is not pushed until the APIC sees a MAC address or IP on that port.

---

📌 Where You Set This

When creating a static binding in the APIC GUI:

• Navigate to the EPG → Static Ports
• Add a static port binding
• Choose the Deployment Immediacy: Immediate or On-Demand

---

✅ Best Practices

• Use Immediate for known, always-on devices (like servers).
• Use On-Demand for dynamic environments (like user laptops or VMs that move).

 

Forward Error Correction (FEC) in Cisco ACI

 In Cisco ACI, Forward Error Correction (FEC) is a mechanism used to improve the reliability of high-speed data transmission across physical links, especially in environments using 25G, 40G, 100G, or 400G interfaces.

🔍 What Is Forward Error Correction?

FEC is a technique where the sender adds redundant data (parity bits) to each transmission. If some bits are corrupted during transit, the receiver can detect and correct those errors without needing a retransmission. Think of it like sending a puzzle with extra pieces so the receiver can still complete it even if a few pieces go missing.

🧠 How FEC Works in Cisco ACI

In ACI, FEC is negotiated between switches and endpoints during auto-negotiation. The devices advertise their supported FEC modes and agree on the best one. Common FEC modes include:

• FC-FEC (Firecode FEC): Used for 25G links.
• RS-FEC (Reed-Solomon FEC): Used for 25G, 100G, and 400G links.
• CL91-RS-FEC and IEEE-RS-FEC: Advanced versions for higher speeds.
• AUTO-FEC: Automatically selects the best FEC mode based on link capabilities.

⚙️ Why It Matters

FEC is especially important in Cisco ACI because:

• High-speed links (like 25G or 100G) are more prone to bit errors.
• Breakout ports (e.g., 4x25G from a 100G port) often require FEC to maintain link stability.
• Copper DAC cables used in short-distance connections rely on FEC to compensate for signal degradation.

✅ Use Cases

• Ensuring error-free transmission over high-speed links.
• Supporting auto-negotiation on breakout ports.
• Enhancing link reliability without increasing latency or requiring retransmissions.

 

Symmetric hashing in Cisco ACI

 

🔄 Symmetric Hashing in Cisco ACI: A Traffic Balancing Philosophy

Imagine a highway with multiple lanes, and cars (data packets) trying to reach their destination. Normally, each car chooses a lane based on its starting point and destination. But what if the return journey picks a different lane? That’s what happens with asymmetric hashing — the forward and reverse paths of a data flow may travel through different physical links.

In Cisco ACI, symmetric hashing is like a rule that says: “If you go out through lane 3, you must come back through lane 3.” It ensures that both directions of a traffic flow — from source to destination and back — follow the same physical path within a port channel.

This matters a lot when you're dealing with devices like firewalls, load balancers, or any system that tracks sessions. If traffic enters through one link and exits through another, it can confuse these devices, leading to dropped packets or broken connections.

Symmetric hashing is not supported on the following switches:

• Cisco Nexus 93128TX
• Cisco Nexus 9372PX
• Cisco Nexus 9372PX-E
• Cisco Nexus 9372TX
• Cisco Nexus 9372TX-E
• Cisco Nexus 9396PX
• Cisco Nexus 9396TX

🧠 Why Cisco ACI Made It Optional

Cisco ACI’s default behavior is asymmetric — it spreads traffic across links based on a hash of various packet fields (IP, MAC, ports). This works well for general load balancing. But when precision and consistency are needed, ACI gives you the option to enable symmetric hashing in the port-channel policy.

Once enabled, you can choose the hashing algorithm — like using only IP addresses or including Layer 4 ports — to fine-tune how traffic is distributed.

✅ Use Cases That Benefit

• Firewall clusters that expect consistent ingress/egress paths.
• Load balancers that rely on session stickiness.
• Troubleshooting scenarios where symmetric paths simplify packet tracing.

 

Difference between “Treat as Virtual IP Address” and “Make this IP Address Primary” in Cisco ACI

 

---

🧠 Cisco ACI Demystified: “Treat as Virtual IP Address” vs “Make this IP Address Primary”

In the world of Cisco ACI, Bridge Domains (BDs) are the backbone of Layer 2 networking. But when configuring subnets within a BD, two deceptively similar options often confuse engineers:

• ✅ Make this IP Address Primary
• 🌐 Treat as Virtual IP Address

Let’s break down what each of these means, when to use them, and how they impact your ACI fabric.

---

🔹 What is “Make this IP Address Primary”?

This option is used to define the default gateway for endpoints within the Bridge Domain.

✅ Key Characteristics:

• Only one primary IP per BD.
• Used for routing traffic between subnets or to external networks.
• Responds to ARP requests from endpoints.
• Can be advertised externally if route advertisement is enabled.

📌 When to Use:

• In single-site ACI deployments.
• When you want the fabric to act as the default gateway for endpoints.
• For standard BD configurations where no multi-site or stretched fabric is involved.

---

🔹 What is “Treat as Virtual IP Address”?

This option is designed for multi-site or stretched fabric deployments where you want a consistent gateway IP and MAC address across multiple locations.

🌐 Key Characteristics:

• Requires a Virtual MAC address.
• Enables Common Pervasive Gateway (CPG) functionality.
• Ensures seamless endpoint mobility across sites.
• Can coexist with a primary IP in the same BD.

📌 When to Use:

• In multi-pod or multi-site ACI environments.
• When you need Layer 3 gateway consistency across data centers.
• For active-active data center designs.

---

🔁 Side-by-Side Comparison

Feature	Make this IP Primary	Treat as Virtual IP Address
Default Gateway Role	✅ Yes	✅ Yes (in multi-site)
Number per BD	One	Multiple (with virtual MAC)
Requires Virtual MAC	❌ No	✅ Yes
Use Case	Single-site routing	Multi-site gateway consistency
Supports Endpoint Mobility	❌ Limited	✅ Seamless
Route Advertisement	✅ Yes (if enabled)	✅ Yes (if enabled)

---

🧪 Real-World Example

Imagine you have two data centers—DC1 and DC2—connected via ACI Multi-Site. You want VMs to move between them without changing their default gateway.

• You’d configure the same subnet in both sites.
• Use “Treat as Virtual IP Address” with a shared virtual MAC.
• This ensures the gateway IP and MAC remain consistent, avoiding disruptions.

---

🧩 Final Thoughts

Both options serve critical but distinct purposes. Choosing the right one depends on your ACI topology and traffic flow requirements. For most single-site deployments, “Make this IP Address Primary” is sufficient. But for advanced, distributed environments, “Treat as Virtual IP Address” is your go-to for seamless mobility and high availability.