Построение коммутируемых компьютерных сетей

Функции управления коммутаторами

Разбить на страницы
Показывать лекцию целиком

Управление множеством коммутаторов

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

  • физическое стекирование коммутаторов;
  • виртуальное стекирование коммутаторов.
  • Оба эти подхода предполагают объединение коммутаторов в физическую или логическую группу, которая будет управляться через единый IP-адрес.

    Объединение коммутаторов в физический стек

    При физическом стекировании коммутаторы представляют собой одно логическое устройство, что обеспечивает удобство управления и мониторинга их параметров. Для управления коммутаторами можно использовать интерфейс командной строки (CLI), Web-интерфейс, Telnet, протокол SNMP, и только одному коммутатору (мастеру-коммутатору) потребуется присвоение управляющего IP-адреса.

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

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

    В примере, приведенном на рис. 26.1 , показано, что данные от коммутатора 2 передаются не по кругу (через коммутаторы 3, 4, 5 и т.д.), а непосредственно в направлении коммутатора 9 (через коммутаторы 1,12,11,10). При этом следует отметить, что весь трафик в стеке передается одновременно, и локальный трафик не оказывает влияния на трафик, циркулирующий внутри стека (рис. 26.2).

    (рис 26.1) Пример выбора оптимального пути передачи пакета в стеке типа "кольцо" (рис 26.2) Потоки трафика в стеке

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

    В стекируемых коммутаторах D-Link для повышения отказоустойчивости и производительности стека, реализованы следующие механизмы:

  • механизм Resilient Master Technology (RMT) обеспечивает непрерывную работу стека при выходе какого-либо устройства из строя, замене, добавлении и удалении коммутаторов, а также позволяет автоматически назначать нового мастера-коммутатора в случае неработоспособности текущего и автоматически восстанавливать работу стека;
  • механизм Cross Device Trunking (CDT) позволяет объединять несколько физических портов разных коммутаторов стека в один агрегированный канал с повышенной полосой пропускания. При этом такая логическая магистраль будет продолжать функционирование, даже если какой-либо порт или коммутатор выйдут из строя;
  • технология SmartRoute позволяет копировать таблицы коммутации 3-го уровня, хранимые на мастере-коммутаторе, на все другие устройства стека (в том случае, если стек построен на коммутаторах L3). Благодаря этому каждый коммутатор стека может маршрутизировать трафик локально, не пересылая его на мастер-коммутатор, что уменьшает потребление полосы пропускания между коммутаторами и повышает отказоустойчивость стека.
  • Роли коммутаторов стека

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

    Основной мастер (Primary Master) — основной мастер-коммутатор является ведущим устройством стека и единой точкой управления. Он следит за нормальной работой стека, топологией, назначает идентификаторы устройствам стека (Box ID), синхронизирует конфигурации и передает команды другим коммутаторам. Роль основного мастера может быть присвоена коммутатору вручную, путем назначения наивысшего приоритета администратором сети, или определена автоматически в процессе выборов.

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

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

  • резервный мастер стал основным мастером;
  • резервный мастер вышел из строя или удален из стека;
  • оба, и основной, и резервный мастер, вышли из строя или удалены из стека.
  • Выборы основного мастера-коммутатора стека

    После того как коммутаторы будут объединены в стек, каждое устройство начнет собирать информацию (такую как приоритет, МАС-адрес) о соседних коммутаторах и сохранять ее во временной базе данных топологии стека (self temp stacking topology database). Далее коммутаторы приступят к выбору основного мастера-коммутатора стека. Основной мастер выбирается путем сравнения приоритетов (по умолчанию приоритет 32) и МАС-адресов коммутаторов стека.

    (рис 26.3) Процесс выбора основного мастера на основании приоритетов

    Основным мастером становится коммутатор с наименьшим значением приоритета. Если приоритеты коммутаторов равны, то будет выбран коммутатор с наименьшим значением МАС-адреса.

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

    Как только выбраны основной и резервный мастер, всем коммутаторам стека будут присвоены порядковые номера Box ID. Если в настройках коммутатора параметр Box ID установлен в Auto, основной мастер назначит каждому устройству стека порядковый номер в соответствии с правилами автоматического назначения номеров (основному мастеру в автоматическом режиме присваивается номер 1). Эта информация о топологии будет разослана всем устройствам стека.

    (рис 26.4) Процесс выбора основного мастера на основании МАС-адресов при равном значении приоритетов (рис 26.5) Назначение порядковых номеров в автоматическом режиме

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

    Следует отметить, что основной мастер-коммутатор и резервный мастер-коммутатор не имеют фиксированных номеров, т.е. основному мастеру может быть присвоен Box ID, отличный от 1.

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

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

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

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

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

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

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

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

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

    Пример настройки стекирования

    (рис 26.6) Коммутаторы, объединенные в стек

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

    Настройка коммутатора 1

    config stacking mode enable
    config box_priority current_box_id 1 priority 1
    

    Настройка коммутатора 2

    config stacking mode enable
    config box_priority current_box_id 1 new_box_id 2
    config box_priority current_box_id 2 priority 2
    

    Виртуальный стек. Технология Single IP Management (SIM)

    Технология Single IP Management (SIM) является простым и удобным способом сетевого управления. Она разработана для управления группой коммутаторов, называемых SIM-группой, как единым устройством. При этом для управления SIM-группой требуется только один IP-адрес, который назначается выделенному коммутатору группы (Commander switch).

    Технология SIM позволяет:

  • устранить ограничения на модели коммутаторов, объединяемых в стек;
  • уменьшить количество управляющих IP-адресов в сети;
  • устранить необходимость использования специализированных модулей и кабелей, предназначенных для стекирования; преодолеть ограничения, связанные с длиной кабелей в стеке.
  • В отличие от стеков, построенных с использованием традиционных методов стекирования, виртуальный стек на основе технологии SIM не ограничивается 6-ю или 12-ю коммутаторами. В SIM-группу может входить до 32-х коммутаторов любых моделей, поддерживающих функции Single IP Management. Это означает, что виртуальный стек может включать коммутаторы разного типа, от недорогих коммутаторов 2-го уровня до высокопроизводительных коммутаторов на основе шасси (для ядра сети).

    Объединение коммутаторов в SIM-группу не требует использования специальных соединительных кабелей. Трафик, передаваемый между устройствами стека, проходит через интерфейсы Fast Ethernet, Gigabit Ethernet или 10 Gigabit Ethernet по обычным медным или оптическим кабелям. Отказ от использования специализированных стекирующих кабелей позволяет преодолеть ограничения, связанные с их длиной. Устройства SIM-группы могут быть подключены друг к другу через промежуточные устройства, не поддерживающие технологию SIM. Объединение коммутаторов в SIM-группу не влияет на их нормальное функционирование.

    (рис 26.7) Технология SIM Внимание: SIM является дополнительной функцией коммутаторов и может быть активизирована или отключена через Web-интерфейс или CLI. По умолчанию эта функция на коммутаторе отключена.

    Технология SIM предусматривает три роли, которые могут быть назначены коммутаторам группы:

  • Commander Switch (CS) — это коммутатор, который вручную настраивается администратором сети как управляющее устройство SIM-группы. В SIM-группе может быть только один Commander Switch. CS обладает следующими характеристиками:
  • ему присвоен IP-адрес;
  • он не является Commander Switch или Member Switch другой SIM-группы;
  • он подключен к коммутаторам Member Switch через управляющую VLAN (VLAN, к которой привязан управляющий интерфейс коммутатора System. По умолчанию управляющей VLAN является default VLAN);
  • Member Switch (MS) — коммутатор, который вступил в SIM-груп-пу и доступен через Commander Switch. Member Switch обладает следующими характеристиками:
  • он не является Commander Switch или Member Switch другой SIM-группы;
  • он подключен к Commander Switch через управляющую VLAN;
  • Candidate Switch (CaS) — это коммутатор, который готов вступить в SIM-группу (стать Member Switch), используя либо автоматический метод, либо ручную настройку. Коммутатор, настроенный как Candidate Switch, не является членом SIM-группы. Он обладает следующими характеристиками:
  • он не является Commander Switch или Member Switch другой SIM-группы;
  • он подключен к Commander Switch через управляющую VLAN.
  • Все коммутаторы, объединенные в одну SIM-группу, должны принадлежать одной IP-подсети (широковещательному домену). В пределах одной подсети может быть создано несколько SIM-групп, но при этом каждый коммутатор должен принадлежать только одной SIM-группе. Каждая группа может содержать до 32 коммутаторов (от 0 до 31), включая Commander Switch (его номер 0). Если в сети настроено несколько VLAN, SIM-группа будет использовать только управляющую VLAN любого коммутатора.

    По умолчанию после активизации функции SIM всем коммутаторам присваивается роль "Candidate Switch". Это означает, что они смогут стать членами SIM-группы (Member Switch), как только получат запрос от Commander Switch.

    После того, как одному из коммутаторов группы была присвоена роль "Commander Switch", он начинает формировать SIM-группу, добавляя в нее новых членов. Для этого Commander Switch просматривает список кандидатов (Candidate Switch) и отправляет им периодические запросы. Кандидат отправляет Commander Switch ответ, содержащий информацию о нем, что позволяет ему стать членом SIM-группы. Если коммутатор-кандидат имел ранее сконфигурированный пароль, он не сможет стать членом группы до тех пор, пока не будут введены его аутентификационные данные.

    Можно добавлять членов группы, используя Web-интерфейс. Функционал SIM встроен в Web-интерфейс управления коммутаторов и не требует установки дополнительного ПО.

    (рис 26.8) Функция SIM в Web-интерфейсе

    После настройки Commander Switch в папке Single IP Management Web-интерфейса станет доступна опция Topology. Эта опция позволяет настраивать коммутаторы и управлять ими внутри SIM-группы. При выборе пункта View окна Topology появится топологическая карта, показывающая, как подключены устройства внутри SIM-группы. Топологическая карта автоматически обновляется каждые 20 секунд.

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

    В топологической карте используются следующие иконки для обозначения Commander Switch, Member Switch и Candidate Switch.

    (рис 26.9) Топологическая карта (рис 26.10) Иконки, используемые для представления устройств в топологической карте

    Протокол SNMP

    Протокол SNMP (Simple Network Management Protocol) является протоколом 7 уровня модели OSI, который специально разработан для управления и мониторинга сетевых устройств. Протокол SNMP входит в стек протоколов TCP/IP и позволяет администраторам сетей получать информацию о состоянии устройств сети, обнаруживать и исправлять неисправности и планировать развитие сети.

    В настоящее время существует три версии протокола SNMP: SNMP v1 (RFC 1157), SNMP v2c (RFC 1901-1908) и SNMP v3 (RFC 3411-3418). Эти версии отличаются предоставляемым уровнем безопасности при обмене данными между менеджером и агентом SNMP. Коммутаторы D-Link поддерживают все три версии протокола.

    Компоненты SNMP

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

    (рис 26.11) Компоненты SNMP

    Менеджер SNMP (SNMP Manager) — это программное обеспечение, установленное на рабочей станции управления, наблюдающее за сетевыми устройствами и управляющее ими.

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

    База управляющей информации (Management Information Base, MIB) — это совокупность иерархически организованной информации, доступ к которой осуществляется посредством протокола управления сетью.

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

    База управляющей информации SNMP

    Базы управляющей информации описывают структуру управляющей информации устройств и состоят из управляемых объектов (переменных).

    Управляемый объект (или MIB-объект) — это одна из нескольких характеристик управляемого сетевого устройства (например, имя системы, время, прошедшее с ее перезапуска, количество интерфейсов устройства, IP-адрес и т.д.).

    Обращение к управляемым объектам MIB происходит посредством идентификаторов объекта (Object IDentifier, OID). Каждый управляемый объект имеет уникальный идентификатор в пространстве имен OID и контролируется агентством IANA. Пространство имен OID можно представить в виде иерархической структуры с корнем без названия, идентификаторы верхних уровней которой отданы организациям, контролирующим стандартизацию, а идентификаторы нижних уровней определяются самими этими организациями. Каждая ветвь дерева OID нумеруется целыми числами слева направо, начиная с единицы. Идентификатор представляет собой последовательность целых десятичных цифр, разделенных точкой, записанных слева направо и включает полный путь от корня до управляемого объекта. Числам могут быть поставлены в соответствие текстовые строки для удобства восприятия. В целом структура имени похожа на систему доменных имен Интернета (Domain Name System, DNS).

    Каждая MIB (в настоящее время основными стандартами на базы управляющей информации для протокола SNMP являются MIB-I и MIB-II) определяет набор переменных, т. е. определенную ветку дерева OID, описывающую управляющую информацию в определенной области. Например, ветка 1.3.6.1.2.1.1 (символьное эквивалентное имя: iso.org.dod.inter-net.mgmt.mib-2.system) описывает общую информацию о системе.

    (рис 26.12) Пространство имен OID

    Производители сетевого оборудования определяют частные ветви пространства имен OID (группа объектов private (4)), куда помещают управляемые объекты для своей продукции. Так, D-Link в качестве вершины иерархии для своей продукции использует OID, равный 1.3.6.1.4.1.171.

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

    Типы сообщений протокола SNMP

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

  • Get-Request — запрос значений одного или нескольких объектов;
  • Get-Next-Request — запрос значения следующего объекта в соответствии с алфавитным порядком идентификаторов OID;
  • Set-Request — запрос на изменение значения одного или нескольких объектов;
  • Get(Set)-Reply — получение ответа от агента на сообщение Get-Request, Get-Next-Request или Set-Request.
  • Сообщение Trap (ловушка) используется агентом SNMP для асинхронного сообщения менеджеру SNMP о событии, происходящем на управляемом сетевом устройстве. События могут быть серьезные, например перезагрузка устройства, или менее серьезные, например изменение состояния порта.

    Версия SNMP v.2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько переменных за один запрос.

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

    (рис 26.13) Типы сообщения протокола SNMP

    Безопасность SNMP

    В протоколе SNMP v.1 и v.2c предусмотрена аутентификация пользователей, которая выполняется с помощью строки сообщества (Community string). Строки Community string функционирует подобно паролю, который разрешает удаленному менеджеру SNMP доступ к агенту. Менеджер и агент SNMP должны использовать одинаковые строки Community string, т.к. все пакеты от менеджера SNMP, не прошедшего аутентификацию, будут отбрасываться. В коммутаторах с поддержкой SNMP v.1 и v.2c используются следующие Community string по умолчанию:

  • public — позволить авторизованной рабочей станции читать (право "read only") MIB-объекты;
  • private — позволить авторизованной рабочей станции читать и изменять (право "read/write") MIB-объекты.
  • Внимание: Community string передаются по сети в открытом виде.

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

    На коммутаторе SNMP можно создавать группы со списками пользователей (менеджеров SNMP) и настраивать для них общий набор привилегий. Помимо этого, для каждой группы может быть установлена версия используемого ею протокола SNMP. Таким образом, можно создать группу менеджеров SNMP, которым позволено просматривать информацию с правом "read only" или получать ловушки (trap), используя SNMP v.1, в то время как другой группе можно настроить наивысший уровень привилегий с правами "read/write" и возможность использования протокола SNMP v.3.

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

    Пример настройки протокола SNMP

    На рис. 26.14 показана схема сети, в которой управление коммутатором может выполняться через управляющую консоль SNMP по протоколу SNMP v.2. В случае обнаружения SNMP-агентом коммутатора каких-либо неполадок он будет отправлять сообщения Trap менеджеру SNMP. В целях повышения безопасности строки Community string по умолчанию удалены.

    (рис 26.14) Схема сети

    Настройка коммутатора

  • Активизировать функцию SNMP глобально на коммутаторе.
    enable snmp
    
  • Удалить строки Community string по умолчанию и создать новые строки Community string.
    delete snmp community public
    delete snmp community private
    create snmp community dlinkro view CommunityView read_only
    create snmp community dlinkrw view CommunityView read_write
    
  • Задать параметры получателя сообщений Trap от агента и активизировать функцию отправки сообщений Trap.
    create snmp host 192.168.1.100 v2c dlinkrw
    enable snmp traps
    enable snmp authenticate_traps
    
  • RMON (Remote Monitoring)

    Спецификация RMON MIB (Remote MONitoring, удаленный мониторинг) была разработана сообществом IETF для поддержки мониторинга и анализа протоколов в локальных сетях. Первая версия RMON v.1 (RFC 2819) основывается на мониторинге информации сетей Ethernet и Token Ring. Ее расширением является RMON v.2 (RFC 2021), которая добавила к уже имеющимся средствам мониторинга поддержку мониторинга на сетевом уровне и уровне приложений модели OSI.

    Реализация RMON основывается на модели "клиент/сервер". На устройствах мониторинга, называемых в терминологии RMON "зондами" (probe), установлено специальное программное обеспечение — агент RMON, которое собирает информацию и анализирует пакеты. Зонды действуют как серверы, а приложения сетевого управления, установленные на станциях управления сетью, исполняют роль клиентов. Агенты RMON могут как размещаться на автономных устройствах, так и встраиваться в коммутаторы, маршрутизаторы и другие сетевые устройства. Станция управления сетью и распределенные зонды RMON взаимодействуют по сети по протоколу SNMP.

    (рис 26.15) Консоль и зонд RMON

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

    RMON поставляет информацию в группы RMON MIB, каждая из которых поддерживает определенный набор данных, удовлетворяющих общим требованиям мониторинга сети. RMON v.1 содержит десять групп RMON MIB, а RMON v.2 добавляет к ним еще девять групп RMON MIB. Вместе RMON v.1 и RMON v.2 позволяют собирать статистику о трафике на всех уровнях модели OSI. Из-за того, что при выполнении обработки данных на ресурсы устройств мониторинга ложится большая нагрузка, то производители реализуют на оборудовании ограниченный набор групп RMON MIB. Обычно агент RMON поддерживает только группы statistics, history, alarm и event.

    Для настройки RMON на коммутаторах D-Link второго уровня требуется активизировать эту функцию глобально на коммутаторе с помощью команды enable rmon.

    Группы мониторинга RMON v.1
    Группа RMONФункция
    1StatisticsСодержит статистические данные, измеренные датчиком на каждом интерфейсе устройства, для которого проводится мониторинг
    2HistoryПериодическая запись статистических выборок из сети и их хранение для дальнейшего использования
    3AlarmПериодическое извлечение статистических выборок из переменных в датчике и их сравнение с заранее выбранными пороговыми значениями. Если наблюдаемые значения выходят за границы пороговых, генерируется событие
    4HostСодержит статистические данные, связанные с каждым узлом, обнаруженным в сети
    5Hosts top NСодержит отсортированные данные по указанному числу узлов в порядке убывания их статистики
    6MatrixСодержит статистику по диалогам между парами узлов, в том числе о величине трафика и количестве ошибок в обоих направлениях
    7FilterСодержит условия фильтрации пакетов
    8CaptureСодержит пакеты, захваченные интерфейсом в соответствии с условиями фильтрации
    9EventПротоколирование событий и определение действий при их наступлении
    10Token RingРасширенная статистика для сетей Token Ring
    Группы мониторинга RMON v.2
    Группа RMONФункция
    1Protocol DirectoryСписок протоколов, для которых зонд может осуществлять мониторинг пакетов
    2Protocol DistributionСтатистика трафика для каждого протокола с информацией о распределении и тенденциях в использовании протоколов
    3Address MapСоответствия между адресами сетевого уровня и MAC-адресами, обнаруженные зондом на интерфейсе
    4Network-Layer HostСтатистика трафика передаваемого от и к каждому обнаруженному зондом узлу
    5Network-Layer MatrixСодержит статистику по диалогам между парами узлов на сетевом уровне
    6Application-Layer HostСтатистика трафика передаваемого от и к каждому обнаруженному зондом узлу по протоколам
    7Application-Layer MatrixСтатистика трафика по диалогам между парами узлов на сетевом уровне по протоколам
    8User HistoryПериодические выборки для определенных пользователем переменных
    9Probe ConfigurationУдаленная конфигурация параметров зонда

    При настройке функции на коммутаторе третьего уровня необходимо дополнительно активизировать протокол SNMP и определить Community string.

    Функция Port Mirroring

    Функция Port Mirroring ("Зеркалирование портов") позволяет отображать (копировать) кадры, принимаемые и отправляемые портом-источником (Source port) на целевой порт (Target port) коммутатора, к которому подключено устройство мониторинга с целью анализа проходящих через интересующий порт пакетов. Эта функция полезна администраторам для мониторинга и поиска неисправностей в сети.

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

    На рис. 26.16 показан пример, в котором трафик, передаваемый и получаемый портами 2 и 4, будет зеркалироваться на порт 1, к которому подключено устройство мониторинга.

    (рис 26.16) Функция Port Mirroring

    Настройка коммутатора

    config mirror port 1 add source ports 2, 4 both
    enable mirror
    
    Страницы:

    Управление множеством коммутаторов

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

  • физическое стекирование коммутаторов;
  • виртуальное стекирование коммутаторов.
  • Оба эти подхода предполагают объединение коммутаторов в физическую или логическую группу, которая будет управляться через единый IP-адрес.

    Объединение коммутаторов в физический стек

    При физическом стекировании коммутаторы представляют собой одно логическое устройство, что обеспечивает удобство управления и мониторинга их параметров. Для управления коммутаторами можно использовать интерфейс командной строки (CLI), Web-интерфейс, Telnet, протокол SNMP, и только одному коммутатору (мастеру-коммутатору) потребуется присвоение управляющего IP-адреса.

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

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

    В примере, приведенном на рис. 26.1 , показано, что данные от коммутатора 2 передаются не по кругу (через коммутаторы 3, 4, 5 и т.д.), а непосредственно в направлении коммутатора 9 (через коммутаторы 1,12,11,10). При этом следует отметить, что весь трафик в стеке передается одновременно, и локальный трафик не оказывает влияния на трафик, циркулирующий внутри стека (рис. 26.2).

    (рис 26.1) Пример выбора оптимального пути передачи пакета в стеке типа "кольцо" (рис 26.2) Потоки трафика в стеке

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

    В стекируемых коммутаторах D-Link для повышения отказоустойчивости и производительности стека, реализованы следующие механизмы:

  • механизм Resilient Master Technology (RMT) обеспечивает непрерывную работу стека при выходе какого-либо устройства из строя, замене, добавлении и удалении коммутаторов, а также позволяет автоматически назначать нового мастера-коммутатора в случае неработоспособности текущего и автоматически восстанавливать работу стека;
  • механизм Cross Device Trunking (CDT) позволяет объединять несколько физических портов разных коммутаторов стека в один агрегированный канал с повышенной полосой пропускания. При этом такая логическая магистраль будет продолжать функционирование, даже если какой-либо порт или коммутатор выйдут из строя;
  • технология SmartRoute позволяет копировать таблицы коммутации 3-го уровня, хранимые на мастере-коммутаторе, на все другие устройства стека (в том случае, если стек построен на коммутаторах L3). Благодаря этому каждый коммутатор стека может маршрутизировать трафик локально, не пересылая его на мастер-коммутатор, что уменьшает потребление полосы пропускания между коммутаторами и повышает отказоустойчивость стека.
  • Роли коммутаторов стека

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

    Основной мастер (Primary Master) — основной мастер-коммутатор является ведущим устройством стека и единой точкой управления. Он следит за нормальной работой стека, топологией, назначает идентификаторы устройствам стека (Box ID), синхронизирует конфигурации и передает команды другим коммутаторам. Роль основного мастера может быть присвоена коммутатору вручную, путем назначения наивысшего приоритета администратором сети, или определена автоматически в процессе выборов.

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

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

  • резервный мастер стал основным мастером;
  • резервный мастер вышел из строя или удален из стека;
  • оба, и основной, и резервный мастер, вышли из строя или удалены из стека.
  • Выборы основного мастера-коммутатора стека

    После того как коммутаторы будут объединены в стек, каждое устройство начнет собирать информацию (такую как приоритет, МАС-адрес) о соседних коммутаторах и сохранять ее во временной базе данных топологии стека (self temp stacking topology database). Далее коммутаторы приступят к выбору основного мастера-коммутатора стека. Основной мастер выбирается путем сравнения приоритетов (по умолчанию приоритет 32) и МАС-адресов коммутаторов стека.

    (рис 26.3) Процесс выбора основного мастера на основании приоритетов

    Основным мастером становится коммутатор с наименьшим значением приоритета. Если приоритеты коммутаторов равны, то будет выбран коммутатор с наименьшим значением МАС-адреса.

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

    Как только выбраны основной и резервный мастер, всем коммутаторам стека будут присвоены порядковые номера Box ID. Если в настройках коммутатора параметр Box ID установлен в Auto, основной мастер назначит каждому устройству стека порядковый номер в соответствии с правилами автоматического назначения номеров (основному мастеру в автоматическом режиме присваивается номер 1). Эта информация о топологии будет разослана всем устройствам стека.

    (рис 26.4) Процесс выбора основного мастера на основании МАС-адресов при равном значении приоритетов (рис 26.5) Назначение порядковых номеров в автоматическом режиме

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

    Следует отметить, что основной мастер-коммутатор и резервный мастер-коммутатор не имеют фиксированных номеров, т.е. основному мастеру может быть присвоен Box ID, отличный от 1.

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

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

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

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

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

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

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

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

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

    Пример настройки стекирования

    (рис 26.6) Коммутаторы, объединенные в стек

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

    Настройка коммутатора 1

    config stacking mode enable
    config box_priority current_box_id 1 priority 1
    

    Настройка коммутатора 2

    config stacking mode enable
    config box_priority current_box_id 1 new_box_id 2
    config box_priority current_box_id 2 priority 2
    

    Виртуальный стек. Технология Single IP Management (SIM)

    Технология Single IP Management (SIM) является простым и удобным способом сетевого управления. Она разработана для управления группой коммутаторов, называемых SIM-группой, как единым устройством. При этом для управления SIM-группой требуется только один IP-адрес, который назначается выделенному коммутатору группы (Commander switch).

    Технология SIM позволяет:

  • устранить ограничения на модели коммутаторов, объединяемых в стек;
  • уменьшить количество управляющих IP-адресов в сети;
  • устранить необходимость использования специализированных модулей и кабелей, предназначенных для стекирования; преодолеть ограничения, связанные с длиной кабелей в стеке.
  • В отличие от стеков, построенных с использованием традиционных методов стекирования, виртуальный стек на основе технологии SIM не ограничивается 6-ю или 12-ю коммутаторами. В SIM-группу может входить до 32-х коммутаторов любых моделей, поддерживающих функции Single IP Management. Это означает, что виртуальный стек может включать коммутаторы разного типа, от недорогих коммутаторов 2-го уровня до высокопроизводительных коммутаторов на основе шасси (для ядра сети).

    Объединение коммутаторов в SIM-группу не требует использования специальных соединительных кабелей. Трафик, передаваемый между устройствами стека, проходит через интерфейсы Fast Ethernet, Gigabit Ethernet или 10 Gigabit Ethernet по обычным медным или оптическим кабелям. Отказ от использования специализированных стекирующих кабелей позволяет преодолеть ограничения, связанные с их длиной. Устройства SIM-группы могут быть подключены друг к другу через промежуточные устройства, не поддерживающие технологию SIM. Объединение коммутаторов в SIM-группу не влияет на их нормальное функционирование.

    (рис 26.7) Технология SIM Внимание: SIM является дополнительной функцией коммутаторов и может быть активизирована или отключена через Web-интерфейс или CLI. По умолчанию эта функция на коммутаторе отключена.

    Технология SIM предусматривает три роли, которые могут быть назначены коммутаторам группы:

  • Commander Switch (CS) — это коммутатор, который вручную настраивается администратором сети как управляющее устройство SIM-группы. В SIM-группе может быть только один Commander Switch. CS обладает следующими характеристиками:
  • ему присвоен IP-адрес;
  • он не является Commander Switch или Member Switch другой SIM-группы;
  • он подключен к коммутаторам Member Switch через управляющую VLAN (VLAN, к которой привязан управляющий интерфейс коммутатора System. По умолчанию управляющей VLAN является default VLAN);
  • Member Switch (MS) — коммутатор, который вступил в SIM-груп-пу и доступен через Commander Switch. Member Switch обладает следующими характеристиками:
  • он не является Commander Switch или Member Switch другой SIM-группы;
  • он подключен к Commander Switch через управляющую VLAN;
  • Candidate Switch (CaS) — это коммутатор, который готов вступить в SIM-группу (стать Member Switch), используя либо автоматический метод, либо ручную настройку. Коммутатор, настроенный как Candidate Switch, не является членом SIM-группы. Он обладает следующими характеристиками:
  • он не является Commander Switch или Member Switch другой SIM-группы;
  • он подключен к Commander Switch через управляющую VLAN.
  • Все коммутаторы, объединенные в одну SIM-группу, должны принадлежать одной IP-подсети (широковещательному домену). В пределах одной подсети может быть создано несколько SIM-групп, но при этом каждый коммутатор должен принадлежать только одной SIM-группе. Каждая группа может содержать до 32 коммутаторов (от 0 до 31), включая Commander Switch (его номер 0). Если в сети настроено несколько VLAN, SIM-группа будет использовать только управляющую VLAN любого коммутатора.

    По умолчанию после активизации функции SIM всем коммутаторам присваивается роль "Candidate Switch". Это означает, что они смогут стать членами SIM-группы (Member Switch), как только получат запрос от Commander Switch.

    После того, как одному из коммутаторов группы была присвоена роль "Commander Switch", он начинает формировать SIM-группу, добавляя в нее новых членов. Для этого Commander Switch просматривает список кандидатов (Candidate Switch) и отправляет им периодические запросы. Кандидат отправляет Commander Switch ответ, содержащий информацию о нем, что позволяет ему стать членом SIM-группы. Если коммутатор-кандидат имел ранее сконфигурированный пароль, он не сможет стать членом группы до тех пор, пока не будут введены его аутентификационные данные.

    Можно добавлять членов группы, используя Web-интерфейс. Функционал SIM встроен в Web-интерфейс управления коммутаторов и не требует установки дополнительного ПО.

    (рис 26.8) Функция SIM в Web-интерфейсе

    После настройки Commander Switch в папке Single IP Management Web-интерфейса станет доступна опция Topology. Эта опция позволяет настраивать коммутаторы и управлять ими внутри SIM-группы. При выборе пункта View окна Topology появится топологическая карта, показывающая, как подключены устройства внутри SIM-группы. Топологическая карта автоматически обновляется каждые 20 секунд.

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

    В топологической карте используются следующие иконки для обозначения Commander Switch, Member Switch и Candidate Switch.

    (рис 26.9) Топологическая карта (рис 26.10) Иконки, используемые для представления устройств в топологической карте

    Протокол SNMP

    Протокол SNMP (Simple Network Management Protocol) является протоколом 7 уровня модели OSI, который специально разработан для управления и мониторинга сетевых устройств. Протокол SNMP входит в стек протоколов TCP/IP и позволяет администраторам сетей получать информацию о состоянии устройств сети, обнаруживать и исправлять неисправности и планировать развитие сети.

    В настоящее время существует три версии протокола SNMP: SNMP v1 (RFC 1157), SNMP v2c (RFC 1901-1908) и SNMP v3 (RFC 3411-3418). Эти версии отличаются предоставляемым уровнем безопасности при обмене данными между менеджером и агентом SNMP. Коммутаторы D-Link поддерживают все три версии протокола.

    Компоненты SNMP

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

    (рис 26.11) Компоненты SNMP

    Менеджер SNMP (SNMP Manager) — это программное обеспечение, установленное на рабочей станции управления, наблюдающее за сетевыми устройствами и управляющее ими.

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

    База управляющей информации (Management Information Base, MIB) — это совокупность иерархически организованной информации, доступ к которой осуществляется посредством протокола управления сетью.

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

    База управляющей информации SNMP

    Базы управляющей информации описывают структуру управляющей информации устройств и состоят из управляемых объектов (переменных).

    Управляемый объект (или MIB-объект) — это одна из нескольких характеристик управляемого сетевого устройства (например, имя системы, время, прошедшее с ее перезапуска, количество интерфейсов устройства, IP-адрес и т.д.).

    Обращение к управляемым объектам MIB происходит посредством идентификаторов объекта (Object IDentifier, OID). Каждый управляемый объект имеет уникальный идентификатор в пространстве имен OID и контролируется агентством IANA. Пространство имен OID можно представить в виде иерархической структуры с корнем без названия, идентификаторы верхних уровней которой отданы организациям, контролирующим стандартизацию, а идентификаторы нижних уровней определяются самими этими организациями. Каждая ветвь дерева OID нумеруется целыми числами слева направо, начиная с единицы. Идентификатор представляет собой последовательность целых десятичных цифр, разделенных точкой, записанных слева направо и включает полный путь от корня до управляемого объекта. Числам могут быть поставлены в соответствие текстовые строки для удобства восприятия. В целом структура имени похожа на систему доменных имен Интернета (Domain Name System, DNS).

    Каждая MIB (в настоящее время основными стандартами на базы управляющей информации для протокола SNMP являются MIB-I и MIB-II) определяет набор переменных, т. е. определенную ветку дерева OID, описывающую управляющую информацию в определенной области. Например, ветка 1.3.6.1.2.1.1 (символьное эквивалентное имя: iso.org.dod.inter-net.mgmt.mib-2.system) описывает общую информацию о системе.

    (рис 26.12) Пространство имен OID

    Производители сетевого оборудования определяют частные ветви пространства имен OID (группа объектов private (4)), куда помещают управляемые объекты для своей продукции. Так, D-Link в качестве вершины иерархии для своей продукции использует OID, равный 1.3.6.1.4.1.171.

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

    Типы сообщений протокола SNMP

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

  • Get-Request — запрос значений одного или нескольких объектов;
  • Get-Next-Request — запрос значения следующего объекта в соответствии с алфавитным порядком идентификаторов OID;
  • Set-Request — запрос на изменение значения одного или нескольких объектов;
  • Get(Set)-Reply — получение ответа от агента на сообщение Get-Request, Get-Next-Request или Set-Request.
  • Сообщение Trap (ловушка) используется агентом SNMP для асинхронного сообщения менеджеру SNMP о событии, происходящем на управляемом сетевом устройстве. События могут быть серьезные, например перезагрузка устройства, или менее серьезные, например изменение состояния порта.

    Версия SNMP v.2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько переменных за один запрос.

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

    (рис 26.13) Типы сообщения протокола SNMP

    Безопасность SNMP

    В протоколе SNMP v.1 и v.2c предусмотрена аутентификация пользователей, которая выполняется с помощью строки сообщества (Community string). Строки Community string функционирует подобно паролю, который разрешает удаленному менеджеру SNMP доступ к агенту. Менеджер и агент SNMP должны использовать одинаковые строки Community string, т.к. все пакеты от менеджера SNMP, не прошедшего аутентификацию, будут отбрасываться. В коммутаторах с поддержкой SNMP v.1 и v.2c используются следующие Community string по умолчанию:

  • public — позволить авторизованной рабочей станции читать (право "read only") MIB-объекты;
  • private — позволить авторизованной рабочей станции читать и изменять (право "read/write") MIB-объекты.
  • Внимание: Community string передаются по сети в открытом виде.

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

    На коммутаторе SNMP можно создавать группы со списками пользователей (менеджеров SNMP) и настраивать для них общий набор привилегий. Помимо этого, для каждой группы может быть установлена версия используемого ею протокола SNMP. Таким образом, можно создать группу менеджеров SNMP, которым позволено просматривать информацию с правом "read only" или получать ловушки (trap), используя SNMP v.1, в то время как другой группе можно настроить наивысший уровень привилегий с правами "read/write" и возможность использования протокола SNMP v.3.

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

    Пример настройки протокола SNMP

    На рис. 26.14 показана схема сети, в которой управление коммутатором может выполняться через управляющую консоль SNMP по протоколу SNMP v.2. В случае обнаружения SNMP-агентом коммутатора каких-либо неполадок он будет отправлять сообщения Trap менеджеру SNMP. В целях повышения безопасности строки Community string по умолчанию удалены.

    (рис 26.14) Схема сети

    Настройка коммутатора

  • Активизировать функцию SNMP глобально на коммутаторе.
    enable snmp
    
  • Удалить строки Community string по умолчанию и создать новые строки Community string.
    delete snmp community public
    delete snmp community private
    create snmp community dlinkro view CommunityView read_only
    create snmp community dlinkrw view CommunityView read_write
    
  • Задать параметры получателя сообщений Trap от агента и активизировать функцию отправки сообщений Trap.
    create snmp host 192.168.1.100 v2c dlinkrw
    enable snmp traps
    enable snmp authenticate_traps
    
  • RMON (Remote Monitoring)

    Спецификация RMON MIB (Remote MONitoring, удаленный мониторинг) была разработана сообществом IETF для поддержки мониторинга и анализа протоколов в локальных сетях. Первая версия RMON v.1 (RFC 2819) основывается на мониторинге информации сетей Ethernet и Token Ring. Ее расширением является RMON v.2 (RFC 2021), которая добавила к уже имеющимся средствам мониторинга поддержку мониторинга на сетевом уровне и уровне приложений модели OSI.

    Реализация RMON основывается на модели "клиент/сервер". На устройствах мониторинга, называемых в терминологии RMON "зондами" (probe), установлено специальное программное обеспечение — агент RMON, которое собирает информацию и анализирует пакеты. Зонды действуют как серверы, а приложения сетевого управления, установленные на станциях управления сетью, исполняют роль клиентов. Агенты RMON могут как размещаться на автономных устройствах, так и встраиваться в коммутаторы, маршрутизаторы и другие сетевые устройства. Станция управления сетью и распределенные зонды RMON взаимодействуют по сети по протоколу SNMP.

    (рис 26.15) Консоль и зонд RMON

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

    RMON поставляет информацию в группы RMON MIB, каждая из которых поддерживает определенный набор данных, удовлетворяющих общим требованиям мониторинга сети. RMON v.1 содержит десять групп RMON MIB, а RMON v.2 добавляет к ним еще девять групп RMON MIB. Вместе RMON v.1 и RMON v.2 позволяют собирать статистику о трафике на всех уровнях модели OSI. Из-за того, что при выполнении обработки данных на ресурсы устройств мониторинга ложится большая нагрузка, то производители реализуют на оборудовании ограниченный набор групп RMON MIB. Обычно агент RMON поддерживает только группы statistics, history, alarm и event.

    Для настройки RMON на коммутаторах D-Link второго уровня требуется активизировать эту функцию глобально на коммутаторе с помощью команды enable rmon.

    Группы мониторинга RMON v.1
    Группа RMONФункция
    1StatisticsСодержит статистические данные, измеренные датчиком на каждом интерфейсе устройства, для которого проводится мониторинг
    2HistoryПериодическая запись статистических выборок из сети и их хранение для дальнейшего использования
    3AlarmПериодическое извлечение статистических выборок из переменных в датчике и их сравнение с заранее выбранными пороговыми значениями. Если наблюдаемые значения выходят за границы пороговых, генерируется событие
    4HostСодержит статистические данные, связанные с каждым узлом, обнаруженным в сети
    5Hosts top NСодержит отсортированные данные по указанному числу узлов в порядке убывания их статистики
    6MatrixСодержит статистику по диалогам между парами узлов, в том числе о величине трафика и количестве ошибок в обоих направлениях
    7FilterСодержит условия фильтрации пакетов
    8CaptureСодержит пакеты, захваченные интерфейсом в соответствии с условиями фильтрации
    9EventПротоколирование событий и определение действий при их наступлении
    10Token RingРасширенная статистика для сетей Token Ring
    Группы мониторинга RMON v.2
    Группа RMONФункция
    1Protocol DirectoryСписок протоколов, для которых зонд может осуществлять мониторинг пакетов
    2Protocol DistributionСтатистика трафика для каждого протокола с информацией о распределении и тенденциях в использовании протоколов
    3Address MapСоответствия между адресами сетевого уровня и MAC-адресами, обнаруженные зондом на интерфейсе
    4Network-Layer HostСтатистика трафика передаваемого от и к каждому обнаруженному зондом узлу
    5Network-Layer MatrixСодержит статистику по диалогам между парами узлов на сетевом уровне
    6Application-Layer HostСтатистика трафика передаваемого от и к каждому обнаруженному зондом узлу по протоколам
    7Application-Layer MatrixСтатистика трафика по диалогам между парами узлов на сетевом уровне по протоколам
    8User HistoryПериодические выборки для определенных пользователем переменных
    9Probe ConfigurationУдаленная конфигурация параметров зонда

    При настройке функции на коммутаторе третьего уровня необходимо дополнительно активизировать протокол SNMP и определить Community string.

    Функция Port Mirroring

    Функция Port Mirroring ("Зеркалирование портов") позволяет отображать (копировать) кадры, принимаемые и отправляемые портом-источником (Source port) на целевой порт (Target port) коммутатора, к которому подключено устройство мониторинга с целью анализа проходящих через интересующий порт пакетов. Эта функция полезна администраторам для мониторинга и поиска неисправностей в сети.

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

    На рис. 26.16 показан пример, в котором трафик, передаваемый и получаемый портами 2 и 4, будет зеркалироваться на порт 1, к которому подключено устройство мониторинга.

    (рис 26.16) Функция Port Mirroring

    Настройка коммутатора

    config mirror port 1 add source ports 2, 4 both
    enable mirror
    
    Вернуться к учебному плану