Úvod
MTR (původně Matt's TraceRoute, nyní jen My TraceRoute) je praktický a lehký nástroj v arzenálu správce UNIX/Linux, který může pomoci identifikovat a diagnostikovat běžné síťové problémy, jako je latence, ztráta paketů a chyby směrování. Je to výkonný nástroj 2 v 1, který kombinuje a zobrazuje výsledky traceroute a pingu jediným příkazem. Pojďme si projít základy používání MTR a jak interpretovat data, která poskytuje.
Předpoklady
- Budete potřebovat server Linux, a pokud server ještě nemáte, můžete navštívit naši stránku VPS Hosting a spustit nový server za méně než 30 sekund
Instalace MTR
Balíčky MTR jsou dostupné pro většinu dnešních populárních operačních systémů Linux (nebo založených na UNIXu).
Nainstalujte MTR na Ubuntu/Debian:
sudo apt-get install mtr-tiny
mtr-tinypackage je verzemtrurčená pouze pro příkazový řádek balík.mtrbalíček obsahuje podporu pro grafické rozhraní X-11.
Nainstalujte MTR na CentOS/Fedora:
yum install mtr
Nainstalujte MTR na Arch Linux:
pacman -S mtr
Nainstalujte MTR na FreeBSD:
pkg install mtr
.
Jak funguje MTR
Chcete-li porozumět výstupu, který MTR generuje, může být užitečné vědět, jak to funguje. Pokud jste již obeznámeni s tím, jak traceroute příkaz funguje, pak vám toto vysvětlení bude znít povědomě.
MTR vygeneruje paket požadavku ICMP Echo Request určený pro cílovou IP/název hostitele vašeho mtr příkaz. První paket bude mít hodnotu time-to-live (TTL) 1. Když tento paket dorazí k routeru, který je jeho bránou na cestě k jeho případnému cíli, přijímající router sníží TTL o 1, takže bude 0. Když TTL dosáhne 0, router zahodí paket a odešle původnímu odesílateli paket ICMP Time Exceeded. Tento návratový paket obsahuje IP adresu odesílatele a MTR zobrazí tuto IP (nebo název hostitele, pokud to dokáže) jako první skok. Poté odešle samostatný paket ICMP Echo Request s TTL 2, a když přijme paket ICMP Time Exceeded z vypršení TTL, vypíše toto zařízení jako druhý skok a tak dále, dokud cíl nevrátí paket ICMP Echo Reply. .
.
Čtení zpráv MTR
Kromě výpisu každého síťového skoku mezi původcem a cílem MTR také sleduje statistiky související s dobou zpáteční cesty pro pakety od původního hostitele ke každému skoku na cestě. Tato doba zpáteční cesty se často nazývá latence .
Abychom získali lepší představu o tom, co nám MTR říká, podívejme se na příklad, který sleduje cestu k veřejnému DNS společnosti Google.
sudo mtr -r 8.8.8.8
[sample results below]
HOST: endor Loss% Snt Last Avg Best Wrst StDev
1. 69.28.84.2 0.0% 10 0.4 0.4 0.3 0.6 0.1
2. 38.104.37.141 0.0% 10 1.2 1.4 1.0 3.2 0.7
3. te0-3-1-1.rcr21.dfw02.atlas. 0.0% 10 0.8 0.9 0.8 1.0 0.1
4. be2285.ccr21.dfw01.atlas.cog 0.0% 10 1.1 1.1 0.9 1.4 0.1
5. be2432.ccr21.mci01.atlas.cog 0.0% 10 10.8 11.1 10.8 11.5 0.2
6. be2156.ccr41.ord01.atlas.cog 0.0% 10 22.9 23.1 22.9 23.3 0.1
7. be2765.ccr41.ord03.atlas.cog 0.0% 10 22.8 22.9 22.8 23.1 0.1
8. 38.88.204.78 0.0% 10 22.9 23.0 22.8 23.9 0.4
9. 209.85.143.186 0.0% 10 22.7 23.7 22.7 31.7 2.8
10. 72.14.238.89 0.0% 10 23.0 23.9 22.9 32.0 2.9
11. 216.239.47.103 0.0% 10 50.4 61.9 50.4 92.0 11.9
12. 216.239.46.191 0.0% 10 32.7 32.7 32.7 32.8 0.1
13. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14. google-public-dns-a.google.c 0.0% 10 32.7 32.7 32.7 32.8 0.0
Přehledy MTR ve výchozím nastavení zobrazují následující sloupce:
– Procento ztráty =Procento paketů, pro které nebyla přijata odpověď ICMP.
– Snt =Počet paketů odeslaných do každého skoku.
– Poslední =Doba zpáteční cesty poslední sondy traceroute v milisekundách.
– Prům =Průměrná doba oběhu všech sond traceroute v milisekundách.
– Nejlepší =Nejkratší doba oběhu ze všech sond traceroute v milisekundách.
– Wrst =Nejdelší doba oběhu ze všech sond traceroute v milisekundách.
– StDev =Výsledky sondy standardní odchylky pro každý skok.
.
Získání živé zprávy z MTR
Pokud spustíte MTR pouze s cílovou IP (nebo názvem hostitele), získáte živý přehled, který bude pokračovat, dokud neukončíte relaci nebo nespustíte příkaz break (Ctrl+C ).
sudo mtr 8.8.8.8
Některé operační systémy vyžadují
sudopřed spuštěnímmtrpříkaz; ostatní ne.
.
Pokud chcete MTR pozastavit, stiskněte p . MTR zachová všechny počty shromážděné během pozastavení, což vám umožní pořídit snímek obrazovky nebo zkopírovat data do schránky. Zrušte pozastavení MTR pomocí mezerníku.
.
Generování přehledu MTR s pevným počtem
Můžete také vygenerovat zprávu MTR po určitém počtu trasovacích sond pomocí -r možnost (dlouhá forma je --report ). Výchozí počet počtů je 10, ale pokud chcete spustit MTR pro jiný počet počtů, použijte -c (--report-cycles ) možnost také. Pokud byste například chtěli vygenerovat přehled s více než 200 počty:
sudo mtr -rc 200 8.8.8.8 [long form] sudo mtr --report --report-cycles 200 8.8.8.8
Jakýkoli běh MTR s -r volba nevytvoří žádný výstup (na rozdíl od živé zprávy výše), dokud nedokončí plný počet počtů. MTR ve výchozím nastavení odesílá sérii trasovacích sond jednou za sekundu, takže hlášení by mělo být dokončeno za několik sekund, které se rovnají vašemu počtu (200 sekund ve výše uvedeném příkladu).
.
Další užitečné možnosti
Existuje několik dalších možností, které se vám mohou hodit při používání MTR. Ty, které nevyžadují argumenty (například -r ) mohou být zřetězeny ve stejném řetězci voleb (např. -rn ). Možnost vyžadující argument lze zahrnout do jednoho z těchto řetězců pouze v případě, že je poslední možností a za ní následuje její argument (např. -rnc 200 ).
-n:(dlouhý tvar--no-dns) Zakázat vyhledávání názvu hostitele DNS.nklíč lze také použít během živého hlášení k přepínání mezi zakázáním a povolením vyhledávání DNS.-u:Odesílat datagramy UDP místo ICMP echo paketů požadavku.umůže také přepínat mezi UDP a ICMP během živé zprávy.-w:(dlouhý tvar--report-wide) Nahrazuje-rale vytváří sestavu, která nezkracuje delší názvy hostitelů.-i*:(dlouhý tvar--interval) Zadejte interval v sekundách mezi testovacími sondami. Výchozí interval je 1 sekunda.-4:Omezit test na IPv4.-6:Omezit test na IPv6.
.
Analýza dat MTR pro latenci
Výstup dat MTR vám může pomoci identifikovat problémy se směrováním, které můžete mít vy nebo některý z internetových operátorů. Může také pomoci nastavit základní linii pro očekávanou latenci mezi koncovými body.
Zopakujme zde, že časy generované MTR jsou časy zpáteční cesty, kdy paket ICMP dosáhne skoku, ve kterém vyprší jeho TTL, zařízení zpracuje toto vypršení, aby vygenerovalo paket ICMP Time Exceeded, a aby se tento paket vrátil do původní zařízení. Pro mnoho směrovačů má provádění odpovědi ICMP na zahozené pakety nízkou prioritu – a na některých zařízeních je zcela zakázáno.
Z jednoho z těchto důvodů pravděpodobně uvidíte případy, kdy jeden přechodný skok ukazuje občasný skok ve sloupci „Poslední“ nebo „Nejhorší“. Pokud se skok v latenci nerozšíří také do každého následujícího skoku, pak to, co vidíte, je zpoždění od mechanismu odezvy na tomto jednom zařízení, na rozdíl od skutečné latence propustnosti. Vezměte si například následující výstup MTR:
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. vl223-ar-01.nyc-ny.atlantic.net 0.0% 66 0.5 6.1 0.5 140.2 25.5 2. te0-0-1-1.rcr11.ewr04.atlas.cogentco.com 0.0% 66 1.0 1.0 0.8 2.8 0.2 3. te0-3-0-4.rcr21.ewr02.atlas.cogentco.com 0.0% 66 1.1 1.1 0.9 2.5 0.2 4. be2601.rcr24.jfk01.atlas.cogentco.com 0.0% 66 1.6 1.7 1.5 2.0 0.0 5. be2632.ccr42.jfk02.atlas.cogentco.com 0.0% 66 1.7 1.8 1.6 3.0 0.1 6. be2807.ccr42.dca01.atlas.cogentco.com 0.0% 66 8.3 8.1 7.7 12.1 0.6 7. be2113.ccr42.atl01.atlas.cogentco.com 9.1% 66 27.5 21.7 18.6 34.7 3.9 8. be2123.ccr22.mia01.atlas.cogentco.com 0.0% 66 33.0 33.4 33.0 41.5 1.1 9. be2055.ccr21.mia03.atlas.cogentco.com 0.0% 66 33.3 33.6 33.1 36.3 0.4 10. 38.104.95.170 0.0% 65 40.8 40.9 40.7 42.0 0.1 11. 209.208.7.42 0.0% 65 41.6 43.3 40.9 187.9 18.2 12. [target host] 0.0% 65 41.1 41.1 40.9 41.3 0.0
Vidíte, jak první a jedenáctý skok mají nejhorší čas mnohem vyšší, než je jejich průměr? Mnozí se dívají na indikátor, jako je tento, a předpokládají, že představuje důkaz latence propustnosti. Ale všimněte si, že druhý a dvanáctý skok také nevykazují podobně nejhorší čas? Pokud by sloupec nejhoršího času pro každý následující skok ukazoval stejný nebo delší čas, mohli bychom tento výsledek považovat za incident poukazující na potenciální problémy s latencí. Všimněte si naopak sloupce průměrného času, zejména mezi skoky 6 a 7. Průměr skočí z 8,3 milisekund na 21,7 milisekund a každý následující skok má vyšší číslo. Tento sloupec ukazuje příklad skutečné latence, v tomto případě mezi routery ve Washingtonu, DC a Atlantě, GA (tento výsledek je podle standardů roku 2015 docela normální).
Můžete také pozorovat přechodné skoky sporadicky nebo dokonce soustavně zahazovat pakety úplně. Opět platí, že pokud jsou tyto poklesy izolované na jednom zařízení a nejsou konzistentní ve všech následujících skocích, pak je velmi pravděpodobné, že se jedná o příznak toho, že zprávy s odezvou ICMP Time Exceeded jsou vyřazeny z priorit pro důležitější tranzitní provoz (můžete vidět příklad tohoto poklesu ve skoku 7 výše). V některých případech správci sítě konfigurují směrovače tak, aby vůbec neodpovídaly žádnými odpověďmi ICMP Time Exceeded. Můžete vidět, že se tyto skoky projevují jako pokles 100 % provozu, zatímco skoky za ním stále reagují (v prvním příkladu v tomto článku můžete vidět příklad tohoto chování ve skoku 13, který ukazuje 100% ztrátu a nezobrazuje IP hostitele nebo název hostitele).
.
Co dál?
Tento článek je pouze úvodem k tomu, jak můžete pomocí nástroje MTR prozkoumat vaše síťové připojení k různým koncovým bodům na internetu. I když je toho mnoho, co se můžete naučit, zde uvedené informace by vám měly poskytnout dobrý začátek, abyste byli schopni diagnostikovat problémy se sítí, se kterými se můžete setkat. Děkujeme, že jste si přečetli, a znovu se k nám vraťte pro další aktualizace a pokročilejší výukové programy hostování VPS a články jako Co je:Základy sítě – přepínače, směrovače a brány firewall.
Zjistěte více o našich hostingových službách VPS a virtuálních privátních serverech.
.
.