Showing posts with label Cisco ACI Basics. Show all posts
Showing posts with label Cisco ACI Basics. Show all posts

Friday, 8 May 2026

Cisco ACI Decommission Only vs Remove vs Secure Remove — Complete Guide with Management IP Behavior

Introduction

In Cisco ACI environments, switch lifecycle management is a critical operational task. Whether you are performing a node ID change, replacing hardware, or decommissioning a switch permanently, understanding the differences between Decommission Only, Decommission & Remove, and Decommission & Secure Remove is essential.

Many engineers misunderstand these options, especially when it comes to switch behavior, APIC interaction, and management IP handling, which can lead to unexpected outages or onboarding failures.

In this detailed guide, we will break down each option with real-world behavior, management IP impact, and best-use scenarios.

What Happens During Decommission in Cisco ACI

Decommissioning in ACI involves three key components:

  1. Switch (Leaf/Spine) behavior
  2. APIC database behavior
  3. Fabric identity and configuration handling

Each decommission option treats these components differently.

1. Decommission Only (Reset but Keep Identity)

Behavior

  • Switch is wiped and reloaded
  • Node ID and serial number mapping is retained in APIC
  • APIC retains configuration for that node

After Reload

  • Switch boots in clean state
  • Automatically rejoins the fabric
  • No manual intervention required

Management IP Behavior

  • OOB Management IP (mgmt0):
    • Retained and reused
    • No need to reconfigure
  • TEP IP:
    • Re-established automatically

Key Advantage

  • Fast recovery without reconfiguration

Use Case

  • Fixing switch issues without changing node identity
  • Restarting node cleanly
  • Troubleshooting fabric inconsistencies

Important Insight

This is the only mode where the switch auto-rejoins the fabric without manual setup.

2. Decommission & Remove (Reset + Remove Identity)

Behavior

  • Switch is wiped and reloaded
  • Node registration is removed from APIC
  • APIC retains logical configuration (policies, tenants)

After Reload

  • Switch appears as:
    • Unregistered node
  • Requires manual onboarding via:
    • Fabric → Inventory → Node Setup

Management IP Behavior

  • OOB Management IP (mgmt0):
    • Not retained logically in APIC
    • Needs to be re-entered or reconfigured
  • TEP IP:
    • Reassigned during recommission

Key Advantage

  • Allows fresh onboarding of the same hardware

Use Case

  • Node ID change
  • Recommissioning switch
  • Hardware replacement (same fabric)
  • Moving switch within fabric design

Critical Step

You must perform:

run bash
setup-clean-config.sh
reload

Practical Risk

If you skip cleanup:

  • Residual configs may remain
  • Fabric join issues can occur

3. Decommission & Secure Remove (Full Secure Wipe)

Behavior

  • Switch is:
    • Securely wiped (deep erase)
    • Reloaded
  • Removes:
    • Configuration
    • Certificates
    • Encryption keys
    • Fabric identity

After Reload

  • Switch becomes:
    • Factory-like device
  • Cannot join fabric directly

Management IP Behavior

  • OOB Management IP:
    • Completely erased
  • TEP IP:
    • Fully removed

Key Requirement

  • Requires:
    • ACI image validation/reload (if removed)
    • Complete day-0 onboarding

Key Advantage

  • Ensures zero residual data

Use Case

  • Device disposal
  • RMA return
  • Moving switch to a different customer/fabric
  • Security compliance requirements

Side-by-Side Comparison

FeatureDecommission OnlyDecommission & RemoveSecure Remove
Switch ReloadYesYesYes
Config WipeYes (normal)Yes (normal)Full secure wipe
Node ID RetainedYesNoNo
Auto Rejoin FabricYesNoNo
Manual RecommissionNoYesYes
Mgmt IP (OOB)RetainedNeeds reconfigFully erased
TEP IPAuto restoredReassignedRemoved
Secure Data EraseNoNoYes

Real-World Decision Guide

Use Decommission Only When:

  • You want quick reset
  • You are not changing Node ID
  • You want automatic fabric rejoin

Use Decommission & Remove When:

  • You are:
    • Changing Node ID
    • Rebuilding switch
    • Replacing hardware
  • You are okay with manual recommission

Use Secure Remove When:

  • Device is leaving environment
  • Security wipe is required
  • Moving to new fabric/customer

Common Mistakes to Avoid

1. Assuming “Remove” wipes everything

It does not remove all residual configs. Always run cleanup script.

2. Forgetting Management IP

  • After Decommission & Remove:
    • Mgmt IP must be planned and reconfigured
  • After Secure Remove:
    • Completely lost

3. Using Decommission Only for Node ID Change

This will fail because:

  • Node identity is preserved
  • APIC will not allow new ID

Pro Tip (Very Important for Production)

Before any decommission:

✅ Note down:

  • Node ID
  • Serial number
  • Management IP
  • TEP pool

✅ Ensure:

  • Console access is available

✅ Plan:

  • Multiple reload windows

Conclusion

Understanding the differences between Decommission Only, Decommission & Remove, and Secure Remove is crucial for smooth Cisco ACI operations.

  • Decommission Only keeps identity and allows auto-rejoin
  • Decommission & Remove resets switch and requires manual setup
  • Secure Remove completely wipes the device for disposal or reuse

The biggest differentiator in real environments is management IP behavior and node identity retention, which directly impacts how the switch rejoins the fabric.


Please refer to below blog for Leaf Node ID swap

Networklearner: Leaf Node ID Swap in Cisco ACI: Risks, Precautions, and Steps

Tuesday, 28 April 2026

How to Safely Decommission a Leaf Switch in Cisco ACI — Step-by-Step Guide with Checklist

 Decommissioning a leaf switch in a Cisco ACI fabric is a high‑impact operational activity. Doing it correctly avoids outages, policy corruption, ghost nodes, and rediscovery issues. Doing it incorrectly can result in traffic loss, unresolved faults, and extended downtime.

Many engineers think decommissioning a leaf is as simple as clicking a button in APIC. In reality, Cisco ACI follows a strict dependency and lifecycle model, and a leaf must be carefully prepared before removal.

This blog explains how to decommission a leaf switch from an ACI fabric safely, with real‑world checks, APIC steps, CLI verification, and best practices. It is written for production environments, troubleshooting scenarios, and interviews.


What Does “Decommissioning a Leaf Switch” Mean in ACI?

In Cisco ACI, decommissioning a leaf switch means:

  • Removing the switch from fabric membership
  • Withdrawing all policies and certificates
  • Detaching the switch logically from the fabric control plane
  • Preparing it for power‑off, replacement, or reuse

Decommissioning is a logical operation, not just a hardware action.


Why Proper Decommissioning Is Critical

Incorrect decommissioning can lead to:

  • Traffic outages due to active endpoints
  • Broken vPC or port‑channel configurations
  • L3Out or BGP/OSPF failures
  • “Ghost nodes” still visible in APIC
  • Problems when re‑adding or repurposing the switch

In production data centers, a clean decommission is often part of:

  • Hardware refresh
  • RMA replacement
  • Capacity rebalancing
  • Fabric redesign

Pre‑Decommission Checklist (Very Important)

Before you touch APIC, validate all dependencies. This is where most failures occur.

1. Confirm No Active Endpoints on the Leaf

A leaf with active endpoints must not be decommissioned.

APIC GUI path:

Fabric → Inventory → Pod → Node → Leaf → Endpoints

✅ Endpoint count should be 0

Optional APIC CLI:

Shell
moquery -c fvCEp | grep node-<leaf-id>

If endpoints are present:

  • Migrate workloads
  • Shut down ports
  • Move static bindings

2. Remove Static EPG Bindings

Static path bindings directly tie an EPG to a leaf port.

APIC GUI path:

Tenant → Application Profile → EPG → Static Ports

Remove:

  • Access ports
  • Port‑channels
  • vPC bindings

⚠️ A leaf with static bindings will fail decommission.


3. Handle vPC and Port‑Channels Properly

If the leaf is part of a vPC pair:

  • Remove vPC associations
  • Remove port‑channels
  • Ensure services are moved to the peer leaf

Never decommission one side of an active vPC without cleanup.


4. Check if the Leaf Is a Border Leaf (L3Out)

If the leaf is used for L3Out:

  • Remove it from:
    • Logical Node Profile
    • Logical Interface Profile
  • Ensure routing is functional on alternate border leaves
  • Verify BGP/OSPF is stable

Decommissioning a border leaf without migration can cause external connectivity outages.


Step‑by‑Step: Decommissioning a Leaf Switch from ACI Fabric

Step 1: Verify Fabric Health (Recommended)

Before removing infrastructure components, ensure fabric health is stable.

Fabric → Inventory → Fabric Membership
  • No critical fabric‑wide faults
  • Controllers and spines healthy

This reduces unexpected behavior during changes.


Step 2: Decommission the Leaf from APIC

This is the main and officially supported step.

APIC GUI path:

Fabric → Inventory → Fabric Membership
  1. Select the leaf switch
  2. Click Actions
  3. Choose Decommission
  4. Confirm the action

APIC will:

  • Withdraw policies
  • Remove certificates
  • Update fabric membership state

⏱️ This usually takes 1–2 minutes.


Step 3: Verify Decommission Status

After completion, confirm the state.

APIC GUI:

Fabric → Inventory → Fabric Membership

Leaf should show:

  • Decommissioned or Removed

Optional APIC CLI:

Shell
moquery -c fabricNode | grep <leaf-id>

Step 4 (Optional but Strongly Recommended): Clean the Switch

Once decommissioned, APIC no longer manages the switch.
If the switch will be reused or re‑added, you must clean it locally.

How to Clean the Decommissioned Leaf

Access via:

  • Console
  • OOB management
  • CIMC / KVM (if available)

Run:

Shell
acidiag touch clean
reload

This removes:

  • Fabric certificates
  • Node ID
  • ACI state information

After reboot, the switch will be ready for fresh discovery.


What NOT to Do (Common Mistakes)

MistakeImpact
Decommission with live endpointsTraffic outage
Skip static path cleanupDecommission failure
Forget L3Out dependenciesExternal routing outage
Power off without decommissionGhost node in APIC
Skip cleaning before reuseRediscovery failures

Leaf vs Spine Decommissioning (Quick Comparison)

ItemLeafSpine
Endpoint check required✅ Yes❌ No
Policy dependency cleanup✅ Mandatory❌ Minimal
L3Out impact✅ Possible❌ None
Redundancy consideration✅ Workloads✅ Fabric
Last node restriction❌ Leaf allowed❌ Never remove last spine

Real‑World Decommission Scenarios

Scenario 1: Hardware Refresh

A leaf is replaced due to lifecycle expiry.
Decommission old leaf → clean → rack new leaf → approve membership.

Scenario 2: RMA Replacement

Failed leaf is decommissioned logically, replaced physically, and re‑added with the same or new node ID.

Scenario 3: Fabric Re‑design

Leaf removed as part of capacity reshaping or topology optimization.


Troubleshooting Decommission Failures

If decommission fails:

  • Check for:
    • Active endpoints
    • Static bindings
    • vPC remnants
  • Look at Faults under the leaf
  • Verify no L3Out or service graph references remain

ACI always points to what dependency is blocking the operation.


Interview‑Ready Questions and Answers

Q: How do you decommission a leaf switch in Cisco ACI?
A: Remove all endpoints and policy dependencies, then decommission the leaf from Fabric Membership in APIC.

Q: Can you decommission a leaf with active endpoints?
A: No, endpoints must be removed first.

Q: Why run acidiag touch clean after decommission?
A: To remove fabric identity and prepare the switch for reuse or rediscovery.


Best Practices Summary

  • Always validate endpoints and bindings first
  • Treat border leaves with extra caution
  • Use vPC and redundancy wisely
  • Clean switches before reuse
  • Document node IDs and reasons for decommission

Final One‑Line Summary

In Cisco ACI, a leaf switch must be carefully prepared, cleaned of dependencies, and decommissioned through Fabric Membership in APIC to ensure a safe and outage‑free fabric operation.

Sunday, 26 April 2026

Cisco ACI Explained: Concepts, Learning Prerequisites, Benefits, and Limitations-Cisco ACI Interview Questions


Modern data centers are under constant pressure to deliver higher scalability, stronger security, faster application deployment, and simpler operations. Traditional networking built around individual switches, VLANs, and CLI‑based configuration struggles to meet these demands at scale. To address these challenges, Cisco introduced Application Centric Infrastructure (ACI)—a policy‑driven, software‑defined approach to data center networking.

This blog provides a complete introduction to Cisco ACI, covering ACI fundamentals, key concepts, learning prerequisites, why organizations adopt ACI, and where ACI has limitations. The goal is to help network engineers, architects, and beginners understand what ACI is, why it exists, and whether it is the right choice for their environment.


What Is Cisco ACI?

Cisco ACI (Application Centric Infrastructure) is a policy‑based data center networking solution that centralizes network management and shifts the focus from individual devices to applications and their communication requirements.

Unlike traditional Nexus switching, where each switch is configured independently, Cisco ACI uses:

  • A fabric architecture built on Nexus 9000 switches
  • A centralized controller called APIC (Application Policy Infrastructure Controller)
  • A declarative policy model, where intent is defined once and enforced across the entire fabric

In simple terms, ACI allows network teams to describe what the application needs, rather than configuring how each switch should behave.


Why Cisco ACI Was Introduced

Traditional data center networking has several limitations:

  • Device‑centric configuration
  • Manual VLAN and ACL management
  • Inconsistent policies across switches
  • Difficult scalability
  • Slow application onboarding

As data centers evolved toward virtualization, microservices, and hybrid cloud, these limitations became more visible. Cisco ACI was introduced to:

  • Simplify operations
  • Improve security
  • Enable automation
  • Provide consistent policy enforcement at scale

Cisco ACI Architecture Overview

Cisco ACI uses a leaf–spine fabric architecture.

  • Leaf switches connect to endpoints such as servers, firewalls, load balancers, and L3Outs.
  • Spine switches provide high‑speed forwarding between leafs.
  • APIC controllers manage and program the fabric.

All endpoints connect only to leaf switches, and leaf switches connect to all spine switches. This design ensures predictable latency, high bandwidth, and easy scalability.

Importantly, APIC does not sit in the data path. If APIC goes down, traffic continues to flow normally, making ACI operationally safe.


Core Cisco ACI Concepts

Understanding ACI requires learning a few key concepts. Once these are clear, the model becomes much easier to work with.

Tenant

A Tenant is an administrative container that represents a customer, business unit, or environment (for example, Prod, Dev, or Shared Services). It provides logical separation within the fabric.

VRF (Context)

A VRF (Virtual Routing and Forwarding instance) defines a Layer‑3 routing domain. Multiple VRFs can exist within a tenant, and each VRF is isolated by default.

Bridge Domain (BD)

A Bridge Domain represents a Layer‑2 forwarding domain (similar to a VLAN, but more powerful). It defines:

  • Flooding behavior
  • ARP settings
  • Subnets (default gateways)

Bridge Domains are associated with VRFs.

Endpoint Group (EPG)

An EPG is a logical grouping of endpoints (servers, VMs, containers) that share the same policy. Endpoints in the same EPG can communicate with each other by default.

This abstraction removes the need to think in terms of individual IPs or MAC addresses.

Contracts

By default, ACI denies traffic between EPGs. Traffic is allowed only when a contract is explicitly configured.

Contracts define:

  • Who can talk (consumer/provider)
  • What traffic is allowed (filters)
  • Direction and scope

This built‑in deny‑by‑default model makes ACI inherently more secure than traditional flat networks.


Traffic Flow in Cisco ACI

One of the most important ACI principles is deny by default.

  • Traffic within the same EPG is permitted.
  • Traffic between different EPGs is denied unless a contract exists.
  • No implicit trust exists between applications.

This design enables micro‑segmentation and aligns well with zero‑trust security principles.


Cisco ACI Learning Prerequisites

Before learning Cisco ACI, engineers should have a solid foundation in traditional networking. ACI simplifies operations, but it does not eliminate the need to understand networking fundamentals.

Recommended Prerequisites

  1. Networking Fundamentals

    • TCP/IP
    • Subnetting
    • Routing vs switching
    • ARP and MAC learning
  2. Cisco Switching Basics

    • VLANs
    • Trunking
    • STP concepts
    • Nexus switching basics
  3. Data Center Concepts

    • Virtualization (VMware concepts help a lot)
    • East‑west vs north‑south traffic
    • Basic firewall and load‑balancer understanding
  4. Mindset Shift

    • Policy‑based thinking instead of per‑device configuration
    • Understanding abstraction and logical constructs

Engineers transitioning from NX‑OS mode Nexus switches will need time to adjust, but once the model is understood, ACI becomes easier to manage than legacy designs.


How Cisco ACI Is Better Than Legacy Nexus Switching

Cisco ACI does not replace Nexus hardware—it transforms how it is used.

Centralized Management

Instead of logging into 20 or 200 switches, configuration is done once through APIC. This reduces human error and configuration drift.

Scalability

In legacy designs, scaling increases operational complexity. In ACI, adding switches or endpoints does not significantly increase operational effort.

Built‑In Security

Traditional networks allow traffic by default and rely on ACLs for restriction. ACI blocks traffic by default and allows only what is explicitly defined.

Automation and APIs

ACI has a native REST API, enabling seamless automation, DevOps integration, and infrastructure‑as‑code models.

Faster Troubleshooting

ACI provides fabric‑wide visibility. Tools like health scores, faults, and moquery let engineers troubleshoot issues faster than hopping between switches.


Real‑World Benefits of Cisco ACI

Organizations adopt Cisco ACI for several practical reasons:

  • Faster application deployment
  • Reduced configuration errors
  • Stronger security posture
  • Easier scaling
  • Better visibility and operational control

For large enterprises, service providers, and regulated environments, these benefits often justify the investment.


Cisco ACI Disadvantages and Limitations

While Cisco ACI is powerful, it is not perfect and is not suitable for every environment.

Learning Curve

ACI introduces new terminology and concepts. Engineers coming from CLI‑only backgrounds often find the initial learning curve steep.

Cost

ACI requires Nexus 9000 switches and APIC controllers. For small environments, the cost may outweigh the benefits.

Vendor Lock‑In

ACI is a Cisco ecosystem solution. Organizations looking for multi‑vendor fabrics may find this limiting.

Policy Complexity

Poor ACI design can lead to overly complex policies that are difficult to maintain. ACI simplifies good designs but exposes weak ones.

Not Always Necessary

For very small or static data centers, traditional Nexus switching may be simpler and more cost‑effective.


When Cisco ACI Makes Sense

Cisco ACI is best suited for:

  • Medium to large data centers
  • Environments with frequent change
  • Enterprises adopting automation
  • Multi‑tenant or shared infrastructure
  • Security‑focused organizations

It may not be ideal for:

  • Very small data centers
  • Teams unwilling to learn new models
  • Environments with minimal change

Conclusion

Cisco ACI represents a fundamental shift from device‑centric networking to policy‑driven, application‑centric design. While it requires a mindset change and upfront investment, it delivers strong operational, security, and scalability advantages for modern data centers.

Understanding ACI concepts, learning the prerequisites, and being aware of its limitations helps engineers and architects make informed decisions. When designed and operated correctly, Cisco ACI becomes a powerful platform that simplifies data center networking rather than complicating it.