1270 ответов в теме

[FaNTik]

Логин 604125

[Unearth]

Ошибся, была авария, с 15:13 до  18:45 не работало оборудование на доме.

Логин 604125

[Boris3000]

Засёк вот такие трассировки:

 

  1     1 ms     1 ms         1 ms  213.248.0.28
  2    <1 мс    <1 мс      <1 мс  213.248.7.140
  3     2 ms    <1 мс        1 ms  213.248.3.249
  4     1 ms    <1 мс       <1 мс  213.248.7.90
  5    15 ms    15 ms     15 ms  109.239.137.105
  6    15 ms    16 ms      15 ms  213.239.224.38
  7    36 ms    36 ms      35 ms  213.239.224.166
  8    37 ms     *            54 ms  213.239.252.17
  9     *            138 ms  45 ms  213.239.252.42
 10    40 ms    40 ms     40 ms  213.239.229.134
 11    40 ms    40 ms     40 ms  94.130.204.236

 

  1     1 ms     1 ms     1 ms     213.248.0.28
  2    <1 мс    <1 мс    <1 мс   213.248.7.140
  3     1 ms     1 ms     1 ms     213.248.3.249
  4     1 ms     1 ms    <1 мс     213.248.7.90
  5    15 ms    15 ms    15 ms  109.239.137.105
  6    15 ms    16 ms    16 ms   213.239.224.38
  7    36 ms    36 ms    36 ms   213.239.224.166
  8    36 ms    35 ms     *         213.239.252.17
  9     *             *             *         Превышен интервал ожидания для запроса.
 10    40 ms    42 ms    40 ms  213.239.229.134
 11    40 ms    40 ms    40 ms  94.130.204.236

 

Ист дас ейн проблем ин Дойчляндия или как-то с нами связано? А то последствия этого я наблюдаю только у себя, у чуваков из других стран ситуация как минимум лучше.

[Boris3000]

Сегодня в 0:57 уже ближе и горячее:

 

  1     1 ms      4 ms     1 ms    213.248.0.28
  2    <1 мс     *           <1 мс  213.248.7.140
  3     *            1 ms     1 ms    213.248.3.249
  4     1 ms     <1 мс     *         213.248.7.90
  5    15 ms    15 ms    15 ms  109.239.137.105
  6    16 ms    15 ms    15 ms  213.239.224.38
  7    36 ms    36 ms    36 ms  213.239.224.166
  8    41 ms    63 ms    *         213.239.252.17
  9    46 ms     *            *         213.239.252.42
 10   40 ms    40 ms    40 ms  213.239.229.134
 11   40 ms    40 ms    40 ms  94.130.204.236

 

  1     *            1 ms      3 ms   213.248.0.28
  2    50 ms    <1 мс    46 ms  213.248.7.140
  3     2 ms     1 ms       <1 мс   213.248.3.249
  4    <1 мс    <1 мс     <1 мс   213.248.7.90
  5    15 ms    15 ms    15 ms   109.239.137.105
  6    18 ms     *           16 ms   213.239.224.38
  7    39 ms    37 ms    36 ms    213.239.224.166
  8    36 ms    36 ms    35 ms    213.239.252.17
  9    75 ms    40 ms     *          213.239.252.42
 10   41 ms    40 ms    40 ms    213.239.229.134
 11   40 ms    40 ms    40 ms    94.130.204.236

[Unearth]

Ваша трассировка непоказательна, собирайте статистику утилитой mtr(winmtr) или аналогом. Смотреть стоит только на задержки и количество потерь до последнего хоста (до которого выполняется трассировка), если их нет, результаты на транзитных узлах можно не рассматривать.

Сегодня в 0:57 уже ближе и горячее:

 

  1     1 ms      4 ms     1 ms    213.248.0.28
  2    <1 мс     *           <1 мс  213.248.7.140
  3     *            1 ms     1 ms    213.248.3.249
  4     1 ms     <1 мс     *         213.248.7.90
  5    15 ms    15 ms    15 ms  109.239.137.105
  6    16 ms    15 ms    15 ms  213.239.224.38
  7    36 ms    36 ms    36 ms  213.239.224.166
  8    41 ms    63 ms    *         213.239.252.17
  9    46 ms     *            *         213.239.252.42
 10   40 ms    40 ms    40 ms  213.239.229.134
 11   40 ms    40 ms    40 ms  94.130.204.236

 

  1     *            1 ms      3 ms   213.248.0.28
  2    50 ms    <1 мс    46 ms  213.248.7.140
  3     2 ms     1 ms       <1 мс   213.248.3.249
  4    <1 мс    <1 мс     <1 мс   213.248.7.90
  5    15 ms    15 ms    15 ms   109.239.137.105
  6    18 ms     *           16 ms   213.239.224.38
  7    39 ms    37 ms    36 ms    213.239.224.166
  8    36 ms    36 ms    35 ms    213.239.252.17
  9    75 ms    40 ms     *          213.239.252.42
 10   41 ms    40 ms    40 ms    213.239.229.134
 11   40 ms    40 ms    40 ms    94.130.204.236

[Boris3000]

собирайте статистику утилитой mtr(winmtr)

Какой из них? https://github.com/W...WinMTR/releases

[Boris3000]

Смотреть стоит только на задержки и количество потерь до последнего хоста (до которого выполняется трассировка), если их нет, результаты на транзитных узлах можно не рассматривать.

Вообще, приведённые трассировки -- это результат работы батника, который пингует именно конечный узел и в случае отсутствия в течение двух секунд ответа сразу же делает трассировку. Так тоже не показательно?

[Boris3000]

Сегодняшняя трассировка в 8:19, когда меня чуть не выкинуло сервака:

 

1     1 ms       1 ms       1 ms   213.248.0.28
2     <1 мс     <1 мс     <1 мс  213.248.7.140
3     <1 мс     <1 мс     <1 мс  213.248.3.249
4      6 ms       9 ms      5 ms   213.248.7.90
5     15 ms     15 ms    15 ms  109.239.137.105
6     15 ms     19 ms    16 ms  213.239.224.38
7      34 ms    35 ms    34 ms  213.239.224.166
8      37 ms    34 ms    37 ms  213.239.252.17
9      *             *             *         Превышен интервал ожидания для запроса.
10    39 ms    39 ms    39 ms  213.239.229.134
11    39 ms    39 ms    39 ms  94.130.204.236

[Unearth]

Да, т.к. не виден участок на котором возникают потери, не видно количество потерь.

Вообще, приведённые трассировки -- это результат работы батника, который пингует именно конечный узел и в случае отсутствия в течение двух секунд ответа сразу же делает трассировку. Так тоже не показательно?

 

 

попробуйте mtr-v100-static.zip

 

Какой из них? https://github.com/W...WinMTR/releases

[Boris3000]

Версия 1.00 у меня не взлетела, ни та, ни другая. Поэтому пришлось юзать исходную 0.92.

Статистика за прошедшие сутки:

 Ping.jpg   269,73К   1 Количество загрузок:

 

О чём это нам говорит?

 

В общем-то, картина примерно та же, что и с обычных трассировок. И я так и не понял, в чём смысл сбора усреднённой за длительный период статистики, если меня интересует отлов кратковременного сбоя, длящегося от силы секунд 10, и трассировка именно в момент этого сбоя.

[Unearth]

Это нам говорит о том, что до конечного хоста теряется около 0.13% пакетов, причем потери начинаются с первого узла, более вероятно, на участке от 213.248.0.28 до вашего ПК. 

Чтобы подтвердить это или опровергнуть нужны дополнительные проверки, можно тестировать сразу до нескольких ресурсов, также конечно очень полезной информацией является время, когда потери начинаются.

Можете использовать утилиту pingplotter, она делает аналогичную проверку, только отмечает потери на графике и позволяет удобно посмотреть, когда именно были потери.

При наличии такой статистики с большой вероятностью  я смогу найти проблему на нашей сети, если она есть.

Если у вас есть доступ к 94.130.204.236, вы также можете делать mtr до вашего роуетра/пк и до каких-то адресов из сети РТК, т.к. обратная трасса может отличаться и иногда позволяет увидеть более полную картину.

Версия 1.00 у меня не взлетела, ни та, ни другая. Поэтому пришлось юзать исходную 0.92.

Статистика за прошедшие сутки:

Ping.jpg

 

О чём это нам говорит?

 

В общем-то, картина примерно та же, что и с обычных трассировок. И я так и не понял, в чём смысл сбора усреднённой за длительный период статистики, если меня интересует отлов кратковременного сбоя, длящегося от силы секунд 10, и трассировка именно в момент этого сбоя.

Сообщение отредактировал Unearth: 10 Февраль 2021 - 02:07

[Boris3000]

Если у вас есть доступ к 94.130.204.236

Нет, доступа у меня нет.
 

до конечного хоста теряется около 0.13% пакетов

Это много или мало? Особенно если учесть, что это среднее за сутки.
 

можно тестировать сразу до нескольких ресурсов

Здесь продолжение тестирования целевого сервака, плюс www.yandex.ru и www.google.com:
 Ping2.jpg   183,15К   1 Количество загрузок:

Вроде картина одинаковая?
 

потери начинаются с первого узла, более вероятно, на участке от 213.248.0.28 до вашего ПК

Меня вновь терзают смутные сомнения -- а не всё ли это та же самая проблема с неработающим фулл-дуплексом? На сотке у меня так и вообще всё сыпется, и тестировать ничего не надо, а на гигабите вроде бы нормально, но это на глазок. Я теперь попробую сутки погонять снова на 100 Mbit Half-duplex.
 

Можете использовать утилиту pingplotter

Я буду юзать вот эту версию. Какие-нибудь рекомендации по настройке будут? Программка-то уже не столь простая. Фрагментацию пакетов разрешать, запрещать? И т. д. И в каком виде результаты представлять? Образец какой-нибудь есть?
 

[Unearth]

Это небольшие потери, но если связность полностью теряется на какое-то продолжительное время, то это может быть заметным как раз по разрывам сессий с серверами и т.д.

За последнюю неделю не вижу ни одного падения линка в вашу сторону (кроме перевода на 100 half), лучше верните обратно или тестируйте на 10 или 100 full, на half duplex могут быть дополнительные потери.

Я почти не использовал pingplotter, по-моему может работать без каких-то специфичных настроек. Фрагментация при пакетах ~до 1500байт значения иметь не будет 

Результат - или save sample set  или просто скриншоты, где будут видны потери

В общем в данный момент примерный участок понятен,  больше интересует именно время, когда начинаются потери. pingplotter просто наглядно это рисует на графике.

Нет, доступа у меня нет.
 

Это много или мало? Особенно если учесть, что это среднее за сутки.
 

Здесь продолжение тестирования целевого сервака, плюс www.yandex.ru и www.google.com:
Ping2.jpg

Вроде картина одинаковая?
 

Меня вновь терзают смутные сомнения -- а не всё ли это та же самая проблема с неработающим фулл-дуплексом? На сотке у меня так и вообще всё сыпется, и тестировать ничего не надо, а на гигабите вроде бы нормально, но это на глазок. Я теперь попробую сутки погонять снова на 100 Mbit Half-duplex.
 

Я буду юзать вот эту версию. Какие-нибудь рекомендации по настройке будут? Программка-то уже не столь простая. Фрагментацию пакетов разрешать, запрещать? И т. д. И в каком виде результаты представлять? Образец какой-нибудь есть?
 

Сообщение отредактировал Unearth: 12 Февраль 2021 - 03:52

[Boris3000]

За последнюю неделю не вижу ни одного падения линка в вашу сторону

Так я на падения и не жаловался. Если б были падения, то на панели задач оставалось бы всплывающее сообщение "Провайдер сейчас подключён", но этого нет.
 

лучше верните обратно или тестируйте на 10 или 100 full

Говорю ж, фулл-дуплекс на сотке у меня вообще практически лежит. На десятку переключаться уж совсем как-то неприлично, да и смысла не вижу на ней тестировать -- всё равно я не буду её использовать на постоянной основе. Поэтому остаётся только два варианта -- 100 Half и гигабит, причём гигабит появился лишь с приходом IPoE, а до него я всё время сидел на 100 Half, проблем не было. Но теперь меня выкинуло с сервера и на 100 Half, т. е. и 100 Half и гигабит ведут себя одинаково, значит, проблема не в переключении на гигабит.
Вот статистика на 100 Half (около полутора суток), вроде разницы никакой нет:
 Ping3.jpg   168,89К   0 Количество загрузок:
 
Переключил обратно на гигабит. Ещё один разрыв -- это я ПингПлоттер на свой сервак ставил.
 

save sample set

Что там под сэмплом подразумевается? Единичный ICMP-запрос, что ли?

ЗЫ.
По поводу MTR меня что-то терзают смутные сомнения, по крайней мере, касаемо версии 0.92. Автор явно не дружит с элементарной арифметикой:
1) Если прога запущена в момент недоступности какого-либо узла, то минимальный пинг для этого узла будет показан как 0.
2) Единственный потерянный пакет = 1% потерь для любого количества отправленных пакетов, начиная от 51 и выше.
3) И что уже не настолько очевидно -- радикальное занижение процента потерь при длительной недоступности узла. Дело в том, что прога отправляет следующий пакет лишь в случае получения ответа на предыдущий, а иначе ждёт 5 секунд. В итоге получается, что она пингует недоступный узел лишь раз в 5 секунд, а не так, как указано в настройках, и, соответственно, не с той частотой, с которой она пингует при доступности узла. В моих примерах получается, что она пингует недоступный узел в 10 раз реже, чем доступный, поэтому и количество потерянных пакетов существенно меньше, чем должно быть.
В выше приведённом примере для 94.130.204.236 процент потерь для 9-го узла рассчитан как (35891 - 12833) / 35891 * 100 = 65. А правильно будет вот так: (243094 - 12833) / 243094 * 100 = 95. На самом деле и это не совсем правильно, но уже куда ближе к истине.
 
Да и в остальном они с ПингПлоттером расходятся во мнениях. У обоих стоит размер отправляемых данных 56 байт и частота пингования 1 раз в секунду:

 WinMTR_vs_PingPlotter.jpg   144,36К   0 Количество загрузок:

 

Это я пока сам ПингПлоттер проверял. На сбои поставлю крутиться сегодня в полночь.

[Boris3000]

Запустил на Семёрке WinMTR 1.00 -- там всё то же самое. И если подумать получше, то становится ясно, что "задумчивость" WinMTR при недоступности узла вносит погрешность не только в случаи длительной недоступности, но и во все остальные тоже, за исключением случая полного отсутствия потерь. Всё зависит от случайного распределения интервалов пятисекундной "задумчивости" по периодам доступности и недоступности узла. Соответственно, WinMTR показывает точно лишь одно число потерь -- 0%. Всё остальное -- плюс-минус километр, как бог на душу положит. Но для того чтобы просто оценить, есть ли потери или нет, достаточно штатных виндовых команд, и WinMTR полностью теряет смысл.

WinMTR будет давать точные показания только в том случае, если в настройках период пингования будет кратным 5-ти секундам. Но даже минимальные в этом случае 5 секунд -- это слишком много для отлова кратковременных сбоев, поэтому WinMTR -- в топку.

[Boris3000]

Ну вот, наконец. На скринах -- проблемный участок за вчерашние сутки, а сэмпл-сет -- полный, за все 24 часа. Я там пометил, где меня выкидывало (или почти), но, разумеется, я не торчал на этом серваке все 24 часа, поэтому не факт, что не выкидывало бы и на других участках.

 Ping.zip   2,4МБ   4 Количество загрузок:

Не второй ли узел сбоит?

Сообщение отредактировал Boris3000: 16 Февраль 2021 - 02:03

[Unearth]

Мне не удалось найти никаких проблем на оборудовании. Из семпла я увидел 2 ваших отметки, которые у меня не сопоставляются с потерями. PL до конечного узла 0%.

Я бессилен здесь чем-то помочь, можете продолжать диагностировать дальше (напрямую до разных узлов и т.д) , можете обращаться в саппорт. Локальных проблем при детальном изучении я не обнаружил, массовых жалоб нет. 

Ну вот, наконец. На скринах -- проблемный участок за вчерашние сутки, а сэмпл-сет -- полный, за все 24 часа. Я там пометил, где меня выкидывало (или почти), но, разумеется, я не торчал на этом серваке все 24 часа, поэтому не факт, что не выкидывало бы и на других участках.

Ping.zip

Не второй ли узел сбоит?

[Boris3000]

Из семпла я увидел 2 ваших отметки, которые у меня не сопоставляются с потерями. PL до конечного узла 0%.

Не понял. Ноль потерь только на моей средней отметке, где я написал, что ЧУТЬ не выкинуло. А на двух других -- где именно выкинуло -- конечный узел был полностью недоступен по 20 секунд, что прекрасно видно по высоченным красным пикам на этих отметках:

 Ping5.jpg   327,32К   0 Количество загрузок:

 

Отметки ставятся вручную и стоят, естественно, приблизительно, а не с точностью до секунды.

 

И что со вторым узлом? Явную корреляцию между моими отметками и подпрыгиванием пинга с джиттером на нём только слепой не заметит. Сегодня был ещё один мощный красный выброс на конечном узле, и снова совпадающий с данными явлениями на втором узле.

Сообщение отредактировал Boris3000: 17 Февраль 2021 - 12:13

[Unearth]

Да, там где вы отмечаете, что вас выкинуло, видны потери на последних 2 хопах, при этом на предыдущих хопах потерь нет, т.е. выходит что потери или в сети hetzner или на обратной трассе, не в сети РТК.

Задержки-потери только на транзитных узлах связаны с низким приоритетом на обработку icmp, на конечном узле таких проблем нет.

 

 

 

Не понял. Ноль потерь только на моей средней отметке, где я написал, что ЧУТЬ не выкинуло. А на двух других -- где именно выкинуло -- конечный узел был полностью недоступен по 20 секунд, что прекрасно видно по высоченным красным пикам на этих отметках:

Ping5.jpg

 

Отметки ставятся вручную и стоят, естественно, приблизительно, а не с точностью до секунды.

 

И что со вторым узлом? Явную корреляцию между моими отметками и подпрыгиванием пинга с джиттером на нём только слепой не заметит. Сегодня был ещё один мощный красный выброс на конечном узле, и снова совпадающий с данными явлениями на втором узле.

Сообщение отредактировал Unearth: 17 Февраль 2021 - 05:11

[Unearth]

Хотя, если нажать непосредственно на отмеченный красным участок, в поле current выдает ERR уже между 4 и 5 хопом, это аплинк и на нем никаких проблем я не вижу. Для теста зароутил 94.130.204.236/32 через другой аплинк, поскольку на нашей сети проблем я не нашел, это единственное, что можно сделать, потестируйте, будут ли изменения. 

Прикрепленные файлы

•  Снимок.JPG   142,65К   0 Количество загрузок:

Сообщение отредактировал Unearth: 17 Февраль 2021 - 05:26

[Boris3000]

Задержки-потери только на транзитных узлах связаны с низким приоритетом на обработку icmp

Это знание настроек конкретных транзитных узлов или гипотеза общего порядка? И может, тогда имеет смысл в настройках выставить UDP или TCP Packets вместо ICMP?

 

А вообще, для приложений реального времени необязательны именно потери, чтоб начали возникать проблемы -- достаточно задержкам подскочить, скажем, до 500 мс (настоящим, а не только на ICMP), чтоб начались глюки или даже выкидыши.

[Unearth]

Это знание настроек и общей практики. Есть смысл потестировать через udp. tcp, как мне кажется, стоит использовать, если есть подозрение именно на проблемы с прохождением tcp 

Я не вижу какой-то явной проблемы в нашей сети, сообщите после проверки изменилась ли ситуация в лучшую сторону после изменения маршрута, если да, то временно оставлю так, если нет, верну как было. 

Если используете еще какой-то ip из сети hetzner можете сравнить результаты до него с результатами до 94.130.204.236

Это знание настроек конкретных транзитных узлов или гипотеза общего порядка? И может, тогда имеет смысл в настройках выставить UDP или TCP Packets вместо ICMP?

 

А вообще, для приложений реального времени необязательны именно потери, чтоб начали возникать проблемы -- достаточно задержкам подскочить, скажем, до 500 мс (настоящим, а не только на ICMP), чтоб начались глюки или даже выкидыши.

Сообщение отредактировал Unearth: 17 Февраль 2021 - 09:37

[Boris3000]

и общей практики

А, неполная индукция -- королева познания. Но не надо забывать, что она не есть стопроцентно надёжная штука.
 

если есть подозрение именно на проблемы с прохождением tcp

Не факт, что TCP. Возможно, что UDP. Но уж точно не ICMP, поэтому вообще выглядят странными все эти сканирования ping-ом, когда всегда можно возразить, что это, дескать, не реальные задержки, а просто приоритет у ICMP низкий. Какая-то больно шаманская "методология".
 

Если используете еще какой-то ip из сети hetzner можете сравнить результаты до него с результатами до 94.130.204.236

Нет, не использую (или просто не знаю), хотя можно взять любой от балды. Но знаю, что других, использующих этот же сервер, не выбрасывает. По крайней мере, единомоментно со мной. Поэтому с вероятностью 99% дело именно в другом маршруте.
 

ообщите после проверки изменилась ли ситуация в лучшую сторону после изменения маршрута

ОК, пойду мытарствовать дальше.

[Boris3000]

У меня сейчас опять смена маршрутизации произошла -- с 14 до 15 часов поменялись узлы 2, 3 и 7. Это оно само?

[R_E_M]

Вот в упор не понимаю...

Почему когда я идентифицировал себя на 1 линии и назвал причину звонка как "отсутствие линка" меня заставляют подключить ноутбук, вместо роутера? После чего меня опять идентифицируют на 2 линии, после чего мне изволят сообщить что авария маштаба дома.

 

Ваши сотрудники всерьез полагают что после того как я проверил свой участок линии, прозвонил его lan тестером, проверил работоспособность портов роутера и попробовав другой роутер на всякий случай у меня волшебным образом появится линк если я подключу ноут или комп?

 

Почему сразу не сказать - юбилейный 6 авария, сделаем примерно тогда то?