MTR: netwerkroutes en pakketverlies testen
Auteur: Redactie Domeny.ForSale Gepubliceerd
Kort samengevat: MTR, oftewel My Traceroute, is een hulpmiddel voor netwerkdiagnose dat de route van pakketten onderzoekt en herhaaldelijk de vertraging en het uitblijven van antwoorden meet. In Linux helpt het vaststellen of een verbindingsprobleem al in het lokale netwerk ontstaat of verderop op weg naar de server. De belangrijkste regel bij het interpreteren: als één router niet antwoordt, betekent dat nog niet dat hij verkeer naar de bestemming laat vallen.
Hoe werkt MTR en wat is het verschil met ping?
ping controleert of de opgegeven host antwoordt en meet hoelang het duurt voordat een antwoord binnenkomt. traceroute toont de opeenvolgende knooppunten op de route naar de bestemming. MTR combineert deze functies: het brengt de route in kaart en verstuurt herhaaldelijk testpakketten, waarbij het de resultaten per knooppunt bijwerkt.
Een knooppunt, ook wel een hop genoemd, is meestal een router die pakketten doorstuurt. MTR detecteert deze apparaten door de TTL, de limiet voor het aantal hops van een pakket, stapsgewijs te verhogen. Wanneer die limiet is bereikt, kan de router een bericht terugsturen waarmee zijn adres te achterhalen is.
De meting toont de reistijd van het testpakket en het antwoord, niet alleen de vertraging tussen twee aangrenzende routers. De terugweg kan verschillen van de route naar de bestemming. Daardoor is uit het rapport niet altijd eenduidig af te leiden waar een storing zit.
Installatie en eerste test in Linux
Op Debian en Ubuntu kun je de tekstversie van het hulpmiddel doorgaans installeren met deze opdrachten:
sudo apt update
sudo apt install mtr-tiny
In andere distributies kan het pakket anders heten; vaak is de naam mtr. Controleer dit in de documentatie van de distributie of via de zoekfunctie van je pakketbeheerder.
Je start een interactieve test door een IP-adres of hostnaam op te geven:
mtr 1.1.1.1
De resultaten worden bijgewerkt totdat je de test beëindigt, bijvoorbeeld met de toets q. Het adres 1.1.1.1 dient hier om de verbinding met een publieke bestemming te testen. Onderzoek je een specifieke dienst, test dan vooral de host van die dienst.
Om resultaten op te slaan en te delen is een rapport met een vast aantal meetcycli handiger:
mtr -r -w -c 100 -n 1.1.1.1
De optie -r schakelt de rapportage in, -w maakt de uitvoer breder, -c 100 stelt 100 meetcycli in en -n voorkomt dat IP-adressen worden omgezet naar hostnamen. Meldt het programma dat het geen rechten heeft om testpakketten te versturen, controleer dan de configuratie van het pakket. Afhankelijk van de installatie moet je het mogelijk starten met sudo.
De kolommen van het rapport lezen
Elke rij beschrijft een gedetecteerd knooppunt. Dit zijn de nuttigste kolommen:
| Kolom | Betekenis |
|---|---|
Loss% | Percentage testpakketten waarop geen antwoord is ontvangen |
Snt | Aantal verstuurde testpakketten |
Last | Responstijd van het laatst ontvangen antwoord |
Avg | Gemiddelde responstijd |
Best / Wrst | Kortste en langste responstijd |
StDev | Maat voor de variatie in responstijden |
De tijden worden meestal in milliseconden weergegeven. Een hoge waarde voor Wrst bij een laag gemiddelde kan wijzen op een eenmalige piek in de vertraging. Een hoge StDev wijst op wisselende meetresultaten, maar zegt op zichzelf niets over de oorzaak.
Beoordeel de verbinding niet op basis van slechts enkele testpakketten. Verzamel bijvoorbeeld 100 meetcycli terwijl het probleem optreedt en vergelijk die vervolgens met een meting op een moment dat de dienst goed werkt.
Wanneer ontbrekende antwoorden op een probleem wijzen
Routers kunnen diagnostische antwoorden beperken of die een lagere prioriteit geven dan het doorsturen van verkeer. Daarom is Loss% voor een tussenliggend knooppunt niet automatisch een maat voor het verlies van gebruikerspakketten.
Een voorbeeld: bij het vierde knooppunt ontbreekt 70% van de antwoorden, maar bij alle volgende knooppunten, inclusief de bestemming, is dat 0%. Zo’n resultaat wijst doorgaans op een beperking van de antwoorden door de vierde router, niet op verlies van het doorgestuurde verkeer. De pakketten bereiken immers de apparaten verderop.
Zorgwekkender is het als antwoorden vanaf een bepaald punt ook bij de volgende knooppunten en de bestemming uitblijven. Dat is aanleiding voor verder onderzoek, maar geen bewijs dat een specifieke router de oorzaak is: verschillende routes, filtering en de manier waarop testpakketten worden verwerkt kunnen het resultaat beïnvloeden.
Interpreteer vertragingen op dezelfde manier. Als één router langzaam antwoordt en de volgende snel, bewijst de hoge responstijd van die ene router niet dat de hele verbinding traag is. Ook ontbrekende antwoorden, aangegeven met ???, betekenen niet noodzakelijk dat de route onderbroken is.
Wat controleren bij problemen met een website?
De standaardtestpakketten van MTR gebruiken ICMP, een protocol dat onder meer voor diagnostische berichten wordt gebruikt. Het netwerk kan deze pakketten anders behandelen dan websiteverkeer. Bij problemen met HTTPS kan een TCP-test op poort 443 nuttig zijn:
mtr -r -w -c 100 -n --tcp -P 443 example.com
Vervang example.com door de host van de dienst die je onderzoekt. Ook deze test meet niet het laden van de pagina, de TLS-onderhandeling of de werking van de applicatie. Een MTR-rapport zonder afwijkingen sluit dus problemen met DNS, de webserver of de database niet uit.
Als de host zowel IPv4- als IPv6-adressen heeft, kun je tests met de opties -4 en -6 vergelijken. Voeg bij een melding aan de beheerder het rapport toe, samen met het tijdstip van de meting inclusief tijdzone, de geteste bestemming en een beschrijving van het waargenomen probleem. Verwijder vóór publicatie adressen of namen die informatie over de private infrastructuur prijsgeven.
Zie ook: Wat is ping?
Lees ook
