بررسی ابزار MTR - حلقه ارتباطی ابر آروان

ابر آروان

زیرساخت یکپارچه ابری

۲۲ اسفند ۱۳۹۷

بررسی ابزار MTR

از کارهای مهم در مدیریت سرورها، مانیتور وضعیت شبکه است. ابزارهای مختلفی برای مانیتورینگ ارتباطات وجود دارند که می‌توان یکی از قدرتمندترین آن‌ها را MTR (My Traceroute) معرفی کرد. این ابزار به مدیر شبکه کمک می‌کند تا خطاها را شناسایی کند و گزارشی از وضعیت کلی شبکه به‌دست آورد.

در این مطلب سعی شده است تا به 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 (مقدار یک) ارسال می‌شود و به‌تدریج مقدار 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

هدف اصلی استفاده از گزارش‌های 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، همان ۳۰درصد نشان داده شده‌ی آخرین گام (گام 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 تا مقدار ۱۰درصد نرمال است اما اگر این درصد افزایش پیدا کند، حاکی از وجود مشکل است و نیاز به بررسی‌های بیش‌تری دارد. باز هم توصیه می‌شود تا از 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 نیز باید به داده‌های مربوط به آخرین گام‌ها توجه کرد.

بدون دیدگاه

برچسب‌ها:




× برای اطلاع از آخرین اخبار و مقالات آروان عضو خبرنامه ما شوید