מכירים את הסיטואציה הבאה:
באים להכנס לאתר, והוא לא עולה, או יותר גרוע, הוא עובד כמו צב נחלים מצוי.
אז מי אשם? האתר?מישהו בדרך? ספק האינטרנט? ספק התשתית? הרשת המקומית?
MTR יגיד לנו.
MTR הוא כלי שנועד לזהות צווארי בקבוק בקשר ממך לאתר מסויים, הוא עובד במצב גראפי וגם במצב טקסטואלי.
עקרונית זה כלי ללינוקס, אבל אנשים טובים יצרו גרסאת חלונות שלו (לא בדקתי).
בתמונה פה אפשר לראות שיש עומס באחד הנתבים של בזק (תיקון: אין עומס, זו תופעה שנובעת מהגדרות מסויימות בנתב המסויים), שאקטקום עוברים דרכו מאז שבזק בינ"ל (ימח שמם) קנו אותם.
Facebook Comments
זה כולה GUI של הרצת tracert, לא?
יש אנשים שצריך לשלול את רישיון ה-traceroute שלהם :-). באמת נראה לך שיש יותר מ- 90% של אובדן באחד מההופים הראשונים, אבל בבאים בתור אין בעיות? כלומר פאקטים חדשים נוצרים יש מאין?
תרגיל פשוט: תעשה פינג ליעד הסופי שלך ותראה שאתה מקבל בחזרה הרבה יותר מ- 10%. איך זה יתכן אם יותר מ- 90% מהפאקטים אובדים בדרך?
התשובה פשוטה: הם לא. יש לבזק בינ"ל כמה נתבי core שעונים מאוד לאט ל- ICMP, זה הכל. חלקם לא עונים בכלל.
הייקו, לא – זה לא.
MTR זה לא tracert רגיל, ממש לא.
אמיר, לפני שאתה עושה מעצמך צחוק תקרא קצת על הכלי.
באמת? לפי האתר של mtr,
mtr combines the functionality of the 'traceroute' and 'ping' programs in a single network diagnostic tool.
As mtr starts, it investigates the network connection between the host mtr runs on and a user-specified destination host. After it determines the address of each network hop between the machines, it sends a sequence ICMP ECHO requests to each one to determine the quality of the link to each machine. As it does this, it prints running statistics about each machine.
ואחרי שעשית מעצמך צחוק, נסה בכל זאת לשלוח פינגים אל היעד הסופי של הבדיקה שלך ותראה שאני צודק.
צודק במה?
טענתי שיש עומס על אחד הנתבים בדרך, זה לא אומר שהוא מאבד 90% מהחבילות.
MTR בודק עומס על כך אחד מהנתבים בדרך, הוא מאפשר לך לדעת איפה מתחילה בעיה.
הבעיה במקרה הזה היא מדומה והיא באמת נובעת מהגדרות של אותו נתב (לא היתה לי בעיה לגשת לגוגל באותו רגע, בסך הכל רציתי צילומסך), אבל באופן כללי MTR נותן יותר מידע מtraceroute.
צודק במה? בכל מה שכתבתי בהודעה המקורית שלי.
אין שום עומס על הנתב הזה, כפי שניתן לראות בבירור מהתוצאות של ההופים הבאים בדרך. מדובר בהגדרה בנתב ולא בעומס.
עומס בנתב כלשהו בדרך, כפי שהיה אמור להיות ברור לך, ישפיע על התוצאות שתקבל מכל הנתבים הבאים אליו כיוון שהפאקטים אל הנתבים הבאים עוברים דרך הנתב העמוס. הבדיקה שהצגת מראה בבירור שאין בעיות עם הנתבים הבאים.
ואני עם הויכוח הזה סיימתי. או שאתה באמת לא מבין על מה אתה מדבר ולכן לא יכול להודות שטעית, או שאתה מסרב להודות באעות שברור לך שעשית. בכל מקרה אין טעם להמשיך.
אמיר, נראה שאתה כל כך עסוק בלהתנפח שאתה בכלל לא קורא את מה שאני כותב.
תן לי לחזור:
"הבעיה במקרה הזה היא מדומה והיא באמת נובעת מהגדרות של אותו נתב".
מבין?
אני מסכים איתך שאין בעית עומס בנתב הזה (במיוחד שלא היתה לי שום סיבה לחשוב שיש בו עומס לפני שביצעתי את הבדיקה).
ובכל זאת, MTR יכול להראות אובדן נתונים מנתב אחד ובכל זאת להראות שהמצב באלו שאחריו תקין.
לא עיינתי בקוד של MTR כדי להבין מה המשמעות של נתון כזה, אבל ברור לגמרי שהתוצאות של MTR שונות בטבע שלהם מהתוצאות של פינג או טרייס-ראוט רגיל.
אני סיימתי להגיב לך.