Cấu Hình Mẫu Cisco ACI Chi Tiết Cho 2 Mô Hình Doanh Nghiệp

Đây là bài viết chuyên sâu, thực hành trực tiếp trên nền tảng kiến thức đã trình bày ở bài viết tổng quan Cisco ACI Là Gì? Giải Pháp SDN Cho Trung Tâm Dữ Liệu Hiện Đại. Nếu bạn chưa nắm rõ khái niệm Tenant, VRF, Bridge Domain, EPG, Contract hay các thành phần APIC/Nexus 9000/Nexus Dashboard, nên đọc qua bài viết đó trước để dễ theo dõi nội dung dưới đây.

Bài viết này trình bày 2 kịch bản cấu hình mẫu thực tế, đầy đủ từ danh sách thiết bị cần mua, sơ đồ đấu nối vật lý, các bước cấu hình trên APIC, cho tới mã lệnh CLI/REST API — áp dụng cho một doanh nghiệp quy mô vừa và một tập đoàn đa chi nhánh, đa trung tâm dữ liệu. Đây là cấu trúc tham khảo mang tính minh họa, dựa theo đúng cú pháp trong các hướng dẫn chính thức của Cisco; khi triển khai thực tế cần khảo sát và tư vấn kỹ thuật chi tiết theo hạ tầng hiện có.

1. Công Ty A – Doanh Nghiệp Quy Mô Vừa (Mô Hình Single-Pod)

Bối cảnh: 1 trung tâm dữ liệu duy nhất, hệ thống ứng dụng 3 lớp (Web – App – Database), cần bảo mật vi phân đoạn giữa các lớp ứng dụng.

Hạ tầng vật lý đề xuất: 2 switch spine, 4 switch leaf Nexus 9000, cụm APIC gồm 3 controller.

a) Danh sách thiết bị cần mua (Bill of Materials):

b) Sơ đồ đấu nối vật lý:

1. Mỗi leaf phải đấu tới toàn bộ spine trong fabric (full-mesh 2 spine × 4 leaf = 8 đường uplink); spine không đấu với spine, leaf không đấu trực tiếp với leaf — đây là yêu cầu bắt buộc của Cisco để đảm bảo chuyển tiếp tối ưu giữa các endpoint.
2. Mỗi APIC được đấu vào 2 leaf khác nhau (mỗi APIC dùng 2 cổng dữ liệu) để đảm bảo dự phòng — APIC không nằm trên đường truyền dữ liệu (data path), chỉ đóng vai trò điều khiển/quản lý nên APIC "chết" không làm gián đoạn chuyển mạch.
3. Cổng mgmt0 của mọi APIC, leaf, spine được đấu vào switch quản lý ngoài băng (OOB) riêng biệt, tách khỏi mạng dữ liệu — dùng để truy cập GUI/CLI, NTP, DNS trước khi fabric hoạt động.
4. Server/VM host đấu vào cổng downlink của leaf (có thể đấu đơn hoặc đấu kép dạng vPC vào 2 leaf để dự phòng).

c) Toàn bộ cấu hình thực hiện ở đâu? APIC hay switch?

Đây là điểm khác biệt quan trọng nhất của Cisco ACI so với mạng truyền thống, cần hiểu rõ trước khi xem các bước bên dưới:

• Quản trị viên chỉ đăng nhập và thao tác trên APIC (chọn bất kỳ 1 trong 3 node, qua GUI/CLI/API) — không bao giờ đăng nhập trực tiếp vào leaf hay spine để gõ lệnh cấu hình. Vì 3 APIC dùng chung một cơ sở dữ liệu phân tán, thay đổi thực hiện trên APIC nào cũng tự động đồng bộ sang 2 APIC còn lại.
• Switch không cần cấu hình thủ công cho tenant/VRF/EPG/contract. APIC tự tính toán "cấu hình cụ thể" từ chính sách logic bạn khai báo, rồi chỉ đẩy xuống đúng những leaf có server liên quan — ví dụ EPG-WEB chỉ xuất hiện trên Leaf 101/102 (nơi server Web thực sự cắm vào), các leaf khác không hề nhận cấu hình này. Đây chính là bản chất "lấy ứng dụng làm trung tâm" của ACI.
• Switch chỉ liên quan tới 2 việc mang tính hạ tầng nền — và cả 2 việc này vẫn thực hiện trên APIC, không phải gõ lệnh trực tiếp trên switch: (1) được APIC tự động phát hiện và đăng ký vào fabric qua LLDP, quản trị viên chỉ xác nhận Node ID trên GUI; (2) được APIC đẩy Access Policies xuống để "mở đường" đúng cổng vật lý.
• Về mặt kỹ thuật, bạn vẫn có thể SSH trực tiếp vào leaf/spine để chạy lệnh show tra cứu/debug, nhưng nếu cố tình gõ lệnh cấu hình thủ công trực tiếp trên switch, APIC sẽ coi đó là "cấu hình trôi dạt" (config drift) và tự động ghi đè lại theo đúng trạng thái đã khai báo trên APIC ở lần đồng bộ tiếp theo — switch luôn phải tuân theo APIC.

d) Các bước khởi tạo và cấu hình chi tiết:

1. Trên APIC thứ nhất: cắm cáp console, chạy script thiết lập lần đầu (initial setup script) — khai báo Fabric Name, Fabric ID, số lượng APIC trong cụm (3), Pod ID, APIC ID, dải địa chỉ TEP Pool nội bộ (ví dụ 10.0.0.0/16 — đây là dải IP hạ tầng riêng, không trùng với mạng người dùng), VLAN hạ tầng (Infra VLAN), địa chỉ IP/gateway cho cổng OOB, và mật khẩu quản trị.
2. Cơ chế tự phát hiện fabric (cascading discovery): APIC chỉ phát hiện leaf mà nó cắm trực tiếp qua giao thức LLDP; sau khi leaf đó đăng ký vào fabric, APIC tiếp tục phát hiện các spine đấu với leaf này, rồi từ spine lại phát hiện các leaf còn lại — cứ thế lan tỏa cho tới khi toàn bộ fabric được nhận diện mà không cần cấu hình thủ công từng switch.
3. Trên GUI APIC, vào mục Fabric > Inventory > Fabric Membership để xác nhận Node ID và đặt tên cho từng switch vừa được phát hiện (Spine1, Spine2, Leaf101-104).
4. Lặp lại bước 1 cho APIC thứ 2 và thứ 3 (cùng Fabric Name/ID nhưng khác APIC ID) để 3 APIC hợp thành một cụm (cluster) có tính sẵn sàng cao.
5. Cấu hình NTP và DNS trong "First Time Setup Wizard" (hoặc Fabric > Fabric Policies) để đồng bộ thời gian và tên miền cho toàn bộ node — bắt buộc vì hệ thống dùng chứng chỉ số (certificate) giữa các thành phần.
6. Cấu hình Access Policies để "mở đường" cho EPG xuống đúng cổng vật lý: tạo VLAN Pool (dải VLAN được cấp phát), Physical Domain, Attachable Entity Profile (AEP), Interface Policy Group, Interface Profile và Switch Profile — sau đó gán AEP này vào EPG. Đây là bước bắt buộc để một EPG (ví dụ EPG-WEB) thực sự được đẩy xuống cổng cắm server tương ứng trên leaf.
7. Sau khi fabric sẵn sàng, tiến hành tạo cấu trúc logic (tenant, VRF, bridge domain, application profile, EPG, contract) như trình bày ở phần dưới — toàn bộ cấu hình logic này được APIC tự động đẩy xuống mọi leaf liên quan, quản trị viên không cần đăng nhập vào từng switch.

e) Cấu trúc đối tượng logic mẫu (nội dung sẽ khai báo trên APIC ở bước 7):

1. Tenant: CONGTYA_PROD
2. VRF: VRF-CONGTYA-PROD
3. Bridge Domain: BD-WEBAPP (subnet 10.10.10.0/24), BD-DATABASE (subnet 10.10.20.0/24)
4. Application Profile: AP-ERP-NOIBO
5. EPG:
   • EPG-WEB (VLAN 100, gắn vào BD-WEBAPP)
   • EPG-APP (VLAN 101, gắn vào BD-WEBAPP)
   • EPG-DB (VLAN 102, gắn vào BD-DATABASE)
6. Contract:
   • CT-WEB-TO-APP: cho phép EPG-WEB gọi EPG-APP qua cổng TCP 8080/8443
   • CT-APP-TO-DB: cho phép EPG-APP gọi EPG-DB qua cổng TCP 1433 (SQL) hoặc 3306 (MySQL)
   • Không cấp Contract giữa EPG-WEB và EPG-DB → mặc định bị chặn theo mô hình zero-trust

Cấu hình mẫu theo cú pháp NX-OS Style CLI của APIC (cấu trúc lệnh tham chiếu theo Cisco APIC NX-OS Style CLI Configuration Guide – Use Case: Three-Tier Application, áp dụng cho mô hình web/app/db 3 lớp, chỉ đổi tên đối tượng theo Công ty A):

apic1# configure
apic1(config)# tenant CONGTYA_PROD
apic1(config-tenant)# vrf context VRF-CONGTYA-PROD
apic1(config-tenant-vrf)# contract enforce
apic1(config-tenant)# bridge-domain BD-WEBAPP
apic1(config-tenant-bd)# vrf member VRF-CONGTYA-PROD

apic1(config-tenant)# application AP-ERP-NOIBO
apic1(config-tenant-app)# epg EPG-WEB
apic1(config-tenant-app-epg)# bridge-domain member BD-WEBAPP
apic1(config-tenant-app-epg)# contract provider CT-WEB
apic1(config-tenant-app-epg)# contract consumer CT-APP
apic1(config-tenant-app)# epg EPG-APP
apic1(config-tenant-app-epg)# bridge-domain member BD-WEBAPP
apic1(config-tenant-app-epg)# contract provider CT-APP
apic1(config-tenant-app-epg)# contract consumer CT-DB
apic1(config-tenant-app)# epg EPG-DB
apic1(config-tenant-app-epg)# bridge-domain member BD-WEBAPP
apic1(config-tenant-app-epg)# contract provider CT-DB

apic1(config-tenant)# access-list ACL-HTTP
apic1(config-tenant-acl)# match tcp dest 8080
apic1(config-tenant-acl)# match tcp dest 8443

apic1(config-tenant)# access-list ACL-SQL
apic1(config-tenant-acl)# match tcp dest 1433

apic1(config-tenant)# contract CT-APP
apic1(config-tenant-contract)# subject SUBJ-APP
apic1(config-tenant-contract-subj)# access-group ACL-HTTP both

apic1(config-tenant)# contract CT-DB
apic1(config-tenant-contract)# subject SUBJ-DB
apic1(config-tenant-contract-subj)# access-group ACL-SQL both

Nguồn tham khảo cú pháp: Cisco APIC NX-OS Style Command-Line Interface Configuration Guide — mục "Use Case: Three-Tier Application with Transit Topology" (xem mục 4.1 trong danh sách tài liệu tham khảo). Đây là ví dụ chính thức của Cisco minh họa cách deploy một ứng dụng 3 lớp (web/app/db) bằng contract theo mô hình provider/consumer; bài viết chỉ đổi tên tenant, EPG, contract cho phù hợp với Công ty A. Do EPG-DB gắn cùng Bridge Domain BD-WEBAPP theo đúng ví dụ gốc của Cisco, khi triển khai thực tế bạn có thể tách riêng Bridge Domain cho lớp Database nếu cần cách ly Layer 2 rộng hơn.

Kết quả đạt được: hệ thống ERP nội bộ được cô lập theo từng lớp, giảm rủi ro tấn công lan ngang (lateral movement), đơn giản hóa việc bổ sung máy chủ mới bằng cách gán EPG tương ứng thay vì cấu hình VLAN thủ công trên từng switch.

f) Cách thức hoạt động cụ thể:

• Khi một gói tin đi từ server thuộc EPG-WEB đến server thuộc EPG-APP, leaf nơi server nguồn cắm vào (leaf ingress) sẽ đóng gói gói tin theo giao thức VXLAN rồi chuyển tới leaf nơi server đích cắm vào (leaf egress), đi qua lớp spine ở giữa — toàn bộ quá trình này diễn ra trong lớp hạ tầng (infra VRF) và trong suốt với người dùng.
• Trước khi chuyển gói tin, leaf kiểm tra xem giữa EPG-WEB và EPG-APP đã có Contract cho phép hay chưa (dựa trên cấu hình provider/consumer đã khai báo ở APIC); nếu không có Contract, gói tin bị chặn ngay tại leaf theo đúng mô hình zero-trust.
• Các spine đóng vai trò tra cứu vị trí endpoint thông qua giao thức nội bộ COOP (Council Of Oracle Protocol) — khi leaf ingress không biết đích đến nằm ở leaf nào, nó hỏi spine, spine trả lời "endpoint đó đang nằm sau leaf nào" rồi leaf ingress mới đóng gói và gửi đi.
• Toàn bộ 3 APIC hoạt động như một cụm cấu hình phân tán: quản trị viên chỉ cần thay đổi chính sách trên 1 APIC bất kỳ, thay đổi đó sẽ tự động đồng bộ sang 2 APIC còn lại và được đẩy xuống toàn bộ leaf/spine liên quan trong vài giây, không cần đăng nhập thủ công vào từng thiết bị.

2. Công Ty B – Tập Đoàn Đa Chi Nhánh, Đa Trung Tâm Dữ Liệu (Mô Hình Multi-Pod + Multicloud)

Bối cảnh: 2 trung tâm dữ liệu chính (Hà Nội và TP.HCM), nhiều chi nhánh vệ tinh, có nhu cầu mở rộng workload lên AWS, yêu cầu cao về khả năng sẵn sàng và khôi phục thảm họa (BC/DR) cho hệ thống ERP và nền tảng thương mại điện tử.

Hạ tầng đề xuất:

1. Cisco Nexus Dashboard Orchestrator: quản lý chính sách tập trung cho nhiều Pod/site.
2. Pod 1 (DC Hà Nội) và Pod 2 (DC TP.HCM): mỗi Pod là một fabric spine-leaf độc lập, dùng chung một cụm APIC theo mô hình Multi-Pod.
3. Remote Leaf: đặt tại các chi nhánh lớn, kết nối về spine tại DC chính.
4. Virtual APIC (vAPIC) trên AWS: mở rộng chính sách ACI lên workload chạy trên đám mây công cộng.

a) Danh sách thiết bị cần mua (Bill of Materials):

b) Sơ đồ đấu nối vật lý:

1. Bên trong mỗi Pod: đấu nối giống hệt Công ty A — leaf đấu full-mesh tới spine trong cùng Pod, APIC đấu vào 2 leaf, mgmt0 đấu vào switch OOB riêng của từng DC.
2. Giữa 2 Pod: mỗi spine của Pod 1 đấu một đường Layer 3 (dùng sub-interface đóng gói 802.1Q VLAN-4) tới router IPN đặt tại DC Hà Nội; tương tự, spine của Pod 2 đấu tới router IPN tại DC TP.HCM. Hai router IPN này kết nối với nhau qua đường truyền WAN/cáp quang thuê riêng/DWDM, yêu cầu độ trễ khứ hồi (RTT) không vượt quá 50 mili-giây để Multi-Pod hoạt động ổn định.
3. Remote Leaf tại chi nhánh: 2 leaf đặt tại chi nhánh không đấu vào spine tại chỗ (vì chi nhánh không có spine), mà đấu lên router WAN của chi nhánh, từ đó truyền qua mạng WAN/Internet về tới IPN của Pod chính mà Remote Leaf này được gán vào. Yêu cầu tối thiểu: RTT dưới 300 mili-giây và băng thông từ 10-100 Mbps trở lên tùy nhu cầu.
4. Mở rộng AWS: Cisco Cloud Network Controller được triển khai như một máy ảo trong tài khoản AWS; nó tự động dựng các đường hầm IPSec/VXLAN giữa AWS Transit Gateway (hoặc router ảo CSR1000v trong VPC) với border leaf tại trung tâm dữ liệu chính, hình thành một "site" ảo trong mô hình Multi-Site mà không cần đấu cáp vật lý.

c) Các bước triển khai và cấu hình:

Lưu ý: giống như Công ty A, toàn bộ cấu hình tenant/VRF/EPG/contract bên dưới chỉ thực hiện trên cụm APIC (hoặc trên Nexus Dashboard Orchestrator) — switch tại cả Pod 1 lẫn Pod 2 không cần cấu hình thủ công. Điểm khác biệt duy nhất so với Công ty A là có thêm 2 thiết bị "trung gian" cũng cần cấu hình riêng: router IPN (dùng CLI của chính router đó, không qua APIC — vì IPN là mạng trung lập giữa 2 Pod, không thuộc quyền quản lý của APIC) và Cloud Network Controller (cấu hình qua giao diện riêng của nó, đồng bộ với APIC qua Nexus Dashboard Orchestrator).

1. Triển khai Pod 1 giống hệt quy trình của Công ty A (chạy setup script trên 3 APIC, khai báo Pod ID = 1, TEP Pool riêng cho Pod 1).
2. Cấu hình router IPN: bật OSPF (hoặc eBGP từ APIC 5.2(3) trở lên) trên các sub-interface hướng về spine, bật DHCP Relay trỏ về địa chỉ hạ tầng của APIC để spine ở Pod 2 có thể "xin" địa chỉ và gia nhập fabric, bật PIM Bidir để chuyển tiếp lưu lượng broadcast/multicast/unknown-unicast (BUM) giữa 2 Pod, và nâng MTU đủ lớn để chứa gói tin đã đóng gói VXLAN.
3. Thêm Pod 2 vào fabric: trên GUI APIC, vào Fabric > Inventory > Pod Fabric Setup Policy > Create Multi-Pod, khai báo TEP Pool riêng cho Pod 2 và community string dùng chung; sau khi cáp vật lý giữa spine Pod 2 và IPN được đấu nối, các switch tại Pod 2 sẽ tự động được cụm APIC (đang chạy ở Pod 1) phát hiện và đưa vào cùng một fabric duy nhất — không cần dựng thêm cụm APIC riêng.
4. Bổ sung APIC dự phòng tại Pod 2 (thường 1-2 node) để cụm APIC không tập trung toàn bộ tại một Pod, tránh mất quyền quản trị nếu Pod 1 gặp sự cố.
5. Triển khai Remote Leaf: đấu leaf tại chi nhánh vào router WAN, trên APIC vào mục cấu hình Remote Leaf để khai báo TEP Pool riêng cho vị trí từ xa và gán leaf đó vào Pod tương ứng; toàn bộ EPG/Contract đã tạo ở tenant sẽ tự động khả dụng tại leaf này.
6. Triển khai Nexus Dashboard: cài đặt cụm 3 node (mã ND-CLUSTERG5S dạng phần cứng vật lý hoặc ND-VIRTUAL dạng máy ảo). Mỗi node có 2 nhóm cổng mạng: cổng quản lý (mgmt0/mgmt1 trên card mLOM) đấu về switch OOB — cùng mạng quản lý với APIC/leaf/spine; cổng dữ liệu (fabric0/fabric1 trên card mở rộng khe PCIe) đấu dạng vPC vào 2 leaf switch khác nhau trong fabric, tương tự cách đấu một server thông thường, để Nexus Dashboard giao tiếp được với APIC qua mạng hạ tầng. Sau khi cài đặt, cài ứng dụng Nexus Dashboard Orchestrator và "onboard" (thêm) fabric Multi-Pod vừa tạo vào Orchestrator để quản lý chính sách và theo dõi tình trạng xuyên suốt 2 Pod từ một giao diện duy nhất.
7. Mở rộng lên AWS: triển khai Cisco Cloud Network Controller từ AWS Marketplace vào một VPC riêng, liên kết với Nexus Dashboard Orchestrator theo mô hình Cloud Multi-Site; ánh xạ Tenant/VRF/EPG phía on-premises sang cấu trúc VPC/Security Group tương ứng trên AWS — hệ thống tự động dựng đường hầm kết nối, không cần cấu hình IPSec thủ công.
8. Sau khi hạ tầng sẵn sàng, đẩy cấu trúc logic (tenant, VRF, bridge domain, EPG, contract) như trình bày dưới đây — có thể thực hiện qua REST API hoặc thông qua template trên Nexus Dashboard Orchestrator để đảm bảo đồng bộ chính sách giữa 2 Pod.

d) Cấu trúc đối tượng logic mẫu (nội dung sẽ khai báo trên APIC/Orchestrator ở bước 8):

1. Tenant: CONGTYB_GLOBAL
2. VRF: VRF-ERP-GLOBAL, VRF-ECOM-GLOBAL
3. Bridge Domain: BD-ERP-HANOI, BD-ERP-HCM, BD-ECOM-CLOUD
4. Application Profile: AP-ERP, AP-ECOMMERCE
5. EPG:
   • EPG-ERP-HANOI (Pod 1)
   • EPG-ERP-HCM (Pod 2, đồng bộ chính sách với Pod 1 qua Nexus Dashboard Orchestrator)
   • EPG-ECOM-FRONTEND (đặt tại on-premises)
   • EPG-ECOM-BACKEND-CLOUD (mở rộng lên AWS qua vAPIC)
6. Contract liên site:
   • CT-ERP-REPLICATION: cho phép đồng bộ dữ liệu ERP giữa Pod 1 và Pod 2 (phục vụ BC/DR)
   • CT-ECOM-FRONTEND-TO-BACKEND: cho phép frontend on-premises gọi backend trên AWS qua cổng HTTPS 443, được mã hóa toàn trình

Cấu hình mẫu qua REST API của APIC (cấu trúc payload tham chiếu theo ví dụ chính thức trong Cisco APIC REST API Configuration Guide — mục "Managing Layer 4 to Layer 7 Services", nơi Cisco minh họa cách một lệnh POST duy nhất có thể tạo đồng thời Tenant, VRF, Bridge Domain, Application Profile và EPG; ở đây chỉ đổi tên đối tượng theo Công ty B):

POST https://apic-ip-address/api/mo/uni.json

{
  "fvTenant": {
    "attributes": { "dn": "uni/tn-CONGTYB_GLOBAL", "name": "CONGTYB_GLOBAL" },
    "children": [
      { "fvCtx": { "attributes": { "name": "VRF-ERP-GLOBAL" } } },
      {
        "fvBD": {
          "attributes": { "name": "BD-ERP-HANOI" },
          "children": [
            { "fvRsCtx": { "attributes": { "tnFvCtxName": "VRF-ERP-GLOBAL" } } },
            { "fvSubnet": { "attributes": { "ip": "10.20.10.1/24" } } }
          ]
        }
      },
      {
        "fvBD": {
          "attributes": { "name": "BD-ERP-HCM" },
          "children": [
            { "fvRsCtx": { "attributes": { "tnFvCtxName": "VRF-ERP-GLOBAL" } } },
            { "fvSubnet": { "attributes": { "ip": "10.20.20.1/24" } } }
          ]
        }
      },
      {
        "fvAp": {
          "attributes": { "dn": "uni/tn-CONGTYB_GLOBAL/ap-AP-ERP", "name": "AP-ERP" },
          "children": [
            {
              "fvAEPg": {
                "attributes": { "dn": "uni/tn-CONGTYB_GLOBAL/ap-AP-ERP/epg-EPG-ERP-HANOI", "name": "EPG-ERP-HANOI" },
                "children": [
                  { "fvRsBd": { "attributes": { "tnFvBDName": "BD-ERP-HANOI" } } },
                  { "fvRsCons": { "attributes": { "tnVzBrCPName": "CT-ERP-REPLICATION" } } }
                ]
              }
            },
            {
              "fvAEPg": {
                "attributes": { "dn": "uni/tn-CONGTYB_GLOBAL/ap-AP-ERP/epg-EPG-ERP-HCM", "name": "EPG-ERP-HCM" },
                "children": [
                  { "fvRsBd": { "attributes": { "tnFvBDName": "BD-ERP-HCM" } } },
                  { "fvRsProv": { "attributes": { "tnVzBrCPName": "CT-ERP-REPLICATION" } } }
                ]
              }
            }
          ]
        }
      }
    ]
  }
}

Nguồn tham khảo cú pháp: Cisco APIC REST API Configuration Guide — ví dụ chính thức tạo tenant "acme" gồm VRF, Bridge Domain, Application Profile và EPG bằng một request POST duy nhất tới uni.json (xem mục 4.2 trong danh sách tài liệu tham khảo). Payload trên chỉ đổi tên đối tượng theo Công ty B và bổ sung quan hệ fvRsCons/fvRsProv để minh họa Contract đồng bộ dữ liệu giữa 2 Pod.

Về hạ tầng vật lý kết nối 2 Pod, Cisco quy định IPN (Inter-Pod Network) giữa các Pod phải dùng kết nối Layer 3, và Multi-Pod sử dụng MP-BGP EVPN làm giao thức control-plane giữa các spine của các Pod khác nhau — theo Cisco APIC Layer 3 Networking Configuration Guide, mục Multi-Pod (xem mục 4.3 trong tài liệu tham khảo). Toàn bộ Pod trong Multi-Pod vẫn dùng chung một cụm APIC duy nhất, nên cấu hình tenant/VRF/BD/EPG ở trên sẽ tự động được đồng bộ và khả dụng trên cả 2 Pod mà không cần cấu hình lặp lại.

Kết quả đạt được: chính sách mạng và bảo mật được đồng bộ tự động trên cả 2 trung tâm dữ liệu và chi nhánh, hỗ trợ chuyển đổi dự phòng (failover) khi một Pod gặp sự cố, đồng thời cho phép mở rộng linh hoạt sang AWS mà vẫn giữ nguyên mô hình chính sách zero-trust xuyên suốt.

e) Cách thức hoạt động cụ thể:

• Về control-plane, mỗi Pod tự vận hành một tiến trình IS-IS/COOP riêng để tra cứu vị trí endpoint nội bộ; giữa 2 Pod, các spine trao đổi thông tin định tuyến với nhau qua MP-BGP EVPN chạy trên IPN — đây là cơ chế giúp Pod 2 "biết" được endpoint nào đang nằm ở Pod 1 và ngược lại mà không cần một bộ điều khiển trung gian.
• Về data-plane, khi EPG-ERP-HANOI (Pod 1) cần đồng bộ dữ liệu với EPG-ERP-HCM (Pod 2), gói tin được đóng gói VXLAN tại leaf nguồn, chuyển qua spine của Pod 1, vượt qua IPN (đóng gói thêm một lớp header định tuyến IP thông thường để đi qua mạng IPN vốn không hiểu VXLAN của ACI), tới spine của Pod 2 rồi giải mã và chuyển tới leaf đích — toàn bộ vẫn nằm dưới sự kiểm soát của Contract CT-ERP-REPLICATION đã khai báo.
• Vì cả 2 Pod dùng chung một cụm APIC, khi quản trị viên tạo hoặc sửa policy tại Pod 1, thay đổi này được tự động nhân bản (replicate) sang Pod 2 mà không cần thao tác lặp lại — đây là điểm khác biệt so với ACI Multi-Site (giải pháp dùng nhiều cụm APIC độc lập, đồng bộ qua Nexus Dashboard Orchestrator ở mức "template" thay vì tự động 100%).
• Với Remote Leaf, dữ liệu của endpoint tại chi nhánh vẫn được VXLAN-hóa và gửi ngược về spine tại Pod chính để tra cứu chính sách/COOP (trừ khi bật chế độ chuyển mạch cục bộ - local switching), do đó chi nhánh vẫn tuân thủ đúng Contract dù không có spine hay APIC tại chỗ.
• Với phần mở rộng AWS, Cloud Network Controller dịch các đối tượng Tenant/VRF/EPG sang ngôn ngữ hạ tầng của AWS (VPC, Route Table, Security Group) và tự động thiết lập đường hầm mã hóa để lưu lượng giữa on-premises và cloud vẫn được kiểm soát bởi cùng một bộ Contract, giúp đội ngũ hạ tầng không phải quản lý 2 bộ chính sách bảo mật riêng biệt cho 2 môi trường.

3. Kết Luận

Hai kịch bản trên cho thấy Cisco ACI có thể mở rộng linh hoạt từ một fabric đơn giản trong một trung tâm dữ liệu (Công ty A) cho tới một kiến trúc phức tạp trải dài nhiều Pod, nhiều chi nhánh và cả public cloud (Công ty B) — nhưng vẫn giữ nguyên một nguyên tắc cốt lõi xuyên suốt: toàn bộ chính sách được khai báo tập trung trên APIC/Orchestrator, tự động đẩy xuống đúng thiết bị liên quan, thay vì cấu hình thủ công từng switch như mô hình mạng truyền thống. Đây chính là giá trị cốt lõi giúp doanh nghiệp rút ngắn thời gian triển khai và giảm rủi ro sai sót cấu hình.

Để hiểu thêm về khái niệm, thành phần và lợi ích tổng thể của giải pháp trước khi bắt tay triển khai, bạn có thể tham khảo bài viết Cisco ACI Là Gì? Giải Pháp SDN Cho Trung Tâm Dữ Liệu Hiện Đại.

4. Tài Liệu Tham Khảo (Chính Hãng Cisco)

1. Cisco APIC NX-OS Style CLI Configuration Guide – Use Case: Three-Tier Application with Transit Topology (nguồn cú pháp CLI cho cấu hình mẫu Công ty A): cisco.com/.../b_APIC_NXOS_CLI_User_Guide_appendix_010000.html
2. Cisco APIC REST API Configuration Guide – Managing Layer 4 to Layer 7 Services (nguồn cú pháp payload REST API cho cấu hình mẫu Công ty B): cisco.com/.../Cisco-APIC-REST-API-Configuration-Guide-401_chapter_01111.html
3. Cisco APIC Layer 3 Networking Configuration Guide – Multi-Pod (nguồn nguyên lý kết nối IPN và MP-BGP EVPN giữa các Pod): cisco.com/.../multipod-layer3-config-61x.html
4. Cisco Application Centric Infrastructure Fabric Hardware Installation Guide – Connecting the Switch to the ACI Fabric (nguồn quy tắc đấu nối spine-leaf-APIC): cisco.com/.../b_aci_hardware_install_guide_chapter_011.html
5. Cisco APIC Getting Started Guide – Fabric Initialization and Switch Discovery (nguồn cơ chế cascading discovery và initial setup script): cisco.com/.../m_fabric_initialization.html
6. Cisco ACI Remote Leaf Architecture White Paper (nguồn yêu cầu độ trễ/băng thông Remote Leaf): cisco.com/.../white-paper-c11-740861.html
7. Cisco Application Centric Infrastructure Multi-Pod Configuration White Paper (nguồn các bước cấu hình Create Multi-Pod trên GUI APIC): cisco.com/.../white-paper-c11-739714.html
8. Cisco Nexus Dashboard Data Sheet (nguồn mã sản phẩm ND-CLUSTERG5S/ND-CLUSTER-L4/ND-VIRTUAL và thông số phần cứng): cisco.com/.../datasheet-c78-744371.html
9. Cisco Nexus Dashboard Deployment and Upgrade Guide – Deploying as a Physical Appliance (nguồn cách đấu nối cổng quản lý mLOM và cổng dữ liệu PCIe của từng node): cisco.com/.../nd-deploy-physical-41x.html