จัดการแบนด์วิดท์ MikroTik ด้วย Queues

สรุป การจัดการแบนด์วิดท์บน MikroTik ตั้งอยู่บนเครื่องมือสามอย่าง คือ simple queue สำหรับจำกัดความเร็วต่อลูกค้าอย่างรวดเร็ว, queue tree สำหรับลำดับชั้นและ priority และ PCQ สำหรับการแบ่งใช้อย่างเป็นธรรมในหมู่ผู้ใช้จำนวนมากโดยไม่ต้องสร้าง queue ทีละราย queue tree ทำงานคู่กับ firewall mangle mark และให้ทั้งการรับประกันความเร็วขั้นต่ำ เพดานสูงสุด และลำดับความสำคัญ คู่มือนี้แสดงให้เห็นว่าควรใช้อะไรเมื่อใด พร้อมคำสั่ง RouterOS และวิธีรักษานโยบายเดียวกันให้สอดคล้องกันทั่วทั้งฟลีตเราเตอร์

การจัดการแบนด์วิดท์บน MikroTik คืออะไร

การจัดการแบนด์วิดท์บน MikroTik คือการใช้ queue ของ RouterOS เพื่อควบคุมว่าลูกค้า, ซับเน็ต หรือคลาสของทราฟฟิกแต่ละรายสามารถใช้ลิงก์ได้มากน้อยเพียงใด ทั้งการจำกัดความเร็ว การรับประกันขั้นต่ำ และการตัดสินว่าใครต้องยอมเมื่อลิงก์เต็ม RouterOS สร้าง queue ด้วยตัวจัดคิวแบบ Hierarchical Token Bucket (HTB) ซึ่งเปิดให้ใช้งานในสองที่ คือ simple queue ที่เป็นรายการเรียงลำดับซึ่งประมวลผลตามลำดับ และ queue tree ที่เป็นลำดับชั้นซึ่งผูกกับ interface หรือกับ packet mark จากฟีเจอร์ mangle ของไฟร์วอลล์ (MikroTik Documentation — Queues)

ความแตกต่างนี้เป็นตัวกำหนดว่าการออกแบบของคุณจะขยายได้ไกลแค่ไหน simple queue ตอบคำถามว่า “จำกัดลูกค้ารายนี้ที่ 50 Mbps” ส่วน queue tree ตอบว่า “อัปลิงก์ 500 Mbps นี้ถูกแชร์โดยสมาชิก 300 ราย VoIP มาก่อน ไม่มีใครขาดแคลน และคนที่ดาวน์โหลดหนักๆ จะไม่ทำลายช่วงค่ำของคนอื่น” ในที่สุดทุก ISP ก็ต้องการคำตอบแบบที่สอง

ขั้นตอนที่ 1 — จำกัดลูกค้าหนึ่งรายด้วย simple queue

simple queue คือเส้นทางที่สั้นที่สุดจากปัญหาไปสู่การแก้ไข ระบุเป้าหมายเป็น IP, ซับเน็ต หรือ interface ตั้งค่าเพดาน แล้วก็เสร็จ:

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

max-limit เขียนในรูปแบบ upload/download เมื่อมองจากมุมของเราเตอร์ กฎถูกประมวลผลตามลำดับและกฎแรกที่ตรงจะชนะ ดังนั้นกฎกว้างๆ ที่อยู่ก่อนจะกลืนกฎเฉพาะเจาะจงที่คุณเพิ่มทีหลังไปอย่างเงียบๆ การเรียงลำดับนี้เป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้ queue ที่ “ใช้งานได้” หยุดทำงานหลังจากมีคนเพิ่มกฎไว้เหนือมัน (MikroTik Documentation — Queues)

simple queue ยังทำงานคู่กับการยืนยันตัวตนสมาชิกได้ด้วย ฟิลด์ rate-limit ของ PPPoE profile จะสร้าง simple queue แบบไดนามิกให้แต่ละเซสชัน แผนจึงติดตามตัวผู้ใช้แทนที่จะติดตาม IP คู่มือ MikroTik PPPoE server สำหรับ ISP ของเราครอบคลุมฝั่ง profile ไว้แล้ว

ขั้นตอนที่ 2 — มาร์กทราฟฟิกด้วย firewall mangle

queue tree มองไม่เห็น “VoIP” หรือ “ลูกค้า 101” มันเห็นแค่ packet mark สร้างมันขึ้นมาใน mangle โดยมาร์ก connection ก่อนแล้วจึงมาร์ก packet ทีหลัง ซึ่งประหยัดกว่าการตรวจสอบทุก packet ซ้ำ:

/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

รักษาระบบการตั้งชื่อ mark ให้เล็กและคงที่ mark คือคำศัพท์ที่ queue ของคุณใช้สื่อสาร และเมื่อฟลีตหนึ่งมีชื่อ mark ที่ตั้งกันเองสามยุคสามสมัย ก็ไม่มีใครบอกได้ว่าเราเตอร์เครื่องไหนบังคับใช้นโยบายใด นี่คือจุดที่การตรวจสอบและประวัติการตั้งค่าของ MKController แสดงคุณค่าออกมา ดูสถานะ mangle และ queue ของเราเตอร์ทุกเครื่อง เทียบกับนโยบายที่ตั้งใจไว้ แล้วส่งกฎที่แก้ไขแล้วออกไปทั้งฟลีต แทนที่จะต้องเปิดเซสชัน Winbox สามสิบครั้งเพื่อตามหาเครื่องเดียวที่ไม่เคยได้รับการเปลี่ยนแปลงนั้น

ขั้นตอนที่ 3 — สร้างลำดับชั้นของ queue tree

queue tree มี parent หนึ่งตัวที่ถือความจุจริงของลิงก์ไว้ และมี child ที่แบ่งความจุนั้นออกไป:

/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

มีสามฟิลด์ที่ทำงานหลัก limit-at คือความเร็วที่รับประกันว่า child จะได้รับแม้ในตอนที่ลิงก์เต็ม max-limit คือเพดานที่มันอาจไปถึงได้เมื่อยังมีความจุว่าง priority — 1 คือสูงสุด 8 คือต่ำสุด — เป็นตัวตัดสินว่า child ตัวไหนจะได้ส่วนที่เหลือก่อน และมีผลเฉพาะในช่วงระหว่าง limit-at กับ max-limit เท่านั้น (MikroTik Documentation — Queues) ตั้งค่า max-limit ของ parent ให้เท่ากับที่ลิงก์ส่งได้จริง ไม่ใช่ตามที่สัญญาระบุ ไม่เช่นนั้น queue จะไม่มีวันกลายเป็นคอขวดและจะไม่ควบคุมอะไรเลย

ขั้นตอนที่ 4 — เพิ่ม PCQ สำหรับการแบ่งใช้อย่างเป็นธรรม

Per Connection Queue (PCQ) คือเหตุผลที่ MikroTik ขยายไปรองรับจำนวนสมาชิกที่มากจนทำให้การจัดการรายการ queue ต่อผู้ใช้ทีละรายเป็นไปไม่ไหว PCQ queue type จะจำแนกทราฟฟิกตามฟิลด์ที่อยู่ และสร้าง sub-queue แบบไดนามิกให้แต่ละค่าที่แตกต่างกัน โดยใช้ความเร็วเท่ากันกับแต่ละอัน (MikroTik Documentation — PCQ example):

/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

ผูก pcq-down เป็น queue ของ child ที่รับทราฟฟิกดาวน์โหลดของลูกค้า แล้วลูกค้าทุกรายจะได้รับความเร็วสูงสุด 20 Mbps โดยจัดสรรอัตโนมัติ ตั้งค่า pcq-rate=0 แล้ว PCQ จะแบ่งแบนด์วิดท์ของ parent ให้เท่าๆ กันในหมู่ผู้ที่กำลังใช้งานอยู่ ซึ่งเป็นการตั้งค่าแบบ “ไม่มีใครขาดแคลน” อันคลาสสิก queue type เพียงตัวเดียวแทนที่รายการที่เขียนด้วยมือนับร้อยรายการ

ตรรกะการแบ่งให้เท่ากันแบบเดียวกันนี้ใช้ได้กับ WiFi ที่แชร์กัน การจำกัดความเร็วของแผนและ PCQ parent ร่วมกันจะกันไม่ให้ผู้ใช้งานคนหนึ่งกินอัปลิงก์ของสถานที่ไปหมด ดูคู่มือตั้งค่า MikroTik HotSpot voucher ของเราสำหรับฝั่งข้อมูลรับรอง

ขั้นตอนที่ 5 — ปรับ limit-at, max-limit, burst และ priority

QoS ที่เสียส่วนใหญ่ไม่ได้เกิดจากเครื่องมือที่ผิด แต่เกิดจากตัวเลขที่ผิด รักษาผลรวมของ limit-at ของ child ทุกตัวให้เท่ากับหรือน้อยกว่า max-limit ของ parent ถ้าการรับประกันมีมากเกินความจุของลิงก์ HTB จะไม่สามารถทำตามได้และ priority จะไม่ทำงานอย่างที่คุณคาดหวัง สงวน priority=1 ไว้สำหรับทราฟฟิกที่ไวต่อความหน่วง เช่น VoIP, เกม, DNS และปล่อยให้การถ่ายโอนข้อมูลจำนวนมากอยู่ที่ 8 พร้อมเพดานที่ใจกว้าง

burst สมควรได้รับคำเตือน burst-limit, burst-threshold และ burst-time ยอมให้ลูกค้าเกิน max-limit ได้ชั่วครู่ในขณะที่ค่าเฉลี่ยยังคงต่ำ ดีสำหรับการทดสอบความเร็ว แต่แย่สำหรับลิงก์ที่ถูกจองเกิน วัดผลด้วย /queue simple print stats หรือ counter ของ queue tree ในขณะที่ลิงก์กำลังมีโหลด ไม่ใช่ตอนตีสามที่ทุกอย่างว่างเปล่า หากการอ่าน counter ในช่วงพีคทำได้ไม่สะดวก มุมมอง Internet Link ของ MKController จะเก็บภาพเดียวกันนี้ไว้อย่างต่อเนื่อง ทั้งการใช้งานเทียบกับความเร็วตามสัญญา ความหน่วงในรูปค่าเฉลี่ย ค่าสูงสุด และ P95 และจำนวนชั่วโมงที่แต่ละลิงก์ใช้งานเกิน 90% เพื่อให้คุณปรับจูนโดยอ้างอิงจากประวัติ ไม่ใช่ภาพสแนปช็อตที่ฟลุ๊ก

ความจุก็เปลี่ยนแปลงได้เช่นกัน บนการตั้งค่า dual-WAN failover ค่า max-limit ของ parent ที่คุณปรับไว้สำหรับไฟเบอร์จะกลายเป็นเรื่องเพ้อฝันทันทีที่ทราฟฟิกไปตกที่ LTE สำรอง จึงควรวางแผนนโยบายที่สองไว้ด้วย

ขั้นตอนที่ 6 — นำนโยบายไปใช้ทั่วทั้งฟลีต

เราเตอร์หนึ่งเครื่องคือการตั้งค่า แต่เราเตอร์ร้อยเครื่องคือปฏิบัติการ ตอนนี้นโยบายต้องเหมือนกันในทุกเครื่อง ต้องอยู่รอดจากช่างที่ “ชั่วคราว” ปรับเพดานของลูกค้าให้สูงขึ้น และต้องกู้คืนได้เมื่อเราเตอร์บนเสาถูก netinstall ไม่มีอะไรใน RouterOS ที่ทำสิ่งนั้นให้คุณ

MKController ทำได้ ทั้งการส่ง queue type, rate-limit profile และกฎไฟร์วอลล์ออกไปทั้งฟลีต ประวัติการตั้งค่าที่ทำให้คุณเห็นว่าขีดจำกัดเปลี่ยนไปเมื่อใดและกู้คืนเวอร์ชันก่อนหน้าได้ในคลิกเดียว การสำรองข้อมูลอัตโนมัติก่อนการเปลี่ยนแปลง และการเข้าถึงเราเตอร์จากระยะไกลผ่านช่องทางขาออกที่ปลอดภัยสำหรับเราเตอร์ที่อยู่หลัง CGNAT หรือบน Starlink โดยไม่ต้องมี IP สาธารณะและไม่ต้องทำ port forwarding ซึ่งเป็นแนวทางที่เราอธิบายไว้ในการจัดการ MikroTik ระยะไกลเบื้องหลัง CGNAT และระบบมอนิเตอร์ Internet Link ของมันก็คอยเฝ้าดูอัปลิงก์ที่คุณเพิ่งควบคุมไป ทั้งการใช้งานต่อแหล่งเทียบกับความเร็วตามสัญญา ความหน่วงพร้อม P95 และการใช้งานที่ข้ามแถบ 75% และ 90% ในแหล่ง WAN ได้สูงสุดสี่แหล่งต่อเราเตอร์ ดังนั้นลิงก์ที่ค่อยๆ ไต่เข้าใกล้จุดเต็มจะปรากฏขึ้นบนแดชบอร์ด และ (เมื่อจับคู่กับการแจ้งเตือน Telegram) ในการแจ้งเตือนของคุณ ก่อนที่สมาชิกจะโทรมา ISP และ WISP ที่รัน MikroTik ในระดับใหญ่ใช้มันเพื่อให้นโยบายแบนด์วิดท์ยังคงเป็นการตัดสินใจครั้งเดียว ไม่ใช่ร้อยครั้ง

เคล็ดลับ

• ควบคุมทราฟฟิกบน interface ที่ทราฟฟิกออกจากเราเตอร์ เพราะ queue ควบคุมขาออก ดังนั้นการดาวน์โหลดจะถูกควบคุมที่ฝั่ง LAN และการอัปโหลดที่ฝั่ง WAN
• เลือกใช้ PCQ queue type เพียงตัวเดียวแทน simple queue นับร้อยเมื่อคุณมีสมาชิกเกินไม่กี่สิบราย
• passthrough=no บนกฎ mark-packet ช่วยประหยัดการไล่ผ่านกฎ mangle ที่เหลือโดยไม่จำเป็น
• สำรองข้อมูลเสมอก่อนแตะต้อง queue บน edge ที่ใช้งานจริง และเปลี่ยนทีละตัวแปร

เลิกเดาว่าแบนด์วิดท์ของคุณหายไปไหน

queue คือความแตกต่างระหว่างการขายแผนกับการส่งมอบแผนนั้นจริงๆ simple queue จำกัดความเร็วลูกค้า queue tree ให้โครงสร้างและ priority PCQ ทำให้ความเป็นธรรมเกิดขึ้นโดยอัตโนมัติ และ MKController เปลี่ยนทั้งสามอย่างนี้ให้เป็นนโยบายที่คุณตั้งครั้งเดียวแล้วบังคับใช้ได้ทุกที่ ทั้งการจัดการฟลีตแบบรวมศูนย์ การส่ง rate-limit และกฎไฟร์วอลล์ไปยังทุกเราเตอร์ ประวัติการตั้งค่าพร้อมกู้คืนในคลิกเดียว การเข้าถึงระยะไกลโดยไม่ต้องมี IP สาธารณะ และระบบมอนิเตอร์ Internet Link ที่แจ้งเตือนลิงก์ที่กำลังเต็มเทียบกับความเร็วตามสัญญาก่อนที่ลูกค้าของคุณจะแจ้ง

เริ่มทดลองใช้ MKController ฟรี