Saturday, 30 August 2025

Cisco ACI - Node Stateful Vs Stateless reload

 

Aspect

Stateful Reload

Stateless Reload

Definition

Reload where process state is preserved using checkpoints

Reload where process starts fresh without any prior state

State Preservation

Yes – runtime state is saved to Persistent Storage Services (PSS)

No – process is restarted without retaining previous state

Recovery Speed

Faster – resumes from last known state

Slower – requires full reinitialization

System Impact

Minimal – seamless continuation of operations

Higher – may cause temporary disruption or delay

Use Case

Preferred for critical services needing quick recovery

Used when state cannot be preserved or process needs a clean start

Managed By

Persistent Storage Services (PSS)

System Manager

Example Scenario

Restarting a service with session data intact

Replacing a crashed process with a new instance

 

Thursday, 28 August 2025

ACI Node state - undiscovered Vs Unknown

 

  Undiscovered:

  • You’ve manually added a node ID in APIC.
  • The switch is not yet connected or powered on.
  • Could be due to cabling issues or incorrect port configuration.

  Unknown:

  • The switch is physically connected and sending LLDP packets.
  • APIC detects it but doesn’t have a matching Node ID policy.
  • You need to assign a Node ID to complete discovery.

 

Tuesday, 26 August 2025

What is a Contract Preferred Group in ACI?

 🔷 What is a Contract Preferred Group in ACI?

In Cisco ACI, Endpoint Groups (EPGs) typically require contracts to communicate with each other. This follows the “allow list” model, where communication is explicitly permitted only if a contract exists.

The Preferred Group (PG) feature simplifies this by allowing certain EPGs within the same VRF to communicate freely without contracts.


Key Concepts

Term

Description

Included EPGs

EPGs that are part of the preferred group and can communicate with each other without contracts.

Excluded EPGs

EPGs outside the preferred group that still require contracts to communicate.

VRF PG Setting

Must be enabled for the preferred group to work. Without this, even included EPGs won’t communicate freely.


🛠️ Configuration Steps

  1. Enable Preferred Group on VRF:
    • Go to the VRF settings in APIC or Nexus Dashboard Orchestrator (NDO).
    • Check the Preferred Group box.
  2. Add EPGs to the Preferred Group:
    • In the EPG properties, check Include in Preferred Group.
    • Save the configuration.
  3. Verify Membership:
    • You can view all EPGs in the preferred group under the VRF’s properties.

🌐 Multi-Site Considerations

  • In a stretched VRF across multiple sites, preferred group EPGs are shadowed in other sites to enable inter-site communication.
  • This allows, for example, a web EPG in Site 1 to communicate with an app EPG in Site 2 without contracts.

⚠️ Limitations

  • Preferred Groups are not supported for L3Out external EPGs.
  • If vzAny is already consuming/providing a contract in the VRF, you should not configure preferred groups.
  • All EPGs in a preferred group must be managed consistently (either all via APIC or all via NDO).

 

ACI Leaf Switch Replacement

 To replace a Cisco ACI leaf switch, follow these step-by-step instructions to ensure a smooth transition without disrupting your fabric:


🛠️ Preparation

  1. Document the existing switch details:
    • POD ID
    • Node ID
    • Node Name
    • Serial Number 
  1. Ensure the replacement switch is in ACI mode:
    • Connect via console and run show version.
    • If in NX-OS mode, convert to ACI mode using Cisco's documented procedure 
    • Before adding the new leaf switch to the fabric, ensure it's manually upgraded to the target image or one with a direct upgrade path. Avoid using intermediate images that require multiple upgrade steps, as they can trigger issues and impact your production environment. A final upgrade via policy helps ensure BIOS and FPGA components are properly updated.
  1. Clean up the replacement switch:
    • Run setup-clean-config.sh and then reload to remove any existing configuration 

🔄 Decommission the Faulty Leaf Switch

  1. Go to APIC GUI:
    Fabric > Inventory > Fabric Membership
  2. Right-click the faulty switch → Select Decommission.
  3. Once decommissioned, Remove from Controller and confirm the action 
  4. Physically disconnect and unmount the old switch.

🔌 Install and Connect the New Leaf Switch

  1. Mount the new switch and connect uplinks to spine switches. DONOT CONNECT DOWNLINK AT THIS STAGE
  2. Power on the switch.
  3. In APIC GUI, go to:
    Fabric > Inventory > Fabric Membership > Nodes Pending Registration
  4. Verify serial number, then Register the switch:
    • Use the same POD ID, Node ID, and Node Name as the old switch 
  1. Once registered, go to:
    Fabric > Inventory > Fabric Membership > Registered Nodes
    → Right-click → Select Commission.
  2. Wait for the switch to reach Active state.

🔍 Post-Replacement Validation

  1. Connect downlink cables (after switch is active).
  2. Go to:
    Fabric > Inventory > Topology
    → Verify the switch is visible and operational.
  3. SSH into APIC and run:

→ Confirm switch status is active 

  1. If you get SSH warnings (e.g., DNS spoofing), update the known_hosts file:

🧩 Troubleshooting Tips

  • Switch not discovered: Check LLDP neighbors and cable connections.
  • Switch shows "Not Supported": Upgrade APIC firmware to match switch model.
  • No TEP IP assigned: May be a DHCP issue—contact Cisco TAC.
  • SSL issues: Check for established sessions on port 12215 

Sunday, 24 August 2025

Common Causes of "Unknown" Leaf State

 

 Common Causes of "Unknown" Leaf State

  • Certificate Issues: The leaf might not be presenting a valid certificate chain to the APIC, which prevents proper SSL handshake and authentication.

  • LLDP Mismatch or Failure: ACI relies on LLDP (Link Layer Discovery Protocol) for fabric discovery. If LLDP info isn’t exchanged correctly between APIC and leaf, discovery fails.

  • Firmware Incompatibility: The leaf switch might be running a version of ACI software that’s not compatible with the APIC or spine switches.

  • Hardware Problems: Faulty transceivers, cables, or ports can block communication between APIC and leaf.

  • Time Sync Issues: If the leaf’s system time is out of sync with the APIC, certificate validation may fail.

  • Incorrect Node ID or Serial Number: If the leaf was previously part of another fabric or misconfigured, it may need to be wiped and re-initialized.

Saturday, 23 August 2025

ACI Contracts Components - Contacts Vs Filters Vs Aliases Vs Labels

 In Cisco ACI (Application Centric Infrastructure), Contracts are a key component of the policy model, used to define how endpoints (EPGs) communicate with each other. Within contracts, the terms LabelsFiltersAliases, and Subjects each play distinct roles. Here's a breakdown of each:


🔹 1. Filters

  • Purpose: Define the actual traffic (protocols, ports) that is allowed or denied.
  • Details:
    • Filters are composed of entries specifying Layer 4 information like TCP/UDP ports and protocols.
    • They are reusable across multiple contracts.
    • Example: A filter might allow TCP traffic on port 80 (HTTP).

🔹 2. Subjects

  • Purpose: Act as containers within a contract that reference filters and define directionality.
  • Details:
    • A contract can have multiple subjects.
    • Each subject can reference one or more filters.
    • You can specify whether the traffic is unidirectional or bidirectional.
    • Example: A subject might define that HTTP traffic is allowed from EPG A to EPG B.

🔹 3. Aliases

  • Purpose: Provide a way to abstract or alias filters for reuse or simplification.
  • Details:
    • Aliases are less commonly used and are more relevant in complex policy models.
    • They can help in referencing filters indirectly, making policy definitions more modular.

🔹 4. Labels

  • Purpose: Used for categorization and policy enforcement.
  • Details:
    • Labels can be applied to contracts, EPGs, and other objects.
    • They help in grouping and applying policies based on tags.
    • Useful in large environments for automation and policy scaling.

🧩 How They Work Together in a Contract

  • Contract contains one or more Subjects.
  • Each Subject references one or more Filters (or Aliases to filters).
  • Labels can be used to tag contracts or EPGs for organizational or policy purposes.

 

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.)