آموزش Bandwidth Test در میکروتیک؛ تست پهنای باند با WinBox و ترمینال

هنگام راه‌اندازی یک لینک کابلی، وایرلس، فیبر نوری یا تونل VPN، مشاهده نرخ اتصال Interface به‌تنهایی برای ارزیابی عملکرد واقعی شبکه کافی نیست. ممکن است پورت Ethernet با نرخ یک گیگابیت متصل باشد یا رادیوی وایرلس نرخ بالایی را نمایش دهد، اما سرعت واقعی انتقال داده به دلیل نویز، افت بسته، محدودیت پردازنده، تنظیمات Queue یا مشکلات مسیر بسیار کمتر باشد.

ابزار Bandwidth Test در MikroTik RouterOS برای تولید ترافیک آزمایشی میان دو دستگاه و اندازه‌گیری Throughput در جهت ارسال، دریافت یا هر دو جهت استفاده می‌شود. این ابزار از پروتکل‌های TCP و UDP پشتیبانی می‌کند و از طریق WinBox یا ترمینال RouterOS قابل اجرا است.

Bandwidth Test می‌تواند در شناسایی گلوگاه‌های شبکه، ارزیابی ظرفیت لینک وایرلس، تست تونل VPN، بررسی عدم تقارن سرعت و مقایسه تنظیمات مختلف کاربرد داشته باشد. با این حال، استفاده نادرست از این ابزار ممکن است نتیجه‌ای کمتر از ظرفیت واقعی لینک نشان دهد یا حتی شبکه عملیاتی را برای مدت تست اشباع کند.

هشدار مهم: Bandwidth Test به‌صورت پیش‌فرض می‌تواند تمام پهنای باند در دسترس را مصرف کند. اجرای آن در ساعات کاری ممکن است باعث افزایش Latency، افت تماس‌های VoIP، کندی اینترنت، اختلال دوربین‌ها و قطع Sessionهای حساس شود. برای تست شبکه عملیاتی، حتماً نرخ ارسال و مدت تست را محدود کنید.

ابزار Bandwidth Test در میکروتیک چیست؟

Bandwidth Test یک ابزار تولید و دریافت ترافیک در RouterOS است که ارتباطی آزمایشی میان یک Bandwidth Test Client و یک Bandwidth Test Server ایجاد می‌کند.

در این ساختار:

  • Bandwidth Test Client: دستگاهی است که تست را آغاز و پارامترهای آن را تعیین می‌کند.
  • Bandwidth Test Server: دستگاه مقصدی است که ترافیک تست را دریافت یا ارسال می‌کند.
  • Device Under Test: روتر، لینک، تونل یا زیرساختی است که ظرفیت عبور ترافیک آن بررسی می‌شود.

ساده‌ترین سناریو استفاده از دو دستگاه MikroTik است:

MikroTik A ─────────────── MikroTik B
BTest Client BTest Server

این روش برای بررسی سریع ظرفیت ارتباط میان دو دستگاه مناسب است، اما اگر هدف اندازه‌گیری توان Forwarding یکی از همان دستگاه‌ها باشد، نتیجه می‌تواند تحت تأثیر پردازش تولید و دریافت ترافیک قرار بگیرد.

Bandwidth Test چه مواردی را اندازه‌گیری می‌کند؟

با توجه به نوع و جهت تست، اطلاعات زیر قابل مشاهده هستند:

  • نرخ لحظه‌ای ارسال یا TX Current
  • نرخ لحظه‌ای دریافت یا RX Current
  • میانگین ده ثانیه اخیر
  • میانگین کل مدت تست
  • تعداد بسته‌های ازدست‌رفته در تست UDP
  • اندازه بسته‌های UDP
  • پروتکل و جهت تست
  • وضعیت برقراری Session

Bandwidth Test به‌تنهایی ابزار کاملی برای اندازه‌گیری Latency و Jitter نیست. برای بررسی Ping، Jitter و Packet Loss همراه با تست TCP و UDP می‌توان از ابزار Speed Test یا تست‌های جداگانه Ping استفاده کرد.

تفاوت Bandwidth، Throughput و نرخ اتصال چیست؟

اصطلاحتوضیح
Bandwidthظرفیت اسمی یا تئوری یک مسیر ارتباطی
PHY Rate یا Link Rateنرخ فیزیکی مذاکره‌شده روی Ethernet یا وایرلس
Throughputحجم واقعی داده‌ای که در واحد زمان منتقل می‌شود
Goodputحجم Payload مفید برنامه پس از حذف تمام سربارها

برای مثال، نمایش نرخ 867Mbps روی یک لینک وایرلس به معنای انتقال واقعی 867Mbps فایل نیست. سربار پروتکل، ACK، Retransmission، زمان انتظار کانال و محدودیت Ethernet باعث می‌شوند Throughput واقعی کمتر باشد.

چرا روش اجرای تست اهمیت دارد؟

Bandwidth Test علاوه بر انتقال داده، باید ترافیک را تولید یا دریافت کند. این عملیات توسط CPU دستگاه انجام می‌شود. اگر همان روتری که قرار است توان Forwarding آن اندازه‌گیری شود، نقش Client یا Server تست را نیز داشته باشد، پردازنده باید هم‌زمان دو وظیفه را انجام دهد:

  • تولید یا خاتمه ترافیک آزمایشی
  • پردازش Routing، Firewall، Queue، Bridge یا VPN

در چنین حالتی ممکن است CPU پیش از اشباع‌شدن لینک به ۱۰۰ درصد برسد و نتیجه نهایی به‌اشتباه پایین‌تر از ظرفیت واقعی شبکه گزارش شود.

توپولوژی صحیح برای تست توان واقعی روتر

برای اندازه‌گیری دقیق‌تر توان عبور ترافیک یک روتر، بهتر است تولیدکننده و دریافت‌کننده ترافیک روی دو دستگاه جدا قرار داشته باشند و ترافیک از روتر مورد آزمایش عبور کند:

BTest Client ───── Device Under Test ───── BTest Server

برای مثال:

Router A ───────── Router B ───────── Router C
Client DUT Server

در این ساختار Router B فقط ترافیک را Forward می‌کند و Router A و Router C وظیفه تولید و دریافت آن را بر عهده دارند.

برای تست لینک‌های پرظرفیت می‌توان به‌جای RouterOS Bandwidth Test، دو کامپیوتر یا سرور مجهز به iperf3 را در دو سمت Device Under Test قرار داد:

iperf3 Client ───── Router/Switch ───── iperf3 Server

این روش معمولاً برای لینک‌های چندگیگابیتی و ارزیابی Hardware Offloading نتیجه واقع‌بینانه‌تری ارائه می‌دهد.

پیش‌نیازهای اجرای Bandwidth Test

قبل از شروع تست، موارد زیر را بررسی کنید:

  • دو دستگاه باید از طریق IP به یکدیگر دسترسی داشته باشند.
  • Bandwidth Test Server روی دستگاه مقصد فعال باشد.
  • Firewall مسیر ارتباط را مسدود نکرده باشد.
  • نام کاربری و رمز عبور معتبر در مقصد وجود داشته باشد.
  • کاربر مقصد دسترسی لازم برای احراز هویت Bandwidth Test را داشته باشد.
  • Device Mode اجازه اجرای Bandwidth Test را بدهد.
  • CPU و Interfaceهای دستگاه قبل از تست در وضعیت عادی باشند.
  • تست در زمان مناسب و با نرخ کنترل‌شده انجام شود.

بررسی Device Mode در RouterOS v7

در نسخه‌های جدید RouterOS، قابلیت‌هایی مانند Bandwidth Test ممکن است توسط Device Mode محدود شده باشند. ابتدا وضعیت آن را بررسی کنید:

/system/device-mode/print

در خروجی به مقدار زیر توجه کنید:

bandwidth-test: yes

اگر مقدار آن no باشد، اجرای Bandwidth Test، Bandwidth Server و Speed Test امکان‌پذیر نخواهد بود.

برای درخواست فعال‌سازی قابلیت می‌توان از دستور زیر استفاده کرد:

/system/device-mode/update bandwidth-test=yes

فعال‌سازی Device Mode به تأیید فیزیکی نیاز دارد. باید در مهلت نمایش‌داده‌شده برق دستگاه قطع و وصل شود یا دکمه مورد تأیید دستگاه فشار داده شود. این عملیات باعث ریبوت روتر خواهد شد.

هشدار: تنظیم Device Mode را فقط زمانی تغییر دهید که دسترسی فیزیکی به دستگاه دارید. در سایت‌های دوردست یا روترهای حساس، اجرای این دستور بدون برنامه‌ریزی می‌تواند باعث قطع دسترسی شود.

فعال‌کردن Bandwidth Test Server در WinBox

برای فعال‌کردن سرور تست در دستگاه مقصد:

  1. با WinBox به دستگاه مقصد متصل شوید.
  2. از منوی سمت چپ وارد بخش Tools شوید.
  3. گزینه BTest Server را انتخاب کنید.
  4. گزینه Enabled را فعال کنید.
  5. گزینه Authenticate را فعال نگه دارید.
  6. تعداد Max Sessions را براساس نیاز محدود کنید.
  7. تنظیمات را ذخیره کنید.

در شبکه عملیاتی توصیه می‌شود Authenticate فعال باشد و سرور تست فقط برای مدت موردنیاز روشن شود.

فعال‌کردن Bandwidth Test Server از طریق ترمینال

برای مشاهده تنظیمات فعلی:

/tool bandwidth-server print

برای فعال‌کردن سرور همراه با احراز هویت:

/tool bandwidth-server
set enabled=yes authenticate=yes max-sessions=1

پارامترهای اصلی Bandwidth Server عبارت‌اند از:

پارامترکاربرد
enabledفعال یا غیرفعال‌کردن BTest Server
authenticateالزام نام کاربری و رمز عبور معتبر
max-sessionsحداکثر تعداد تست هم‌زمان
allocate-udp-ports-fromپورت شروع برای Sessionهای UDP

چرا نباید Authenticate را غیرفعال کنیم؟

فعال‌کردن Bandwidth Server بدون احراز هویت می‌تواند به کاربران غیرمجاز اجازه دهد ظرفیت شبکه و پردازنده روتر را مصرف کنند. در بدترین حالت، مهاجم می‌تواند با ایجاد ترافیک سنگین باعث اختلال سرویس شود.

از تنظیم زیر در شبکه عملیاتی استفاده نکنید:

/tool bandwidth-server
set enabled=yes authenticate=no

این حالت فقط در آزمایشگاه بسته و موقت قابل قبول است.

ایجاد کاربر جداگانه برای Bandwidth Test

بهتر است به‌جای استفاده از حساب اصلی admin، یک کاربر اختصاصی و محدود برای تست ایجاد شود.

نمونه ایجاد گروه محدود:

/user group
add name=btest-group policy=test,winbox

سپس یک کاربر با رمز قوی و محدودیت آدرس مبدأ ایجاد کنید:

/user
add name=btest-user \
 group=btest-group \
 password="USE-A-STRONG-UNIQUE-PASSWORD" \
 address=10.10.10.1/32

آدرس 10.10.10.1 در این مثال IP دستگاهی است که اجازه اجرای تست را دارد و باید براساس شبکه واقعی تغییر داده شود.

پورت مورد استفاده Bandwidth Test

سرویس Bandwidth Test برای ارتباط کنترلی از TCP پورت 2000 استفاده می‌کند. در تست UDP نیز پورت‌های UDP از مقداری که در allocate-udp-ports-from مشخص شده است، تخصیص داده می‌شوند.

اگر Firewall ورودی روتر مقصد محدود است، دسترسی TCP پورت 2000 را فقط از IP دستگاه تست‌کننده مجاز کنید:

/ip firewall filter
add chain=input \
 src-address=10.10.10.1 \
 protocol=tcp \
 dst-port=2000 \
 action=accept \
 comment="Allow BTest from trusted host"

برای تست UDP نیز باید بازه موردنیاز UDP از همان مبدأ قابل دسترسی باشد. Ruleهای دسترسی باید قبل از قانون Drop عمومی قرار گیرند.

پورت Bandwidth Test نباید به‌صورت عمومی روی اینترنت باز شود. برای تست از راه دور بهتر است ابتدا یک VPN امن مانند WireGuard ایجاد شود و تست از داخل شبکه مدیریتی انجام گیرد.

آموزش اجرای Bandwidth Test در WinBox

پس از آماده‌سازی دستگاه مقصد، روی دستگاه مبدأ مراحل زیر را انجام دهید:

  1. با WinBox وارد دستگاه مبدأ شوید.
  2. از منوی سمت چپ وارد بخش Tools شوید.
  3. گزینه Bandwidth Test را انتخاب کنید.
  4. در بخش Test To، آدرس IP دستگاه مقصد را وارد کنید.
  5. پروتکل TCP یا UDP را انتخاب کنید.
  6. جهت تست را روی Transmit، Receive یا Both قرار دهید.
  7. نام کاربری و رمز عبور دستگاه مقصد را وارد کنید.
  8. در صورت استفاده از UDP، نرخ و اندازه بسته را تنظیم کنید.
  9. روی دکمه Start کلیک کنید.
  10. هم‌زمان مصرف CPU و وضعیت Interfaceها را بررسی کنید.

معنی گزینه Test To چیست؟

در این بخش IP دستگاهی وارد می‌شود که Bandwidth Test Server روی آن فعال است. آدرس مقصد باید از طریق Routing Table دستگاه مبدأ قابل دسترسی باشد.

قبل از اجرای تست، اتصال را با Ping بررسی کنید:

/ping 10.10.10.2 count=10

اگر Ping برقرار نیست، ابتدا Routing، VLAN، Firewall و IP Addressها را اصلاح کنید. Bandwidth Test نمی‌تواند نبود ارتباط پایه شبکه را جبران کند.

معنی جهت‌های Transmit، Receive و Both

جهت تست از دید دستگاهی تعیین می‌شود که Bandwidth Test را آغاز کرده است.

Directionمسیر ترافیک
Transmit یا Sendاز دستگاه Client به سمت Server
Receiveاز دستگاه Server به سمت Client
Bothارسال و دریافت هم‌زمان در هر دو جهت

برای عیب‌یابی حرفه‌ای بهتر است ابتدا هر جهت جداگانه تست شود و سپس تست Both اجرا شود. تست هم‌زمان ممکن است CPU، Queue یا Airtime لینک وایرلس را میان دو جهت تقسیم کند.

چرا نتیجه Transmit و Receive متفاوت است؟

نامتقارن‌بودن سرعت می‌تواند دلایل مختلفی داشته باشد:

  • تفاوت نرخ TX و RX لینک وایرلس
  • نویز بیشتر در یکی از سمت‌ها
  • تنظیم متفاوت توان ارسال
  • Queue یا محدودیت پهنای باند یک‌طرفه
  • مسیر Routing متفاوت
  • مشکل Duplex یا کابل شبکه
  • مصرف CPU متفاوت در Client و Server
  • تعداد Connectionهای TCP
  • عدم تقارن تونل یا سرویس اینترنت

اختلاف سرعت به‌تنهایی ثابت نمی‌کند که رادیو یا روتر خراب است. باید Signal، نرخ لینک، CPU، Interface Errors و مسیر ترافیک نیز بررسی شوند.

تفاوت تست TCP و UDP در MikroTik

ویژگیTCPUDP
تضمین تحویلداردندارد
ارسال مجدد بستهداردندارد
کنترل ازدحامداردندارد
تأثیرپذیری از Latencyزیادترکمتر
امکان مشاهده Packet Lossغیرمستقیم و با Retransmissionمستقیم‌تر
کاربرد اصلیشبیه‌سازی انتقال‌های مبتنی بر TCPبررسی ظرفیت، Loss و پایداری در نرخ مشخص

تست TCP چه چیزی را نشان می‌دهد؟

TCP دارای مکانیزم ACK، ارسال مجدد، کنترل جریان و کنترل ازدحام است. اگر Packet Loss، Latency یا Jitter افزایش یابد، TCP نرخ ارسال را کاهش می‌دهد.

تست TCP برای بررسی عملکرد کاربردهای زیر مفید است:

  • انتقال فایل
  • HTTP و HTTPS
  • Backup شبکه
  • دسترسی به NAS
  • بسیاری از سرویس‌های سازمانی

با این حال، نتیجه TCP فقط به ظرفیت فیزیکی لینک وابسته نیست. موارد زیر نیز روی آن اثر می‌گذارند:

  • Round Trip Time
  • Packet Loss
  • TCP Window
  • تعداد Connectionها
  • توان پردازنده دو دستگاه
  • الگوریتم کنترل ازدحام

در آمار Bandwidth Test، تست TCP فقط داده TCP را محاسبه می‌کند و Headerهای IP و TCP و ترافیک ACK در عدد Throughput گزارش‌شده لحاظ نمی‌شوند.

پارامتر Connection Count در تست TCP

یک TCP Connection ممکن است نتواند تمام ظرفیت لینک‌های دارای Latency بالا را مصرف کند. پارامتر Connection Count امکان اجرای چند جریان TCP هم‌زمان را فراهم می‌کند.

نمونه تست با چهار Connection:

/tool bandwidth-test \
 address=10.10.10.2 \
 protocol=tcp \
 direction=both \
 connection-count=4 \
 duration=30s \
 user=btest-user \
 password="YOUR-PASSWORD"

افزایش تعداد Connectionها می‌تواند Throughput را بیشتر کند، اما فشار بیشتری به CPU و Connection Tracking وارد خواهد کرد. نتایج یک، چهار و هشت Connection باید جداگانه ثبت و مقایسه شوند.

تست UDP چه چیزی را نشان می‌دهد؟

UDP بدون دریافت ACK و بدون کنترل ازدحام ترافیک را با نرخ تعیین‌شده ارسال می‌کند. در نتیجه می‌توان بررسی کرد لینک در چه نرخی شروع به ازدست‌دادن بسته‌ها می‌کند.

تست UDP برای سناریوهای زیر کاربرد دارد:

  • تعیین سقف تقریبی ظرفیت لینک
  • بررسی Packet Loss
  • تست VoIP و ترافیک Real-Time
  • ارزیابی لینک وایرلس
  • بررسی Queue و Policer
  • تست تونل‌ها و مسیرهای WAN

در UDP باید نرخ ارسال مشخص شود. اگر نرخ نامحدود انتخاب شود، تست ممکن است لینک را کاملاً اشباع کرده و Packet Loss زیادی ایجاد کند.

نمونه تست UDP با نرخ محدود

برای ارسال 100Mbps از Client به Server:

/tool bandwidth-test \
 address=10.10.10.2 \
 protocol=udp \
 direction=transmit \
 local-tx-speed=100M \
 local-udp-tx-size=1400 \
 duration=30s \
 user=btest-user \
 password="YOUR-PASSWORD"

برای دریافت 100Mbps از Server:

/tool bandwidth-test \
 address=10.10.10.2 \
 protocol=udp \
 direction=receive \
 remote-tx-speed=100M \
 remote-udp-tx-size=1400 \
 duration=30s \
 user=btest-user \
 password="YOUR-PASSWORD"

برای تست 100Mbps هم‌زمان در هر جهت:

/tool bandwidth-test \
 address=10.10.10.2 \
 protocol=udp \
 direction=both \
 local-tx-speed=100M \
 remote-tx-speed=100M \
 local-udp-tx-size=1400 \
 remote-udp-tx-size=1400 \
 duration=30s \
 user=btest-user \
 password="YOUR-PASSWORD"

چگونه سقف ظرفیت لینک را با UDP پیدا کنیم؟

به‌جای شروع تست با نرخ بسیار بالا، نرخ را به‌صورت مرحله‌ای افزایش دهید:

  1. تست را با حدود ۵۰ درصد ظرفیت مورد انتظار آغاز کنید.
  2. Packet Loss و CPU را بررسی کنید.
  3. نرخ را ۱۰ تا ۲۰ درصد افزایش دهید.
  4. تست را دوباره اجرا کنید.
  5. این کار را تا شروع Packet Loss یا افزایش شدید Latency ادامه دهید.
  6. آخرین نرخ پایدار را ثبت کنید.

برای مثال، در یک لینک مورد انتظار 200Mbps می‌توان نرخ‌های زیر را آزمایش کرد:

100M
140M
170M
190M
210M

ظرفیت عملی مناسب معمولاً باید مقداری پایین‌تر از نقطه اشباع در نظر گرفته شود تا لینک برای Burst، Retransmission و تغییر شرایط محیطی حاشیه کافی داشته باشد.

انتخاب اندازه بسته UDP

اندازه بسته روی نتیجه تست تأثیر زیادی دارد. بسته‌های کوچک تعداد Packet Per Second بیشتری ایجاد می‌کنند و فشار بیشتری به CPU، Firewall و Queue وارد می‌کنند.

بسته‌های بزرگ برای سنجش حداکثر Throughput مناسب‌تر هستند، اما نباید از MTU مسیر بیشتر باشند؛ در غیر این صورت Fragmentation یا Drop رخ می‌دهد.

اندازه بستهکاربرد تقریبی
64 تا 128 بایتتست فشار Packet Per Second و بسته‌های کوچک
512 بایتترافیک متوسط و سناریوهای ترکیبی
1200 تا 1400 بایتتست عمومی بدون نزدیک‌شدن زیاد به محدودیت MTU
نزدیک MTU مسیربررسی حداکثر Throughput

در Ethernet معمولی MTU اغلب 1500 است، اما در PPPoE، VPN و تونل‌های مختلف ممکن است MTU مؤثر کمتر باشد. اندازه بسته باید براساس کوچک‌ترین MTU موجود در مسیر انتخاب شود.

بررسی MTU مسیر قبل از تست

برای بررسی MTU می‌توان Ping با گزینه Do Not Fragment اجرا کرد و اندازه را به‌تدریج تغییر داد:

/ping 10.10.10.2 \
 size=1472 \
 do-not-fragment

عدد 1472 برای ICMP روی مسیر IPv4 با MTU برابر با 1500 نمونه رایجی است؛ زیرا Headerهای IP و ICMP نیز فضا اشغال می‌کنند. این عدد نباید مستقیماً به‌عنوان اندازه UDP در تمام مسیرها استفاده شود.

پارامتر Random Data چیست؟

برخی لینک‌ها یا تونل‌ها ممکن است از فشرده‌سازی داده استفاده کنند. اگر Payload تست دارای الگوی ساده و قابل فشرده‌سازی باشد، نتیجه بالاتر از ظرفیت انتقال داده واقعی نمایش داده می‌شود.

با فعال‌کردن Random Data، Payload غیرقابل فشرده‌سازی تولید می‌شود:

random-data=yes

تولید داده تصادفی مصرف CPU را افزایش می‌دهد. روی دستگاه‌های ضعیف بهتر است نتیجه با Random Data روشن و خاموش مقایسه شود و مصرف CPU هم‌زمان بررسی گردد.

نمونه تست TCP دریافت

/tool bandwidth-test \
 address=10.10.10.2 \
 protocol=tcp \
 direction=receive \
 connection-count=4 \
 duration=30s \
 user=btest-user \
 password="YOUR-PASSWORD"

نمونه تست TCP ارسال

/tool bandwidth-test \
 address=10.10.10.2 \
 protocol=tcp \
 direction=transmit \
 connection-count=4 \
 duration=30s \
 user=btest-user \
 password="YOUR-PASSWORD"

نمونه تست TCP دوطرفه

/tool bandwidth-test \
 address=10.10.10.2 \
 protocol=tcp \
 direction=both \
 connection-count=4 \
 duration=30s \
 user=btest-user \
 password="YOUR-PASSWORD"

معنی نتایج Bandwidth Test

پارامتر خروجیتوضیح
statusوضعیت اتصال و اجرای تست
durationمدت سپری‌شده یا کل تست
tx-currentنرخ لحظه‌ای ارسال از Client
rx-currentنرخ لحظه‌ای دریافت در Client
tx-10-second-averageمیانگین ارسال در ده ثانیه اخیر
rx-10-second-averageمیانگین دریافت در ده ثانیه اخیر
tx-total-averageمیانگین کل ارسال
rx-total-averageمیانگین کل دریافت
lost-packetsتعداد بسته‌های ازدست‌رفته در UDP
tx-size و rx-sizeاندازه بسته‌های تست UDP

کدام عدد برای گزارش نهایی مناسب‌تر است؟

Tx Current و Rx Current ممکن است به‌صورت لحظه‌ای نوسان داشته باشند. برای گزارش بهتر است موارد زیر ثبت شوند:

  • Total Average
  • 10 Second Average پس از پایدارشدن تست
  • Packet Loss در UDP
  • حداقل و حداکثر CPU دو دستگاه
  • Latency قبل، حین و بعد از تست
  • تنظیمات Protocol، Direction و Packet Size

نتیجه یک تست چندثانیه‌ای برای تصمیم‌گیری نهایی کافی نیست. تست را حداقل چند بار تکرار و شرایط هر مرحله را ثبت کنید.

کنترل مصرف CPU هنگام تست

هم‌زمان با Bandwidth Test، مصرف CPU هر دو دستگاه را بررسی کنید:

/system resource monitor

برای مشاهده جزئیات پردازش‌ها:

/tool profile cpu=all

اگر CPU یکی از دستگاه‌ها به ۱۰۰ درصد برسد، نتیجه ممکن است محدودیت تولید یا دریافت ترافیک همان دستگاه باشد و نه ظرفیت واقعی لینک.

نشانه‌های CPU Bottleneck عبارت‌اند از:

  • CPU نزدیک ۱۰۰ درصد
  • ثابت‌ماندن Throughput با وجود افزایش نرخ UDP
  • کاهش سرعت در تست Both
  • افزایش Latency در خود روتر
  • افزایش مصرف Process مربوط به BTest یا Networking

بررسی ترافیک Interface هنگام تست

برای مشاهده نرخ واقعی روی Interface:

/interface monitor-traffic ether1

همچنین می‌توان از Torch استفاده کرد:

/tool torch interface=ether1

مقایسه خروجی Bandwidth Test با نرخ Interface کمک می‌کند سربار، ترافیک جانبی یا عبور تست از Interface اشتباه شناسایی شود.

تست لینک وایرلس با Bandwidth Test

برای تست یک لینک Point-to-Point وایرلس بهتر است مراحل زیر انجام شوند:

  1. ابتدا Signal Strength و نرخ TX/RX بررسی شود.
  2. هر دو Chain از نظر قدرت سیگنال مقایسه شوند.
  3. Noise Floor و CCQ بررسی شوند.
  4. تست TCP یک‌طرفه در هر دو جهت اجرا شود.
  5. تست UDP با نرخ محدود انجام شود.
  6. Packet Loss در نرخ‌های مختلف ثبت شود.
  7. در پایان تست Both اجرا شود.

در لینک وایرلس، تست Both ممکن است ظرفیت Airtime را میان ارسال و دریافت تقسیم کند. مخصوصاً در ارتباط‌های Half-Duplex، مجموع دو جهت لزوماً برابر با دو برابر ظرفیت یک‌طرفه نیست.

تحلیل اختلاف زیاد سرعت در لینک وایرلس

اگر برای مثال دریافت حدود 90Mbps و ارسال فقط 20Mbps باشد، موارد زیر را بررسی کنید:

  • Signal Strength هر Chain در هر دو سمت
  • TX Power و Regulatory Domain
  • Alignment آنتن‌ها
  • Noise Floor در هر سمت
  • نرخ TX/RX مذاکره‌شده
  • تداخل فرکانسی نامتقارن
  • پورت Ethernet و Auto Negotiation
  • مصرف CPU رادیوی ارسال‌کننده
  • Queue یا Simple Queue
  • نوع Protocol وایرلس مانند 802.11 یا Nv2

مشاهده سرعت مناسب در یک جهت، سلامت کامل لینک را ثابت نمی‌کند. کیفیت هر دو جهت باید جداگانه بررسی شود.

تست ظرفیت تونل VPN

Bandwidth Test می‌تواند برای مقایسه ظرفیت تونل‌های WireGuard، IPsec، GRE، EoIP یا سایر Tunnelها استفاده شود.

در این سناریوها معمولاً عوامل زیر محدودکننده هستند:

  • توان رمزنگاری CPU
  • MTU و Fragmentation
  • Latency مسیر اینترنت
  • Packet Loss
  • نوع الگوریتم رمزنگاری
  • تعداد Connectionهای TCP
  • Fast Path یا Hardware Acceleration

تست باید یک بار با آدرس‌های خارج از Tunnel و یک بار از داخل Tunnel اجرا شود. اختلاف دو نتیجه، سربار و محدودیت تقریبی Tunnel را نشان می‌دهد.

Bandwidth Test با Speed Test چه تفاوتی دارد؟

ابزارکاربرد
Bandwidth Testکنترل دقیق TCP، UDP، Direction، Rate و Packet Size
Speed Testاجرای مجموعه تست Ping، Jitter، TCP و UDP به‌صورت ساده‌تر
Pingبررسی Latency، Packet Loss و دسترسی IP
iperf3تست میان سیستم‌های انتهایی بدون تولید بار روی RouterOS DUT
Traffic Generatorتولید ترافیک پیشرفته و آزمایش سناریوهای تخصصی

ابزار Speed Test برای بررسی سریع مناسب است:

/tool speed-test \
 address=10.10.10.2 \
 user=btest-user \
 password="YOUR-PASSWORD"

Speed Test نیز به Bandwidth Test Server فعال در دستگاه مقصد نیاز دارد و تحت محدودیت CPU دو دستگاه قرار می‌گیرد.

چرا Bandwidth Test نتیجه‌ای کمتر از iperf3 نشان می‌دهد؟

دلایل احتمالی عبارت‌اند از:

  • تولید ترافیک روی CPU روتر انجام می‌شود.
  • iperf3 روی سیستم قوی‌تری اجرا شده است.
  • تعداد TCP Streamها متفاوت است.
  • اندازه Buffer و Window متفاوت است.
  • Hardware Offloading در ترافیک عبوری فعال است.
  • ترافیک Bandwidth Test در خود روتر Terminate می‌شود.
  • Random Data یا Packet Size متفاوت است.

برای سنجش توان Forwarding، نتیجه تست End-to-End از طریق روتر معمولاً معتبرتر از تستی است که روی خود روتر خاتمه می‌یابد.

روش استاندارد اجرای تست و ثبت نتیجه

برای مقایسه معتبر، یک روش ثابت اجرا کنید:

  1. تنظیمات و نسخه RouterOS هر دو دستگاه ثبت شود.
  2. مصرف CPU قبل از تست بررسی شود.
  3. Ping پایه برای حداقل ۳۰ ثانیه اجرا شود.
  4. TCP Receive برای ۳۰ تا ۶۰ ثانیه اجرا شود.
  5. TCP Transmit برای همان مدت اجرا شود.
  6. تست UDP با چند نرخ کنترل‌شده اجرا شود.
  7. در پایان تست Both انجام شود.
  8. CPU و Packet Loss ثبت شوند.
  9. هر تست حداقل سه بار تکرار شود.
  10. میانگین نتایج برای گزارش نهایی استفاده شود.

خطای Connection Refused

این خطا معمولاً نشان می‌دهد Bandwidth Test Server روی مقصد فعال نیست یا پورت مربوط مسدود شده است.

موارد زیر را بررسی کنید:

/tool bandwidth-server print
/system/device-mode/print
/ip firewall filter print
/ip service print where dynamic

در فهرست سرویس‌های Dynamic معمولاً سرویس BTest روی TCP پورت 2000 قابل مشاهده است.

خطای Timeout

دلایل رایج Timeout عبارت‌اند از:

  • نبود Route به مقصد
  • مسدودبودن TCP پورت 2000
  • مسدودبودن UDP در تست UDP
  • اشتباه‌بودن آدرس مقصد
  • انتخاب VRF یا Routing Table نامناسب
  • قطع لینک فیزیکی یا وایرلس

ابتدا Ping و Traceroute اجرا کنید:

/ping 10.10.10.2
/tool traceroute 10.10.10.2

خطای Authentication Failed

در این حالت موارد زیر را بررسی کنید:

  • نام کاربری و رمز عبور صحیح باشند.
  • کاربر روی دستگاه مقصد وجود داشته باشد.
  • کاربر از IP دستگاه Client اجازه ورود داشته باشد.
  • Group کاربر دارای Policy مناسب باشد.
  • Caps Lock یا کاراکترهای خاص رمز بررسی شوند.
  • Authenticate روی Server مطابق تنظیمات باشد.

Policy مربوط به WinBox برای احراز هویت Bandwidth Test و Policy مربوط به Test برای اجرای ابزار اهمیت دارند.

چرا سرعت روی 95Mbps متوقف می‌شود؟

اگر نتیجه نزدیک 90 تا 95Mbps باقی می‌ماند، احتمالاً یکی از اجزای مسیر Fast Ethernet است.

موارد زیر را بررسی کنید:

  • پورت 10/100 روی رادیو یا روتر
  • کابل دارای دو زوج سالم به‌جای چهار زوج
  • سوئیچ Fast Ethernet
  • Auto Negotiation روی 100Mbps
  • PoE Injector قدیمی با پشتیبانی فقط از 100Mbps

وضعیت پورت را بررسی کنید:

/interface ethernet monitor ether1 once

چرا UDP Packet Loss زیادی دارد؟

Packet Loss بالا در UDP می‌تواند به این دلایل ایجاد شود:

  • نرخ ارسال بالاتر از ظرفیت لینک است.
  • Queue یا Policer بسته‌ها را حذف می‌کند.
  • CPU دستگاه به سقف رسیده است.
  • اندازه بسته باعث Fragmentation شده است.
  • بافر Interface پر شده است.
  • لینک وایرلس نویز یا Retransmission زیادی دارد.
  • پورت Ethernet دارای Error است.

نرخ ارسال را کاهش داده و تست را دوباره اجرا کنید. اگر Loss با کاهش نرخ از بین برود، لینک در تست قبلی اشباع شده است.

چرا تست Both بسیار کمتر از تست یک‌طرفه است؟

در تست Both، دو جهت هم‌زمان CPU، Queue و ظرفیت مسیر را مصرف می‌کنند. در لینک‌های وایرلس Half-Duplex، هر دو جهت از Airtime مشترک استفاده می‌کنند.

تست Both برای بررسی عملکرد هم‌زمان مفید است، اما نباید انتظار داشت هر جهت همان نتیجه تست یک‌طرفه را حفظ کند.

نکات امنیتی Bandwidth Test

  • Bandwidth Server را روی اینترنت منتشر نکنید.
  • Authenticate را فعال نگه دارید.
  • از حساب admin برای تست‌های روزمره استفاده نکنید.
  • یک کاربر محدود و اختصاصی ایجاد کنید.
  • دسترسی کاربر را به IP مشخص محدود کنید.
  • پورت TCP 2000 را فقط از شبکه مدیریت مجاز کنید.
  • Max Sessions را محدود کنید.
  • پس از پایان تست، Server را غیرفعال کنید.
  • از اجرای تست بدون محدودیت در شبکه عملیاتی خودداری کنید.
  • برای تست از راه دور از VPN استفاده کنید.

پس از پایان تست، سرور را غیرفعال کنید:

/tool bandwidth-server set enabled=no

اشتباهات رایج هنگام استفاده از Bandwidth Test

تست‌کردن توان روتر از خود همان روتر

در این حالت CPU تولید ترافیک می‌تواند نتیجه Forwarding را محدود کند.

اجرای UDP بدون تعیین نرخ

این کار ممکن است تمام لینک را اشباع و سرویس کاربران را مختل کند.

اعتماد به یک تست کوتاه

نتیجه چندثانیه‌ای ممکن است تحت تأثیر Burst و نوسان لحظه‌ای باشد.

نادیده‌گرفتن CPU

Throughput پایین همراه با CPU صددرصد الزاماً به معنای مشکل لینک نیست.

مقایسه TCP و UDP بدون ثبت تنظیمات

دو تست با Protocol، Packet Size یا Connection Count متفاوت قابل مقایسه مستقیم نیستند.

استفاده از Both به‌عنوان تنها تست

برای تشخیص عدم تقارن باید هر جهت جداگانه نیز آزمایش شود.

بازگذاشتن BTest Server

سرور غیرضروری می‌تواند سطح حمله و احتمال سوءاستفاده از منابع را افزایش دهد.

اعلام سلامت لینک فقط براساس Zero Packet Loss

در TCP، بسته‌های ازدست‌رفته می‌توانند مجدداً ارسال شوند و به شکل کاهش سرعت دیده شوند. برای بررسی Loss باید تست UDP و Ping نیز اجرا شوند.

چک‌لیست تست حرفه‌ای پهنای باند

  1. هدف تست را مشخص کنید: لینک، روتر، VPN یا اینترنت.
  2. توپولوژی مناسب تست را انتخاب کنید.
  3. مسیر IP و Firewall را بررسی کنید.
  4. Device Mode را کنترل کنید.
  5. کاربر محدود برای BTest بسازید.
  6. سرور مقصد را با Authentication فعال کنید.
  7. ابتدا Ping پایه بگیرید.
  8. تست TCP را در هر جهت جداگانه اجرا کنید.
  9. تست UDP را با نرخ محدود آغاز کنید.
  10. Packet Size را با MTU مسیر هماهنگ کنید.
  11. CPU دو دستگاه را مانیتور کنید.
  12. Interface Errors و Link Rate را بررسی کنید.
  13. تست را چند بار تکرار کنید.
  14. نتایج و تنظیمات را مستند کنید.
  15. پس از پایان، BTest Server را غیرفعال کنید.

سؤالات متداول درباره Bandwidth Test میکروتیک

Bandwidth Test در میکروتیک چیست؟

ابزاری در RouterOS برای تولید ترافیک TCP یا UDP و اندازه‌گیری Throughput میان دو دستگاه میکروتیک است.

Bandwidth Test در WinBox کجاست؟

برای اجرای تست از مسیر Tools > Bandwidth Test و برای تنظیم مقصد از مسیر Tools > BTest Server استفاده کنید.

چرا Bandwidth Test به دستگاه مقصد متصل نمی‌شود؟

معمولاً BTest Server غیرفعال است، Device Mode اجازه اجرا نمی‌دهد، Firewall پورت 2000 را مسدود کرده یا اطلاعات ورود اشتباه است.

برای تست از TCP استفاده کنیم یا UDP؟

TCP برای بررسی عملکرد انتقال‌های مطمئن مناسب است. UDP برای تعیین ظرفیت، بررسی Packet Loss و آزمایش نرخ مشخص کاربرد بیشتری دارد. بهتر است هر دو تست انجام شوند.

کدام تست سرعت واقعی‌تری نشان می‌دهد؟

پاسخ به هدف تست بستگی دارد. UDP برای تخمین سقف ظرفیت لینک مناسب‌تر است و TCP رفتار برنامه‌های مبتنی بر TCP را بهتر شبیه‌سازی می‌کند.

چرا TCP کمتر از UDP نتیجه می‌دهد؟

TCP تحت تأثیر ACK، Latency، Packet Loss، کنترل ازدحام و تعداد Connectionها قرار دارد و با بروز خطا نرخ خود را کاهش می‌دهد.

آیا Bandwidth Test اینترنت را اندازه می‌گیرد؟

فقط در صورتی که دستگاه مقصد در سمت دیگر مسیر اینترنت قرار داشته باشد. Bandwidth Test معمولاً ظرفیت میان دو نقطه مشخص را اندازه‌گیری می‌کند و جایگزین عمومی Speedtest اینترنت نیست.

آیا Bandwidth Test به CPU فشار وارد می‌کند؟

بله. تولید و دریافت ترافیک منابع پردازنده را مصرف می‌کند و ممکن است نتیجه روی دستگاه‌های ضعیف به CPU محدود شود.

چرا سرعت روی حدود 95Mbps باقی می‌ماند؟

احتمالاً یکی از پورت‌ها، PoE Injectorها یا تجهیزات مسیر فقط از Fast Ethernet پشتیبانی می‌کند.

آیا می‌توان BTest Server را همیشه روشن گذاشت؟

در شبکه عملیاتی توصیه نمی‌شود. بهتر است فقط هنگام تست فعال و پس از پایان غیرفعال شود.

آیا Bandwidth Test از IPv6 پشتیبانی می‌کند؟

بله. می‌توان از آدرس IPv6 و برای Link-Local از آدرس همراه با نام Interface استفاده کرد.

برای لینک چندگیگابیتی چه ابزاری بهتر است؟

برای تست دقیق‌تر، دو سیستم قدرتمند مجهز به iperf3 را در دو سمت لینک قرار دهید تا روتر فقط ترافیک را Forward کند.

Packet Loss قابل قبول چقدر است؟

مقدار قابل قبول به سرویس بستگی دارد، اما در یک لینک داخلی سالم و با نرخی پایین‌تر از ظرفیت طراحی‌شده، انتظار می‌رود Loss بسیار کم یا صفر باشد. تماس صوتی، ویدئو و ترافیک صنعتی نسبت به Loss حساس‌تر هستند.

جمع‌بندی

Bandwidth Test میکروتیک یک ابزار کاربردی برای اندازه‌گیری Throughput، مقایسه جهت ارسال و دریافت و شناسایی محدودیت‌های لینک‌های کابلی، وایرلس و VPN است. این ابزار از TCP و UDP پشتیبانی می‌کند و از طریق WinBox و ترمینال قابل اجرا است.

TCP رفتار انتقال‌های مطمئن را شبیه‌سازی می‌کند، اما نتیجه آن تحت تأثیر Latency، Loss و کنترل ازدحام قرار دارد. UDP امکان تعیین نرخ، اندازه بسته و مشاهده Packet Loss را فراهم می‌کند و برای یافتن ظرفیت تقریبی لینک مناسب‌تر است.

برای دستیابی به نتیجه معتبر باید CPU هر دو دستگاه کنترل شود. اگر همان روتر مورد آزمایش وظیفه تولید یا دریافت ترافیک را نیز بر عهده داشته باشد، نتیجه ممکن است به توان CPU محدود شود. برای تست واقعی Forwarding بهتر است ترافیک از دستگاه عبور کند و در دو Endpoint جداگانه تولید و دریافت شود.

همچنین Bandwidth Test می‌تواند تمام ظرفیت شبکه را مصرف کند. در شبکه عملیاتی باید نرخ، مدت و زمان تست محدود شوند. فعال‌بودن Authentication، محدودسازی Firewall و غیرفعال‌کردن BTest Server پس از پایان آزمایش نیز از نکات مهم امنیتی هستند.

در نهایت، هیچ عددی به‌تنهایی وضعیت کامل شبکه را نشان نمی‌دهد. Throughput باید همراه با CPU، Packet Loss، Latency، Jitter، MTU، Interface Errors و در لینک‌های وایرلس همراه با Signal و Noise تحلیل شود.