Vietnamese Professional - DCACI

VxLAN EVPN

dangquangminh — Sun, 07 Jun 2026 02:58:45 GMT

BGP EVPN Control Plane hoạt động như thế nào?

Hình minh họa mô tả vai trò của BGP EVPN (Ethernet VPN) trong kiến trúc VXLAN EVPN Spine-Leaf. Trong các mạng Layer 2 truyền thống, switch phải sử dụng cơ chế flood-and-learn để học địa chỉ MAC. Khi một thiết bị mới xuất hiện, switch sẽ phát tán lưu lượng quảng bá (broadcast, unknown unicast) để tìm vị trí của thiết bị đó. Điều này gây lãng phí băng thông và không phù hợp với các Data Center quy mô lớn. Với EVPN, việc học thông tin thiết bị đầu cuối được chia thành hai giai đoạn:

1. Local Learning

Khi máy chủ M1/IP1 kết nối vào VTEP bên trái, VTEP học được các thông tin như Địa chỉ MAC của M1, Địa chỉ IP của M1, Interface kết nối (Eth1/1). Đây được gọi là Local Learning. Sau khi học được thông tin này, VTEP tạo một bản ghi EVPN Route (thường là Type-2 Route) và quảng bá thông qua BGP EVPN.

2. Route Distribution

Thông tin MAC/IP vừa học được sẽ được gửi qua các phiên BGP EVPN tới các VTEP khác trong fabric. Ví dụ: VTEP chứa M1 sẽ quảng bá các thông tin như MAC = M1, IP = IP1, VTEP Source = VTEP1. Các VTEP còn lại đều nhận được bộ thông tin này. Đây chính là phần Route Distribution được ghi trong slide.

3. Remote Learning

Sau khi nhận route EVPN, các VTEP từ xa học được các thông tin gồm MAC M1, IP1, VTEP đích chứa M1. Quá trình này gọi là Remote Learning. Điểm quan trọng là các VTEP không cần phải phát tán (flood) lưu lượng để tìm MAC của M1 nữa. Thông tin được học thông qua Control Plane (BGP) thay vì thông qua Data Plane.

4. Peer Discovery

BGP EVPN cũng giúp các VTEP phát hiện các VTEP khác trong fabric và thiết lập quan hệ trao đổi route, xây dựng bảng ánh xạ:
MAC/IP <-> VTEP. Nhờ vậy mỗi VTEP đều biết chính xác endpoint đang nằm ở đâu.

Tại sao hình vẫn ghi "Learning local end-host through Data Plane"?

EVPN không loại bỏ hoàn toàn việc học qua Data Plane. Đối với thiết bị vừa mới kết nối VTEP vẫn phải nhận frame thực tế từ host, Học MAC/IP trên cổng vật lý. Sau đó, thông tin được đưa lên BGP EVPN, các VTEP khác học qua Control Plane Do đó:

Local Learning = Data Plane

Remote Learning = Control Plane (BGP EVPN)

Lợi ích của EVPN so với Flood-and-Learn VXLAN

Trong VXLAN truyền thống:
Host mới xuất hiện
↓
Flood
↓
Các VTEP học MAC
Trong VXLAN EVPN:
Host mới xuất hiện
↓
Local Learning
↓
BGP EVPN Advertisement
↓
Remote Learning
Kết quả là mạng sẽ giảm Broadcast, giảm Unknown Unicast Flooding, mạng hội tụ nhanh hơn. Ngoài ra, hạ tầng có thể mở rộng tới hàng chục nghìn endpoint, phù hợp cho AI Fabric, Cloud Data Center và Multi-Tenant Data Center. Đây chính là lý do vì sao hiện nay VXLAN EVPN đã trở thành kiến trúc Data Center mặc định trên Cisco Nexus, Arista EOS, Juniper Apstra và hầu hết các hạ tầng AI/Cloud hiện đại.

VxLAN Overview

dangquangminh — Sat, 06 Jun 2026 08:38:42 GMT

VXLAN Overview – Vì sao VXLAN ra đời?

Khi học về mạng Campus truyền thống, chúng ta quen với khái niệm VLAN để phân chia các miền Layer 2. Tuy nhiên, VLAN có một giới hạn lớn là chỉ sử dụng 12 bit trong thẻ 802.1Q, do đó chỉ hỗ trợ tối đa:
2¹² = 4.096 VLAN
Với mạng doanh nghiệp nhỏ thì con số này khá lớn, nhưng trong các trung tâm dữ liệu hiện đại, môi trường Cloud và Multi-Tenant, 4.096 VLAN nhanh chóng trở thành giới hạn. Vấn đề của VLAN truyền thống

Trong khung Ethernet thông thường, VLAN được biểu diễn thông qua trường 802.1Q VLAN Tag (12 bits). Ví dụ:

VLAN 10 cho phòng Kế toán

VLAN 20 cho phòng Nhân sự

VLAN 100 cho máy chủ

VLAN 200 cho khách

Tổng cộng toàn bộ hệ thống chỉ có tối đa 4.096 VLAN. Đối với các nhà cung cấp dịch vụ Cloud như AWS, Azure hay Google Cloud, mỗi khách hàng có thể cần hàng chục hoặc hàng trăm mạng riêng biệt. Khi có hàng ngàn khách hàng, giới hạn VLAN trở thành rào cản rất lớn.

Giải pháp của VXLAN

VXLAN (Virtual Extensible LAN) thay thế VLAN ID bằng một trường mới gọi là VNI (VXLAN Network Identifier). VNI có độ dài 24 bit. Do đó số lượng mạng logic có thể tạo ra là 2²⁴ = 16.777.216 VNI. Tức là hơn 16 triệu mạng Layer 2 độc lập so với 4.096 VLAN truyền thống.

VXLAN đóng gói như thế nào?

Trong hình, chúng ta thấy toàn bộ khung Ethernet gốc được giữ nguyên. Khung Ethernet ban đầu DMAC, SMAC, 802.1Q (optional), EtherType, Payload, CRC sẽ được đóng gói bên trong một gói VXLAN mới. Cấu trúc mới Outer MAC Header, Outer IP Header, UDP Header, VXLAN Header, Original Ethernet Frame. Đây được gọi là MAC-in-UDP Encapsulation
Một khung Ethernet được đặt bên trong một gói UDP/IP.

Tại sao lại dùng UDP?

VXLAN được thiết kế để chạy trên hạ tầng Layer 3. Điều này mang lại nhiều lợi ích Tận dụng ECMP, Tận dụng định tuyến IP hiện có, Dễ mở rộng quy mô Data Center, không bị giới hạn bởi STP như mạng Layer 2 truyền thống. VXLAN mặc định sử dụng UDP Port 4789.

Overhead của VXLAN

Để vận chuyển một khung Ethernet qua mạng IP, VXLAN phải thêm các header mới Outer Ethernet Header 14 bytes, Outer IPv4, Header 20 bytes, UDP Header 8 bytes, VXLAN Header 8 bytes
Tổng overhead 14 + 20 + 8 + 8 = 50 bytes. Đây chính là con số được ghi trong hình. Ví dụ thực tế

Giả sử VM1 nằm ở Rack A và VM2 nằm ở Rack B. Cả hai đều thuộc:
VNI 10001. Mặc dù khác Switch, khác Rack, khác Subnet Underlay
nhưng VXLAN sẽ tạo cảm giác như VM1 ----- VM2 thuộc cùng VLAN. Đối với hệ điều hành và ứng dụng. Đây chính là khái niệm:
Layer 2 Overlay trên Layer 3 Underlay Underlay và Overlay

Trong mạng VXLAN hiện đại luôn tồn tại hai lớp mạng:

Underlay là Mạng IP vật lý bên dưới. Ví dụ:

Leaf1 --- Spine1 --- Leaf2
Chạy OSPF, IS-IS, eBGP
Nhiệm vụ của Underlay là Đảm bảo kết nối IP giữa các VTEP.

Overlay

Mạng ảo được xây dựng phía trên. Ví dụ VNI 10001, VNI 10002
VNI 10003. Nhiệm vụ là kéo dài, mở rộng Layer 2 giữa các máy chủ ở nhiều vị trí khác nhau.

Vai trò của VTEP

Thiết bị thực hiện đóng gói và giải đóng gói VXLAN gọi là VTEP (VXLAN Tunnel Endpoint). Khi nhận frame từ máy chủ Ethernet Frame, VTEP sẽ thực hiện các bước:

Thêm VXLAN Header

Thêm UDP Header

Thêm Outer IP Header

Gửi qua mạng Underlay

VTEP ở đầu bên kia sẽ:

Bóc các header VXLAN

Khôi phục Ethernet Frame gốc

Chuyển đến máy đích

Tóm tắt BÀI vXlan.

VXLAN được sinh ra để giải quyết giới hạn 4.096 VLAN của mạng Ethernet truyền thống. Thay vì dùng VLAN ID 12 bit, VXLAN sử dụng VNI 24 bit, cho phép tạo tới 16,7 triệu mạng logic. VXLAN hoạt động bằng cơ chế MAC-in-UDP Encapsulation, đóng gói toàn bộ frame Ethernet vào bên trong gói UDP/IP và vận chuyển qua mạng Layer 3. Đây là nền tảng của các kiến trúc Data Center hiện đại như Cisco VXLAN EVPN, VMware NSX, AWS VPC Networking, Azure Virtual Network, Multi-Tenant Cloud Infrastructure. Chúng ta có thể xem VXLAN là công nghệ đã mang khả năng mở rộng của IP Routing vào thế giới Layer 2.

Nguyên nhân gây mất gói tin (Packet Loss) trong mạng

dangquangminh — Fri, 05 Jun 2026 00:35:03 GMT

Nguyên nhân gây mất gói tin (Packet Loss) trong mạng

Có hai nguyên nhân phổ biến nhất:

Bit Errors (Lỗi bit)
Congestion (Nghẽn mạng)

Giải thích theo góc nhìn thực tế của kỹ sư mạng

Khi người dùng phản ánh ứng dụng chậm, cuộc gọi VoIP bị giật hoặc truyền file không ổn định, một trong những chỉ số đầu tiên cần kiểm tra là packet loss. Tuy nhiên, không phải mọi trường hợp mất gói đều có cùng nguyên nhân.

Bit Errors (Lỗi bit) thường xuất phát từ các vấn đề ở tầng vật lý hoặc tầng liên kết dữ liệu. Ví dụ:

Cáp mạng bị lỗi hoặc suy hao
Module quang (SFP/QSFP) gặp sự cố
Đầu nối quang bị bẩn
Nhiễu điện từ (EMI)
Duplex mismatch
Tín hiệu Wi-Fi yếu hoặc bị nhiễu

Khi frame Ethernet bị lỗi CRC hoặc FCS, thiết bị nhận sẽ loại bỏ frame đó. Từ góc nhìn của tầng trên, điều này được xem như một gói tin bị mất.

Các lệnh thường dùng để kiểm tra:
show interfaces

Quan tâm đến các chỉ số:
CRC
Input Errors
Frame Errors
Runts
Giants

Congestion (Nghẽn mạng) lại là một vấn đề hoàn toàn khác.

Trong trường hợp này, đường truyền hoặc thiết bị mạng không bị lỗi vật lý. Vấn đề nằm ở việc lưu lượng gửi đến nhiều hơn khả năng xử lý hoặc chuyển tiếp của thiết bị.

Ví dụ:

Đường WAN 100 Mbps nhưng lưu lượng thực tế lên tới 150 Mbps
Buffer trên switch hoặc router bị đầy
Traffic burst từ backup, AI training hoặc replication
DDoS hoặc lưu lượng bất thường

Khi hàng đợi (queue) đầy, thiết bị sẽ bắt đầu loại bỏ các gói tin mới đến.

Các chỉ số cần kiểm tra:
show interfaces
show policy-map interface
show platform hardware qfp active statistics drop

Các dấu hiệu thường gặp:

Output drops
Queue drops
Tail drops
Random Early Detection (RED) drops

Một mẹo Troubleshooting thực chiến

Khi phát hiện packet loss, hãy tự hỏi:

Packet bị mất do lỗi vật lý hay do thiết bị chủ động loại bỏ vì quá tải?

Nếu thấy:
CRC Errors tăng
Input Errors tăng

=> Nghi ngờ Bit Errors

Nếu thấy:
Output Drops tăng
Queue Drops tăng
Interface utilization cao

=> Nghi ngờ Congestion

Đây là bước phân loại đầu tiên giúp kỹ sư mạng tiết kiệm rất nhiều thời gian khi troubleshooting.

Nói ngắn gọn, phần lớn các sự cố packet loss trong mạng doanh nghiệp cuối cùng đều quay về hai nhóm nguyên nhân cốt lõi: lỗi truyền dẫn (Bit Errors) hoặc nghẽn tài nguyên (Congestion). Việc xác định đúng nhóm nguyên nhân ngay từ đầu sẽ quyết định tốc độ xử lý sự cố của kỹ sư mạng.

QoS

dangquangminh — Tue, 02 Jun 2026 13:29:44 GMT

QoS trong hạ tầng AI và Storage: Không phải mọi gói tin đều được đối xử như nhau

Hình trên mô tả một mô hình QoS (Quality of Service) đơn giản hóa thường được sử dụng trong các mạng Data Center hiện đại, đặc biệt là các môi trường AI, HPC, Storage và Cloud.

QoS hoạt động theo 4 bước chính:

Classification (Phân loại)
Thiết bị mạng nhận diện loại lưu lượng dựa trên các trường như Ethernet CoS hoặc IP DSCP.

Ví dụ:

RoCE traffic
NVMe/TCP traffic
iSCSI traffic
Traffic quản trị
Traffic ứng dụng thông thường

Sau khi nhận diện, gói tin sẽ được gắn nhãn ưu tiên.

Queueing (Đưa vào hàng đợi)

Thay vì tất cả gói tin tranh nhau cùng một đường truyền, switch tạo nhiều hàng đợi khác nhau.

Trong ví dụ này có 8 lớp:

Class 1: Traffic ưu tiên cao (Priority)
Class 2: Business Critical
Class 3: FCoE (lossless)
Class 4: iSCSI và NVMe/TCP
Class 5: RoCE (lossless)
Class 6: Management
Class 7: Bulk Data
Class 8: Best Effort

Điều này giúp lưu lượng AI và Storage không bị ảnh hưởng bởi các ứng dụng thông thường.

Queue Management (Quản lý hàng đợi)

Khi hàng đợi bắt đầu đầy, switch phải quyết định:

Giữ lại gói tin
Đánh dấu ECN
Hoặc loại bỏ gói tin

Một số cơ chế phổ biến:

WRED (Weighted Random Early Detection)

Switch chủ động loại bỏ một phần gói tin trước khi queue đầy hoàn toàn để tránh nghẽn.

AFD (Adaptive Flow Distribution)

Được dùng nhiều trong mạng AI Ethernet hiện đại để phát hiện các flow "quá lớn" và giảm nguy cơ một luồng chiếm hết băng thông.

ECN (Explicit Congestion Notification)

Thay vì drop packet, switch đánh dấu gói tin để máy chủ biết rằng mạng đang bị nghẽn.

Đây là cơ chế cực kỳ quan trọng trong RoCEv2.

Scheduling (Lập lịch truyền gói)

Cuối cùng, switch phải quyết định gói tin nào được gửi ra cổng trước.

Các thuật toán thường dùng:

Strict Priority
WRR (Weighted Round Robin)
DWRR (Deficit Weighted Round Robin)

Ví dụ:

RoCE có thể được ưu tiên cao nhất.

iSCSI và NVMe/TCP nhận tỷ lệ băng thông cố định.

Best Effort chỉ sử dụng phần băng thông còn lại.

Tại sao QoS lại đặc biệt quan trọng trong AI Data Center?

Trong Data Center truyền thống:

Một vài gói bị mất thường không phải vấn đề lớn.
TCP sẽ truyền lại.

Nhưng trong AI Training Cluster:

Hàng nghìn GPU phải đồng bộ dữ liệu liên tục.
All-Reduce yêu cầu độ trễ cực thấp.
Chỉ một GPU chậm cũng có thể làm chậm cả job huấn luyện.

Vì vậy các mạng AI hiện đại thường:

Dành queue riêng cho RoCE
Sử dụng ECN thay vì drop packet
Kết hợp PFC (Priority Flow Control)
Sử dụng AFD hoặc các cơ chế chống congestion tiên tiến

Mục tiêu là xây dựng một lossless Ethernet fabric cho lưu lượng AI, trong khi vẫn phục vụ đồng thời các dịch vụ như NVMe/TCP, iSCSI, Management và Business Applications trên cùng một hạ tầng mạng.

Nói ngắn gọn, QoS chính là "người điều phối giao thông" của Data Center. Khi mạng bắt đầu đông đúc, QoS quyết định ai được đi trước, ai phải chờ, ai được bảo vệ khỏi mất gói và ai phải nhường đường để đảm bảo các ứng dụng quan trọng như AI Training và Storage luôn hoạt động ổn định.

Bên trong một Tenant ACI có gì?

anhnguyxn — Tue, 02 Jun 2026 07:45:12 GMT

Nhiều người mới học ACI hay bị rối vì không biết các thành phần liên quan đến nhau như thế nào.
Hãy hình dung Tenant như một tòa nhà — bên trong có nhiều tầng, mỗi tầng có vai trò riêng:
—
Tầng 1 – VRF (Virtual Routing & Forwarding)
Là không gian định tuyến L3 riêng biệt.
Một Tenant có thể có nhiều VRF → tách biệt hoàn toàn về routing.
Ví dụ: VRF-Production và VRF-Dev chạy song song, không "thấy" nhau.
Tầng 2 – Bridge Domain (BD)
Tương đương với một broadcast domain (VLAN) trong mạng truyền thống.
Mỗi BD gắn với một VRF và chứa một hoặc nhiều subnet.
BD có thể chạy ở L2 mode (chỉ bridging) hoặc L3 mode (có gateway, unicast routing).
Tầng 3 – Application Profile
Container tổ chức các EPG theo ứng dụng.
Ví dụ: App "ERP" gồm 3 EPG: Web tier, App tier, DB tier.
Tầng 4 – EPG (Endpoint Group)
Nhóm các endpoint có cùng chính sách bảo mật.
EPG gắn với Bridge Domain và nhận traffic từ port vật lý hoặc VM.
Mặc định: các EPG KHÔNG nói chuyện được với nhau → cần Contract.
Tầng 5 – Contract
Quy định EPG nào được phép giao tiếp với EPG nào, theo giao thức và port nào.
Mô hình Provider (server) / Consumer (client) — rõ ràng và có kiểm soát.
—
Tóm tắt cấu trúc:
Tenant
└── VRF
└── Bridge Domain → Subnet
└── Application Profile
└── EPG → Endpoint
└── Contract (với EPG khác)
Hiểu được tầng lớp này là bạn đã nắm được 80% nền tảng để học ACI.
Bạn đang bị rối ở tầng nào nhất? Comment bên dưới nhé
#CiscoACI #DCACI #DataCenter #Networking #NetworkEngineer #LearnNetworking

Làm chủ kiến trúc cisco data center aci (dcaci) thực chiến – khai giảng 08/06

hongnhungvnpro — Tue, 02 Jun 2026 07:39:54 GMT

LÀM CHỦ KIẾN TRÚC CISCO DATA CENTER ACI (DCACI) THỰC CHIẾN – KHAI GIẢNG 08/06
Bạn là Network Engineer, System Admin đang đối mặt với làn sóng dịch chuyển hạ tầng mạnh mẽ sang SDN (Software-Defined Networking)? Bạn mệt mỏi vì quản trị, cấu hình CLI truyền thống trên từng thiết bị đơn lẻ và muốn nâng cấp lên chuyên gia deal lương ngàn đô?
Khóa DCACI ONLINE tại VnPro là câu trả lời dành cho bạn!
Học tại VnPro có gì khác biệt?
100% Thực hành Lab thực tế: Hệ thống thiết bị Cisco Nexus, ACI vật lý hiện đại bậc nhất trực thuộc trung tâm (Không học lý thuyết suông).
Chuẩn hóa kiến thức chuyên sâu: Lộ trình tinh gọn giúp tự tin làm chủ công nghệ & chinh phục chứng chỉ CCNP Data Center / CCIE danh giá.
Tương tác trực tiếp: Học online tương tác trực tiếp cùng chuyên gia hạ tầng hàng đầu, giải quyết các bài toán/sự cố thực tế ngay tại doanh nghiệp của bạn.
Thông tin lớp học:
Lịch học: Tối Thứ 2 - 4 - 6 (Từ 19:30 - 22:00)
Hình thức: Học Online toàn quốc (Hỗ trợ kỹ thuật 24/7)
Khai giảng chắc chắn: 08/06/2026
ƯU ĐÃI ĐẶC BIỆT: Tặng ngay trọn bộ Workbook Hướng dẫn cấu hình Lab độc quyền và học bổng ưu đãi học phí cho 3 kỹ sư đăng ký sớm nhất trong hôm nay.
Đừng bỏ lỡ xu hướng công nghệ! Nhấp vào nút "Gửi tin nhắn" ngay để nhận lộ trình chi tiết và tài khoản trải nghiệm hệ thống Lab thực chiến hoàn toàn miễn phí.
--- Thông tin liên hệ & Tư vấn trực tiếp:
Hotline/Zalo: 0933 427 079
Như Ngọc: 076 5944 386
Anh Thư: 033 9943 732
Hồng Nhung: 038 3920 627

Mạng lưu trữ cho hạ tầng AI

dangquangminh — Sun, 31 May 2026 08:20:41 GMT

Storage Network trong hạ tầng AI: Nên dùng mạng riêng hay dùng chung?

Khi nói đến hạ tầng AI hiện đại, nhiều người thường tập trung vào GPU, CPU hay các mô hình LLM. Tuy nhiên, một thành phần rất quan trọng nhưng thường bị đánh giá thấp chính là mạng lưu trữ Storage Network – mạng kết nối các cụm GPU với hệ thống lưu trữ dữ liệu.
Trong các hệ thống AI Training và AI Inference quy mô lớn, dữ liệu huấn luyện thường nằm trong các hệ thống lưu trữ dùng chung (Shared Storage) như NAS, Parallel File System hoặc Distributed Storage. Nhiệm vụ của Storage Network là vận chuyển dữ liệu từ Storage đến GPU với tốc độ đủ nhanh để GPU luôn có việc để làm.
Nếu storage không theo kịp tốc độ xử lý của GPU, kết quả là những GPU trị giá hàng chục nghìn USD sẽ phải ngồi chờ dữ liệu, làm giảm đáng kể hiệu quả đầu tư. (GPU nhanh mà bị đói dữ liệu).

Dedicated Storage Network hay Shared Storage Network?

Có hai cách triển khai phổ biến.

Dedicated Storage Network

Đây là mô hình được khuyến nghị trong các hệ thống AI quy mô lớn. Storage traffic được tách biệt hoàn toàn khỏi lưu lượng mạng thông thường như User traffic, Management traffic, VM traffic, Application traffic. Lợi ích của cách này là:

Không xảy ra tranh chấp băng thông giữa lưu lượng storage và lưu lượng ứng dụng.

Dễ phát hiện và xử lý hiện tượng congestion.

Dễ quản lý thay đổi cấu hình.

Đảm bảo hiệu năng ổn định cho các tác vụ AI Training.

Trong các AI Factory hiện đại, người ta thường thấy Front-end Network, Back-end GPU Network và Storage Network được xây dựng thành các fabric riêng biệt.

Shared Storage Network

Trong mô hình này, storage traffic và application traffic cùng chia sẻ một hạ tầng Ethernet. Ưu điểm lớn nhất là chi phí thấp hơn; Ít switch và NIC hơn; Triển khai đơn giản hơn. Tuy nhiên khi hệ thống AI phát triển, việc chia sẻ tài nguyên mạng có thể dẫn tới nghẽn (congestion), mất gói Packet loss, Tăng latency, GPU starvation (GPU chờ dữ liệu). Do đó mô hình này thường chỉ phù hợp với các cụm AI nhỏ hoặc môi trường PoC.

Storage quan trọng như thế nào đối với AI?

Một GPU H100 hoặc B200 có khả năng xử lý dữ liệu với tốc độ cực lớn. Nếu dữ liệu từ storage không được cấp phát đủ nhanh GPU utilization giảm, thời gian training kéo dài, chi phí vận hành tăng, ROI của hệ thống AI giảm mạnh. Đó là lý do các hệ thống AI hiện đại thường yêu cầu ổ SSD, NVMe, NVMe-over-Fabrics, Parallel File System thay vì HDD truyền thống.

Vì sao AI rất thích NVMe?

AI workload thường tạo ra nhiều thao tác đọc dữ liệu song song, nhiều truy cập ngẫu nhiên (Random I/O). Các file của AI có kích thước nhỏ đến trung bình, checkpoint liên tục trong quá trình training. NVMe được thiết kế để xử lý số lượng IOPS rất lớn với độ trễ thấp, phù hợp hơn nhiều so với SAS hoặc SATA SSD truyền thống.

RDMA cho Storage

Nếu hệ thống lưu trữ hỗ trợ RDMA thì lưu lượng storage có thể sử dụng RoCEv2, RDMA NIC, Lossless Ethernet tương tự như mạng Back-end giữa các GPU thi lúc này dữ liệu có thể được truyền trực tiếp từ bộ nhớ của Storage Server đến bộ nhớ GPU hoặc máy chủ mà không cần CPU xử lý nhiều lần. Kết quả là giảm latency, giảm CPU overhead, tăng throughput, tăng hiệu quả huấn luyện AI.

Một sai lầm phổ biến khi xây dựng AI Cluster

Nhiều tổ chức đầu tư hàng triệu USD cho GPU nhưng lại giữ nguyên hệ thống storage cũ. Kết quả GPU đạt utilization chỉ 40–60%, thời gian training kéo dài hơn dự kiến, không khai thác hết giá trị của hạ tầng AI. Trong thực tế, một AI Cluster mạnh không chỉ cần GPU mạnh mà còn cần phần tính toán Compute mạnh, Network mạnh và phần Storage mạnh. Ba thành phần này phải được thiết kế đồng bộ.
Bài học quan trọng: Trong AI Infrastructure, GPU thường là thành phần đắt tiền nhất, nhưng Storage Network lại là thành phần quyết định liệu GPU có thực sự hoạt động hết công suất hay không. Một hệ thống lưu trữ chậm có thể biến cả cụm GPU trị giá hàng triệu USD thành những bộ xử lý đang... ngồi chờ dữ liệu.

Từ Fibre Channel đến RoCEv2: Bức Tranh Toàn Cảnh Về Các Giao Thức Lưu Trữ Trong Data Center Hiện Đại

dangquangminh — Sat, 30 May 2026 07:37:40 GMT

Từ Fibre Channel đến RoCEv2: Bức Tranh Toàn Cảnh Về Các Giao Thức Lưu Trữ Trong Data Center Hiện Đại

Một trong những điều khiến nhiều kỹ sư mạng và hệ thống cảm thấy khó hiểu khi bước vào lĩnh vực Storage Networking là có quá nhiều thuật ngữ xuất hiện cùng lúc:

Fibre Channel, FCoE, FCIP, iSCSI, NVMe-oF, SMB, NFS, RoCE, RoCEv2, iWARP, InfiniBand...

Nhìn vào sơ đồ trên, chúng ta có thể thấy toàn bộ hệ sinh thái lưu trữ hiện đại thực chất được xây dựng từ bốn thành phần chính:

Loại lưu trữ (Storage Type)
Giao thức lưu trữ (Storage Protocol)
Giao thức vận chuyển (Transport)
Mạng truyền tải (Network)

Hiểu được mối quan hệ này sẽ giúp chúng ta không còn bị "ngợp" trước hàng loạt thuật ngữ trong thế giới Storage và AI Infrastructure.

Bước 1: Các loại lưu trữ

Từ góc nhìn ứng dụng, dữ liệu thường được truy cập theo ba mô hình chính:

Block Storage

Đây là kiểu lưu trữ truyền thống của SAN.

Máy chủ nhìn thấy thiết bị lưu trữ như một ổ đĩa thô (raw disk).

Các giao thức phổ biến:

SCSI
NVMe

Ví dụ:

VMware Datastore
Oracle Database
Microsoft SQL Server

File Storage

Dữ liệu được truy cập dưới dạng thư mục và tập tin.

Các giao thức phổ biến:

NFS
SMB/CIFS

Ví dụ:

File Server
Home Directory
Shared Folder

Object Storage

Dữ liệu được lưu dưới dạng đối tượng (Object).

Ví dụ:

Amazon S3
MinIO
Ceph Object Storage

Mô hình này đặc biệt phổ biến trong AI vì có khả năng lưu trữ khối lượng dữ liệu huấn luyện cực lớn.

Bước 2: Giao thức lưu trữ

Sau khi ứng dụng tạo yêu cầu đọc hoặc ghi dữ liệu, giao thức lưu trữ sẽ đóng gói yêu cầu đó.

SCSI

Là giao thức lâu đời nhất trong thế giới SAN.

Nhiều công nghệ ngày nay thực chất vẫn đang vận chuyển lệnh SCSI bằng nhiều phương thức khác nhau.

Ví dụ:

Fibre Channel
FCoE
iSCSI

đều đang vận chuyển các lệnh SCSI.

NVMe

Được thiết kế cho SSD và Flash Storage hiện đại.

Ưu điểm:

Độ trễ thấp
Nhiều queue
Hiệu năng cực cao

Ngày nay NVMe đang dần thay thế SCSI trong các hệ thống AI Storage hiệu năng cao.

Bước 3: Giao thức vận chuyển

Đây là nơi các công nghệ bắt đầu phân hóa mạnh.

Fibre Channel

Con đường truyền thống của SAN.

Đặc điểm:

Lossless
Độ trễ thấp
Mạng riêng biệt

Nhiều doanh nghiệp lớn vẫn sử dụng Fibre Channel cho các hệ thống Mission Critical.

FCoE

Fibre Channel over Ethernet.

Ý tưởng:

Thay vì xây dựng hai mạng riêng biệt:

Ethernet LAN
Fibre Channel SAN

chúng ta hợp nhất thành một mạng Ethernet duy nhất.

FCoE đóng gói Fibre Channel Frame vào Ethernet Frame.

Tuy nhiên FCoE yêu cầu Ethernet Lossless nên triển khai khá phức tạp.

FCIP

Fibre Channel over IP.

Được dùng để kéo dài SAN qua khoảng cách xa.

Ví dụ:

Kết nối hai Data Center
SAN Replication

FC Frame được đóng gói vào TCP/IP.

iSCSI

Có lẽ là giao thức SAN phổ biến nhất trong môi trường doanh nghiệp vừa và nhỏ.

Cấu trúc:

SCSI → TCP → IP → Ethernet

Ưu điểm:

Chi phí thấp
Chạy trên Ethernet thông thường
Không cần Fibre Channel

NVMe/TCP

Phiên bản hiện đại hơn của iSCSI.

Cấu trúc:

NVMe → TCP → IP → Ethernet

Ưu điểm:

Hiệu năng tốt hơn iSCSI
Không yêu cầu mạng RDMA

Đang trở thành lựa chọn rất hấp dẫn trong các Data Center mới.

Bước 4: RDMA và AI Storage

Đây là phần đang thay đổi toàn bộ ngành công nghiệp.

Các cụm GPU hiện đại yêu cầu:

Latency cực thấp
Throughput cực cao
CPU overhead gần như bằng 0

Vì vậy RDMA xuất hiện.

iWARP

RDMA chạy trên TCP.

Ưu điểm:

Không cần mạng lossless

Nhược điểm:

Overhead TCP cao hơn

RoCE

RDMA chạy trên Ethernet Layer 2.

Không định tuyến được.

Hiện nay ít được triển khai.

RoCEv2

RDMA chạy trên UDP/IP.

Đây là công nghệ đang được sử dụng rộng rãi nhất trong các AI Factory hiện đại.

Cấu trúc:

RDMA Verbs → InfiniBand Transport → UDP → IP → Ethernet

Ưu điểm:

Hỗ trợ Layer 3
Hỗ trợ ECMP
Mở rộng quy mô rất lớn

InfiniBand

Là RDMA nguyên bản.

Không sử dụng Ethernet.

Đặc điểm:

Lossless
Credit-based Flow Control
Latency cực thấp

Các siêu máy tính và cụm GPU hàng đầu thế giới vẫn đang sử dụng InfiniBand.

Xu hướng mới trong AI Data Center

Nếu nhìn vào các AI Cluster hiện đại của NVIDIA, Cisco, Arista, Microsoft hay Meta, chúng ta thấy ba xu hướng rất rõ ràng:

Thứ nhất, Fibre Channel vẫn tiếp tục tồn tại trong các hệ thống lưu trữ doanh nghiệp truyền thống.

Thứ hai, NVMe/TCP đang phát triển rất nhanh nhờ khả năng tận dụng hạ tầng Ethernet sẵn có.

Thứ ba, RoCEv2 đang trở thành giao thức chủ đạo cho AI Networking và AI Storage nhờ khả năng kết hợp giữa hiệu năng RDMA và tính mở rộng của mạng IP.

Đó cũng là lý do vì sao các kỹ sư hạ tầng AI ngày nay không chỉ cần hiểu Ethernet, TCP/IP hay SAN truyền thống, mà còn phải làm quen với các khái niệm mới như RDMA, RoCEv2, PFC, ECN, NVMe-oF và InfiniBand. Đây chính là nền tảng của thế hệ AI Data Center hiện đại.

Lấy slot khóa dcaci online trước khi full

hongnhungvnpro — Sat, 30 May 2026 02:53:26 GMT

LẤY SLOT KHÓA DCACI ONLINE TRƯỚC KHI FULL
Nếu bạn:
• Đã học CCNP nhưng muốn nâng cao chuyên môn hơn
• Nâng tư duy xử lý hệ thống Cisco
• Chuẩn bị cho công việc thực tế
Thì hãy Inbox ngay hôm nay để giữ chỗ khai giảng 03/06.

KHÓA DCACI ONLINE tại VnPro:
Thời gian học: Tối 2-4-6 | 19:30 – 22:00
Học Online trực tiếp cùng giảng viên

SLOT đang dần hết — inbox ngay để được tư vấn lộ trình phù hợp!
--------
Hotline/Zalo: 0933 427 079
Như Ngọc: 076 5944 386
Anh Thư: 033 9943 732
Hồng Nhung: 0383920627

Cisco ACI là gì ?

anhnguyxn — Sat, 30 May 2026 00:39:22 GMT

Cisco ACI (Application Centric Infrastructure) là một kiến trúc mạng data center được Cisco phát triển, ra mắt vào năm 2013. Đây là một trong những nền tảng SDN (Software-Defined Networking) phổ biến nhất trong môi trường enterprise và data center.
Ý tưởng cốt lõi
Thay vì cấu hình từng thiết bị mạng riêng lẻ như truyền thống, ACI cho phép bạn định nghĩa chính sách ứng dụng tập trung rồi fabric tự động triển khai xuống phần cứng. Nói đơn giản: bạn nói "Web server được phép nói chuyện với App server qua port 80", ACI tự lo phần còn lại.
Các thành phần chính

APIC – Controller trung tâm, nơi bạn cấu hình toàn bộ policy qua GUI, CLI, hoặc REST API

Leaf switch – Kết nối trực tiếp với server, thiết bị đầu cuối

Spine switch – Xương sống kết nối các leaf với nhau, chạy underlay IS-IS

Fabric – Toàn bộ hạ tầng vật lý leaf + spine

Điểm khác biệt so với mạng truyền thống
Mạng truyền thống dùng mô hình blacklist (cho phép tất cả, chặn cái nguy hiểm). ACI dùng mô hình whitelist — mặc định chặn tất cả, chỉ cho phép traffic có Contract định nghĩa rõ ràng. Điều này giúp bảo mật tốt hơn rất nhiều trong data center.
Tại sao ACI phổ biến?
Nó giải quyết đồng thời nhiều bài toán: tự động hóa cấu hình, microsegmentation bảo mật, tích hợp với VMware/Kubernetes, và khả năng scale lớn mà vẫn quản lý tập trung.

Lấy slot khóa dcaci online trước khi full

hongnhungvnpro — Thu, 28 May 2026 03:32:38 GMT

gNMI

dangquangminh — Thu, 21 May 2026 00:19:14 GMT

NETCONF, RESTCONF hay gNMI? Khi nào nên dùng cái nào trong thực chiến Network Automation?

Nếu bạn đang bước vào thế giới Network Automation / NetDevOps, sớm hay muộn bạn sẽ gặp câu hỏi này:

"Nên học NETCONF, RESTCONF hay gNMI?"

Thoạt nhìn, cả ba đều là API để nói chuyện với thiết bị mạng. Nhưng trong thực tế, chúng sinh ra cho những triết lý rất khác nhau.

Nhìn vào slide trên, ta thấy ba cột khá giống nhau:

đều có khả năng đọc dữ liệu
đều có khả năng cấu hình
đều có thể xóa cấu hình
một số hỗ trợ subscription / telemetry

Nhưng điểm khác biệt thực sự nằm ở kiến trúc, hiệu năng, khả năng mở rộng, và use case triển khai.

1. Khi nào dùng NETCONF?

NETCONF là "ông anh lớn" trong thế giới network programmability.

Ra đời để giải quyết bài toán:

SSH CLI scripting quá mong manh.

Ví dụ:
show run | include ospf

Nếu vendor đổi format output, script của bạn chết.

NETCONF thay đổi cách tiếp cận.

Thay vì parse text CLI, bạn làm việc với structured data dựa trên YANG model.

NETCONF dùng RPC qua SSH.

Ví dụ operations:

Read:

Write:

Subscription:

Khi nào NETCONF phù hợp?

1. Enterprise automation

Nếu bạn quản lý:

Catalyst
IOS XE
NX-OS
JunOS
các thiết bị hỗ trợ NETCONF/YANG

NETCONF rất hợp.

Ví dụ:

deploy VLAN
push BGP config
configure interfaces
collect operational state

2. Khi cần transaction consistency

NETCONF mạnh ở chỗ transaction model.

Ví dụ:

candidate config
commit
rollback

Điều này cực kỳ quan trọng.

CLI scripting:
config t
interface g1
ip address ...
router ospf ...

Nếu fail ở bước 3?

Thiết bị rơi vào trạng thái half-configured.

NETCONF xử lý tốt hơn nhiều.

3. Khi cần vendor-native model

Cisco IOS XE YANG model.

Juniper YANG model.

Arista YANG model.

Nếu automation bám vendor-specific features → NETCONF ổn.

Khi nào KHÔNG nên dùng NETCONF?

NETCONF không phải lựa chọn lý tưởng nếu: XML fatigue

Payload kiểu:

Automation engineer quen JSON sẽ thấy khá mệt.

High-frequency telemetry

NETCONF không sinh ra cho streaming scale lớn.

Nếu bạn muốn:

thousands metrics/sec
real-time telemetry
hyperscale observability

NETCONF không phải vua.

2. Khi nào dùng RESTCONF?

RESTCONF là nỗ lực đưa network automation gần hơn với web/API ecosystem.

Triết lý:

"Tại sao network engineers phải học RPC XML kỳ quặc?"

RESTCONF dùng HTTP verbs quen thuộc:

Read:
GET

Create:
POST

Update:
PUT
PATCH

Delete:
DELETE

Dữ liệu thường là:
JSON

hoặc XML.

Khi nào RESTCONF phù hợp?

1. Team DevOps / Developers

Nếu team quen:

REST API
Postman
curl
Python requests
JSON

RESTCONF dễ tiếp cận hơn NETCONF rất nhiều.

Ví dụ:
requests.get()
requests.patch()

Rất tự nhiên.

2. Integration nhanh

Ví dụ tích hợp với:

ServiceNow
custom portal
internal orchestrator
CI/CD pipeline

RESTCONF khá tiện.

3. CRUD automation

Các bài toán kiểu:

create interface
modify route
delete VLAN

RESTCONF làm tốt.

Khi nào RESTCONF không lý tưởng?

Transaction model yếu hơn NETCONF

HTTP request mang tính stateless.

Không có cảm giác transaction mạnh như:
candidate
commit
rollback

Streaming telemetry không phải điểm mạnh

Polling:
GET
GET
GET
GET

ở scale lớn = đau khổ.

3. Khi nào dùng gNMI?

Đây là nơi câu chuyện đổi hoàn toàn.

gNMI không chỉ là API config.

Nó là API sinh ra cho cloud-scale networking.

Thế giới:

hyperscaler
data center fabric
streaming telemetry
OpenConfig

Core operations

Read:
GET

Update:
SET update

Replace:
SET replace

Delete:
SET delete

Streaming:
SUBSCRIBE

Khi nào gNMI phù hợp?

1. Streaming telemetry

Đây là killer feature.

Thay vì:

RESTCONF polling:
GET every 30 sec

gNMI:
subscribe once
stream continuously

Khác biệt cực lớn.

Ví dụ collect:

interface counters
BGP state
CPU
memory
route churn
drops
latency

real-time.

2. Large-scale data center

Nếu môi trường:

spine-leaf
EVPN fabric
cloud network
AI infrastructure
Kubernetes networking

gNMI sáng giá hơn.

3. Multi-vendor standardization

gNMI thường đi cùng:
OpenConfig

Thay vì vendor-specific madness.

Ví dụ cùng một model:

Cisco
Arista
Juniper

4. Event-driven automation

Ví dụ:

nếu interface down:
event -> automation trigger

Thay vì polling.

Khi nào KHÔNG nên dùng gNMI?

Learning curve cao hơn

Bạn sẽ gặp:

protobuf
gRPC
OpenConfig paths

Ví dụ:
/interfaces/interface[name=Ethernet1]/state/counters

Không thân thiện với người mới.

Không phải mọi enterprise vendor đều mature như nhau

Support khác nhau giữa platforms.

Vendor matrix cần kiểm tra kỹ.

So sánh thực chiến

Chọn NETCONF nếu:

Bạn cần:

reliable config automation
transaction safety
vendor-native YANG
enterprise automation

Điển hình:

Cisco campus / branch automation.

Chọn RESTCONF nếu:

Bạn cần:

API đơn giản
JSON
web integration
quick automation

Điển hình:

DevOps team tích hợp network vào pipeline.

Chọn gNMI nếu:

Bạn cần:

hyperscale telemetry
streaming data
event-driven automation
cloud/DC fabric observability

Điển hình:

modern DC / AI infra / service provider.

Góc nhìn thực tế

Nếu học Network Automation năm 2026:

NETCONF + RESTCONF = nền tảng bắt buộc.

Vì enterprise vẫn dùng nhiều.

gNMI = hướng tương lai.

Đặc biệt nếu bạn làm:

AI infrastructure
cloud networking
observability
intent-based automation
closed-loop automation

Tóm tắt

Một cách rất đơn giản:

NETCONF = transaction-heavy configuration API

RESTCONF = RESTful network API

gNMI = cloud-scale programmable network interface

Không có cái nào "best".

Chỉ có cái phù hợp với đúng bài toán.

Fiber Optics

dangquangminh — Wed, 20 May 2026 00:44:44 GMT

Chức năng của module quang cắm nóng (Pluggable Optics)

Chức năng duy nhất của module quang (optics) là mở rộng giao diện vật lý từ một thiết bị sang thiết bị khác. Chính ASIC bên trong thiết bị mạng mới là thành phần điều khiển interface.
Vì vậy, điều thực sự quan trọng là năng lực của ASIC và lộ trình phát triển (roadmap) của ASIC, còn vai trò của optics là theo kịp yêu cầu đó — nhưng không tạo ra quá nhiều vấn đề trong quá trình vận hành.

Đây là một slide khá thú vị vì nó đụng vào một hiểu lầm rất phổ biến trong giới network engineering.

Nhiều kỹ sư mạng, đặc biệt khi mới bước vào thế giới Data Center hoặc High-Speed Networking, thường nhìn module quang như một “thành phần thông minh” quyết định năng lực của cổng mạng. Thực tế thì không phải vậy.

Nếu nhìn từ góc độ kiến trúc phần cứng switch/router, interface forwarding logic không nằm trong optics.

Thành phần thực sự xử lý packet là ASIC.

ASIC chịu trách nhiệm cho:

Packet parsing
Forwarding lookup
Buffer management
Queueing
QoS
MACsec
FEC handling
Lane distribution
Speed negotiation logic
Error detection/control plane signaling

Module quang chỉ đóng vai trò media adapter.

Hiểu đơn giản:

ASIC nói:

Tôi tạo ra luồng tín hiệu 100G/400G/800G.

Optics nói:

OK, tôi sẽ biến tín hiệu điện này thành tín hiệu quang và chuyển nó qua fiber.

Ở đầu bên kia:

Optics nhận tín hiệu quang → đổi lại thành tín hiệu điện → ASIC bên kia xử lý.

Nói cách khác:

Optics không phải bộ não. Optics chỉ là cánh tay nối dài.

Một ví dụ thực chiến.

Cisco Nexus 9K có ASIC hỗ trợ 400G.

Điều đó có nghĩa switch có khả năng:

chạy 400Gbps line rate
hỗ trợ breakout
hỗ trợ FEC mode tương ứng
xử lý buffer phù hợp
maintain forwarding performance

Nhưng để mang tín hiệu đó ra ngoài, bạn cần optics phù hợp:

Ví dụ:

QSFP-DD 400G SR8
QSFP-DD 400G DR4
QSFP-DD 400G FR4
QSFP-DD 400G LR4

Lúc này optics chỉ là phương tiện truyền dẫn.

Khác biệt nằm ở:

khoảng cách
loại fiber
wavelength
connector
power budget

Chứ không làm switch “thông minh hơn”.

Đây là lý do trong thiết kế Data Center hiện đại, roadmap thường xoay quanh ASIC trước.

Ví dụ:

Broadcom:

Trident
Tomahawk
Jericho

Cisco:

Silicon One

NVIDIA:

Spectrum

Intel/Barefoot:

Tofino

Người ta hỏi:

ASIC hỗ trợ bao nhiêu Tbps?
buffer bao nhiêu?
latency bao nhiêu?
VXLAN scale?
ECMP scale?
ACL TCAM bao nhiêu?
telemetry capability?
PFC/ECN support?

Ít ai bắt đầu bằng câu:

“Module quang gì?”

Vì optics là lớp implementation detail.

Nhưng slide có một ý cực kỳ thực tế:

optics must keep up without causing too many issues

Đây là nơi vận hành mạng đau đầu nhất.

ASIC mạnh không đủ nếu optics tạo chaos.

Ví dụ thực tế:

1. DOM mismatch

Digital Optical Monitoring báo:

Tx low
Rx low
temperature high
bias current abnormal

ASIC vẫn khỏe nhưng link flap.

2. FEC incompatibility

Ví dụ:

một đầu cần RS-FEC
đầu kia dùng FC-FEC

Kết quả:

link up/down bất thường
CRC tăng mạnh
throughput tệ

3. Breakout incompatibility

ASIC hỗ trợ:

400G → 4x100G

Nhưng optics breakout không match đúng lane mapping.

Kết quả:

interface không lên.

4. Vendor interoperability

Cisco ↔ Arista
Juniper ↔ Cisco
Whitebox ↔ OEM optics

Lý thuyết chuẩn mở.

Thực tế:

EEPROM check fail
unsupported transceiver
DOM parse lỗi

5. Power/thermal constraints

800G optics tiêu thụ điện rất lớn.

Ví dụ:

15W–25W/module hoặc hơn.

Nếu chassis thermal design không phù hợp:

overheating
port shutdown
optics reset

Kết luận:

Trong networking truyền thống, người ta hay nghĩ:

“Module quang quyết định tốc độ.”

Nhưng góc nhìn kiến trúc đúng hơn là:

ASIC quyết định khả năng xử lý. Optics chỉ giúp khả năng đó đi xa hơn.

Một câu dễ nhớ:

ASIC defines capability. Optics define reach.

Đây chính là tư duy rất quan trọng khi bước vào thiết kế:

modern data center
AI fabric
spine-leaf
400G/800G Ethernet
hyperscale networking

Mpls

dangquangminh — Mon, 18 May 2026 12:41:13 GMT

MPLS trong Data Center và Cloud: Một công nghệ cũ trong thế giới mới?

Có những công nghệ trong ngành mạng mà chỉ cần nhắc tên, người ta lập tức nghĩ đến sự ổn định, quy mô lớn và độ tin cậy cấp nhà mạng. MPLS là một trong số đó.

Trong suốt nhiều năm, MPLS gần như là nền tảng mặc định cho các mạng WAN doanh nghiệp lớn và hạ tầng của các nhà cung cấp dịch vụ. Khi doanh nghiệp cần kết nối nhiều chi nhánh, cần VPN lớp 3, cần điều khiển lưu lượng hoặc đảm bảo chất lượng dịch vụ, MPLS gần như luôn là câu trả lời đầu tiên.

Nhưng ngành công nghệ chưa bao giờ đứng yên.

Sự trỗi dậy của Data Center hiện đại, điện toán đám mây, ảo hóa, mô hình spine-leaf và các giao thức overlay mới đã đặt ra một câu hỏi đáng suy nghĩ: liệu MPLS có còn vị trí trong Data Center và Cloud, hay đây là lãnh địa của những công nghệ mới hơn? Những lý do khiến MPLS không phải lựa chọn mặc định

Một trong những khác biệt lớn nhất giữa mạng WAN truyền thống và Data Center hiện đại nằm ở đội ngũ vận hành.

Trong môi trường WAN, MPLS là công nghệ quen thuộc. Các kỹ sư mạng thường xuyên làm việc với label switching, LDP, VRF, MP-BGP và các mô hình VPN phức tạp. Nhưng trong thế giới Data Center, tư duy vận hành đã thay đổi.

Các đội ngũ Data Center thường quen với Ethernet switching, IP routing, virtualization và gần đây là VXLAN EVPN. Với họ, MPLS không phải công nghệ “bản địa”.

Điều này tạo ra một rào cản rất thực tế. Một công nghệ mạnh không đồng nghĩa với một công nghệ phù hợp nếu đội ngũ vận hành không sẵn sàng tiếp nhận nó.

Vấn đề thứ hai đến từ chính kiến trúc hạ tầng.

Các Data Center hiện đại thường được xây dựng theo mô hình spine-leaf với underlay thuần IP. Những kiến trúc này ưu tiên sự đơn giản, khả năng mở rộng và cân bằng tải theo ECMP.

Trong mô hình như vậy, MPLS không phải là thành phần tự nhiên. Muốn đưa MPLS vào, tổ chức phải bổ sung thêm một lớp điều khiển mới, cơ chế phân phối nhãn mới và toàn bộ logic vận hành đi kèm. Điều đó đồng nghĩa với chi phí vận hành cao hơn và độ phức tạp lớn hơn.

Ngoài ra, thế giới WAN cũng đã thay đổi.

Nếu như trước đây MPLS gần như là xương sống mặc định của WAN, thì hiện nay nhiều doanh nghiệp đã chuyển sang các mô hình IP overlay như SD-WAN, GRE over Internet hoặc các giải pháp VPN linh hoạt hơn.

Nếu WAN không còn dựa hoàn toàn vào MPLS, lý do để kéo MPLS sâu vào Data Center cũng giảm đi đáng kể.

Một điểm đáng chú ý khác là traffic engineering, vốn từng là một trong những lợi thế lớn nhất của MPLS.

Trong WAN truyền thống, việc điều khiển chính xác đường đi của lưu lượng là rất quan trọng. Nhưng trong Data Center hiện đại, traffic thường di chuyển theo mô hình east-west, với nhiều đường song song có chi phí bằng nhau. ECMP đã giải quyết khá hiệu quả bài toán phân phối lưu lượng.

Trong nhiều trường hợp, MPLS traffic engineering trở thành một cơ chế quá mạnh cho một bài toán vốn không còn quá phức tạp. Vậy tại sao vẫn có người muốn dùng MPLS?

Dù vậy, sẽ là sai lầm nếu cho rằng MPLS đã hết thời.

Thực tế, trong nhiều môi trường, MPLS vẫn là lựa chọn hợp lý.

Lý do đầu tiên là yếu tố kế thừa.

Nhiều doanh nghiệp lớn đã đầu tư đáng kể vào MPLS WAN. Họ có đội ngũ hiểu MPLS, có hệ thống giám sát phù hợp, có quy trình xử lý sự cố đã được chuẩn hóa.

Trong bối cảnh đó, mở rộng tư duy MPLS sang Data Center không phải điều vô lý. Nó giúp giảm khoảng cách giữa WAN và DC, đồng thời tạo ra một kiến trúc nhất quán hơn.

Lý do thứ hai là kinh nghiệm vận hành.

Một đội ngũ đã quen MPLS đôi khi sẽ cảm thấy thoải mái hơn với MPLS so với việc phải tiếp cận một stack hoàn toàn mới như VXLAN EVPN.

Công nghệ mới không phải lúc nào cũng đơn giản hơn. Chỉ là nó phù hợp hơn với một số bối cảnh nhất định.

Ngoài ra, MPLS hiện đại không còn giống hoàn toàn MPLS của nhiều năm trước.

Với Segment Routing, MPLS đã bước vào một giai đoạn linh hoạt hơn, nơi việc định tuyến lưu lượng có thể mang tính lập trình cao hơn, phù hợp hơn với các yêu cầu điều khiển lưu lượng theo ứng dụng.

Đặc biệt, khi nói đến multi-tenancy và tách biệt dịch vụ, MPLS vẫn là một nền tảng rất mạnh.

Những môi trường như nhà cung cấp dịch vụ, NFV hay telco cloud vẫn có nhiều lý do để tiếp tục gắn bó với MPLS. Góc nhìn thực tế

Nếu nhìn từ doanh nghiệp thông thường, câu trả lời khá rõ ràng.

Phần lớn Data Center hiện đại đang đi theo hướng VXLAN EVPN.

Công nghệ này phù hợp với virtualization, hỗ trợ multi-tenant tốt, mở rộng linh hoạt và tương thích tự nhiên với mô hình cloud-native.

Nhưng nếu nhìn từ góc độ service provider, bức tranh lại khác.

MPLS không phải di sản cũ kỹ cần loại bỏ. Nó là nền tảng đã được kiểm chứng ở quy mô rất lớn, với khả năng tách biệt dịch vụ và điều khiển lưu lượng cực kỳ mạnh.

Do đó, câu hỏi không nên là MPLS còn sống hay đã chết.

Câu hỏi đúng hơn là: môi trường của bạn cần điều gì?

Bởi trong ngành mạng, một công nghệ tốt không phải công nghệ mới nhất.

Một công nghệ tốt là công nghệ phù hợp nhất với bài toán cần giải quyết.

Cách khắc phục sự cố của Switch

dangquangminh — Wed, 13 May 2026 11:16:54 GMT

Khắc phục sự cố hiệu năng trên switch Cisco Catalyst: Bắt đầu từ đâu?

Một trong những tình huống “khó chịu” nhất đối với kỹ sư mạng là nhận được phản ánh kiểu: “Mạng hôm nay chậm quá!”

Nghe thì đơn giản, nhưng đây lại là một trong những dạng sự cố khó xử lý nhất. Vì sao? Bởi chữ “chậm” thường mang tính cảm nhận (subjective). Với người dùng, “chậm” có thể chỉ đơn giản là ứng dụng mở lâu hơn họ mong đợi 2–3 giây. Nhưng cũng có thể đó là dấu hiệu thật sự của một vấn đề nghiêm trọng đang làm giảm hiệu suất toàn hệ thống.

Điều đầu tiên trong troubleshooting không phải là lao ngay vào switch, mà là trả lời câu hỏi:

“Chậm do network, hay do endpoint/application?”

Rất nhiều trường hợp, switch hoàn toàn bình thường, nhưng nguyên nhân thật sự lại nằm ở:

máy client bị quá tải CPU/RAM
server phản hồi chậm
ứng dụng bị bottleneck
database xử lý kém
storage latency cao

Nói cách khác, network thường bị nghi ngờ đầu tiên, nhưng không phải lúc nào cũng là thủ phạm.

Khi đã xác định switch là nguyên nhân

Nếu quá trình phân tích xác nhận rằng hiệu năng mạng đang thấp hơn mức kỹ thuật kỳ vọng (không chỉ là cảm giác người dùng), và thiết bị gây ra vấn đề là một Cisco Catalyst switch, thì lúc này mới bắt đầu troubleshooting ở cấp độ switch.

Cần lưu ý rằng Cisco có rất nhiều dòng Catalyst khác nhau:

Catalyst 2960
Catalyst 3560
Catalyst 3850
Catalyst 9300
Catalyst 9500
Catalyst 9600

Mỗi platform có:

mật độ cổng (port density) khác nhau
switching capacity khác nhau
forwarding ASIC khác nhau
kiến trúc phần cứng khác nhau

Vì vậy troubleshooting luôn mang tính platform-dependent.

Tuy nhiên, hầu hết Cisco Catalyst switch đều có cùng các thành phần cốt lõi.

Các thành phần quan trọng trong Cisco Catalyst Switch

1. Ports (Interfaces)

Đây là thành phần dễ hình dung nhất.

Port là nơi switch kết nối vật lý với các thiết bị khác:

PC
server
router
firewall
access point
switch khác

Port thực hiện hai chức năng:

nhận traffic vào (ingress)
gửi traffic ra (egress)

Ví dụ:

PC gửi frame vào cổng Gi1/0/10 → đây là ingress port.

Switch quyết định chuyển tiếp frame sang Gi1/0/24 → đây là egress port.

Nếu port gặp lỗi vật lý, hiệu năng sẽ bị ảnh hưởng ngay lập tức.

2. Forwarding Logic

Đây là “bộ não chuyển mạch” ở data plane.

Switch không forward frame ngẫu nhiên. Nó dựa trên các bảng thông tin như:

MAC address table
VLAN information
CAM table
TCAM entries
QoS forwarding policies
ACL lookup

Ví dụ:

Switch nhận frame có destination MAC:
00:11:22:33:44:55

Nó tra CAM table:
00:11:22:33:44:55 → Gi1/0/24

Sau đó forwarding logic quyết định:

“Gửi frame ra Gi1/0/24.”

Nếu forwarding logic bị quá tải hoặc resource lookup gặp vấn đề, switch performance sẽ giảm.

3. Backplane

Backplane là “xa lộ nội bộ” của switch.

Khi traffic đi qua switch:
Ingress Port → Backplane → Egress Port

Backplane kết nối tất cả các port vật lý bên trong thiết bị.

Ví dụ:

Một switch 48-port Gigabit Ethernet.

Nếu nhiều port cùng truyền traffic đồng thời, tất cả đều chia sẻ switching fabric/backplane bandwidth.

Nếu switch có:
Switching capacity = 176 Gbps

thì tổng traffic vượt mức này sẽ gây congestion.

Kết quả:

packet drops
latency tăng
throughput giảm

4. Control Plane

Đây là nơi chứa:

CPU
memory
operating system

Control plane chịu trách nhiệm:

chạy Cisco IOS / IOS XE
xây MAC address table
xử lý STP
xử lý routing protocols
xử lý management traffic
xử lý ARP
xử lý control packets

Ví dụ:

Switch phải xử lý:

STP BPDUs
CDP
LLDP
ARP requests
routing updates

Tất cả đều dùng CPU.

Control Plane có ảnh hưởng hiệu năng không?

Thoạt nhìn thì có vẻ không.

Vì forwarding frame chủ yếu do ASIC ở data plane xử lý.

Nhưng thực tế thì có ảnh hưởng gián tiếp rất lớn.

Lý do:

Forwarding hardware không tự “nghĩ”.

Nó nhận logic từ control plane.

Ví dụ:

Control plane xây:

MAC table
spanning tree topology
routing information

Data plane chỉ dùng thông tin này để forward.

Nếu control plane bị stress:

CPU 95–100%
memory cạn
process overload

thì hậu quả:

MAC learning chậm
topology recalculation chậm
ARP processing delay
protocol instability

=> performance toàn switch giảm.

Khi forwarding hardware bị full

Bình thường:
ASIC handles forwarding

Nhanh, wire-speed.

Nhưng nếu hardware resource đạt cực hạn:

CAM exhausted
TCAM full
forwarding engine overloaded

thì một phần traffic có thể bị punt lên CPU.

Lúc này:
Data plane → Control plane

CPU phải tham gia forwarding.

Đây là kịch bản rất nguy hiểm vì CPU forwarding chậm hơn ASIC rất nhiều.

Ví dụ:

ASIC xử lý:
millions of packets per second

CPU xử lý:

ít hơn rất nhiều.

Kết quả:

latency spike
packet loss
switch appears slow

Hai mục tiêu troubleshooting phổ biến nhất

Theo thực tế vận hành Cisco Catalyst, hai điểm kiểm tra đầu tiên khi nghi ngờ switch performance là: Port Errors

Các lỗi vật lý ở interface thường là nguyên nhân cực phổ biến.

Ví dụ:
show interfaces

Bạn có thể thấy:

input errors
CRC
frame errors
runts
giants
overruns
ignored
output drops

Ví dụ CRC tăng:

thường liên quan:

cáp lỗi
SFP lỗi
electromagnetic interference
bad patch panel

Duplex Mismatch

Một classic issue.

Ví dụ:

Switch:
Full duplex

Thiết bị đối diện:
Half duplex

Kết quả:

collisions
late collisions
retransmissions
throughput cực thấp

Biểu hiện:

Người dùng than:

“Mạng chậm bất thường nhưng không down.”

Kiểm tra:
show interfaces status
show interfaces

Tư duy troubleshooting đúng

Đừng bắt đầu bằng assumption:

“Switch chậm.”

Hãy đi theo flow:

Bước 1

Xác nhận vấn đề thật sự tồn tại:

latency?
packet loss?
throughput drop?

Bước 2

Xác định domain:

client?
server?
application?
network?

Bước 3

Nếu là switch:

kiểm tra:

interface health
duplex/speed
CPU
memory
CAM/TCAM
STP events
drops
ASIC counters

Một kỹ sư mạng giỏi không chỉ biết gõ lệnh.

Họ biết xác định đúng nơi cần nhìn trước tiên.