Сборка заданий (Лаб практикум) / AiPOS_Laboratornaia_rabota_N6__Matierialy

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

Емкость буфера для сбора пакетов у SNMP-агентов с поддержкой группы Packet Capture ограничена. Например, для концентраторов SuperStack II компании 3Com - 500 Кбайт. Этого часто недостаточно для локализации сложных дефектов в сети.

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

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

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

Анализаторы протоколов можно разделить на две категории: программные и аппаратные (или программно-аппаратные). Программный анализатор - это программа, которая устанавливается на компьютер с обычной сетевой платой. Анализатор протоколов переводит сетевую плату компьютера в режим приема всех пакетов (promiscous mode). Примерами программных анализаторов протоколов являются Observer и Distributed Observer компании Network Instruments, NetXray компании Network Associates, LANalyzer for Windows компании Novell и многие другие.

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

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

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

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

Аппаратный анализатор протоколов - это специализированный прибор или специализированная сетевая плата. И в том и в другом случае аппаратный анализатор имеет специальные аппаратные средства, с помощью которых он может проводить более детальную диагностику сети, чем при использовании программного анализатора. Аппаратные анализаторы выпускаются компаниями Network Associates, NetTest, Hewlett-Packard, RadCom, Wandel&Goltermann и другими.

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

Замечание N10. Если задача состоит только в диагностике локальной сети, то предпочтение следует отдать программному анализатору протоколов. Если вы планируете проводить диагностику как локальных, так и телекоммуникационных сетей (ATM, SDH, frame relay и т. п.), то лучше выбрать аппаратный анализатор протоколов.

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

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

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

Примером программного локального анализатора может служить LANalyzer for Windows компании Novell. Примером программного распределенного анализатора протоколов - Distributed Observer компании Network Instruments. Большинство аппаратных анализаторов протоколов являются, как правило, локальными. Исключение составляет Distributed Sniffer.

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

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

Чаще всего агенты программного распределенного анализатора протоколов являются сервисами NT или процессами под Windows 95. Таким образом, они могут работать на компьютерах обычных пользователей, не мешая им и одновременно диагностируя домен сети, куда они подключены.

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

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

Замечание N12. Для локализации ряда дефектов сети необходимо одновременно наблюдать за двумя и более сегментами (коллизионными доменами) сети. Это можно сделать только с помощью распределенного анализатора протоколов.

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

домене А, периодически "зависает" (работает неустойчиво). При этом зависание происходит в непредсказуемые моменты времени.

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

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

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

КАЖДОМУ СВОЕ

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

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

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

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

При выборе в качестве критерия интегрального показателя (стоимость+возможности решения задач реактивной и упреждающей диагностики), наилучшими характеристиками, с нашей точки зрения, обладают распределенные анализаторы протоколов. Они иногда уступают средствам сетевого мониторинга в решении вопросов упреждающей диагностики - прежде всего, в тех случаях, когда сеть построена на базе коммутатора, у которого нет зеркального порта и отсутствуют агенты для конкретного типа ОС. Однако тенденция их развития такова, что в ближайшем будущем этот недостаток будет устранен. Так, например, компания Network Instruments объявила о выходе новой версии анализатора Distributed Observer с поддержкой SNMP-агентов с RMON MIB.

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

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

ЗАКЛЮЧЕНИЕ

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

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

Приложение 1

Сетевые протоколы

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

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

Принцип работы протокола

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

1. Разбивает данные на небольшие фрагменты — пакеты

2. Добавляет к пакетам информацию адресации, идентифицирующую целевой компьютер

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

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

2. Удаляет служебную информацию, добавленную передающим компьютером

3. Выполняет сборку пакетов данных в оригинальное сообщение

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

Сетевые пакеты

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

Структура пакета Пакет включает в себя следующие компоненты:

• Адрес отправителя, задающий адрес передающего пакет компьютера

• Адрес получателя

• Команды, сообщающие компьютеру, как передавать данные

• Информацию сборки (если пакет является частью длинного сообщения)

• Данные, передаваемые на удаленный компьютер

• Информацию контроля ошибок, обеспечивающую доставку верных данных Эти компоненты объединяются в три раздела:

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

• Данные. Фактические передаваемые данные. Их длина может быть различной — от 48 байт до 4 Кбайт (в зависимости от типа сети).

• Завершающая часть. Содержимое этой части (и само ее наличие) зависит от конкретного типа сети, но обычно включает в себя контрольную сумму (CRC, Cyclic Redundancy Check). CRC по­могает сети определить, был ли испорчен, пакет при передаче.

Состав пакета представлен на рис. 3.15.

Сборка пакетов Каждый уровень модели OSI добавляет к пакету некоторую информацию. Инфор­мация каждого уровня должна считываться соответствующим уровнем OSI на компьютере-получателе. Например, информация, добавляемая на сетевом уровне в одном компьютере, будет считываться сете­вым уровнем другой машины. Рис. 1.16 показывает, как информация, добавляемая на каждом уровне, считывается соответствующим уровнем на другом компьютере. Компоненты сетей Microsoft в рамках модели OSI

Маршрутизация

Сначала локальные сети редко соединялись друг с другом, но, начиная с середины 80-х годов, ком­пании стали понимать преимущества взаимодействия ЛС и объединения их в более крупные сетевые структуры.

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

Стеки протоколов

Работая совместно, протоколы реализуют уровень или уровни модели OSI. Это называется стеками или комплектами протоколов. Каждый уровень обрабатывает свою часть процесса коммуникаций, имеет собственные правила и требования. Стек уровней OSI показан в таблице Я.2. Чем выше в стеке нахо­дится протокол, тем более сложным он должен быть.

Таблица 3.2

Уровни стека OSI

7.	Прикладной уровень	Реализует средства непосредственной поддержки приложений пользователя
6.	Представительный уровень	Транслирует форматы данных и добавляет шифрование
5.	Сеансовый уровень	Создает и прерывает соединения (сеансы), выполняет администрирование сеансов
4.	Транспортный уровень	Добавляет идентификаторы процессов и обрабатывает информацию контроля Ошибок
3.	Сетевой уровень	Управляет последовательностью межсетевого обмена, адресами и маршрутизацией
1
2.	Канальный уровень	Добавляет информацию контроля ошибок и организует биты а кадры
1	физический уровень	Передает и принимает биты в среде передачи данных

Привязка протоколов

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

Процесс привязки (binding) ассоциирует стек протоколов с сетевым драйвером и платой сетевого интерфейса (адаптером). Одна плата допускает привязку нескольких протоколов. Например, к одному и тому же адаптеру Ethernet можно привязать и TCP/IP, и IPX/SPX. Кроме того, на одном компьютере несколькими интерфейсными адаптерами (например, сервере, взаимодействующем с локальной сетью с базовой магистралью) можно связать один протокол с двумя или более сетевыми платами. Процесс привязки применяется на разных уровнях OSI. Это позволяет привязать один стек прого­нов к другому. Драйвер устройства (реализующий канальный уровень) привязывается к плате сетевого ггерфейса (физический уровень). TCP/IP можно привязать к драйверу устройства, а сеансовый уровень –NetBIOS - к TCP/IP.

Протоколы, ориентированные и не ориентированные установление соединения

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

Системы, не ориентированные на установление соединения, реализуют сквозную передачу потока мых, поэтому в них нет непроизводительных потерь из-за гарантированной доставки данных с помощью протоколов или последовательного упорядочения пакетов. Это позволяет подобным системам Встать очень быстро. Примером протокола Internet, не ориентированного на установление соединения, является UDP/IP (User Datagram Protocol/Internet Protocol).

Системы, ориентированные на установление соединения, предполагают, что в процессе передачи которые данные могут теряться или поступать в некорректном порядке. Протоколы, ориентированные на установление соединения, гарантируют получение адресатом данных в правильном' порядке. Для ото данные сохраняются, и согласовывается повторная их передача. Лишь затем последовательные цшые передаются протоколам более высокого уровня. Это означает, что любое приложение может пользовать протокол, ориентированный на установление соединения, для надежной доставки переда-им данных. Примером протокола Internet, ориентированного на установление соединения, является TCP/IP (Transmission Control Protocol/Internet Protocol).

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

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

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

Стандартные стеки протоколов

Сегодня в сетях применяется несколько стандартных стеков протоколов:

• Комплект протоколов ISO/OSI

• IBM SNA (Systems Network Architecture)

• DECnet компании Digital

• Novell NetWare

• AppleTalk компании Apple

• TCP/IP, комплект протоколов Internet

Протоколы в стеках реализуются на разных уровнях семиуровневой модели OSI, но их можно при­близительно разбить на три типа:

• Протоколы приложений обеспечивают взаимодействие и обмен данными для прикладных программ.

• Транспортные протоколы устанавливают сеансы коммуникаций между компьютерами.

• Сетевые протоколы выполняют такие функции, как формирование информации адресации и маршрутизации, контроль ошибок и выработка запросов на повторную передачу.

Эти три типа представлены на рис. 3.17.

Сетевые протоколы, поставляемые Microsoft

Сетевые продукты корпорации Microsoft поставляются с тремя сетевыми транспортными протоко­лами, каждый из которых предназначен для сетей разных размеров и с различными требованиями:

• NetBEUI

Компоненты сетей Microsoft в рамках модели OSI

• NWLink

• TCP/IP

Каждый из сетевых транспортных протоколов имеет свои достоинства и недостатки. В целом Net­BEUI предназначен для небольших односерверных сетей. NWLink разработан для использования в сетях среднего размера (возможно, в одной организации) или в сетях, где необходим доступ к файловым серверам Novell NetWare. TCP/IP — сложный транспортный протокол, подходящий для таких всемир­ных сетей, как Internet.

NetBEUI NetBEUI означает "расширенный пользовательский интерфейс NetBIOS" (NetBIOS Extended User Interface), a NetBIOS — "сетевая базовая система ввода/вывода" (Network Basic Input/Output System). NetBEUI реализует транспортный протокол NetBIOS Frame (NBF), который был разработан IBM в середине 80-ых годов для поддержки рабочих групп в локальных сетях в среде OS/2 и LAN Manager.

Когда IBM создавала NetBEUI, этот протокол не предназначался для объединения в сеть IBM-совмес­тимых ПК в масштабе предприятия. Он проектировался для рабочих групп, насчитывающих от 2 до 200 компьютеров. NetBEUI нельзя маршрутизировать между сетями, поэтому его использование огра­ничивается небольшими локальными сетевыми средами, состоящими из клиентов и серверов Microsoft и IBM. Microsoft включила в Windows NT обновленную версию NetBEUI IBM - NetBEUI 3.0. Протокол NetBEUI имеет в том числе и следующие преимущества:

• Высокую скорость работы в небольших сетях

• Большее, по сравнению с предыдущими версиями, число сеансов (более 2540