Showing posts with label Network Automation. Show all posts

Wednesday, 6 May 2026

DNAC Enterprise vs Cluster Interface – Architecture, Design & Best Practices, DNAC Interview Questions

DNAC Interface Overview

Cisco DNA Center primarily uses two important interfaces:

Enterprise Interface (ENT) – External communication
Cluster Interface – Internal node communication

Both serve completely different purposes but are equally important.

Enterprise Interface (ENT)

What is Enterprise Interface?

The Enterprise Interface is the main external-facing interface of DNAC.

Enterprise interface in DNAC is always deployed as Layer 3.

It is used by:

Network engineers (GUI access)
APIs and integrations
Network devices

Key Functions

The ENT interface is responsible for:

GUI access (HTTPS)
REST API communication
Device management (Switches, Routers, WLCs)
Integration with external services:
- DNS
- NTP
- TACACS / RADIUS
- Active Directory
Third-party integrations (ServiceNow, SIEM)

Key Characteristics

Routable IP address
Accessible from enterprise network
Carries management and telemetry traffic
User-facing interface
Mission-critical for operations

Design Best Practices

Ensure high availability
Apply proper firewall/security policies
Avoid congestion (affects automation & telemetry)
Place in secure DC/management VLAN

Cluster Interface

What is Cluster Interface?

The Cluster Interface is used for internal communication between DNAC nodes.

Cluster interface in DNAC is typically deployed as Layer 2 (same subnet/VLAN) — NOT routed (L3)

👉 This is only required in multi-node cluster deployments (e.g., 3-node cluster).

Key Functions

The cluster interface handles:

Node-to-node communication
Database replication
Application synchronization
Cluster health monitoring
Workload distribution

Key Characteristics

Not accessible by users
Used only internally
Typically non-routable or restricted
Requires low latency
Sensitive to packet loss

Design Best Practices

Use a dedicated network
Ensure low latency (same DC preferred)
Avoid WAN usage
Monitor bandwidth utilization
Keep it isolated for stability

Enterprise vs Cluster Interface (Comparison)

Enterprise Interface

External communication
GUI and API access
Device connectivity
Routable and user-facing
Required in all deployments

Cluster Interface

Internal communication
Node synchronization
Database replication
Private and restricted
Required only in multi-node clusters

Real-World Deployment Example

In a 3-node DNAC cluster:

Enterprise Network: 10.10.10.0/24
Cluster Network: 192.168.100.0/24

Traffic Flow

Users access GUI → Enterprise Interface
Devices communicate → Enterprise Interface
Node synchronization → Cluster Interface

Common Mistakes to Avoid

Using same network for ENT and Cluster
Deploying cluster communication over WAN
Ignoring latency requirements
Not securing ENT interface
Underestimating cluster bandwidth

Troubleshooting Guide

Check Enterprise Interface if:

GUI is not accessible
Devices are unreachable
API calls are failing

Check Cluster Interface if:

Cluster health is degraded
Nodes are out of sync
Database or service issues occur

Why This Matters

Incorrect interface design can cause:

Device onboarding failures
Automation issues
Data inconsistency
Cluster instability
Poor user experience

Final Thoughts

Enterprise Interface = External communication gateway
Cluster Interface = Internal DNAC backbone

Both interfaces play a crucial role in ensuring:

Stability
Scalability
High performance

Designing them correctly ensures a reliable Cisco DNA Center deployment.

Conclusion

Understanding the difference between ENT and Cluster interfaces is essential for every network engineer working with Cisco DNAC.

A well-designed interface architecture results in:

Better performance
Easier troubleshooting
Improved user experience

Sunday, 15 March 2026

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.

Sunday, 8 March 2026

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.