59 средства управления коммутаторами

Обновлено: 05.07.2024

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

сетей производства компаний Bay Networks, Cabletron Systems, Cisco Systems и 3Com.

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

"Если учесть, что всего лишь 12-15 месяцев назад никаких средств управления коммутаторами не было, то станет ясно, что промышленность прошла за это время длинный путь, - говорит Джон Моренси, руководитель консалтинговой компании The Registry (Ньютон, шт. Массачусетс). -Однако некоторые производители продвинулись в этом направлении значительно дальше, чем другие".

Одним из признаков, позволяющих различать изделия разных производителей, является возможность автоматического распределения конечных станций по одной или нескольким виртуальным локальным сетям (Virtual Local Area Network - VLAN). Как отмечают отраслевые обозреватели, в этом отношении лучше других выглядят продукты фирмы Cabletron. "Vnet Manager производства Cabletron действительно умеет выяснять, как устроена сеть и автоматически конфигурировать виртуальные сети, - говорит Джеймс Вайдель, директор по компьютерным сетям Южно-Калифорнийского университета, в котором используются коммутаторы Cabletron. - Я не знаю другого производителя, который справлялся бы с этой задачей столь успешно".

При работе с коммутаторами Bay на организацию виртуальной сети приходится затрачивать значительно больше усилий. Чтобы перевести конечную станцию из одной виртуальной сети в другую, администратор сети должен запустить программу LAN Architect компании Bay и "отбуксировать" данного пользователя из одной подсети в другую; после этого следует воспользоваться программой AutoSphere Topolgy (входящей в пакет Network Atlas) и убедиться, что соответствующее изменение действительно было внесено. "Для того чтобы просто изменить конфигурацию сети, приходится запускать две программы, - говорит Джон Моренси. - Бесспорно, Bay нуждается в более полной интеграции продуктов. По существу, Cabletron - единственная компания, обеспечивающая полную автоматизацию этой функции".

По мнению аналитиков, Cabletron также лидирует в области систематического управления виртуальными сетями (policy-based management). Это - основной компонент приложения управления Vnet Manager. "Компании вроде Cisco постепенно эволюционируют в сторону систематической модели автоматических VLAN, той самой, которая уже сейчас реализована в изделиях Cabletron, - говорит Джон Моренси. - Не думаю, чтобы Cisco или 3Com получили систематические VLAN ранее конца 1997 года."

Однако, как утверждают аналитики, изделия Cabletron отстают в других важных областях управления сетями, например в RMON2 и средствах управления временем реакции (response time). "Отсутствие поддержки RMON2 может принести вред Cabletron, - утверждает Джон Мак-Коннелл, президент компании McConnell Consulting (Боулдер, шт. Колорадо). - Кроме того, продукция Cabletron предоставляет администраторам сетей недостаточные средства для контроля за пропускной способностью сети и временем реакции, принадлежащего к числу наиболее важных функций управления."

Заметные различия между продуктами разных производителей имеются также в области моделирования сети. Например, компании Bay и Cisco поставляют средства моделирования и проектирования сетей вместе с программами Optivity Design и NetSys соответственно. Однако у Cabletron и 3Com нет таких программ, которые могли бы стать основной частью приложений управления и, как считают аналитики, эти компании не имеют партнерских отношений с теми фирмами, которые могли бы предоставить им такие средства.

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

Как указывают аналитики, ни одна из компаний, входящих в Большую Четверку, не поставляет средства, способные собирать данные о времени реакции, и не обеспечивает получения сведений о топологии сети на уровне приложений. "Нам нужна более полная информация о топологии сети, поскольку в настоящее время отказы сети на логическом уровне могут быть не видны на топологических картах физического уровня и наоборот," - утверждает Кэти Линд, администратор сети на базе оборудования 3Com клиники при Университете штата Колорадо (Денвер).

С ней согласен Брайан Штенгель, руководитель рабочей группы по управлению сетями компании American Greetings (Кливленд), являющийся клиентом фирмы Cisco. "Мы пользуемся пакетами HP OpenView и CiscoWorks, и получаемые нами картины топологии сети совершенно не отражают того, что происходит в действительности. Поэтому главной задачей производителей должно стать обеспечение сквозного управления работой приложений, - говорит Моренси. - Решив эту задачу, они смогут выйти на следующий уровень."

По мнению аналитиков коммутаторы фирмы Cabletron Systems лидируют в области автоматического определения и конфигурирования виртуальных локальных сетей (VLAN) однако в них отсутствует поддержка RMON2 и средств моделирования сети.

Различия продуктов компаний Большой Четверки в области управления коммутируемыми локальными сетями

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



Мы уже много писали о возможностях, которые предоставляют современные коммутаторы с загрузочной средой ONIE и открытые ОС на базе Linux для них. Построение L3-фабрик, оверлейные виртуальные сети L2, — все это уже было. Но осталась нераскрытой одна важная тема, о которой много упоминалось — возможности по автоматизации.

Командная строка — это, конечно, здорово и вообще классика, но в 2014 году хочется уже большего. Особенно если работать приходится с десятками и сотнями устройств в одной сети.

Так что же мы получаем при использовании коммутатора c ОС на основе Linux, такой как Cumulus?

Автоматизация начинается уже на этапе подключения коммутатора в сетевую среду. И за это стоит благодарить установочную среду ONIE, пришедшую на смену PXE. При первой загрузке при помощи опции 239 DHCP запрашивается URL-адрес, с которого будет получаться образ системы. А вместе с ним запрашивается скрипт, который будет выполнен при установке. В список поддерживаемых языков входят Bash (Shell), Perl, Python, Ruby. Типичный пример выглядит примерно так:


Zero Touch Provisioning

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

Но вот мы прорвались за этап установки, и тут уже начинается все самое интересное, что есть в мире Linux.

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


Маршрутизация на узлах обмена траффиком

Про VMware NSX мы писали в нашем предыдущем материале, а OpenStack — настолько объемная тема, что требует даже не отдельной статьи, а целого цикла статей, так что эту часть мы, пожалуй, оставим без дополнительных комментариев.

    — написанная на Ruby одна из самых известных клиент-серверных систем управления конфигурациями ОС и ПО при помощи специального языка Guide — еще одна широко известная система конфигурации — третья конфигурационная система с мировой известностью

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

И еще несколько слов о популярных пакетах управления сетевыми интерфейсами. Наверняка многим известен такой пакет Debian, как ifupdown. В Cumulus используется его обновленная версия ifupdown2:


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

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

Prescriptive Topology Manager (PTM)
Еще одной полезной функцией на стыке мониторинга и автоматизации является PTM. Этот пакет позволяет при помощи LLDP опроса ближайших соседей и BFD (Bidirectional Forwarding Detection) найти сбои в существующих путях, построить реально существующую топологию сети и сравнить ее с заранее заданной файлом topology.dot. Последний представляет собой файл формата graphviz-DOT — сравнительно распространенный способ текстового описания графа соединений, достаточно удобный как для работы с ним в качестве текста, так и для преобразования в графическое отображение топологии.


Prescriptive Topology Manager

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

Ну вот как-то так выглядит ситуация с автоматизацией в современных сетевых открытых ОС.
А чем пользуетесь вы?

Коммутаторы локальной сети можно классифицировать по возможности управления. Существует три категории коммутаторов:

  • неуправляемые коммутаторы;
  • управляемые коммутаторы;
  • настраиваемые коммутаторы.

Неуправляемые коммутаторы не поддерживают возможности управления и обновления программного обеспечения.

Управляемые коммутаторы являются сложными устройствами, позволяющими выполнять расширенный набор функций 2-го и 3-го уровня модели OSI . Управление коммутаторами может осуществляться посредством Web-интерфейса, командной строки ( CLI ), протокола SNMP , Telnet и т.д.

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

Средства управления коммутаторами

Большинство современных коммутаторов поддерживают различные функции управления и мониторинга. К ним относятся дружественный пользователю Web- интерфейс управления, интерфейс командной строки ( Command Line Interface , CLI ), Telnet, SNMP -управление. В коммутаторах D-Link серии Smart также реализована поддержка начальной настройки и обновления программного обеспечения через утилиту D-Link SmartConsole Utility .

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

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

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

Еще один способ управления коммутатором — использование протокола SNMP (Simple Network Management Protocol ). Протокол SNMP является протоколом 7-го уровня модели OSI и разработан специально для управления и мониторинга сетевыми устройствами и приложениями связи. Это выполняется путем обмена управляющей информацией между агентами, располагающимися на сетевых устройствах, и менеджерами, расположенными на станциях управления. Коммутаторами D-Link поддерживается протокол SNMP версий 1, 2с и 3.

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

Подключение к коммутатору

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

При подключении к медному ( разъем RJ-45 ) порту Ethernet коммутатора Ethernet -совместимых серверов, маршрутизаторов или рабочих станций используется четырехпарный кабель UTP категории 5, 5е или 6 для Gigabit Ethernet . Поскольку коммутаторы D-Link поддерживают функцию автоматического определения полярности ( MDI /MDIX), можно использовать любой тип кабеля ( прямой или кроссовый).

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

Для подключения к медному ( разъем RJ-45 ) порту Ethernet другого коммутатора также можно использовать любой четырехпарный кабель UTP категории 5, 5е, 6, при условии, что порты коммутатора поддерживают автоматическое определение полярности. В противном случае надо использовать кроссовый кабель .

Подключение коммутатора к обычному (не Uplink) порту коммутатора с помощью прямого или кроссового кабеля


Рис. 2.2. Подключение коммутатора к обычному (не Uplink) порту коммутатора с помощью прямого или кроссового кабеля

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

Подключение к консоли интерфейса командной строки коммутатора

Управляемые коммутаторы D-Link оснащены консольным портом. В зависимости от модели коммутатора консольный порт может обладать разъемом DB-9 или RJ-45 . С помощью консольного кабеля, входящего в комплект поставки, коммутатор подключается к последовательному порту компьютера. Подключение по консоли иногда называют "Out-of-Band-подключением. Это означает, что консоль использует отличную от обычного сетевого подключения схему (не использует полосу пропускания портов Ethernet).

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

При соединении коммутатора с консолью появится следующее окно (только для коммутаторов, имеющих поддержку интерфейса командной строки CLI) (рис. рис. 2.3).

Если окно не появилось, необходимо нажать Ctrl+r, чтобы его обновить.

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

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

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

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

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

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

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

1. rConfig

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

Читайте также: