Traceroute

Traceroute חושף את רצף הקפיצות בינך לבין יעד. כל קו בפלט הוא נתב אחד; זמן הנסיעה הלוך ושוב אומר לך את ההשהיה לנתב זה. כאשר משהו באינטרנט איטי או מקולקל, traceroute הוא בדרך כלל הכלי הראשון שיצא מהקופסה.

איך זה עובד: טריק TTL

לכל חבילת IP יש שדה Time To Live (TTL), שנועד במקור למנוע חבילות להסתובב לנצח במעגל. כל נתב מוריד את ה-TTL באחד. כאשר TTL מגיע לאפס, הנתב מפיל את החבילה ושולח בחזרה הודעת ICMP "Time Exceeded" למקור.

Traceroute מייצר את זה:

1. שלח חבילה ליעד עם TTL=1. הנתב הראשון מוריד אותו ל-0, מוריד אותו, משיב ב-"Time Exceeded" - חושף את עצמו כהופ 1.
2. Send TTL=2. הנתב הראשון מוריד ל-1 ואילך; הנתב השני יורד ל-0, נופל, משיב - חושף הופ 2.
3. המשך להגדיל עד שתגיע ליעד, אשר עונה במשהו אחר (יציאה בלתי ניתנת להשגה או תגובה של יישום בפועל). שלוש בדיקות לכל קפיצה הן ברירת המחדל, וזו הסיבה שאתה רואה שלוש מדידות RTT בכל קו.

   שלושת סוגי הבדיקה

   יישומי traceroute שונים שולחים סוגים שונים של בדיקות:

   • UDP traceroute יציאות גבוהות ל-XPLZ יציאות UDP29): מספרים. היעד משיב ב"נמל בלתי ניתן להגיע". ברירת מחדל ב-Linux/macOS.
   • ICMP traceroute (Windows tracert): שולח מנות ICMP Echo Request. היעד משיב ב-Echo Reply. התנהג טוב יותר דרך כמה חומות אש.
   • TCP traceroute: שולח TCP SYN ליציאה ספציפית (בדרך כלל 80 או 443). שימושי כאשר יעד מוריד את UDP ו-ICMP אך מקבל TCP על יציאה ידועה.

   הכלי הנכון תלוי במה שמפילות חומות האש של הנתיב. tcptraceroute מצליח לעיתים קרובות כאשר traceroute נכשל.

   קריאת הפלט

   A קו טיפוסי:

    5 aefrale.net.de1.exfra.net (172.16.50.1) 18.234 ms 18.012 ms 17.998 ms

   מספר ההופ, שם הנתב וה-IP, ולאחר מכן שלוש מדידות RTT. כוכביות * * * אומרות שהנתב לא הגיב - או שהוא הפיל את הבדיקה, תגובות ICMP מוגבלות בקצב, או שהוגדר לא לזהות את עצמו. כוכביות הן נורמליות ואינן אומרות בהכרח בעיה; נתבי עמוד שדרה רבים אינם מגיבים ל-traceroute בכוונה. ae1.cr1.fra4.de אומר לך: צרור Ethernet מאגד 1, נתב ליבה 1, אתר 4 של פרנקפורט, גרמניה. מהנדסי רשת יכולים לקרוא את השמות האלה כמו לוחיות רישוי ולומר לך לאיזה ספק יש את הנתיב, באיזו עיר נמצאת החבילה, ואפילו באיזו ספק ציוד (Cisco vs Juniper vs Arista) משתמש המפעיל.

   מעקף גיאוגרפי בלתי צפוי - מנות ליעד פרנקפורט העוברות דרך סינגפור - פירושו בדרך כלל החלטת מדיניות חיתוך סיבים פיזית של BGP. ניתוב לא אופטימלי מתרחש כל הזמן ואינו מהווה בהכרח בעיה.

   בעיית הנתיב האסימטרי

   Traceroute מציגה רק את הנתיב outbound. נתיב החזרה יכול להיות - ולעתים קרובות הוא - שונה לחלוטין, מכיוון שכל AS בוחר את הניתוב היוצא שלו. RTT גבוה בקפיצה יכול להיות קישור איטי שם, או שזה יכול לומר שהקישור האיטי נמצא בנתיב החזרה מאותה הקפצה. ללא traceroute מהיעד בחזרה אליך, אתה לא יכול לדעת.

   זו הסיבה ש"traceroute נראה בסדר אבל ההשהיה שלי נוראית" הוא מצב שכיח. הגשושית בוחנת את הנתיב כיוון אחד בכל פעם.

   חלופות מודרניות: כלים בסגנון MTR ו-mtr

   MTR (ה-Traceroute שלי) היא מסלול רציף - הוא מצלצל כל קפיצה בלופ ומראה נתונים סטטיסטיים של הפסד, RTT ממוצע. הרבה יותר שימושי לאבחון בעיות לסירוגין מאשר מעקב ב-shot one. WinMTR ב-Windows, mtr ב-Unix, PathPing כחלופה המובנית של Windows.

   לאבחון נתיב שאין בבעלותך, שרתי RIPE Atlas ושרתי מראה המופעלים על ידי רשתות גדולות מאפשרים לך להריץ traceroute מנקודת תצפית מרוחקת - לא יסולא בפז להבנת מסלולים אסימטריים.<

   .h2>מגבלות ומוזרויות

   MPLS מודעים לנתבים יכולים להסתיר תנועות על ידי אי הפחתה של TTL על פני ענן MPLS. רשתות מאוזנות עומס יכולות להראות נתיבים שונים בבדיקות עוקבות, מה שגורם לפלט להיראות כאוטי. הגבלת קצב ICMP בנתבים עסוקים עלולה לייצר קריאות שווא "הופ איטי" שאינן משקפות ביצועים בפועל של מישור הנתונים. RTT של נתבי הביניים מודד את הזמן עד למטוס הבקרה של אותו נתב, שלעתים קרובות איטי יותר ממישור הנתונים דרך אותו נתב. השתמש ב-traceroute כרמז, לא מדד.