שלום לכולם, לאחרונה יש לי בעיות של Lag spikes במגוון של משחקי רשת.

בצעתי Trace Route לאחד השרתים הבעיתיים ויש לי מספר שאלות.

לפי מה שאני מבין Trace Route זה בעצם שולח פינג לכל שרת שאני מנותב דרכו עד שאני מגיע ליעד, האם אני צודק ?

אם כך איך זה יכול להיות שהפינג לאחד הHops יכול להיות גדול מהפינג הסופי ליעד ? הפינג הסופי ליעד לא אמור להיות סכום של כל הפינגים דרך כל הHops ?

לפי הגרף הנ"ל רואים שיש איבוד חבילות גדול מאוד מהHops הראשונים שהם בעצם נתבים של הספק (בזק) לא ?

או שאולי הם חוסמים פינג לשרתים אלו ? אם כך לא היה אמור להופיע 100% איבוד חבילות ?

מה ניתן להסיק מהגרף הנ"ל ? האם יש תקלה בשרתים של בזק ?

בתודה מראש, מייק.

אני ממליץ לך להריץ חיפוש פה בפורום רשתות לגבי traceroute כדי להבין מה באמת התוצאות האלו אומרות.

אם שרת מסויים היה חוסם icmp echo request אז בכלל אל היית מקבל ממנו ping מלכתחילה.

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

מה שלא מובן לי, מה אומר הזמן כאשר בודקים הרבה Traces ובודקים זמן חזרה מינימלי (שניהם בשמיים בכל זאת בדוגמה הנ"ל) בזמן זה הנתב כניראה לא במאמץ גבוהה ומחזיר את הזמן המדוייק ?

מה בדבר הPacketloss ?

אני חושב שההסבר בויקיפדיה מסביר את העניין בצורה דיי פשוטה:

Traceroute works by increasing the "time-to-live" value of each successive batch of packets sent. The first three packets sent have a time-to-live (TTL) value of one (implying that they are not forwarded by the next router and make only a single hop). The next three packets have a TTL value of 2, and so on. When a packet passes through a host, normally the host decrements the TTL value by one, and forwards the packet to the next host. When a packet with a TTL of one reaches a host, the host discards the packet and sends an ICMP time exceeded (type 11) packet to the sender. The traceroute utility uses these returning packets to produce a list of hosts that the packets have traversed en route to the destination. The three timestamp values returned for each host along the path are the delay (aka latency) values typically in milliseconds (ms) for each packet in the batch. If a packet does not return within the expected timeout window, a star (asterisk) is traditionally printed. Traceroute may not list the real hosts. It indicates that the first host is at one hop, the second host at two hops, etc. IP does not guarantee that all the packets take the same route. Also note that if the host at hop number N does not reply, the hop will be skipped in the output

packet loss זה אומר שחבילות תקשורת הולכות לאיבוד (לא חוזרות או לא מגיעות ליעדן)

לחפש בפורום היה נותן לך את התשובה מיד.

הנה הסבר קצר:

trace route זה שליחת ICMP packet אחד אחרי השני כאשר הTTL עולה כל פעם ב1.

TTL (או Time To Live) זה מספר הרשתות (או נתבים) שלפקאט מותר לעבור. PING עם TTL=1 יעצר בנתב הבייתי (או בנתב הראשון של התשתית בכבלים, לחילופין הנתב הראשון של הספקית בADSL).

הקטע הוא שכשפאקט "מת" לפני היעד הנתב/שרת שמחזיק בו שולח הודעה חזרה למחשב שממנו יצא הפאקט ע"מ שידע שהמידע לא הגיע ליעדו. הטרייס בודק כמה זמן לקח משליחת הפאקט עד שמגיעה התשובה "הפאקט מת", כלומר זה לא תשובת פינג. טרייס היא לא פינג!

בגלל איך שהפקודה עובדת אפשר "למפות" את הדרך של המידע למקום מסויים (למרות שהוא יכול להשתנות).

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

אז מה הבעיה אם איך שאתה קורא את המידע, DarkMoh? פשוט - הרבה שרתים, בייחוד של ספקיות האינטרנט מתעדפים את מתן תשובה לפינג או "פאקט מת" ככה שהוא יהיה אחרון בסדר העדיפות, לכן מקבלים פתאום תשובה של 600MS משרת של בזק בינ"ל. הסיבה לתעדף תשובות כאלו נמוך היא שזה לא יפריע לפעולה ה"אמיתית" של הנתב/שרת - ניתוב מידע באינטרנט. בגלל הסיבה הזאת, אם רואים "פינגים" גבוהים בטרייס שאח"כ יורדים לטווח התקין זה אומר שאין בעיה. ד"א, אפשר להגיד לשרת/נתב לא לשלוח בכלל תשובה חזרה ואז מה שרואים זה רק כוכביות.

בעיה שאפשר לראות בטרייס זה שפתאום משרת מסוים והלאה הזמן לתשובות ארוך ולא יורד, למשל אם אחד השרתים של בזק בינ"ל היה מחזיר תשובה של 400ms וכל תשובה אחרי זה הייתה גם 400ms ומעלה אז באמת יש בעיה אצלהם.

דוגמא לטרייס שביצעתי לIP שהבאת באחת התמונה:

aner@MultiVac:~$ traceroute 85.17.111.12
traceroute to 85.17.111.12 (85.17.111.12), 30 hops max, 40 byte packets
 1 192.168.1.1 (192.168.1.1)                1.624 ms  2.498 ms  3.376 ms
 2 172.26.255.17 (172.26.255.17)              26.044 ms  29.512 ms  35.370 ms
 3                              * * *
 4 gi2-8.bk1-gw.013bk.net (62.90.133.141)          38.271 ms  39.951 ms  *
 5 gi5-0.bk1-bb.013bk.net (212.150.232.125)         36.362 ms  37.245 ms  39.073 ms
 6 gi3-0.uk-bb.013bk.net (212.150.232.237)         115.576 ms 99.633 ms  105.206 ms
 7 ldn-tch-i1-link.telia.net (213.248.100.25)        109.174 ms 135.212 ms 151.162 ms
 8 ldn-b1-link.telia.net (80.91.250.209)          138.392 ms 142.007 ms 144.921 ms
 9 ldn-bb1-link.telia.net (80.91.248.90)          147.590 ms 150.133 ms 154.143 ms
10 adm-bb1-pos6-0-0.telia.net (213.248.65.150)       157.847 ms 158.702 ms 159.549 ms
11 adm-b3-link.telia.net (80.91.254.125)          155.114 ms 155.971 ms 156.797 ms
12 leaseweb-ic-121169-adm-b3.c.telia.net (213.248.102.154) 101.774 ms 100.976 ms 100.404 ms
13 hosted-by.leaseweb.com (85.17.111.12)          104.095 ms 104.130 ms 105.399 ms

שים לב לשורה 10 ו13 - נראה לך הגיוני שלוקח למידע פחות זמן להגיע ליעד מאשר לנתב באמצע הדרך?? ברור שלא כי הבדיקה לא עובדת ככה!

אם, למשל, בשורה התשיעית הייתי מקבל 200ms וכל תשובה אחרי זה לא הייתי מקבל פחות מזה אז הייתי יודע שהקפיצה הזאת היא הבעייתית. יכול להיות שזה קפיצה מאירופה לארה"ב, אבל אם אני יודע שלא היה שינוי מיוחד בדרך אז הבעיה היא שם.