Pakketverlies vinden met MTR, en het correct lezen

Installatie

apt install -y mtr-tiny     # Debian
dnf install -y mtr          # AlmaLinux

Voer het correct uit

mtr -rwbc 200 <destination>

• -r reportmodus, zodat het een bruikbaar resultaat oplevert dat je kunt plakken
• -w brede uitvoer, zodat lange hostnamen overleven
• -b toon de naam en het adres van elke hop
• -c 200 tweehonderd cycli, ongeveer drie en een halve minuut, en het verschil tussen bewijs en een anekdote

Tien pakketten bewijzen niets. Als een run van tien cycli verlies toont, draai dan tweehonderd cycli voordat je er conclusies uit trekt.

Lees eerst de laatste hop

Routers geven pakketten gericht aan zichzelf een lagere prioriteit. Een transitrouter die honderden gigabits verwerkt, beantwoordt je probes met verlopen TTL als er een cyclus over is en laat ze vallen als dat niet zo is. Dat creëert verlies in het midden van je rapport, terwijl elk pakket waar het je om gaat onbeschadigd aankomt.

Twee regels dekken de meeste rapporten:

1. Verlies op hop zeven dat ontbreekt op hop acht en daarna, is een snelheidslimiet. Negeer het.
2. Verlies dat begint op hop zeven en doorloopt tot de bestemming, is echt, en de hop waar het begint is waar je moet kijken.

Latentie gedraagt zich hetzelfde. Een hop die tachtig milliseconden toevoegt en vervolgens verkeer overdraagt aan de volgende hop op het vorige niveau, antwoordt langzaam, niet doorsturen langzaam.

ICMP is niet jouw verkeer

Als de dienst op TCP draait, test dan op TCP:

mtr -rwbc 200 --tcp --port 443 <destination>

Netwerken die ICMP hard beperken, laten TCP vaak ongemoeid. Het omgekeerde geval is de moeite waard om te ontdekken voordat je iemands netwerk de schuld geeft: een firewall die vrolijk antwoordt op ping en de poort blokkeert waar je gebruikers daadwerkelijk naartoe gaan.

Beide richtingen, elke keer

Routering is eerder asymmetrisch dan niet. Het pad van jou naar ons is niet het pad van ons naar jou, en een rapport van één kant beschrijft precies één van beide. Voer MTR uit vanaf de instantie richting de klant en vanaf de klant richting de instantie, en voeg beide toe. Onze helft van het pad kan ook zonder shell worden getest, via de looking glass.

Bevestig het met de TCP-counters

MTR beschrijft het pad. De socketstatistieken beschrijven het gevolg:

ss -ti state established
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Een retransmissiepercentage boven ongeveer een procent, op een verbinding die schoon zou moeten zijn, ondersteunt het rapport. Nul retransmissies naast een MTR vol verlies betekent dat je naar een snelheidslimiet kijkt en niets anders.

Wat ons te sturen

• Beide MTR-rapporten, tweehonderd cycli, als tekst en niet als screenshot
• Bestemming, transport en poort
• Tijdstempels met een tijdzone, en of het verlies constant is of in bursts
• Het instantie-ID

Ongeveer de helft hiervan blijkt een beperkte tussenhop te zijn, en dat zeggen we in het eerste antwoord. De rest kunnen we meestal binnen het uur omleiden: verlies binnen ons eigen netwerk is ons probleem, en verlies in één transitpad is een kwestie van je verkeer naar een ander pad verplaatsen.