MTR et nettverksdiagnostisk verktøy
Artikkelen beskriver arbeidet med MTR, gir noen eksempler på kommandolinje og forklarer dataene den genererer. Til slutt, gitt utdataene, utfører vi rapportanalyse.
Hvordan fungerer MTR?
Nettverksdiagnostiske verktøy, for eksempel Ping, Traceroute og MTR undersøker forbindelsen mellom to enheter med ICMP -pakker for feilsøking av nettverkstilkobling. Mens ping-verktøyet bruker ICMP ECHO_REQUEST og ECHO_REPLIES, bruker sporte og MTR ICMP-pakker med tid-til-live TTL TTL TTL.
For hop-to-hop-analyse, til å begynne med, etablerer MTR adresser til brytere, gateways og rutere mellom de lokale og eksterne enhetene. Deretter bruker den ICMP -pakkene med TTL for å pinge hvert hopp slik at TTL kontrollerer nodene pakken vil nå før de dør. Derfor sender den en serie ICMP ECHO_REQUEST med TTL satt til en, to, tre, og så videre til MTR samles hele ruten.
Ovennevnte prosessutgangsstatistikk som inneholder tilleggsinformasjon, for eksempel Hop State, Network Connection, Node Responsivity, Network Latency og Jitter. Mest interessant er det likt toppkommandoen, da det holder seg forfriskende med sanntids nettverkstilkobling.
MTR -installasjon
Som standard lever verktøyet i /bruker/sbin Katalog når det kommer forhåndsinstallert med de fleste distribusjoner. Hvis det ikke er tilgjengelig, installer MTR Med distribusjonens standardpakkebehandler.
For Ubuntu:
ubuntu@ubuntu: ~ $ sudo apt -get -y installer mtr
For RHEL:
ubuntu@ubuntu: ~ $ sudo yum -y installer mtr
For Arch:
ubuntu@ubuntu: ~ $ sudo pacman -y installer mtr
Generere og lese live MTR -rapporter
Som vist på skjermbildene over, bortsett fra å oppgi nettverkshop, holder MTR også oversikt over latensen. Med andre ord, det estimerer også tur / retur -tiden fra den lokale maskinen til hver enhet på banen.
For en bedre ide, bruk -rapportflagget til å generere en rapport som utgjør statistikk angående nettverkskvalitet. Brukere kan også bruke dette med alternativet -C, da det bare vil kjøre for antall sykluser som er spesifisert av IT og avslutte etter å ha skrevet ut statistikk.
ubuntu@ubuntu: ~ $ sudo mtr -r -c 5 google.com
Den forrige skjermbildet gir ut flere felt/kolonner for å få tilgang til nettverkstrafikk. Disse kolonnene rapporterer følgende statistikk:
- %Tap: Prosenttapsprosent ved hver maskin
- SNT: Antall sendte pakker
- Siste: Tur / retur -tiden for den siste Traceroute -pakken
- Avg: Gjennomsnittlig tur / retur for alle sonder
- Beste: Korteste tur / retur av en pakke til en bestemt vert
- Wrst: Lengste tur / retur tid for en pakke til en vert
- Stdev: Standardavvik for latenser
De SNT til Wrst Kolonner måler latenser i millisekunder, men bare Avg kolonnen betyr mest. Den eneste ulempen for å generere rapporter for nettverkskvalitet er at den bruker mye nettverkstrafikk som forringer nettverksytelsen.
Nyttige alternativer
Følgende avsnitt inneholder noen av de mest nyttige MTR -flaggets kommandoeksempler. Vi vil forklare outputdetaljene i MTR -rapportleseksjonen senere.
IPv6: MTR bruker IPv6 som standardalternativ, som krever inkludert IP -adressen eller domenenavnet til destinasjonsverten som et argument. Den vil vise en sanntidsutgangspresse Ctrl+C eller Q for å avslutte:
ubuntu@ubuntu: ~ $ sudo mtr google.com
eller
ubuntu@ubuntu: ~ $ sudo mtr 8.8.8.8
KUN IPV4: IPv4-bryteren (-4) viser bare IPv4-adresser og inkluderer fullt kvalifiserte domenenavn:
ubuntu@ubuntu: ~ $ sudo mtr -4 google.com
b For å vise både domenenavn og IPv4 -adresser, bruk -B -flagget som følger:
ubuntu@ubuntu: ~ $ sudo mtr -b google.com
c: Som diskutert tidligere, begrenser flagget antall pinger som ble sendt til hver maskin. Etter å ha fullført antall pinger, stopper det liveoppdateringen og går ut MTR like etterpå:
ubuntu@ubuntu: ~ $ sudo mtr -c7 google.com
T/U: Bytt ut ICMP Echo -pakker med TCP Syn -T/-tcp eller UDP -datagrammer -u/-udp:
ubuntu@ubuntu: ~ $ sudo mtr - -tcp google.com
eller
ubuntu@ubuntu: ~ $ sudo mtr --dp google.com
o: Ordne utgangsfeltet i henhold til ditt krav. For eksempel viser den gitte kommandoen utgang på følgende måte:
ubuntu@ubuntu: ~ $ mtr -o "lsd nbaw jmxi" 8.8.8.8
m: Spesifiser humlen mellom den lokale verten og ekstern maskin. Følgende eksempler angir humle til 5, mens standardverdien er 30:
ubuntu@ubuntu: ~ $ mtr -m 5 8.8.8.8
s: Undersøk nettverket ved å spesifisere ICMP -pakkestørrelse, inkludert IP/ICMP -overskrifter i byte:
ubuntu@ubuntu: ~ $ mtr -s packetSize -c 5 google.com
Rapportanalyse
MTR Output Report Analyse utgjør hovedsakelig eller er fokusert på pakketap og nettverksforsinkelse. La oss diskutere hver av disse i detalj:
Pakketap
MTR -rapporten genererer en prosentandel av pakketapsfeltet ved hvert hop for å indikere et problem. Imidlertid har tjenesteleverandører en felles praksis med rate-limit MTR ICMP-pakker som gir en illusjon av pakketap, noe som ikke er sant. For å identifisere om pakketapet faktisk skyldes hastighetsbegrensende eller ikke, legg merke til pakketapet av det påfølgende hoppet. Som i skjermbildet over, for -o flaggeksempel, vi observerer et pakketap av 16.7% ved hop 5 og 6. Hvis det ikke er noen pakketap ved neste enhet, resulterer det på grunn av hastighetsbegrensende.
I et annet scenario, hvis rapportene representerer forskjellige mengder tap ved start påfølgende humle og de senere få enhetene viser den samme pakketapsprosenten, skyldes tapet ved de første maskinene begge faktorene: hastighetsbegrensende og faktisk tap. Derfor, når MTR rapporterer om forskjellige pakketap ved forskjellige humle, stoler du på tapet ved de senere humle.
Nettverksforsinkelse
Latensen til et nettverk øker med antall humle mellom to endepunkter. Latens avhenger imidlertid også av nettverkstilkoblingskvaliteten mellom de lokale og eksterne maskinene. For eksempel viser oppringingstilkoblinger høyere latens enn kabelmodemer.
Det er også viktig å merke seg at nettverksforsinkelse ikke innebærer en ineffektiv rute. Uavhengig av den høye nettverksforsinkelsen ved forskjellige noder, kan pakker nå destinasjonen og gå tilbake til kilden med null tap.
I eksemplet over observerer vi et hopp i latens fra det 8. hoppet og utover, men ingen pakke gikk tapt bortsett fra på destinasjonsverten.
Konklusjon
Å forstå det grunnleggende om MTR er nødvendig for å ta tak i og finne ut de vanligste nettverkstilkoblingsproblemene, for eksempel feil konfigurasjon av ISP/Residential Router og Destination Host -nettverk, timeouts og ICMP -hastighetsbegrensning. Artikkelen bygger en grunn for en nybegynnerbruker for å forstå bruken og arbeidet med MTR. Den viser også hvordan man genererer MTR-rapporter og utfører analyse for å identifisere hastighetsbegrensende relaterte pakketapsproblemer og analysere nettverksforsinkelse.