mtr vs. traceroute

Traceroute și mtr sunt ambele instrumente de linie de comandă pentru diagnosticarea problemelor legate de traseul rețelei. Traceroute vă oferă un instantaneu al traseului pe care îl urmează pachetele. mtr face același lucru, dar continuă să sondeze, construind statistici privind pierderea de pachete, latența și jitter-ul în timp. Această postare prezintă modul în care funcționează fiecare instrument, cum să citiți rezultatele și când să le utilizați.

Cum funcționează traceroute

Traceroute utilizează câmpul Time-to-Live (TTL) din anteturile pachetelor IP. Acesta trimite un pachet cu TTL setat la 1. Primul router decrementează TTL la zero, elimină pachetul și trimite înapoi un mesaj ICMP "Time Exceeded". Traceroute înregistrează IP-ul routerului și timpul de întoarcere, apoi trimite un alt pachet cu TTL setat la 2 și așa mai departe până când pachetul ajunge la destinație sau atinge limita maximă de hopuri (30 în mod implicit, reglabilă cu -m).

În mod implicit, traceroute trimite trei sonde per hop, oferindu-vă trei citiri ale latenței. Protocoalele diferă în funcție de sistemul de operare:

• Windows: Comanda tracert trimite ICMP Echo Requests.
• Linux/macOS: Comanda traceroute trimite datagrame UDP (porturile 33434-33534). Utilizați -I pentru ICMP sau -T pentru TCP dacă UDP este blocat.

Adăugarea indicatorului -n omite căutările DNS inverse, ceea ce accelerează semnificativ lucrurile pe căile cu multe salturi.

Cum funcționează mtr

mtr (My Traceroute) utilizează aceeași descoperire a căii bazată pe TTL ca și traceroute, dar continuă să trimită sonde, de obicei una pe secundă. În loc de trei puncte de date pentru fiecare salt, obțineți statistici curente: procent de pierdere de pachete, latență medie, cel mai bun și cel mai rău timp de răspuns și abaterea standard (jitter).

mtr acceptă sondele ICMP (implicit), UDP și TCP SYN. Modul TCP este util atunci când firewall-urile blochează ICMP sau când doriți să testați un anumit port de aplicație:

mtr --tcp --port 443 example.com

Pentru un raport non-interactiv pe care îl puteți partaja cu o echipă de asistență, utilizați modul raport:

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

Acesta rulează 100 de sonde și tipărește un rezumat. De asemenea, puteți seta dimensiuni personalizate ale pachetelor cu --psize pentru a testa probleme legate de MTU sau fragmentare.

mtr rulează nativ pe Linux și macOS. Utilizatorii Windows pot folosi WinMTR pentru un echivalent GUI.

Diferențe esențiale

Diferența practică se reduce la problemele intermitente. Un singur traceroute poate rata cu ușurință un router care pierde 2% din pachete sau un hop cu 15ms de jitter. mtr detectează aceste probleme pentru că continuă să măsoare.

Citirea rezultatelor

Cea mai frecventă greșeală la citirea rezultatelor traceroute sau mtr este presupunerea că un hop intermediar cu aspect problematic înseamnă că există o problemă reală. De obicei, nu este așa.

Asteriscurile (*) din traceroute înseamnă că routerul nu a răspuns la sondă. Multe routere sunt configurate să ignore sau să limiteze rata ICMP. Dacă hopurile următoare răspund în mod normal, calea este bună.

Pierderea de pachete la un singur hop în mtr urmează aceeași logică. Dacă hopul 5 indică o pierdere de 20%, dar destinația finală indică 0%, routerul respectiv nu face decât să deprioritizeze răspunsurile sondei. Pierderea reală a pachetelor se manifestă sub forma unui model: pierderea apare la un hop și persistă la fiecare hop ulterior până la destinație.

Salturile de latență între hopuri sunt normale și așteptate. Un salt de la 10ms la 80ms înseamnă de obicei că pachetul a traversat un ocean sau o rută terestră lungă. Vă faceți griji cu privire la latență doar dacă este neobișnuit de mare pentru distanță (sub 5 ms într-o zonă metropolitană, zeci de milisecunde în afara țării, 80-150 ms transoceanic) sau dacă latența destinației finale este inacceptabilă.

StDev (jitter) în mtr merită atenție. Valorile de peste 10ms la orice hop pot cauza probleme pentru VoIP, apeluri video și jocuri. Dacă observați un jitter ridicat, efectuați cel puțin 100 de cicluri pentru a confirma că este un model susținut și nu un vârf scurt.

Când să utilizați fiecare instrument

Utilizați traceroute atunci când aveți nevoie de un răspuns rapid: se poate ajunge la destinație și, dacă nu, unde se întrerupe calea? Este punctul de plecare potrivit pentru întreruperi și pentru a verifica rutarea de bază.

Utilizați mtr atunci când problema este intermitentă sau legată de performanță. Utilizatorii care raportează deconectări ocazionale, probleme legate de calitatea VoIP sau vârfuri de latență au nevoie de datele continue ale mtr. Rulați cel puțin 50-100 de cicluri pentru statistici fiabile.

Pentru un diagnostic complet, rulați mtr în ambele direcții: de la computerul dvs. la server și de la server înapoi la IP-ul dvs. Rutarea pe internet este asimetrică, astfel încât calea de întoarcere poate avea caracteristici complet diferite. Dacă testați doar o direcție, s-ar putea să nu observați unde se află de fapt problema.

Dacă întâmpinați probleme cu serverul dvs. dedicat sau VPS, echipele de asistență FDC Servers acceptă rapoartele mtr ca dovezi standard de diagnostic pentru escaladarea rețelei.