آموزش میکروتیک MTCNA؛ شب ۱۹: FastTrack و اثر آن بر مشاهده و QoS
فهرست نوشته
FastTrack می‌تواند مسیر پردازش بعضی اتصال‌ها را کوتاه کند؛ اما همین ویژگی ممکن است اندازه‌گیری و Queue را دور بزند. امشب سرعت را همراه با صحت سیاست می‌سنجیم.
این نوشته بخشی از دورهٔ MTCNA در ۳۰ شب است. مبنای مثال‌ها RouterOS 7 و آزمایشگاه ایزولهٔ دوره است؛ پیش از تغییر، Snapshot و دسترسی Console داشته باشید.
پیش‌نیاز آزمایش#
R1 سیاست شب هفدهم را دارد. بین کلاینت A و میزبان تست در سمت WAN مجازی یک انتقال پایدار برقرار کنید. Load را روی دو Endpoint تولید کنید؛ Bandwidth Test روی خود روتر می‌تواند CPU دستگاه را مصرف کند و نتیجهٔ FastTrack را گمراه کند.
/ip firewall filter print stats
/ip firewall connection print detail
/tool profile
قبل از فعال‌سازی، Throughput، بار CPU و Counterهای سیاست را ثبت کنید. نوع ترافیک، مدت تست و نسخه ثابت باشد. این تمرین برای IPv4 آزمایشگاه است؛ نتیجه را بدون بررسی مستندات نسخه به سایر خانواده‌ها و Offload سخت‌افزاری تعمیم ندهید.
فعال کردن در Chain صحیح#
در Chain سفارشی mtcna-forward، Rule FastTrack را قبل از Accept اتصال‌های established قرار دهید:
/ip firewall filter add chain=mtcna-forward action=fasttrack-connection connection-state=established,related place-before=[find comment="MTCNA policy established"] comment="MTCNA fasttrack"
Rule Accept بعدی باید باقی بماند، چون همهٔ بسته‌های یک اتصال لزوماً FastTrack نمی‌شوند. اولین بستهٔ اتصال جدید همچنان باید از سیاست اجازهٔ ما عبور کند. FastTrack را جای مجوز LAN به WAN نگذارید.
آزمایشگاه مقایسه#
دو انتقال تازهٔ مشابه اجرا کنید: یک‌بار Rule Disable و یک‌بار Enable. اتصال‌های قبلاً FastTrackشده ممکن است تا پایان وضعیتشان ادامه دهند؛ برای مقایسه، جریان‌های تازه بسازید یا فقط رکوردهای دقیقِ تست را پس از پایان پاک کنید. قطع کلی Connection tracking معیار سنجش بی‌خطر نیست.
یک Simple Queue از نوع جلسهٔ بیستم بسازید یا همان تمرین را بعداً تکرار کنید. وقتی ترافیک مربوط FastTrack شود، انتظار نداشته باشید Simple Queue همان جریان را درست شکل دهد. Counter کم به معنی کم بودن کل ترافیک نیست.
در سناریوهای دارای Mangle، Routing mark، IPsec یا Queue، باید ترافیک نیازمند پردازش کامل را از FastTrack مستثنا کنید. تشخیص استثنا به طرح واقعی وابسته است؛ «همهٔ establishedها را FastTrack کن» نسخهٔ عمومی برای هر شبکه نیست.
ابزار مشاهده هم بر نتیجه اثر دارد#
Torch یا Sniffer ممکن است مسیر سریع را تحت تأثیر قرار دهد. هنگام مقایسه، وضعیت ابزارها را ثبت کنید؛ بهتر است اندازه‌گیری Endpoint و CPU را با ابزارهای ثابت انجام دهید. CHR و RouterBOARD نیز محدودیت‌های متفاوت CPU و Offload دارند.
بازگشت و خودآزمایی#
/ip firewall filter disable [find comment="MTCNA fasttrack"]
برای بخش QoS، این Rule Disable بماند و جریان تازه استفاده شود. خروجی قابل قبول، جدول نرخ، CPU، Counter و وضعیت FastTrack است. چرا Rule Accept بعد از FastTrack لازم است؟ چرا Queue بی‌اثر ممکن است سالم باشد؟ چگونه یک اتصال تازه را از اتصال باقی‌ماندهٔ قبل تشخیص می‌دهید؟