Как интерпретировать traceroute / вывод MTR?
Я запускал MTR с одного из моих серверов и заметил что-то странное для меня. Поскольку я не очень в этом, я дам вам три вывода:
Это от сервера до моего дома:
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. ???
Это из моего дома на сервер:
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
И это с другого сервера (amazon ec2) на сервер:
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
Что выглядит странно для меня, так это очень высокая потеря>80% при последнем переходе с моего домашнего местоположения на сервер. Сервер отвечает нормально, а службы работают нормально.
Это может быть связано с тем, что я недостаточно хорошо разбираюсь в сетевых технологиях, но для меня было бы логичным, чтобы показатели потерь составляли? Но я часто вижу результаты MTR, где на пути высокие потери, но конечная целевая потеря намного ниже.
Итак, мои вопросы:
В моем конкретном случае это индикатор возможной проблемы, на которую я должен обратить внимание?
В целом, как правильно интерпретировать вывод mtr? Можете ли вы порекомендовать хорошую статью / литературу по этому поводу?
2 ответа
Потеря пакета не является обязательным признаком проблемы. Помните, что это попытки связаться с этим конкретным сетевым узлом напрямую. Обычно эти промежуточные узлы маршрутизатора отвечают только за передачу трафика в другое место. Они вообще не обязаны общаться с вами напрямую, и тот, который отбрасывает большую часть вашего чата, не должен вызывать беспокойства. Единственный важный для вас номер - сколько пакетов проходит до пункта назначения.
Наиболее полезная информация для этих отчетов - это относительные данные о том, как далеко друг от друга находятся узлы (с точки зрения времени пакета), и, что еще более важно, сколько существует прыжков, чтобы вы могли понять, как долго разные ноги путешествие займет тех, кто пытается общаться с вашими серверами. Обычно чем меньше прыжков, тем эффективнее маршрут - что указывает на качество вашего провайдера.
MTR хорош для измерения задержки и хопов от сайта к сайту. Обычно 100% потерь начинаются с брандмауэра перед доступным сайтом. Я обычно устанавливаю интервал в 15 секунд или больше, чтобы облегчить нагрузку на сеть. Это займет немного больше времени, чтобы получить результаты, но я считаю, что результаты являются более надежными.
Некоторые маршрутизаторы отдают более низкий приоритет генерации пакета ошибок, который MTR использует для обнаружения промежуточных маршрутизаторов. Если маршрутизатор занят, они могут отбросить пакет и ждать следующего. Это приведет к высокой частоте выпадения для этого маршрутизатора. Если есть маршрутизаторы дальше с потерей 0%, все в порядке.
Потери пакетов также могут возникать при динамическом изменении маршрутов. Ваш последний след показывает, что маршруты меняются со временем. Тезисы должны быть относительно краткосрочными и легко восстанавливаемыми.
Показатели потерь могут указывать на перегруженный маршрутизатор. Если возникают проблемы с подключением или потерей пакетов, я начинаю расследование на ближайшем маршрутизаторе с коэффициентом потерь выше 0%.