اگر Simple Queue در MikroTik ساخته‌اید اما سرعت کاربر محدود نمی‌شود، یکی از اولین مواردی که باید بررسی کنید FastTrack است. در RouterOS، ترافیک FastTrackشده از Simple Queue عبور نمی‌کند؛ بنابراین ممکن است Queue کاملاً درست ساخته شده باشد اما Counter آن بالا نرود و کاربر همچنان سرعت کامل بگیرد.
در این راهنما مشکل را مرحله‌به‌مرحله تشخیص می‌دهیم، با یک تست کنترل‌شده FastTrack را تأیید یا رد می‌کنیم و در پایان به‌جای خاموش‌کردن کامل FastTrack، فقط ترافیکی را که باید Queue شود از FastTrack مستثنا می‌کنیم.
چرا Simple Queue با FastTrack کار نمی‌کند؟
FastTrack برای کاهش پردازش CPU، بخشی از مسیر عادی پردازش بسته‌ها را دور می‌زند. طبق مستندات رسمی MikroTik، ترافیک FastTrackشده از Simple Queue و همچنین Queue Tree با parent=global عبور نمی‌کند. نتیجه این است که Queue وجود دارد، اما بسته‌های FastTrackشده را نمی‌بیند.
نشانه رایج این مشکل این است که برای یک IP مثلاً 192.168.88.50 محدودیت 20Mbps تعریف کرده‌اید، اما Speedtest همچنان سرعت کامل لینک را نشان می‌دهد و Counter مربوط به Queue تقریباً ثابت می‌ماند.
تشخیص سریع مشکل FastTrack و Simple Queue
قبل از تغییر تنظیمات، این سه دستور را اجرا کنید:
/ip firewall filter print stats where action=fasttrack-connection
/queue simple print stats
/ip firewall connection print where fasttrack=yesاگر Counter قانون FastTrack افزایش پیدا می‌کند، Connection مربوط به کاربر FastTrack شده و در همان زمان Counter مربوط به Simple Queue بالا نمی‌رود، احتمال زیادی وجود دارد که FastTrack علت کار نکردن محدودیت سرعت باشد. برای اثبات آن باید یک تست کنترل‌شده انجام دهید.
سناریوی نمونه: Queue ساخته شده اما سرعت محدود نمی‌شود
فرض کنید برای کلاینت 192.168.88.50 این Queue را ساخته‌ایم:
/queue simple add name="client-20m" target=192.168.88.50/32 max-limit=20M/20Mاگر کاربر هنوز سرعت بیشتر از 20Mbps دارد، فوراً max-limit را تغییر ندهید. ابتدا بررسی کنید آیا ترافیک واقعاً به Queue می‌رسد یا قبل از آن توسط FastTrack از مسیر عادی خارج می‌شود.
مرحله 1: قبل از تغییر Firewall بکاپ بگیرید
قبل از دست‌کاری Ruleهای Firewall از تنظیمات Export و Backup تهیه کنید:
/export file=before-fasttrack-queue-test
/system backup save name=before-fasttrack-queue-testExport برای مقایسه تنظیمات قبل و بعد از تغییر مناسب است و Backup برای بازیابی سریع‌تر کاربرد دارد. اگر با روش صحیح تهیه و بازیابی فایل‌ها آشنا نیستید، راهنمای بکاپ و بازیابی تنظیمات MikroTik را ببینید.
مرحله 2: Counter قانون FastTrack را بررسی کنید
/ip firewall filter print stats where action=fasttrack-connectionاگر تعداد Packet و Byte این Rule هنگام تست کاربر افزایش پیدا می‌کند، FastTrack فعال است. سپس Connectionهای FastTrackشده را بررسی کنید:
/ip firewall connection print where fasttrack=yesفعال بودن FastTrack به‌تنهایی اثبات نمی‌کند که دقیقاً ترافیک کاربر موردنظر مشکل دارد؛ به همین دلیل باید نتیجه را با Counter خود Queue مقایسه کنیم.
مرحله 3: ببینید Simple Queue واقعاً ترافیک دریافت می‌کند یا نه
/queue simple print statsQueue مربوط به IP موردنظر را پیدا کنید و هم‌زمان روی همان کلاینت دانلود یا Speedtest اجرا کنید. اگر کاربر ترافیک دارد اما Packet/Byte Counter آن Queue تقریباً ثابت است، ترافیک به Queue نمی‌رسد یا Target/مسیر انتخاب‌شده اشتباه است.
برای شبکه‌هایی که چند Rule و چند Queue دارند، بررسی Counterها از حدس‌زدن بسیار مطمئن‌تر است. برای دید بهتر روی مصرف منابع و ترافیک روتر نیز می‌توانید از راهنمای مانیتورینگ در MikroTik استفاده کنید.
مرحله 4: FastTrack را فقط برای تست موقت غیرفعال کنید
ابتدا شماره Rule را پیدا کنید:
/ip firewall filter print where action=fasttrack-connectionاگر مثلاً Rule شماره 5 است، فقط در بازه تست آن را Disable کنید:
/ip firewall filter disable 5نکته مهم: غیرفعال‌کردن FastTrack می‌تواند مصرف CPU را افزایش و Throughput روتر را کاهش دهد. این کار را روی روتر Production فقط برای یک تست کوتاه و کنترل‌شده انجام دهید.
Connection قبلی کاربر ممکن است نتیجه تست را مخدوش کند. ساده‌ترین روش این است که Session تست را ببندید و Connection جدید بسازید. اگر لازم شد Connectionهای همان IP آزمایشی را حذف کنید؛ کل Connection Table را روی روتر Production پاک نکنید.
/ip firewall connection remove [find where src-address~"192.168.88.50"]حالا دوباره Speedtest یا دانلود کنترل‌شده اجرا کنید و هم‌زمان این موارد را ببینید:
/queue simple print stats
/tool profileاگر با Disable شدن FastTrack، Counter صف شروع به افزایش کرد و سرعت نزدیک 20Mbps محدود شد، علت اصلی مشخص شده است.
راه‌حل اصولی: ترافیک Queue را از FastTrack مستثنا کنید
خاموش‌کردن دائمی FastTrack برای کل شبکه معمولاً انتخاب خوبی نیست. بهتر است فقط کلاینت‌ها یا شبکه‌هایی که باید توسط Simple Queue پردازش شوند از FastTrack خارج شوند و سایر ترافیک همچنان از مزیت FastTrack استفاده کند.
برای مدیریت ساده‌تر می‌توانید IPهای Queueشده را در Address List قرار دهید:
/ip firewall address-list add list=no-fasttrack address=192.168.88.50 comment="Queued client"سپس Rule موجود FastTrack را طوری تنظیم کنید که Connectionهایی با مبدا یا مقصد این Address List را FastTrack نکند. قبل از هر تغییر، Rule فعلی را با جزئیات ببینید:
/ip firewall filter print detail where action=fasttrack-connectionمنطق Rule باید معادل این باشد که فقط Connectionهای established,related که مبدا و مقصدشان عضو no-fasttrack نیست FastTrack شوند:
chain=forward action=fasttrack-connection connection-state=established,related src-address-list=!no-fasttrack dst-address-list=!no-fasttrackاین خط یک الگو است، نه دستور آماده برای جایگزینی کورکورانه Rule فعلی. Interface List، HW offload، IPsec policy و شرط‌های دیگر Firewall فعلی خودتان را حفظ کنید. ابتدا Rule موجود را بررسی کنید و فقط شرط‌های Exclusion لازم را به همان ساختار اضافه کنید.
چرا Rule accept بعد از fasttrack-connection مهم است؟
همه بسته‌های یک Connection الزاماً از Fast Path عبور نمی‌کنند. به همین دلیل در تنظیمات معمول RouterOS بعد از Rule با action=fasttrack-connection یک Rule با action=accept برای Connectionهای established,related دیده می‌شود. آن را صرفاً برای حل مشکل Queue حذف نکنید؛ تغییر بی‌برنامه ترتیب Firewall می‌تواند ارتباط کاربران را مختل کند.
اگر Queue Tree استفاده می‌کنید چه؟
این مسئله فقط مخصوص Simple Queue نیست. MikroTik مشخصاً Queue Tree با parent=global را نیز جزو مسیرهایی می‌داند که ترافیک FastTrackشده از آن عبور نمی‌کند. بنابراین هنگام عیب‌یابی Queue Tree، محل Queue در Packet Flow و نوع Parent را هم بررسی کنید.
بعد از اصلاح، نتیجه را Verify کنید
بعد از اضافه‌کردن Exclusion یک Connection جدید از کلاینت آزمایشی بسازید و فقط به نتیجه Speedtest اکتفا نکنید. این چهار بررسی را هم‌زمان انجام دهید:
/queue simple print stats
/ip firewall filter print stats where action=fasttrack-connection
/ip firewall connection print where fasttrack=yes
/tool profile- Counter مربوط به Simple Queue باید هنگام ترافیک کاربر افزایش پیدا کند.
- سرعت کلاینت باید به Limit تعریف‌شده نزدیک شود.
- ترافیک سایر کاربران که Queue نمی‌شوند باید همچنان بتواند FastTrack شود.
- CPU روتر بعد از تغییر باید در محدوده قابل‌قبول باقی بماند.
اگر هدف شما محدودسازی کاربران شبکه بی‌سیم است، راهنمای محدود کردن کاربران وای‌فای در MikroTik نیز می‌تواند برای سناریوی شما مفید باشد.
اگر MikroTik CHR روی سرور مجازی دارید
در CHR نیز منطق FastTrack و Queue اهمیت دارد، اما توان CPU و ظرفیت شبکه ماشین مجازی روی نتیجه تست اثر مستقیم می‌گذارد. اگر RouterOS را به‌صورت CHR اجرا می‌کنید، قبل از نتیجه‌گیری درباره Queue مطمئن شوید محدودیت از منابع Hypervisor یا پورت شبکه نیست. برای سناریوهایی که به یک روتر مجازی با IP عمومی نیاز دارند، می‌توانید مشخصات سرور مجازی وان‌سرور را هم بررسی کنید.
خطاهای رایج هنگام رفع مشکل Simple Queue
- خاموش‌کردن دائمی FastTrack: ممکن است Queue را فعال کند اما CPU و Throughput را بی‌دلیل بدتر کند.
- تست با Connection قدیمی: بعد از تغییر Ruleها Session جدید ایجاد کنید.
- پاک‌کردن کل Connection Table: روی Production باعث قطع Sessionهای فعال کاربران می‌شود.
- تغییر مداوم max-limit: وقتی Counter Queue بالا نمی‌رود، تغییر Limit مشکل مسیر ترافیک را حل نمی‌کند.
- نادیده گرفتن ترتیب Ruleها: شرط Exclusion باید در همان منطق FastTrack مؤثر باشد.
- کپی‌کردن Rule آماده بدون بررسی Firewall: ساختار Interface، NAT، IPsec و Policy هر شبکه متفاوت است.
Rollback: اگر بعد از تغییر شبکه دچار مشکل شد
اگر فقط برای تست FastTrack را Disable کرده بودید، Rule قبلی را دوباره فعال کنید:
/ip firewall filter enable 5اگر شرط‌های Exclusion اضافه کرده‌اید و بعد از آن Packet Loss، افزایش شدید CPU یا اختلال Routing دیده می‌شود، تغییرات جدید را به وضعیت Export قبل از تست برگردانید و Counterها را دوباره بررسی کنید. هدف Rollback این است که فقط تغییر مربوط به این تست برگردد، نه اینکه کل تنظیمات روتر بدون بررسی Restore شود.
چک‌لیست نهایی رفع مشکل
- از تنظیمات Export و Backup بگیرید.
- Counter قانون FastTrack را بررسی کنید.
- Connectionهای FastTrackشده را ببینید.
- Counter خود Simple Queue را هنگام ترافیک واقعی بررسی کنید.
- FastTrack را فقط برای تست کوتاه Disable کنید.
- با Connection جدید دوباره سرعت و Counter را تست کنید.
- اگر علت تأیید شد، IP یا شبکه Queueشده را از FastTrack مستثنا کنید.
- Queue Counter، سرعت، FastTrack سایر کاربران و CPU را Verify کنید.
جمع‌بندی
وقتی Simple Queue در MikroTik کار نمی‌کند و FastTrack فعال است، اولین سؤال این نیست که «عدد Queue را چطور تغییر بدهم؟»؛ باید ببینید ترافیک اصلاً به Queue می‌رسد یا نه. افزایش Counter FastTrack در کنار ثابت ماندن Counter Queue، و سپس درست‌شدن محدودیت پس از Disable موقت FastTrack، تشخیص را روشن می‌کند. راه‌حل نهایی نیز معمولاً خاموش‌کردن FastTrack برای همه نیست؛ ترافیک نیازمند Queue را Exclude کنید و بعد نتیجه را با Counter، سرعت و CPU تأیید کنید.