Как определить почему возникают кратковременные большие задержки в локальной сети?

Question

[TheBigBear]

Здравсвтуйте
Имеем такой пинг с любого устройства в одном сегменте гигабитной локальной сети (20 компов)

Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время=304мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время=1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время=1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время=157мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время=9мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время=6мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время=79мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время=135мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<1мс TTL=255
Ответ от 192.168.22.13: число байт=32 время<190мс TTL=255

Т.е. в сети есть какие-то задержки.
При копировании файлов это хорошо видно (кратковременные замирания)
Как можно вычислить - почему это происходит?

Comments

[Drno]

всё кабелем подключено?
возможно какой то из "центральных" патч кордов глючит... или порт

[TheBigBear]

Drno, Всё кабелем, у всех гигабит. Кабеля уже лет пять не трогал
Началось недавно, и только в одном сегменте
При казачке по сети большого файла скорость около 70 Мбайт/с, но видны на графике периодические кратковременные провалы
За этот участок отвечает коммутатор TP-Link TL-SG3424
Я бы конечно подключил коммутатор Mikrotik и посмотрел бы Torch-ем - но увы - свободного нет

[Drno]

TheBigBear, проверьте физику, прозвонкой мож провода, смените порт на свитче
Ну и другой свитч...

Тут надо именно тестить, так никто не скажет

Но разговорите что проблема именно при передаче большого файла- то я бы проверчюял первым делом свитч

[Akina]

Имеем такой пинг с любого устройства в одном сегменте гигабитной локальной сети (20 компов)

Это пинг за пределы коммутатора, или то же наблюдается и между двумя подключенными к нему узлами?
Наблюдаются ли такие же затыки при пинге адреса внутреннего интерфейса коммутатора?

Посмотрите настройку Port Edge, BPDU Protection и Loopback Detection по портам.
Вообще посмотрите попристальнее на STP и роли портов - вот такие равномерно-периодические зависы характерны для регулярных перестроек схемы в (R)STP, при этом сам источник проблемы может быть даже за пределами сегмента, хотя и рядом, в 1-2 хопах.

[TheBigBear]

Всем спасибо!
Банальная перезагрузка коммутатора по питанию решила проблему. Теперь пинг ровный.
Конечно, хотелось бы знать что происходило.... но лучше я без этого отпуск догуляю....

Answer 1

[Руслан Федосеев]

сеть управляемая надеюсь? графики портов и смотрите, что где происходит.

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

Comments

[TheBigBear]

Спасибо, но "служба на винде не причем" так как такие пинги были у всех в сегменте
Проблему решил перезагрузкой коммутатора по питанию

Answer 2

[Alexander]

На сколько помню, то ICMP пакеты имеют низкий приоритет и при загруженности сети это может сказываться на задержке пакетов. На это не стоит особо обращать внимание.

Comments

[TheBigBear]

Думаю что всё-таки стоит
Сотрудников этого сегмента сети при работе по RDP раздражают микрозадержки каждую 2-3 секунды

[mayton2019]

TheBigBear, а по мне - вполне себе приличный график. Задержку в 0.1 секунды обычно пользователь не замечает.

Самым капризным пользователям в качестве исключения - можно приложение поставить локально. Пускай наслаждаются. Надеюсь там у них не будет кажущихся задержек.

Гарантировать константный лаг - почти невозможно в современных цифровых реалиях. У меня даже кроссовер-линк между двумя компами такое не обеспечивал. Мдя.

Answer 3

[Станислав Бодро́в]

Wireshark в помощь