Come interpretare traceroute / output di MTR?

Ho eseguito MTR in / da uno dei miei server e ho notato qualcosa che mi sembra strano. Perché non sono veramente in questo vi darò tre uscite:

Questo è dal server alla mia home location:

My traceroute [v0.75] prag341.server4you.de (0.0.0.0) Sat Apr 16 12:31:36 2011 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. v9-609a.s4y14.fra.routeserver.net 0.0% 143 6.6 2.9 0.7 15.6 2.4 2. 217.118.16.161 0.0% 143 0.7 5.7 0.4 67.3 13.2 3. 217.118.16.25 0.0% 143 3.3 5.3 3.3 63.5 8.6 4. 194.25.211.53 0.0% 143 3.4 5.5 3.2 61.1 9.1 5. vie-sb2-i.VIE.AT.NET.DTAG.DE 0.7% 143 17.8 21.7 17.6 131.1 14.8 vie-sb2-i.VIE.AT.NET.DTAG.DE 6. at-vie05b-ri1-pos-5-0.aorta.net 0.7% 143 18.7 18.4 17.6 23.8 0.9 7. at-vie05b-ri2-ge-2-1-9.aorta.net 0.0% 143 17.9 18.6 17.5 41.7 2.6 8. at-vie01a-rd1-xe-1-0-0.aorta.net 0.0% 143 18.2 21.1 17.3 104.1 12.0 9. at-vie-sk11-pe01-vl-20.upc.at 0.0% 143 18.2 20.6 17.7 55.7 7.0 10. at-vie-sk11-pe02-vl-1.upc.at 0.0% 143 17.8 19.6 17.3 55.2 6.6 11. ??? 

Questo è dalla mia posizione di casa al server:

 My traceroute [v0.80] joe-desktop (0.0.0.0) Sat Apr 16 14:27:54 2011 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.1.1 0.0% 87 0.2 0.2 0.2 0.2 0.0 2. ??? 3. 84.116.4.33 0.0% 86 9.7 9.0 6.3 27.3 3.5 4. at-vie-sk11-cia01-vl-2070.upc.at 0.0% 86 22.7 22.8 20.0 52.2 4.7 5. at-vie-sk11-pe01-vl-2069.upc.at 0.0% 86 47.6 23.9 20.2 47.6 5.8 6. at-vie01a-rd1-vl-2042.aorta.net 0.0% 86 21.7 25.0 20.1 61.7 8.5 7. de-fra03a-rd1-xe-9-2-0.aorta.net 0.0% 86 21.3 22.8 19.6 44.0 5.0 8. 84.116.132.154 0.0% 86 20.2 22.8 19.3 41.0 4.1 9. tge-5-1-0-353a.cr2.fra.routeserver.net 0.0% 86 38.6 27.4 20.9 120.2 16.0 10. 217.118.16.130 0.0% 86 23.7 26.9 20.8 73.0 9.8 11. 217.118.16.26 0.0% 86 25.5 28.8 22.9 85.1 11.8 12. 217.118.16.165 81.2% 86 68.2 37.5 25.0 68.2 10.3 13. prag341.server4you.de 0.0% 86 35.7 27.1 24.0 49.3 4.3 

E questo è da un altro server (amazon ec2) al server:

 My traceroute [v0.75] flimmit.com (0.0.0.0) Sat Apr 16 12:32:50 2011 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. ip-10-48-192-3.eu-west-1.compute.internal 0.0% 178 0.4 0.9 0.3 16.4 1.7 ip-10-48-192-2.eu-west-1.compute.internal 2. ec2-79-125-0-244.eu-west-1.compute.amazonaws.com 0.0% 178 0.5 0.9 0.3 30.8 2.6 ec2-79-125-0-242.eu-west-1.compute.amazonaws.com 3. ??? 4. ??? 5. ??? 6. xe-4-1-0.dub10.ip4.tinet.net 36.5% 178 1.9 3.9 1.6 56.8 8.5 7. xe-4-1-0.dub10.ip4.tinet.net 0.0% 178 12.1 9.7 1.6 92.5 10.5 xe-0-1-0.lon14.ip4.tinet.net xe-2-1-0.lon14.ip4.tinet.net 8. xe-0-1-0.lon14.ip4.tinet.net 0.0% 177 17.4 17.7 11.1 184.3 24.6 xe-2-1-0.lon14.ip4.tinet.net 213.200.77.234 9. 213.200.77.234 0.0% 177 25.2 23.7 12.0 162.5 16.0 tge-4-2-0-0a.cr2.fra.routeserver.net 10. tge-4-2-0-0a.cr2.fra.routeserver.net 0.6% 177 178.6 57.1 24.7 178.6 39.0 217.118.16.26 11. 217.118.16.26 47.2% 177 32.7 61.1 29.1 164.4 35.4 217.118.16.165 12. 217.118.16.165 28.2% 177 28.9 29.8 27.8 48.9 4.2 prag341.server4you.de 13. prag341.server4you.de 1.1% 177 28.2 28.7 27.7 63.4 2.9 

Quello che mi sembra strano è questa perdita molto alta> 80% sull'ultimo salto dalla mia casa al server. Il server sta rispondendo bene ei servizi funzionano senza problemi.

Può essere dovuto alla mancanza di conoscenza della networking, ma sembrerebbe logico per me che i tassi di perdita dovrebbero aumentare? Ma spesso vedo le uscite MTR in cui ci sono tassi di perdita elevati sulla strada, ma la perdita finale è molto inferiore.

Quindi le mie domande sono:

  • Nel mio caso particolare, è questo un indicatore di un ansible problema che dovrei prestare attenzione?

  • In generale, come interpretare correttamente un'output di mtr? Puoi consigliare un buon articolo / letteratura su questo?

  • Perché la perdita di pacchetti dopo che tcpdump ha registrato il pacchetto?
  • Quanto sono comuni pacchetti in comunicazioni all'interno di un data center?
  • Velocità di perdita di pacchetti con iperf e tcpdump
  • Analizzare i rigetti in arrivo di pacchetti TCP su GNU / Linux
  • Maggiore valore rmem_max che port a perdere più pacchetti
  • Estrema perdita di pacchetti UDP a 300Mbit (14%), ma TCP> 800Mbit w / o ritrasmuta
  • enormi perdite di pacchetti e errori di checksum
  • Come monitorare passivamente la perdita di pacchetti TCP? (Linux)
  • 2 Solutions collect form web for “Come interpretare traceroute / output di MTR?”

    La perdita di pacchetti non è necessaria un'indicazione di un problema. Ricordati che questi sono tentativi di comunicare direttamente con quel particolare nodo di networking. Solitamente i nodes di router interconnessi sono responsabili solo per il passaggio di traffik in un'altra posizione. Non sono tenuti a chiacchierare direttamente con te, e uno che scompare la maggior parte della tua chat non dovrebbe essere motivo di preoccupazione. L'unico numero importnte per te sarebbe quanti pacchetti stanno attraversando la tua destinazione .

    Le informazioni più utili da uscire da queste relazioni sono i dati relativi ai nodes distanti (in termini di tempo di pacchetto) e, ancor più, quanti luppoli ci sono in modo da poter avere un'idea di quanto tempo le gambe diverse il viaggio avrà per le persone che cercano di comunicare con i server. Di solito i less luppoli sono, più efficiente il path – indicando la qualità del tuo ISP.

    MTR è buono per misurare la latenza e il luppolo da un sito all'altro. È commmino avere una perdita del 100% a partire dal firewall davanti a un sito raggiungibile. Di solito imposta l'intervallo a 15 secondi o più per alleggerire il carico di networking. Ci vorrà un po 'di tempo per get risultati, ma trovo i risultati più affidabili.

    Alcuni router danno priorità minore alla generazione del pacchetto di errore utilizzato da MTR per rilevare i router intermedi. Se il router è occupato, potrebbe scappare il pacchetto e attendere quello successivo. Ciò causerà elevati tassi di drop per quel router. Se ci sono router più lontano con le perdite di 0% le cose sono bene.

    Le perdite di pacchetti possono anche verificarsi quando le rotte cambiano dynamicmente. L'ultima traccia mostra le rotte che cambiano nel tempo. Le tesi dovrebbero essere relativamente brevi e facilmente recuperate.

    I tassi di perdita possono essere indicativi di un router sovraccaricato. Se ci sono problemi di connessione o di perdita di pacchetti, inizia a indagare al router più vicino con un tasso di perdita superiore a 0%.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.