Поиск причины повторной передачи TCP в локальной сети


25

Привет жителям сервера Fault

У меня раздражающая проблема с локальной сетью из примерно 100 компьютеров, 2 серверов домена Windows и 12 телефонов VoIP. С момента их установки около года назад, каждую неделю или около того, мы замечаем, что телефон VoIP перезагружается сам - иногда во время разговора. Одновременно часто появляются признаки временной потери соединения на компьютерах: зависание в проводнике при доступе к сетевым ресурсам, ошибки в нашем программном обеспечении для администрирования из-за потери соединения с сервером базы данных.

Я проводил мониторинг Wireshark на соединении между УАТС VoIP и остальной частью сети. Wireshark обнаруживает группу повторно переданных TCP-пакетов в то время, когда мы записываем перезапуски телефона. Журнал Wireshark показывает около 2 кластеров повторных передач в день, от 5 пакетов до сотен. Они в каждом кластере находятся в основном между УАТС и некоторым набором телефонов VoIP, но не всегда один и тот же набор. Часто повторные передачи одновременно осуществляются на телефоны, подключенные к одному и тому же коммутатору, но иногда повторные передачи происходят вместе на телефоны на противоположных концах сети. Обычно при передаче TCP-трафика происходят некоторые повторные передачи, например, между клиентскими компьютерами и файловыми серверами.

Пики в повторных передачах и перезагрузках телефона плохо коррелируют с тем, когда сеть сильно загружена. Кажется, что они случаются немного чаще в течение дня, но чаще вечером, когда движение должно уменьшиться. Они происходят достаточно часто поздно ночью, когда большинство компьютеров выключено и трафик должен быть наименьшим.

У вас есть идеи, которые могут помочь диагностировать причину подобных проблем? Одна вещь, которую я еще не попробовал, но должен был, это обновить прошивку всех коммутаторов.


1
Какая модель переключается? Как выглядит статистика процессора, памяти и т. Д.? Вы находитесь на одном широковещательном домене? Как близко к максимальной пропускной способности вы видите в сети?
Зайфер

Какой протокол VoIP вы используете? Кроме того, используя UDP или TCP?
Крис С

Все коммутаторы 3Com: базовая линия 2924 - PWR Plus (3CBLSG24PWR) x 2, 4200 (3C17304A) x 3, 4200 (3C17304) x 2, 2824-SPF Plus (3C16487), 2250 плюс (3C16476CS). Я не думаю, что они дают статистику по процессору или памяти, но я был бы очень рад узнать иначе. Да, мы находимся на одном вещательном домене. Я не знаю о пропускной способности, я буду смотреть на ее измерение.
Сюрреалистический

Ответы:


17

Повторные передачи TCP обычно происходят из-за перегрузки сети. Ищите большое количество широковещательных пакетов во время возникновения проблемы. Если процент трафика широковещания в вашем захвате превышает примерно 3% от общего захваченного трафика, то вы определенно испытываете заторы. Посмотрите на широковещательные рассылки как физического уровня (ARP), так и сетевого уровня (разрешение имен) в сети. Если вы обнаружите большой объем широковещательного трафика, вы можете отследить его до источника по данным захвата.


9
Кроме того, повторные передачи TCP не являются причиной вашей проблемы, они являются симптомом проблемы.
Joeqwerty

Я должен был упомянуть, что я посмотрел на широковещательные рассылки UDP, и они не коррелировали с повторными передачами. Некоторые события повторной передачи совпадают с пиками в широковещательных рассылках UDP, но большинство - нет. Я посмотрел еще раз и обнаружил, что широковещательные рассылки UDP не превышают 1,5% трафика (около 350 пакетов) в любом 10-минутном временном сегменте, и достижение этого уровня происходит редко. Однако я не смотрел эфирные передачи. Сейчас я запускаю скрипт для фильтрации всех моих логов Wireshark. Эмпирическое правило 3% для UDP-трансляций и Ethernet-трансляций индивидуально или в сочетании?
Сюрреалистический

1
3% на самом деле не эмпирическое правило. Это то, что мне сказали, и то, что я видел в моем собственном окружении. Я слышал цифры от 10 до 20%, но обнаружил, что если оно превышает 3–5%, это обычно вызывает проблемы. Вы должны смотреть на весь широковещательный трафик: Ethernet, сеть и многоадресные широковещательные рассылки, поскольку все они могут вызвать перегрузку. По сути, любой трафик, который транслируется на все порты коммутатора, является трафиком, который необходимо проанализировать и уменьшить или устранить.
Joeqwerty

У меня до сих пор нет симпатичного графика, чтобы проверить хорошую корреляцию в течение длительного периода, но трансляции Ethernet выглядят довольно многообещающе. Один журнал, где произошла ретрансляция, имел чуть более 3% широковещательных рассылок, другой - около 6%. По крайней мере, я обнаружил одну проблему: старый сервер выпускает постоянный поток бесплатных ARP-пакетов.
Сюрреалистический

1
Я обнаружил чрезмерные записи ARP с помощью фильтра Wireshark arp- и только для просмотра широковещательных записей - с использованием фильтраeth.addr==ff:ff:ff:ff:ff:ff
mlhDev

2

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

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

Вы можете решить проблему с телефонами путем ограничения трафика. Это просто перенесет проблему на других пользователей.


2

Для меня это звучит как петля связующего дерева или широковещательный шторм, особенно если повторные передачи и проблемы локализованы для одного и того же коммутатора (который отличается). Когда это происходит, каковы состояния порта на вашем устройстве L2? Возможно плохой коммутатор или плохие приоритеты корневого моста? Интересная проблема.


Спасибо, что побудили меня прочитать о покрывающих деревьях, о которых я смущенно ничего не знаю. Однако я не думаю, что это может быть цикл связующего дерева, потому что у нас нет никаких избыточных ссылок в нашей сети (возможно, проблема сама по себе). Под "состояниями портов на вашем устройстве L2" я прав, вы имеете в виду, какие порты были включены коммутаторами в результате алгоритма связующего дерева? Мы не настраивали корневой мост вручную, было бы неплохо сделать это?
Сюрреалистический

Знакомство с STP - хорошая идея, но если вы уверены, что у вас нет лишних ссылок, то STP не будет проблемой.
Joeqwerty

Да, если у вас нет избыточных ссылок, это не будет проблемой. Под состояниями порта, я имею в виду, что вперед / заблокировано / обучение.
МакДжефф

2

Вы, вероятно, решили эту проблему, так как это было так долго, но по сути вам нужно включить «быстрый порт» на портах, которые имеют конечные точки (VoIP-телефоны, рабочие станции, серверы). Телефон может отправлять PDU, поэтому, если этот парень перезагружается, это вызывает сближение STP, в результате чего таблица FDB сбрасывается и все устройства проходят через 4/5 шагов STP. Помещая порты с конечной точкой в ​​«быстрый порт», они пропускают ожидание и переходят прямо в режим пересылки.


1

Надеюсь, ваши телефоны находятся в другой подсети и VLAN от других компьютеров?


Нет, они находятся в одной и той же IP-подсети, и я почти уверен в том же VLAN. Это серьезная проблема? Это, конечно, звучит так, как будто это хорошая идея. Я вижу, что это разделило бы широковещательные домены для телефонов и всего остального. Будет ли у него какие-то другие преимущества?
Сюрреалистический

Да, я бы определенно поставил телефоны на выделенную VLAN.
Грег Аскью

1

Это также может быть неисправное оборудование, например, неисправный выключатель. Ретрансляции соотносятся с телефонами / компьютерами на одном конкретном коммутаторе или части сети?

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

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


Я хотел бы, чтобы они сделали. Похоже, что наибольшие проблемы возникают с устройствами, подключенными к двум коммутаторам, которые находятся на противоположных концах сети. Тем не менее, есть значительные повторные передачи на телефоны в других частях сети.
Сюрреалистический
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.