Bỏ qua nội dung
InstagramYouTubeFacebook

Tutorial

Quản Lý Băng Thông MikroTik: Queues

Cách quản lý băng thông trên MikroTik: simple queue, queue tree với mangle mark, PCQ chia sẻ công bằng, burst và priority, cùng giới hạn tốc độ toàn hệ thống.

Tóm tắt Quản lý băng thông trên MikroTik dựa trên ba công cụ: simple queue để giới hạn nhanh theo từng client, queue tree cho phân cấp và ưu tiên, và PCQ để chia sẻ công bằng giữa nhiều người dùng mà không cần tạo queue riêng cho mỗi người. Queue tree kết hợp với các mark của firewall mangle và cho bạn các mức đảm bảo, trần và ưu tiên. Bài này chỉ ra khi nào dùng cái nào, các lệnh RouterOS, và cách giữ cùng một chính sách đồng nhất trên cả một hệ thống router.

Quy trình quản lý băng thông MikroTik: giới hạn một client bằng simple queue, đánh dấu lưu lượng bằng firewall mangle, xây dựng queue tree với queue cha và con, thêm một queue type PCQ để chia sẻ công bằng theo từng người dùng, tinh chỉnh limit-at, max-limit, burst và priority, rồi triển khai cùng một chính sách ra mọi router.

Quản Lý Băng Thông Trên MikroTik Là Gì?

Quản lý băng thông trên MikroTik là việc dùng các queue của RouterOS để kiểm soát mỗi khách hàng, subnet hay lớp lưu lượng được tiêu thụ bao nhiêu dung lượng của đường truyền — giới hạn tốc độ, đảm bảo mức tối thiểu, và quyết định ai phải nhường khi đường truyền đầy. RouterOS hiện thực queue bằng bộ lập lịch Hierarchical Token Bucket (HTB), được phơi bày ở hai nơi: simple queue, một danh sách có thứ tự được áp dụng tuần tự, và queue tree, một cây phân cấp gắn với interface hoặc với các packet mark từ tính năng mangle của firewall (Tài liệu MikroTik — Queues).

Sự khác biệt này quyết định thiết kế của bạn mở rộng được tới đâu. Một simple queue trả lời câu hỏi “giới hạn khách hàng này ở mức 50 Mbps.” Một queue tree trả lời “đường uplink 500 Mbps này được 300 thuê bao dùng chung, VoIP đi trước, không ai bị bỏ đói, và những người tải nặng không phá hỏng cả buổi tối.” Mọi ISP rồi cũng sẽ cần đến câu trả lời thứ hai.

Bước 1 — Giới hạn một client bằng simple queue

Simple queue là con đường ngắn nhất từ vấn đề đến giải pháp. Nhắm vào một IP, một subnet hay một interface, đặt mức trần, và xong:

/queue simple add name=client-101 target=10.10.0.101/32 max-limit=10M/50M

max-limit được viết dưới dạng upload/download theo góc nhìn của router. Các rule được đánh giá theo thứ tự và rule khớp đầu tiên sẽ thắng — nên một rule rộng đặt sớm sẽ âm thầm nuốt mất những rule cụ thể mà bạn thêm sau đó. Thứ tự đó là nguyên nhân phổ biến nhất khiến một queue “đang chạy tốt” ngừng hoạt động sau khi ai đó thêm một rule lên phía trên nó (Tài liệu MikroTik — Queues).

Simple queue cũng kết hợp với xác thực thuê bao: trường rate-limit của một profile PPPoE tạo ra một simple queue động cho mỗi phiên, nên gói cước đi theo người dùng chứ không theo IP. Bài hướng dẫn PPPoE server MikroTik cho ISP của chúng tôi nói về phần profile.

Bước 2 — Đánh dấu lưu lượng bằng firewall mangle

Queue tree không nhìn thấy “VoIP” hay “khách hàng 101”; nó chỉ thấy các packet mark. Hãy tạo chúng trong mangle, đánh dấu connection trước rồi đến packet sau, cách này rẻ hơn việc phải kiểm tra lại từng gói tin:

/ip firewall mangle
add chain=forward action=mark-connection new-connection-mark=voip-conn protocol=udp port=5060,10000-20000
add chain=forward action=mark-packet connection-mark=voip-conn new-packet-mark=voip-pkt passthrough=no

Hãy giữ hệ thống phân loại mark nhỏ gọn và ổn định. Mark là ngôn ngữ mà queue của bạn nói, và một khi cả hệ thống đã có ba thế hệ tên mark tùy hứng, không ai còn phân biệt nổi router nào áp dụng chính sách nào. Đây là lúc tính năng audit và lịch sử cấu hình của MKController phát huy giá trị: xem trạng thái mangle và queue của mọi router, so sánh nó với chính sách dự kiến, và đẩy các rule đã sửa ra toàn hệ thống thay vì mở ba mươi phiên Winbox chỉ để tìm ra chiếc router duy nhất chưa bao giờ nhận được thay đổi.

Bước 3 — Xây dựng cây phân cấp queue tree

Một queue tree có một parent nắm giữ dung lượng thực của đường truyền, và các con chia nhỏ nó:

/queue tree
add name=download parent=bridge-lan max-limit=500M
add name=voip parent=download packet-mark=voip-pkt limit-at=50M max-limit=100M priority=1
add name=bulk parent=download packet-mark=bulk-pkt limit-at=50M max-limit=500M priority=8

Ba trường làm nên tất cả. limit-at là mức đảm bảo mà một con nhận được ngay cả khi đường truyền bị bão hòa. max-limit là mức trần mà nó có thể đạt tới khi còn dung lượng trống. priority — 1 là cao nhất, 8 là thấp nhất — quyết định con nào được nhận phần dư trước, và chỉ áp dụng trong khoảng giữa limit-atmax-limit (Tài liệu MikroTik — Queues). Hãy đặt max-limit của parent bằng đúng những gì đường truyền thực sự cung cấp, chứ không phải theo con số ghi trên hợp đồng, nếu không queue sẽ không bao giờ trở thành nút thắt cổ chai và không định hình được gì cả.

Bước 4 — Thêm PCQ để chia sẻ công bằng

Per Connection Queue (PCQ) là lý do MikroTik có thể mở rộng tới số lượng thuê bao mà một danh sách queue theo từng người dùng không thể quản lý nổi. Một queue type PCQ phân loại lưu lượng theo một trường địa chỉ và tạo ra một sub-queue động cho mỗi giá trị khác nhau, áp dụng cùng một tốc độ cho mỗi cái (Tài liệu MikroTik — ví dụ PCQ):

/queue type
add name=pcq-down kind=pcq pcq-rate=20M pcq-classifier=dst-address
add name=pcq-up kind=pcq pcq-rate=10M pcq-classifier=src-address

Gắn pcq-down làm queue của con mang lưu lượng download của khách hàng, và mỗi khách hàng sẽ nhận được tối đa 20 Mbps, được phân bổ tự động. Đặt pcq-rate=0 và PCQ sẽ chia đều băng thông của parent cho bất kỳ ai đang hoạt động — cấu hình kinh điển “không ai bị bỏ đói”. Một queue type thay thế cho hàng trăm mục phải viết tay.

Cùng một logic cân bằng đó áp dụng cho WiFi dùng chung: giới hạn tốc độ của gói cước và một parent PCQ cùng nhau ngăn một vị khách chiếm trọn đường uplink của một địa điểm — xem bài hướng dẫn thiết lập voucher HotSpot MikroTik của chúng tôi cho phần thông tin đăng nhập.

Bước 5 — Tinh chỉnh limit-at, max-limit, burst và priority

Phần lớn QoS bị hỏng không phải do sai công cụ, mà do sai con số. Hãy giữ tổng limit-at của mọi con bằng hoặc thấp hơn max-limit của parent; nếu các mức đảm bảo vượt quá khả năng đường truyền, HTB không thể tôn trọng chúng và priority sẽ không còn hành xử như bạn mong đợi. Hãy dành priority=1 cho lưu lượng nhạy với độ trễ — VoIP, gaming, DNS — và để các lượt truyền dữ liệu lớn ở mức 8 với một mức trần rộng rãi.

Burst xứng đáng có một lời cảnh báo. burst-limit, burst-thresholdburst-time cho phép một client vượt max-limit trong chốc lát trong khi mức trung bình vẫn thấp — tuyệt cho các bài test tốc độ, tệ hơn cho một đường truyền bị bán vượt công suất. Hãy đo bằng /queue simple print stats hoặc các bộ đếm của queue tree khi đường truyền đang chịu tải, chứ không phải lúc 3 giờ sáng khi mọi thứ đều rảnh rỗi. Nếu việc đọc bộ đếm vào giờ cao điểm là không thực tế, chế độ xem Internet Link của MKController giữ nguyên bức tranh đó một cách liên tục — mức sử dụng so với tốc độ đã cam kết; độ trễ theo trung bình, tối đa và P95; và mỗi đường truyền đã dành bao nhiêu giờ vượt trên 90% — để bạn tinh chỉnh dựa trên lịch sử, chứ không phải một khoảnh khắc may mắn.

Dung lượng cũng thay đổi. Trên một thiết lập dual-WAN failover, giá trị max-limit của parent mà bạn đã tinh chỉnh cho cáp quang trở thành hư cấu ngay khi lưu lượng chuyển sang đường LTE dự phòng — hãy chuẩn bị sẵn một chính sách thứ hai.

Bước 6 — Triển khai chính sách ra toàn bộ hệ thống

Một router là một cấu hình; một trăm router là một hoạt động vận hành. Chính sách giờ đây phải giống hệt nhau trên mọi thiết bị, sống sót qua tay kỹ thuật viên đã “tạm thời” nâng mức trần cho một khách hàng, và có thể khôi phục được khi một router trên trạm bị netinstall. Không có gì trong RouterOS làm việc đó thay bạn.

MKController thì làm được: đẩy queue type, profile rate-limit và rule firewall ra toàn hệ thống; lịch sử cấu hình, để bạn thấy được khi nào một giới hạn thay đổi và khôi phục phiên bản trước chỉ với một cú click; sao lưu tự động trước mỗi thay đổi; và truy cập từ xa outbound an toàn tới các router sau CGNAT hay trên Starlink, không cần IP công khai và không cần port forwarding — cách tiếp cận mà chúng tôi mô tả trong quản lý từ xa MikroTik sau CGNAT. Và tính năng giám sát Internet Link của nó theo dõi chính những đường uplink mà bạn vừa định hình — mức sử dụng theo từng nguồn so với tốc độ đã cam kết, độ trễ kèm P95, và mức tiêu thụ vượt qua các ngưỡng 75% và 90% trên tối đa bốn nguồn WAN mỗi router — để một đường truyền đang bò dần tới bão hòa sẽ hiện lên trên bảng điều khiển, và (kết hợp với cảnh báo Telegram) trong thông báo của bạn, trước khi một thuê bao gọi điện. Các ISP và WISP vận hành MikroTik ở quy mô lớn dùng nó để chính sách băng thông vẫn là một quyết định duy nhất, chứ không phải một trăm.

Mẹo

  • Định hình trên interface nơi lưu lượng rời khỏi router; queue kiểm soát chiều đi ra, nên download được định hình ở phía LAN còn upload ở phía WAN.
  • Hãy ưu tiên một queue type PCQ thay vì hàng trăm simple queue một khi bạn vượt qua vài chục thuê bao.
  • passthrough=no trên các rule mark-packet giúp tiết kiệm việc duyệt qua các rule mangle còn lại một cách không cần thiết.
  • Luôn sao lưu trước khi động vào queue trên một thiết bị biên đang chạy production, và mỗi lần chỉ thay đổi một biến.

Đừng đoán mò băng thông của bạn đi đâu

Queue chính là ranh giới giữa việc bán một gói cước và việc thực sự giao được nó. Simple queue giới hạn một client, queue tree mang lại cấu trúc và ưu tiên, PCQ khiến sự công bằng trở nên tự động — và MKController biến cả ba thành một chính sách mà bạn áp dụng một lần và thực thi ở khắp mọi nơi: quản lý tập trung toàn hệ thống, đẩy rate-limit và firewall ra mọi router, lịch sử cấu hình với khôi phục chỉ một cú click, truy cập từ xa không cần IP công khai, và giám sát Internet Link báo hiệu một đường truyền đang bão hòa so với tốc độ đã cam kết trước cả khi khách hàng của bạn nhận ra.

Bắt đầu dùng thử miễn phí MKController