mtr vs traceroute

A traceroute és az mtr egyaránt parancssori eszközök a hálózati útvonalakkal kapcsolatos problémák diagnosztizálására. A traceroute egyszeri pillanatfelvételt ad a csomagok útvonaláról. Az mtr ugyanezt teszi, de folyamatosan szondázza, és idővel statisztikákat készít a csomagvesztésről, a késleltetésről és a jitterről. Ez a bejegyzés azt mutatja be, hogyan működnek az egyes eszközök, hogyan olvasható a kimenet, és mikor melyiket érdemes használni.

Hogyan működik a traceroute

A traceroute az IP-csomagok fejlécében található Time-to-Live (TTL) mezőt használja. Egy csomagot küld, amelynek TTL értéke 1. Az első útválasztó nullára csökkenti a TTL értéket, eldobja a csomagot, és visszaküld egy ICMP "Time Exceeded" üzenetet. A Traceroute rögzíti az útválasztó IP-címét és a körbefutási időt, majd újabb csomagot küld 2-re állított TTL-lel, és így tovább, amíg a csomag el nem éri a célállomást, vagy el nem éri a maximális ugráshatárt (alapértelmezés szerint 30, beállítható a -m kapcsolóval).

Alapértelmezés szerint a traceroute ugrásonként három szondát küld, így három késleltetési időt mér. A protokollok operációs rendszerenként eltérőek:

• Windows: A tracert parancs ICMP Echo Requesteket küld.
• Linux/macOS: A traceroute parancs UDP adatcsomagokat küld (33434-33534 portok). Használja a -I parancsot az ICMP vagy a -T parancsot a TCP esetében, ha az UDP blokkolva van.

A -n jelző hozzáadása kihagyja a fordított DNS-keresést, ami jelentősen felgyorsítja a dolgokat a sok ugrást tartalmazó útvonalakon.

Hogyan működik az mtr

az mtr (My Traceroute) ugyanazt a TTL-alapú útvonal-keresést használja, mint a traceroute, de folyamatosan küld szondákat, jellemzően másodpercenként egyet. Az ugrásonkénti három adatpont helyett futó statisztikákat kap: csomagvesztési százalék, átlagos késleltetés, legjobb és legrosszabb válaszidő, valamint szórás (jitter).

az mtr támogatja az ICMP (alapértelmezett), UDP és TCP SYN szondákat. A TCP mód akkor hasznos, ha a tűzfalak blokkolják az ICMP-t, vagy ha egy adott alkalmazási portot szeretne tesztelni:

mtr --tcp --port 443 example.com

Ha nem interaktív jelentést szeretne készíteni, amelyet megoszthat a támogató csapattal, használja a jelentés módot:

mtr --report --report-cycles 100 example.com

Ez 100 próbát futtat le, és kiír egy összefoglalót. Egyéni csomagméreteket is beállíthat a --psize paranccsal az MTU vagy töredezettségi problémák teszteléséhez.

az mtr natívan fut Linuxon és macOS-en. A Windows-felhasználók a WinMTR-t használhatják a GUI megfelelőjéhez.

Legfontosabb különbségek

A gyakorlati különbség az időszakos problémákra vezethető vissza. Egyetlen traceroute könnyen kihagyhat egy olyan routert, amely a csomagok 2%-át dobja le, vagy egy 15 ms-os jitterrel rendelkező hopot. Az mtr ezeket azért kapja el, mert folyamatosan mér.

A kimenet elolvasása

A leggyakoribb hiba a traceroute vagy mtr kimenet olvasásakor az, hogy azt feltételezzük, hogy egy problémásnak tűnő köztes ugrás azt jelenti, hogy valódi probléma van. Ez általában nem így van.

A csillagok (*) a traceroute-ban azt jelentik, hogy a router nem válaszolt a szondára. Sok útválasztó úgy van beállítva, hogy figyelmen kívül hagyja vagy korlátozza az ICMP-t. Ha az utána következő lépések normálisan válaszolnak, az útvonal rendben van.

A csomagvesztés egyetlen ugrásnál az mtr-ben ugyanezt a logikát követi. Ha az 5. hop 20%-os veszteséget mutat, de a végső célállomás 0%-ot, akkor az az útválasztó csak deprioritizálja a szondaválaszokat. A valódi csomagvesztés mintaként jelenik meg: a veszteség egy ugrásnál jelenik meg, és minden további ugráson keresztül fennáll a célállomásig.

Az ugrások közöttikésleltetési időugrások normálisak és várhatóak. A 10 ms és 80 ms közötti ugrás általában azt jelenti, hogy a csomag egy óceánon vagy egy hosszú szárazföldi útvonalon haladt át. Csak akkor aggódjon a késleltetés miatt, ha az a távolsághoz képest szokatlanul magas (5 ms alatt egy nagyvárosi területen belül, több tíz milliszekundumos országhatáron, 80-150 ms óceánon át), vagy ha a végső célállomás késleltetése elfogadhatatlan.

Az StDev (jitter) mtr-ben kifejezett értékére érdemes odafigyelni. A 10 ms feletti értékek bármelyik hopban problémákat okozhatnak a VoIP, a videohívások és a játékok esetében. Ha magas jittert észlel, futtasson le legalább 100 ciklust, hogy megbizonyosodjon arról, hogy ez egy tartós mintázat, és nem egy rövid kiugrás.

Mikor kell használni az egyes eszközöket

A traceroute-ot akkorhasználja, ha gyors válaszra van szüksége: elérhető-e a célállomás, és ha nem, hol szakad meg az útvonal? Ez a megfelelő kiindulópont a kiesések és az alapvető útválasztás ellenőrzéséhez.

Használja az mtr-t, ha a probléma időszakos vagy a teljesítménnyel kapcsolatos. Az mtr folyamatos adataira van szükségük azoknak a felhasználóknak, akik alkalmi megszakadásokat, VoIP-minőségi problémákat vagy késleltetési csúcsokat jelentenek. A megbízható statisztikákhoz legalább 50-100 ciklust futtasson le.

Az alapos diagnózis érdekében futtassa az mtr-t mindkét irányban: a géptől a kiszolgálóig és a kiszolgálótól vissza az IP-címig. Az internetes útválasztás aszimmetrikus, így a visszaút teljesen eltérő jellemzőkkel bírhat. Ha csak az egyik irányt teszteli, lehet, hogy nem veszi észre, hol van valójában a probléma.

Ha problémái vannak dedikált szerverével vagy VPS-ével, az FDC Servers ügyfélszolgálati csapatai elfogadják az mtr-jelentéseket a hálózati eszkaláció standard diagnosztikai bizonyítékaként.