Tổng Quan Chất Lượng Dịch Vụ Mạng QoS (Cisco Concept)
Mục lục
- 1. QoS là gì và vì sao vẫn cần dùng?
- 2. Ba loại hình QoS: Best Effort, DiffServ, IntServ
- 3. Các nhóm cơ chế QoS
- 4. Classification và Marking
- 5. Weighted Random Early Detection (WRED) và ECN
- 6. Queuing: CBWFQ và LLQ
- 7. Traffic Conditioners: Policing và Shaping
- 8. Link Efficiency Mechanisms
- 9. Cấu hình MQC (Modular QoS CLI)
- 10. Auto QoS
- 11. QoS trên mạng không dây (WMM)
- 12. QoS trên switch Catalyst (mls qos)
1. QoS là gì và vì sao vẫn cần dùng?
Định nghĩa hay nhất về QoS: "managed unfairness" — sự không công bằng có quản lý. Mạng có nhiều loại traffic khác nhau, và QoS chủ động thiên vị: cho một số loại traffic (ví dụ voice) được đối xử ưu tiên hơn loại khác (ví dụ traffic gaming), tuỳ vào mức độ quan trọng mà tổ chức xác định. Traffic quan trọng đi trước, traffic ít quan trọng phải chờ.
Có một ngộ nhận phổ biến: "tôi có link 1G, link 10G, thậm chí ra Internet cũng cả trăm meg rồi, không còn link chậm 56k nữa nên việc gì phải cần QoS." Thực tế QoS vẫn cần thiết vì hai lý do:
- Speed mismatch (chênh lệch tốc độ): một router nhận traffic từ LAN ở tốc độ gig nhưng gửi ra WAN/Internet chỉ ở tốc độ Fast Ethernet — chênh lệch 10:1. Router có thể nhận traffic nhanh gấp 10 lần tốc độ nó gửi đi được. Phần dữ liệu chưa gửi kịp sẽ được lưu tạm vào queue (hàng đợi) hoặc buffer, đợi khi có băng thông trống thì gửi tiếp.
- Aggregation point (điểm hội tụ traffic): ví dụ 3 server cùng nối vào 1 switch gig, tổng traffic đổ vào switch có thể lên tới 3 gig, trong khi switch chỉ có 1 link gig để thoát ra ngoài.
Tuy nhiên QoS không phải thuốc chữa bách bệnh cho mọi vấn đề nghẽn mạng. QoS chỉ hữu ích với nghẽn theo chu kỳ (periodic congestion) — ví dụ giờ backup hằng đêm, hoặc đầu giờ sáng khi mọi người đồng loạt đồng bộ file lên cloud. Nếu mạng nghẽn 24/7 thì vấn đề thực sự là thiếu băng thông, và giải pháp đúng là mua thêm băng thông chứ không phải cấu hình QoS.
2. Ba loại hình QoS: Best Effort, DiffServ, IntServ
QoS chia làm ba loại hình:
Best Effort — dùng FIFO (First In First Out) queuing: gói đến trước thì ra trước, không phân biệt loại traffic nào cả. Đây gần như không thể gọi là "quality of service" đúng nghĩa, vì không có sự phân biệt đối xử nào.
DiffServ (Differentiated Services) — đây là trọng tâm chính của toàn bộ nội dung. DiffServ phân biệt và đối xử khác nhau với từng loại traffic. Ví dụ: giới hạn traffic gaming ở mức 15 Mbps bằng công cụ policing — nếu vượt quá, phần vượt sẽ bị drop. Điểm hay của DiffServ: nếu một ứng dụng A được cam kết một phần băng thông nhưng hiện không dùng hết, phần dư đó có thể chia sẻ cho ứng dụng khác (ví dụ ứng dụng C) đang cần thêm.
IntServ (Integrated Services) — dùng giao thức RSVP (Resource Reservation Protocol). Khác với DiffServ (có chia sẻ), RSVP không chia sẻ: nó reserve (đặt trước) một phần băng thông cố định cho một ứng dụng trong suốt thời gian ứng dụng đó hoạt động. Ngay cả khi ứng dụng không dùng hết phần đã đặt trước, và ứng dụng khác đang cần thêm băng thông, phần đó vẫn không được chia sẻ — đây là một sự đặt chỗ cứng nhắc.
💡 Hình dung: DiffServ giống một buffet chung — ai không ăn hết phần của mình, người khác được lấy thêm. RSVP giống một bàn đã đặt cọc riêng ở nhà hàng: dù khách chưa tới hay ăn không hết, bàn đó vẫn bị giữ nguyên suốt buổi, không ai khác được ngồi vào dù đang đói và bàn thì trống.
Trọng tâm của toàn bộ nội dung tiếp theo là DiffServ.
3. Các nhóm cơ chế QoS
QoS không phải một công cụ đơn lẻ, mà là một tập hợp nhiều nhóm công cụ khác nhau:
- Classification and Marking — phân loại và đánh dấu traffic.
- Congestion Avoidance — WRED, tránh nghẽn trước khi nó xảy ra.
- Congestion Management / Queuing — quản lý nghẽn bằng hàng đợi.
- Traffic Conditioners — Policing và Shaping.
- Link Efficiency Mechanisms — cơ chế tối ưu hiệu quả đường truyền.
💡 Hình dung: Giống như tấm vé máy bay có in dòng chữ "Sky Priority" — khi lên máy bay, nhân viên cổng không bắt bạn chứng minh lại lịch sử bay mỗi lần, họ chỉ nhìn vào cái mark trên vé là biết ngay bạn được ưu tiên lên trước. Classification và Marking cũng vậy: đánh một dấu QoS lên packet (hoặc frame ở Layer 2), để router/switch kế tiếp chỉ cần nhìn vào dấu đó là ra quyết định forward/drop ngay lập tức, rất nhanh và hiệu quả, không phải phân loại lại từ đầu.
Cần lưu ý: Classification và Marking tự bản thân nó không làm gì cả — nó chỉ đặt một cái nhãn lên traffic. Phải có các cơ chế khác (queuing, WRED, policing/shaping...) đọc cái nhãn đó rồi mới thực sự hành động dựa trên nó.
Cisco khuyến nghị nên phân loại và đánh dấu traffic càng gần nguồn càng tốt, để các hop tiếp theo không cần phân loại lại mà chỉ cần đọc marking sẵn có.
4. Classification và Marking
Trước khi vào chi tiết: marking này nằm ở đâu trong một frame/packet thật?
Traffic di chuyển trong mạng qua 2 lớp đóng gói lồng nhau. Ở Layer 2, hai thiết bị kề nhau (switch với switch, switch với router) nói chuyện bằng frame — có Source MAC và Destination MAC, chỉ có ý nghĩa trên đúng một segment, bị bóc ra và đóng lại ở mỗi hop. Bên trong frame đó là một packet ở Layer 3 — có Source IP và Destination IP, giữ nguyên từ nguồn tới đích, đi xuyên qua nhiều hop mà không đổi.
💡 Hình dung: Frame giống một phong bì thư, packet giống lá thư bên trong. Phong bì bị bóc ra và thay bằng phong bì mới ở mỗi trạm chuyển tiếp (địa chỉ trên phong bì đổi theo từng trạm) — nhưng lá thư bên trong, với địa chỉ cuối cùng và nội dung thật, không đổi cho tới khi tới tay người nhận.
Cả ba loại marking sắp nói tới — CoS, IP Precedence, DSCP — đều "sống" bên trong hai lớp đóng gói này, chỉ khác vị trí: CoS nằm ở phần frame (phong bì), còn IP Precedence và DSCP nằm sâu hơn, ở phần packet (lá thư).
Layer 2 — CoS (Class of Service)
Như sơ đồ trên vừa cho thấy, khi đóng gói trên một trunk 802.1Q, switch sẽ thêm 4 byte gọi là tag byte (trừ native VLAN không có). Trong 4 byte đó có 3 bit gọi là priority bit, dùng để biểu diễn CoS. Với 3 bit, ta có 2³ = 8 giá trị khả dĩ (0-7). Cisco khuyến cáo không dùng giá trị 6 và 7 — hai giá trị này dành riêng cho network use (traffic điều khiển mạng). Giá trị CoS cao nhất nên dùng cho traffic sản xuất (kể cả voice, video) là 5. Cisco IP Phone mặc định xuất traffic ra với CoS = 5.
Vấn đề: CoS là marking Layer 2, giống MAC address chỉ có hiệu lực trên một segment — khi traffic đi qua router, marking CoS bị mất. Cần một loại marking sống sót được qua router hop.
Layer 3 — IP Precedence
IP Precedence dùng 3 bit trái nhất của byte ToS (Type of Service) trong header IPv4 (với IPv6 là Traffic Class byte). Cũng chỉ có 8 giá trị (0-7), và cũng cấm dùng 6, 7. Vấn đề: Cisco cho phép tối đa 11 class traffic, nhưng IP Precedence chỉ cung cấp 6 giá trị sử dụng được — không đủ để ánh xạ hết 11 class, nên IP Precedence ngày nay ít được dùng.
DSCP (Differentiated Services Code Point)
DSCP dùng 6 bit trái nhất của byte ToS/Traffic Class — cho 2⁶ = 64 giá trị khả dĩ. Vấn đề mới nảy sinh: 64 giá trị là quá nhiều, và nếu mỗi tổ chức tự chọn số tùy ý sẽ không có "ngôn ngữ chung" — router A có thể đánh dấu 26 là traffic ưu tiên cao, trong khi router B lại hiểu 26 là traffic thấp.
IETF giải quyết vấn đề này bằng cách chọn sẵn 21 giá trị chuẩn trong 64 giá trị và đặt tên cho chúng — gọi là PHB (Per-Hop Behavior), vì marking DSCP quyết định hành vi xử lý tại mỗi hop (mỗi router có thể có luật xử lý riêng cho từng PHB). Khi cấu hình trên router Cisco, có thể dùng tên PHB hoặc giá trị thập phân tương ứng.
21 giá trị PHB gồm:
- Default — giá trị thập phân 0 (nhị phân
000000). Dùng cho traffic không có ưu tiên đặc biệt. - Expedited Forwarding (EF) — giá trị thập phân 46 (nhị phân
101110). Dùng cho voice — traffic có độ ưu tiên cao nhất, không được delay. - Class Selector (CS1–CS7) — 7 giá trị tương thích ngược với IP Precedence: chỉ dùng 3 bit trái nhất (giống IP Precedence), các bit vị trí 4, 5, 6 luôn để 0. Nhờ vậy nếu một router chỉ hiểu IP Precedence nhận được gói đánh dấu CS4 từ một router nói DSCP, nó vẫn hiểu đúng là IP Precedence = 4 (vì 3 bit trái nhất của CS4 giống hệt IP Precedence 4 khi xét ở byte đó).
- Assured Forwarding (AF) — 12 giá trị còn lại, cũng là phần khó nhất với người học. Mỗi tên AFxy chứa hai thông tin:
- x (số đầu, 1-4): class, xác định bởi 3 bit trái nhất — coi như mức ưu tiên.
- y (số sau, 1-3): drop probability (xác suất bị drop khi nghẽn — thấp/trung bình/cao), xác định bởi 2 bit tiếp theo.
- Bit thứ 6 (cuối cùng, trong 6 bit DSCP) luôn là 0 với toàn bộ 21 giá trị chuẩn của IETF — nếu gặp một giá trị DSCP có bit cuối là 1, đó không phải một trong 21 giá trị chuẩn.
Cấu hình router Cisco chấp nhận cả hai cách viết một PHB — tên (ef, af41) hoặc giá trị thập phân (46, 34) — nên trong thực tế cần chuyển đổi qua lại giữa hai dạng này khá thường xuyên. Hai ví dụ dưới đây đi theo hai chiều ngược nhau: từ tên suy ra số, rồi từ số suy ngược lại tên.
Chiều 1 — từ tên PHB ra giá trị thập phân: CS4 tương ứng số nào?
CS4 nghĩa là tương đương IP Precedence = 4, và 3 bit trái nhất biểu diễn số 4 là 100. Vì Class Selector luôn để trống các bit vị trí 4-5-6 (giữ nguyên số 0) để đảm bảo tương thích ngược với IP Precedence, nên toàn bộ 6 bit DSCP của CS4 là 100000 — đổi sang thập phân được 32.
Chiều 2 — ngược lại, từ giá trị thập phân ra tên PHB: DSCP 20 là PHB nào?
Đổi 20 sang 6 bit nhị phân được 010100. Loại dần từng khả năng: không phải Default vì không toàn số 0, không phải EF vì EF luôn cố định ở 46, không phải Class Selector vì bit thứ 4 đang là 1 trong khi CS luôn giữ 3 bit cuối bằng 0 — vậy chỉ còn khả năng là Assured Forwarding. Với AF, 3 bit trái nhất 010 cho ra class = 2, hai bit tiếp theo 10 cho ra drop probability = 2, ghép lại đúng là PHB AF22.
5. Weighted Random Early Detection (WRED) và ECN
Vấn đề: TCP synchronization
Trong bắt tay ba bước TCP (SYN → SYN-ACK → ACK), sau khi kết nối thiết lập, kích thước cửa sổ gửi (sliding window) sẽ tăng dần theo thời gian (gửi 1 segment, rồi 2, rồi 4...). Nếu một gói bị mất hoặc không nhận được ACK đúng hạn, luồng TCP đó nhận ra đang gửi quá nhanh và thu nhỏ cửa sổ gửi lại (TCP slow start).
Nếu một hàng đợi bị đầy tới mức tràn (queue đầy 100%) và bắt đầu drop tất cả các gói không phân biệt, nhiều luồng TCP cùng lúc sẽ bị rớt gói và đồng loạt vào slow start — hiện tượng này gọi là TCP synchronization, gây ra việc sử dụng băng thông cực kỳ kém hiệu quả.
RED và WRED
RED (Random Early Detection) là chuẩn công nghiệp: đặt một ngưỡng tối thiểu (minimum threshold) và ngưỡng tối đa (maximum threshold) cho độ sâu hàng đợi. Dưới ngưỡng tối thiểu: xác suất drop = 0%. Giữa hai ngưỡng: xác suất drop tăng dần khi hàng đợi càng đầy. Vượt ngưỡng tối đa: xác suất drop = 100%. RED giúp tránh việc hàng đợi luôn đầy tới 100% rồi drop tất cả cùng lúc.
WRED (Weighted RED) là biến thể của Cisco: mỗi loại marking traffic (Default, EF, các Class Selector, các AF...) có RED profile riêng — với ngưỡng tối thiểu, ngưỡng tối đa, và mark probability denominator (xác suất drop tại ngưỡng tối đa) khác nhau.
Lấy một RED profile cụ thể để hình dung: ngưỡng tối thiểu đặt ở 25 gói, ngưỡng tối đa ở 45 gói. Từ 0 đến 25 gói trong hàng đợi, xác suất drop bằng 0% — hàng đợi được "thả lỏng" hoàn toàn, chưa ai bị đụng tới. Qua khỏi 25 gói, xác suất drop bắt đầu tăng dần theo độ đầy của hàng đợi, và tại đúng 45 gói thì xác suất đó chạm mốc 20%. Nhưng ngay khi vượt quá 45 gói, xác suất drop không tiếp tục tăng theo đường cong nữa mà nhảy thẳng lên 100% — đồ thị bên dưới minh hoạ rõ cú nhảy này.
Với các giá trị AF, WRED mặc định thiết lập: những PHB kết thúc bằng số 1 (AFx1 — drop probability thấp) có ngưỡng tối thiểu cao hơn (ví dụ 35), nghĩa là được giữ lại lâu hơn trong hàng đợi trước khi bắt đầu bị drop. Ví dụ: nếu độ sâu trung bình hàng đợi hiện tại là 28 gói, đã vượt ngưỡng tối thiểu của traffic có drop probability cao (AFx3), nhưng chưa vượt ngưỡng tối thiểu của AFx1 hay AFx2 — nên tại thời điểm đó, chỉ những gói AFx3 mới có khả năng bị drop.
ECN (Explicit Congestion Notification)
Byte ToS còn 2 bit cuối cùng (bit 7, 8) chưa dùng tới cho DSCP — dùng cho tính năng ECN (tùy chọn, không bắt buộc). Thay vì phải drop gói để ép luồng TCP vào slow start, ECN cho phép hai router "lịch sự" yêu cầu bên gửi tự nguyện giảm cửa sổ gửi mà không cần drop gói.
Hai bit này tạo thành một cái thang 3 nấc, đi từ "không biết gì về ECN" tới "đang thực sự nghẽn":
00— router không hỗ trợ ECN, hai bit này coi như bỏ trống.01hoặc10— router có hỗ trợ ECN, nhưng hiện tại chưa hề bị nghẽn.11— router có hỗ trợ ECN và đang thực sự bị nghẽn ngay lúc này. Chính giá trị11này là tín hiệu kích hoạt, khiến bên gửi tự nguyện giảm tốc.
6. Queuing: CBWFQ và LLQ
Ý tưởng cơ bản của queuing: chia một hàng đợi lớn (buffer) tại egress interface (cổng traffic đi ra khỏi thiết bị — chính là nơi xảy ra speed mismatch đã nói ở mục 1) thành nhiều sub-queue theo loại traffic, để bảo vệ traffic quan trọng (ví dụ voice) khỏi bị traffic khác (ví dụ best effort) làm tràn hàng đợi và bị drop chung. Việc phân chia này gọi là Congestion Management. Cisco khuyến nghị không tạo quá 11 sub-queue/class — "nếu ai cũng đặc biệt thì không ai đặc biệt cả".
CBWFQ (Class-Based Weighted Fair Queuing)
CBWFQ đảm bảo mỗi class có một băng thông tối thiểu trong thời điểm nghẽn, cấu hình bằng lệnh bandwidth. Điều quan trọng cần hiểu đúng: con số khai báo không phải giới hạn tốc độ tối đa. Ví dụ nếu khai báo bandwidth 3000 (3 Mbps) cho một class:
Trong thời điểm nghẽn, tôi đảm bảo bạn có ít nhất 3 Mbps băng thông nếu bạn cần. Và bạn có thể có nhiều hơn nếu bạn cần nhiều hơn, và phần thêm đó đang có sẵn (do các class khác không dùng hết phần của họ và chia sẻ lại — đúng tinh thần DiffServ).
Nhược điểm của CBWFQ: không có priority queue thực sự — mọi class chỉ luân phiên lấy phần của mình, không ai được đi trước ai.
LLQ (Low Latency Queuing)
LLQ = CBWFQ + thêm một priority queue. Dùng cho traffic nhạy cảm độ trễ như voice/video, cấu hình bằng lệnh priority (thay vì bandwidth). Khác với bandwidth, con số khai báo với priority là giới hạn tối đa (<=, không phải >=) — vì priority queue luôn được rút cạn hoàn toàn trước khi router phục vụ bất kỳ class nào khác, nên phải giới hạn cứng lượng traffic được vào priority queue để tránh làm "đói" (starve) các class khác. Traffic cố gắng vượt giới hạn priority sẽ bị policing (drop).
💡 Hình dung: Priority queue giống làn đường dành cho xe chở nhiều người (HOV/carpool lane) trên xa lộ — trong khi các làn khác đang nhích từng chút vì kẹt xe, làn này gần như trống và xe đủ điều kiện được đi thẳng qua trước. Nhưng chính vì được đi trước tuyệt đối như vậy nên làn này phải giới hạn nghiêm ngặt ai được vào — nếu để quá nhiều xe tràn vào làn ưu tiên, các làn còn lại sẽ chết đứng hoàn toàn.
Cuối cùng, luôn có một class-default — class mặc định, tự động tồn tại (không cần tự tạo, không thể xoá), là nơi traffic không khớp với bất kỳ class nào khác sẽ rơi vào. Bên trong class-default chạy cơ chế Weighted Fair Queuing.
7. Traffic Conditioners: Policing và Shaping
Cả Policing và Shaping đều đặt một "tốc độ giới hạn" (speed limit) cho traffic, nhưng xử lý phần traffic vượt giới hạn khác nhau:
- Shaping ("kinder and gentler" — kiểu tiếp cận nhẹ nhàng hơn): nếu traffic vượt tốc độ giới hạn, không drop ngay mà giữ lại (buffer) trong một hàng đợi tạm, đợi khi băng thông rảnh thì gửi tiếp. Cisco khuyến nghị dùng shaping trên các interface tốc độ chậm.
- Policing: nếu traffic vượt giới hạn, mặc định drop ngay lập tức — traffic bị mất phải được retransmit lại từ đầu. Cisco khuyến nghị dùng policing trên interface tốc độ cao (vì trên link chậm, việc drop rồi retransmit sẽ càng làm chậm thêm).
Vì sao có thể "giới hạn tốc độ" trên một interface có tốc độ vật lý cố định?
Một interface được clock ở tốc độ vật lý cố định (ví dụ 100 Mbps) — không thể literally gửi liên tục ở một tốc độ trung bình thấp hơn (ví dụ 10 Mbps) một cách liên tục. Giải pháp: gửi theo chu kỳ bật/tắt — burst dữ liệu ở đúng tốc độ đường truyền (line rate) trong một khoảng ngắn, rồi dừng hẳn, lặp lại theo chu kỳ — sao cho tốc độ trung bình theo thời gian đúng bằng tốc độ giới hạn mong muốn.
💡 Hình dung: Giống như lái xe 120 dặm/giờ trong 30 phút đầu, rồi đỗ xe đứng yên 30 phút còn lại — tính trung bình cả một giờ, tốc độ vẫn đúng là 60 dặm/giờ, dù tốc độ tức thời lúc đang chạy luôn là 120.
Ba khái niệm cốt lõi: CIR, Bc, Tc
- CIR (Committed Information Rate) — tốc độ trung bình cam kết, chính là "speed limit".
- Tc (timing interval) — khoảng thời gian được chia nhỏ ra để tính toán.
- Bc (Committed Burst) — lượng bit (với shaping) hoặc byte (với policing) được phép gửi trong mỗi khoảng Tc.
Ví dụ tính toán (Frame Relay traffic shaping): chia 1 giây thành 8 khoảng thời gian bằng nhau, Tc = 0.125 giây. Line speed = 128k, tốc độ giới hạn muốn đặt (CIR) = 64k.
Bc = CIR × Tc = 64.000 × 0.125 = 8.000 bit
Mỗi khoảng Tc, "đổ" 8.000 bit vào token bucket, gửi hết toàn bộ ở tốc độ đường truyền (line rate) rồi dừng lại — chờ khoảng Tc kế tiếp mới được đổ tiếp. Lặp lại 8 lần trong 1 giây: 8.000 × 8 = 64.000 bit/giây — đúng bằng CIR mong muốn, dù mỗi lúc gửi vẫn luôn chạy ở line rate.
Token bucket: các mô hình
Cùng một cơ chế "đổ token vào bucket" này có 4 biến thể, từ đơn giản nhất tới đầy đủ nhất — mỗi biến thể thêm đúng một khả năng mới so với biến thể trước:
- Single bucket, single rate: một bucket dung lượng Bc. Mỗi Tc "đổ" đầy Bc bit (shaping) hoặc Bc byte (policing) vào bucket. Chỉ có một hành động: conforming (tuân thủ) — không bao giờ vượt được CIR vì không đủ bit/byte để vượt.
- Thêm Be (Excess Burst): nếu một Tc không dùng hết Bc, phần dư (residue) sẽ cộng dồn sang Tc kế tiếp — cho phép burst tạm thời vượt CIR bằng cách dùng phần dư tích luỹ đó. Đây gọi là hành động exceeding (trong policing).
- Dual bucket, single rate (policing): một bucket CIR (Bc byte) + một bucket Be riêng.
- Đủ byte trong bucket Bc → conforming.
- Không đủ trong Bc nhưng đủ nếu cộng thêm Be → exceeding.
- Cộng cả hai bucket vẫn không đủ → violating (thường bị drop; hiếm khi cấu hình transmit traffic violating, vì việc có đủ byte để exceed hay không phụ thuộc vào phần dư tích luỹ từ Tc trước — không có gì đảm bảo).
- Dual bucket, dual rate: có thêm một bucket riêng gọi là PIR (Peak Information Rate), được chủ động "đổ" byte mỗi Tc (không chỉ dựa vào phần dư như Be) — cho phép cấu hình hành động khác nhau cho conforming / exceeding (dùng bucket PIR) / violating.
Khác biệt quan trọng: Shaping không cấu hình được hành động khác nhau cho "exceeding" — chỉ đơn giản giữ traffic vượt giới hạn trong buffer để gửi sau (dù vẫn có thể dùng bucket lớn hơn để cho phép burst định kỳ). Policing thì linh hoạt hơn: có thể cấu hình riêng biệt hành động cho conforming/exceeding/violating — ví dụ transmit, drop, hoặc remark (đánh dấu lại) xuống một mức ưu tiên thấp hơn.
8. Link Efficiency Mechanisms
Nhóm cơ chế này chỉ áp dụng cho các link WAN tốc độ rất thấp — ngày nay hầu như không còn phổ biến nữa nên chỉ điểm qua:
- Với link dưới 768 kbps: dùng LFI (Link Fragmentation and Interleaving).
- Với link dưới 2 Mbps: có thể dùng RTP header compression.
💡 Hình dung: Tưởng tượng một xe tải kéo 3 rơ-moóc (longer combination vehicle) đang dừng ở đèn đỏ cùng với một chiếc xe thể thao nhỏ (đại diện cho một frame voice) phía sau. Đèn xanh, xe tải 3 rơ-moóc bắt đầu di chuyển — rơ-moóc thứ nhất, rồi thứ hai, tới khi rơ-moóc thứ ba qua khỏi giao lộ thì đèn có thể đã đỏ trở lại. Chiếc xe thể thao nhỏ bị delay rất lâu.
Đó chính là những gì xảy ra trên link chậm khi có một khung dữ liệu lớn (big data frame) đi trước một khung nhỏ (voice frame) — khung lớn chiếm dụng interface quá lâu, làm khung nhỏ phía sau bị trễ.
Giải pháp LFI: tách khung dữ liệu lớn thành nhiều fragment (mảnh nhỏ), giống như tách 3 rơ-moóc thành 3 xe tải riêng biệt — sau đó interleave (chen) khung voice nhỏ vào giữa các mảnh đã tách, giống như chiếc xe thể thao nhỏ giờ có thể len lỏi vượt qua nhanh hơn giữa các xe tải riêng lẻ.
9. Cấu hình MQC (Modular QoS CLI)
MQC (Modular QoS CLI) là quy trình cấu hình QoS gồm 3 bước:
- class-map — phân loại traffic (classification).
- policy-map — định nghĩa cách xử lý (policy) cho từng class.
- service-policy — áp policy-map vào một interface, theo một hướng cụ thể (input/output).
Bước 1 — tạo class-map
Toàn bộ các lệnh class-map/policy-map dưới đây gõ trong global configuration mode của router (configure terminal), chưa đụng tới interface nào cả — chỉ tới Bước 3 mới thật sự áp vào một interface cụ thể.
class-map match-any email
match protocol pop3
match protocol smtp
match protocol imap
Lưu ý quan trọng: mặc định class-map là match-all — traffic phải khớp tất cả tiêu chí mới được vào class. Nhưng một gói không thể vừa là POP3, vừa là IMAP, vừa là SMTP cùng lúc — nên với trường hợp muốn khớp bất kỳ protocol nào trong nhóm, phải khai báo match-any (khớp bất kỳ tiêu chí nào là đủ). Lệnh match protocol sử dụng NBAR (Network Based Application Recognition) để nhận diện protocol.
class-map voice
match protocol rtp audio
Chỉ có một tiêu chí match nên không cần khai match-any/match-all.
class-map scavenger
match protocol bittorrent
Dùng cho traffic "không mong muốn" trong tổ chức.
Kiểm tra bằng show class-map — sẽ thấy thêm một class-map tên class-default được tạo sẵn tự động, là catch-all class chứa mọi traffic chưa khớp class nào khác.
Bước 2 — tạo policy-map
policy-map demo
class email
bandwidth 512
random-detect dscp-based
random-detect ecn
class voice
priority 256
class scavenger
police 128000
bandwidth 512(đơn vị kbps) — cam kết tối thiểu 512 kbps khi nghẽn, đúng như CBWFQ đã trình bày.random-detect dscp-based— bật WRED, dựa theo DSCP (nếu không khai rõ, mặc định sẽ dựa theo IP Precedence).random-detect ecn— bật ECN.priority 256— đưa class voice vào priority queue, tối đa 256 kbps (chính là cấu hình LLQ).police 128000(đơn vị bit/giây, khác vớibandwidthdùng kbps) — giới hạn tối đa 128 kbps cho traffic scavenger. Hành vi mặc định: conforming → transmit, exceeding → drop.
Bước 3 — áp policy vào interface
interface gig0/2
service-policy output demo
Lưu ý: không phải cơ chế QoS nào cũng áp được cả hai chiều. Ví dụ policing áp được cả inbound lẫn outbound, nhưng shaping chỉ áp được outbound.
Kiểm tra cấu hình
Lệnh kiểm tra mạnh nhất: show policy-map interface gig0/2 — hiển thị toàn bộ class-map, policy đang áp dụng trên interface đó, kèm theo số liệu packet và byte thực tế đã match từng class — giúp xác nhận traffic có thực sự đi đúng class như mong muốn hay không.
show policy-map interface gig0/2
GigabitEthernet0/2
Service-policy output: demo
Class-map: email (match-any)
1523 packets, 1847216 bytes
Match: protocol pop3
Match: protocol smtp
Match: protocol imap
Queueing
Bandwidth 512 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 1523/1847216
(depth/total drops/no-buffer drops) 0/12/0
dscp Transmitted Random drop Minimum Maximum
pkts/bytes pkts/bytes threshold threshold
default 1511/1834912 0/0 20 40
af11 0/0 0/0 28 40
Class-map: voice (match-all)
8420 packets, 673600 bytes
Match: protocol rtp audio
Queueing
Strict Priority
Bandwidth 256 (kbps) Burst 6400 (Bytes)
(pkts matched/bytes matched) 8420/673600
(total drops/bytes drops) 0/0
Class-map: scavenger (match-all)
412 packets, 296640 bytes
Match: protocol bittorrent
police:
cir 128000 bps, bc 4000 bytes
conformed 380 packets, 273600 bytes; actions: transmit
exceeded 32 packets, 23040 bytes; actions: drop
Class-map: class-default (match-any)
15300 packets, 18576000 bytes
Match: any
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
Vài điểm đáng chú ý trong output này: dòng Bandwidth 512 (kbps) ở class email và Bandwidth 256 (kbps) + Strict Priority ở class voice chính là bằng chứng cho thấy CBWFQ và LLQ đã thực sự được áp dụng đúng như cấu hình. Bảng dscp Transmitted / Random drop ở class email là số liệu WRED (đã bật ở mục 5) — mỗi dòng ứng với một PHB, cho biết bao nhiêu gói đã bị random drop theo từng ngưỡng riêng. Ở class scavenger, cặp conformed / exceeded xác nhận policing đang hoạt động: gói vượt 128000 bps bị đánh dấu exceeded và drop, đúng hành vi mặc định.
10. Auto QoS
Auto QoS là một dạng "macro" giúp thiết lập một cấu hình QoS khá đầy đủ chỉ với 1-3 lệnh. Có ba phiên bản:
auto qos voip(trên router) — tập trung vào voice, đảm bảo voice traffic được ưu tiên/đưa vào priority queue. Chỉ chạy được trên interface kiểu WAN (serial chạy HDLC, PPP, Frame Relay, hoặc ATM) — không chạy được trên Ethernet.auto qostrên switch — cũng tập trung vào voice, tối ưu riêng cho switch.auto qos enterprise(trên router, phiên bản nâng cấp nhất) — không chỉ quan tâm voice: chạy ở chế độ quan sát traffic (observation mode) trong khoảng 2-3 ngày (khuyến nghị của Cisco) để học traffic pattern thực tế trên interface, sau đó đề xuất một cấu hình policy dựa trên những gì đã học. Có thể tự động populate tới 10 trong 11 class — riêng class nào là "mission critical" thì phải tự cấu hình tay, vì hệ thống không thể tự biết quan điểm riêng của từng doanh nghiệp về việc gì là mission critical.
Demo trên router
interface serial 0/1/0
auto qos voip
(có tuỳ chọn trust để tin tưởng marking đến sẵn từ Cisco IP Phone).
Sau khi chạy, show class-map sẽ thấy tự động tạo các class map khớp theo DSCP cho voice payload, voice signaling (giá trị hiện tại là CS3, trước đây từng dùng giá trị khác), và một class khớp theo access-list cho traffic điều khiển cuộc gọi (ví dụ port 1720 dùng cho H.323, các port khác dùng cho Skinny/SIP/MGCP).
show policy-map sẽ thấy một policy tên autoqos-voip-policy được tạo, cấp 70% băng thông cho RTP (voice media), 5% cho voice control traffic, phần còn lại cho class-default.
Đánh giá: hữu ích nhưng chỉ tập trung vào voice, nên trong thực tế ít khi dùng riêng lẻ trên router mà không kết hợp thêm.
Demo trên switch
Trước tiên xác định port nào nối với Cisco IP Phone bằng show cdp neighbors — CDP (Cisco Discovery Protocol) là giao thức độc quyền Cisco chạy giữa các thiết bị kề nhau trên cùng segment, giúp switch tự nhận diện láng giềng của mình là loại thiết bị gì (switch khác, router, hay chính Cisco IP Phone) mà không cần cấu hình thủ công.
interface range fastethernet 0/13 - 14
auto qos voip cisco-phone
(trust marking đến từ Cisco IP Phone, xác định qua CDP). Kết quả sinh ra rất nhiều lệnh mls qos (thiết lập các ngưỡng, drop threshold, số gói buffer cho từng queue...) — phức tạp hơn hẳn so với trên router. Các port nối phone được đưa vào priority queue.
Đây là cấu hình gần như dùng "hằng ngày" mỗi khi có port nối trực tiếp Cisco IP Phone, và gần như không cần chỉnh sửa thêm sau khi áp dụng.
Demo Auto QoS Enterprise
auto discover qos/auto qos (Enterprise) là lệnh IOS đời cũ hơn hẳn so với auto qos voip — Cisco đã và đang dịch chuyển nhiều lệnh QoS "cổ điển" sang chuẩn MQC (đã học ở mục 9) trên các dòng IOS/IOS-XE mới, nên trước khi dùng trên thiết bị production nên kiểm tra lại đúng release notes/command reference của chính IOS-XE đang chạy để chắc lệnh này vẫn còn được hỗ trợ nguyên vẹn trên platform đó.
Yêu cầu CEF (Cisco Express Forwarding) đã bật (ip cef) — CEF là cơ chế forwarding packet hiệu năng cao dựa trên bảng định tuyến được build sẵn (thay vì tra cứu route-table cho từng packet), gần như mặc định bật sẵn trên router Cisco hiện đại. Auto QoS Enterprise cần CEF vì cơ chế nhận diện traffic pattern trong observation mode dựa trên NBAR (đã nhắc ở mục 9) — mà bản thân NBAR lại cần CEF mới chạy được.
interface serial 0/1/0
auto discover qos
Sau đó chờ (thực tế Cisco khuyến nghị 2-3 ngày quan sát). Xem đề xuất bằng:
show auto discovery qos
Nếu hài lòng với đề xuất, áp dụng bằng:
auto qos
(không kèm discover). Đây được đánh giá là một điểm khởi đầu tốt, tiết kiệm nhiều thời gian, nhưng vẫn có thể cần tinh chỉnh thêm cho phù hợp với nhu cầu riêng của từng doanh nghiệp.
11. QoS trên mạng không dây (WMM)
Với Wi-Fi truyền thống (không tính Wi-Fi 6), các thiết bị dùng cơ chế CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance): lắng nghe sóng trước khi truyền; nếu thấy "im lặng" (không ai đang truyền) thì mới gửi. Nếu hai thiết bị cùng lúc nghe thấy im lặng và cùng truyền, xảy ra collision (va chạm) — cả hai phải back off (lùi lại) một khoảng thời gian ngẫu nhiên rồi mới thử truyền lại.
QoS không dây tận dụng chính cơ chế back-off này để tạo ưu tiên:
- Traffic ưu tiên cao được back off ngắn hơn — thử truyền lại nhanh và "aggressive" hơn.
- Traffic ưu tiên thấp back off lâu hơn.
- Khoảng cách giữa các frame gửi liên tiếp (inter-frame space) cũng nhỏ hơn với traffic ưu tiên cao, lớn hơn với traffic ưu tiên thấp.
💡 Hình dung: Giống một cuộc họp đông người, ai cũng phải chờ đến lượt mới được nói, và nếu hai người lỡ nói chồng lên nhau thì cả hai đều phải dừng lại, chờ một khoảng im lặng rồi mới thử nói lại. Người có việc gấp (traffic ưu tiên cao) chỉ cần chờ một khoảng rất ngắn là được phép chen vào nói tiếp; người có việc không gấp (traffic ưu tiên thấp) phải nhường, chờ lâu hơn hẳn mới đến lượt.
Chuẩn QoS không dây gọi là WMM (Wi-Fi MultiMedia), chỉ chia làm 4 category (không phải 11 class như DiffServ có dây): background, best effort, voice, video.
Với thiết bị không nằm trên trunk (ví dụ laptop gửi trực tiếp), marking Layer 2 dùng chuẩn 802.1p thay vì 802.1Q — cũng thêm 4 byte và dùng 3 bit priority giống CoS. Khác biệt duy nhất: 802.1p để toàn bộ phần VLAN ID = 0 (không dùng để chỉ định VLAN như 802.1Q làm).
8 giá trị CoS/802.1p sẽ được ánh xạ vào 4 category của WMM.
12. QoS trên switch Catalyst (mls qos)
Ví dụ minh hoạ dùng dòng switch Catalyst 3750 series (đây là model xuất hiện trong bài lab chứng chỉ CCIE Collaboration) — hành vi có thể khác trên các model/dòng switch khác nên cần kiểm tra tài liệu tương ứng.
Trên switch này, egress interface được chia thành 4 sub-queue. Chỉ có queue số 1 có thể cấu hình làm priority queue. Mỗi queue có 3 threshold: threshold 1, threshold 2, và threshold 3 (queue đầy hoàn toàn).
Áp khái niệm 4 queue này vào một mapping thực tế: traffic càng nhạy cảm độ trễ thì càng nên nằm ở queue được phục vụ sớm nhất và ít bị drop nhất. Voice và video — hai loại chịu delay kém nhất — đi thẳng vào queue ưu tiên; traffic ít quan trọng hơn dồn chung một queue và chấp nhận bị drop sớm hơn khi nghẽn:
- CoS 4 (video) và CoS 5 (voice) → queue 1 (priority).
- CoS 6, 7 (không nên dùng cho traffic thường) → queue 2.
- CoS 3 (signaling) → queue 3 riêng.
- CoS 0, 1, 2 → queue 4, với threshold: ban đầu chấp nhận cả CoS 0/1/2; vượt threshold 1 thì bắt đầu drop CoS 0; vượt threshold 2 thì chỉ còn chấp nhận CoS 2.
Vấn đề CoS không qua được router
CoS là marking Layer 2, không vượt qua được router boundary. Vì vậy switch cần convert CoS sang DSCP để traffic sống sót khi đi qua router. Mapping mặc định của switch không hoàn toàn đúng ý muốn — ví dụ CoS 5 mặc định được map sang DSCP 40 (= CS5), không phải 46 (= EF) — nên nên set thủ công lại mapping này.
Áp lại đúng bộ PHB đã học ở mục 4 vào bài toán collaboration cụ thể này:
- Voice signaling → CS3 (giá trị 24).
- Video media → AF41 (giá trị 34).
- Voice media → EF (giá trị 46).
Vì sao chỉ nên trust marking từ nguồn tin cậy
Vì lo ngại người dùng có thể tự đánh dấu 802.1p/DSCP cao để "gian lận" giành ưu tiên, switch chỉ nên trust marking đến từ nguồn thực sự tin cậy — ví dụ chỉ trust khi switch xác nhận (qua CDP) rằng traffic đến từ một Cisco IP Phone thật.
Cấu hình mẫu
! 1. Bật QoS toàn cục — mặc định QoS bị tắt hoàn toàn trên dòng switch này
mls qos
! 2. Cấu hình mapping CoS -> DSCP
mls qos map cos-dscp 0 8 16 24 34 46 48 56
! 3. Trong interface range nối phone
interface range fastethernet 0/13 - 14
mls qos trust cos
mls qos trust device cisco-phone
priority-queue out
Lưu ý một lỗi cấu hình thường gặp: nhiều người chỉ gõ mls qos trust device cisco-phone mà quên gõ mls qos trust cos trước đó — quên khai báo rõ loại marking nào (CoS hay DSCP) đang được trust, dẫn tới switch không thực sự trust marking nào cả dù đã khai nguồn tin cậy.
Lệnh priority-queue out bật priority queue (queue 1) cho các cổng trong range đó, để traffic từ phone được xử lý ưu tiên trước.
Kiểm tra cấu hình
show mls qos interface fastethernet0/13
FastEthernet0/13
Trust state: trust cos
Trust mode: trust cos
Trust enabled flag: ena
Trust device: cisco-phone
COS override: dis
Default COS: 0
show mls qos maps cos-dscp
COS-DSCP Map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 34 46 48 56
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
Dòng Trust device: cisco-phone trong output đầu là bằng chứng trực tiếp cho lỗi cấu hình vừa nhắc ở trên — nếu quên gõ mls qos trust cos, dòng Trust state sẽ hiện untrusted dù đã khai trust device cisco-phone. Bảng COS-DSCP Map ở lệnh thứ hai xác nhận đúng mapping vừa cấu hình ở phần trên.
Đây chỉ là một ví dụ cơ bản để minh hoạ ý tưởng; việc cấu hình đầy đủ QoS trên switch Catalyst 3750 series (bao gồm policing, shaping, mapping CoS vào nhiều queue/threshold khác nhau) là một chủ đề riêng, phức tạp hơn nhiều so với phạm vi bài viết này.
Nguồn tham khảo
Nguồn gốc: QoS Deep Dive — kênh Kevin Wallace Training, LLC
Các điểm dưới đây đã được verify qua research (Mode R), truy cập 08/2026:
- Giá trị DSCP thập phân 34 tương ứng PHB AF41 (class 4, drop probability thấp — nhị phân
100010), không phải "AF1x" — RFC 2597, Assured Forwarding PHB Group. - DSCP EF = 46 (
101110) và Default = 0 (000000) — RFC 3246, An Expedited Forwarding PHB, RFC 2474, Definition of the DS Field. - Mapping mặc định
mls qos map cos-dscp(chưa tùy chỉnh) trên switch Catalyst là CoS × 8 — 0, 8, 16, 24, 32, 40, 48, 56 — khớp đúng lý do cần đổi CoS 5 từ DSCP 40 sang 46 nêu ở mục 12, Cisco Catalyst 3750-X/3560-X Software Configuration Guide — Configuring QoS. - Giới hạn khuyến nghị không quá 11 class traffic vẫn là khuyến nghị hiện hành, gọi là QoS Baseline model — Cisco Collaboration SRND — Network Infrastructure.
- Ngưỡng 768 kbps cho LFI (Link Fragmentation and Interleaving) vẫn là khuyến nghị chính thức của Cisco cho việc đạt serialization delay mục tiêu 10ms — Cisco — Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits.
- Lệnh
auto qos voipvẫn còn được document và hỗ trợ trên IOS-XE hiện tại, không bị deprecated — Cisco Catalyst 9600 QoS Configuration Guide, IOS XE 17.15.x — Configuring Auto-QoS.