Cisco ACI คืออะไร? สอน Application Centric Infrastructure สำหรับ Data Center 2026

Cisco ACI คืออะไร?

Cisco ACI (Application Centric Infrastructure) คือโซลูชัน Software-Defined Networking (SDN) สำหรับ Data Center ที่พัฒนาโดย Cisco โดยเปลี่ยนแนวคิดการจัดการ Network จากแบบ Device-centric (ตั้งค่า Switch ทีละตัว) มาเป็น Application-centric (กำหนด Policy ตาม Application แล้ว ACI จะตั้งค่า Network ให้อัตโนมัติ) ACI เปิดตัวครั้งแรกในปี 2013 และในปี 2026 ได้พัฒนาเป็นเวอร์ชัน 6.x ที่รองรับ Multi-site, Multi-cloud, Kubernetes integration และ AI-driven automation

ACI ถูกออกแบบมาเพื่อแก้ปัญหาของ Traditional Data Center Networking ที่มี Complexity สูง การเปลี่ยนแปลง Network ต้องใช้เวลานาน (weeks ถึง months), Error-prone จากการตั้งค่ามือ, Inconsistent policies ระหว่าง Switch ต่างตัว, ไม่มี Visibility ว่า Application ใช้ Network อย่างไร และ Troubleshooting ยาก เพราะต้องตรวจสอบทุก Device

ACI Architecture — Spine-Leaf Topology

ACI ใช้ Spine-Leaf topology ซึ่งเป็นมาตรฐานสำหรับ Modern Data Center แทน Traditional 3-tier (Core, Distribution, Access) ทุก Leaf switch เชื่อมต่อกับทุก Spine switch ทำให้ Traffic ข้ามระหว่าง Server ใดๆ ผ่านแค่ 2 hops (Leaf → Spine → Leaf) ได้ Latency ที่ต่ำและคาดเดาได้

Spine Switches: เป็น Backbone ของ Fabric ทำหน้าที่ Forward traffic ระหว่าง Leaf switches ไม่มี Server/Endpoint เชื่อมต่อโดยตรง ใช้ Cisco Nexus 9500 series (Fixed หรือ Modular)

Leaf Switches: เป็นจุดเชื่อมต่อกับ Server, Storage, Firewall, Load Balancer และ External network (WAN/Internet) ทุก Endpoint ต้องเชื่อมต่อผ่าน Leaf เสมอ ใช้ Cisco Nexus 9300 series

APIC (Application Policy Infrastructure Controller): คือ Brain ของ ACI Fabric เป็น Centralized management point ที่ทำหน้าที่ Policy management (สร้าง, แก้ไข, ลบ Policy), Fabric provisioning (ตั้งค่า Switches อัตโนมัติ), Health monitoring (ดูสถานะ Fabric ทั้งหมด), Troubleshooting (Visibility ลึกถึง Packet level) และ API gateway (REST API สำหรับ Automation) APIC ทำงานเป็น Cluster (แนะนำ 3 APIC) เพื่อ High Availability ถ้า APIC ทั้งหมดล่ม Fabric ยังทำงานได้ (ข้อมูล Policy ถูก Push ไปที่ Switch แล้ว) แต่จะไม่สามารถเปลี่ยน Policy ได้

ACI Object Model — แนวคิดหลัก

ACI ใช้ Object Model ที่เป็นลำดับชั้น (Hierarchical) ทุกอย่างถูกกำหนดเป็น Managed Objects (MO) ที่มีความสัมพันธ์กัน:

Tenant

Tenant คือ Logical container ระดับสูงสุดสำหรับแบ่งแยก Policy ขององค์กร แผนก หรือ Application ได้ เปรียบเหมือน Virtual Data Center แต่ละ Tenant มี Network, Security policy, L4-L7 services ของตัวเอง ไม่เห็นข้อมูลของ Tenant อื่น ตัวอย่าง: Tenant-Production, Tenant-Dev, Tenant-CustomerA

VRF (Virtual Routing and Forwarding)

VRF คือ Routing domain ภายใน Tenant หนึ่ง Tenant มีได้หลาย VRF แต่ละ VRF มี Routing table แยกกัน ทำให้ใช้ IP ซ้ำกันได้ (IP overlap) เปรียบเหมือน Virtual Router

BD (Bridge Domain)

Bridge Domain คือ L2 broadcast domain เปรียบเหมือน VLAN แต่ยืดหยุ่นกว่ามาก BD สัมพันธ์กับ VRF (1 BD → 1 VRF) มี Subnet gateway อยู่ใน BD สามารถกำหนด Options ต่างๆ เช่น ARP flooding, Unicast routing, L2 unknown unicast

EPG (End Point Group)

EPG คือแนวคิดที่สำคัญที่สุดใน ACI ทำหน้าที่จัดกลุ่ม Endpoints (VMs, Containers, Physical servers, IP devices) ที่มี Policy เหมือนกันเข้าด้วยกัน EPG ไม่ได้จำกัดอยู่แค่ VLAN หรือ Subnet เดียว สามารถมี Endpoints จากหลาย VLAN, หลาย Subnet, หลาย Leaf switch ได้

ตัวอย่างการจัดกลุ่ม: EPG-WebServers (รวม Web server ทั้งหมด ไม่ว่าจะอยู่ที่ Leaf ตัวไหน), EPG-AppServers (รวม Application server), EPG-DBServers (รวม Database server), EPG-Monitoring (รวม Monitoring tools)

Contract

Contract คือกฎที่กำหนดว่า EPG ไหนสามารถสื่อสารกับ EPG ไหนได้ และด้วย Protocol/Port อะไร ถ้าไม่มี Contract Endpoint ต่าง EPG จะไม่สามารถสื่อสารกันได้เลย (Whitelist model — default deny) Contract ประกอบด้วย Subject (กลุ่มของ Filters) และ Filter (กำหนด Protocol, Port, Direction)

# ตัวอย่าง Contract: Web → App (HTTP/HTTPS)
Tenant: Production
  Contract: Web-to-App
    Subject: HTTP-Traffic
      Filter: HTTP
        Entry: tcp dst port 80 (permit)
        Entry: tcp dst port 443 (permit)

  EPG-WebServers → Consumer of Contract "Web-to-App"
  EPG-AppServers → Provider of Contract "Web-to-App"

# ผลลัพธ์: Web servers สามารถเข้าถึง App servers ที่ port 80, 443 ได้
# App servers ไม่สามารถ initiate connection ไปหา Web servers ได้

ACI Fabric Initialization

การตั้งค่า ACI Fabric ครั้งแรก มีขั้นตอนหลักดังนี้:

ขั้นตอนที่ 1: Physical Setup — ติดตั้ง APIC (3 เครื่อง), Spine switches, Leaf switches, เชื่อมสาย Spine-Leaf (ทุก Leaf → ทุก Spine), เชื่อมสาย APIC → Leaf (คนละ Leaf)

ขั้นตอนที่ 2: APIC Bootstrap — เข้า Console ของ APIC ตัวแรก กำหนด Fabric name, Controller ID (1), TEP pool (10.0.0.0/16 default), Infrastructure VLAN (default 4093), OOB management IP

ขั้นตอนที่ 3: Fabric Discovery — APIC จะ Discover Spine และ Leaf switches อัตโนมัติผ่าน LLDP เข้า APIC GUI (https://apic-ip) ไปที่ Fabric > Inventory > Fabric Membership จะเห็น Switches ที่ Unregistered อนุมัติ (Register) แต่ละ Switch กำหนด Node ID และ Name

ขั้นตอนที่ 4: Configure Access Policies — กำหนด Interface policies (Speed, LLDP, CDP), VLAN pools, Physical/VMM domains, AEP (Attachable Entity Profile), Interface profiles

APIC GUI Walkthrough

APIC GUI มี Tabs หลักดังนี้:

System: ดูสถานะ APIC cluster, Firmware management, Configuration export/import, Schedulers

Tenants: จัดการ Tenants, VRFs, BDs, EPGs, Contracts ทั้งหมด นี่คือ Tab ที่ใช้บ่อยที่สุด

Fabric: จัดการ Access policies (VLAN, Interface profiles), Inventory (Switch status), Policies (BGP, DNS, NTP, SNMP)

Virtual Networking: จัดการ VMM Domains (VMware vCenter, Microsoft SCVMM, Kubernetes) ที่ Integrate กับ ACI

L4-L7 Services: กำหนด Service Graphs สำหรับ Firewall, Load Balancer insertion

Operations: ดู Health score, Faults, Events, Audit logs, EP tracker

Apps: ติดตั้ง Apps เพิ่มเติมจาก Cisco ACI App Center

Micro-segmentation ด้วย EPG

Micro-segmentation คือการแบ่ง Security zone ให้เล็กลงถึงระดับ Application หรือ Workload แทนที่จะแบ่งแค่ระดับ VLAN/Subnet ACI ทำ Micro-segmentation ได้ง่ายด้วย EPG:

# Traditional: VLAN-based segmentation
VLAN 10 → All Web servers → 1 Firewall rule set
VLAN 20 → All App servers → 1 Firewall rule set
# ปัญหา: Server ใน VLAN เดียวกันสื่อสารกันได้หมด (East-West traffic ไม่ถูก filter)

# ACI: EPG-based micro-segmentation
Tenant: Production
  EPG-WebFrontend → Web UI servers
  EPG-APIGateway → API Gateway servers
  EPG-OrderService → Order microservice
  EPG-PaymentService → Payment microservice
  EPG-Database → Database servers

  Contracts:
    WebFrontend → APIGateway (HTTPS 443)
    APIGateway → OrderService (gRPC 50051)
    APIGateway → PaymentService (gRPC 50052)
    OrderService → Database (MySQL 3306)
    PaymentService → Database (MySQL 3306)
    # WebFrontend ไม่สามารถเข้าถึง Database ได้โดยตรง!
    # OrderService ไม่สามารถเข้าถึง PaymentService ได้!

USG (uSeg / Microsegment EPG) เป็นฟีเจอร์ที่ทำให้ จัดกลุ่ม Endpoint ตาม Attribute ได้ เช่น IP address, MAC address, VM name, OS type โดยไม่ต้องพึ่ง VLAN ทำให้ Micro-segmentation ละเอียดขึ้นไปอีก

Service Graphs — Firewall & Load Balancer Insertion

Service Graph คือวิธีที่ ACI ใช้แทรก L4-L7 Services (Firewall, Load Balancer, WAF, IPS) เข้าไปใน Traffic path โดยไม่ต้องเปลี่ยน Network topology ACI จะ Redirect traffic ไปผ่าน Service device อัตโนมัติ

# Service Graph: Web → Firewall → Load Balancer → App
# ขั้นตอน:
# 1. Register L4-L7 Device (Firewall, LB) ใน ACI
# 2. สร้าง Service Graph Template
# 3. กำหนด Function (Firewall = GoTo, LB = GoTo)
# 4. Apply Service Graph กับ Contract ระหว่าง EPG
# 5. ACI จะ:
#    - สร้าง Shadow EPGs สำหรับ Service device
#    - Redirect traffic: EPG-Web → Firewall → LB → EPG-App
#    - ตั้งค่า VLAN, IP, Routes ให้อัตโนมัติ

Supported Devices:
- Firewall: Palo Alto, Cisco ASA/FTD, Fortinet, Check Point
- Load Balancer: F5 BIG-IP, Citrix ADC, AVI Networks
- WAF: Imperva, F5 ASM
- IPS/IDS: Cisco Firepower, Palo Alto Threat Prevention

ACI Multi-Site

ACI Multi-Site ใช้ Cisco Nexus Dashboard (เดิมชื่อ Multi-Site Orchestrator / MSO) เพื่อจัดการ ACI Fabrics หลายแห่งจากที่เดียว เหมาะสำหรับองค์กรที่มี Data Center หลาย Location:

Multi-Site: เชื่อม ACI Fabrics ที่อยู่คนละ Data Center (เช่น Bangkok DC + Singapore DC) แต่ละ Site มี APIC cluster ของตัวเอง Nexus Dashboard จัดการ Policy consistency ระหว่าง Sites รองรับ Stretched Tenant, Stretched EPG (Endpoint อยู่คนละ Site แต่ใน EPG เดียวกัน)

ACI Anywhere: ขยาย ACI Policy ไปยัง Remote sites (Mini ACI, Virtual ACI), Cloud (AWS, Azure ด้วย Cloud APIC), และ Edge locations ทำให้มี Consistent policy ตั้งแต่ Data Center ไปจนถึง Cloud

ACI + VMware Integration

ACI integrate กับ VMware vCenter/vSphere ผ่าน VMM Domain (Virtual Machine Manager Domain) ทำให้:

ACI สร้าง Port Group บน vDS (vSphere Distributed Switch) อัตโนมัติเมื่อสร้าง EPG, VM ที่ย้ายด้วย vMotion จะยังคง Policy เดิม (Policy follows VM), vCenter Admin เห็น EPG เป็น Port Group ปกติ ไม่ต้องเรียนรู้ ACI, ACI เห็น VM ทุกตัวใน vCenter (Endpoint Tracker), Microsegmentation ทำได้ถึงระดับ VM

# ขั้นตอน Integration:
# 1. สร้าง VMM Domain ใน ACI (Tenants > Networking > VMM Domains)
# 2. กำหนด vCenter credentials (IP, Username, Password)
# 3. กำหนด VLAN Pool สำหรับ DVS
# 4. ACI จะสร้าง DVS บน vCenter อัตโนมัติ
# 5. สร้าง EPG แล้ว Associate กับ VMM Domain
# 6. ACI สร้าง Port Group ชื่อ Tenant|AP|EPG บน DVS
# 7. vCenter Admin assign VM ไปที่ Port Group นั้น

ACI + Kubernetes

Cisco ACI CNI Plugin (Container Networking Interface) ทำให้ Kubernetes Pods ใช้ ACI Policy ได้เหมือน VM หรือ Physical server:

Kubernetes Pods ถูก Map เข้า EPG ใน ACI, Contract ระหว่าง EPG ใช้กับ Pod traffic ได้, Network Policy ของ Kubernetes ถูก Translate เป็น ACI Contract, Pod-to-VM, Pod-to-Physical traffic ใช้ Policy เดียวกัน, ทำ Microsegmentation ถึงระดับ Pod/Namespace

# ACI CNI Plugin Architecture:
# - acc-provision: สร้าง ACI objects สำหรับ K8s cluster
# - aci-containers-controller: Sync K8s resources → ACI
# - aci-containers-host-agent: Manage OVS bridge on nodes
# - opflex-agent: Push Policy จาก ACI ไปที่ Node

# ติดตั้ง:
# 1. สร้าง ACI objects (Tenant, VRF, BD, EPG) สำหรับ K8s
acc-provision -a -c acc-provision-config.yaml -f k8s-flavor -u admin -p password

# 2. Deploy ACI CNI บน Kubernetes cluster
kubectl apply -f aci-containers.yaml

# 3. Kubernetes Namespace → EPG mapping
# Namespace "production" → EPG "kube-production"
# Namespace "staging" → EPG "kube-staging"

ACI vs NSX — เปรียบเทียบ

ACI Automation — Ansible, Terraform, Python

Ansible

# playbook: create_tenant.yml
- name: Create ACI Tenant
  hosts: apic
  connection: local
  gather_facts: no
  collections:
    - cisco.aci

  tasks:
    - name: Create Tenant
      aci_tenant:
        host: "{{ apic_host }}"
        username: "{{ apic_user }}"
        password: "{{ apic_pass }}"
        validate_certs: no
        tenant: Production
        description: "Production Tenant"
        state: present

    - name: Create VRF
      aci_vrf:
        host: "{{ apic_host }}"
        username: "{{ apic_user }}"
        password: "{{ apic_pass }}"
        validate_certs: no
        tenant: Production
        vrf: Prod-VRF
        state: present

    - name: Create Bridge Domain
      aci_bd:
        host: "{{ apic_host }}"
        username: "{{ apic_user }}"
        password: "{{ apic_pass }}"
        validate_certs: no
        tenant: Production
        bd: Web-BD
        vrf: Prod-VRF
        state: present

    - name: Create EPG
      aci_epg:
        host: "{{ apic_host }}"
        username: "{{ apic_user }}"
        password: "{{ apic_pass }}"
        validate_certs: no
        tenant: Production
        ap: Production-AP
        epg: Web-EPG
        bd: Web-BD
        state: present

Terraform

# main.tf
terraform {
  required_providers {
    aci = {
      source = "CiscoDevNet/aci"
      version = "~> 2.0"
    }
  }
}

provider "aci" {
  username = var.apic_user
  password = var.apic_pass
  url      = var.apic_url
  insecure = true
}

resource "aci_tenant" "production" {
  name        = "Production"
  description = "Production Tenant managed by Terraform"
}

resource "aci_vrf" "prod_vrf" {
  tenant_dn   = aci_tenant.production.id
  name        = "Prod-VRF"
}

resource "aci_bridge_domain" "web_bd" {
  tenant_dn          = aci_tenant.production.id
  name               = "Web-BD"
  relation_fv_rs_ctx = aci_vrf.prod_vrf.id
}

resource "aci_application_profile" "prod_ap" {
  tenant_dn = aci_tenant.production.id
  name      = "Production-AP"
}

resource "aci_application_epg" "web_epg" {
  application_profile_dn = aci_application_profile.prod_ap.id
  name                   = "Web-EPG"
  relation_fv_rs_bd      = aci_bridge_domain.web_bd.id
}

Python (Cobra SDK / REST API)

# Python REST API Example
import requests
import json

APIC_URL = "https://apic.example.com"
USERNAME = "admin"
PASSWORD = "password"

# Login
login_url = f"{APIC_URL}/api/aaaLogin.json"
login_data = {"aaaUser": {"attributes": {"name": USERNAME, "pwd": PASSWORD}}}
session = requests.Session()
resp = session.post(login_url, json=login_data, verify=False)
token = resp.json()["imdata"][0]["aaaLogin"]["attributes"]["token"]
session.headers.update({"Cookie": f"APIC-cookie={token}"})

# Create Tenant
tenant_url = f"{APIC_URL}/api/mo/uni.json"
tenant_data = {
    "fvTenant": {
        "attributes": {"name": "PythonTenant", "descr": "Created by Python"},
        "children": [
            {"fvCtx": {"attributes": {"name": "Python-VRF"}}},
            {"fvBD": {
                "attributes": {"name": "Python-BD"},
                "children": [
                    {"fvRsCtx": {"attributes": {"tnFvCtxName": "Python-VRF"}}},
                    {"fvSubnet": {"attributes": {"ip": "10.10.10.1/24", "scope": "public"}}}
                ]
            }}
        ]
    }
}
resp = session.post(tenant_url, json=tenant_data, verify=False)
print(f"Create Tenant: {resp.status_code}")

ACI Troubleshooting

ACI มีเครื่องมือ Troubleshooting ที่ทรงพลังหลายตัว:

Health Score: ทุก Object ใน ACI มี Health Score (0-100) ที่คำนวณจาก Faults ทั้งหมดที่เกี่ยวข้อง ช่วยระบุปัญหาได้เร็ว ดูได้ที่ Dashboard หรือ Tenant/EPG level

Endpoint Tracker: ติดตาม Endpoint ทุกตัวใน Fabric ว่าอยู่ที่ Leaf/Port/VLAN/EPG ไหน ย้ายไปที่ไหน เมื่อไหร่ เข้าถึงได้ที่ Operations > EP Tracker

Atomic Counters: นับ Packets ระหว่าง EPG คู่ใดๆ แสดง Source EPG, Destination EPG, Packet count, Byte count, Drop count ช่วยวิเคราะห์ว่า Traffic ถูก Drop ที่ไหน

SPAN/ERSPAN: Mirror traffic จาก Port/EPG ไปยัง Packet analyzer (Wireshark) เพื่อ Deep packet inspection

Troubleshooting Wizard: APIC GUI มี Troubleshooting wizard ที่ช่วย Trace path ระหว่าง 2 endpoints แสดงว่า Traffic ผ่าน Switch/Port/Policy อะไรบ้าง ช่วยระบุ Configuration error ได้

ACI Certifications

Cisco มี Certifications ที่เกี่ยวข้องกับ ACI:

แนวทางเรียน ACI: เริ่มจาก Cisco ACI Simulator (ACISIM) บน VMware หรือ Cisco dCloud (free lab) ศึกษา ACI Object Model ให้เข้าใจ (Tenant, VRF, BD, EPG, Contract) ฝึก Lab ตั้งค่าจริงบน Simulator ศึกษา Automation ด้วย Ansible/Python สอบ 300-620 DCACI สำหรับ CCNP Data Center

สรุป

Cisco ACI เปลี่ยนแนวคิดการจัดการ Data Center Network จาก Device-centric มาเป็น Application-centric ด้วย Spine-Leaf architecture ที่ให้ Performance สูง, EPG-based microsegmentation ที่ Security ดี, Service Graph ที่แทรก Firewall/LB ได้ง่าย, Multi-site/Multi-cloud ที่ขยายได้ทั่วโลก และ Automation ด้วย Ansible/Terraform/Python ที่จัดการ Network เป็น Code ได้

ACI เหมาะกับองค์กรที่มี Data Center ขนาดกลางถึงใหญ่ ต้องการ Centralized management, Strong microsegmentation, และ Automation capabilities แม้ต้นทุนจะสูง (Nexus 9000 hardware + ACI license) แต่สำหรับองค์กรที่ใช้ Cisco เป็นหลัก ACI ให้ ROI ที่ดีจากการลดเวลา Provisioning, ลด Human error, และเพิ่ม Security visibility อย่างมาก