تشخیص مشکلات شبکه با MTR

[تعداد: 0    میانگین: 0/5]

MTR یک ابزار قدرتمند و مورد نیاز و مخفف My traceroute که مدیران شبکه را قادر می سازد تا مشکلات شبکه را شناسایی کنند و گزارشاتی از وضعیت آن را ارائه دهند.

ابزاهای شناسایی مشکلات شبکه مانند  ping , traceroute و MTR از پروتکل Internet Control Message Protocol به صورت اختصار (ICMP) برای ارسال پکت ها و تست ترافیک بین دو نقطه در شبکه استفاده می کند.

وقتی یک کاربر یک هاست را در شبکه پینگ می کند ، یکسری از پکت های ICMP به آن ارسال می شود ، که در مقابل هاست مقصد در جواب پکت هایی را بر می گرداند و بدین صورت می توان رفت و برگشت در دو نقطه در شبکه را محاسبه کرد.در مقابل ابزار هایی مانند traceroute و MTR پکت ها را با افزایش تدریجی TTLs ارسال می کنند تا مسیر بین مبدا و مقصد را مشاهده شود.

در این آموزش به نصب و چگونگی استفاده از MTR می پردازیم.

نصب MTR در لینوکس 

Debian/Ubuntu

1.بروز رسانی سیستم عامل :

2.نصب با APT

CentOS/RHEL/Fedora

1.بروز رسانی سیستم عامل :

2.نصب با Yum

نصب MTR در ویندوز

در ویندوز نرم افزار WinMTR می باشد که آخرین نسخه ی این نرم افزار را می توانید از لینک زیر دریافت کنید.

دریافت آخرین نسخه ی WinMTR

WinMTR

نصب MTR در macOS

نصب MTR روی مک او اس با Homebrew یا MacPorts :

شروع کار با MTR

استفاده از MTR در لینوکس

تولید گزارش با استفاده از دستور زیر :

به جای [destination_host] باید آدرس هاست مقصد را بزاریم

برای مثال :

اگر پکتی از دست نرفت (lost نشد) می توانیم برای بررسی دقیق تر اجرای را سریع تر کنیم :

در برخی سیستم ها این دستور ممکن دسترسی سوپر یوزر نیاز داشته باشد که با اضافه کردن sudo به اول دستور خود این دسترسی را تامین می کنیم.

بررسی option های این دستور :

r مخفف report می باشد و گزارش تولید می کند.

w مخفف report-wide می باشد و برای مشاهده هاست نیم کامل استفاده می شود.

c تعداد پکت هایی که ارسال می شود را مشخص می کند. شاید به خاطر سپردن آن با کلمه count راحت تر باشد.

i عملیات را با نرخ سریع تر اجرا می کند و باعث می شود MTR پکت ها را هر n ثانیه ارسال کند.(در حالت پیش فرض 1 ثانیه می باشدکه در بالا ما 0.2 ثانیه استفاده کردیم)

بررسی یک گزارش تولید شده توسط MTR

این یک گزارش MTR از شبکه داخلی به گوگل می باشد که تفسیر آن در نگاه اول ممکن است کمی پیچیده باشد.

در این گزارش از دستور :

استفاده شده است که 10 پکت به گوگل ارسال می کند.

اگر از آپشن –report استفاده نشود ، MTR بدون متوقف شدن تولید گزارش را ادامه می دهد.

هر خط در این گزارش یک نود اینترنتی را نشان می دهد که پکت ها را به مقصد خود می رسانند.

inner-cake یک هاست نیم می باشد ، برای این که به جای هاست نیم ها آی پی آن ها نمایش داده شود از آپشن –no-dns می توانیم استفاده کنیم.

دستور :

همانطور که مشاهده می کنید در گزارش بالا MTR با آپشن –no-dns اجرا شد و به جای هاست نیم ها ، آی پی آن ها نمایش داده شد.

در این گزارش ها به آسانی مسیر بین سرور ها که پکت ها به مقصد خود می رسانند قابل مشاهده می باشد.

گزارش های MTR هفت ستون دارند که به توضیح آن ها می پردازیم : 

ستون Loss% درصد پکت های از دست رفته یا lost شده را در هر node را نشان می دهد.

ستون Snt تعداد پکت های ارسال شده در هر node را نشان می دهد که با آپشن :

می توان مقدار آن را تغییر داد.

چهار ستون دیگر یعنی Last, Avg, Best, Wrst برای اندازه گیری زمان تاخیر یا انتظار در واحد میلی ثانیه استفاده می شود.

Last زمان تاخیر آخرین پکت ارسالی ، Avg زمان تاخیر تمامی پکت ها ، Best و Wrst کم ترین و بیشترین زمان ارسال پکت به هاست آن ردیف می باشد.

در بیشتر موارد باید ستون Avg مورد توجه قرار گیرد.

ستون آخر یعنی StDev مخفف Standard deviation می باشد که اگر StDev بالا باشد یعنی اندازه گیری های  زمان تاخیر (Last, Avg, Best, Wrst) متناقض می باشد.

در گزارش MTR اگر در ردیفی مقدار Loss% صفر نبود حتما به این معنی نیست که مشکلی در آن نود وجود دارد و پکتی lost می شود ، در برخی سرویس دهنده ها روی ترافیک ICMP محدودیت می گذارند که باعث به وجود آمدن این مورد می شود.

برای اینکه متوجه بشیم این lost شدن واقعی هست یا صرفا سرویس دهنده روی ICMP محدودیت گذاشته به گزارش زیر توجه کنید :

در این گزارش مقدار lost شدن در نود یک 0% و در نود دوم 50% و در بقیه نود ها 0% می باشد که به این معنیست که در نود دوم محدودیت ترافیک ICMP گذاشته شده و مشکلی در آن نود وجود ندارد و پکتی از دست نمی رود.

در گزارش زیر :

که از نود 4 ام به بعد مقدار Loss% صفر نیست متوجه میشیم در نود 3 و 4 مشکلی وجود دارد و مربوط به محدودیت سرویس دهنده نیست.

Latency شبکه 

Latency یا زمان تاخیر در شبکه معمولا به کیفیت دو هاست مقصد و مبدا و فاصله ی آنها بستگی دارد ، همچنین کیفیت ارتباطی یا سرعت شبکه بین آنها ممکن است تاثیر گذار باش ، برای مثال Dial-up ها Latency بیشتری نسبت به ADSL ها و … دارند.

گزارش بالا Latency بالا را نشان می دهد که از نود 3 به بعد به میزان قابل توجهی افزایش یافته است.

از این گزارش فهمیدن مشکل تقریبا غیر ممکن است و ممکن است که مربوط به کانفیگ ضعیف روتر یا … باشد.

روتر های عمومی یا تجاری : 

بعضی اوقات اجرای MTR در این روتر ها گزارش گمراه کننده ای را می دهد ، برای مثال :

در نود دوم همانطور که می بینید مقدار Loss% صد در صد می باشد که به این معنی نیست که مشکلی وجود دارد زیرا در ادامه مقدار Loss% بقیه نود ها صفر می باشد.

استفاده از MTR با پروتکل TCP

در نسخه های جدید ابزار MTR قابلیت اجرا شدن بر روی یک پورت خاص TCP و با پروتکل TCP به جای ICMP فراهم شده است.

در برخی شبکه ها که فایروال آن ها به درستی کانفیگ نشده اجرای MTR با پروتکل پیشفرض یعنی ICMP ممکن است که نتایج درست از lost شدن پکت ها را نشان ندهد که اجرای MTR بر روی پورت مشخص می تواند این مشکل را حل کند.

اجرای MTR با پروتکل TCP

بر روی پورت 80

بر روی پورت 22

 

با تشکر که با ما همراه بودید.


درصورت وجود هرگونه مشکل و یا نیاز به مشاوره برای کانفیگ سرور، با کارشناسان ویکی بیت به صورت 24 ساعته در ارتباط باشید.

کانال ویکی بیت در تلگرام : @wikibit

Tags :

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *