MikroTik RB5009UG+S + RouterOS 7.22.3 搭載 100 人環境的設定筆記

搭載中華電信 500M 雙向,掛載 100 台機器在線。

階段一:Cake QoS 基礎建置 (解決 Bufferbloat)

要讓網路在滿載時依然保持低延遲,導入 Cake 演算法並關閉干擾機制是首要任務。

1. 關閉 FastTrack (關鍵前置作業)

FastTrack 會讓封包繞過 QoS 佇列,必須將其完全關閉。
  • IPv4:進入 IP > Firewall > Filter Rules,停用 Action 為 fasttrack-connection 的規則。
  • IPv6:進入 IPv6 > Firewall > Filter Rules,停用對應的 fasttrack-connection 規則。
  • 生效方式:進入 IP > Firewall > Connections,全選並移除所有現有連線,或直接重啟路由器。

2. 建立專屬 Cake 佇列類型 (Queue Types)

進入 Queues > Queue Types 建立上傳與下載的專屬規則:
  • 下載佇列 (Cake-RX):Name 命名為 cake-rx,Kind 選擇 cake。Flow Isolation 設定為 dual-dsthost (依目的端 IP 公平分配),並勾選 NAT
  • 上傳佇列 (Cake-TX):Name 命名為 cake-tx,Kind 選擇 cake。Flow Isolation 設定為 dual-srchost (依來源端 IP 公平分配),並勾選 NAT

3. 套用簡易佇列 (Simple Queues)

進入 Queues > Simple Queues 將 QoS 套用至內網。
  • Name: Cake-QoS
  • Target: 加入 10.0.0.0/24 (Bridge) 與 10.0.1.0/24 (Wireguard)。
  • Max Limit: 雙向皆設定為實體頻寬的 95%(約 475M)。
  • Queue Type: Upload 選擇 cake-tx,Download 選擇 cake-rx。

階段二:Cake QoS 進階微調 (演算法最佳化)

精準計算實體層開銷,並處理外網雜亂的 QoS 標籤。
<thead></thead>
設定項目
上傳端 (cake-tx)
下載端 (cake-rx)
設定目的
Overhead 34 (或 pppoe) 34 (或 pppoe) 補償 PPPoE 額外表頭帶來的頻寬計算誤差。
MPU 64 64 設定最小封包單位。
Ack Filter filter none 過濾多餘 TCP ACK 封包,提升上傳真實效率。
Wash 不勾選 勾選 (Yes) 清洗外網混亂的 DSCP 標籤,避免干擾內網 Wi-Fi 的 WMM 機制。
Diffserv diffserv4 besteffort 上傳內網標籤準確,分四級處理;下載標籤已洗淨,單一佇列分配以節省 CPU 資源。

階段三:百人環境乘載優化 (突破基礎限制)

設備數量達到 100 台時,必須解決網路資源分配的瓶頸。

1. 限制單一 IP 異常連線數 (防範 P2P 癱瘓)

進入 IP > Firewall > Filter Rules 新增兩條規則(TCP 與 UDP 各一),並移至清單上方:
Chain: forward
Src. Address: 10.0.0.0/24
Protocol: tcp (與 udp)
Advanced -> Connection Limit: 500, Netmask: 32
Action: drop


2. DNS 解析效能提升

進入 IP > DNS:
  • DoH Max Concurrent Queries 提升至 500。
  • DoH Max Server Connections 提升至 50。
  • Cache Size 擴充至 4096 或 8192 KiB。

3. 避免 1G 實體瓶頸

串接百人主交換器 (Switch) 時,應使用 RB5009 的 10G sfp-sfpplus1 埠或 2.5G ether2 埠作為 Uplink,確保區域網路傳輸瓶頸大於 WAN 頻寬。

階段四:榨乾效能與極致低延遲 (極客級設定)

減少 CPU 處理雜訊的負擔,將所有運算能力全數投入於封包轉發。

1. 防火牆規則最佳化

  • 提升既有規則優先級:進入 IP > Firewall > Filter Rules,將 Chain 為 forward 與 input 的 established,related,untracked 規則分別拖曳至各區塊的最頂端。

2. MSS clamp to PMTU 設定(IPv4 + IPv6 Firewall)

為避免 PPPoE 導致封包過大遭丟棄,建立 Mangle 規則動態調整 TCP MSS:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=pppoe-out1 protocol=tcp tcp-flags=syn

3. 啟用 Baby Jumbo Frames (達成 MTU 1500)

進入 Interfaces 打開 pppoe-out1,將 Max MTUMax MRU 強制修改為 1500,解除傳統 PPPoE 1492 的限制。

4. 激進的連線追蹤瘦身

進入 IP > Firewall > Connections > Tracking:
  • TCP Established Timeout:縮短至 00:30:00。
  • UDP Timeout:縮短至 00:00:10。
  • UDP Stream Timeout:縮短至 00:02:00。

5. 關閉實體層 Flow Control 與限縮廣播

  • 進入 Interfaces > Ethernet,確保所有實體網卡的 Tx / Rx Flow Control 皆為 off。
  • 進入 IP > Neighbor > Discovery Settings,以及 Tools > MAC Server,嚴格將允許介面限制為 LAN。

階段五:IPv6 進階效能最佳化

同步 IPv4 的效能設定,並優化 IPv6 的基礎設施。

1. IPv6 MTU 與 RA 廣播優化

進入 IPv6 > ND,編輯 bridge 介面的設定:
  • MTU 欄位手動設定為 1500,配合 Baby Jumbo Frames。
RA Interval 縮短為 20s - 60s,加快休眠設備喚醒後取得 IPv6 的速度。


RB3009 路過...
我會覺得, 安全性大於轉發效率. AGH / snort / Suricata 好歹裝一下.
Baby Jumbo Frames對於瀏覽網路幫助微乎其微,

瀏覽網頁時大量的 HTTP 請求與回應、小圖片、文字等封包,
大小通常遠低於 1492 位元組,根本不會觸發封包分段。

況且ISP 的機房設備(BRAS)必須允許接收大於 1500 核心長度的 PPPoE 協商。
只要你是使用小烏龜,這點就不可能...

與其在封包下手,不如rb5009啟用Hardware Offload讓switch chip分流。
L2 Hardware Offloading (Switching):
主要用於 Bridge 中的數據交換。當多個網孔加入同一個 Bridge 且開啟此功能時,
它們的運作方式就像一台實體交換機。
在bridge port接口勾選Hardware Offload即可,成功port接口會標註H

L3 Hardware Offloading (IP Routing):
較新的功能(主要見於 CRS3xx/5xx 系列或 RB5009 等),
允許將 Layer 3(路由與 NAT) 的任務也交由硬體加速,進一步提升路由效能。
pppoe裡add default route不要勾選,路由表手動新增dst-address=0.0.0.0/0規則,並將suppress hw offload勾選。

因pppoe設定的add default route預設不會勾選suppress hw offload,所以才需手動規則來強制啟用。


以上是ipv4部分。至於ipv6使用無狀態,
將isp給的GUA(/64公網段)直接分ip給裝置對router資源吃的最少了。但就怕GUA更新網段...

好在這問題v7.22.2獲得更新,但像suppress hw offload並未納入為預設選項。所以需手動啟用它~
https://www.mobile01.com/topicdetail.php?f=110&t=3205444&p=869#93109183

若您的內部網路是用fc00::/10(ULA),然後在nat啟用masquerade偽裝對外,這判定是有狀態交換;不過在v7.18後您也可以採無狀態交換的NPTv6,省缺cpu追蹤來加速。
https://www.mobile01.com/topicdetail.php?f=110&t=3205444&p=869#93112071
文章分享
評分
評分
複製連結

今日熱門文章 網友點擊推薦!