When deploying an EPG on a vPC, both leaf switch ports (on each leg of the vPC) must be associated with the same domain and use the same VLAN pool. This ensures consistent VLAN encapsulation and proper traffic forwarding across the vPC pair.
I am a network professional with over 18 years of experience in enterprise and data‑center networking. I am a CCIE Data Center certified engineer with strong hands‑on expertise in Cisco Nexus and Cisco ACI design, deployment, troubleshooting, and operations. I work on production ACI fabrics and am available for Cisco ACI and Nexus freelancing or consulting work. Contact: rockingoa@gmail.com
Sunday, 17 August 2025
Can VLAN numbers previously used for EPGs be reused on the same leaf switch?
Yes, VLAN numbers can be reused for different EPGs on different ports of the same leaf switch, provided the configuration is done carefully to avoid disruption.
You previously used VLANs 20–100 for EPGs
on a leaf switch port. Now, you want to reuse VLANs 30-40 for new EPGs on
different ports of the same leaf switch.
- Create a new VLAN pool with the required VLAN range (e.g.,
30-40).
- Set up a new physical domain.
- Link the VLAN pool to the new physical domain.
- Set VLAN scope to portLocal on the leaf port to isolate VLAN
usage.
- Associate new EPGs with the physical domain.
- Deploy the EPGs on the target leaf ports.
Recovering and Reinitializing a Standby APIC to active APIC in Cisco ACI
Recovering and Reinitializing a Standby APIC in Cisco ACI
If you're working with
a standby APIC and need to verify access or promote it to an
active role, here’s a practical approach to follow.
🔐 Step 1: Accessing the Standby APIC
You can attempt to log
in using the rescue-user account. This account is specifically
designed for emergency access to standby controllers.
- Try using your standard APIC admin
password first.
- If the standby APIC is in sync
with the cluster, this should work.
- If not, attempt login without a
password — some configurations allow password-less access for
rescue-user in isolated standby mode.
🔄 Step 2: Reinitializing the Standby APIC as
Active
If you need to promote
a standby APIC (e.g., APIC3) to an active role, it's best to wipe and
reconfigure it from scratch. Ensure you have KVM access to
the APIC before proceeding.
Run the following
commands in sequence:
- Clean the existing configuration.
- Trigger the setup script on next boot.
- Reboot the APIC to begin the reinitialization process.
- acidiag touch clean
- acidiag touch setup
- acidiag reboot
Once rebooted, the
APIC will prompt you to configure it as part of the active cluster.
🧠 Pro Tip
Always ensure that the
APIC you’re reinitializing is physically connected to the fabric and
that you have console or KVM access. This process is irreversible and should
only be done when you're certain the APIC is no longer needed in standby mode.
Cold Standby
APIC – Key Characteristics
- Supported in both single-pod and multi-pod ACI
deployments.
- Can be connected to any leaf switch in
any pod, restoring edit capabilities in minority scenarios.
- Automatically receives firmware
updates to stay in sync with the active APIC cluster.
- During upgrades, once all active APICs are
updated, the standby APIC is upgraded automatically.
- Assigned temporary node IDs; a new ID
is issued when promoted to active.
- Admin login is disabled on standby
APICs.
- Troubleshooting is done via SSH using
the rescue-user account.
- During switchover, the replaced active
APIC is powered down to avoid dual connectivity.
- Standby APICs do not participate in
policy configuration or fabric management.
- Cisco recommends placing standby APICs in
the same pod as the active ones they may replace.
- No configuration or credential data is
replicated to standby APICs — only rescue-user access is
available.
Configuring Port Profiles in Cisco ACI (NX-OS Style CLI) - Uplink to Downlink port
Up until Cisco ACI 3.1, fabric ports on
leaf switches were hard-coded as fabric (iVXLAN) ports and could connect only
to spine switches. Starting with Cisco ACI 3.1, you can change the default
configuration and make ports that would normally be fabric links, be downlinks,
or vice-versa.
🧩 The Discovery Catch
Fabric discovery in
ACI is only supported through native fabric ports. These are
typically high-speed interfaces—like the 40/100G QSFP ports—designed
specifically for spine-leaf connectivity.
If you're planning to
connect via 10G SFP, you'll need to use a CVR-QSFP-SFP10G
adapter on one of the native QSFP ports. This allows the switch to
initiate discovery even when using lower-speed optics.
🔄 Post-Discovery Flexibility
Once the switch is
successfully discovered:
- You can reassign downlink ports
(1–48) to act as fabric ports.
- This gives you flexibility in how you
architect your connections post-onboarding.
However, this
flexibility only comes after the switch has been discovered.
Until then, you're dependent on the native fabric ports.
⚠️ Why You Should Always Keep One Native Fabric
Port Active
Even after discovery
and configuration:
- Always reserve at least one native fabric
port for fabric
connectivity.
- If the switch is wiped or reset, and no
native fabric port is active, it won’t be able to rejoin the fabric.
- This can leave you in a bind—unable to
rediscover or reconfigure the switch without manual intervention.
🧠 Pro Tip
Think of native fabric
ports as your lifeline to the ACI fabric. Use adapters if
needed, but never fully rely on converted downlink ports for long-term fabric
access.
Cisco ACI allows administrators to
configure port profiles using a familiar NX-OS style CLI. This method is
especially useful for those who prefer command-line workflows over GUI-based configuration.
Below is a step-by-step guide to help you set up a port profile on a leaf
switch.
Pre-Requisites
- The ACI fabric is fully deployed, with
APIC controllers online and the cluster in a healthy state.
- You have access to an APIC administrator account with permissions to
configure fabric infrastructure.
- The leaf switches you intend to configure are registered and visible in the
fabric.
Configuration Steps
Step 1: Enter Global Configuration Mode
Start by accessing the APIC CLI and
entering configuration mode:
apic1# configure
Step 2: Select the Leaf Node
Specify the leaf switch you want to
configure by its node ID:
apic1(config)# leaf 102
Step 3: Define the Interface
Identify the interface you want to
configure. For Ethernet ports, use the format ethernet slot/port:
apic1(config-leaf)# interface ethernet
1/2
Step 4: Set the Port Direction
Assign the port role as either uplink or
downlink. In this example, we configure it as a downlink:
apic1(config-leaf-if)# port-direction
downlink
Note: On certain models like the
N9K-C9336C-FX, changing port roles from uplink to downlink is not supported.
Step 5: Clean and Reload the Leaf Configuration
Log into the leaf switch directly and run
the following commands to apply the configuration cleanly:
setup-clean-config.sh -k
reload
Final Tip
Always verify hardware compatibility before
attempting port role changes. Some switches have fixed port roles that cannot
be modified, and skipping the clean reload step may result in incomplete
configuration.
Saturday, 16 August 2025
Cisco ACI - Node states - Unknown vs discovering vs undiscovered vs Unsupported vs decommissioned vs inactive Vs active
In Cisco ACI, node states describe the status of a fabric node (like a leaf or spine switch) in relation to the APIC controller and the overall fabric. Here's a breakdown of the common node states you mentioned:
🔹 Active
- The node is fully discovered, registered,
and operational in the fabric.
- It is participating in policy enforcement
and forwarding traffic.
🔹 Inactive
- The node is known to the APIC but is not
currently participating in the fabric.
- This could be due to administrative
shutdown or connectivity issues.
🔹 Discovering
- The APIC has detected the node and is in
the process of gathering its information.
- This is a transitional state before
becoming active.
🔹 Undiscovered
- The node is not yet detected by the APIC.
- It may be powered off, disconnected, or
not properly cabled.
🔹 Unknown
- The APIC cannot determine the state of the
node.
- This could be due to communication failure
or misconfiguration.
🔹 Unsupported
- The node is running a software version or
hardware type that is not compatible with the current ACI fabric.
- It cannot be managed or used until
upgraded or replaced.
🔹 Decommissioned
- The node has been intentionally removed
from the fabric.
- It no longer participates in any fabric
operations and is not expected to return unless re-commissioned.
🧠 Summary Table
| Node State | Description | Common Causes |
|---|---|---|
| Active | Node is fully discovered and operational within the fabric. | Successful discovery, proper cabling, compatible firmware. |
| Inactive | Node is known to APIC but not participating in the fabric. | Admin shutdown, link issues, or configuration mismatch. |
| Discovering | Node is in the process of being onboarded into the fabric. | Initial connection, waiting for LLDP adjacency or infra VLAN. |
| Undiscovered | Node is not detected by APIC. | Cabling issues, powered off, wrong port type, or missing infra VLAN. |
| Unknown | APIC cannot determine the node’s state. | Communication failure, misconfigured switch, or APIC database inconsistency. |
| Unsupported | Node hardware or software is incompatible with the current ACI fabric. | Outdated firmware, non-ACI image, or unsupported model. |
| Decommissioned | Node has been intentionally removed from the fabric. | Manual decommissioning via APIC or CLI. |
JSON Demystified: {} vs [] — What’s the Real Difference?
JSON is a data exchange format and open standard. It is based on a subset of JavaScript and is a text format that is completely language-independent.
JSON
Demystified: {} vs [] — What’s the Real Difference?
When diving into JSON,
two symbols often spark confusion: {} and []. They may look
simple, but they define the very structure of your data. Let’s break it down in
a way that’s both clear and memorable.
🧱 {} — The Architect of Structure
(JSON Object)
Think of {} as
the blueprint of a building. It defines named rooms (keys) and
what’s inside them (values).
- Purpose: Represents an object — a collection of key-value
pairs.
- Analogy: Like a dictionary or a contact card.
- Example:
Each key is a label,
and each value is the data associated with it.
📦 [] — The Organizer of Items (JSON
Array)
Now, [] is
your box of items. It holds things in order, without naming them
individually.
- Purpose: Represents an array — an ordered list of values.
- Analogy: Like a playlist or a shopping list.
- Example:
Each item is accessed
by its position, not by a name.
🔄 Together in Harmony
JSON often combines
both structures to model complex data:
Here:
- {} defines the overall structure (devices).
- [] holds multiple device entries.
- Each device is again an object ({}) with
its own properties.
🧠 Quick Tip to Remember
|
Symbol |
Represents |
Think of it as... |
|
{} |
Object |
A labeled folder |
|
[] |
Array |
A stack of items |
Saturday, 9 August 2025
L3Out Subnet Scope Options in Cisco ACI
L3Out Subnet Scope
Options in Cisco ACI
|
Scope Option |
Purpose |
|
Export Route
Control Subnet |
Advertises specific
transit routes out of the ACI fabric. Used for controlling which
external routes are exported. |
|
Import Route
Control Subnet |
Allows specific
external routes to be imported into the ACI fabric using BGP or OSPF. |
|
External Subnets
for External EPG (Security
Import Subnet) |
Enables data
plane traffic between external EPGs and internal EPGs. Without this,
traffic is dropped even if routes are learned. |
|
Shared Route
Control Subnet |
Used in inter-VRF
route leaking. Marks subnets that should be advertised across VRFs. |
|
Shared Security
Import Subnet |
Similar to External
Subnets, but for shared L3Outs. Enables traffic flow between shared
external and internal EPGs. |
|
Aggregate
Export/Import/Shared Routes |
Used to summarize
routes, e.g., adding /32 in front of 0.0.0.0/0 for default route
aggregation. |
🧠 Key Notes
- These scope options are critical for controlling
route advertisement and enabling secure communication between
different parts of the network.
- Cisco ACI uses a contract-based
model, so even if routes are advertised, traffic will be dropped
unless explicitly allowed by contracts and security prefixes