Vietnamese Professional - CCNP ENCOR

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?

[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é!

Tiến trình tiến hóa của khung lưu lượng lớp 3: Từ ip precedence đến cơ chế dscp hiện đại

ThanhQuyen — Thu, 04 Jun 2026 09:56:40 GMT

TIẾN TRÌNH TIẾN HÓA CỦA KHUNG LƯU LƯỢNG LỚP 3: TỪ IP PRECEDENCE ĐẾN CƠ CHẾ DSCP HIỆN ĐẠI

Trong kiến trúc Quản trị mạng và Thiết kế hệ thống, việc tối ưu hóa băng thông tại Lớp 3 luôn đòi hỏi các kỹ sư phải can thiệp trực tiếp vào cấu trúc của IP Header. Khác với trường CoS (Class of Service) vốn chỉ tồn tại trong thẻ Tag 802.1Q ở Lớp 2 trên các đường truyền Trunking, Lớp 3 sở hữu một phân vùng dữ liệu cốt lõi giúp định hình toàn bộ hành vi truyền dẫn end-to-end: đó là TOS Byte (Type of Service).
Trải qua hơn 4 thập kỷ phát triển, việc định nghĩa và sử dụng TOS Byte đã có những bước chuyển dịch công nghệ quan trọng, trực tiếp quyết định cách thức các thiết bị định tuyến Cisco xử lý hàng đợi. 1. Giai đoạn khởi đầu (1981 - 1992): IP Precedence & TOS Bits

Được định nghĩa lần đầu tiên trong văn bản RFC 791 (năm 1981), cấu trúc 8 bits của TOS Byte được chia tách thành hai phân vùng chức năng riêng biệt:

3 Bits đầu tiên (Bit 0 - 2): Được gọi là IP Precedence. Giá trị này đại diện cho độ ưu tiên của gói tin theo nguyên tắc: Giá trị càng cao, mức độ quan trọng càng lớn. Khi xảy ra hiện tượng nghẽn mạch, thiết bị định tuyến sẽ thực hiện cơ chế hủy bỏ các gói tin có IP Precedence thấp trước.

$$\text{Mã hóa IP Precedence: } 000 \text{ (Routine)} \rightarrow 111 \text{ (Network Control)} \text{[cite: 5]}$$

5 Bits tiếp theo (Bit 3 - 7): Được gọi là các Type of Service bits dùng để yêu cầu các tuyến đường đáp ứng tiêu chí về độ trễ thấp (low delay), băng thông cao (high throughput), hoặc độ tin cậy cao (high reliability).

Đến năm 1992, văn bản RFC 1349 đã tinh chỉnh lại phân vùng này: rút ngắn cấu trúc xuống còn 4 bits chuyên biệt (bao gồm các tùy chọn như minimize delay, maximize throughput) và giữ lại bit cuối cùng làm MBZ (Must Be Zero). Tuy nhiên, trên thực tế vận hành mạng toàn cầu, các bits quy định Type of Service này gần như không bao giờ được sử dụng, hệ thống chỉ phụ thuộc duy nhất vào 3 bits của IP Precedence. 2. Kỷ nguyên hiện đại (1998 - Nay): Kiến trúc Differentiated Services (DiffServ)

Nhằm tối ưu hóa khả năng phân cấp lưu lượng và mở rộng số lượng mức độ ưu tiên, vào năm 1998, văn bản RFC 2474 chính thức ra đời, thay đổi hoàn toàn định nghĩa của TOS Byte thành DS Field (Differentiated Services Field).
Trong cấu trúc mới này, 8 bits của DS Field được phân rã như sau:

6 Bits đầu tiên (Bit 0 - 5): Được gọi là DSCP (Differentiated Services Code Point). Với 6 bits, hệ thống mạng có thể tạo ra tối đa $2^6 = 64$ giá trị ưu tiên khác nhau, mang lại tính linh hoạt vượt trội so với chỉ 8 giá trị của IP Precedence.

2 Bits cuối cùng (Bit 6 - 7): Được gọi là CU (Currently Unused), các node mạng khi xử lý PHB sẽ bỏ qua giá trị của hai bits này.

Giá trị DSCP sẽ trực tiếp quyết định PHB (Per Hop Behavior) – tức là hành vi xử lý cụ thể (như xếp hàng đợi, giới hạn băng thông hoặc chủ động hủy gói) của từng Router tại mỗi bước nhảy mạng khi gói tin đi qua. Để DiffServ đạt hiệu quả tối ưu, cấu hình QoS bắt buộc phải được triển khai đồng bộ End-to-End trên toàn bộ lộ trình vật lý. 3. Các chuẩn mực Per Hop Behavior (PHB) ứng dụng thực tế

3.1. Class-Selector PHB: Khả năng tương thích ngược

Để đảm bảo các thiết bị đời mới sử dụng cấu trúc DiffServ vẫn có thể giao tiếp đồng bộ với các thiết bị đời cũ chỉ hỗ trợ IP Precedence, cơ chế Class-Selector được thiết lập bằng cách chỉ sử dụng 3 bits đầu tiên và cố định 3 bits tiếp theo bằng giá trị 000.

Ví dụ: Mã CS1 tương đương dòng nhãn Priority (giá trị nhị phân 001000), hoặc CS4 tương đương dòng nhãn Flash Override (giá trị nhị phân 100000).

3.2. Assured Forwarding (AF) PHB: Quản lý hàng đợi và Tránh nghẽn nâng cao

Được định nghĩa trong RFC 2597, nhóm AF phân chia gói tin thành 4 Class khác nhau (tương ứng với 4 hàng đợi vật lý). Trong mỗi Class lại tiếp tục chia thành 3 mức độ cảnh báo hủy gói khi xảy ra nghẽn (Drop Precedence: Thấp - Trung bình - Cao).

Công thức chuyển đổi nhanh sang hệ thập phân:

$$\text{Decimal Value} = 8x + 2y$$
$$\text{(Trong đó: } x = \text{chỉ số Class từ 1 đến 4; } y = \text{chỉ số Drop Precedence từ 1 đến 3)} \text{[cite: 5]}$$
Ví dụ áp dụng: Để tính giá trị thập phân của nhãn AF31 ($x=3, y=1$), ta áp dụng công thức: $8 \times 3 + 2 \times 1 = 26$. 3.3. Expedited Forwarding (EF) PHB: Đặc quyền cho lưu lượng Thời gian thực

Đối với các ứng dụng nhạy cảm tối đa với độ trễ và biến động trễ (Jitter) như dữ liệu Voice (VoIP), nhãn EF (giá trị nhị phân 101110, tương đương giá trị thập phân 46) sẽ được áp dụng. Các gói tin mang nhãn EF sẽ được đưa thẳng vào Priority Queue (Hàng đợi ưu tiên nghiêm ngặt) và được đẩy đi trước tất cả các hàng đợi khác nhằm triệt tiêu độ trễ. 4. Thực tế triển khai hệ thống: Triết lý vận hành của Router

Một điểm mấu chốt mà mọi kỹ sư CCIE cần lưu ý: Bản thân các giá trị DSCP hay IP Precedence được đánh dấu trên gói tin sẽ không tự động làm thay đổi hành vi của thiết bị. Router sẽ hoàn toàn giữ nguyên trạng thái Best-Effort nếu người quản trị không chủ động cấu hình các chính sách (Action) thông qua công cụ MQC (Modular QoS CLI).
Dựa trên các tài liệu hướng dẫn thiết kế chuẩn hóa của Cisco (Cisco Validated Designs):

Lưu lượng Voice Traffic (Dữ liệu thoại) luôn được khuyến nghị áp dụng nhãn DSCP EF (hoặc IP Precedence 5).

Lưu lượng Call Signaling (Tín hiệu thiết lập cuộc gọi) luôn được khuyến nghị áp dụng nhãn DSCP CS3 hoặc AF31 (hoặc IP Precedence 3).

LÀM CHỦ KIẾN TRÚC QOS NÂNG CAO CÙNG CHUYÊN GIA CCIE TẠI VNPRO
QoS và cấu trúc phân cấp IP Header là phần kiến thức bắt buộc, chiếm tỷ trọng điểm số lớn trong các kỳ thi quốc tế cao cấp như CCNP Enterprise và CCIE Enterprise Infrastructure Lab. Để chuyển hóa các lý thuyết phức tạp này thành kỹ năng cấu hình thực tế trên thiết bị Cisco IOS XE, hãy tham gia ngay các khóa đào tạo chuyên sâu tại VnPro.

Liên hệ đăng ký & Tư vấn lộ trình: Học viên vui lòng trao đổi trực tiếp qua Hotline/Zalo 093 3427 079 để nhận khung chương trình chi tiết.

Cập nhật lịch khai giảng mới nhất: Truy cập hệ thống thông tin tại vnpro.vn.

KIẾN TRÚC QoS TRONG TỐI ƯU HÓA HIỆU NĂNG HỆ THỐNG MẠNG DOANH NGHIỆP

ThanhQuyen — Thu, 04 Jun 2026 09:12:59 GMT

KIẾN TRÚC QoS TRONG TỐI ƯU HÓA HIỆU NĂNG HỆ THỐNG MẠNG DOANH NGHIỆP

Trong môi trường vận hành mạng doanh nghiệp, một trong những thách thức lớn nhất của người quản trị là đảm bảo tính ổn định và liên tục của các dịch vụ cốt lõi khi hệ thống xảy ra hiện tượng nghẽn mạch. Theo cơ chế hoạt động mặc định, các thiết bị định tuyến (Router) và chuyển mạch (Switch) vận hành theo mô hình Best-Effort (hoặc FIFO - First In First Out). Thiết bị chỉ thực hiện chức năng đọc thông tin lớp 2 (MAC đích) hoặc lớp 3 (IP đích) để chuyển tiếp gói tin mà hoàn toàn không phân biệt được bản chất của lưu lượng đó là gì.

Sự bình đẳng này vô hình trung lại chính là nguyên nhân gây ra sự suy giảm chất lượng dịch vụ khi xảy ra nghẽn mạch. Việc triển khai kiến trúc Quality of Service (QoS) dựa trên tài liệu chuyên sâu "Introduction to QoS (Quality of Service).pdf" chính là giải pháp cốt lõi để giải quyết bài toán phân phối tài nguyên này. 1. Bốn thông số cốt lõi cấu thành chất lượng mạng

Để thiết kế và triển khai QoS thành công, kỹ sư mạng cần phải kiểm soát bốn đặc tính kỹ thuật sau:

Bandwidth (Băng thông): Tốc độ truyền dẫn trên đường truyền, tính bằng bit trên giây (bps). QoS cho phép thay đổi cơ chế FIFO bằng cách phân chia băng thông theo tỷ lệ phần trăm cố định cho từng nhóm dịch vụ.
Delay (Độ trễ): Thời gian gói tin di chuyển từ nguồn đến đích. Kỹ sư cần phân biệt rõ trễ xử lý (Processing delay tại CPU), trễ tuần tự hóa (Serialization delay tại cổng vật lý), trễ truyền dẫn (Propagation delay trên môi trường cáp) và quan trọng nhất là trễ hàng đợi (Queuing delay) – loại trễ duy nhất mà QoS có thể can thiệp tối ưu.
Jitter (Độ biến động trễ): Sự sai lệch về khoảng thời gian giữa các gói tin liên tiếp trong cùng một luồng dữ liệu. Jitter cao là tác nhân trực tiếp làm méo tiếng hoặc gián đoạn các cuộc gọi VoIP.
Loss (Tỷ lệ mất gói): Khi hàng đợi của thiết bị vượt quá dung lượng tối đa, hiện tượng Tail Drop sẽ xảy ra và Router sẽ hủy bỏ tất cả gói tin đến sau.

2. Phân loại ứng dụng và các ngưỡng kỹ thuật tiêu chuẩn

Hệ thống mạng doanh nghiệp hiện nay bao gồm ba nhóm lưu lượng chính với các yêu cầu kỹ thuật hoàn toàn khác nhau:

Batch Application (Ứng dụng theo lô): Các tác vụ như truyền tải file FTP, tải dữ liệu hoặc cập nhật hệ thống. Nhóm này chạy trên nền TCP, đòi hỏi băng thông cao nhưng không nhạy cảm với trễ hay jitter vì TCP có cơ chế tự động truyền lại gói tin lỗi.
Interactive Application (Ứng dụng tương tác): Các lưu lượng như Telnet, SSH hoặc các phần mềm ERP. Nhóm này không chiếm nhiều băng thông nhưng yêu cầu độ trễ thấp để đảm bảo thời gian phản hồi cho người dùng cuối.
Voice & Video Application (Ứng dụng thời gian thực): Đây là nhóm lưu lượng nhạy cảm nhất đối với các thông số delay, jitter và loss.

Ví dụ giải thích về VoIP: Khi một người thực hiện cuộc gọi sử dụng codec G.711, âm thanh analog sẽ được số hóa liên tục sau mỗi 20ms thành một phân đoạn dữ liệu 160 bytes. Khi đóng gói qua các tầng với tiêu đề IP, UDP và RTP, gói tin sẽ có dung lượng tổng cộng là 200 bytes (tương đương tốc độ 80 Kbps). Để đảm bảo chất lượng cuộc gọi không bị suy giảm, hệ thống mạng phải đáp ứng nghiêm ngặt các thông số: Độ trễ một chiều (One-way delay) < 150ms, Jitter < 30ms, và Tỷ lệ mất gói (Loss) < 1%. 3. Bộ công cụ thực thi QoS trong thiết bị Cisco

Để hiện thực hóa việc ưu tiên lưu lượng, kiến trúc QoS cung cấp 4 nhóm công cụ chính:

Classification & Marking (Phân loại và Đánh dấu): Sử dụng các kỹ thuật như Access-List (ACL) hoặc nhận diện ứng dụng tầng sâu (NBAR) để phân loại dữ liệu. Sau khi phân loại, thiết bị sẽ đánh dấu mức độ ưu tiên vào trường ToS (Type of Service) trên IP header hoặc trường Priority trong tag 802.1Q ở lớp 2. Việc đánh dấu giúp các Router tuyến sau không phải tốn tài nguyên xử lý lại các ACL phức tạp.
Congestion Management (Quản lý nghẽn): Áp dụng cơ chế xếp hàng đợi phân cấp. Đối với dữ liệu thông thường, cơ chế Class-Based Weighted Fair Queuing (CBWFQ) sẽ phân chia băng thông tối thiểu theo tỷ lệ phần trăm cố định (ví dụ: 50% - 20% - 30%) khi xảy ra nghẽn mạch. Riêng đối với lưu lượng thoại, kỹ thuật Low Latency Queuing (LLQ) sẽ thiết lập một hàng đợi ưu tiên nghiêm ngặt (Strict Priority Queue) để chuyển tiếp gói tin thoại ngay lập tức mà không phải xếp hàng chờ đợi.
Policing & Shaping (Giới hạn lưu lượng): Policing thực hiện việc áp đặt một giới hạn cứng (CIR) lên băng thông, các gói tin vượt ngưỡng sẽ bị hủy ngay lập tức (thường dùng ở phía ISP). Ngược lại, Shaping (thường cấu hình ở phía Router doanh nghiệp) sẽ giữ các gói tin vượt ngưỡng lại trong hàng đợi buffer và đẩy ra từ từ để tránh tình trạng gói tin bị ISP hủy bỏ.
Congestion Avoidance (Tránh nghẽn): Thay vì để hàng đợi rơi vào trạng thái Tail Drop (hủy toàn bộ gói tin khi đầy), công cụ WRED sẽ giám sát dung lượng hàng đợi chủ động và hủy ngẫu nhiên các gói tin TCP khi đạt đến ngưỡng thiết lập (Minimum Threshold). Hành động này kích hoạt cơ chế Slow-start của TCP, buộc các nguồn phát giảm tốc độ truyền tải trước khi hiện tượng nghẽn thực sự xảy ra.

Kết luận

Triển khai QoS không đơn thuần là tăng băng thông đường truyền, mà là việc sử dụng thông minh các công cụ để phân phối tài nguyên mạng một cách hợp lý và khoa học. Việc thấu hiểu các công cụ quản lý hàng đợi và cơ chế kiểm soát lưu lượng sẽ giúp các kỹ sư xây dựng được một hệ thống mạng vững chắc, sẵn sàng đáp ứng mọi dịch vụ chất lượng cao của doanh nghiệp.

Để làm chủ toàn diện các giải pháp QoS nâng cao và chuẩn bị cho các kỳ thi chứng chỉ quốc tế cao cấp như CCNP/CCIE Enterprise Infrastructure, bạn hãy đăng ký tham gia các khóa học chuyên sâu tại VnPro dưới sự dẫn dắt của đội ngũ giảng viên giàu kinh nghiệm thực tế.

📲 Hotline/Zalo tư vấn: 093 3427 079
🌐 Website :vnpro.vn

Chặn Website trên Cisco Router bằng NBAR – Không cần biết IP vẫn có thể lọc được ứng dụng

ThanhQuyen — Thu, 04 Jun 2026 08:21:50 GMT

Chặn Website trên Cisco Router bằng NBAR – Không cần biết IP vẫn có thể lọc được ứng dụng

Khi nhắc đến việc chặn truy cập website trên Router Cisco, đa số kỹ sư mạng thường nghĩ ngay đến ACL (Access Control List).
Ví dụ muốn chặn YouTube, cách làm truyền thống là:

Tìm toàn bộ địa chỉ IP mà YouTube đang sử dụng

Tạo Access-list để deny các địa chỉ đó

Cập nhật liên tục khi IP thay đổi

Nghe có vẻ đơn giản, nhưng thực tế gần như bất khả thi đối với các dịch vụ lớn như YouTube, Facebook, Google hay Microsoft 365.
Vậy có cách nào để Router nhận biết trực tiếp ứng dụng hoặc website mà người dùng đang truy cập thay vì chỉ nhìn vào địa chỉ IP?
Câu trả lời là NBAR (Network Based Application Recognition).
Đây là một trong những công nghệ rất thú vị của Cisco QoS, cho phép Router nhận diện lưu lượng ở tầng ứng dụng (Application Layer) và đưa ra chính sách xử lý phù hợp. NBAR là gì?

Thông thường ACL chỉ có thể kiểm tra các thông tin như:

Địa chỉ IP nguồn

Địa chỉ IP đích

Protocol

Port Number

Hay nói cách khác, Router chủ yếu hoạt động dựa trên thông tin của Layer 1, Layer 2, Layer 3 và Layer 4.
NBAR bổ sung thêm khả năng nhận diện:
Application Layer
Điều này cho phép Router hiểu được:

Người dùng đang truy cập website nào

Đang sử dụng ứng dụng gì

Đang truyền loại lưu lượng nào

Đây chính là lý do NBAR thường được sử dụng trong:

QoS Classification

Traffic Filtering

Application Visibility

Network Monitoring

Ý tưởng chặn YouTube bằng NBAR

Giả sử doanh nghiệp muốn hạn chế nhân viên truy cập:
youtube.com
Nếu sử dụng ACL thông thường, chúng ta phải thu thập rất nhiều địa chỉ IP của YouTube.
Trong khi đó với NBAR, Router có thể nhận diện trực tiếp hostname của website.
Ví dụ:
class-map match-any BLOCKED
match protocol http host "*youtube.com*" Phân tích cấu hình

Đầu tiên tạo Class-map:
R1(config)#class-map match-any BLOCKED
R1(config-cmap)#match protocol http host "*youtube.com*"
Trong đó:
*youtube.com*
có nghĩa là:

Khớp youtube.com

Khớp www.youtube.com

Khớp m.youtube.com

Khớp các sub-domain khác của YouTube

Dấu:
*
được sử dụng như ký tự đại diện (wildcard).
Điều này giúp chính sách linh hoạt hơn rất nhiều. Tạo Policy-map để xử lý lưu lượng

Sau khi đã nhận diện được lưu lượng, bước tiếp theo là tạo hành động.
Ví dụ:
R1(config)#policy-map DROP
R1(config-pmap)#class BLOCKED
R1(config-pmap-c)#drop
Ý nghĩa:
Khi Router phát hiện lưu lượng khớp với class BLOCKED thì:
DROP
hay nói cách khác:
Loại bỏ gói tin Áp dụng Policy vào Interface

Tiếp theo áp dụng Policy-map lên interface kết nối ra Internet:
R1(config)#interface FastEthernet0/1
R1(config-if)#service-policy output DROP
Sau khi kích hoạt:

Người dùng vẫn truy cập Internet bình thường

Các website khác vẫn hoạt động

Chỉ riêng lưu lượng truy cập YouTube bị chặn

Đây là cách triển khai rất đơn giản nhưng hiệu quả. Kiểm tra kết quả

Sau khi người dùng thử truy cập YouTube, có thể kiểm tra bằng:
show policy-map interface FastEthernet0/1
Kết quả:
Class-map: BLOCKED

1 packets, 500 bytes

Match: protocol http host "*youtube.com*"

drop
Điều này cho thấy Router đã:

Nhận diện đúng YouTube

Match đúng lưu lượng

Thực hiện hành động Drop

Đây là bước rất quan trọng khi Troubleshooting QoS hoặc NBAR. Vì sao NBAR nhận diện được YouTube?

Khi truy cập một website bằng HTTP, trình duyệt sẽ gửi yêu cầu:
GET / HTTP/1.1
Host: www.youtube.com
Thông tin hostname xuất hiện dưới dạng văn bản rõ ràng (Plain Text).
NBAR đọc trường này và so sánh với điều kiện đã cấu hình.
Nếu trùng khớp:
youtube.com
Router sẽ áp dụng chính sách tương ứng. Một hạn chế rất quan trọng của NBAR

Đây là phần mà nhiều kỹ sư mới học thường bỏ qua.
NBAR trong ví dụ này chỉ hoạt động với:
HTTP
không hoạt động với:
HTTPS Tại sao HTTPS lại khác?

Với HTTP:
Router có thể nhìn thấy:
GET / HTTP/1.1
Host: youtube.com
vì toàn bộ dữ liệu được gửi dưới dạng Plain Text.
Nhưng với HTTPS:

Nội dung được mã hóa SSL/TLS

Hostname và dữ liệu ứng dụng không còn hiển thị rõ ràng

Router không thể đọc được nội dung bên trong gói tin

Do đó NBAR không thể xác định chính xác website mà người dùng đang truy cập theo cách này. Ví dụ thực tế

Khi mở YouTube bằng:
http://youtube.com
Router có thể đọc được hostname.
Nhưng khi truy cập:
https://youtube.com
Router chỉ nhìn thấy:
TLS/SSL Encrypted Traffic
và không thể đọc được nội dung HTTP bên trong.
Đây là lý do vì sao hầu hết các giải pháp kiểm soát web hiện đại thường kết hợp:

Proxy Server

Secure Web Gateway

Next-Generation Firewall

SSL Inspection

thay vì chỉ sử dụng ACL hoặc NBAR đơn thuần. Cấu hình hoàn chỉnh

hostname R1

ip cef

class-map match-any BLOCKED
match protocol http host "*youtube.com*"

policy-map DROP
class BLOCKED
drop

interface FastEthernet0/1
ip address 192.168.1.1 255.255.255.0
service-policy output DROP Kết luận

NBAR là một công nghệ rất hữu ích trên Cisco IOS giúp Router nhận diện lưu lượng ở tầng ứng dụng thay vì chỉ dựa vào IP Address hay Port Number.
Thông qua NBAR, chúng ta có thể:

Nhận diện ứng dụng

Phân loại lưu lượng

Áp dụng QoS

Thực hiện Filtering thông minh hơn ACL truyền thống

Tuy nhiên cần nhớ rằng:
NBAR có thể nhận diện tốt lưu lượng HTTP.
Với HTTPS được mã hóa SSL/TLS, khả năng nhận diện sẽ bị hạn chế nếu không có thêm các giải pháp phân tích chuyên sâu.
Đây cũng là một trong những lý do khiến NBAR trở thành chủ đề quan trọng trong các chương trình học:

CCNP Enterprise (ENCOR)

Network Security

Cisco IOS XE

Trong hệ thống của bạn, nếu cần chặn Facebook, YouTube hoặc các ứng dụng SaaS hiện đại, bạn sẽ lựa chọn NBAR, ACL hay Next-Generation Firewall?
Hãy chia sẻ kinh nghiệm thực tế cùng cộng đồng Quản Trị Mạng VnPro!
Muốn học chuyên sâu về QoS, NBAR, Security, SD-WAN, BGP, MPLS và các công nghệ Enterprise thực chiến?
Liên hệ VnPro để được tư vấn lộ trình từ CCNA → CCNP Enterprise → CCIE Enterprise Infrastructure cùng đội ngũ giảng viên nhiều năm kinh nghiệm triển khai thực tế.
Hotline/Zalo: 093 3427 079
Website: vnpro.vn

#VnPro #QuanTriMang #Cisco #CCNP #ENCOR #CCIE #NBAR #QoS #CiscoIOS #NetworkSecurity #ApplicationRecognition #EnterpriseNetworking #NetworkEngineer #HocCCNP #CiscoEnterprise

Chặn Website trên Cisco Router bằng NBAR – Không cần biết IP vẫn có thể lọc được ứng dụng

ThanhQuyen — Thu, 04 Jun 2026 08:07:35 GMT

Tìm toàn bộ địa chỉ IP mà YouTube đang sử dụng

Tạo Access-list để deny các địa chỉ đó

Cập nhật liên tục khi IP thay đổi

Địa chỉ IP nguồn

Địa chỉ IP đích

Protocol

Port Number

Người dùng đang truy cập website nào

Đang sử dụng ứng dụng gì

Đang truyền loại lưu lượng nào

Đây chính là lý do NBAR thường được sử dụng trong:

QoS Classification

Traffic Filtering

Application Visibility

Network Monitoring

Khớp youtube.com

Khớp www.youtube.com

Khớp m.youtube.com

Khớp các sub-domain khác của YouTube

Người dùng vẫn truy cập Internet bình thường

Các website khác vẫn hoạt động

Chỉ riêng lưu lượng truy cập YouTube bị chặn

Nhận diện đúng YouTube

Match đúng lưu lượng

Thực hiện hành động Drop

Nội dung được mã hóa SSL/TLS

Hostname và dữ liệu ứng dụng không còn hiển thị rõ ràng

Router không thể đọc được nội dung bên trong gói tin

Proxy Server

Secure Web Gateway

Next-Generation Firewall

SSL Inspection

Nhận diện ứng dụng

Phân loại lưu lượng

Áp dụng QoS

Thực hiện Filtering thông minh hơn ACL truyền thống

CCNP Enterprise (ENCOR)

Network Security

Cisco IOS XE

CCNP ENCOR OFFLINE Khai Giảng Tháng 6 – Nâng Cấp Kỹ Năng Network Chuyên Sâu

hongnhungvnpro — Wed, 03 Jun 2026 02:36:35 GMT

Làm Network nhiều năm nhưng chỉ dừng ở cấu hình cơ bản?
Muốn lên Senior nhưng chưa nắm vững Routing, MPLS, VPN, QoS, SD-WAN?
Đọc tài liệu ENCOR hiểu nhưng vào lab không triển khai được?
ENCOR là một trong những bước quan trọng nếu bạn muốn tiến xa hơn trong nghề Network.
Khóa ENCOR OFFLINE
Học tối 2-4-6 | 18h30 – 21h00
Tặng balo VnPro phiên bản giới hạn cho học viên đăng ký sớm.
-----------
Số lượng slot có hạn – Inbox đăng ký ngay!
Hotline/Zalo: 0933 427 079
Như Ngọc: 076 5944 386
Anh Thư: 033 9943 732
Hồng Nhung: 038 3920 627
276 - 278 Ung Văn Khiêm, P. Thạnh Mỹ Tây, TP.HCM

CCNP ENCOR - Bước Đệm Lên Tầm Network Engineer

Nguyễn Thị Khánh Hương — Wed, 03 Jun 2026 01:50:07 GMT

Làm Network nhiều năm nhưng chỉ dừng ở cấu hình cơ bản?
Muốn lên Senior nhưng chưa nắm vững Routing, MPLS, VPN, QoS, SD-WAN?
Đọc tài liệu CCNP ENCOR hiểu nhưng vào lab không triển khai được?

CCNP ENCOR là một trong những bước quan trọng nếu bạn muốn tiến xa hơn trong nghề Network.

Khóa CCNP ENCOR OFFLINE
Học tối 2-4-6 | 18h30 – 21h00
Tặng balo VnPro phiên bản giới hạn cho học viên đăng ký sớm.

-----------
Số lượng slot có hạn – Inbox đăng ký ngay!
Hotline/Zalo: 0933 427 079
Như Ngọc: 076 5944 386
Anh Thư: 033 9943 732
Hồng Nhung: 038 3920 627
276 - 278 Ung Văn Khiêm, P. Thạnh Mỹ Tây, TP.HCM

Bắt Bệnh IP SLA & Những "Cú Lừa" Cấu Hình Track Route Trớ Trêu!

Lương Thị Thùy — Mon, 01 Jun 2026 12:21:31 GMT

Link cáp quang đi quốc tế đứt phựt, mạng thì rớt thê thảm, nhưng cổng WAN trên Router vẫn kiên cường báo trạng thái "Up/Up". Kết quả? Định tuyến mặc định không chịu đổi, traffic cứ thế đi vào "hố đen" mà không tự động chuyển sang đường Backup. Giải pháp cứu cánh kinh điển của dân Network chúng ta lúc này chính là IP SLA kết hợp Object Tracking!

1. Bản chất của IP SLA: Chủ động chứ không thụ động!

Khác với NetFlow thường chỉ ngồi im "hứng" và phân tích lưu lượng, IP SLA liên tục "chủ động" tạo và bơm các gói tin nhân tạo (probe) vào mạng để đo lường. Điểm hay của công nghệ này là nó hoàn toàn độc lập với lớp 2 (Layer 2 transport-independent).
Dù bạn chạy trên nền cáp quang, Metro Ethernet hay đường hầm, IP SLA vẫn bám sát được trạng thái mạng với các chỉ số chi tiết từ độ trễ, packet loss cho đến chất lượng thoại MOS (Mean Opinion Score).

2. Bẫy số 1: Quên "Track" trong định tuyến tĩnh

Bạn hì hục gõ đủ combo: tạo ip sla, đặt timeout, hẹn giờ schedule chạy vĩnh viễn, gán track object đàng hoàng. Nhưng khi rút dây WAN để test thử, default route vẫn nằm chễm chệ trong bảng định tuyến! Lý do muôn thuở? Câu lệnh định tuyến tĩnh thiếu mất chiếc đuôi quan trọng nhất.

Lệnh thiếu: ip route 0.0.0.0 0.0.0.0 172.20.20.2
Lệnh chuẩn: ip route 0.0.0.0 0.0.0.0 172.20.20.2 track 10

Chỉ một từ khóa bị bỏ quên cũng đủ khiến toàn bộ kịch bản dự phòng trở nên vô dụng.

3. Bẫy số 2: Ping đi được nhưng không có đường về

Đây là lỗi cực kỳ nhức nhối khi làm lab đa định tuyến. Anh em cấu hình lệnh: icmp-echo 172.20.20.2 source-interface FastEthernet0/0 (với Fa0/0 là cổng LAN). Gói tin ping đi ra đến Router của ISP thành công, nhưng ISP lại ném bỏ gói tin Reply vì nó mang địa chỉ đích là IP Private của mạng LAN (mạng mà ISP hoàn toàn không biết đường trả về). Lúc này IP SLA báo trạng thái Down, kéo theo đường truyền chính bị đánh sập một cách oan uổng!

Giải pháp: Hãy source gói tin ping từ chính cổng WAN đấu nối trực tiếp với ISP, hoặc phải đảm bảo thiết bị đầu xa có định tuyến tĩnh trả về mạng LAN của bạn.

4. IP SLA Responder: Khi nào thực sự cần thiết?

Nếu bài toán chỉ là track ping (ICMP Echo) để xem link còn sống hay không, anh em không cần cấu hình gì ở đầu đích. Nhưng nếu triển khai các ứng dụng nhạy cảm (như Voice, Video) và cần đo độ trễ biến thiên (UDP Jitter), thiết bị đầu xa BẮT BUỘC phải được bật tính năng ip sla responder. Nếu không có một tiến trình đứng ra "hứng" và tính toán tem thời gian (timestamp) ở Router đối diện, phép đo Jitter sẽ không thể thực hiện được.

Nắm chắc nguyên lý hoạt động và hiểu sâu về cơ chế định tuyến ngược của gói tin Probe sẽ giúp bạn làm chủ hoàn toàn IP SLA, tự tin vượt qua các câu hỏi hóc búa của đề thi ENCOR.
Hệ thống của bạn có đang dùng IP SLA để tracking link không, hay mọi người ưu tiên dùng giao thức định tuyến động để tự hội tụ?

Network Assurance: "Bắt Mạch" Hệ Thống Bằng Syslog, EEM & Đọc Vị Traceroute

Lương Thị Thùy — Mon, 01 Jun 2026 11:18:11 GMT

Network Assurance luôn là một mảng kiến thức cực kỳ thực tế và cũng đầy tính "cảnh giác". Làm sao để hệ thống tự động báo lỗi chính xác? Làm sao để gửi log bảo mật? Hay đơn giản là nhìn vào kết quả traceroute để biết ngay firewall/ACL nào đang chặn luồng traffic?
Hôm nay, mình xin tóm tắt lại một số case study kỹ thuật cốt lõi được trích xuất từ tài liệu cấu hình, tập trung vào Syslog, Embedded Event Manager (EEM) và kỹ năng troubleshooting, giúp anh em kỹ sư mạng vững tay hơn khi quản trị hạ tầng thực tế.

1. Nắm Trọn 8 Mức Độ Cảnh Báo Syslog (Severity Levels)

Khi đọc log trên thiết bị Cisco, con số kẹp giữa bản tin chính là chìa khóa. Ví dụ, trong bản tin %LINEPROTO-5-UPDOWN hay %LINK-3-UPDOWN, các số 5 và 3 cho chúng ta biết mức độ nghiêm trọng của sự kiện.
Để dễ nhớ, dân mạng chúng ta thường truyền tai nhau câu thần chú: "Everyone Always Complains Even When Nothing Is Difficult" tương ứng với 8 cấp độ từ 0 đến 7:

0 - Emergency (Emergency): Hệ thống tê liệt, không thể sử dụng.
1 - Alert (Always): Cần hành động can thiệp ngay lập tức.
2 - Critical (Complains): Tình trạng nguy kịch.
3 - Error (Even): Có lỗi xảy ra (Ví dụ: trạng thái LINK chuyển sang DOWN).
4 - Warning (When): Cảnh báo có dấu hiệu bất thường.
5 - Notice (Nothing): Mức thông báo, sự kiện bình thường nhưng quan trọng (Ví dụ: Interface thay đổi trạng thái giao thức).
6 - Informational (Is): Các tin nhắn thông tin đơn thuần.
7 - Debug (Difficult): Tin nhắn dùng để gỡ lỗi quá trình hoạt động.

2. Gửi Syslog: Khi Nào Cần Bảo Mật và Chọn Cổng (Port) Nào?

Mặc định, Syslog gửi qua mạng là không đáng tin cậy và không bảo mật. Khi thiết kế hạ tầng, chúng ta cần nhớ rõ các tiêu chuẩn vận chuyển (Transport) theo RFC:

UDP Port 514: Đây là mặc định, không bảo mật và không đảm bảo việc tin nhắn sẽ tới đích (Unreliable).
TCP/UDP Port 601: Đảm bảo độ tin cậy (Reliable) nhưng vẫn chưa được mã hóa an toàn.
TCP Port 6514: Sử dụng chung với TLS. Đây là lựa chọn hoàn hảo khi bạn cần luồng log vừa truyền tải đáng tin cậy qua TCP, vừa được bảo mật tuyệt đối.

Nếu trong trường hợp hệ thống yêu cầu cấu hình dùng TCP và dùng một port không phải chuẩn cấp phát mặc định (Well-known ports từ 0 - 1023), kỹ sư sẽ cần chỉ định các port ở dải User Ports (từ 1024 trở lên) bằng lệnh như: logging host 10.10.10.1 transport tcp port 1024.
3. Tự Động Hóa Xử Lý Sự Cố Với EEM (Embedded Event Manager)

EEM giống như một người trợ lý túc trực 24/7 bên trong Router/Switch Cisco. Chúng ta có thể dùng EEM để bắt (catch) một bản tin Syslog và tự động thực thi các hành động gỡ lỗi.
Ví dụ: Bạn muốn tự động bật tính năng "debug ip ospf" ngay khi OSPF neighborship bị rớt.
Chúng ta có thể viết một script EEM lắng nghe chính xác mẫu log từ trạng thái FULL chuyển sang DOWN của mức cảnh báo 5 (Notice):
event syslog pattern "%OSPF-5-ADJCHG: Process 5, Nbr 1.1.1.1 on Serial0/0 from FULL to DOWN"
Sau khi bắt được sự kiện, hành động kích hoạt sẽ là cấu hình lệnh sinh ra một bản log tùy chỉnh: action 1 syslog msg "OSPF ROUTING ERROR". Đây là cách rất hay để admin có thể nhận cảnh báo qua hệ thống monitor trung tâm kịp thời thay vì phải ngồi canh màn hình CLI.

4. Đọc Vị Traceroute: Ký Tự !A Nghĩa Là Gì?

Troubleshooting bằng lệnh traceroute là kỹ năng cơ bản, nhưng không phải ai cũng chú ý đến các mã lỗi trả về.
Giả sử bạn trace từ Router 1 đến Router 3 (thuộc cùng OSPF Area 0) nhưng kết quả bị Timeout làm đứt gánh giữa chừng và trả về mã !A. Điều này có nghĩa là gì?

Chữ !A (Administratively prohibited) báo hiệu rằng gói tin đã bị chặn lại bởi một cấu hình quản trị viên, cụ thể thường là Access Control List (ACL).
Đằng sau nó, thiết bị chặn (thường là Router đích hoặc Router trung gian) đã trả về cho nguồn một bản tin ICMP Type 3 (Destination Unreachable) kèm Code 13 (Communication administratively filtered).

Hiểu được điều này, thay vì đi kiểm tra lại bảng định tuyến OSPF, bạn sẽ khoanh vùng ngay được vấn đề nằm ở các chỉ thị deny trong cấu hình ACL trên cổng Inbound/Outbound của các thiết bị trên đường truyền.

Hy vọng những tóm lược cấu hình và phân tích phía trên sẽ giúp các anh chị em kỹ sư nhà ôn tập tốt các khái niệm cốt lõi của Network Assurance. Mọi người thường dùng công cụ gì để quản lý Syslog và EEM trong hạ tầng của mình? Cùng chia sẻ ở dưới phần bình luận nhé!