Диагностика компьютерных сетей штатными средствами операционной системы. Диагностика сетевого оборудования

Муромский институт (филиал) Владимирского государственного университета

Методы решения проблем проектирования и диагностики локальных вычислительных сетей

А.Е. Лашин, Д.О. Мальцев

Научный руководитель – В.В. Чекушкиин, профессор кафедры САПР, д.т.н.

Локальная вычислительная сеть (ЛВС) это совместное подключение отдельных компьютеров или рабочих станций и через канал передачи данных. Понятие ЛВС относится к географически ограниченным реализациям, в которых определённое число компьютеров связаны друг с другом с помощью современных и технологичных средств коммуникаций.

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

Возможность получить и отправить любую информацию с любого компьютера в сети.

Свободное добавление, удаление и перемещение рабочих мест сотрудников внутри офиса/здания.

Оперативное наращивание (модернизация) системы оборудования без затрат на кабельную сеть.

При построении ЛВС главной задачей является эффективное проектирование её структуры (Рис. 1). Благодаря правильно выбранной структуре локальной сети можно существенно повысить скорость и функциональность системы и сократить дальнейшие расходы на её создание и последующий сервис.

Рис. 1 – Структура локальной вычислительной сети

Рассмотрим сеть, в которой есть доступ в интернет и к любому компьютеру, подключённому в сеть. Доступ к сети Интернет осуществляется за счёт роутера, к которому подключена выделенная линия, mac адреса отключены. Роутер – используется для объединения сетей с разными типами программного и аппаратного обеспечения. Мост – разделяет сеть на участки, таким образом данные проходят через мост только если это действительно необходимо, т.е. если получатель не находится в одном сегменте с отправителем. Коммутатор (сетевой концентратор) – отличатся от моста только тем, что он имеет по процессору на каждое гнездо, в то время как у моста - один процессорный блок на все гнезда. Такая структура повышает производительность. Коннектор – устанавливается на концах сетевого кабеля (витой пары) с помощью обжимного инструмента, служит в качестве штекера витой пары.

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

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

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

локальный сеть роутер

1. Изначально, необходимо проверить целостность линии витой пары. Если ели обнаружен обрыв, необходимо его устранить;

2. Проверить, качество контакта коннектора витой пары, как в разъёме сетевой карты, так и в разъёме коммутатора. Извлечь коннектор из разъёма и вставить вновь до характерного щелчка;

3. Проверить правильность введенных настроек (к примеру, у 2-х машин в ЛВС не может быть одинаковый IP адрес). Ввести правильные настройки для конкретной машины;

4. Если проблема не в этом, то необходимо попробовать подсоединить сетевой провод к другому разъёму в коммутаторе (бывает, что выгорает один из разъёмов, а не весь коммутатор). Извлечь коннектор из разъёма и присоединить его к другому разъёму;

5. Проверить состояние mac адреса (при установке на машину некоторых операционных систем он может измениться). В данном случае, отключить в настройках mаc адрес;

6. Если неисправность не устранена, то нужно переустановить драйвера сетевой карты, но после придется вводить все настройки заново. Вставить диск с драйвером и запустить установку драйвера с помощью стандартной утилиты, далее ввести все настройки для конкретной машины;

7. Если всё выше перечисленное не решило проблему, то следует заменить сетевую карту (если есть такая возможность), после этого нужно будет снова установить драйвера и ввести все настройки. Если сетевая карта встроена в материнскую, то вставить в специальный разъём на материнской плате сетевую карту. Если сетевая карта уже была установлена, то поменять её на заведомо рабочую. Это крайняя мера, но не редки случаи, когда выгорает встроенная сетевая плата.

Это основные 7 проблем, которые могут возникнуть. Но бывают случаи абсолютно специфических неполадок: к примеру, очень сильная запылённость, выход из строя роутера или его блока питания, проблема с розеткой питающей сети 220 В, и т.д. Некоторые неполадки могут быть совершенно неординарны и требовать иного решения проблемы (к примеру, не правильная разводка соединительных проводов, в таком случае нужно исправить некорректно разведенный конец провода).

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

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

Методология проведения анализа может быть представлена в виде следующих шести этапов:

1. Захват данных.

2. Просмотр захваченных данных.

3. Анализ данных.

4. Поиск ошибок. (Большинство анализаторов облегчают эту работу, определяя типы ошибок и идентифицируя станцию, от которой пришел пакет с ошибкой.)

5. Исследование производительности. Рассчитывается коэффициент использования пропускной способности сети или среднее время реакции на запрос.

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

Обычно процесс анализа протоколов занимает относительно немного времени - 1-2 рабочих дня.

Большинство современных анализаторов позволяют анализировать сразу несколько протоколов глобальных сетей, таких, как X.25, PPP, SLIP, SDLC/SNA, frame relay, SMDS, ISDN, протоколы мостов/маршрутизаторов (3Com, Cisco, Bay Networks и другие). Такие анализаторы позволяют измерять различные параметры протоколов, анализировать трафик в сети, преобразование между протоколами локальных и глобальных сетей, задержку на маршрутизаторах при этих преобразованиях и т. п. Более совершенные приборы предусматривают возможность моделирования и декодирования протоколов глобальных сетей, "стрессового" тестирования, измерения максимальной пропускной способности, тестирования качества предоставляемых услуг. В целях универсальности почти все анализаторы протоколов глобальных сетей реализуют функции тестирования ЛВС и всех основных интерфейсов. Некоторые приборы способны осуществлять анализ протоколов телефонии. А самые современные модели могут декодировать и представлять в удобном варианте все семь уровней OSI. Появление ATM привело к тому, что производители стали снабжать свои анализаторы средствами тестирования этих сетей. Такие приборы могут проводить полное тестирование сетей АТМ уровня E-1/E-3 с поддержкой мониторинга и моделирования. Очень важное значение имеет набор сервисных функций анализатора. Некоторые из них, например возможность удаленного управления прибором, просто незаменимы.

Таким образом, современные анализаторы протоколов WAN/LAN/ATM позволяют обнаружить ошибки в конфигурации маршрутизаторов и мостов; установить тип трафика, пересылаемого по глобальной сети; определить используемый диапазон скоростей, оптимизировать соотношение между пропускной способностью и количеством каналов; локализовать источник неправильного трафика; выполнить тестирование последовательных интерфейсов и полное тестирование АТМ; осуществить полный мониторинг и декодирование основных протоколов по любому каналу; анализировать статистику в реальном времени, включая анализ трафика локальных сетей через глобальные сети.

2. 4 Общая характеристика протоколов монит о ринга

2. 4 .1 Протокол SNMP

SNMP (англ. Simple Network Management Protocol -- простой протокол управления сетью) -- это протокол управления сетями связи на основе архитектуры TCP/IP.

На основе концепции TMN в 1980--1990 гг. различными органами стандартизации был выработан ряд протоколов управления сетями передачи данных с различным спектром реализации функций TMN. К одному из типов таких протоколов управления относится SNMP. Протокол SNMP был разработан с целью проверки функционирования сетевых маршрутизаторов и мостов. Впоследствии сфера действия протокола охватила и другие сетевые устройства, такие как хабы, шлюзы, терминальные сервера, LAN Manager сервера, машины под управлением Windows NT и т.д. Кроме того, протокол допускает возможность внесения изменений в функционирование указанных устройств.

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

При использовании SNMP присутствуют управляемые и управляющие системы. В состав управляемой системы входит компонент, называемый агентом, который отправляет отчёты управляющей системе. По существу SNMP агенты передают управленческую информацию на управляющие системы как переменные (такие как «свободная память», «имя системы», «количество работающих процессов»).

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

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

Аппаратный агент - встроенная аппаратура (с процессором и памятью), в которой хранятся программные агенты.

Переменные, доступные через SNMP, организованы в иерархии. Эти иерархии и другие метаданные (такие, как тип и описание переменной) описываются Базами Управляющей Информации (Management Information Bases (MIBs)).

На сегодня существует несколько стандартов на базы данных управляющей информации . Основными являются стандарты MIB-I и MIB-II, а также версия базы данных для удаленного управления RMON MIB. Кроме этого, существуют стандарты для специальных MIB устройств конкретного типа (например, MIB для концентраторов или MIB для модемов), а также частные MIB конкретных фирм-производителей оборудования.

Первоначальная спецификация MIB-I определяла только операции чтения значений переменных. Операции изменения или установки значений объекта являются частью спецификаций MIB-II.

Версия MIB-I (RFC 1156) определяет до 114 объектов, которые подразделяются на 8 групп:

· System - общие данные об устройстве (например, идентификатор поставщика, время последней инициализации системы).

· Interfaces - описываются параметры сетевых интерфейсов устройства (например, их количество, типы, скорости обмена, максимальный размер пакета).

· AddressTranslationTable - описывается соответствие между сетевыми и физическими адресами (например, по протоколу ARP).

· InternetProtocol - данные, относящиеся к протоколу IP (адреса IP-шлюзов, хостов, статистика об IP-пакетах).

· ICMP - данные, относящиеся к протоколу обмена управляющими сообщениями ICMP.

· TCP - данные, относящиеся к протоколу TCP (например, о TCP-соединениях).

· UDP - данные, относящиеся к протоколу UDP (число переданных, принятых и ошибочных UPD-дейтаграмм).

· EGP - данные, относящиеся к протоколу обмена маршрутной информацией ExteriorGatewayProtocol, используемому в сети Internet (число принятых с ошибками и без ошибок сообщений).

Из этого перечня групп переменных видно, что стандарт MIB-I разрабатывался с жесткой ориентацией на управление маршрутизаторами, поддерживающими протоколы стека TCP/IP.

В версии MIB-II (RFC 1213), принятой в 1992 году, был существенно (до 185) расширен набор стандартных объектов, а число групп увеличилось до 10.

2. 3 .2 Агенты RMON

Новейшим добавлением к функциональным возможностям SNMP является спецификация RMON, которая обеспечивает удаленное взаимодействие с базой MIB.

Стандарт на RMON появился в ноябре 1991 года, когда Internet Engineering Task Force выпустил документ RFC 1271 под названием "Remote Network Monitoring Management Information Base" ("Информационная база дистанционного мониторинга сетей"). Данный документ содержал описание RMON для сетей Ethernet.

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

До появления RMON протокол SNMP не мог использоваться удаленным образом, он допускал только локальное управление устройствами. База RMON MIB обладает улучшенным набором свойств для удаленного управления, так как содержит агрегированную информацию об устройстве, что не требует передачи по сети больших объемов информации. Объекты RMON MIB включают дополнительные счетчики ошибок в пакетах, более гибкие средства анализа графических трендов и статистики, более мощные средства фильтрации для захвата и анализа отдельных пакетов, а также более сложные условия установления сигналов предупреждения. Агенты RMON MIB более интеллектуальны по сравнению с агентами MIB-I или MIB-II и выполняют значительную часть работы по обработке информации об устройстве, которую раньше выполняли менеджеры. Эти агенты могут располагаться внутри различных коммуникационных устройств, а также быть выполнены в виде отдельных программных модулей, работающих на универсальных ПК и ноутбуках (примером может служить LANalyzerNovell).

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

Сбор информации RMON осуществляется аппаратно-программными зондами, подключаемыми непосредственно к сети. Чтобы выполнить задачу сбора и первичного анализа данных, зонд должен обладать достаточными вычислительными ресурсами и объемом оперативной памяти. В настоящее время на рынке имеются зонды трех типов: встроенные, зонды на базе компьютера, и автономные. Продукт считается поддерживающим RMON, если в нем реализована хотя бы одна группа RMON. Разумеется, чем больше групп данных RMON реализовано в данном продукте, тем он, с одной стороны, дороже, а с другой - тем более полную информацию о работе сети он предоставляет.

Встроенные зонды представляют собой модули расширения для сетевых устройств. Такие модули выпускаются многими производителями, в частности, такими крупными компаниями, как 3Com, Cabletron, Bay Networks и Cisco. (Кстати, 3Com и Bay Networks недавно приобрели компании Axon и ARMON, признанных лидеров в области разработки и производства средств управления RMON. Такой интерес к этой технологии со стороны крупнейших производителей сетевого оборудования лишний раз показывает, насколько нужным для пользователей является дистанционный мониторинг.) Наиболее естественным выглядит решение встраивать модули RMON в концентраторы, ведь именно из наблюдения за этими устройствами можно составить себе представление о работе сегмента. Достоинство таких зондов очевидно: они позволяют получать информацию по всем основным группам данных RMON при относительно невысокой цене. Недостатком в первую очередь является не слишком высокая производительность, что проявляется, в частности, в том, что встроенные зонды часто поддерживают далеко не все группы данных RMON. Не так давно 3Com объявила о намерении выпустить поддерживающие RMON драйверы для сетевых адаптеров Etherlink III и Fast Ethernet. В результате окажется возможным собирать и анализировать данные RMON непосредственно на рабочих станциях в сети.

Зонды на базе компьютера - это просто подключенные к сети компьютеры с установленным на них программным агентом RMON. Такие зонды (к числу которых относится, например, продукт Cornerstone Agent 2.5 компании Network General) обладают более высокой производительностью, чем встроенные зонды, и поддерживают, как правило, все группы данных RMON. Они более дороги, чем встроенные зонды, но гораздо дешевле автономных зондов. Помимо этого, зонды на базе компьютера имеют довольно большой размер, что может иногда ограничивать возможности их применения.

Автономные зонды обладают наивысшей производительностью; как легко понять, это одновременно и наиболее дорогие продукты из всех описанных. Как правило, автономный зонд - это процессор (класса i486 или RISC-процессор), оснащенный достаточным объемом оперативной памяти и сетевым адаптером. Лидерами в этом секторе рынка являются компании Frontier и Hewlett-Packard. Зонды этого типа невелики по размеру и весьма мобильны - их очень легко подключать к сети и отключать от нее. При решении задачи управления сетью глобального масштаба это, конечно, не слишком важное свойство, однако если средства RMON применяются для анализа работы корпоративной сети средних размеров, то (учитывая высокую стоимость устройств) мобильность зондов может сыграть весьма положительную роль.

Объекту RMON присвоен номер 16 в наборе объектов MIB, а сам объект RMON объединяет в соответствии с документом RFC 1271, состоит из десяти групп данных.

· Statistics - текущие накопленные статистические данные о характеристиках пакетов, количестве коллизий и т.п.

· History - статистические данные, сохраненные через определенные промежутки времени для последующего анализа тенденций их изменений.

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

· Host - данных о хостах сети, в том числе и об их MAC-адресах..

· HostTopN - таблица наиболее загруженных хостов сети. Таблица N главных хостов (HostTopN) содержит список N первых хостов, характеризующихся максимальным значением заданного статистического параметра для заданного интервала. Например, можно затребовать список 10 хостов, для которых наблюдалось максимальное количество ошибок в течение последних 24 часов. Список этот будет составлен самим агентом, а приложение управления получит только адреса этих хостов и значения соответствующих статистических параметров. Видно, до какой степени такой подход экономит сетевые ресурсы

· TrafficMatrix - статистика об интенсивности трафика между каждой парой хостов сети, упорядоченная в виде матрицы. Строки этой матрицы пронумерованы в соответствии с MAC-адресами станций - источников сообщений, а столбцы - в соответствии с адресами станций-получателей. Матричные элементы характеризуют интенсивность трафика между соответствующими станциями и количество ошибок. Проанализировав такую матрицу, пользователь легко может выяснить, какие пары станций генерируют наиболее интенсивный трафик. Эта матрица, опять-таки, формируется самим агентом, поэтому отпадает необходимость в передаче больших объемов данных на центральный компьютер, отвечающий за управление сетью.

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

· PacketCapture - условия захвата пакетов. В состав группы перехвата пакетов (packet capture) входят буфера для захвата, куда направляются пакеты, чьи признаки удовлетворяют условиям, сформулированным в группе фильтров. При этом захватываться может не пакет целиком, а, скажем, только первые несколько десятков байт пакета. Содержимое буферов перехвата можно впоследствии анализировать при помощи различных программных средств, выясняя целый ряд весьма полезных характеристик работы сети. Перестраивая фильтры на те или иные признаки, можно характеризовать разные параметры работы сети.

· Event - условия регистрации и генерации событий. В группе событий (events) определяется, когда следует отправлять аварийный сигнал приложению управления, когда - перхватывать пакеты, и вообще - как реагировать на те или иные события, происходящие в сети, например, на превышение заданных в группе alarms пороговых значений: следует ли ставить в известность приложение управления, или надо просто запротоколировать данное событие и продолжать работать. События могут и не быть связаны с предачей аварийных сигналов - например, направление пакета в буфер перехвата тоже представляет собой событие.

Данные группы пронумерованы в указанном порядке, поэтому, например, группа Hosts имеет числовое имя 1.3.6.1.2.1.16.4.

Десятую группу составляют специальные объекты протокола TokenRing.

Всего стандарт RMON MIB определяет около 200 объектов в 10 группах, зафиксированных в двух документах - RFC 1271 для сетей Ethernet и RFC 1513 для сетей TokenRing.

Отличительной чертой стандарта RMON MIB является его независимость от протокола сетевого уровня (в отличие от стандартов MIB-I и MIB-II, ориентированных на протоколы TCP/IP). Поэтому, его удобно использовать в гетерогенных средах, использующих различные протоколы сетевого уровня.

2. 5 Обзор популярных с истемы управления сетями

Система управления сетью (Network management system)- аппаратные и/или программные средства для мониторинга и управления узлами сети. Программное обеспечение системы управления сетью состоит из агентов, локализующихся на сетевых устройствах и передающих информацию сетевой управляющей платформе. Метод информационного обмена между управляющими приложениями и агентами на устройствах определяется протоколами.

Системы управления сетями должны обладать целым рядом качеств:

· истинной распределенностью в соответствии с концепцией клиент/сервер,

· масштабируемостью,

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

Первые два свойства тесно связаны. Хорошая масштабируемость достигается за счет распределенности системы управления. Распределенность означает, что система может включать несколько серверов и клиентов. Серверы (менеджерами) собирают данные о текущем состоянии сети от агентов (SNMP, CMIP или RMON), встроенных в оборудование сети, и накапливают их в своей базе данных. Клиенты представляют собой графические консоли, за которыми работают администраторы сети. Программное обеспечение клиента системы управления принимает запросы на выполнение каких-либо действий от администратора (например, построение подробной карты части сети) и обращается за необходимой информацией к серверу. Если сервер обладает нужной информацией, то он сразу же передает ее клиенту, если нет - то пытается собрать ее от агентов.

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

Поддержка разнородного оборудования - скорее желаемое, чем реально существующее свойство сегодняшних систем управления. К числу наиболее популярных продуктов сетевого управления относятся четыре системы: Spectrum компании CabletronSystems, OpenView фирмы Hewlett-Packard, NetView корпорации IBM и Solstice производства SunSoft - подразделения SunMicrosystems. Три компании из четырех сами выпускают коммуникационное оборудование. Естественно, что система Spectrum лучше всего управляет оборудованием компании Cabletron, OpenView - оборудованием компании Hewlett-Packard, а NetView- оборудованием компании IBM.

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

Для исправления этого недостатка разработчики систем управления включают поддержку не только стандартных баз MIB I, MIB II и RMON MIB, но и многочисленных частных MIB фирм-производителей. Лидер в этой области - система Spectrum, поддерживающая около 1000 баз MIB различных производителей.

Другим способом более качественной поддержки конкретной аппаратуры является использование на основе какой-либо платформы управления приложения той фирмы, которая выпускает это оборудование. Ведущие компании - производители коммуникационного оборудования - разработали и поставляют весьма сложные и многофункциональные системы управления для своего оборудования. К наиболее известным системам этого класса относятся Optivity компании BayNetworks, CiscoWorks компании CiscoSystems, Transcend компании 3Com. Система Optivity, например, позволяет производить мониторинг и управлять сетями, состоящими из маршрутизаторов, коммутаторов и концентраторов компании BayNetwork, полностью используя все их возможности и свойства. Оборудование других производителей поддерживается на уровне базовых функций управления. Система Optivity работает на платформах OpenView компании Hewlett-Packard и SunNetManager (предшественник Solstice) компании SunSoft. Однако, работа на основе какой-либо платформы управления с несколькими системами, такими как Optivity, слишком сложна и требует, чтобы компьютеры, на которых все это будет работать, обладали очень мощными процессорами и большой оперативной памятью.

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

Открытость платформы управления зависит также от формы хранения собранных данных о состоянии сети. Большинство платформ-лидеров позволяют хранить данные в коммерческих базах данных, таких как Oracle, Ingres или Informix. Использование универсальных СУБД снижает скорость работы системы управления по сравнению с хранением данных в файлах операционной системы, но зато позволяет обрабатывать эти данные любыми приложениями, умеющими работать с этими СУБД.

В таблице представлены наиболее важные характеристики наиболее популярных платформ управления

Таблица 2.1 - Характеристики популярных платформ диагностики

Характеристики	OpenView Network Node Manager 4.1 (Hewlett- Packard)	Spectrum Enterprise Manager (Cabletron Systems)	NetView forAIX SNMPManager (IBM)	Solstice Enterprise Manager (SunSoft)
Автообнаружение
Ограничение по числу промежуточных маршрутизаторов
Определение имени хоста по его адресу через сервер DNS
Возможность модификации присвоенного имени хоста
Распознавание сетевых топологий	Любые сети, работающие по TCP/IP	Ethernet, TokenRing, FDDI, ATM, распределенные сети, сети с коммутацией	распознавание по интерфейсам устройств	Ethernet, Token-Ring, FDDI, распределен- ные сети
	200 - 2000, наибольшее известное - 35000		Программных ограничений не существует
Поддержка баз данных			Собств., Oracle, Sybase, ...	Informix, Oracle, Sybase
Распределенное управление
Один сервер /		клиентов
Число клиентов		Нет программного ограничения	Протестиро- вано более 30	Нет программного ограничения
Клиент использует X-Window
Система с GUI запускается на клиенте
Собственная карта сети у клиента
Задание доступных для просмотра объектов сети	С помощью дополнительного продукта Operations Center (HP)
Много серверов /		клиентов
текущее состояние
планируется
Число приложений третьих фирм
Число поддерживаемых MIB третьих фирм				Нет данных
Поддержка протокола SNMP :
Поддержка MIB, утвержденных IETF	Большинство, но нет RMON
Поддержка протокола CMIP	Дополнительно оплачиваемый продукт - Open View HP Distributed Management Platform	Дополнительно оплачиваемый продукт
Взаимодействие с мейнфреймами	При помощи приложений третьих фирм	По SNA через Blue Vision	Может обращаться к NetView на мейнфрейме
Поддержка ОС	HPUX, SunOS, Solaris	IBM AIX, Sun OS, HP UX, SGI IRIX, Windows NT	AIX, OSF/1, Windows NT

3 Организация диагностики компьютерной сети

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

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

- Измерение текущей загруженности канала связи сети и определение влияния величины загрузки канала связи на время реакции прикладного ПО.

- Измерение числа коллизий в сети и выяснение причин их возникновения.

- Измерение числа ошибок передачи данных на уровне канала связи и выяснение причин их возникновения.

- Выявление дефектов архитектуры сети.

- Измерение текущей загруженности сервера и определение влияния степени его загрузки на время реакции прикладного ПО.

- Выявление дефектов прикладного ПО, следствием которых является неэффективное использование пропускной способности сервера и сети.

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

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

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

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

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

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

Третий подход осуществляется посредством контроля интегральных показателей качества функционирования диагностируемого устройства (далее -- интегральный подход). Следует подчеркнуть, что с точки зрения методологии диагностики сети между первыми двумя подходами, которые будем называть традиционными, и третьим, интегральным, есть принципиальное различие. При традиционных подходах мы наблюдаем за отдельными характеристиками работы сети и, чтобы увидеть ее “целиком”, должны синтезировать результаты отдельных наблюдений. Однако мы не можем быть уверены, что при этом синтезе не потеряем важную информацию. Интегральный подход, наоборот, дает нам общую картину, которая в ряде случаев бывает недостаточно детальной. Задача интерпретации результатов при интегральном подходе, по существу, обратная: наблюдая целое, выявить, где, в каких частностях заключается проблема.

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

3.1 Документирование сети

Ведение документирования сети дает сетевому администратору целый ряд преимуществ. Документирование сети может выступить:

- Инструментом для устранения неисправностей - в том случае, если что-нибудь идет не так как надо, документация может служить руководством при поиске и устранении неисправности. Она сохранит время и деньги.

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

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

Каждая сеть имеет свои уникальные особенности, но обладает и многими общими элементами, которые должны быть включены в документацию:

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

Информация о серверах - то есть, та информация, которая необходима вам для управления и администрирования серверами, такая как имя, функции, IP адреса, конфигурация дисков, ОС и сервис-паки, дата и место покупки, гарантия и т.д...

Назначение портов коммутаторов и маршрутизаторов - сюда включается детальная информация о конфигурации WAN, VLAN-ов или даже назначение портов сетевым узлам через патч-панель.

Конфигурация сетевых служб -- сетевые службы, такие как DNS, WINS, DHCP, и RAS, критичны для операций в сети, следует детально описать, как они структурированы. Данную информацию всегда можно получить с серверов, но документация ее заранее в легкочитаемом формате позволяет сэкономить время.

Политики и профили доменов - можно ограничить возможности пользователей с помощью Policy Editor в Windows NT или с помощью Group Policies в Windows 2000. При этом существует возможность создать профили пользователей, хранимые на сервере, а не на локальной машине. Если такие возможности используются, то такая информация должна быть документирована.

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

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

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

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

Основной задачей современных систем документирования сети на базе программного обеспечения является достижение гибкости и точности документации, а также управление сетями при низких затратах и минимальных трудностях. Система документирования сети хранит данные о всех пассивных (кабели, разъемы, панели переключений, распределительные шкафы) и активных (маршрутизаторы, коммутаторы, серверы, ПК, УАТС) компонентах сети, включая информацию о соединениях и их состоянии (Connectivity) в центральной реляционной базе данных (к примеру, Oracle, SQL, DB2), и визуализирует всю систему как в алфавитно-цифровой, так и в графической форме. Кроме того, основываясь на планах зданий и земельных участков, можно отобразить расположение отдельных компонентов и маршруты прокладки кабеля Информация о компонентах и их изображения хранятся в библиотеке компонентов, которая постоянно обновляется. Многие современные системы уже предлагают клиенты Web, позволяющие получать доступ к документации по сети через Internet. Так, обслуживающие техники могут на месте напрямую запрашивать рабочие задания посредством мобильных устройств, а после выполнения квитировать их в производственной системе. Некоторые системы документирования сети даже обладают функцией обнаружения (Discovery) для автоматического выявления посредством SNMP новых активных компонентов и включения их в документацию.

При наличии системы документирования сети пользователь в любое время может получить актуальный и целостный обзор всех сетевых ресурсов инфраструктуры организации. Согласно подсчетам Международной организации управления службами IT (IT Service Management Forum, ITSMF), на протяжении всего жизненного цикла системы IT затраты на ее содержание сокращаются в результате на 80%. Система документирования сети позволяет осуществлять большее (чем при обработке вручную) количество действий, необходимых для функционирования инфраструктуры сети, и при этом значительно экономит время на их выполнение. Вдобавок предотвращаются ошибки при вводе данных или их дублирование. В систему можно вводить автоматизированные процессы для изменения инфраструктуры (Change Requests) и, наконец, автоматически создавать рабочие задания, к примеру, при ремонтных работах или переездах. Деятельность обслуживающего персонала на местах становится намного эффективнее, за счет чего существенно упрощаются процессы обслуживания и изменения компьютерной сети. Расчеты показали, что сокращение усилий, а соответственно, и финансовых затрат на планирование и документирование необходимых изменений в сети может достигать 90%.

Согласно статистике по Network Operating Centers (NOC), около 80% всех неполадок в сети вызваны неисправностью проводки. При использовании системы документирования сети предприятия могут быстро локализовать проблемную зону и, таким образом, оперативно устранить неполадки. Более того, посредством системы документирования сети можно планировать и организовывать избыточные маршруты передачи сигнала, с тем чтобы в случае неполадок просто подключить их.

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

В качестве примера рассмотри некоторые из подобных систем.

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

· Визуализация компьютерной сети в красивой анимационной форме с отображением, какие компьютеры включены, а какие нет;

· Оповещение об остановке/запуске серверов;

· Просмотр, кто, к каким файлам обращается на компьютере по сети;

· Автоматический сбор информации о программном и аппаратном обеспечении компьютеров в сети.

·

Рисунок 3.1- Карта сети

10-Strike LANState - программа для администраторов и простых пользователей сетей Microsoft Windows. С помощью LANState можно наблюдать текущее состояние сети в графическом виде, управлять серверами и рабочими станциями, вести мониторинг удаленных устройств с помощью периодического опроса компьютеров, отслеживать подключения к сетевым ресурсам, получать своевременные оповещения о различных событиях.

LANState содержит множество полезных функций для администраторов и пользователей сети, например, отправка сообщений, перезагрузка и завершение работы удаленных компьютеров, пинг, определение имени по ip адресу, трассировка маршрута, сканирование портов и хостов. Также имеется возможность получения различной информации об удаленных компьютерах (без инсталляции серверной части на них). Например, просмотр реестра по сети, просмотр удаленного event log"а, просмотр списка установленных программ. Поддерживаются Windows 95/98/Me/NT/2000/XP.

Для пользователей сети: программа позволяет наглядно видеть какие компьютеры в сети включены, а какие - нет. В любой момент программу можно вызвать из трея Windows и быстро обратиться к ресурсам нужного компьютера (замена окна сетевого окружения). Можно настроить сигнализацию на включение/выключение определенных компьютеров и серверов в сети, на доступность файлов и папок, на запуск web- и FTP-серверов, и на другие события. LANState осуществляет контроль подключений к общим ресурсам и отслеживает обращения к файлам из сети. Есть возможность выяснить, кто и к каким файлам на компьютере обращается по сети, в том числе и через административные ресурсы.

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

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

1. SNMP должен быть включен на коммутаторах. Программа должна быть разрешена в брандмауэре для успешной работы по протоколу SNMP.

2. Запустить Мастер Создания Карты Сети.

3. Выбрать сканирование сети по диапазону IP-адресов. Указать диапазоны. Устройства с SNMP должны находиться внутри указанных диапазонов.

Рисунок 3.2 - Задание диапазона адресов

4. Выбрать методы сканирования и настроить их параметры. Поставить галочку рядом с опцией "Поиск устройств с SNMP..." и указать правильные community strings для подключения к коммутаторам.

Рисунок 3.3 - Параметры и способы сканирования

5. После сканирования программа должна нарисовать схему сети. Если сканирование SNMP прошло успешно, соединения между сетевыми устройствами будут нарисованы автоматически.

Схема сети может быть выгружена в картинку, либо в схему Microsoft Visio

Рисунок 3.4 - Укрупненная схема сети

3. 2 Методика упреждающей диагностики

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

Наблюдаемыми параметрами обычно являются:

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

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

Зная зависимость между временем реакции прикладного ПО и значениями наблюдаемых параметров, администратор сети должен определить максимальные значения параметров, допустимые для данной сети. Эти значения вводятся в виде порогов (thresholds) в диагностическое средство. Если в процессе эксплуатации сети значения наблюдаемых параметров превысят пороговые, то диагностическое средство проинформирует об этом событии администратора сети. Такая ситуация свидетельствует о наличии в сети проблемы.

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

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

3.2 Организация процесса диагностики

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

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

Если сеть имеет архитектуру с компактной магистралью (collapsed backbone) и в качестве магистрали используется коммутатор, то анализатор необходимо подключать к тем портам коммутатора, через которые проходит анализируемый трафик. Некоторые программы имеют специальные агенты или зонды (probes), устанавливаемые на компьютерах, подключенных к удаленным портам коммутатора. Обычно агенты (не путать с агентами SNMP) представляют собой сервис или задачу, работающую в фоновом режиме на компьютере пользователя. Как правило, агенты потребляют мало вычислительных ресурсов и не мешают работе пользователей, на компьютерах которых они установлены. Анализаторы и агенты могут быть подключены к коммутатору двумя способами.

При первом способе (см. рисунок 3.5) анализатор подключается к специальному порту (порту мониторинга или зеркальному порту) коммутатора, если таковой имеется, и на него по очереди направляется трафик со всех интересующих портов коммутатора.

Рисунок 3.5 - Первый способ подключения анализатора

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

Рисунок 3.6 - Второй способ подключения анализатора

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

Во-первых, анализатор протоколов должен иметь встроенную функцию генерации трафика Во-вторых, анализатор протоколов должен уметь "прореживать" принимаемые кадры, т. е. принимать не все кадры подряд, а, например, каждый пятый или каждый десятый с обязательной последующей аппроксимацией полученных результатов. Если эта функция отсутствует, то при сильной загруженности сети, какой бы производительностью ни обладал компьютер, на котором установлен анализатор, последний будет "зависать" и/или терять кадры. Это особенно важно при диагностике быстрых сетей типа Fast Ethernet и FDDI.

Предлагаемую методику мы будем иллюстрировать на примере использования чисто программного анализатора протоколов Observer компании Network Instruments - этомощный анализатор сетевых протоколов и средство для мониторинга и диагностики сетей Ethernet, беспроводных сетей стандарта 802.11 a/b/g, сетей Token Ring и FDDI. Observer позволяет в режиме реального времени измерять характеристики работы сети, осуществлять декодирование сетевых протоколов (поддерживается более 500 протоколов), создавать и анализировать тренды характеристик работы сети.

Подобные документы

Сущность и значение мониторинга и анализа локальных сетей как контроля работоспособности. Классификация средств мониторинга и анализа, сбор первичных данных о работе сети: анализаторы протоколов и сетей. Протокол SNMP: отличия, безопасность, недостатки.

контрольная работа , добавлен 07.12.2010


Понятие и структура компьютерных сетей, их классификация и разновидности. Технологии, применяемые для построения локальных сетей. Безопасность проводных локальных сетей. Беспроводные локальные сети, их характерные свойства и применяемые устройства.

курсовая работа , добавлен 01.01.2011


Организация частной сети. Структура незащищенной сети и виды угроз информации. Типовые удаленные и локальные атаки, механизмы их реализации. Выбор средств защиты для сети. Схема защищенной сети с Proxy-сервером и координатором внутри локальных сетей.

курсовая работа , добавлен 23.06.2011


Передача информации между компьютерами. Анализ способов и средств обмена информацией. Виды и структура локальных сетей. Исследование порядка соединения компьютеров в сети и её внешнего вида. Кабели для передачи информации. Сетевой и пакетный протоколы.

реферат , добавлен 22.12.2014


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

презентация , добавлен 04.05.2012


Теоретические основы организации локальных сетей. Общие сведения о сетях. Топология сетей. Основные протоколы обмена в компьютерных сетях. Обзор программных средств. Аутентификация и авторизация. Система Kerberos. Установка и настройка протоколов сети.

курсовая работа , добавлен 15.05.2007


Характеристика протоколов и методов реализации частных виртуальных сетей. Организация защищенного канала между несколькими локальными сетями через Интернет и мобильными пользователями. Туннель на однокарточных координаторах. Классификация VPN сетей.

курсовая работа , добавлен 01.07.2011


Компьютерные сети и их классификация. Аппаратные средства компьютерных сетей и топологии локальных сетей. Технологии и протоколы вычислительных сетей. Адресация компьютеров в сети и основные сетевые протоколы. Достоинства использования сетевых технологий.

курсовая работа , добавлен 22.04.2012


Назначение и классификация компьютерных сетей. Обобщенная структура компьютерной сети и характеристика процесса передачи данных. Управление взаимодействием устройств в сети. Типовые топологии и методы доступа локальных сетей. Работа в локальной сети.

реферат , добавлен 03.02.2009


Способы коммутации компьютеров. Классификация, структура, типы и принцип построения локальных компьютерных сетей. Выбор кабельной системы. Особенности интернета и других глобальных сетей. Описание основных протоколов обмена данными и их характеристика.

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

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

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

Поиск неисправностей в сети аппаратными средствами.

Условно, оборудование для диагностики, поиска неисправностей и сертификации кабельных систем можно поделить на четыре основные группы:

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

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

3. Кабельные сканеры позволяют определить длину кабеля, затухание, импеданс, схему разводки, уровень электрических шумов и оценить полученные результаты. Для определения местоположения неисправности кабельной системы (обрыва, короткого замыкания и т.д.) используется метод «кабельного радара», или Time Domain Reflectometry (TDR). Суть эго метода состоит в том, что сканер излучает в кабель короткий электрический импульс и измеряет время задержки до прихода отраженного сигнала. По полярности отраженного импульса определяется характер повреждения кабеля (короткое замыкание или обрыв). В правильно установленном и подключенном кабеле отраженный импульс отсутствует.

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

Подключение персонального компьютера к локальной сети

Первое, что нужно сделать – это убедиться в работоспособности сетевой карты компьютера/ноутбука и наличии установленных драйверов. Еще одна немаловажная деталь, необходимая для локальной сети – это свитч (коммутатор) и сам сетевой кабель. Вместо коммутатора можно использовать Wi-Fi роутер. Но количество портов будет ограничено, зато в качестве бонуса будет доступ к сети интернет.

Подключение к локальной сети происходит в следующей последовательности.

Сетевой кабель присоединаятся к коммутатору и сетевой карте компьютера. Далее включается компьютер и свитч. ОС загрузится, примерно за это же время свитч-роутер мигнет лампочками, и можно приступать к настройкам сетевых параметров: надо перейти в «Панель управления» – «Просмотр состояния сети и задач» – «Изменение параметров адаптера» – «ПКМ» – «Свойства» – «Настроить IP-адрес компьютера» – «Протокол Интернета версии 4» – «Свойства». Ввести IP-адрес в формате «192.168.YYY.ХХХ». Нажать на маску сети один раз, она установится автоматически. Необходимо учесть, что последние два блока чисел и маска сети должны совпадать с адресами той сети, к которой настраивается подключение. Например, если сеть «192.168.1.ХХХ», то «1» - это номер подсети, а «ХХХ» - любое число от 1 до 254. После настройки нужно нажать «ОК».

Далее нужно установить рабочую группу, это необходимо для отображения компьютера в соответствующей группе. В офисе, например, в группе «Бухгалтерия» будут рабочие машины только из отдела «Бухгалтерия». Далее надо зайти в свойства «Мой компьютер» – «Изменить параметры». В свойствах системы нажать «Изменить», для присоединения компьютера к рабочей группе. Ввести имя компьютера и рабочую группу. Нажать «ОК» и перезагрузить ПК для вступления изменений в силу.

Еще один вариант подключения – беспроводной. Этот способ пригоден только при наличии Wi-Fi роутера. Для этого понадобятся Wi-Fi адаптер (для установки внутрь или USB-порта) и Wi-Fi роутер. Нужно подключить адаптер. Система автоматически распознает его, установит для него драйверы или попросит вставить диск с драйверами. В системном лотке рядом с часами отобразится значок беспроводной сети. Далее надо нажать на него, появится список доступных для подключения сетей, в котором нужно найти свою и подключиться. В этом случае достаточно только установить домашнюю группу, IP-адрес будет присвоен автоматически. В ноутбуке уже встроены сетевая карта и Wi-Fi адаптер.

Подключение персонального компьютера к сети интернет

Для подключения компьютера к ПК необходимо проделать следующее: «Пуск» – «Панель управления» – «Сеть и Интернет» – «Центр управления сетями и общим доступом» – «Изменение параметров адаптера» – «Сетевые подключения» – «Подключение по локальной сети» – «ПКМ» – «Свойства» – «Сеть» – «Протокол Интернета версии 4 (ТСР/IPv4)» – «Свойства». В последующем окне нужно поставить отметки напротив функций «Получить IP-адрес автоматически» и «Получить адрес DNS-сервера автоматически».

Подключая компьютер к беспроводной сети Wi-Fi, нужно произвести следующие действия: перейти в «Центр управления сетями и общим доступом» – «Подключение к сети». Справа всплывет окно, в котором показаны настройки подключения к сети. Нужно убедиться, не активен ли режим «в самолете» – он должен быть выключен. Ниже будет предоставлен список доступных подключений. Нужно выбрать сеть и подключиться. Можно также поставить отметку напротив строки «Подключаться автоматически» – компьютер будет сам подключаться к этой сети, если она доступна. Обычно при проверке требований сети требуется ввести пароль, но иногда бывает и бесплатный Wi-Fi.

Изучение АСУ предприятия

Автоматизированная система управления (сокращённо АСУ) – комплекс аппаратных и программных средств, а также персонала, предназначенный для управления различными процессами в рамках технологического процесса, производства, предприятия. АСУ применяются в различных отраслях промышленности, энергетике, транспорте и т.п. Термин «автоматизированная», в отличие от термина «автоматическая», подчёркивает сохранение за человеком-оператором некоторых функций, либо наиболее общего, целеполагающего характера, либо не поддающихся автоматизации. АСУ с системой поддержки принятия решений (СППР) являются основным инструментом повышения обоснованности управленческих решений.

Важнейшая задача АСУ – повышение эффективности управления объектом на основе роста производительности труда и совершенствования методов планирования процесса управления. Различают автоматизированные системы управления объектами (технологическими процессами – АСУТП, предприятием – АСУП, отраслью – ОАСУ) и функциональные автоматизированные системы, например, проектирование плановых расчётов, материально-технического снабжения и т.д.

В общем случае, систему управления можно рассматривать в виде совокупности взаимосвязанных управленческих процессов и объектов. Обобщенной целью автоматизации управления является повышение эффективности использования потенциальных возможностей объекта управления. Таким образом, можно выделить ряд целей:

­ предоставление лицу, принимающему решение (ЛПР), релевантных данных для принятия решений;

­ ускорение выполнения отдельных операций по сбору и обработке данных;

­ снижение количества решений, которые должно принимать ЛПР;

­ повышение уровня контроля и исполнительской дисциплины;

­ повышение оперативности управления;

­ снижение затрат ЛПР на выполнение вспомогательных процессов;

­ повышение степени обоснованности принимаемых решений.

В состав АСУ входят следующие виды обеспечений: информационное, программное, техническое, организационное, метрологическое, правовое и лингвистическое.

Основными классификационными признаками, определяющими вид АСУ, являются:

­ сфера функционирования объекта управления (промышленность, строительство, транспорт, сельское хозяйство, непромышленная сфера и т. д.);

­ вид управляемого процесса (технологический, организационный, экономический и т. д.);

­ уровень в системе государственного управления.

Функции АС устанавливают в техническом задании на создание конкретной АСУ на основе анализа целей управления, заданных ресурсов для их достижения, ожидаемого эффекта от автоматизации и в соответствии со стандартами, распространяющимися на данный вид АСУ. Каждая функция АСУ реализуется совокупностью комплексов задач, отдельных задач и операций. Функции АСУ в общем случае включают в себя следующие элементы (действия):

­ планирование и (или) прогнозирование;

­ учет, контроль, анализ;

­ координацию и (или) регулирование.

Необходимый состав элементов выбирают в зависимости от вида конкретной АСУ. Функции АСУ можно объединять в подсистемы по функциональному и другим признакам.

NDF (Network Diagnostics Framework) позволяет пользователям диагностировать и устранять неполадки, предоставляя диагностические оценки и информацию о последовательности операций, которая позволит устранить проблему. NDF упрощает и автоматизирует многие из стандартных операций по устранению неполадок и реализации решений для устранения проблем сети.

Теперь Microsoft поставляет NDF в составе Windows 7 наряду с другими новшествами, такими как доступ к утилите устранения неполадок из области уведомлений, апплет «Устранение неполадок компьютера» (Troubleshooting) в панели управления и трассировка сети средствами Event Tracing for Windows (ETW). Все они облегчают просмотр и сбор информации, необходимой для исследования неполадок сети, требующих исправления — автоматически или за счет вмешательства пользователя.

Устранение неполадок с использованием значка сети в области уведомлений

Утилиту устранения неполадок легко запустить, щелкнув правой кнопкой значок сети в области уведомлений рабочего стола Windows 7 и выбрав команду «Диагностика неполадок» (Troubleshoot problems). Откроется окно утилиты «Диагностика сетей Windows» (Windows Network Diagnostics) и запустится диагностика сети.

Поиск неполадок из Панели управления

В Windows 7 не нужно ждать, пока произойдет сбой сети, чтобы выполнить встроенную диагностику. Открыть сеанс поиска неполадок можно в любой момент, открыв служебную программу «Устранение неполадок компьютера» (Troubleshooting) на Панели управления, рис. 1. В данном случае служебная программа обнаружила, что у компьютера нет подключения к Интернету. Об этом говорит сообщение в верхней части страницы, при этом предлагается попытаться подключиться повторно.

Рис. 1 Открытие апплета устранения неполадок компьютера в панели управления.

Если щелкнуть «Сеть и Интернет» (Network and Internet), откроется диалоговое окно, показанное на рис. 2. Там можно выбрать один из семи вариантов исследования сетевых подключений, в том числе устранить неполадки подключения к Интернету, доступа к файлам и папкам на других компьютерах и печати.

Рис. 2 Поиск неполадок сети и подключения к Интернету.

При выборе любого из этих семи вариантов открывается мастер, помогающий выполнить диагностику неполадки и, если возможно, устранить ее автоматически или вручную. Средство диагностики также ведет запись в журнал трассировки событий (Event Tracing Log, ETL). Если неполадку не удается устранить, можно исследовать журнал самостоятельно или переслать его более сведущим людям. Для этого щелкните в диалогом окне поиска неполадок «Просмотр журнала» (View History). На рис.3 показан пример журнала ETL.

Рис. 3 Пример журнала ETL.

Каждая запись в журнале представляет отдельный сеанс поиска неполадок. Двойной щелчок сеанса открывает его журнал (рис. рис.4.

Рис. 4 Пример журнала устранения неполадок.

Чтобы просмотреть детали процедуры поиска неполадок обнаружения, щелкните ссылку «Обнаружение проблемы» (Detection details) - откроется окно, похожее на показанное на рис. 5.

Рис. 5 Типичное окно с подробностями поиска неполадок.

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

Просматривать и анализировать ETL-файлы можно средствами Сетевого монитора версии 3.3. Также для этой цели можно задействовать средство «Просмотр событий» и Tracerpt.exe. Можно преобразовать файл в XML или текстовый формат командой netsh trace convert. Подробные результаты сеанса поиска неполадок можно получить в виде CAB-файла, для чего нужно щелкнуть правой кнопкой сеанс в окне «Журнал устранения неполадок» (Troubleshooting History) и выбрать Сохранить как (Save As). Как и ETL-файлы, CAB-файл можно отправить в отдел поддержки для анализа.

Трассировка сети средствами Netsh.exe

Windows 7 включает новый контекст утилиты Netsh.exe - netsh trace, служащий для трассировки сети. Команды в этом контексте позволяют выборочно включать трассировку провайдеров или сценариев. Провайдер - это отдельный компонент в стеке сетевых протокол, такой как Winsock, TCP/IP, службы беспроводной локальной сети или NDIS. Сценарий трассировки - это набор провайдеров, реализующих одну функциональность, например совместный доступ к файлам или беспроводную локальную сеть. Чтобы избавиться от несущественных подробностей и уменьшить размер ETL-файла, можно применять фильтры.

Как правило, для выполнения детального анализа неполадок сети нужно предоставлять сотрудникам отдела поддержки или службе поддержки клиентов Microsoft как информацию о трассировки компонента, так и запись сетевого трафика во время проявления неполадки. До Windows 7 для получения этих данных приходилось выполнять две различных процедуры: использовать команды Netsh.exe для включения и отключения трассировке и задействовать сетевой анализатор, такой как Сетевой монитор, для записи сетевого трафика. После этого предстояло решить нелегкую задачу синхронизации информации из этих двух источников, чтобы определить, как сетевой трафик соотносится с событиями в журналах трассировки.

В Windows 7 при выполнении трассировки сети в контексте netsh trace ETL-файлы могут последовательно содержать информацию и сетевого трафика, и трассировки компонента. Полученные ETL-файлы можно изучать средствами Сетевого монитора версии 3.3, который предоставляет намного более эффективный интерфейс анализа и исследования сетевых неполадок (рис. На рис. 6 показан пример файла ETL, который просматривается в Network Monitor 3.3.

Рис. 6 Использование сетевого монитора версии 3.3 для просмотра сетевого трафика, сохраненного в ETL-файле.

Эта новая возможность позволяет не требовать от конечных пользователей или сотрудников отдела поддержки для записи сетевого трафика устанавливать и использовать Сетевой монитор на компьютере, где наблюдаются неполадки. Имейте в виду, что по умолчанию ETL-файлы, созданные в сеансах диагностики неполадок апплета «Устранение неполадок компьютера» (Troubleshooting) не содержат данных сетевого трафика.

Для последовательной регистрации данных трассировки и сетевого трафика многих компонентов сетевого стека (таких как Winsock, DNS, TCP, NDIS, WFP и т. п.) в Windows используется корреляция на основе идентификатора транзакции, которая называется группировкой и используется для сбора и записи трассировки и трафика в ETL-файле. Группировка в ETL-файлах позволяет исследовать всю транзакцию как единую последовательность взаимосвязанных событий.

Подробнее о командах Netsh.exe для трассировки см. врезку «Запуск и остановка трассировки в Netsh.exe».

При использовании Netsh.exe в Windows 7 могут создаваться два файла. ETL-файл содержит события трассировки компонентов Windows и, если требуется, сетевого трафика. По умолчанию ETL-файл называется Nettrace.etl и размещается в папке %TEMP%\\NetTraces. Можно задать другое имя и место, задав параметр tracefile=. Необязательный CAB-файл может содержать файлы нескольких типов, в том числе текстовые файлы, файлы реестра Windows, XML и другие - они содержат дополнительную информацию для поиска неполадок. CAB-файл также включает копию ETL-файла. По умолчанию CAB-файл называется Nettrace.cab и размещается в папке %TEMP%\NetTraces.

Трассировку средствами Netsh.exe можно совмещать с диагностированием с помощью апплета «Устранение неполадок компьютера» панели управления. Сначала выполните соответствующую команду Netsh.exe, чтобы запустить трассировку сценария, например: netsh trace scenario=internetclient report=yes. В апплете «Устранение неполадок компьютера» запустите сеанс устранения неполадок подключения к Интернету. По завершении сеанса выполните команду netsh trace stop. Теперь при просмотре журнала сеанса устранения неполадок будет доступен CAB-файл.
Боковая панель: Запуск и остановка трассировки в Netsh.exe

Чтобы запустить трассировку сети в Netsh.exe, прежде всего надо открыть окно командной строки с дополнительными правами. Чтобы получить список провайдеров трассировки, выполните команду netsh trace show providers. Получить список сценариев, можно командой netsh trace show scenarios. Чтобы получить список провайдеров в сценарии, выполните netsh trace show scenario ScenarioName.

Можно запустить трассировку одного или нескольких провайдеров или сценариев. Например, трассировка сценария InternetClient запускается командой netsh trace start scenario=internetclient. Чтобы запустить трассировку нескольких сценариев, надо последовательно их задать:netsh trace start scenario=FileSharing scenario=DirectAccess.

Чтобы создать CAB-файл с форматированным отчетом, добавьте параметр report=yes. Для задания имени и местоположения ETL- и CAB-файлов служит параметр tracefile=parameter. Если в ETL файле нужно записать еще и сетевой трафик, добавьте параметр capture=yes.

Вот пример команды, которая запустит трассировку сценария WLAN, создаст CAB-файл с форматированным отчетом, запишет сетевой трафик и сохранит файлы под именем WLANTest в папке C:\\Tshoot: netsh trace start scenario=WLAN capture=yes report=yes tracefile=c:\tshoot\WLANtest.etl.

Чтобы остановить трассировку, используйте команду netsh trace stop command.

Боковая панель: Использование сетевого монитора версии 3.3 для просмотра ETL-файлов

Чтобы Сетевой монитор версии 3.3 смог полностью отображать ETL-файлы, сгенерированные в Windows 7, нужно сконфигурировать полные анализаторы Windows. По умолчанию Сетевой монитор версии 3.3 использует стандартные анализаторы Windows. Чтобы конфигурировать полные анализаторы Windows, выберите Tools/Options/Parsers. В списке анализаторов выберите Windows/Stubs, чтобы отключить стандартные анализаторы и включить полные анализаторы, далее щелкните OK.

Джозеф Дейвис (Joseph Davies) - ведущий технический писатель в группе команды технических писателей по теме сетей Windows в Microsoft. Он является автором и соавтором нескольких книг, опубликованных в издательстве Microsoft Press, в числе которых «Windows Server 2008 Networking and Network Access Protection (NAP)», «Understanding IPv6, Second Edition» и «Windows Server 2008 TCP/IP Protocols and Services».

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

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

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

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

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

Измерение текущей загруженности канала связи сети и определение влияния величины загрузки канала связи на время реакции прикладного ПО.

Измерение числа коллизий в сети и выяснение причин их возникновения.

Измерение числа ошибок передачи данных на уровне канала связи и выяснение причин их возникновения.

Выявление дефектов архитектуры сети.

Измерение текущей загруженности сервера и определение влияния степени его загрузки на время реакции прикладного ПО.

Выявление дефектов прикладного ПО, следствием которых является неэффективное использование пропускной способности сервера и сети.

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

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

Хотелось бы обратить ваше внимание на два момента, тем более что о них часто забывают при тестировании кабельной системы сети с помощью сканера.

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

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

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