Рвется TCP соединение. Поиск программного средства для протоколирования
 

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

Примерно полгода назад сеть начала работать отвратительно - постоянно происходят разрывы TCP соединений.

Результат : все сетевые приложения тормозят (по минуте и больше) или аварийно закрываются.

Вопрос : каким программным средством можно убедительно продемонстрировать наличие таких безобразий в сети?

Такое впечатление, что наш отдел специально "динамят", переведя наши розеточные порты на глючные порты коммутаторов.

а тупо попинговать с ключем - t скажем ваш основной сервак и посмотреть время задержек ? вообще подобная хрень вполне может наблюдаться если скажем кто-то иотловил вирус и флудит теперь, у меня один тренднетовский свитч как антивирус :) если начались на нем тормоза значит кто-то отловил вирусняк :)

Попробуй NMAP. ;)
Есть еще одна софтина, хоть убей, название вспомнить не могу. Вечером буду дома, отпишусь точнее.

Для примера приведу сообщение об ошибке, которую время от времени выдаёт 1С 8.1, при попытке соединиться с TCP портом 1541 на сервере omc1 :

Нужно заметить, что рвётся соединение и с прочими серверами, не только с omc1.

сетевушку проверить стоило бы.
А зачем вам что-то доказывать нужно просто писать служебку начальству и упирать, что работать невозможно - оно в чвою очередь передает вопрос на своем уровне.
Это не ваша задача что-то доказывать. С вашей стороны вполне хватит и пары скриншотов с той ошибкой которую вы скопировали, если так хотите доказательств.
Но это на самом деле не ваше дело это ИХ дело доказать что они исполняют свою работу правильно.
Например. проблема может быть не в вашем vlan или загрузке магистрали ( если не сетевушка то упирание в ширину канала где-либо второе по вероятности подходящее к вашим симптомам) - вы просто ничего не увидите со своей машины никогда.
Даже глючной порт вы никак не определите - ну если только пытать отловить пакеты с битым crc, а если их не будет что вы надеетесь увидеть? провалы в моменты неактивности программ которые ни о чем не говорят?

По стандарту TCP, если правильный пакет не приходит вовремя, его перезапрашивают. А тут : сбой длится одну-две минуты, после сбоя какое-то время всё работает нормально.

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

Если и перезапрошенный пакет не дойдет то в итоге будет обрыв.
Если у всего отдела, тогда это вероятнее всего полка на магистрали либо проблемы в какой-то общей точке, которую вы никогда не увидите скорее всего. сложно судить не зная что вы там по сети корпоративной гоняете и какого объема, вполне может быть и какая-нибуть вирусная гадость или кто-то познал радости р2р клиентов, вообще одна-две минуты это много - хватит, например, свичу перегрузиться.
Вам для заявы нужно зафиксировать факт отказа - а дальше другой отдел отрабатывает свою зарплату.
Можно в принципе поднять например ping -t на шлюз и на сервер, с которым пропала связь делать трассировки и поанализировать это, но это может опять таки ничего не дать или могут быть такие особенности построения сети что без их учета интерпретация этих данных будет неверной и вас просто пошлют, а проблема останется.

Попробуй Essential Net Tools, я ею работал, интерфейс понятен, правда для начала желательно почитать руководство(имеется в наличии, язык-русский).Понадобиться, пиши, сброшу.:)

К стати а откуда такое впечатление про "динамят" был какой-то повод из области кто-то с кем-то поругался ?

Именно так :mad:

добавлено через 12 минут
Установил эту программу. А дальше в каком направлении действовать?

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

НУ а дальше: ping, netstat, traceroute, и анализ полученной информации. Еще неплохо было бы почитать теорию по сетям.:contract: Есть краткий PDF-manual. Но там лишь описание каждой из функций.

Теорию сетей я знаю хорошо. И команды эти мне тоже известны.

Так что с этими командами делать-то? :idontnow:

добавлено через 3 минуты
От пассивного слушания сети ещё никто не помирал :ржать:

Неа не помирал, только будет слово специалиста против вашего, угадайте кому в итоге поверят ;)
а скажет ваш спец примерно следующее "запущенные программмы занимают место в оперативнеой памяти, а также используют процессорное время если из-за этого у кого-то что0-то плохо работает то он сам себе нехороший человек" в зависимости от стпени официальности и желания пошутить могут быть добавлены дополнительные замечания как личностные так и технического плана ;)
тем более я так понял вы с ними на ножах.

Ситуация не такая безнадёжная, как кажется.

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

Во-вторых, администраторы сети в курсе, что у нас происходят проблемы с сетью. Мы писали заявки на устранение проблемы, но в день прихода специалиста-администратора сеть работала хорошо, и сбоев не удалось продемонстрировать. Заявку закрыли.

добавлено через 1 минуту
В том-то и дело, что нет.

Обычные деловые отношения. Ни больше, ни меньше.

Oleg , тогда можно попробовать протоколировать сбои, фиксировать время сбоя, кого затронуло пинговать шлюз и неотвечающий сервер, делать трассировку. Если все проходит нормально проверять доступность порта сервера команда - telnet адрес порт. Для эталона сделать тоже самое, когда работает.

А вообще есть переодичность этого глюка ? если с момента заявки до прихода глюк исчезает..... может тупо и банально свитч подвисает скажем от перегрева или перепадов напряжения ?

Почтовое соединение (MS Outlook с MAPI сервером MS Exchange) подвисает по 20-30 раз в день.

Когда учился в институте(лет пять назад) единственной прогой была утилита network monitor( windows утилита), поставляется вместе с сервером винды. Прога конечно сразу непонятная, но когда разберешься, то ... Видно там все. Мы на лабках ее ставили на обычные станции, она работала, только к ней нужно установить еще простые службы тсп ип и слушатель рип. С помощью ее мы проверяли доступность серверов, наличие коллизий. Так что попробуй.

Для анализа любой сетевой деятельности рекомендую Wireshark.

Ставите сниферить все. Если трафика рабочего много, то и он наловит кучу всего. На очень больших объемах начинает тормозить, надо в опцих ставить чтобы не держал большие буферы, скидывал на винт.

На у дальше уже, когда есть скажем снимок трафика всего дня - он же для анализа просто незаменимый инструмент - можете построить графики, посмотреть статистику (например битых пакетов и ретрансмиссий). В моменты падения сети, посмотрите оставшуюся активность, обычно она тоже может сказать о многом - это могут быть ARP, броадкасты, GRE, мультикасты и куча всего остального.

Кое-каких результатов по этой теме удалось достичь.

Если запустить команду
то количество сбросов TCP соединений с этим сервером server-ip резко сокращается.

если время отклика держится при этом постоянным, то могу предложить в порядке вечернего бреда поискать сетевушки с одинаковым МАС адресом воткнутые в один свич.

Сокращается, но все же проблема остается? А что происходить в тот момент, когда начинаются траблы, пинг идет? Ping, это всего лишь echo-ответ на посланный запрос, сложно проследить зависимость между возникновением обрыва и его снижением при пинговании. Может на сервере есть какое нибудь ограничение на подключение к нему, и при достижении критической точки, кто то страдает:idontnow:?

Кажется, проблема полностью решилась заменой активного сетевого оборудования на нашем этаже (в нашей комнате никакие изменения не производились). :yees:

:beer: