Независимое управление множеством коммутаторов требует выделения каждому устройству отдельного IP-адреса, что ведет к неэкономному использованию адресного пространства и необходимости запоминания администратором сети IP-адреса каждого коммутатора. D-Link предлагает два подхода к управлению множеством коммутаторов:
Оба эти подхода предполагают объединение коммутаторов в физическую или логическую группу, которая будет управляться через единый IP-адрес.
При физическом стекировании коммутаторы представляют собой одно логическое устройство, что обеспечивает удобство управления и мониторинга их параметров. Для управления коммутаторами можно использовать интерфейс командной строки (
Передача данных между коммутаторами стека ведется в полнодуплексном режиме. Коммутаторы могут быть объединены в стек либо кольцевой топологии, либо линейной топологии. Одним из преимуществ стека кольцевой топологии над стеком линейной топологии является поддержка технологии определения оптимального пути передачи пакетов. Эта технология позволяет достичь полного использования полосы пропускания и повысить отказоустойчивость стека.
В примере, приведенном на рис. 26.1 , показано, что данные от коммутатора 2 передаются не по кругу (через коммутаторы 3, 4, 5 и т.д.), а непосредственно в направлении коммутатора 9 (через коммутаторы 1,12,11,10). При этом следует отметить, что весь трафик в стеке передается одновременно, и локальный трафик не оказывает влияния на трафик, циркулирующий внутри стека (рис. 26.2).
(рис 26.1) Пример выбора оптимального пути передачи пакета в стеке типа "кольцо"
(рис 26.2) Потоки трафика в стеке
В стеке линейной топологии данные передаются только в одном направлении, и выход из строя какого-либо коммутатора стека повлияет на его работу.
В стекируемых коммутаторах D-Link для повышения отказоустойчивости и производительности стека, реализованы следующие механизмы:
Каждому коммутатору стека присваивается определенная роль. Эти роли могут быть вручную настроены администратором сети на каждом коммутаторе или определены стеком автоматически. Существуют 3 роли, которые могут быть назначены коммутаторам стека.
Основной мастер (Primary Master) — основной мастер-коммутатор является ведущим устройством стека и единой точкой управления. Он следит за нормальной работой стека, топологией, назначает
Резервный мастер (Backup Master) — резервный мастер дублирует основной мастер-коммутатор и в случае его выхода из строя берет на себя функции основного мастера. Резервный мастер-коммутатор следит за состоянием соседних коммутаторов стека, основного мастера-коммутатора и выполняет его команды. Роль резервного мастера может быть назначена коммутатору вручную, путем присвоения ему второго по значению наивысшего приоритета до физического объединения устройств в стек или автоматически во время выборов.
Ведомый (Slave) — ведомыми являются все остальные коммутаторы стека. Ведомые коммутаторы выполняют операции, требуемые основным мастером, следят за состоянием соседних коммутаторов стека и топологией, следуют командам резервного мастера, когда он становится основным. Ведомые коммутаторы принимают участие в процессе выбора нового резервного мастера, в случае если:
После того как коммутаторы будут объединены в стек, каждое устройство начнет собирать информацию (такую как приоритет, МАС-адрес) о соседних коммутаторах и сохранять ее во временной базе данных топологии стека (self temp stacking
(рис 26.3) Процесс выбора основного мастера на основании приоритетов
Основным мастером становится коммутатор с наименьшим значением приоритета. Если приоритеты коммутаторов равны, то будет выбран коммутатор с наименьшим значением МАС-адреса.
После выбора основного мастера, начинается процесс выбора резервного мастера из оставшихся устройств стека по аналогичному сценарию.
Как только выбраны основной и резервный мастер, всем коммутаторам стека будут присвоены порядковые номера Box ID. Если в настройках коммутатора параметр Box ID установлен в Auto, основной мастер назначит каждому устройству стека порядковый номер в соответствии с правилами автоматического назначения номеров (основному мастеру в автоматическом режиме присваивается номер 1). Эта информация о топологии будет разослана всем устройствам стека.
(рис 26.4) Процесс выбора основного мастера на основании МАС-адресов при равном значении приоритетов
(рис 26.5) Назначение порядковых номеров в автоматическом режиме
Когда значение параметра Box ID установлено в статический режим (STATIC), присвоение порядковых номеров коммутаторам будет осуществляться вручную администратором сети. При этом настройки любого коммутатора с новым, отличным от предыдущего, значением Box ID будут возвращены к заводским настройкам по умолчанию. Если в процессе изучения топологии стека возник конфликт идентификационных номеров
Следует отметить, что основной мастер-коммутатор и резервный мастер-коммутатор не имеют фиксированных номеров, т.е. основному мастеру может быть присвоен Box ID, отличный от 1.
При работе в смешанном режиме, когда на коммутаторах используется автоматическое и статическое назначение номеров, действует следующее правило:
В случае добавления или удаления коммутатора(-ов) из стека или изменения топологии протокол стекирования, реализованный в устройствах, быстро обнаружит изменения и синхронизирует информацию о новой топологии стека.
Когда новый коммутатор добавляется в работающий стек, ему присваивается роль ведомого или резервного мастера, в зависимости от значений приоритета и МАС-адреса.
Если в стек добавляется только одно устройство, то процесс выбора основного мастера не запускается.
При удалении одного или нескольких коммутаторов из работающего стека оставшиеся коммутаторы удаляют информацию о выбывших устройствах из своих баз данных топологии стека.
При удалении резервного мастера запускается процесс выборов нового резервного мастера. Этот процесс также запускается при удалении или выходе из строя основного мастера, т.к. резервный мастер становится в этом случае основным. При этом для минимизации нарушения работы сети новому основному мастеру присваивается тот же 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) является простым и удобным способом сетевого управления. Она разработана для управления группой коммутаторов, называемых SIM-группой, как единым устройством. При этом для управления SIM-группой требуется только один IP-адрес, который назначается выделенному коммутатору группы (Commander switch).
Технология SIM позволяет:
В отличие от стеков, построенных с использованием традиционных методов стекирования, виртуальный стек на основе технологии SIM не ограничивается 6-ю или 12-ю коммутаторами. В SIM-группу может входить до 32-х коммутаторов любых моделей, поддерживающих функции Single
Объединение коммутаторов в SIM-группу не требует использования специальных соединительных кабелей. Трафик, передаваемый между устройствами стека, проходит через интерфейсы Fast Ethernet, Gigabit Ethernet или 10 Gigabit Ethernet по обычным медным или оптическим кабелям. Отказ от использования специализированных стекирующих кабелей позволяет преодолеть ограничения, связанные с их длиной. Устройства SIM-группы могут быть подключены друг к другу через промежуточные устройства, не поддерживающие технологию SIM. Объединение коммутаторов в SIM-группу не влияет на их нормальное функционирование.
(рис 26.7) Технология SIM
Технология SIM предусматривает три роли, которые могут быть назначены коммутаторам группы:
Все коммутаторы, объединенные в одну 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
Используя топологическую карту, администратор может получать детальную информацию о группе, просматривать краткую информацию о каждом коммутаторе SIM-группы, настраивать его, добавлять и удалять устройства из SIM-группы.
В топологической карте используются следующие иконки для обозначения Commander Switch, Member Switch и Candidate Switch.
(рис 26.9) Топологическая карта
(рис 26.10) Иконки, используемые для представления устройств в топологической карте
Протокол SNMP (Simple
В настоящее время существует три версии протокола SNMP: SNMP v1 (RFC 1157), SNMP v2c (RFC 1901-1908) и SNMP v3 (RFC 3411-3418). Эти версии отличаются предоставляемым уровнем безопасности при обмене данными между менеджером и агентом SNMP. Коммутаторы D-Link поддерживают все три версии протокола.
Сеть, управляемая по протоколу SNMP, основывается на архитектуре "клиент/сервер" и состоит из трех основных компонентов: менеджера SNMP, агента SNMP, базы управляющей информации.
(рис 26.11) Компоненты SNMP
Менеджер SNMP (SNMP Manager) — это программное обеспечение, установленное на рабочей станции управления, наблюдающее за сетевыми устройствами и управляющее ими.
Агент SNMP (SNMP Agent) — это программный модуль для управления сетью, который находится на управляемом сетевом устройстве (маршрутизаторе, коммутаторе, точке доступа, Интернет-шлюзе, принтере и т.д.). Агент обслуживает базу управляющей информации и отвечает на запросы менеджера SNMP.
База управляющей информации (Management Information Base,
Менеджер взаимодействует с агентами при помощи протокола SNMP с целью обмена управляющей информацией. В основном это взаимодействие реализуется в виде периодического опроса менеджером множества агентов, которые предоставляют доступ к информации.
Базы управляющей информации описывают структуру управляющей информации устройств и состоят из управляемых объектов (переменных).
Управляемый объект (или
Обращение к управляемым объектам
Каждая 1.3.6.1.2.1.1 (символьное эквивалентное имя: iso.org.) описывает общую информацию о системе.
(рис 26.12) Пространство имен OID
Производители сетевого оборудования определяют частные ветви пространства имен 1.3.6.1.4.1.171.
Помимо непосредственного описания данных необходимо вести операции над ними. Первоначальная спецификация
Протокол SNMP является простым протоколом типа "запрос — ответ", т.е. на каждый запрос менеджера, агент должен дать ответ. В протоколе определено несколько
Get-Request — запрос значений одного или нескольких объектов;Get-Next-Request — запрос значения следующего объекта в соответствии с алфавитным порядком идентификаторов Set-Request — запрос на изменение значения одного или нескольких объектов;Get(Set)-Reply — получение ответа от агента на сообщение Get-Request, Get-Next-Request или Set-Request.Сообщение (ловушка) используется агентом SNMP для асинхронного сообщения менеджеру SNMP о событии, происходящем на управляемом сетевом устройстве. События могут быть серьезные, например перезагрузка устройства, или менее серьезные, например изменение состояния порта.
Версия SNMP v.2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько переменных за один запрос.
При передаче управляющих сообщений в качестве протокола транспортного уровня используется
(рис 26.13) Типы сообщения протокола 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") private — позволить авторизованной рабочей станции читать и изменять (право "read/write") Community string передаются по сети в открытом виде.
Протокол SNMP v.3 использует более сложный процесс аутентификации, который разделен на две части. Первая часть — обработка списка и
На коммутаторе SNMP можно создавать группы со списками пользователей (менеджеров SNMP) и настраивать для них общий набор привилегий. Помимо этого, для каждой группы может быть установлена версия используемого ею протокола SNMP. Таким образом, можно создать группу менеджеров SNMP, которым позволено просматривать информацию с правом "read only" или получать ловушки (
При использовании протокола SNMP v.3 отдельным пользователям или группам менеджеров SNMP может быть разрешено или запрещено выполнять определенные функции SNMP-управления. Помимо этого, в SNMP v.3 доступен дополнительный уровень безопасности, при котором SNMP-сообщения могут шифроваться при передаче по сети.
На рис. 26.14 показана схема сети, в которой управление коммутатором может выполняться через управляющую консоль SNMP по протоколу SNMP v.2. В случае обнаружения SNMP-агентом коммутатора каких-либо неполадок он будет отправлять сообщения
(рис 26.14) Схема сети
Настройка коммутатора
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
Реализация RMON основывается на модели "клиент/сервер". На устройствах мониторинга, называемых в терминологии RMON "зондами" (probe), установлено специальное программное обеспечение — агент RMON, которое собирает информацию и анализирует пакеты. Зонды действуют как серверы, а приложения сетевого управления, установленные на станциях управления сетью, исполняют роль клиентов. Агенты RMON могут как размещаться на автономных устройствах, так и встраиваться в коммутаторы, маршрутизаторы и другие сетевые устройства. Станция управления сетью и распределенные зонды RMON взаимодействуют по сети по протоколу SNMP.
(рис 26.15) Консоль и зонд RMON
Несмотря на то, что RMON является расширением протокола SNMP, он отличается от него тем, что зонды RMON могут самостоятельно выполнять сбор и обработку данных. Это позволяет сократить трафик SNMP в сети и нагрузку на станцию управления, причем информация будет передаваться на станцию только когда это необходимо. Расположенные в различных частях сети приложения RMON могут одновременно взаимодействовать и получать информацию от одного и того же зонда.
RMON поставляет информацию в группы RMON
Для настройки RMON на коммутаторах D-Link второго уровня требуется активизировать эту функцию глобально на коммутаторе с помощью команды enable rmon.
| № | Группа RMON | Функция |
|---|---|---|
| 1 | Statistics | Содержит статистические данные, измеренные датчиком на каждом интерфейсе устройства, для которого проводится мониторинг |
| 2 | History | Периодическая запись статистических выборок из сети и их хранение для дальнейшего использования |
| 3 | Alarm | Периодическое извлечение статистических выборок из переменных в датчике и их сравнение с заранее выбранными пороговыми значениями. Если наблюдаемые значения выходят за границы пороговых, генерируется событие |
| 4 | Host | Содержит статистические данные, связанные с каждым узлом, обнаруженным в сети |
| 5 | Hosts top N | Содержит отсортированные данные по указанному числу узлов в порядке убывания их статистики |
| 6 | Matrix | Содержит статистику по диалогам между парами узлов, в том числе о величине трафика и количестве ошибок в обоих направлениях |
| 7 | Filter | Содержит условия фильтрации пакетов |
| 8 | Capture | Содержит пакеты, захваченные интерфейсом в соответствии с условиями фильтрации |
| 9 | Event | Протоколирование событий и определение действий при их наступлении |
| 10 | Token Ring | Расширенная статистика для сетей Token Ring |
| № | Группа RMON | Функция |
|---|---|---|
| 1 | Protocol Directory | Список протоколов, для которых зонд может осуществлять мониторинг пакетов |
| 2 | Protocol Distribution | Статистика трафика для каждого протокола с информацией о распределении и тенденциях в использовании протоколов |
| 3 | Address Map | Соответствия между адресами сетевого уровня и MAC-адресами, обнаруженные зондом на интерфейсе |
| 4 | Network-Layer Host | Статистика трафика передаваемого от и к каждому обнаруженному зондом узлу |
| 5 | Network-Layer Matrix | Содержит статистику по диалогам между парами узлов на сетевом уровне |
| 6 | Application-Layer Host | Статистика трафика передаваемого от и к каждому обнаруженному зондом узлу по протоколам |
| 7 | Application-Layer Matrix | Статистика трафика по диалогам между парами узлов на сетевом уровне по протоколам |
| 8 | User History | Периодические выборки для определенных пользователем переменных |
| 9 | Probe Configuration | Удаленная конфигурация параметров зонда |
При настройке функции на коммутаторе третьего уровня необходимо дополнительно активизировать протокол SNMP и определить Community string.
Функция 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-адрес.
При физическом стекировании коммутаторы представляют собой одно логическое устройство, что обеспечивает удобство управления и мониторинга их параметров. Для управления коммутаторами можно использовать интерфейс командной строки (
Передача данных между коммутаторами стека ведется в полнодуплексном режиме. Коммутаторы могут быть объединены в стек либо кольцевой топологии, либо линейной топологии. Одним из преимуществ стека кольцевой топологии над стеком линейной топологии является поддержка технологии определения оптимального пути передачи пакетов. Эта технология позволяет достичь полного использования полосы пропускания и повысить отказоустойчивость стека.
В примере, приведенном на рис. 26.1 , показано, что данные от коммутатора 2 передаются не по кругу (через коммутаторы 3, 4, 5 и т.д.), а непосредственно в направлении коммутатора 9 (через коммутаторы 1,12,11,10). При этом следует отметить, что весь трафик в стеке передается одновременно, и локальный трафик не оказывает влияния на трафик, циркулирующий внутри стека (рис. 26.2).
(рис 26.1) Пример выбора оптимального пути передачи пакета в стеке типа "кольцо"
(рис 26.2) Потоки трафика в стеке
В стеке линейной топологии данные передаются только в одном направлении, и выход из строя какого-либо коммутатора стека повлияет на его работу.
В стекируемых коммутаторах D-Link для повышения отказоустойчивости и производительности стека, реализованы следующие механизмы:
Каждому коммутатору стека присваивается определенная роль. Эти роли могут быть вручную настроены администратором сети на каждом коммутаторе или определены стеком автоматически. Существуют 3 роли, которые могут быть назначены коммутаторам стека.
Основной мастер (Primary Master) — основной мастер-коммутатор является ведущим устройством стека и единой точкой управления. Он следит за нормальной работой стека, топологией, назначает
Резервный мастер (Backup Master) — резервный мастер дублирует основной мастер-коммутатор и в случае его выхода из строя берет на себя функции основного мастера. Резервный мастер-коммутатор следит за состоянием соседних коммутаторов стека, основного мастера-коммутатора и выполняет его команды. Роль резервного мастера может быть назначена коммутатору вручную, путем присвоения ему второго по значению наивысшего приоритета до физического объединения устройств в стек или автоматически во время выборов.
Ведомый (Slave) — ведомыми являются все остальные коммутаторы стека. Ведомые коммутаторы выполняют операции, требуемые основным мастером, следят за состоянием соседних коммутаторов стека и топологией, следуют командам резервного мастера, когда он становится основным. Ведомые коммутаторы принимают участие в процессе выбора нового резервного мастера, в случае если:
После того как коммутаторы будут объединены в стек, каждое устройство начнет собирать информацию (такую как приоритет, МАС-адрес) о соседних коммутаторах и сохранять ее во временной базе данных топологии стека (self temp stacking
(рис 26.3) Процесс выбора основного мастера на основании приоритетов
Основным мастером становится коммутатор с наименьшим значением приоритета. Если приоритеты коммутаторов равны, то будет выбран коммутатор с наименьшим значением МАС-адреса.
После выбора основного мастера, начинается процесс выбора резервного мастера из оставшихся устройств стека по аналогичному сценарию.
Как только выбраны основной и резервный мастер, всем коммутаторам стека будут присвоены порядковые номера Box ID. Если в настройках коммутатора параметр Box ID установлен в Auto, основной мастер назначит каждому устройству стека порядковый номер в соответствии с правилами автоматического назначения номеров (основному мастеру в автоматическом режиме присваивается номер 1). Эта информация о топологии будет разослана всем устройствам стека.
(рис 26.4) Процесс выбора основного мастера на основании МАС-адресов при равном значении приоритетов
(рис 26.5) Назначение порядковых номеров в автоматическом режиме
Когда значение параметра Box ID установлено в статический режим (STATIC), присвоение порядковых номеров коммутаторам будет осуществляться вручную администратором сети. При этом настройки любого коммутатора с новым, отличным от предыдущего, значением Box ID будут возвращены к заводским настройкам по умолчанию. Если в процессе изучения топологии стека возник конфликт идентификационных номеров
Следует отметить, что основной мастер-коммутатор и резервный мастер-коммутатор не имеют фиксированных номеров, т.е. основному мастеру может быть присвоен Box ID, отличный от 1.
При работе в смешанном режиме, когда на коммутаторах используется автоматическое и статическое назначение номеров, действует следующее правило:
В случае добавления или удаления коммутатора(-ов) из стека или изменения топологии протокол стекирования, реализованный в устройствах, быстро обнаружит изменения и синхронизирует информацию о новой топологии стека.
Когда новый коммутатор добавляется в работающий стек, ему присваивается роль ведомого или резервного мастера, в зависимости от значений приоритета и МАС-адреса.
Если в стек добавляется только одно устройство, то процесс выбора основного мастера не запускается.
При удалении одного или нескольких коммутаторов из работающего стека оставшиеся коммутаторы удаляют информацию о выбывших устройствах из своих баз данных топологии стека.
При удалении резервного мастера запускается процесс выборов нового резервного мастера. Этот процесс также запускается при удалении или выходе из строя основного мастера, т.к. резервный мастер становится в этом случае основным. При этом для минимизации нарушения работы сети новому основному мастеру присваивается тот же 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) является простым и удобным способом сетевого управления. Она разработана для управления группой коммутаторов, называемых SIM-группой, как единым устройством. При этом для управления SIM-группой требуется только один IP-адрес, который назначается выделенному коммутатору группы (Commander switch).
Технология SIM позволяет:
В отличие от стеков, построенных с использованием традиционных методов стекирования, виртуальный стек на основе технологии SIM не ограничивается 6-ю или 12-ю коммутаторами. В SIM-группу может входить до 32-х коммутаторов любых моделей, поддерживающих функции Single
Объединение коммутаторов в SIM-группу не требует использования специальных соединительных кабелей. Трафик, передаваемый между устройствами стека, проходит через интерфейсы Fast Ethernet, Gigabit Ethernet или 10 Gigabit Ethernet по обычным медным или оптическим кабелям. Отказ от использования специализированных стекирующих кабелей позволяет преодолеть ограничения, связанные с их длиной. Устройства SIM-группы могут быть подключены друг к другу через промежуточные устройства, не поддерживающие технологию SIM. Объединение коммутаторов в SIM-группу не влияет на их нормальное функционирование.
(рис 26.7) Технология SIM
Технология SIM предусматривает три роли, которые могут быть назначены коммутаторам группы:
Все коммутаторы, объединенные в одну 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
Используя топологическую карту, администратор может получать детальную информацию о группе, просматривать краткую информацию о каждом коммутаторе SIM-группы, настраивать его, добавлять и удалять устройства из SIM-группы.
В топологической карте используются следующие иконки для обозначения Commander Switch, Member Switch и Candidate Switch.
(рис 26.9) Топологическая карта
(рис 26.10) Иконки, используемые для представления устройств в топологической карте
Протокол SNMP (Simple
В настоящее время существует три версии протокола SNMP: SNMP v1 (RFC 1157), SNMP v2c (RFC 1901-1908) и SNMP v3 (RFC 3411-3418). Эти версии отличаются предоставляемым уровнем безопасности при обмене данными между менеджером и агентом SNMP. Коммутаторы D-Link поддерживают все три версии протокола.
Сеть, управляемая по протоколу SNMP, основывается на архитектуре "клиент/сервер" и состоит из трех основных компонентов: менеджера SNMP, агента SNMP, базы управляющей информации.
(рис 26.11) Компоненты SNMP
Менеджер SNMP (SNMP Manager) — это программное обеспечение, установленное на рабочей станции управления, наблюдающее за сетевыми устройствами и управляющее ими.
Агент SNMP (SNMP Agent) — это программный модуль для управления сетью, который находится на управляемом сетевом устройстве (маршрутизаторе, коммутаторе, точке доступа, Интернет-шлюзе, принтере и т.д.). Агент обслуживает базу управляющей информации и отвечает на запросы менеджера SNMP.
База управляющей информации (Management Information Base,
Менеджер взаимодействует с агентами при помощи протокола SNMP с целью обмена управляющей информацией. В основном это взаимодействие реализуется в виде периодического опроса менеджером множества агентов, которые предоставляют доступ к информации.
Базы управляющей информации описывают структуру управляющей информации устройств и состоят из управляемых объектов (переменных).
Управляемый объект (или
Обращение к управляемым объектам
Каждая 1.3.6.1.2.1.1 (символьное эквивалентное имя: iso.org.) описывает общую информацию о системе.
(рис 26.12) Пространство имен OID
Производители сетевого оборудования определяют частные ветви пространства имен 1.3.6.1.4.1.171.
Помимо непосредственного описания данных необходимо вести операции над ними. Первоначальная спецификация
Протокол SNMP является простым протоколом типа "запрос — ответ", т.е. на каждый запрос менеджера, агент должен дать ответ. В протоколе определено несколько
Get-Request — запрос значений одного или нескольких объектов;Get-Next-Request — запрос значения следующего объекта в соответствии с алфавитным порядком идентификаторов Set-Request — запрос на изменение значения одного или нескольких объектов;Get(Set)-Reply — получение ответа от агента на сообщение Get-Request, Get-Next-Request или Set-Request.Сообщение (ловушка) используется агентом SNMP для асинхронного сообщения менеджеру SNMP о событии, происходящем на управляемом сетевом устройстве. События могут быть серьезные, например перезагрузка устройства, или менее серьезные, например изменение состояния порта.
Версия SNMP v.2 добавляет к этому набору команду GetBulk, которая позволяет менеджеру получить несколько переменных за один запрос.
При передаче управляющих сообщений в качестве протокола транспортного уровня используется
(рис 26.13) Типы сообщения протокола 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") private — позволить авторизованной рабочей станции читать и изменять (право "read/write") Community string передаются по сети в открытом виде.
Протокол SNMP v.3 использует более сложный процесс аутентификации, который разделен на две части. Первая часть — обработка списка и
На коммутаторе SNMP можно создавать группы со списками пользователей (менеджеров SNMP) и настраивать для них общий набор привилегий. Помимо этого, для каждой группы может быть установлена версия используемого ею протокола SNMP. Таким образом, можно создать группу менеджеров SNMP, которым позволено просматривать информацию с правом "read only" или получать ловушки (
При использовании протокола SNMP v.3 отдельным пользователям или группам менеджеров SNMP может быть разрешено или запрещено выполнять определенные функции SNMP-управления. Помимо этого, в SNMP v.3 доступен дополнительный уровень безопасности, при котором SNMP-сообщения могут шифроваться при передаче по сети.
На рис. 26.14 показана схема сети, в которой управление коммутатором может выполняться через управляющую консоль SNMP по протоколу SNMP v.2. В случае обнаружения SNMP-агентом коммутатора каких-либо неполадок он будет отправлять сообщения
(рис 26.14) Схема сети
Настройка коммутатора
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
Реализация RMON основывается на модели "клиент/сервер". На устройствах мониторинга, называемых в терминологии RMON "зондами" (probe), установлено специальное программное обеспечение — агент RMON, которое собирает информацию и анализирует пакеты. Зонды действуют как серверы, а приложения сетевого управления, установленные на станциях управления сетью, исполняют роль клиентов. Агенты RMON могут как размещаться на автономных устройствах, так и встраиваться в коммутаторы, маршрутизаторы и другие сетевые устройства. Станция управления сетью и распределенные зонды RMON взаимодействуют по сети по протоколу SNMP.
(рис 26.15) Консоль и зонд RMON
Несмотря на то, что RMON является расширением протокола SNMP, он отличается от него тем, что зонды RMON могут самостоятельно выполнять сбор и обработку данных. Это позволяет сократить трафик SNMP в сети и нагрузку на станцию управления, причем информация будет передаваться на станцию только когда это необходимо. Расположенные в различных частях сети приложения RMON могут одновременно взаимодействовать и получать информацию от одного и того же зонда.
RMON поставляет информацию в группы RMON
Для настройки RMON на коммутаторах D-Link второго уровня требуется активизировать эту функцию глобально на коммутаторе с помощью команды enable rmon.
| № | Группа RMON | Функция |
|---|---|---|
| 1 | Statistics | Содержит статистические данные, измеренные датчиком на каждом интерфейсе устройства, для которого проводится мониторинг |
| 2 | History | Периодическая запись статистических выборок из сети и их хранение для дальнейшего использования |
| 3 | Alarm | Периодическое извлечение статистических выборок из переменных в датчике и их сравнение с заранее выбранными пороговыми значениями. Если наблюдаемые значения выходят за границы пороговых, генерируется событие |
| 4 | Host | Содержит статистические данные, связанные с каждым узлом, обнаруженным в сети |
| 5 | Hosts top N | Содержит отсортированные данные по указанному числу узлов в порядке убывания их статистики |
| 6 | Matrix | Содержит статистику по диалогам между парами узлов, в том числе о величине трафика и количестве ошибок в обоих направлениях |
| 7 | Filter | Содержит условия фильтрации пакетов |
| 8 | Capture | Содержит пакеты, захваченные интерфейсом в соответствии с условиями фильтрации |
| 9 | Event | Протоколирование событий и определение действий при их наступлении |
| 10 | Token Ring | Расширенная статистика для сетей Token Ring |
| № | Группа RMON | Функция |
|---|---|---|
| 1 | Protocol Directory | Список протоколов, для которых зонд может осуществлять мониторинг пакетов |
| 2 | Protocol Distribution | Статистика трафика для каждого протокола с информацией о распределении и тенденциях в использовании протоколов |
| 3 | Address Map | Соответствия между адресами сетевого уровня и MAC-адресами, обнаруженные зондом на интерфейсе |
| 4 | Network-Layer Host | Статистика трафика передаваемого от и к каждому обнаруженному зондом узлу |
| 5 | Network-Layer Matrix | Содержит статистику по диалогам между парами узлов на сетевом уровне |
| 6 | Application-Layer Host | Статистика трафика передаваемого от и к каждому обнаруженному зондом узлу по протоколам |
| 7 | Application-Layer Matrix | Статистика трафика по диалогам между парами узлов на сетевом уровне по протоколам |
| 8 | User History | Периодические выборки для определенных пользователем переменных |
| 9 | Probe Configuration | Удаленная конфигурация параметров зонда |
При настройке функции на коммутаторе третьего уровня необходимо дополнительно активизировать протокол SNMP и определить Community string.
Функция 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
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.