Vietnamese Professional - CCNP ENTERPRISE®

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.

Bảo Mật Data Center: Muốn An Toàn Phải Bắt Đầu Từ 3 Yếu Tố Nền Tảng

dangquangminh — Sat, 06 Jun 2026 11:24:02 GMT

Bảo Mật Data Center: Muốn An Toàn Phải Bắt Đầu Từ 3 Yếu Tố Nền Tảng

Khi nói đến bảo mật trung tâm dữ liệu (Data Center Security), nhiều người thường nghĩ ngay đến Firewall, IPS hay các giải pháp chống mã độc. Tuy nhiên, trong thực tế, những hệ thống Data Center hiện đại thường được xây dựng dựa trên ba trụ cột quan trọng hơn nhiều:

1. Visibility – Khả năng quan sát toàn diện

"See Everything" – Nhìn thấy mọi thứ. Bạn không thể bảo vệ những gì mình không nhìn thấy. Một hệ thống Data Center hiện đại cần có khả năng quan sát đầy đủ người dùng (Users), thiết bị (Devices), Mạng (Networks), Ứng dụng (Applications), Workload, Quy trình xử lý (Processes). Mục tiêu là xây dựng một bức tranh hoàn chỉnh về những gì đang diễn ra trong hạ tầng. Ví dụ:

Máy chủ nào đang giao tiếp với máy chủ nào?

Ứng dụng nào đang sử dụng cơ sở dữ liệu?

Workload nào đang phát sinh lưu lượng bất thường?

Người dùng nào đang truy cập tài nguyên nhạy cảm?

Đây chính là nền tảng của các giải pháp như Telemetry, NetFlow, IPFIX, SIEM, NDR, Cisco Secure Network Analytics (Stealthwatch), Splunk hay Elastic.

2. Segmentation – Phân đoạn để giảm bề mặt tấn công

"Reduce the Attack Surface" – Thu hẹp vùng tấn công
Ngày nay, hacker hiếm khi tấn công trực tiếp vào hệ thống quan trọng ngay từ đầu. Kịch bản phổ biến hơn là:

Xâm nhập một máy chủ ít quan trọng

Leo thang đặc quyền

Di chuyển ngang (Lateral Movement)

Từng bước tiếp cận các tài sản giá trị

Đây chính là lý do Segmentation trở thành một thành phần cốt lõi trong kiến trúc Zero Trust. Các kỹ thuật thường gặp VLAN Segmentation, VRF Segmentation, VXLAN EVPN Segmentation, Security Groups, Application Whitelisting, Micro-Segmentation
Micro-Segmentation đặc biệt quan trọng trong môi trường Cloud và Data Center hiện đại. Ví dụ Máy chủ Web chỉ được phép giao tiếp với Application Server. Application Server chỉ được phép truy cập Database Server. Ngay cả khi hacker chiếm được Web Server, khả năng di chuyển sang các vùng khác cũng bị hạn chế đáng kể.

3. Threat Protection – Phát hiện và ngăn chặn mối đe dọa

"Stop the Breach" – Chặn đứng cuộc tấn công
Không có hệ thống nào an toàn tuyệt đối. Vì vậy, ngoài việc nhìn thấy và phân đoạn, doanh nghiệp cần khả năng phát hiện sớm, phân tích hành vi bất thường, ngăn chặn tự động, phản ứng nhanh với sự cố. Các công nghệ thường được triển khai NGFW (Next-Generation Firewall), IDS/IPS, EDR/XDR, NDR, Sandbox, SIEM/SOAR, AI-based Threat Detection... Mục tiêu là phát hiện và ngăn chặn cuộc tấn công trước khi kẻ tấn công có thể đánh cắp dữ liệu, mã hóa dữ liệu (Ransomware), phá hoại hoạt động kinh doanh, làm gián đoạn dịch vụ. Góc nhìn thực chiến

Trong nhiều vụ tấn công lớn, nguyên nhân thất bại không phải do thiếu Firewall hay thiếu công cụ bảo mật. Vấn đề thường nằm ở chổ chúng ta không có khả năng quan sát đầy đủ hệ thống, thiếu phân đoạn mạng và ứng dụng, phát hiện quá muộn khi kẻ tấn công đã di chuyển ngang trong hệ thống. Do đó, một chiến lược bảo mật Data Center hiệu quả thường đi theo trình tự Visibility → Segmentation → Threat Protection. Đầu tiên phải nhìn thấy hệ thống. Sau đó thu hẹp phạm vi tấn công. Cuối cùng mới tập trung phát hiện và ngăn chặn mối đe dọa. Đây cũng chính là nền tảng của các kiến trúc bảo mật hiện đại như Zero Trust, Cisco Secure Data Center, Software-Defined Segmentation và Cloud Security Architecture ngày nay.

Bức tranh toàn cảnh về Cisco Cyber Threat Defense: Vượt qua tư duy Firewall truyền thống

Lương Thị Thùy — Sat, 06 Jun 2026 09:41:35 GMT

Thời đại vứt một con Firewall ở vùng biên (perimeter) rồi kê cao gối ngủ đã qua rất lâu rồi. Ngày nay, với bối cảnh mạng phức tạp và các luồng dữ liệu đan xen, câu hỏi thực tế không còn là "Liệu hacker có xuyên thủng được hệ thống của chúng ta không?", mà là "Khi chúng lọt vào rồi, mất bao lâu để hệ thống của chúng ta phát hiện ra, và dập dịch bằng cách nào?".
Bài viết này mình sẽ tổng hợp lại các mảnh ghép kỹ thuật cốt lõi trong kiến trúc Cisco Cyber Threat Defense. Mục tiêu tối thượng của kiến trúc này là khám phá, ngăn chặn và khắc phục các mối đe dọa ngay khi chúng đã xâm nhập vào mạng nội bộ.

1. "Mắt thần" giám sát hành vi: NetFlow và StealthWatch

Anh em làm mạng chắc không xa lạ gì với NetFlow. Ban đầu nó sinh ra để đo lường băng thông, hiệu suất ứng dụng và mức độ sử dụng. Nhưng trong bảo mật hiện đại, nó là nguồn cấp dữ liệu đo lường từ xa (telemetry) sống còn.
Kết hợp NetFlow với hệ thống StealthWatch, chúng ta có một giải pháp phân tích ngữ cảnh của người dùng và luồng dữ liệu (user and flow context analysis) cực kỳ mạnh mẽ. StealthWatch không nhìn vào chữ ký (signature) tĩnh, nó sử dụng dữ liệu telemetry, thông tin ngữ cảnh và độ tin cậy của tệp để:

Cung cấp nhận thức theo thời gian thực về người dùng, thiết bị và lưu lượng truy cập.
Phân tích hành vi mạng để phát hiện sự bất thường.
Trở thành công cụ đắc lực cho phản hồi sự cố và điều tra mạng (forensics).

2. Đối phó với Zero-Day bằng Hệ thống Ngăn chặn Xâm nhập (NIPS)

Lỗ hổng zero-day là ác mộng vì không có bản vá và hệ thống phòng thủ truyền thống hoàn toàn "mù" trước chúng. Vậy triển khai gì ở vành đai để chống lại thứ chưa từng được biết đến?
Câu trả lời chính là NIPS (Network Intrusion Protection System), thường được tích hợp trong các giải pháp như Firepower Threat Defense (FTD).
Lợi thế của NIPS là nó không chỉ trút phế liệu vào các cơ sở dữ liệu mối đe dọa tĩnh như Antivirus. Nó hoạt động bằng cách giám sát các mô hình hoạt động mạng hàng ngày. Khi phát hiện lưu lượng hoặc sự kiện nằm ngoài mức bình thường (anomaly), nó có thể lập tức đưa ra cảnh báo hoặc khóa tường lửa, bảo vệ hệ thống khỏi các mối đe dọa được đưa vào từ cả nguồn bên ngoài lẫn bên trong (như cắm USB lạ).

3. Quản lý Danh tính và Cách ly Tự động (ISE & pxGrid)

Phát hiện ra bất thường rồi thì làm gì tiếp theo? Chạy đi rút dây mạng?
Ở quy mô Enterprise, chúng ta dựa vào Cisco Identity Services Engine (ISE). ISE không chỉ lo việc xác thực (như 802.1x, MAB, WebAuth), mà nó còn tích hợp trực tiếp danh tính thiết bị và người dùng với hệ thống phân tích như StealthWatch.
Khi StealthWatch phát hiện một luồng mạng bất thường từ một thiết bị, nó có thể thông qua nền tảng pxGrid để yêu cầu ISE thay đổi ngay lập tức chính sách truy cập của thiết bị đó (ví dụ: đẩy vào VLAN cách ly hoặc chặn hoàn toàn cổng mạng). Đây chính là sức mạnh của tự động hóa trong khắc phục sự cố.

4. Bảo vệ Điểm cuối và Bảo mật Ứng dụng/API

Ngoài mạng lõi, chúng ta không thể bỏ qua các rào chắn chuyên biệt cho từng bề mặt tấn công:

Bảo vệ Điểm cuối (Endpoint): Giải pháp EDR (Endpoint Detection and Response) như AMP4E (Advanced Malware Protection For Endpoints) cung cấp khả năng phát hiện và phản hồi dựa trên ngăn chặn, thông tin tình báo về mối đe dọa và công nghệ học máy (machine learning).
Email & Web (ESA & WSA/Umbrella): Cisco Email Security Appliance (ESA) kiểm soát động các hình thức đe dọa qua email. Trong khi đó, Web Security Appliance (WSA) chặn đứng các hoạt động web đáng ngờ và Umbrella lo việc bảo vệ ở cấp độ DNS.
Bảo vệ API và Ứng dụng Web: Trong kỷ nguyên Cloud và Microservices, API là cửa ngõ giao tiếp sống còn. Để bảo mật các nền tảng API, ứng dụng di động và website luôn "always on", Web Application Firewalls (WAF) kết hợp cùng tính năng bảo vệ khỏi bot là lá chắn bắt buộc phải có, thay vì chỉ dựa vào firewall L3/L4 truyền thống.

Anh em đang triển khai mô hình Threat Defense ở công ty theo hướng nào? Có đang tận dụng tối đa NetFlow/StealthWatch để bắt anomaly không, hay vẫn đang phụ thuộc nhiều vào tập luật tĩnh của Firewall/IPS?

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.

Kibana

dangquangminh — Sat, 06 Jun 2026 08:08:07 GMT

Distributed Logging: Kiến trúc 5 tầng giúp quan sát hệ thống Microservices hiệu quả

Khi hệ thống còn là Monolith, logging thường chỉ đơn giản là ghi dữ liệu vào file trên máy chủ. Nhưng khi chuyển sang kiến trúc Microservices, Cloud Native và Kubernetes, hàng chục hoặc hàng trăm service có thể tạo ra hàng triệu log mỗi ngày. Lúc này, logging không còn là một tính năng phụ trợ mà đã trở thành một thành phần cốt lõi của tính khả kiến Observability. Một hệ thống Distributed Logging được thiết kế đúng cách thường chia thành 5 giai đoạn chính.

1. Collection Stage – Thu thập log

Đây là bước đầu tiên của toàn bộ quy trình. Các Collector Agent được triển khai gần nguồn sinh log nhất, thường nằm trên các máy chủ vật lý, máy ảo, Container, Kubernetes Node. Collector có thể hoạt động theo nhiều cách như theo dõi file log, theo dõi sự thay đổi của file, cung cấp API để ứng dụng gửi log hoặc Subscribe vào các nguồn log. Mục tiêu của giai đoạn này là thu thập dữ liệu càng gần nguồn phát sinh càng tốt.

2. Forwarding Stage – Chuyển tiếp log

Sau khi thu thập, log sẽ được gửi đến một Log Aggregator.
Log Aggregator đóng vai trò tập trung dữ liệu từ nhiều nguồn khác nhau như từ Application, từ Database, từ Operating System, Web Server, Event Queue... Đây là bước biến hàng trăm nguồn log phân tán thành một luồng dữ liệu tập trung.

3. Storage Stage – Lưu trữ log

Các log sau đó được ghi vào hệ thống lưu trữ. Tùy theo quy mô hệ thống, nơi lưu trữ có thể là Local Storage, Shared Storage, Object Storage, Distributed File System. Tại đây doanh nghiệp thường thiết lập các chính sách Retention Period, Log Rotation, Data Lifecycle, Archiving Policy... Ví dụ các bạn có thể thấy các chính sách như Giữ log vận hành trong 30 ngày, giữ log bảo mật trong 1 năm, chuyển log cũ sang Object Storage giá rẻ....

4. Indexing Stage – Đánh chỉ mục

Đây là bước giúp việc tìm kiếm log trở nên thực tế. Thay vì đọc từng file log thủ công, hệ thống sẽ tạo chỉ mục theo Thời gian, Ứng dụng, theo địa chỉ Máy chủ, Mức độ nghiêm trọng, Correlation ID...
Sau khi được đánh chỉ mục, các công cụ như Elasticsearch có thể thực hiện Full Text Search, Analytics, Dashboard, Trend Analysis
trong thời gian gần như tức thì.

5. Alerting Stage – Cảnh báo

Đây là tầng thông minh nhất của hệ thống logging. Nó liên tục phân tích log để phát hiện các lỗi bất thường, các tấn công bảo mật, Service bị gián đoạn, tăng đột biến lưu lượng, Không nhận được log từ một máy chủ nào đó. ...Khi phát hiện sự kiện bất thường, hệ thống có thể thực hiện các hành động như Gửi Email, Gửi Slack, Gửi Teams, Tạo Incident Ticket, Kích hoạt Automation Workflow....

Những Best Practice quan trọng trong Distributed Logging

Chuẩn hóa nền tảng logging

Trong môi trường Microservices, các nhóm phát triển có thể sử dụng Java, Python, Go, Node.js. Tuy nhiên nền tảng logging nên được thống nhất. Nếu mỗi service sử dụng một giải pháp logging khác nhau, việc quản lý và phân tích log sẽ trở nên cực kỳ phức tạp.

Sử dụng Correlation ID

Một giao dịch có thể đi qua:
User → API Gateway → Service A → Service B → Database
Nếu không có Correlation ID, việc truy vết lỗi gần như là ác mộng.
Correlation ID được gắn vào mọi log liên quan đến cùng một request để dễ dàng theo dõi toàn bộ hành trình của giao dịch.
Đây là kỹ thuật gần như bắt buộc trong kiến trúc Microservices hiện đại.

Không tin tưởng nhiều nguồn thời gian

Một vấn đề rất hay gặp là lệch giờ giữa các máy chủ.
Ví dụ:
09:01:05 User được cập nhật
09:01:03 User được tạo
Rõ ràng đây là điều vô lý. Để tránh hiện tượng này, toàn bộ hạ tầng cần đồng bộ thời gian bằng NTP, Chrony, Enterprise Time Service
Và tốt nhất nên xem một nguồn thời gian là "nguồn sự thật" duy nhất.

Luôn giả định hệ thống logging sẽ hỏng

Đây là tư duy DevOps rất quan trọng. Logging Server cũng là một dịch vụ và hoàn toàn có thể gặp sự cố. Collector Agent nên tự Buffer dữ liệu, Cache cục bộ, Retry khi kết nối phục hồi. Nếu không, bạn sẽ mất chính những log quan trọng nhất vào lúc hệ thống gặp sự cố.

Ghi log có ngữ cảnh

Thông báo lỗi kiểu Error occurred gần như vô dụng vì chúng không cung cấp thông tin hữu ích. Một log tốt nên bao gồm:

Timestamp

Service Name

Function Name

Correlation ID

Stack Trace

Client IP

User Agent

Error Details

Thông tin ngữ cảnh càng đầy đủ thì thời gian xử lý sự cố càng giảm.

Hỗ trợ Query Log

Giá trị thực sự của logging không nằm ở việc lưu trữ log mà nằm ở khả năng trả lời câu hỏi. Ví dụ:

Service nào lỗi nhiều nhất trong giờ cao điểm?

API nào có thời gian phản hồi lâu nhất?

Người dùng từ quốc gia nào tạo nhiều lỗi nhất?

Sau khi deploy phiên bản mới thì tỷ lệ lỗi thay đổi ra sao?

Muốn trả lời được các câu hỏi này, hệ thống phải hỗ trợ truy vấn dữ liệu hiệu quả.

ELK Stack – Bộ công cụ phổ biến nhất cho Distributed Logging

Một trong những giải pháp được sử dụng rộng rãi nhất hiện nay là ELK Stack. ELK bao gồm ba thành phần chính:
Elasticsearch
Là công cụ lưu trữ, tìm kiếm và phân tích dữ liệu dựa trên Apache Lucene. Khả năng Full Text Search cực kỳ mạnh mẽ giúp truy vấn hàng tỷ bản ghi log.
Logstash
Là tầng thu thập và xử lý log. Logstash nhận dữ liệu từ nhiều nguồn, chuyển đổi định dạng và chuyển tiếp đến hệ thống lưu trữ.
Kibana
Là giao diện trực quan hóa. Kibana cho phép Xây dựng Dashboard, Theo dõi thời gian thực, Điều tra sự cố, Phân tích xu hướng.
Ngoài ra ELK còn sử dụng các Collector Agent gọi là Beats.
Phổ biến nhất gồm:

Filebeat: Thu thập log file

Metricbeat: Thu thập CPU, Memory, Disk, Process

Packetbeat: Thu thập lưu lượng mạng

Auditbeat: Thu thập sự kiện bảo mật

Luồng xử lý thường là:
Application
↓
Beats
↓
Logstash
↓
Elasticsearch
↓
Kibana

Góc nhìn DevOps

Nếu phải chọn một thuộc tính quan trọng nhất của Distributed Logging, câu trả lời không phải là định dạng dữ liệu, tính toàn vẹn dữ liệu hay khả năng tìm kiếm. Đó là Data Aggregation.
Bởi vì giá trị lớn nhất của Distributed Logging là đưa toàn bộ log từ hàng trăm hệ thống khác nhau về một nơi duy nhất. Chỉ khi dữ liệu được tập trung, chúng ta mới có thể thực hiện tìm kiếm, phân tích, cảnh báo và điều tra sự cố một cách hiệu quả.
Đây cũng chính là lý do mà trong các nền tảng DevOps, SRE, AIOps và DevSecOps hiện đại, hệ thống Logging luôn được xem là một phần không thể thiếu của nền tảng Observability.

Nguyên Lý Hoạt Động Của Mạng Wi-Fi Doanh Nghiệp Cisco

dangquangminh — Sat, 06 Jun 2026 07:29:45 GMT

Cisco Unified Wireless – Nguyên Lý Hoạt Động Của Mạng Wi-Fi Doanh Nghiệp Cisco

Khi mới tiếp cận hệ thống Wi-Fi doanh nghiệp của Cisco, nhiều người thường nghĩ rằng Access Point (AP) là thành phần quan trọng nhất. Thực tế, trong kiến trúc Cisco Unified Wireless, AP chỉ là một phần của một hệ sinh thái lớn hơn bao gồm Access Point, Wireless LAN Controller (WLC), hệ thống quản lý, phân tích vị trí và các dịch vụ ứng dụng.

Hình trên mô tả kiến trúc Cisco Unified Wireless theo mô hình phân lớp.

1. Access Point – Thiết Bị Phát Sóng Không Dây

Access Point là thành phần tiếp xúc trực tiếp với thiết bị người dùng như laptop, điện thoại hoặc máy quét mã vạch.

Ngoài việc phát sóng Wi-Fi, các AP Cisco Aironet còn cung cấp nhiều tính năng nâng cao:

CleanAir phát hiện và giảm nhiễu RF
Hyperlocation hỗ trợ định vị chính xác trong nhà
Client Coverage tối ưu vùng phủ sóng
Flexible Radio Assignment (FRA) tự động điều chỉnh radio
Over-the-Air Encryption mã hóa lưu lượng điều khiển giữa AP và WLC

AP chịu trách nhiệm xử lý tầng vật lý (PHY) và tầng MAC của chuẩn 802.11, trong khi nhiều chức năng điều khiển được chuyển lên Controller.

2. Wireless LAN Controller (WLC) – Bộ Não Của Hệ Thống Wi-Fi

Trong mô hình Unified Wireless, các AP thường hoạt động ở chế độ Lightweight AP và kết nối đến WLC thông qua giao thức CAPWAP.

WLC thực hiện các nhiệm vụ:

Quản lý tập trung hàng trăm hoặc hàng nghìn AP
Radio Resource Management (RRM)
Client Mobility (roaming giữa các AP)
Chính sách bảo mật
High Availability (HA)
Quản lý WLAN, SSID và VLAN

Nhờ WLC, người quản trị không cần cấu hình từng AP riêng lẻ mà chỉ cần cấu hình tập trung từ Controller.

Ví dụ:

Tạo SSID "Corporate"
Gán VLAN 100
Áp dụng WPA3-Enterprise

Toàn bộ AP trong hệ thống sẽ tự động nhận cấu hình.

3. Network Management – Cisco Prime và Cisco DNA Center

Lớp tiếp theo là hệ thống quản trị mạng.

Trước đây Cisco sử dụng:

Cisco Prime Infrastructure

Hiện nay Cisco chuyển sang:

Cisco Catalyst Center (trước đây là Cisco DNA Center)

Các nền tảng này cung cấp:

Automation
Assurance
Monitoring
Reporting
Inventory Management
Configuration Management

Đây là nơi quản trị viên theo dõi toàn bộ mạng campus từ một giao diện duy nhất.

4. MSE / CMX – Dịch Vụ Định Vị Và Phân Tích

Một điểm rất mạnh của hệ sinh thái Cisco Wireless là khả năng định vị thiết bị.

Các nền tảng như:

MSE (Mobility Services Engine)
CMX (Connected Mobile Experiences)

Cho phép:

Theo dõi vị trí thiết bị theo thời gian thực
Phân tích lưu lượng người dùng
Heatmap
Location Analytics
Asset Tracking

Ứng dụng thực tế:

Bệnh viện theo dõi xe đẩy y tế
Nhà máy theo dõi thiết bị sản xuất
Sân bay theo dõi luồng hành khách
Trung tâm thương mại phân tích hành vi khách hàng

5. Services Layer – Tầng Dịch Vụ Giá Trị Gia Tăng

Đây là lớp cao nhất trong kiến trúc.

Thông tin thu thập từ mạng Wi-Fi được chuyển thành dữ liệu phục vụ kinh doanh:

Client Location
Location Analytics
Operational Insights

Nói cách khác, Wi-Fi không còn chỉ là hạ tầng kết nối mà trở thành nguồn dữ liệu cho các ứng dụng phân tích và vận hành doanh nghiệp.

Luồng Hoạt Động Tổng Thể

Khi một thiết bị kết nối Wi-Fi:

Client kết nối đến Access Point.
AP tạo CAPWAP tunnel về WLC.
WLC thực hiện xác thực và áp dụng chính sách.
Dữ liệu được chuyển qua mạng Campus.
Thông tin vận hành được gửi lên Catalyst Center.
Dữ liệu vị trí được gửi đến CMX/MSE.
Các ứng dụng phân tích tạo báo cáo và dashboard cho doanh nghiệp.

Góc Nhìn CCIE Wireless

Cisco Unified Wireless là một trong những kiến trúc Wi-Fi doanh nghiệp đầu tiên đưa mô hình centralized control, distributed data forwarding vào thực tế.

Mô hình này mang lại:

Quản lý tập trung
Mở rộng quy mô dễ dàng
Hỗ trợ roaming liền mạch
Tối ưu RF tự động
Tích hợp bảo mật doanh nghiệp
Khả năng phân tích và định vị nâng cao

Đây cũng là nền tảng kiến trúc đã phát triển thành các hệ thống hiện đại ngày nay như Cisco Catalyst 9800 Wireless Controller, Catalyst Center, Cisco Spaces và các giải pháp AI-driven Operations trong mạng không dây doanh nghiệp.

[ccnp] cấu hình kiểm soát băng thông (qos policing) trên cisco ios

ThanhQuyen — Sat, 06 Jun 2026 04:59:09 GMT

[CCNP] CẤU HÌNH KIỂM SOÁT BĂNG THÔNG (QOS POLICING) TRÊN CISCO IOS

Trong quản trị mạng nâng cao, Kiểm soát băng thông (Policing) là một trong những công cụ then chốt được áp dụng ở hướng vào (Input) hoặc hướng ra (Output) của giao tiếp cổng nhầm giới hạn tốc độ lưu lượng ứng dụng theo một ngưỡng cam kết. Khác với cơ chế Định hình lưu lượng (Shaping) sử dụng hàng đợi để hoãn binh gói tin khi quá ngưỡng, Policer sẽ thực hiện hành động tức thời như chuyển tiếp, đánh dấu lại (Re-marking) hoặc loại bỏ (Drop) gói tin ngay khi dòng dữ liệu vượt quá giới hạn định sẵn.
Bám sát tài liệu "QoS Policing Configuration Example.pdf", bài viết này hướng dẫn chi tiết phương thức thiết lập 3 thuật toán kiểm soát băng thông tiêu chuẩn trên hệ điều hành Cisco IOS. 1. Mô hình kiểm thử hệ thống

[R1] (.1) ------------ (192.168.12.0/24) ------------ (.2) [R2]

Thiết bị phát (R1): Tạo luồng dữ liệu ICMP liên tục để kiểm thử hiệu năng.

Thiết bị kiểm soát (R2): Thực thi cơ chế phân loại bằng NBAR (match protocol icmp) và áp dụng các chính sách Policing.

2. Triển khai 3 thuật toán Policing tiêu chuẩn

2.1. Thuật toán đơn tốc độ, hai màu (Single Rate, Two-Color)

Đây là mô hình Policer cơ bản nhất, vận hành dựa trên một ngưỡng băng thông cam kết CIR (Committed Information Rate) và một lượng truyền dữ liệu đột biến Bc (Committed Burst). Dữ liệu di chuyển qua sẽ được phân định thành 2 trạng thái hành động:

Conform-action (Hợp chuẩn): Lưu lượng nằm trong ngưỡng CIR.

Exceed-action (Vượt ngưỡng): Lưu lượng vượt ngưỡng CIR.

Trong cấu hình dưới đây, chúng ta thiết lập mức CIR là 128 Kbps (128000 bps). Nếu luồng tin hợp chuẩn sẽ được chuyển tiếp (transmit), nếu vượt ngưỡng sẽ bị hủy bỏ hoàn toàn (drop):
Plaintext
R2(config)# class-map ICMP
R2(config-cmap)# match protocol icmp
R2(config-cmap)# exit

R2(config)# policy-map SINGLE-RATE-TWO-COLOR
R2(config-pmap)# class ICMP
R2(config-pmap-c)# police 128000
R2(config-pmap-c-police)# conform-action transmit
R2(config-pmap-c-police)# exceed-action drop

(Lưu ý: Bạn cũng có thể cấu hình nhanh toàn bộ tham số trên một dòng lệnh đơn: police 128000 conform-action transmit exceed-action drop).
Áp dụng chính sách vào cổng kết nối vật lý hướng nhận dữ liệu:
Plaintext
R2(config)# interface FastEthernet 0/0
R2(config-if)# service-policy input SINGLE-RATE-TWO-COLOR 2.2. Thuật toán đơn tốc độ, ba màu (Single Rate, Three-Color)

Cơ chế này mở rộng khả năng xử lý bằng cách tích hợp thêm tham số đột biến vượt ngưỡng Be (Excess Burst), giúp phân định dòng dữ liệu thành 3 trạng thái màu sắc riêng biệt: Conform (Hợp chuẩn), Exceed (Vượt ngưỡng mạng), và Violate (Vi phạm nghiêm trọng).
Thay vì hủy bỏ ngay các gói tin ở trạng thái Exceed, thuật toán này cho phép "phạt" bằng cách xóa bỏ nhãn ưu tiên (Hạ giá trị DSCP về mặc định - default) nhưng vẫn chuyển tiếp gói tin đi, và chỉ thực hiện hủy bỏ (drop) khi luồng dữ liệu rơi vào trạng thái Violate.
Plaintext
R2(config)# policy-map SINGLE-RATE-THREE-COLOR
R2(config-pmap)# class ICMP
R2(config-pmap-c)# police 128000
R2(config-pmap-c-police)# conform-action transmit
R2(config-pmap-c-police)# exceed-action set-dscp-transmit default
R2(config-pmap-c-police)# violate-action drop

Kích hoạt thay thế chính sách trên cổng interface:
Plaintext
R2(config-if)# no service-policy input SINGLE-RATE-TWO-COLOR
R2(config-if)# service-policy input SINGLE-RATE-THREE-COLOR 2.3. Thuật toán đa tốc độ, ba màu (Dual Rate, Three-Color)

Đây là giải pháp kiểm soát băng thông tối ưu và nghiêm ngặt nhất cho các đường truyền phân cấp. Thuật toán sử dụng đồng thời hai đồng hồ đo tốc độ độc lập: CIR (Tốc độ cam kết tối thiểu) và PIR (Peak Information Rate - Tốc độ đỉnh tối đa).

Luồng tin dưới mức CIR: Trạng thái Conform $\rightarrow$ Chuyển tiếp.

Luồng tin vượt CIR nhưng nằm dưới PIR: Trạng thái Exceed $\$rightarrow Đổi nhãn DSCP về 0 và chuyển tiếp.

Luồng tin vượt quá mức PIR: Trạng thái Violate $\$rightarrow Hủy bỏ tức thì.

Cấu hình thực tế thiết lập mức CIR 128 Kbps và PIR 256 Kbps:
Plaintext
R2(config)# policy-map DUAL-RATE-THREE-COLOR
R2(config-pmap)# class ICMP
R2(config-pmap-c)# police cir 128000 pir 256000
R2(config-pmap-c-police)# conform-action transmit
R2(config-pmap-c-police)# exceed-action set-dscp-transmit default
R2(config-pmap-c-police)# violate-action drop

Kích hoạt chính sách lên cổng mạng:
Plaintext
R2(config-if)# no service-policy input SINGLE-RATE-THREE-COLOR
R2(config-if)# service-policy input DUAL-RATE-THREE-COLOR 3. Giám sát hiệu năng hệ thống qua số liệu thực tế

Sau khi kích hoạt lệnh ping kiểm thử liên tục từ R1, câu lệnh show policy-map interface trên R2 cung cấp các thông số tường minh về hiệu suất xử lý của từng thuật toán.
Trích xuất dữ liệu mẫu từ cơ chế Dual Rate:
Plaintext
R2# show policy-map interface FastEthernet 0/0
Class-map: ICMP (match-all)
7472 packets, 851808 bytes
Match: protocol icmp
police:
cir 128000 bps, bc 4000 bytes
pir 256000 bps, be 8000 bytes
conformed 3713 packets, 423282 bytes; actions: transmit
exceeded 3715 packets, 423510 bytes; actions: set-dscp-transmit default
violated 44 packets, 5016 bytes; actions: drop

Thông tin hiển thị trên minh chứng tính hiệu quả của giải pháp: Router tự động tính toán các giá trị đột biến mặc định ($Bc = 4000 \text{ bytes}$, $Be = 8000 \text{ bytes}$) dựa trên tốc độ cấu hình. Đồng thời, lượng gói tin được phân cấp chính xác vào các phân mục hành động cụ thể, giúp bảo vệ tài nguyên băng thông cốt lõi của doanh nghiệp.
NÂNG CAO KỸ NĂNG ĐIỀU PHỐI LƯU LƯỢNG MẠNG TẠI VNPRO
Kỹ thuật kiểm soát băng thông (QoS Policing) theo các thuật toán Token Bucket đơn và đa tốc độ là học phần thực hành chuyên sâu bắt buộc thuộc cấu trúc bài thi quốc tế CCNP Enterprise và CCIE Enterprise Infrastructure. Để trực tiếp tối ưu hóa và làm chủ hạ tầng viễn thông doanh nghiệp, quý học viên có thể đăng ký tham gia các khóa đào tạo chuyên gia tại VnPro[cite: 10].

Hotline/Zalo hỗ trợ tư vấn: 093 3427 079

Websitevnpro.vn.

[ccnp] cơ chế và triển khai đánh dấu lưu lượng (qos marking) trên cisco ios

ThanhQuyen — Fri, 05 Jun 2026 09:14:57 GMT

[CCNP] CƠ CHẾ VÀ TRIỂN KHAI ĐÁNH DẤU LƯU LƯỢNG (QOS MARKING) TRÊN CISCO IOS

Trong kiến trúc Quản trị chất lượng dịch vụ (QoS), sau khi dòng dữ liệu đã được nhận diện thông qua tiến trình phân loại (Classification), bước chiến lược tiếp theo là thực hiện Đánh dấu lưu lượng (Marking). Đánh dấu là hành vi thiết lập giá trị vào trường tiêu đề (Header) của gói tin mạng — cụ thể là byte ToS (Type of Service) ở lớp 3 đối với cấu trúc định tuyến — bằng một giá trị IP Precedence hoặc mã định danh DSCP (Differentiated Services Code Point) cụ thể.

Việc cấu hình đánh dấu giúp các thiết bị trung gian tiếp theo dọc theo đường truyền không phải thực hiện lại tiến trình phân loại chuyên sâu (DPI) vốn tiêu tốn tài nguyên phần cứng, mà chỉ cần đọc nhãn đã được đánh dấu để áp dụng ngay chính sách xử lý hàng đợi phù hợp. Bám sát tài liệu "QoS Marking on Cisco IOS Router.pdf", bài viết này sẽ phân tích cơ chế thực thi cấu hình đánh dấu trên hệ điều hành Cisco IOS.

1. Kỹ thuật đánh dấu bằng IP Precedence và DSCP thông qua MQC

Hệ điều hành Cisco IOS triển khai cơ chế MQC (Modular QoS CLI) để quản lý cấu trúc đánh dấu một cách đồng bộ thông qua câu lệnh tác vụ set bên trong cấu hình Policy-map. Tùy thuộc vào kiến trúc thiết kế mạng, kỹ sư có thể lựa chọn đánh dấu theo thang đo IP Precedence (giá trị từ $0$ đến $7$) hoặc thang đo DSCP nâng cao (giá trị từ $0$ đến $63$). Mô hình kiểm thử tiêu chuẩn:

[R1] (Client) ------> [R2] (Thực hiện Đánh dấu) ------> [R3] (Xác thực nhãn)
1.1. Thực thi cấu hình đánh dấu IP Precedence

Kỹ thuật này áp dụng cho các hạ tầng mạng thế hệ cũ hoặc các dòng dịch vụ cơ bản. Trong ví dụ này, luồng lưu lượng Telnet sẽ được định tuyến qua R2 và tiến hành đánh dấu mức ưu tiên cao nhất là precedence 7 (Network Control).

Bước 1: Tạo Access-list và liên kết Class-map phân loại

Plaintext

R2(config)# ip access-list extended TELNET-TRAFFIC
R2(config-ext-nacl)# permit tcp any any eq telnet
R2(config-ext-nacl)# exit
R2(config)# class-map TELNET-TRAFFIC
R2(config-cmap)# match access-group name TELNET-TRAFFIC

Bước 2: Sử dụng lệnh set precedence trong Policy-map

Plaintext

R2(config)# policy-map MARKING
R2(config-pmap)# class TELNET-TRAFFIC
R2(config-pmap-c)# set precedence network

(Lưu ý kỹ thuật: Trên các phiên bản Cisco IOS hiện đại, lệnh set precedence đã hoàn toàn thay thế cho lệnh set ip precedence cũ).

Bước 3: Áp dụng chính sách tại cổng vào (Input) của giao tiếp mạng

Plaintext

R2(config)# interface FastEthernet 0/0
R2(config-if)# service-policy input MARKING
1.2. Thực thi cấu hình đánh dấu DSCP

Đối với hạ tầng mạng phân cấp hiện đại đòi hỏi độ mịn cao hơn trong việc phân chia phân lớp dịch vụ, mã DSCP được ưu tiên áp dụng. Ví dụ dưới đây tiến hành định danh luồng dữ liệu HTTP (Port 80) và đánh dấu bằng mã AF12 (Assured Forwarding 12).

Plaintext

R2(config)# ip access-list extended HTTP-TRAFFIC
R2(config-ext-nacl)# permit tcp any any eq 80
R2(config-ext-nacl)# exit

Plaintext

R2(config)# class-map HTTP-TRAFFIC
R2(config-cmap)# match access-group name HTTP-TRAFFIC
R2(config-cmap)# exit

Plaintext

R2(config)# policy-map MARKING
R2(config-pmap)# class HTTP-TRAFFIC
R2(config-pmap-c)# set dscp af12
2. Kiểm tra và xác thực trạng thái đánh dấu trên Router

Sau khi luồng traffic được kích hoạt từ R1, chúng ta sử dụng câu lệnh show policy-map interface trên Router R2 để giám sát hiệu năng thực thi:

Plaintext

R2# show policy-map interface FastEthernet 0/0
Class-map: TELNET-TRAFFIC (match-all)
10 packets, 609 bytes
Match: access-group name TELNET-TRAFFIC
QoS Set
precedence 7
Packets marked 10

Class-map: HTTP-TRAFFIC (match-all)
3 packets, 180 bytes
Match: access-group name HTTP-TRAFFIC
QoS Set
dscp af12
Packets marked 3

Hệ thống báo cáo chi tiết số lượng gói tin đã được chuyển đổi trạng thái thành công (Packets marked), xác nhận cơ chế đánh dấu đang vận hành chính xác.

3. Giải pháp xây dựng hàng đợi đối chiếu (QoS Counter)

Một trong những thách thức lớn nhất khi vận hành QoS trong môi trường Multi-vendor hoặc kết nối qua mạng WAN của ISP là hiện tượng Ghi đè nhãn (Re-marking). Một số thiết bị chuyển mạch (Switch) hoặc bộ điều khiển không dây (Wireless Controller) cấu hình sai có thể xóa bỏ hoặc thay đổi các giá trị DSCP/Precedence ban đầu của doanh nghiệp.

Để kiểm tra và đảm bảo tính toàn vẹn của nhãn QoS khi gói tin đi đến đích (Router R3), giải pháp tối ưu là thiết lập một Policy-map dạng COUNTER chỉ làm nhiệm vụ bắt trùng khớp giá trị tiêu đề và đếm gói:

Plaintext

R3(config)# class-map AF12
R3(config-cmap)# match dscp af12
R3(config)# class-map PREC7
R3(config-cmap)# match precedence 7

Plaintext

R3(config)# policy-map COUNTER
R3(config-pmap)# class AF12
R3(config-pmap-c)# exit
R3(config)# class PREC7
R3(config-pmap-c)# exit

Plaintext

R3(config)# interface FastEthernet 0/0
R3(config-if)# service-policy input COUNTER

Khi trích xuất trạng thái trên R3 thông qua lệnh show policy-map interface, nếu các cấu phần Class-map: AF12 và PREC7 liên tục tăng số lượng gói tin (Packet Count), điều đó chứng tỏ hạ tầng mạng trung gian hoạt động ổn định, nhãn QoS được bảo toàn nguyên vẹn suốt lộ trình truyền tải.

🎓 LÀM CHỦ KIẾN TRÚC THIẾT KẾ QOS TOÀN DIỆN TẠI VNPRO

Kỹ thuật phân loại, đánh dấu và kiểm soát tính toàn vẹn của cấu trúc tiêu đề gói tin (QoS Marking & Re-marking) là học phần bắt buộc, chuyên sâu thuộc chương trình đào tạo CCNP Enterprise và CCIE Enterprise Infrastructure. Để trực tiếp tối ưu hóa hạ tầng, làm chủ các phân lớp dịch vụ mạng doanh nghiệp trên hệ thống thiết bị Cisco chính hãng, quý học viên có thể tham gia các lộ trình đào tạo bài bản tại VnPro[cite: 9].

📲 Hotline/Zalo: 093 3427 079
🌐 Website: vnpro.vn

Cơ chế và cấu hình peak traffic shaping trên cisco ios

ThanhQuyen — Fri, 05 Jun 2026 09:00:54 GMT

[CCNP] PHÂN TÍCH CHUYÊN SÂU CƠ CHẾ VÀ THỰC THI HÀNG ĐỢI ƯU TIÊN ĐỘ TRỄ THẤP (LOW LATENCY QUEUING - LLQ) TRÊN CISCO IOS

Trong hệ thống quản trị chất lượng dịch vụ (QoS), việc xử lý các luồng dữ liệu thời gian thực (Real-time traffic) như thoại (Voice) hay video đặt ra một thách thức lớn về mặt kỹ thuật. Các thuật toán xếp hàng đợi truyền thống, bao gồm cả CBWFQ (Class-Based Weighted Fair Queuing), dù đảm bảo được băng thông tối thiểu cho từng lớp lưu lượng thông qua bộ lập lịch vòng tròn có trọng số (Weighted Round Robin), vẫn không thể tối ưu hóa độ trễ. Lý do là bởi các gói tin nhạy cảm với thời gian vẫn phải xếp hàng chờ bộ lập lịch xoay vòng phục vụ xong các hàng đợi khác.

Để giải quyết triệt để bài toán này, giải pháp LLQ (Low Latency Queuing) được phát triển như một sự mở rộng nâng cao của CBWFQ bằng cách tích hợp thêm cơ chế hàng đợi ưu tiên nghiêm ngặt (Strict Priority Queue) trực tiếp vào bộ lập lịch. Bài viết kỹ thuật này sẽ bám sát nội dung từ tài liệu "QoS LLQ (Low Latency Queueing) on Cisco IOS.pdf" nhằm phân tích sâu bản chất vận hành và phương thức triển khai giải pháp này trên hạ tầng Cisco IOS. 1. Kiến trúc vận hành của thuật toán LLQ

Bản chất của LLQ là sự kết hợp tối ưu giữa tính công bằng của CBWFQ và tính tức thời của thuật toán hàng đợi ưu tiên (Priority Queuing).

+-----------------+
Lớp dữ liệu Ưu tiên (VOICE) --------> | Hàng đợi LLQ | ------+
+-----------------+ |
| (Ưu tiên tuyệt đối)
+-----------------+ v
Lớp Dữ liệu 2 (SIGNALING) ---------> | Hàng đợi CBWFQ | ---> [X] ---> Đầu ra Cổng (Egress)
+-----------------+ ^
| (Vòng tròn trọng số)
+-----------------+ |
Lớp Dữ liệu Mặc định ---------------> | Class-Default | ------+
+-----------------+

Sơ đồ kiến trúc hàng đợi chuẩn hóa cho thấy sự phân tách rõ rệt trong việc xử lý luồng tin:

Hàng đợi Ưu tiên (LLQ): Được điều phối bởi một bộ lập lịch ưu tiên riêng biệt giúp bỏ qua hoàn toàn bộ lập lịch CBWFQ. Tất cả các gói tin rơi vào hàng đợi này (ví dụ: Voice) sẽ được xử lý và chuyển tiếp đi trước bất kỳ gói tin nào ở các hàng đợi khác. Chỉ khi hàng đợi LLQ hoàn toàn trống, bộ lập lịch mới chuyển quyền xử lý sang các hàng đợi còn lại.
Các hàng đợi thông thường (CBWFQ): Các lớp lưu lượng còn lại (như dữ liệu ứng dụng, tín hiệu điều khiển, hệ thống mặc định) được đưa vào các hàng đợi riêng lẻ và được phục vụ theo cơ chế xoay vòng có trọng số (Round Robin) dựa trên tỷ lệ băng thông được cấp phát.

2. Triển khai cấu hình LLQ bằng cơ chế MQC

Để minh họa phương thức thiết lập LLQ, chúng ta tiến hành cấu hình phân tầng QoS trên thiết bị Router R2 đóng vai trò trung gian nhận luồng dữ liệu từ R1 truyền sang R3. Hạ tầng yêu cầu phân tách luồng thoại (Voice) vào hàng đợi ưu tiên thấp và luồng tín hiệu điều khiển cuộc gọi (Call Signaling) vào hàng đợi đảm bảo băng thông. Bước 1: Khởi tạo Class-map phân loại lưu lượng dựa trên nhãn DSCP

Hệ thống sử dụng các tiêu chuẩn phân loại dựa trên giá trị DSCP lớp 3:

Lớp VOICE nhận diện các gói tin có nhãn DSCP EF (Expedited Forwarding) chuyên biệt cho tiến trình truyền giọng nói.
Lớp CALL_SIGNALING nhận diện các gói tin có nhãn DSCP CS3 (Class Selector 3) phục vụ việc thiết lập và điều khiển cuộc gọi.

Plaintext

R2(config)# class-map VOICE
R2(config-cmap)# match dscp ef
R2(config)# class-map CALL_SIGNALING
R2(config-cmap)# match dscp cs3
Bước 2: Xây dựng chính sách Policy-map và cấu hình phân phối hàng đợi

Khi thiết lập cho lớp VOICE, việc sử dụng từ khóa priority sẽ chuyển đổi hàng đợi của lớp này từ cơ chế CBWFQ thông thường sang cơ chế hàng đợi ưu tiên nghiêm ngặt (LLQ). Đối với các dòng sản phẩm phần cứng tiên tiến, lệnh priority hỗ trợ thiết lập đa tầng (Multi-Level Priority Queue) giúp chia nhỏ hàng đợi ưu tiên thành mức cao và mức thấp (High/Low Priority), rất hữu ích khi cần tối ưu hóa đồng thời cả Voice và Video thời gian thực nhằm tránh hiện tượng cạnh tranh lẫn nhau.

Trong ngữ cảnh bài lab này, chúng ta cấp phát cho lớp VOICE một hàng đợi ưu tiên với mức băng thông cam kết là 2000 Kbps, và lớp CALL_SIGNALING nhận mức băng thông đảm bảo là 1000 Kbps bằng câu lệnh bandwidth truyền thống.

Plaintext

R2(config)# policy-map LLQ
R2(config-pmap)# class VOICE
R2(config-pmap-c)# priority 2000
R2(config-pmap-c)# exit
R2(config)# policy-map LLQ
R2(config-pmap)# class CALL_SIGNALING
R2(config-pmap-c)# bandwidth 1000
Bước 3: Gắn chính sách lên cổng vật lý GigabitEthernet hướng đi ra (Output)

Plaintext

R2(config)# interface GigabitEthernet 0/2
R2(config-if)# service-policy output LLQ

⚠️ Lưu ý cốt lõi về mặt kỹ thuật: Thông số băng thông cấu hình trong câu lệnh priority 2000 hay bandwidth 1000 không phải là giới hạn trần nghiêm ngặt (hard limit). Khi cổng vật lý ở trạng thái bình thường (không xảy ra nghẽn), cả hai lớp lưu lượng đều có quyền sử dụng vượt ngưỡng băng thông đã khai báo để tối ưu hóa hiệu suất truyền tải. Tuy nhiên, một khi hiện tượng nghẽn mạch xảy ra, cơ chế LLQ sẽ kích hoạt tính năng kiểm soát tích hợp bên trong để bảo vệ băng thông và ngăn chặn tình trạng hàng đợi ưu tiên chiếm dụng toàn bộ tài nguyên của cổng (Starvation). Nếu muốn thiết lập một giới hạn trần cố định cho hàng đợi ưu tiên trong mọi điều kiện mạng, kỹ sư phải triển khai kết hợp thêm tính năng giới hạn băng thông (Policing).

3. Xác thực cấu hình và phân tích trạng thái hệ thống

Để xác thực độ chính xác của cơ chế, ta phát các chuỗi gói tin ICMP từ Router R1 với các thông số ToS (Type of Service) được chuyển đổi tương đương từ giá trị DSCP lớp 3:

Nhãn DSCP EF (Giá trị nhị phân 101110) tương đương với giá trị thập phân 184 khi cấu hình trường ToS trên câu lệnh ping.
Nhãn DSCP CS3 (Giá trị nhị phân 011000) tương đương với giá trị thập phân 96.

Sau khi phát dữ liệu, thực hiện kiểm tra trạng thái hoạt động trên cổng của R2:

Plaintext

R2# show policy-map interface GigabitEthernet 0/2
GigabitEthernet0/2
Service-policy output: LLQ
queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 100/11400

Class-map: VOICE (match-all)
100 packets, 11400 bytes
Match: dscp ef (46)
Priority: 2000 kbps, burst bytes 50000, b/w exceed drops: 0

Class-map: CALL_SIGNALING (match-all)
200 packets, 22800 bytes
Match: dscp cs3 (24)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 200/22800
bandwidth 1000 kbps

Class-map: class-default (match-any)
7 packets, 724 bytes
Match: any

Kết quả trích xuất hệ thống xác nhận các gói tin kiểm thử đã phân phối chính xác tuyệt đối vào các hàng đợi mục tiêu. Luồng dữ liệu lớp VOICE được gắn nhãn cấu trúc Priority: 2000 kbps riêng biệt, khẳng định hàng đợi LLQ đang vận hành ổn định và sẵn sàng cung cấp độ trễ tối thiểu cho dịch vụ thoại.

🎓 LÀM CHỦ CÁC CÔNG CỤ QUẢN LÝ NGHẼN NÂNG CAO TẠI VNPRO

Cơ chế hàng đợi ưu tiên độ trễ thấp (LLQ) kết hợp CBWFQ là cấu phần kiến trúc bắt buộc trong việc thiết kế và tối ưu hóa hạ tầng mạng thế hệ mới, thuộc nội dung trọng tâm của chương trình đào tạo chuyên sâu CCNP Enterprise và CCIE Enterprise Infrastructure. Để trực tiếp thao tác, đo lường dòng dữ liệu thực tế trên hệ thống phòng Lab tiêu chuẩn quốc tế với các chuyên gia hàng đầu, quý học viên có thể tham khảo các lộ trình học tập chuyên nghiệp tại VnPro[cite: 8].

📲 Hotline/Zalo VnPro 093 3427 079
🌐 Website: vnpro.vn.

Tối ưu hóa hệ thống qos cơ chế và phương pháp phân loại lưu lượng (qos classification)trên cisco ios

ThanhQuyen — Fri, 05 Jun 2026 08:44:07 GMT

TỐI ƯU HÓA HỆ THỐNG QOS: CƠ CHẾ VÀ PHƯƠNG PHÁP PHÂN LOẠI LƯU LƯỢNG (QOS CLASSIFICATION) TRÊN CISCO IOS

Trong một hạ tầng mạng doanh nghiệp tiêu chuẩn, sự đa dạng của các ứng dụng đồng nghĩa với việc mỗi luồng dữ liệu sẽ có những đòi hỏi kỹ thuật riêng biệt về băng thông, độ trễ (delay) và độ biến động trễ (jitter). Chẳng hạn, các ứng dụng truyền tải file như FTP phục vụ sao lưu dữ liệu thường đòi hỏi băng thông lớn nhưng hoàn toàn không nhạy cảm với trễ hay jitter. Ngược lại, dịch vụ thoại VoIP không chiếm dụng nhiều tài nguyên băng thông nhưng lại yêu cầu kiểm soát độ trễ và jitter nghiêm ngặt; nếu trễ quá cao, cuộc gọi sẽ bị gián đoạn như đang sử dụng bộ đàm, và jitter lớn sẽ trực tiếp làm biến dạng chất lượng âm thanh.

Theo cơ chế vận hành mặc định, thiết bị định tuyến (Router) thực hiện chuyển tiếp gói tin theo mô hình Best-Effort: chỉ kiểm tra địa chỉ IP đích, tra cứu bảng định tuyến và chuyển tiếp gói tin đi mà không hề phân biệt bản chất của ứng dụng. Do đó, Phân loại lưu lượng (Classification) chính là bước đi đầu tiên và bắt buộc trong tiến trình triển khai Quality of Service (QoS), giúp Router nhận diện và gán luồng dữ liệu vào các nhóm ứng dụng cụ thể trước khi áp dụng các chính sách chuyên sâu như đánh dấu (marking), xếp hàng đợi (queuing), giới hạn băng thông (policing) hay định hình lưu lượng (shaping).

Bám sát nội dung tài liệu "QoS Classification on Cisco IOS Router.pdf", bài viết này sẽ phân tích hai phương pháp phân loại cốt lõi trên hệ điều hành Cisco IOS. 1. Các phương pháp phân loại lưu lượng trên Cisco IOS

Để nhận diện ứng dụng, Router Cisco sử dụng hai kỹ thuật kiểm tra gói tin chính:

Header Inspection (Kiểm tra phần đầu gói tin): Phân tích các trường thông tin có sẵn trong tiêu đề lớp mạng. Phương pháp này kiểm tra thông tin lớp 2 (Địa chỉ MAC), lớp 3 (Địa chỉ IP nguồn/đích) và lớp 4 (Số cổng và giao thức nguồn/đích, ví dụ TCP Port 23 cho Telnet, TCP Port 80 cho HTTP).
Payload Inspection (Kiểm tra vùng dữ liệu): Thực hiện kỹ thuật kiểm tra gói tin sâu (Deep Packet Inspection - DPI) vào bên trong vùng tài nguyên Payload để nhận diện ứng dụng một cách chính xác. Trên thiết bị Cisco, cơ chế này được thực thi thông qua công cụ NBAR (Network-Based Application Recognition).

2. Thực thi cấu hình phân loại bằng kỹ thuật MQC (Modular QoS CLI)

Cisco quản lý và triển khai các chính sách QoS thông qua cấu trúc dòng lệnh chuẩn hóa MQC bằng cách kết hợp ba thành phần: class-map (định nghĩa dữ liệu), policy-map (định nghĩa hành động) và service-policy (áp dụng vào giao tiếp cổng). 2.1. Phân loại lưu lượng bằng Access-List (Header Inspection)

Mặc dù Header Inspection rất đơn giản và hiệu quả, phương pháp này tồn tại nhược điểm lớn khi các ứng dụng không phổ biến hoặc các phần mềm nhắn tin tức thời cố tình chiếm dụng các cổng tiêu chuẩn (như TCP Port 80) để vượt qua tường lửa, khiến Router phân loại sai hành vi.

Tuy nhiên, đối với các dịch vụ tường minh như Telnet, việc sử dụng Extended Access-List vẫn là một giải pháp tối ưu.

Bước 1: Khởi tạo Access-list định danh cổng dịch vụ

Plaintext

R2(config)# ip access-list extended TELNET
R2(config-ext-nacl)# permit tcp any any eq 23

Bước 2: Thiết lập Class-map liên kết với Access-list

Plaintext

R2(config)# class-map TELNET
R2(config-cmap)# match access-group name TELNET

Bước 3: Tích hợp Class-map vào Policy-map và áp dụng trên giao tiếp cổng (hướng Input)

Plaintext

R2(config)# policy-map CLASSIFY
R2(config-pmap)# class TELNET
R2(config-pmap-c)# exit
R2(config)# interface GigabitEthernet 0/1
R2(config-if)# service-policy input CLASSIFY

Khi kiểm tra bằng câu lệnh show policy-map interface GigabitEthernet 0/1, Router sẽ hiển thị chi tiết số lượng gói tin khớp với ACL. Điểm lưu ý quan trọng là toàn bộ lượng lưu lượng không được định nghĩa rõ ràng trong các Class-map sẽ tự động rơi vào nhóm mặc định mang tên class-default. 2.2. Phân loại lưu lượng bằng NBAR (Payload Inspection)

Để khắc phục nhược điểm của ACL, NBAR cung cấp khả năng phân tích sâu. Khi kích hoạt, Router sẽ đối chiếu luồng dữ liệu nhận được với hệ thống chữ ký định danh ứng dụng và các thuộc tính lưu trữ trong phân hệ PDLM (Packet Description Language Module). Nhờ đó, NBAR có khả năng nhận diện chính xác lưu lượng ứng dụng (ví dụ như HTTP) bất kể ứng dụng đó đang chạy trên cổng dịch vụ nào, đồng thời có thể phân tích chi tiết các thuộc tính như định dạng URL, kiểu dữ liệu MIME (file zip, hình ảnh) hay thông tin User-agent của trình duyệt.

Để hỗ trợ việc giám sát trực quan trước khi cấu hình chính sách, kỹ sư có thể kích hoạt tính năng khám phá giao thức trực tiếp trên cổng giao tiếp mạng:

Plaintext

R2(config)# interface GigabitEthernet 0/1
R2(config-if)# ip nbar protocol-discovery

Sau đó, câu lệnh show ip nbar protocol-discovery sẽ thống kê chính xác các chủng loại giao thức kèm tốc độ bit tương ứng đang di chuyển qua cổng.

Để đưa NBAR vào cấu trúc thực thi QoS, chúng ta sử dụng từ khóa match protocol bên trong Class-map. Hệ điều hành Cisco IOS cung cấp một danh mục tích hợp sẵn vô cùng phong phú bao gồm hàng trăm ứng dụng khác nhau.

Cấu hình thay thế chính sách phân loại bằng NBAR:

Plaintext

R2(config)# class-map NBAR-TELNET
R2(config-cmap)# match protocol telnet
R2(config-cmap)# exit
R2(config)# policy-map CLASSIFY
R2(config-pmap)# no class TELNET
R2(config-pmap)# class NBAR-TELNET

(Lưu ý: Việc kích hoạt câu lệnh ip nbar protocol-discovery trên cổng chỉ nhằm mục đích hiển thị thống kê, không phải là điều kiện bắt buộc để tính năng match protocol trong Class-map hoạt động).

Sau khi triển khai, lệnh kiểm tra giám sát show policy-map interface sẽ xác nhận trạng thái phân loại thành công thông qua dòng thông báo kết quả: Match: protocol telnet. Kết luận

Việc lựa chọn công cụ phân loại phụ thuộc vào đặc tính ứng dụng của doanh nghiệp: sử dụng Access-List cho các dịch vụ có cổng cố định, rõ ràng và sử dụng NBAR cho các ứng dụng web phức tạp hoặc lưu lượng động. Làm chủ giai đoạn Phân loại (Classification) sẽ tạo tiền đề vững chắc cho việc xây dựng các chính sách kiểm soát băng thông toàn diện ở các giai đoạn tiếp theo.

🎓 NÂNG CAO NĂNG LỰC TỐI ƯU HỆ THỐNG MẠNG TẠI VNPRO

Kỹ thuật phân loại và định hình lưu lượng chuyên sâu là một phần kiến thức nền tảng bắt buộc thuộc phân hệ dịch vụ hệ thống của chương trình đào tạo CCNP Enterprise và CCIE Enterprise Infrastructure. Để trực tiếp thao tác trên các thiết bị thật thế hệ mới và xây dựng các giải pháp tối ưu hóa hạ tầng mạng doanh nghiệp toàn diện, quý học viên có thể tham khảo các lộ trình học chuyên nghiệp tại VnPro.

📲 Hotline/Zalo tư vấn lộ trình đào tạo: 093 3427 079 để nhận thông tin chi tiết.
🌐 Website: vnpro.vn.

[ccnp] PHÂN TÍCH CHUYÊN SÂU CƠ CHẾ PEAK TRAFFIC SHAPING TRÊN CISCO IOS

ThanhQuyen — Fri, 05 Jun 2026 05:03:05 GMT

[ccnp] PHÂN TÍCH CHUYÊN SÂU CƠ CHẾ PEAK TRAFFIC SHAPING TRÊN CISCO IOS

Trong kiến trúc Quản trị mạng và Tối ưu hóa băng thông (QoS), định hình lưu lượng (Traffic Shaping) là một giải pháp cốt lõi để quản lý dòng dữ liệu đầu ra nhằm tương thích với cam kết băng thông của nhà cung cấp dịch vụ (ISP). Hệ điều hành Cisco IOS hiện hỗ trợ hai giải pháp định hình chính bao gồm: shape average (định hình theo tốc độ trung bình) và shape peak (định hình theo tốc độ đỉnh).
Mặc dù shape average được ứng dụng rộng rãi và dễ tiếp cận, cơ chế shape peak lại thường gây ra nhiều sự nhầm lẫn và hiểu sai cho các kỹ sư hệ thống mạng. Bài viết kỹ thuật này sẽ bám sát nội dung từ tài liệu "Peak Traffic Shaping on Cisco IOS.pdf" để làm sáng tỏ bản chất vận hành và cách thức cấu hình giải pháp này. 1. Đánh giá sự khác biệt: Shape Average vs. Shape Peak

Để hiểu rõ cách thức hoạt động của shape peak, trước hết chúng ta cần so sánh trực tiếp cơ chế quản lý thẻ bài (Token Bucket) của nó với shape average. 1.1. Cơ chế của Shape Average

Hệ thống sử dụng một thùng chứa Token có dung lượng lưu trữ tối đa bằng tổng lượng bit truyền liên tục ($Bc$) và lượng bit truyền vượt ngưỡng ($Be$).

Tại thời điểm khởi đầu của mỗi chu kỳ thời gian ($Tc$), Router chỉ nạp vào thùng một lượng token cố định bằng giá trị $Bc$.

Nếu hệ thống trải qua những khoảng thời gian nhàn rỗi (Inactivity - không có hoặc có ít dữ liệu cần truyền), lượng token dư thừa sẽ được tích lũy dần lên đến mức tối đa là $Bc + Be$.

Sau giai đoạn nhàn rỗi đó, khi dữ liệu tăng đột biến, Router có thể tiêu thụ toàn bộ lượng token tích lũy ($Bc + Be$) để truyền tải một lượng dữ liệu lớn trong một khoảng thời gian ngắn (Burst). Tuy nhiên, ở các chu kỳ kế tiếp, lượng token nạp vào vẫn chỉ hoàn lại mức $Bc$.

1.2. Cơ chế của Shape Peak

shape peak thay đổi hoàn toàn cách thức sử dụng cấu phần $Be$.

Tại mỗi đầu chu kỳ $Tc$, Router sẽ chủ động nạp đầy vào thùng chứa cả hai lượng token $Bc$ và $Be$ cùng một lúc, thay vì phải chờ đợi giai đoạn nhàn rỗi để tích lũy.

Cuối mỗi chu kỳ $Tc$, nếu lượng token này không được sử dụng hết, chúng sẽ bị hủy bỏ (discarded) chứ không lưu lại cho chu kỳ sau. Do đó, các giai đoạn hệ thống không truyền dữ liệu hoàn toàn không có ý nghĩa tích lũy đối với shape peak.

2. Ý nghĩa thực tế và Ứng dụng trong Hợp đồng Lưu lượng (Traffic Contract)

Tại sao Cisco lại phát triển cơ chế nạp đồng thời cả $Bc$ và $Be$ này? Câu trả lời nằm ở cấu trúc hợp đồng lưu lượng kết nối WAN giữa doanh nghiệp và ISP.
Thông thường, các nhà cung cấp dịch vụ viễn thông sẽ cung cấp hai thông số băng thông trong hợp đồng:

CIR (Committed Information Rate): Tốc độ băng thông tối thiểu được cam kết và đảm bảo không bị mất gói.

PIR (Peak Information Rate): Tốc độ tối đa hệ thống có thể đạt được trong điều kiện mạng lưới của ISP không bị nghẽn (băng thông không cam kết). Khi hạ tầng ISP xảy ra nghẽn, các gói tin thuộc phạm vi từ CIR đến PIR có khả năng cao sẽ bị hủy bỏ đầu tiên. ISP thường áp dụng công cụ Giới hạn lưu lượng (Policing) để thực thi điều khoản này.

Công cụ shape peak được thiết kế để cấu hình phía khách hàng nhằm tương thích trực tiếp với mô hình CIR/PIR của ISP. Khi lưu lượng mạng ở mức cao và liên tục, Router sẽ sử dụng cả token $Bc$ và $Be$ tại mỗi chu kỳ để định hình băng thông lên tới ngưỡng PIR. Khi lưu lượng mạng giảm xuống hoặc thấp hơn, Router chỉ tiêu thụ lượng token tương đương mức $Bc$, tương ứng với việc định hình xoay quanh ngưỡng CIR. 3. Cấu hình thực tế trên thiết bị Cisco IOS

Để minh họa, chúng ta thiết lập chính sách QoS trên Router R1 sử dụng cấu trúc dòng lệnh MQC (Modular QoS CLI) nhằm định hình lưu lượng kiểm thử từ công cụ iPerf (chạy trên nền cổng TCP 5001). Bước 1: Khởi tạo Access-list và Class-map để phân loại lưu lượng

Plaintext
R1(config)# ip access-list extended IPERF_TRAFFIC
R1(config-ext-nacl)# permit tcp any any eq 5001
R1(config-ext-nacl)# exit
R1(config)# class-map IPERF
R1(config-cmap)# match access-group name IPERF_TRAFFIC Bước 2: Cấu hình Policy-map ứng dụng tính năng Peak Shaping

Lưu ý quan trọng: Giá trị số tham số nhập vào sau câu lệnh shape peak chính là ngưỡng tốc độ CIR, hoàn toàn không phải PIR. Ở đây chúng ta cấu hình giá trị CIR là 128 Kbps (128000 bps).
Plaintext
R1(config)# policy-map SHAPE_PEAK
R1(config-pmap)# class IPERF
R1(config-pmap-c)# shape peak 128000 Bước 3: Áp dụng chính sách lên cổng vật lý hướng đi ra (Output)

Plaintext
R1(config)# interface FastEthernet 0/0
R1(config-if)# service-policy output SHAPE_PEAK Kiểm tra trạng thái vận hành của hệ thống

Sử dụng câu lệnh đặc quyền show policy-map interface FastEthernet 0/0, ta thu được kết quả phân tích phân cấp hàng đợi như sau:
Plaintext
R1# show policy-map interface FastEthernet 0/0
Class-map: IPERF (match-all)
Queueing
shape (peak) cir 128000, bc 512, be 512
target shape rate 256000

Dựa vào kết quả trên, mặc dù thông số thiết lập đầu vào là cir 128000 (128 Kbps), hệ thống tự động tính toán giá trị mặc định cho $Bc = 512$ bits và $Be = 512$ bits. Do cả hai lượng mã token này được nạp đồng thời tại mỗi chu kỳ $Tc$, tốc độ định hình thực tế mà Router thực thi (Target Shape Rate) sẽ đạt ngưỡng 256000 bps (256 Kbps). Với cấu hình mặc định, tỷ lệ này tuân theo công thức:
$$\text{PIR} = 2 \times \text{CIR} \text{[cite: 6]}$$ 4. Những điểm lưu ý cốt lõi dành cho Kỹ sư Hệ thống

Bản chất phân phối tốc độ: Việc hiển thị hai thông số CIR và PIR trong kết quả kiểm tra của Router thực chất chỉ mang tính chất hiển thị logic phù hợp với thuật ngữ thiết kế. Thiết bị định tuyến không tự động co giãn linh hoạt tốc độ dựa trên trạng thái nghẽn của mạng ISP. Nó thiết lập một ngưỡng trần tối đa cố định (chính là Target Shape Rate - tức PIR) và thực hiện định hình dòng dữ liệu theo ngưỡng trần đó.

So sánh bản chất giữa shape peak 128000 và shape average 256000: Hai câu lệnh này không mang lại kết quả hoàn toàn đồng nhất. Với shape average 256000, hệ thống nạp $Bc$ ứng với tốc độ 256 Kbps tại mỗi chu kỳ, tuy nhiên sau một giai đoạn nhàn rỗi, sự tích lũy $Be$ có thể khiến lưu lượng bùng phát vượt ngưỡng 256 Kbps trong một khoảng thời gian ngắn. Ngược lại, shape peak 128000 nạp đều $Bc + Be$ để đạt đỉnh 256 Kbps ở mọi chu kỳ và chủ động hủy token thừa, do đó lưu lượng không bao giờ có thể vượt qua mốc 256 Kbps.

Để cấu hình hai trạng thái tương đương tuyệt đối, kỹ sư cần vô hiệu hóa hoàn toàn khả năng bùng phát lưu lượng ($Be = 0$) của câu lệnh định hình trung bình:
$$\text{shape peak 128000} \equiv \text{shape average 256000 1024 0} \text{[cite: 6]}$$

NÂNG CAO NĂNG LỰC THIẾT KẾ QOS CHUYÊN SÂU TẠI VNPRO
Kỹ thuật định hình lưu lượng nâng cao (Peak Traffic Shaping) và tối ưu hóa băng thông kết nối WAN là các nội dung trọng tâm thuộc cấu phần hạ tầng mạng của chương trình đào tạo CCNP Enterprise và CCIE Enterprise Infrastructure. Để trực tiếp thực hành phòng Lab trên các dòng thiết bị định tuyến Cisco thế hệ mới và làm chủ các giải pháp tối ưu hóa lưu lượng cho doanh nghiệp, quý học viên có thể tham khảo lộ trình đào tạo chuyên nghiệp tại VnPro.

Hotline/Zalo VnPro: 093 3427 079

Website: vnpro.vn.

BÀI TOÁN "MẠNG CHẬM KHÔNG RÕ NGUYÊN NHÂN" & TUYỆT CHIÊU MASTER FLEXIBLE NETFLOW (FNF) TRÊN CISCO IOS

Lương Thị Thùy — Fri, 05 Jun 2026 03:11:42 GMT

Chắc hẳn trong đời làm hạ tầng, không ít lần bạn đau đầu với câu hỏi huyền thoại từ sếp hoặc khách hàng: "Mạng em ơi, sao hôm nay chậm thế?".
Lục tìm trên Wireshark thì quá ngộp, bật MRTG hay PRTG thông thường thì chỉ thấy bandwidth tăng vọt chứ không biết chính xác ai (IP nào) đang chiếm dụng, ứng dụng nào (Protocol nào) đang chạy ngầm, hay hệ thống có đang bị dính DDoS hay không.
Để giải quyết triệt để bài toán này một cách chuyên nghiệp, Flexible NetFlow (FNF) chính là trợ thủ đắc lực nhất được tích hợp sẵn trên các thiết bị Cisco.

1. Bản chất cốt lõi: 4 Thành phần tạo nên Flexible NetFlow

Khác với NetFlow truyền thống khá cứng nhắc, chữ "Flexible" (Linh hoạt) cho phép bạn tự định nghĩa mình muốn bắt những thông tin gì để tiết kiệm tài nguyên. Để vận hành hệ thống này bạn chỉ cần nhớ nằm lòng 4 thành phần (4 trụ cột) sau:

Trụ cột 1: Flow Record (Định nghĩa cấu trúc dữ liệu)
Hãy tưởng tượng Flow Record giống như việc bạn thiết kế các cột cho một bảng database. Bản ghi này sẽ chia làm hai nhóm thông tin:

Key fields (Sử dụng lệnh match): Đây là các trường dùng để định danh một luồng traffic (giống như Primary Key). Nếu gói tin trùng toàn bộ các trường này, nó được tính vào cùng một luồng. Ví dụ: IP nguồn, IP đích, giao thức (TCP/UDP).
Non-key fields (Sử dụng lệnh collect): Đây là các thông tin bổ sung mà bạn muốn thu thập để phân tích sâu hơn. Ví dụ: Đếm tổng số packet, tổng số byte đã truyền qua luồng đó, hoặc các thông tin về SNMP.

Trụ cột 2: Flow Exporter (Định nghĩa nơi nhận dữ liệu)
Sau khi thiết bị thu thập dữ liệu vào bộ nhớ đệm (Cache), nó cần đẩy về một "bộ não trung tâm" để vẽ biểu đồ cho trực quan (gọi là NetFlow Collector như SolarWinds, PRTG, ManageEngine...). Flow Exporter chính là nơi bạn khai báo IP của Collector này, giao thức truyền tải (thường là UDP) và cổng dịch vụ (Port mặc định thường là 2055).

Trụ cột 3: Flow Monitor (Bộ não liên kết)
Thành phần này đóng vai trò là "chất keo" liên kết. Nó gọi tên bản ghi dữ liệu (Flow Record) kết hợp với nơi nhận dữ liệu (Flow Exporter) để tạo ra một thực thể lưu trữ Cache thực tế trên Router. Nếu không có Monitor, hai thành phần trên chỉ là các dòng cấu hình rời rạc, không tự chạy được.

Trụ cột 4: Flow Sampler (Bộ lấy mẫu giảm tải - Tùy chọn)
Nếu Router của bạn phải gánh lượng traffic khổng lồ (vài Gbps), việc bắt và phân tích từng gói tin một sẽ làm CPU/RAM của thiết bị "quá tải". Flow Sampler sinh ra để giải quyết việc này bằng cách lấy mẫu theo tỷ lệ. Nó có hai chế độ:

Deterministic (Định kỳ): Cứ cách đúng một khoảng cố định thì lấy 1 gói (Ví dụ: Cứ qua 2 gói thì lấy gói thứ 2).
Random (Ngẫu nhiên): Lấy ngẫu nhiên theo tỷ lệ thiết lập để đảm bảo tính khách quan (Ví dụ: Ngẫu nhiên bốc 1 gói trong cụm 2 gói, tương đương lấy mẫu 50%).

2. Quy trình cấu hình thực chiến (Workflow)
Để cấu hình Flexible NetFlow chạy mượt mà, bạn cần tuân theo trình tự chuẩn 4 bước dưới đây.
Lưu ý điều kiện tiên quyết: Tính năng CEF (Cisco Express Forwarding) bắt buộc phải được kích hoạt trước bằng lệnh ip cef và ipv6 cef, nếu không FNF sẽ không hoạt động.

Bước 1: Tạo Flow Exporter (Chỉ đường đến Collector)
Plaintext
Router(config)# flow exporter MY_EXPORTER
Router(config-flow-exporter)# destination 10.0.10.1
Router(config-flow-exporter)# transport udp 2055udp 2055udp 2055

Giải thích: Lệnh này báo cho Router biết: "Sau khi gom dữ liệu xong, hãy đóng gói thành các gói UDP port 2055 và bắn về máy chủ Collector có IP 10.0.10.1".

Bước 2: Tạo Flow Record (Thiết kế form thu thập)
Bạn có thể dùng các form mặc định sẵn của Cisco như netflow-original, hoặc tự tạo thủ công để tối ưu:
Plaintext
Router(config)# flow record MY_RECORD
Router(config-flow-record)# match ipv4 source-address Router(config-flow-record)# match ipv4 destination-address Router(config-flow-record)# match ipv4 protocol Router(config-flow-record)# collect counter packets longpackets long

Giải thích: Ở đây chúng ta gom nhóm traffic dựa trên IP nguồn, IP đích, Protocol và yêu cầu hệ thống đếm xem có bao nhiêu gói tin (packets long) đi qua luồng đó.

Bước 3: Tạo Flow Monitor (Kết nối Record và Exporter)
Plaintext
Router(config)# flow monitor MY_MONITOR
Router(config-flow-monitor)# record MY_RECORD
Router(config-flow-monitor)# exporter MY_EXPORTERMY_EXPORTER

Bước 4: Áp dụng trực tiếp vào Cổng Interface

Bạn có thể áp dụng theo hướng dòng tiền đi vào (input) hoặc đi ra (output) của cổng mạng. Nếu có sử dụng bộ lấy mẫu Sampler để tiết kiệm CPU, câu lệnh sẽ lồng cả tên Sampler vào:

Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip flow monitor MY_MONITOR sampler MY_SAMPLER inputflow monitor MY_MONITOR sampler MY_SAMPLER input

Kết luận
Hy vọng bài chia sẻ chi tiết này sẽ giúp bạn tự tin làm chủ Flexible NetFlow, nhanh chóng "vạch mặt" được những nguồn lưu lượng bất thường làm chậm hệ thống. Anh em nào có Use Case nào hay về NetFlow hoặc gặp lỗi khi deploy, hãy thoải mái để lại bình luận bên dưới để cùng thảo luận nhé!

Quy trình khởi động mạng lớp phủ Cisco Catalyst SD-WAN

Huỳnh Tấn Đạt — Fri, 05 Jun 2026 03:04:52 GMT

1. Mục tiêu của quá trình Bring-Up

Mục tiêu là đưa toàn bộ hệ thống SD-WAN từ trạng thái chưa cấu hình thành một hệ thống hoạt động hoàn chỉnh:

Controller hoạt động
WAN Edge tham gia vào fabric
Thiết lập các kết nối control plane
Trao đổi route qua OMP
Tạo IPsec Tunnel giữa các site
Đẩy cấu hình từ vManage xuống thiết bị

Sau khi hoàn thành, các chi nhánh có thể liên lạc với nhau thông qua SD-WAN Overlay.

2. Các thành phần tham gia

vManage (Management Plane)

Giao diện quản trị tập trung
Cấu hình thiết bị
Theo dõi trạng thái mạng
Đẩy template xuống WAN Edge

Có thể xem như "bộ não quản lý".

vBond (Orchestration Plane)

Thành phần đầu tiên WAN Edge liên hệ
Xác thực thiết bị
Hỗ trợ NAT Traversal
Giới thiệu vSmart và vManage cho WAN Edge

Có thể hiểu là "người tiếp tân".

vSmart (Control Plane)

Chạy giao thức OMP
Phân phối route
Phân phối TLOC
Thực thi policy

Đây là "bộ não điều khiển".

WAN Edge (vEdge / cEdge)

Router tại các chi nhánh
Chuyển tiếp dữ liệu
Thiết lập IPsec Tunnel

Đây là Data Plane của hệ thống.

3. Trình tự Bring-Up

Cisco mô tả quy trình theo thứ tự sau:

1. Khởi động vManage
2. Khởi động vBond
3. Khởi động vSmart
4. Các controller xác thực lẫn nhau
5. vManage gửi cấu hình cho controller
6. WAN Edge khởi động
7. WAN Edge xác thực với vBond
8. WAN Edge xác thực với vManage
9. WAN Edge xác thực với vSmart
10. vManage đẩy cấu hình xuống WAN Edge

4. Quy trình kết nối thực tế

Bước 1: WAN Edge Boot

Router chi nhánh khởi động.

Lúc này router chỉ có:

IP WAN
System IP
Organization Name
Địa chỉ vBond

Ví dụ:

system
host-name BRANCH1
system-ip 1.1.1.1
site-id 100
organization-name COMPANY
vbond 100.100.100.100

Bước 2: WAN Edge tìm vBond

Router gửi kết nối DTLS/TLS tới vBond.

WAN Edge
|
|
v
vBond

Vai trò:

Xác minh chứng chỉ
Kiểm tra serial number
Kiểm tra thiết bị có được phép tham gia fabric hay không

Bước 3: vBond giới thiệu vSmart và vManage

Sau khi xác thực:

WAN Edge
|
|
vBond
/ \
vSmart vManage

vBond trả về:

IP vSmart
IP vManage

Bước 4: Kết nối Control Plane

WAN Edge thiết lập kết nối tới: vSmart

Nhận:

Route OMP
Policy
TLOC

vManage

Nhận:

Template
Monitoring
Telemetry

Bước 5: OMP hoạt động

OMP là giao thức riêng của Cisco SD-WAN.

Nó quảng bá: Route

Ví dụ:

10.10.10.0/24
10.20.20.0/24

TLOC

Transport Locator.

Ví dụ:

system-ip: 1.1.1.1
color: biz-internet
encap: ipsec

Service Route Thông tin dịch vụ.

5. Hình thành Overlay

Sau khi có route và TLOC:

Branch A -------- IPsec -------- Branch B

WAN Edge tự động tạo tunnel IPsec.

Không cần cấu hình tunnel thủ công như VPN truyền thống.
Link bài viết Cisco : https://www.cisco.com/c/en/us/td/doc...k-bringup.html

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.

IPv6 static route

dangquangminh — Thu, 04 Jun 2026 12:22:28 GMT

IPv6 Static Route: Vì Sao Chỉ Cần Sai Một Tham Số Là Toàn Bộ Lưu Lượng Có Thể Bị "Mất Tích"?

Khi học IPv6, nhiều kỹ sư mạng thường nghĩ rằng cấu hình static route cũng tương tự IPv4. Tuy nhiên, có một khác biệt rất quan trọng: IPv6 không sử dụng ARP mà sử dụng Neighbor Discovery Protocol (NDP). Chính sự khác biệt này khiến một số lỗi cấu hình static route trong IPv6 trở nên khó phát hiện hơn và có thể làm cho việc chuyển tiếp gói tin thất bại hoàn toàn. Cấu hình IPv6 Static Route

Để tạo một static route trong IPv6, sử dụng lệnh:
ipv6 route ipv6_prefix/prefix_length {ipv6_address | interface} [administrative_distance]

Ví dụ trên router R1:
R1(config)# ipv6 route 2001:DB8:0:3::/64 gigabitEthernet1/0 FE80::2 8

Ý nghĩa:

Mạng đích: 2001:DB8:0:3::/64
Next-hop: FE80::2 (địa chỉ Link-Local của R2)
Interface thoát: GigabitEthernet1/0
Administrative Distance (AD): 8

Tại sao phải chỉ rõ interface khi dùng Link-Local Address?

Khác với Global Unicast Address, địa chỉ Link-Local (FE80::/10) chỉ có ý nghĩa trong phạm vi một liên kết (link).

Ví dụ:
R1 ----- R2
FE80::2

R1 ----- R4
FE80::2

Hoàn toàn có thể tồn tại nhiều thiết bị sử dụng cùng địa chỉ FE80::2 trên các liên kết khác nhau.

Do đó khi cấu hình static route:
ipv6 route 2001:DB8:0:3::/64 FE80::2

Router sẽ không biết phải tìm FE80::2 trên interface nào.

Vì vậy Cisco bắt buộc phải khai báo thêm interface:
ipv6 route 2001:DB8:0:3::/64 GigabitEthernet1/0 FE80::2

Nếu next-hop là Global Unicast Address thì không cần chỉ định interface.

Kiểm tra Static Route

Sử dụng lệnh:
show ipv6 route static

Kết quả:
R1# show ipv6 route static

S 2001:DB8:0:3::/64 [8/0]
via FE80::2, GigabitEthernet1/0

Giải thích:

S = Static Route
8 = Administrative Distance
0 = Metric

Metric của static route mặc định bằng 0 vì static route không có cơ chế tính toán chi phí đường đi như OSPF hay EIGRP.

IPv6 Không Có ARP

Trong IPv4:
IP Address -> ARP -> MAC Address

Trong IPv6:
IPv6 Address -> NDP -> MAC Address

IPv6 sử dụng Neighbor Discovery Protocol (NDP) dựa trên multicast để tìm địa chỉ MAC của thiết bị lân cận.

Khi R1 cần gửi gói tin đến mạng:
2001:DB8:0:3::/64

Bảng định tuyến cho biết next-hop là:
FE80::2

Lúc này R1 sẽ tra cứu bảng Neighbor Table.
R1# show ipv6 neighbors

Ví dụ:
IPv6 Address Age Link-layer Addr State Interface
FE80::2 0 ca08.0568.0008 REACH Gi1/0

Router phải tìm thấy đồng thời:

Đúng địa chỉ Link-Local (FE80::2)
Đúng interface (Gi1/0)

Nếu không tìm thấy, router sẽ gửi Neighbor Solicitation (NS) để hỏi MAC tương ứng.

Lỗi Thường Gặp: Directly Attached Static Route

Một lỗi cấu hình phổ biến là:
ipv6 route 2001:DB8:0:3::/64 GigabitEthernet1/0

Đây được gọi là:

Directly Attached Static Route

Lệnh này nói với R1 rằng:

"Mạng 2001:DB8:0:3::/64 nằm trực tiếp trên cổng Gig1/0."

Trong thực tế điều này không đúng vì mạng đó nằm phía sau R2.

Điều Gì Sẽ Xảy Ra?

Giả sử R1 nhận được gói tin có đích:
2001:DB8:0:3::3

R1 nhìn vào routing table và tin rằng địa chỉ này nằm trực tiếp trên Gig1/0.

Do đó nó sẽ không tìm MAC của R2.

Thay vào đó nó sẽ cố gắng tìm MAC của chính địa chỉ đích:
2001:DB8:0:3::3

Router gửi Neighbor Solicitation tới địa chỉ multicast:
FF02::1:FF00:3

để hỏi:

"Ai đang sở hữu địa chỉ 2001:DB8:0:3::3?"

Nhưng trên mạng Gig1/0 không có thiết bị nào sở hữu địa chỉ đó.

Kết quả:

Không có Neighbor Advertisement trả lời.
Không học được MAC Address.
NDP thất bại.
Layer 2 Encapsulation thất bại.
Gói tin bị loại bỏ.

Góc Nhìn Thực Chiến

Khi troubleshooting IPv6 static route, hãy kiểm tra theo thứ tự:

Static route có khai báo đúng next-hop không?
Nếu dùng Link-Local Address, đã khai báo interface chưa?
Bảng Neighbor Table có entry tương ứng không?

show ipv6 neighbors

Có vô tình cấu hình Directly Attached Static Route trên Ethernet hay không?
Neighbor Solicitation và Neighbor Advertisement có hoạt động bình thường không?

TÓM TẮT

IPv6 static route nhìn bề ngoài khá giống IPv4 nhưng cơ chế hoạt động bên dưới hoàn toàn khác do IPv6 sử dụng NDP thay cho ARP. Khi dùng địa chỉ Link-Local làm next-hop, luôn phải chỉ rõ interface thoát. Một lỗi cấu hình nhỏ như sử dụng Directly Attached Static Route trên Ethernet có thể khiến router gửi Neighbor Solicitation đến một địa chỉ không tồn tại, dẫn đến thất bại trong quá trình đóng gói Layer 2 và làm mất hoàn toàn khả năng chuyển tiếp lưu lượng. Đây là một trong những lỗi IPv6 rất thường gặp khi triển khai hoặc troubleshooting trong môi trường thực tế CCNA, CCNP và CCIE.