РАЗРЫВЫ СОЕДИНЕНИЯ

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

  • выполнена холодная перезагрузка проблемной рабочей станции (горячая перезагрузка не обнуляет состояние адаптерных карт). То же касается применения всех необходимых программных исправлений, если они были загружены, но не установлены. Кроме того, некоторым устройствам Plug-n-Play для полной установки требуется двукратная, а то и трехкратная перезагрузка;
  • сбои в аппаратной части отсутствуют;
  • сетевые кабели правильно подключены и функционируют должным образом;
  • сетевая карта не отключена, в подсети назначаются нужные динамические (посредством DHCP) или статические адреса. Отчеты операционной системы о состоянии сетевой карты не содержат аномальных значений, в частности, число отправленных и полученных пакетов отлично от нуля (если хоть одно из этих значений нулевое, значит, надо разобраться, в чем причина);
  • в последнее время ни на самой рабочей станции, ни на сервере не производилось никаких изменений в службах, конфигурации, программном или аппаратном обеспечении;
  • возможные проблемы с распределением памяти на рабочей станции и конфликты программного обеспечения исключены. Для проверки следует загрузить лишь то программное обеспечение, которое необходимо для работы тестируемого приложения в сети, и временно — до завершения теста — отключить антивирусную систему и программное обеспечение безопасности;
  • никакие приложения на пользовательской рабочей станции не потребляют чрезмерно ресурсы микропроцессора и не затормаживают работу компьютера настолько, что за это время происходит сброс счетчиков соединения. Подобными свойствами могут обладать вирусы.

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

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

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

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

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

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

Потенциальными проблемами в широковещательном домене следует заняться только после того, как установлено надежное соединение на уровне MAC. Типичный пример такого сбоя — невозможность создать стабильное логическое подключение через мост. К разрыву связи станции с серверами и маршрутизаторами в том же широковещательном домене могут приводить и проблемы на сетевом уровне:

  • плохо работающий или неисправный порт для каскадирования (uplink port), находящийся в любом месте маршрута. Как правило, это следствие использования плохого кабеля;
  • проблемы со связующим деревом в сети — возможно, также из-за плохого кабеля;
  • широковещательный шторм или чрезмерный трафик другого типа в широковещательном домене (причем вовсе не обязательно, что этот трафик наблюдается на локальном порту);
  • несоответствия в настройках дуплексного режима на каком-то участке маршрута;
  • дублирующиеся IP-адреса;
  • некорректное объявление маршрутов рабочей станцией или сервером.

Отправка повторяющихся запросов Ping на локальный маршрутизатор позволяет выявить потерю пакетов в широковещательном домене. С помощью системы управления сетью опросите сетевые устройства, находящиеся по пути от пользователя до маршрутизатора, сервера или службы. Обратите внимание на ошибки или высокий уровень загруженности, особенно если они отмечаются в тот момент, когда соединение оказывается разорвано. Подключите рабочую станцию к сети и воспользуйтесь анализатором протоколов для мониторинга сетевого трафика и/или сбора пакетов от проблемного сервера или службы для последующего анализа. Если проблема то появляется, то исчезает, оставьте анализатор протоколов для сбора трафика за определенный период времени. Научите пользователя, как остановить сбор данных — он должен сделать это сразу же, как только случится сбой. Довольно часто такие проблемы имеют нерегулярный характер, поэтому без привлечения пользователя к процессу диагностирования не обойтись. Он должен либо немедленно позвать специалиста, либо самостоятельно собрать данные о том, что происходило перед сбоем.

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

  • неустойчивая маршрутизация вследствие пограничного состояния порта или канала на каком-то участке за пределами широковещательного домена. Возможная причина — плохой кабель;
  • чрезмерный трафик для низкоскоростного локального или глобального канала. Возможно, трафик отвергается, либо буфер переполнен;
  • время отклика на запросы Ping и функции Trace Route варьируется;
  • сервер или служба испытывают перегрузку.

Отправка запросов Ping и Trace Route позволяют найти узел, с которого следует начать диагностирование проблемы потери сетевого соединения. Если симптомы то появляются, то исчезают или их трудно уловить, необходимо запустить тесты на непрерывное выполнение. При выявлении подозрительного удаленного узла процесс диагностирования можно ускорить, воспользовавшись системой управления сетью, чтобы опросить соответствующее сетевое устройство, а также устройство, ему предшествующее. Либо то, либо другое покажет ошибки определенного типа или чрезмерный уровень загруженности.

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

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

МЕДЛЕННАЯ РАБОТА СЕТИ

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

Приводимые далее процедуры подразумевают, что до возникновения проблемы сетевое соединение функционировало корректно и вы уже проделали следующее:

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

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

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

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

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

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

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

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

  • порт для каскадирования (uplink port), расположенный в любом месте маршрута, неисправен. Как правило, это следствие использования плохого кабеля;
  • проблемы со связующим деревом в сети — опять-таки из-за плохого кабеля;
  • широковещательный шторм или чрезмерный трафик другого типа в широковещательном домене, причем не только на локальном порту;
  • несоответствия в настройках дуплексного режима между двумя портами вдоль маршрута;
  • повторяющиеся IP-адреса;
  • рабочая станция или сервер некорректно объявляют маршруты.

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

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

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

  • неустойчивая маршрутизация по вине пограничного состояния порта или линии на каком-то участке за пределами широковещательного домена. Возможная причина — плохой кабель;
  • чрезмерный трафик по низкоскоростному локальному или глобальному соединению — возможно, трафик отвергается, либо буфер переполнен;
  • варьируется время отклика на запросы Ping и функции Trace Route;
  • перегружены соответствующие сервер или служба.

Отправка запросов Ping и трассировка маршрута посредством Trace Route позволяют найти точку, с которой следует начинать диагностирование медленной работы сети. Если проблема то появляется, то исчезает или ее трудно уловить, необходимо запустить тесты на непрерывное выполнение. Когда какой-то удаленный узел вызывает подозрение, процесс диагностирования можно ускорить, воспользовавшись системой управления сетью, чтобы опросить «скомпрометированное» сетевое устройство, а также устройство, находящееся перед ним. Одно из них укажет на определенные ошибки или чрезмерный уровень использования.

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

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

Игорь Панов — региональный менеджер по продукции и поддержке партнеров Fluke Networks в России и СНГ. С ним можно связаться по адресу: igor.panov@flukenetworks.com.