به عنوان یک مدیر شبکه نیاز است تا برای مدیریت و خطایابی ساختار، با ابزارهای مختلفی آشنایی داشته باشید. در دنیای شبکه، ابزارهای متفاوتی برای خطایابی وجود دارند که در میان آن‌ها ping و taceroute از شهرت بیشتری برخوردارند. بااین‌حال ابزار دیگری نیز وجود دارد که شاید همانند این دو ابزار شهرت زیادی نداشته باشد اما فراهم‌کننده‌ی اطلاعاتی به‌مراتب بیشتر و مهم‌تر است. این ابزار قدرتمند، MTR نام دارد.
MTR به مدیر شبکه کمک می‌کند تا خطاها را شناسایی کرده و گزارشی از وضعیت کلی شبکه به دست آورد. در این مطلب سعی شده تا به MTR، داده‌های تولیدی توسط آن و نحوه‌ی تحلیل و تفسیر اطلاعات حاصل از این ابزار، پرداخته شود.
مروری بر عملکرد ابزارهای اصلی خطایابی شبکه
ابزارهای خطایابی شبکه چون ping، traceroute و MTR از Control Message Protocol (ICMP) برای تست ارتباطات و ترافیک تبادلی میان دو نقطه در اینترنت استفاده می‌کنند. هنگام ping یک IP، تعدادی پکت ICMP از مبدأ به سمت مقصد ارسال شده و مقصد نیز در پاسخ تعدادی پکت ICMP برای مبدأ ارسال می‌کند. برحسب پاسخ‌های تبادلی میان این دو نقطه، کاربر قادر خواهد بود تا مقدار round trip time (RTT) مابین این دو نقطه را محاسبه کند.
اما ابزارهایی همانند MTR و traceroute، با کمک فیلد TTL (Time to Live) در هدر پکت IP، تعداد گام‌ها (hop) در مسیر میان مبدأ و مقصد را محاسبه می‌کنند. TTL مشخص‌کننده‌ی تعداد گام‌هایی است که پکت قبل از منقضی شدن می‌تواند از آن‌ها عبور کند. هنگامی‌که از traceroute یا MTR استفاده می‌شود، برای شمارش تعداد hopها، ابتدا چند پیام ICMP با کمترین مقدار برای TTL (مقدار 1) ارسال شده و به‌تدریج مقدار TTL افزایش می‌یابد تا نهایتاً بسته به مقصد موردنظر رسد.
MTR را می‌توان ترکیبی از دو ابزار ping و traceroute معرفی کرد. این ابزار علاوه بر دید کلی از مسیری که ترافیک از مبدأ تا یک مقصد مشخص طی می‌کند، اطلاعات بیشتری در رابطه با وضعیت، ارتباطات و پاسخگویی hopهای قرارگرفته میان مبدأ و مقصد را نیز فراهم می‌آورد.
نحوه نصب MTR
برخلاف ping و traceroute، ابزار MTR به‌صورت پیش‌فرض بر روی اکثر سیستم‌ها نصب نیست. برای نصب این ابزار متناسب با نوع سیستم‌عامل، می‌توان از دستورات زیر استفاده کرد.
- Ubuntu/Debian
sudo apt-get install mtr
- CentOS/RHEL/Fedora
yum install mtr
- Arch
pacman -S mtr
- Windows
برای نصب این ابزار بر روی سیستم‌عامل ویندوز می‌توانید از نرم‌افزار WinMTR upstream استفاده کنید.
- MAC OS
برای نصب این ابزار بر روی سیستم‌عامل MAC OS X می‌توان از Homebrew یا MacPorts استفاده کرد. برای نصب با کمک Homebrew از دستور زیر:
brew install mtr
و برای نصب توسط MacPorts از دستور زیر استفاده کنید:
port install mtr
تولید MTR Report
ازآنجایی‌که MTR فراهم آورنده‌ی دیدی از مسیر پیموده شده توسط پکت از مبدأ تا مقصد است، می‌توان آن را ابزاری جهت‌دار درنظر گرفت. ممکن است مسیرهای رفت و برگشت ترافیک میان دو نقطه یکسان نباشند، به همین دلیل توصیه بر آن است تا در هنگام بررسی مشکلات ارتباطی میان دو نقطه، از MTR در هر دو سمت استفاده شده و اطلاعات حاصل از آن جمع‌آوری شود.
یک روش ساده برای استفاده از ابزار MTR، درج دستور mtr به همراه یک URL یا آدرس IP همانند زیر است:
mtr example.com
مزیت بزرگ MTR در مقایسه با traceroute آن است که، خروجی آن به‌طور مداوم به‌روز شده و از این طریق می‌توان تغییرات در عملکرد شبکه در طول زمان را مشاهده کرد.
یک روش دیگر برای استفاده از MTR، تولید گزارش با استفاده از دستور زیر است:
mtr --report example.com
می‌توان با افزودن گزینه‌ی –n به دستور mtr برای این ابزار مشخص کرد که به‌جای نمایش hostnameهای هر hop، آدرس IP آن‌ها را نشان دهد. برای مثال در دستور زیر از ابزار MTR برای گزارش‌گیری از DNS عمومی گوگل استفاده شده است.
mtr -n --report 8.8.8.8
HOST: example Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.1 0.0% 10 9.4 7.5 3.1 11.7 2.8
2.|-- 10.89.0.1 0.0% 10 13.1 24.4 11.7 69.9 21.7
3.|-- 173.212.126.117 0.0% 10 22.0 20.7 13.0 26.5 4.5
4.|-- 24.215.102.161 0.0% 10 29.2 28.1 23.4 31.9 2.9
5.|-- 24.215.102.221 0.0% 10 22.0 26.1 22.0 30.1 3.1
6.|-- 24.215.102.9 0.0% 10 25.8 27.2 22.2 33.7 3.5
7.|-- 24.215.101.10 0.0% 10 107.8 52.1 41.5 107.8 19.8
8.|-- 209.85.250.3 0.0% 10 68.0 48.6 42.1 68.0 7.3
9.|-- 8.8.8.8 0.0% 10 42.9 47.3 42.8 56.0 4.2
هریک از ستون‌های نشان داده شده در خروجی بالا، بیانگر اطلاعات خاصی در رابطه با پکت‌های ارسالی هستند:
- Host: نشان‌دهنده‌ی hostname یا آدرس IP هر گامی که پکت از آن عبور کرده است.
- Loss: درصد packet loss در هر گام
- Snt: تعداد پکت‌های ارسالی
- Last: تأخیر آخرین پکت ارسالی به میلی‌ثانیه
- Avg: میانگین تأخیر تمام بسته‌ها به میلی‌ثانیه
- Best: کمترین round trip time برای یک پکت به میلی‌ثانیه
- Wrst: بیشترین round trip time برای یک پکت به میلی‌ثانیه
- StDev: انحراف معیار تأخیرها برای هر host
تنظیم تعداد پکت‌های ارسالی
در حالت گزارش‌گیری، MTR به صورت پیش‌فرض 10 پکت ارسال می‌کند. برای کاهش یا افزایش این تعداد می‌توان از گزینه‌ی -cدر دستور mtr استفاده کرد.
تنظیم بازه زمانی ارسال پکت‌ها
MTR هر 1 ثانیه پکت‌ها را ارسال می‌کند که در حالت معمول این بازه زمانی نرمال است. برای شبیه‌سازی تراکم شبکه می‌توان این مقدار پیش‌فرض را با استفاده از گزینه‌ی: -i در دستور mtr تغییر داد و مدت‌زمانی (به ثانیه) در بازه ی 0 تا 1 را برای ارسال ICMP ECHOها مشخص کرد.
یافتن AS numberها در مسیر رسیدن به مقصد
با استفاده از گزینه‌ی -z در دستور mtr می‌توان AS number دستگاه‌هایی که در مسیر رسیدن به مقصد قرار دارند را به دست آورد. این قابلیت هنگام خطایابی BGP و یا هنگام تشخیص آن‌که چه دستگاه‌هایی در AS مشابه قرار دارند، مفید است.
استفاده از TCP/UDP/SCTP به جای ICMP
MTR به صورت پیش‌فرض از پروتکل ICMP برای تعیین دستگاه‌ها در مسیر میان مبدأ و مقصد استفاده می‌کند. اما گاهی، ترافیک ICMP توسط برخی دستگاه‌ها در این مسیر فیلتر شده و این امر سبب می‌شود تا MTR نتواند گزارش دقیقی به دست دهد. بنابراین می‌توان کاری کرد که این رفتار پیش‌فرض MTR تغییر کرده و از پروتکل‌های دیگری همانند: TCP، UDP یا SCTP (Stream Control Transmission Protocol) استفاده کند. همچنین می‌توان یک گام فراتر گذاشته و شماره پورت را نیز مشخص کرد.
مثلن یکی از کاربردهای TCP traceroute می‌تواند تشخیص این باشد که در طی مسیر، بعد از کدام Hop ترافیک به مقصد یک پورت drop می‌شود؛ و یا مثلن بررسی اینکه آیا در طی مسیر ترافیک وب، مثلن HTTP روی پورت 80، آیا Transparent Cache Server وجود دارد؟ یا مثلن برای پیدا کردن اینکه آیا درخاست‌های DNS در طول مسیر دچار DNS Poisoning می‌شوند؟ البته این روش همیشه نتایج کاملن دقیقی ارائه نخاهد کرد اما معمولن درست هست.
برای دست‌یابی به این هدف می‌توان از گزینه‌های: -T (یا -tcp)، -u (یا –udp) یا –S (یا -sctp) برای مشخص کردن نوع پروتکل، و گزینه‌ی: -P برای مشخص کردن شماره پورت، در دستور mtr استفاده کرد.
تجزیه‌وتحلیل خروجی MTR
هدف اصلی استفاده از گزارش‌های MTR، بررسی packet loss و latency (تأخیر) است.
بررسی Packet Loss
Packet loss می‌تواند ناشی از وجود مشکل در یکی از روترها در مسیر رسیدن پکت به مقصد و یا محدودیت نرخ (rate limiting) ترافیک ICMP از سوی service provider باشد که در مورد دوم، این packet loss حاکی از وجود مشکل نیست. برای مثال در تصویر زیر، میان گام‌های 1 و 2، packet loss رخ داده که به دلیل استفاده از rate limiting در گام 2 است.
mtr -n --report 8.8.8.8
HOST: example Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.1 0.0% 10 9.4 7.5 3.1 11.7 2.8
2.|-- 10.89.0.1 0.0% 10 13.1 24.4 11.7 69.9 21.7
3.|-- 173.212.126.117 60.0% 10 22.0 20.7 13.0 26.5 4.5
4.|-- 24.215.102.161 0.0% 10 29.2 28.1 23.4 31.9 2.9
5.|-- 24.215.102.221 0.0% 10 22.0 26.1 22.0 30.1 3.1
6.|-- 24.215.102.9 0.0% 10 25.8 27.2 22.2 33.7 3.5
7.|-- 24.215.101.10 0.0% 10 107.8 52.1 41.5 107.8 19.8
8.|-- 209.85.250.3 0.0% 10 68.0 48.6 42.1 68.0 7.3
9.|-- 8.8.8.8 0.0% 10 42.9 47.3 42.8 56.0 4.2
وقوع packet loss در بیش از یک hop، می‌تواند نشان‌دهنده‌ی مشکلی در مسیریابی یا یک روتر خاص در مسیر رسیدن به مقصد باشد. به یاد داشته باشید که گاهی ممکن است packet loss و rate limit به‌صورت هم‌زمان رخ دهند. هنگام وقوع packet loss در hopهای مختلف، همواره مقدار نشان داده شده برای آخرین hop بیانگر درصد packet loss حقیقی است. برای مثال در خروجی زیر، درصد واقعی packet loss، همان 30 درصد نشان داده شده توسط آخرین گام (گام 9) است و در گام‌های 4 و 5 و 6 از rate limit استفاده شده است.
mtr -n --report 8.8.8.8
HOST: example Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.1 0.0% 10 9.4 7.5 3.1 11.7 2.8
2.|-- 10.89.0.1 0.0% 10 13.1 24.4 11.7 69.9 21.7
3.|-- 173.212.126.117 0.0% 10 22.0 20.7 13.0 26.5 4.5
4.|-- 24.215.102.161 70.0% 10 29.2 28.1 23.4 31.9 2.9
5.|-- 24.215.102.221 70.0% 10 22.0 26.1 22.0 30.1 3.1
6.|-- 24.215.102.9 60.0% 10 25.8 27.2 22.2 33.7 3.5
7.|-- 24.215.101.10 30.0% 10 107.8 52.1 41.5 107.8 19.8
8.|-- 209.85.250.3 30.0% 10 68.0 48.6 42.1 68.0 7.3
9.|-- 8.8.8.8 30.0% 10 42.9 47.3 42.8 56.0 4.2
نکته: به یاد داشته باشید که packet lossای تا مقدار 10% نرمال است اما اگر این درصد افزایش پیدا کند، حاکی از وجود مشکل بوده و نیاز به بررسی‌های بیشتری است و باز هم توصیه می‌گردد تا از MTR در هر دو جهت رفت‌وبرگشت برای دست‌یابی به اطلاعات دقیق‌تر استفاده شود.
اگر از MTR بر روی کامپیوتر شخصی خود استفاده کرده و در گام‌های نخست، packet loss قابل‌ملاحظه‌ای مشاهده کردید، مشکل از ارتباط ISP شما، و درصورتی‌که این مقادیر قابل‌ملاحظه در گام‌های پایانی باشد، مشکل از ISP سمت مقصد است.
بررسی Latency
Latency (تأخیر) پارامتری است که به مسافت میان مبدأ و مقصد و کیفیت خط وابسته بوده و دلایل مختلفی چون: پیکربندی نادرست روترها در مسیر رسیدن به مقصد، اشباع لینک و … بر افزایش مقدار آن تأثیر مستیقم دارند. در هنگام تحلیل خروجی MTR باید پیوسته افزایش ناگهانی مقدار latency را که می‌تواند نشان‌دهنده‌ی مشکلی در روتر آن گام باشد، مدنظر داشت.
برای مثال در خروجی زیر، همه‌چیز تا گام 6 نرمال و طبیعی است اما در این گام ناگهان مقدار latency به طرز قابل‌ملاحظه‌ای افزایش یافته و در گام‌های بعد نیز این مقدار کاهش نیافته است. بر طبق این اطلاعات می‌توان نتیجه گرفت که روتر در گام 6 دارای مشکل است.
mtr -n --report 8.8.8.8
HOST: example Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.1 0.0% 10 9.4 7.5 3.1 11.7 2.8
2.|-- 10.89.0.1 0.0% 10 13.1 24.4 11.7 69.9 21.7
3.|-- 173.212.126.117 0.0% 10 22.0 20.7 13.0 26.5 4.5
4.|-- 24.215.102.161 0.0% 10 29.2 28.1 23.4 31.9 2.9
5.|-- 24.215.102.221 0.0% 10 22.0 26.1 22.0 30.1 3.1
6.|-- 24.215.102.9 0.0% 10 430.4 445.2 426.7 463.6 3.5
7.|-- 24.215.101.10 0.0% 10 432.3 445.2 426.7 463.6 3.8
8.|-- 209.85.250.3 0.0% 10 433.5 445.2 426.7 463.6 7.3
9.|-- 8.8.8.8 0.0% 10 435.9 445.2 426.7 463.6 4.2
اگر افزایش ناگهانی مقدار latency تنها محدود به یک hop باشد و مجدداً این مقدار کاهش یابد، می‌توان این افزایش ناگهانی در آن گام را حاصل استفاده از rate limit دانست. Rate limiting علاوه بر packet loss بر latency نیز تأثیر می‌گذارد و همان‌طور که در بخش قبل برای packet loss ذکر شد، برای سنجش میزان latency نیز باید به داده‌های مربوط به آخرین گام‌ها توجه کرد.
سلام ممنون مهندس جان از اطلاعات تکمیلی در زمینه شبکه. بنده از کانال تلگرام شما به این بحث لینک شدم.