MTR, förkortning av My Traceroute är ett litet smidigt verktyg som kombinerar vanliga ping och traceroute till ett effektivt verktyg för felsökning av anslutningar. MTR är licensierat under GNU GPL och finns för både Linux, FreeBSD, OpenBSD och Windows. I Debian installeras MTR med apt-get install mtr, i FreeBSD med pkg install mtr och i OpenBSD med pkg_add mtr. MTR finns både med och utan ett GUI.

Använda MTR

Man kan köra MTR både i interaktivt läge och i rapportläge. Kör man MTR i interaktivt läge får man en live-vy som uppdateras en gång per sekund. Detta kan vara användbart om man vet att nätverket brukar strula vid vissa tidpunkter på dygnet. Då kan man starta en MTR med live-vy och hålla kolla på vilken router det är på vägen som är problemet. För att köra MTR med live-vy starta programmet med hostnamnet eller IP-adressen som du vill testa mot, utan några argument, till exempel mtr testserver1.example.com.

Vill du hellre testa anslutningar vid vissa tidpunkter kan du istället köra MTR i din crontab och låta cron-demonen e-posta resultatet till dig. Jag hade ett sådant scenario för några månader sedan själv där jag visste att en viss server tappade anslutning varje förmiddag mellan kl. 9 och 12. Däremot tappade den bara anslutningen till vissa delar av internet, den gick fortfarande att nå från andra VPS-leverantörer men inte min egna. För att hitta vad som gick fel på vägen satte jag upp en crontab som liknar denna här nedan.

25 09 * * * /usr/bin/mtr -4 -c 500 --report testserver1.example.com

Detta körde MTR varje dygn kl. 09:25 mot servern testserver1.example.com. Argumentet -4 betyder att vi vill använda oss av IPv4, och inte IPv6 (i mitt fall fungerade IPv6 utmärkt, men inte IPv4). Argumentet -c 500 betyder att vi ska göra 500 tester, eller 500 pings. --report betyder att programmet inte ska visa någonting förrän körningen är klar. I det här fallet då, i vår crontab betyder det att så fort MTR är klar, skickas all output till min e-post. Mycket smidigt!

Exempel

Körningen ovan såg ut ungefär som nedan, med vissa modifikationer.

HOST: rattranta.nu                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- testserver2.example.com    0.0%    10    0.8   2.3   0.3  18.1   5.5
  2.|-- 138.197.250.154            0.0%    10    0.4   0.4   0.3   0.6   0.0
  3.|-- de-cix.openpeering.nl      0.0%    10    0.4   1.5   0.3   7.8   2.2
  4.|-- telecity-cr.openpeering.n  0.0%    10    2.8   3.6   0.8  10.0   3.5
  5.|-- nikhef-cr.openpeering.nl  70.0%    10    8.2   7.0   6.3   8.2   1.0
  6.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

Här kan vi se att nikhef-cr har packetloss på 70% av någon anledning från just den maskinen jag körde MTR ifrån. Att den sista destinationen har 100% packetloss behöver inte nödvändigtvis tyda på att något är fel på den maskinen ifråga. Går det fortfarande att nå maskinen kan det vara så att den blockerar vissa typer av ICMP-paket eller dylikt.

Det grafiska interfacet visar även det en live-vy utav vad som händer. Här nedan visas ett litet lokalt laborationsnätverk jag testade MTR i.

Här ovan ser vi att allting flyter på som det ska, utan några packetlosses någonstans på vägen fram till destinationen.