Bandwidth Test در RouterOS توان عبور بین دو روتر میکروتیک را می‌سنجد تا گلوگاه لینک سیمی یا وایرلس پیدا شود. ابزار زیر /tool است: یک طرف bandwidth-server و طرف دیگر bandwidth-test کلاینت. این آموزش صفحهٔ رسمی Bandwidth Test را دنبال می‌کند و نقش سرور/کلاینت و فرق TCP و UDP را روشن می‌کند.
آموزش Bandwidth Test میکروتیک؛ سنجش سرعت بین دو روتر
پیش‌نیازهایی که جا می‌ماند: دو روتر (یا بیشتر) با مسیر IP درست، پکیج system، دسترسی WinBox/SSH، و آگاهی از اینکه تست به‌طور پیش‌فرض پهنای‌باند را پر می‌کند و می‌تواند شبکه را برای بقیه کند کند. نقش‌ها را جدا کنید: Server هدف تست است؛ Client تست را شروع می‌کند؛ اگر می‌خواهید توان واقعی یک روتر میانی را ببینید، طبق مستند بهتر است زنجیرهٔ سه‌روتره بسازید و تست از/به خودِ روتر تحت‌آزمایش نباشد.
- روی روتر سرور وضعیت را ببینید: /tool bandwidth-server print. معمولاً enabled: yes است. برای شروع امن، authenticate: yes را نگه دارید مگر در lab ایزوله.
- در WinBox مسیر تقریبی Tools → Bandwidth Test (و تنظیمات Bandwidth Server) را باز کنید؛ همان فیلدهای CLI را دارید.
- روی کلاینت تست را با آدرس سرور اجرا کنید. مثال مفهومی: /tool bandwidth-test address=192.0.2.1 protocol=udp direction=both — آدرس را با IP واقعی سرور عوض کنید.
- protocol را آگاهانه انتخاب کنید: پیش‌فرض مستند اغلب UDP است. UDP برای تقریب سقف لینک به بسته‌های بزرگ (نزدیک MTU، معمولاً حدود ۱۵۰۰) نزدیک‌تر است؛ TCP فقط دادهٔ TCP را می‌شمارد و به‌خاطر الگوریتم و ACK آمارش برای «سقف خام» به‌اندازهٔ UDP قابل اتکا نیست.
- direction را روی receive، transmit یا both بگذارید تا بفهمید محدودیت یک‌طرفه است یا دوطرفه. duration و interval گزارش را کنترل می‌کنند.
- اگر لینک فشرده‌سازی دارد و نتیجه غیرواقعی است، random-data=yes را در نظر بگیرید؛ مستند می‌گوید CPUخور است و روی CPU ضعیف بهتر است خاموش بماند.
- حین تست، روی سرور با /tool bandwidth-server session print نشست‌های فعال (CLIENT، PROTOCOL، DIRECTION، USER) را ببینید تا مطمئن شوید همان کلاینت وصل است.
- اعداد rx-current / tx و میانگین‌ها را یادداشت کنید، بعد تست را متوقف کنید تا لینک آزاد شود. برای سنجش روتر میانی، الگوی سه‌تایی Server — DUT — Client را از همان صفحه جدی بگیرید.
مستند هشدار می‌دهد Bandwidth Test منابع زیاد مصرف می‌کند و تا نسخه‌های قدیمی‌تر ممکن بود به یک هستهٔ CPU محدود شود. روی لینک زندهٔ کاربران، پنجرهٔ تست کوتاه بگیرید. اگر authenticate روشن است، کلاینت باید با کاربر/رمز معتبر روتر سرور حرف بزند؛ خاموش کردن authenticate فقط برای lab ایزوله معنی دارد.
اگر وضعیت stuck روی connecting است یا عددها نزدیک صفرند، در نظرات نسخهٔ RouterOS دو طرف، protocol/direction و اینکه فایروال بین دو روتر UDP/TCP تست را می‌بندد یا نه بنویسید (بدون رمز).
خطاهای رایج و نکات امنیتی
- connecting می‌ماند → IP غلط، مسیر، یا authenticate بدون credential درست.
- عدد TCP کمتر از انتظار → رفتار عادی نسبت به UDP؛ اول UDP با سایز نزدیک MTU را بسنجید.
- شبکهٔ دفتر قطع شد → تست همهٔ پهنا را می‌گیرد؛ duration کوتاه و خارج از ساعت شلوغ.
- نتیجه فقط از/به همان روتر است → برای throughput واقعی DUT از الگوی سه روتر استفاده کنید.
- bandwidth-server با authenticate=no روی اینترنت یعنی هرکس می‌تواند لینک را بمباران کند؛ فقط lab و LAN کنترل‌شده.
شما Bandwidth Test را بیشتر برای وایرلس نقطه‌به‌نقطه می‌خواهید یا برای لینک سیمی بین دو سایت؟ protocol ترجیحی‌تان UDP است یا TCP؟
برای پیدا کردن گلوگاه وایرلس، UDP با سایز نزدیک MTU و direction=both تصویر بهتری از سقف خام می‌دهد. TCP را وقتی می‌خواهید رفتار واقعی نشست‌های تأییددار را ببینید نگه دارید، نه به‌عنوان تنها معیار «سرعت لینک».
مستند تأکید می‌کند تست منابع زیاد می‌گیرد و ممکن است استفادهٔ شبکه را مختل کند. روی لینک مشتری، پنجرهٔ کوتاه بگیرید و خارج از ساعت اوج کار کنید. authenticate را روی لبه‌های در دسترس اینترنت خاموش نگذارید.
اگر هدف سنجش خودِ روتر میانی است، زنجیرهٔ Server — DUT — Client را جدی بگیرید؛ تست از/به همان DUT بیشتر محدودیت CPU/صف همان جعبه را نشان می‌دهد تا توان عبور واقعی.
مرجع فیلدهای server/client و هشدارهای TCP/UDP همان صفحهٔ Bandwidth Test در مستندات RouterOS است.
