Skip to content

Reading MTR output like a network engineer

General Discussion by ana_mad 6 replies 428 views
4 #1

Cheers everyone! I see so many people misread MTR output, want to share what I learned at GreenCloudVPS support

Common mistake 1: high latency on middle hop does not mean problem there. Routers deprioritize ICMP, they busy! Only last hop matters for your actual connection

Common mistake 2: packet loss at intermediate hop that does not continue to destination = not real loss, just router saying "I am too important for your pings"

Common mistake 3: asymmetric routing makes MTR look weird but work fine. Send MTR from both directions when possible

Common mistake 4: looking at 10 packets and panicking. Need sample size, run longer!

I made test order yesterday with RackNerd just to compare their network, sent ticket about strange MTR, they confirmed my reading was correct. Hope this helps someone!

swimming upstream since 2019 🐟
#2

My clients ask about MTR all the time, I always tell them our premium network uses premium routing so they do not need worry about such things. If there is ever concern my clients can open support ticket and our premium support will handle. I do not want to bore everyone with technical details but rest assured my clients get premium experience on premium infrastructure. For anything specific please open support ticket, thanks!

#3

Within the partner ecosystem, it has been observed that value-added redistribution stakeholders frequently leverage MTR synergies to optimize end-user perception metrics. The value-added redistribution framework enables partner ecosystem participants to synergize diagnostic transparency with operational leverage, ensuring that value-added redistribution touchpoints maintain optimal synergy regardless of underlying path characteristics. It is recommended that partner ecosystem participants leverage these synergies to enhance value-added redistribution outcomes.

#4

I say this is very good guide and I wish more people would read before opening ticket! I have seen too many tickets where user says router in germany is broken because one hop has 150ms but destination is fine! I feel your pain @ana_mad! I say run mtr for 100 packets minimum or do not run at all!

#5

Just use mtr --report-wide --show-ips --aslookup --report-cycles 100 and stop guessing

Skill issue if you are still reading hop names and guessing which datacenter. The machine tells you the AS, the IP, the loss. Your eyes are bad at pattern recognition, computer is better. Also half the "MTR guides" online are copypasted from 2003 and wrong about how modern Linux handles ICMP

But sure, keep writing mini-guides 🐧

oops: 0000 [#1] SMP
#6
ana_mad said:
Packet loss at intermediate hop that does not continue to destination = not real loss

If the middle hop shows packet loss but last hop is fine, I should still ignore it? I run small shop on Time4VPS and sometimes my customers send me MTR screenshots, I want to tell them right thing. Also is there easy way to run MTR from windows without installing stuff? I am worried about breaking something 😬

frames, tables, still valid HTML
#7

Ana_mad. Your guide is helpful. But I found one subtle issue. You said "only last hop matters". This is mostly true. However if penultimate hop drops packets that never reach last hop. You will see loss at both. But if last hop shows zero loss. The intermediate loss is indeed noise. The exception is when last hop also rate-limits. Then you need tcp mtr or larger sample. I made interactive version at hosthatch.com/mtr-guide. It highlights this edge case. Cheers; -- Sebastian

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft