Материал: Методические разработки к лабораторной работе «Принципы управления и мониторинга в локальных сетях. Управление коммутатором Cisco Catalyst» для студентов специальностей 210406, 210400, 210403, 210404 (90

программным обеспечением (firmware). Терминал должен поддерживать определенную систему команд (например, VT-52, VT-100), на которую рассчитано управляемое устройство. В противном случае не будут корректно обрабатываться управляющие коды (перемещение курсора, стирание символа и экрана) и вид диалогов будет сильно отличаться от приведенного в документации на устройство. В качестве терминала часто используют ПК с программной эмуляцией терминала (например, HyperTerminal в Windows), подключенный через СОМ-порт.

Консольное управление позволяет настраивать любые параметры устройства, независимо от состояния сети передачи данных. С его помощью настраивают параметры для внутриполосного управления (IP-адрес и маска, имя устройства, адрес маршрутизатора, параметры SNMP, Telnet, BootP, списки адресов узлов, которым разрешено управление данным устройством, пароль на доступ). Здесь же можно управлять и функциональными свойствами устройств (например, устанавливать режимы работы портов, разрешенные МАС-адреса подключаемых устройств, конфигурировать VLAN для коммутаторов, настраивать маршрутизаторы и т. п.). С консоли можно получать и статистические данные, если они собираются устройством. Установленные параметры конфигурирования могут быть сохранены в энергонезависимой памяти устройства, как правило, для этого выполняется явная команда. Если сохранение не выполнить, то после рестарта устройства (по аппаратному сбросу или включению питания) восстановятся прежние сохраненные значения параметров.

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

2.2. Управление через Telnet

Управление через Telnet позволяет удаленно управлять устройствами по сети передачи данных (внутриполосное управление). По сути, это вариант консольного управления, но без специальных линий связи. Пользовательский интерфейс управления при этом выглядит так же и определяется встроенным ПО управляемого устройства. Управление через Telnet требует использования в сети передачи данных протокола IP. Для него на одном из компьютеров сети необходимо запустить приложение Telnet — эмуляцию терминала со связью через протокольный стек TCP/IP. В этом приложении необходимо установить связь с управляемым устройством, указав его IP-адрес или имя (если оно прописано в DNS) и введя пароль. После установления соединения компьютер будет играть роль удаленного терминала управляемого устройства, работа с которым аналогична вышеописанному консольному управлению.

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

6

установки. В целях обеспечения безопасности на управляемом устройстве задают пароль доступа, причем могут быть заданы разные пароли для доступа только по чтению (read only) и с разрешением записи (read-write). Время предъявления пароля (login timeout) и количество попыток ввода (login retries) могут быть ограничены, и по срабатыванию ограничения соединение разрывается. Можно задавать и время неактивности оператора (inactivity timeout), после которого соединение разрывается. Также задается и список IPадресов узлов (allowed source IP address), с которых разрешены сеансы Telnet.

Управление через Telnet позволяет с одного компьютера управлять множеством устройств, но при этом требует «живой» сети с протоколом IP. Как

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

ипароли доступа). Для повышения безопасности необходимо позаботится о сохранности передаваемых данных (к примеру, весть трафик системы управления передавать в отдельной VLAN). Отдельные устройства поддерживают безопасный протокол SSH, в котором предусмотрено шифрование передаваемых данных.

2.3. Протокол управления SNMP

Протокол прикладного уровня SNMP (Simple Network Management Protocol — простой протокол сетевого управления) является частью протокольного стека TCP/IP, хотя его сообщения могут пересылаться и по протоколу IPX/ SPX.

Протокол SNMP оперирует следующими понятиями:

-Управляемое устройство (managed devices) — узел управляемой сети (промежуточный или конечный), снабженный агентом. Управляемое устройство способно собирать и хранить управляющую информацию и обмениваться ею по протоколу SNMP.

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

-Система сетевого управления NMS (network-management system) — ком-

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

Протокол определяет набор базовых команд взаимодействия NMS с объектами:

-Get — получение значений объектов (наблюдение за устройством) по инициативе NMS.

-GetNext — вариант команды для последовательного обращения к однотипным объектам (например, элементам таблиц маршрутов или таблиц состояния портов).

-GetBulk — получение значений блока объектов (только в SNMP v.2).

7

-Set — установка значений объектов (управление устройством) по инициативе NMS.

-Trap — асинхронное сообщение (прерывание) от устройства к NMS о каком-либо событии.

-Inform — передача сообщений между двумя NMS (только в SNMP v.2). Сообщения SNMP передаются с помощью протокола UDP

(негарантированная доставка, без подтверждения), хотя возможна настройка и на гарантированный транспорт TCP, а также IPX. Сообщения имеют заголовок с идентификатором версии и строкой «общности» — community и блок протокольных данных (PDU). Строка community используется как идентификатор группы устройств, общающихся по SNMP. Это примитивное средство обеспечения безопасности: агент будет отвечать на запрос, если в нем указана та же строка (чувствительно к регистру), что и сконфигурированная у агента. NMS не будет воспринимать сообщение с «неправильной» строкой. Поскольку строки community передаются по сети в открытом виде, безопасность весьма условна. Протокольный блок (PDU) содержит идентификатор типа сообщения (код команды), несколько служебных полей и список имен и значений объектов.

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

Информационная база управления MIB (Management Information Base) SNMP представляет собой иерархически организованную систему объектов. Каждый объект MIB является одним из множества параметров управляемого устройства. Объекты могут быть двух типов. Скалярный (scalar) объект определяет единичный параметр. Табличный (tabular) объект описывает множество однотипных параметров, объединенных в таблицу. Каждый объект имеет идентификатор, однозначно определяющий его положение в иерархии.

Информационная база MIB I (RFC 1156, 1990 г.) была определена для маршрутизаторов TCP/IP. В нее входит 114 объектов, разделенных на 8 групп. База предоставляет общую системную информацию об устройстве (например, тип устройства, время непрерывной работы), параметры сетевых интерфейсов, таблицу трансляции адресов и основные данные по протоколам IP, ICMP, TCP, UDP, EGP. Предусматривалось только чтение данных. Эта база была расширена до 10 групп и 185 объектов в версии MIB II (RFC 1213, 1992 г.), и появилась возможность управления (команда записи). MIB II позволяет, например, собирать статистические данные по пакетам определенных типов (одноадресные, широковещательные), принятых и переданных интерфейсами.

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

Минимально необходимые программные средства взаимодействия с конкретными устройствами для популярных ОС (Windows, UNIX и т. д.), как

8

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

До использования SNMP управляемое устройство должно быть сконфигурировано. Ему должен быть назначен IP-адрес, маска подсети и адрес маршрутизатора в соответствии с местом его установки (в случае использования не IP-протокола конфигурирование будет иным). Также должен быть задан адрес узла (список узлов), на который посылаются сообщенияпрерывания по событиям, и, возможно, определен список событий, по которым посылаются прерывания. Необходимо также занести корректное значение строки community, помня о его чувствительности к регистру. Строка community может быть задана отдельно для доступа только по чтению (SNMP read community, по умолчанию часто используется слово public), для доступа с разрешенной записью (SNMP read-write community, по умолчанию слово private) и для прерываний (SNMP trap community).

2.4. Удаленный мониторинг — RMON и RMON2

С появлением интеллектуальных хабов и коммутаторов в них стали встраивать зонды для мониторинга —RMON (Remote MONitoring) Probe. Взаимодействие с этими зондами, как правило, ведется по протоколу SNMP. Для зондов, поначалу работавших только на МАС-уровне, был принят стандарт RMON. В нем определена база MIB из 9 групп объектов управления и наблюдения (RMON Groups). Первые 3 группы специфичны для технологии Ethernet с ее коллизиями, слишком короткими или длинными кадрами и т. п. Остальные группы не привязаны к конкретной реализации МАС-уровня, а для Token Ring выделена группа с номером 10. Впоследствии определили дополнительные 10 групп для наблюдений на более высоких уровнях —

RMON2 (RFC 2074).

Группы, специфические для МАС-уровня Ethernet (RFC 1271):

-Statistics (статистика) — информация об активности сети (порта, сегмента): общее число переданных и принятых кадров и байт информации, количество нормальных кадров и кадров с разными типами ошибок (см. 6.1), количество коллизий, распределение кадров по размерам (64, 65-127, 128-255, 256-511, 512-1023, 1024-1518 байт), количество широковещательных и многоадресных кадров.

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

-Alarm (тревоги) — установка порогов на измеряемые параметры (счетчики, измерители уровней), по достижении которых агент генерирует

9

сообщение-прерывание. На каждый параметр устанавливается два порога: один на превышение, другой — на возврат к норме.

МАС-независимые группы:

-Host (хосты) — статистические данные (аналогичные 1 группе), собираемые по каждому обнаруженному узлу (по МАС-адресам).

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

-Matrix (матрица трафика) — отслеживание диалогов между парами узлов (уровень трафика и ошибок в каждом направлении).

-Filter (фильтр) — установка специфических признаков фильтрации кадров для захвата.

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

-Event (события) — управление посылкой прерываний по событиям (превышение порогов и возврат, начало и окончание захвата и т. п.).

Группы RM0N2 (RFC 2021 и 2074) предназначены для мониторинга сетевого и прикладного уровней.

-Protocol Directory (каталог протоколов) — список протоколов, которые могут отслеживаться зондом.

-Protocol Distribution (распределение протоколов) — статистика (распределение и тенденции) трафика по протоколам (IP, IPX, DECnet, AppleTalk...).

-Address Mapping (карта адресов) — таблица соответствия сетевых и МАС-адресов узлов.

-Network-Layer Host (хосты на сетевом уровне) — статистика трафика (входного и выходного) по каждому обнаруженому в сети хосту.

-Network-Layer Matrix (матрица сетевого уровня) — статистика трафика диалогов между парами хостов.

-Application-Layer Host (хосты на прикладном уровне) — статистика трафика (входного и выходного) хоста по конкретному протоколу (вплоть до прикладного уровня). Позволяет определять трафик таких приложений, как

Web, Telnet, Lotus Notes и т. п.

-Application-Layer Matrix (матрица прикладного уровня) — статистика трафика диалога хостов по конкретным протоколам вплоть до прикладного уровня.

-User History Collection (программируемый сбор истории) — периодическая выборка значений параметров по выбору пользователя (из списка группы статистики RMON1).

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

10