Cisco ACI – How to Onboard a New Leaf Switch (Step-by-Step)

 

🏗️ Cisco ACI – How to Onboard a New Leaf Switch (Step-by-Step)

---

✅ Prerequisites

Before onboarding a new leaf, make sure:

• ✔️ Cisco ACI fabric is already deployed and operational.
• ✔️ APIC(s) are reachable and healthy.
• ✔️ New leaf switch is physically installed in rack and powered off.
• ✔️ Supported transceivers and uplink cables are connected from leaf to at least one spine.
• ✔️ Switch firmware is compatible with APIC version.
• ✔️ Adequate APIC node license is available.

---

🔧 Step-by-Step Process

---

🔌 Step 1: Cable the Leaf Switch

• Connect uplinks (1 or more) from the new leaf switch to existing spine switches using supported optics.
• Ensure uplinks are connected before powering on the switch to allow ZTP (Zero Touch Provisioning) via LLDP.

---

⚡ Step 2: Power On the Leaf Switch

• Power on the leaf switch.
• It will automatically boot and try to discover the fabric via LLDP (to spine) and TEP communication through spine to APIC.

---

🔍 Step 3: Monitor Discovery in APIC

• Log in to APIC GUI
• Navigate to:
  Fabric → Inventory → Fabric Membership → Nodes Pending Registration
• Wait for the new leaf switch to appear here.
• You will see its Serial Number, Node Role = Leaf, and Status = Blank/ Not Registered

---

📝 Step 4: Register the New Leaf

• Right-click on the serial number of the discovered leaf.
• Click "Register"
• In the registration window, enter:
• 🔢 Node ID: Unique numeric ID (e.g., 103)
• 🏷️ Node Name: Friendly name (e.g., Leaf103)
• Click Register

🌀 The APIC will push the basic config. The leaf will reboot and rejoin the fabric using the new node identity.

---

⏱️ Step 5: Verify Registration

• After the leaf reboots, navigate to:
  Fabric → Inventory → Topology
• Confirm the new leaf:
• ✅ Appears with the correct Node ID and Name
• ✅ Has status "Active"
• ✅ Shows "Fully Fit" fabric membership state
• ✅ Has Green Health Score (> 90)

Cisco ACI Static EPG Configuration– Step-by-Step Deployment Guide

 Cisco ACI Static EPG Configuration for VLAN 420 – Step-by-Step Deployment Guide

 In modern data center architectures, Cisco Application Centric Infrastructure (ACI) provides a scalable, policy-driven approach to network automation. One of the core elements of ACI is the Endpoint Group (EPG)—which simplifies the segmentation and application of network policies.

This blog post walks you through a complete and practical step-by-step guide to statically configure an EPG on VLAN 420 using Cisco ACI's GUI. Whether you're onboarding a new server, integrating legacy infrastructure, or setting up a dedicated application VLAN, this guide covers everything from VLAN Pool creation to contract association.

---

💡 What You’ll Learn:

• How to properly configure access policies, domains, and interface profiles

• How to statically bind a port on a leaf switch to a specific VLAN

• How to associate EPGs with bridge domains and physical domains

• How to create and apply contracts for traffic control

This is a hands-on guide built for ACI administrators, data center engineers, and network architects who want a repeatable and validated procedure to follow. VLAN 420 is used as a sample, but the steps can be adapted to any VLAN or tenant environment.

🧭 Step-by-Step Summary

Step	Task	Navigation Path
1	Create VLAN Pool for VLAN 420	Fabric > Access Policies > Pools > VLAN
2	Create Physical Domain linked to VLAN Pool	Fabric > Access Policies > Physical and External Domains > Physical Domains
3	Create Interface Policies (Link Level, CDP, LLDP)	Fabric > Access Policies > Policies > Interface
4	Create Attachable Access Entity Profile (AAEP) and associate Domain	Fabric > Access Policies > Policies > Global > Attachable Access Entity Profiles
5	Create Leaf Access Port Policy Group with policies and AAEP	Fabric > Access Policies > Interfaces > Leaf Interfaces > Policy Groups
6	Create Leaf Interface Profile and assign interface selector	Fabric > Access Policies > Interfaces > Leaf Interfaces > Profiles
7	Create Leaf Switch Profile and assign node + interface profile	Fabric > Access Policies > Switches > Leaf Switch Profiles
8	Create Tenant, VRF, and Bridge Domain	Tenants
9	Create Application Profile and EPG	Tenants > T1 > Application Profiles
10	Deploy Static EPG on Leaf101 Ethernet1/5 with VLAN 420	Tenants > T1 > App420 > EPG-420 > Static Ports
11	Associate EPG with Physical Domain	Tenants > T1 > App420 > EPG-420 > Domains
12	Create Contract and associate with EPG	Tenants > T1 > Contracts and App420 > EPG-420 > Contracts

---

🔧 Detailed Configuration Steps

✅ Step 1 – Create VLAN Pool

• Path: Fabric > Access Policies > Pools > VLAN
• Right-click VLAN > Create VLAN Pool
• Name: VLANPool-420
• Allocation Mode: Static
• Add Encap Block:
• From: 420
• To: 420
• Allocation Type: Static
• Click OK, then Submit

---

✅ Step 2 – Create Physical Domain

• Path: Fabric > Access Policies > Physical and External Domains > Physical Domains
• Right-click Physical Domains > Create Physical Domain
• Name: physDom420
• VLAN Pool: VLANPool-420
• Click Submit

---

✅ Step 3 – Create Interface Policies

• Path: Fabric > Access Policies > Policies > Interface
• Create:
• Link Level Policy: 10G-Auto (Speed: 10G, Auto-Negotiate: Enabled)
• CDP Policy: CDP-Enabled (Admin State: Enabled)
• LLDP Policy: LLDP-Enabled (Admin State: Enabled)

---

✅ Step 4 – Create AAEP

• Path: Fabric > Access Policies > Policies > Global > Attachable Access Entity Profiles
• Right-click > Create Attachable Access Entity Profile
• Name: AAEP-420
• Under Domains, add: physDom420
• Click Update, then Next, then Finish

---

✅ Step 5 – Create Leaf Access Port Policy Group

• Path: Fabric > Access Policies > Interfaces > Leaf Interfaces > Policy Groups
• Right-click > Create Leaf Access Port
• Name: AccessPG-420
• Policies:
• Link Level: 10G-Auto
• CDP: CDP-Enabled
• LLDP: LLDP-Enabled
• AAEP: AAEP-420
• Click Submit

---

✅ Step 6 – Create Leaf Interface Profile

• Path: Fabric > Access Policies > Interfaces > Leaf Interfaces > Profiles
• Right-click > Profile > Click Create Leaf Interface Profile
• Name: Leaf101_IntProf
• Add Interface Selector:
• Selector Name: IntSel_eth1/5
• Interface: 1/5
• Policy Group: AccessPG-420
• Click OK, then Submit

---

✅ Step 7 – Create Leaf Switch Profile

• Path: Fabric > Access Policies > Switches > Leaf Switches
• Right-click >Profiles > Create Leaf Profile
• Name: Leaf101_SWProf
• Click +  on Leaf Selector
• Name - Leaf101_LS
• Select Switch: 101 under Blocks
• Click Update > Next
• Associate Interface Select Profiles: Leaf101_IntProf
• Click Finish

---

✅ Step 8 – Create Tenant, VRF, and Bridge Domain

• Path: Tenants
• Click ADD Tenant
• Name > T1
• Click Submit

8.1 – Create VRF

Path: Tenants >T1>Networking

• Right-click VRFs > Create VRF: VRF-T1
• Uncheck Create A Bridge Domain
• Click Finish

8.2 – Create BD

Path: Tenants >T1>Networking

 

• Right-click Bridge Domains > Create Bridge Domain: BD-420
• Associate with VRF: VRF-T1 and click Next
• Add Subnet: Gateway IP: 192.168.42.1/24
• Click Ok, Next and then Finish

---

✅ Step 9 – Create Application Profile and EPG

• Path: Tenants > T1 > Application Profiles
• Right-click > Create Application Profile: Name:App420 > Click Submit
• Right click App420 > Create Application EPG:
• Name: EPG-420
• Associate with: BD-420
• Click Finish

---

✅ Step 10 – Deploy Static EPG on Leaf Interface

• Path: Tenants > T1 > App420 > Application EPG> EPG-420
• Right-click > Static Ports , Click Deploy Static EPG on PC, VPC or Interface
• Node: Leaf101
• Interface: eth1/5
• Encapsulation: 420
• Mode: Access > Warning > OK
• Click Next>Finish

---

✅ Step 11 – Associate EPG with Physical Domain

• Path: Tenants > T1 > App420 > EPG-420
• Right-click Domains > Add Physical Domain Association
• Physical Domain Profile: physDom420
•  Click Submit

---

✅ Step 12 – Create Contract and Associate with EPG

🔹 12.1 – Create Filter

• Path: Tenants > T1 > Contracts
• Right-click Filters > Create Filters: Filter-TCP80
• Click + under Entries
• Node: Entry_TCP80
• EtherType: IP
• IP Protocol: tcp
• Stateful: checked
• Destination Port/Range: From/To:http
• Click Update and then Submit

🔹 12.2 – Create Contract

• Path: Tenants > T1 > Contracts
• Right-click Standard > Create Contract: Contract-420
• Click + under Subject ,Name:Subject-420
• Click + under Filters
• Name: choose T1/Filter-TCP80
• Action: Permit
• IP Protocol: tcp
• Click Update and then Submit
• Click OK, then Submit

🔹 12.3 – Associate Contract with EPG

• Path: Tenants > T1 > Application Profile>App420 >Application EPG> EPG-420 >Contracts
• Right Click on Contracts
• Click Add Provided Contracts
• Select: Contract-420
• Click Add, then Submit

Key Concepts of Application Profile in ACI

 In Cisco ACI (Application Centric Infrastructure), an Application Profile is a logical container that defines the structure of an application in terms of endpoint groups (EPGs) and their policies. It is one of the key components of Cisco ACI’s policy-driven model and is used to group together the various parts of an application that communicate with each other.

Key Concepts of Application Profile in ACI:

1. Represents an application’s communication behavior:

   • It defines how different tiers (e.g., web, app, database) interact.

   • These tiers are mapped to Endpoint Groups (EPGs).

2. Organizational Hierarchy in ACI:

   
   Tenant
   └── Application Profile
       └── EPGs
   

   • An Application Profile lives within a Tenant.

   • It contains one or more EPGs, which represent sets of endpoints (VMs, containers, physical servers) that require similar policies.

3. Policies are applied to EPGs, not to individual endpoints.

   • Contracts define how EPGs communicate (e.g., allowing web EPG to talk to app EPG).

   • The Application Profile holds this policy structure.

4. No direct configuration of networking constructs:

   • Instead of configuring VLANs, subnets, and ACLs manually, you define application intent through EPGs and contracts.

Example:

Let’s say you have a three-tier application:

• Web Tier

• App Tier

• Database Tier

In ACI:

• You create an Application Profile named MyAP.

• Inside it, you create three EPGs: Web-EPG, App-EPG, and DB-EPG.

• Then you define contracts:

• Web-EPG can talk to App-EPG on TCP port 8080.

• App-EPG can talk to DB-EPG on TCP port 3306.

 Benefits:

• Simplifies application deployment and scaling.

• Allows clear application segmentation.

• Enables consistent policy enforcement.

• Facilitates micro-segmentation and automation.

Failed to form relation to MO qoscustom-default of class qosCustomPol in context

 Error Explanation:

The error message "Failed to form relation to MO qoscustom-default of class qosCustomPol in context" occurs when there is no QoS policy named qoscustom-default present in the system.

Resolution Steps:

To clear this alarm:

Navigate to:

Tenants → User Tenants → Policies → Custom QoS

Create a new, empty policy with the name qoscustom-default

 

Comparison of Leaf Interfaces vs Spine Interfaces in Cisco ACI

In Cisco ACI, under Fabric > Access Policies > Interfaces, administrators configure how switches connect to endpoints and each other. This section is divided into Leaf Interfaces and Spine Interfaces, each serving distinct roles in the ACI fabric. Understanding the differences between these interface types is crucial for proper policy application and network design.

Leaf Interfaces

Leaf Interfaces are used to connect endpoints such as servers, firewalls, routers, and external switches to the ACI fabric. They support various interface types including Ethernet, Port-Channels, and Virtual Port Channels (vPCs). Policies such as CDP, LLDP, Port Channel, and Storm Control are applied to these interfaces through Interface Policy Groups.

Spine Interfaces

Spine Interfaces are primarily used to connect leaf switches and occasionally external routers for advanced routing scenarios. These interfaces typically use high-speed Ethernet connections and are configured with spine-specific interface policies. Unlike leaf interfaces, spine interfaces do not connect directly to endpoints.

Summary Comparison Table

Feature	Leaf Interfaces	Spine Interfaces
Connects To	Endpoints (servers, routers, firewalls)	Leaf switches, external routers
Policy Types	Access Port, Port Channel, vPC Policy Groups	Spine Interface Policy Groups
Use Case	Endpoint connectivity	Fabric backbone and routing infrastructure
Interface Types	Ethernet, Port-Channel, vPC	High-speed Ethernet

Understanding Domain Types in Cisco ACI - External Bridge domains vs Fibre Channel Domains Vs L3 Domains Vs Physical Domains

 

Understanding Domain Types in Cisco ACI

Cisco ACI (Application Centric Infrastructure) provides a flexible and scalable network architecture. One of the key components in ACI is the concept of domains, which define how endpoints and external networks interact with the fabric. In this blog, we will explore four important domain types in Cisco ACI: External Bridge Domains, Fibre Channel Domains, L3 Domains, and Physical Domains. Understanding their roles and use cases is essential for designing robust ACI environments.

1. External Bridge Domains - Not Recommended

External Bridge Domains are used to extend Layer 2 connectivity beyond the ACI fabric. They are typically associated with L2Out configurations and allow external devices to participate in the same broadcast domain as internal ACI endpoints. This is useful for integrating legacy Layer 2 networks or extending VLANs to external switches.

2. Fibre Channel Domains

Fibre Channel (FC) Domains are designed for integrating ACI with storage area networks (SANs). These domains support Fibre Channel over Ethernet (FCoE) or native Fibre Channel protocols. They enable zoning and connectivity to storage arrays and are essential for environments that require high-performance storage access through Cisco MDS switches or similar infrastructure.

3. L3 Domains

L3 Domains are used for establishing Layer 3 routed connectivity to external networks. They are associated with L3Out configurations and support dynamic routing protocols such as OSPF and BGP, as well as static routes. L3 Domains are crucial for connecting the ACI fabric to the internet, WANs, or other routed domains.

4. Physical Domains

Physical Domains are used to connect bare-metal servers and non-virtualized devices to the ACI fabric. They are associated with AAEPs (Attachable Access Entity Profiles) and interface policies. Physical Domains typically use static VLAN pools and are ideal for environments where VLANs are manually assigned to interfaces for direct server or appliance connectivity.

Summary Comparison Table

Domain Type	Purpose	Associated With	Typical Use Case
External Bridge Domain	Extend Layer 2 outside ACI	L2Out	Legacy VLAN bridging, external switches
Fibre Channel Domain	SAN connectivity	FCoE, FC zoning	Storage integration (e.g., MDS, SAN arrays)
L3 Domain	Routed external connectivity	L3Out	Internet, WAN, external routing
Physical Domain	Connect physical devices to ACI	AAEP, Interface Profiles	Bare-metal servers, appliances

 

 

Understanding VLAN Pool Roles in Cisco ACI: Internal vs External or On-the-Wire

In Cisco ACI, VLAN pools are used to define ranges of VLAN IDs that can be assigned to endpoints. Each VLAN range must be assigned a role, which determines how the VLANs are used within the fabric. There are two primary roles: 'Internal' and 'External or On-the-Wire'. This blog post explains the differences between these roles, their behaviors, and typical use cases.

1. Internal VLAN Pool Role

The 'Internal' role is used for VLANs that are strictly for intra-fabric communication. These VLANs are not exposed outside the ACI fabric and are used for internal encapsulation and mapping EPGs to VXLAN VNIDs.

Use Cases:

·       EPG-to-EPG communication within the fabric

·       Service chaining ( Service Graphs etc.) or internal-only applications

·       solated tenants or test environments

2. External or On-the-Wire VLAN Pool Role

The 'External or On-the-Wire' role is used for VLANs that are visible outside the ACI fabric. These VLANs are preserved on the wire and are used for external connectivity such as L2Out, L3Out, bare-metal servers, and VMM domains.

Use Cases:

·       Integration with legacy VLAN-based networks

·       VMM integration where VLANs must match hypervisor configurations

·       Bare-metal servers requiring specific VLANs

Summary Comparison

Role	Visibility	VLAN ID Preservation	Typical Use Case
Internal	Fabric-only	No	Internal EPGs, service chaining, isolated tenants
External or On-the-Wire	Exposed on physical wire	Yes	L2/L3Out, VMM, bare-metal, legacy integration