Zyxel XMG1930-30HP: обзор способов управления
В прошлой статье мы разобрались с внешним видом, индикаторами и даже заглянули внутрь коммутатора. Теперь пришла пора его подключить и посмотреть, каким образом системные администраторы и сетевые инженеры могут управлять этим устройством и контролировать его параметры.
Физическая консоль
Начнём с самого простого и кондового способа подключения к консоли коммутатора. Искать мудрёные переходники или специфичные кабели не потребуется, подойдёт любой кабель USB Type-C от смартфона. При подключении он определяется, как CP2102N USB to UART Brigde Controller (VID_10C4&PID_EA60) от Silicon Labs. Фактически, обычный виртуальный COM-порт.
На странице загрузок вы можете найти драйверы для Windows 10 версии 1803 и выше (x64, x86) и Windows 11 (x64). Но даже если возникла необходимость подключиться с древнего железа, имеющего лишь Windows XP на борту, то никаких проблем не будет. Подойдут родные драйверы, доступные на сайте Silicon Labs. Более того, там есть драйверы для любого Linux-дистрибутива с версией ядра от 2.6 и даже для Windows CE 5.0/6.0.
Проверим это и подключимся с 20-летнего ноутбука на базе Windows XP. После установки драйверов в системе появился COM-порт (COM4), который можно использовать для дальнейшего подключения:
Предположим, что на компьютере нет даже намёка на PuTTY и воспользуемся стандартным HyperTerminal, который шёл в комплекте с ОС. Выставляем скорость подключения 115200 бод и не забываем отключить аппаратное управление потоком. Остальные параметры оставляем по-умолчанию:
Вот так, имея на руках почти любой старый ноутбук с USB-портом и Windows XP на борту, можно настроить оборудование из 2023 года. Универсальность играет важную роль, особенно когда коммутатор надо установить и настроить вдали от цивилизации.
CLI
Zyxel XMG1930–30HP имеет Cisco-подобный CLI. Он не пытается полностью имитировать поведение IOS, хотя основные принципы те же, что будет удобно для админов старой закалки. Автодополнение по Tab и сокращения команд, пришедшие аж со времён OpenVMS.
Доступность CLI-команд зависит от типа лицензии. С базовой лицензией подключение к физической консоли даёт лишь доступ для дебага. Если коммутатору по каким-то причинам стало плохо и иные способы диагностики недоступны, то можно подключиться в физическую консоль и с помощью базовых команд разобраться в происходящем. Полноценное конфигурирование через CLI доступно лишь при покупке лицензии L3 Access.
Для начала, выполним несколько простых действий, например, построим LACP из двух линков до соседнего роутера Mikrotik (который прикинется коммутатором и на котором заранее настроили bonding-интерфейс).
Переходим в режим конфигурирования:
XMG1930# configure
Активируем сам механизм работы LACP:
XMG1930(config)# lacp
Активируем транк с ID T1:
XMG1930(config)# trunk T1
Указываем, что транк T1 будет работать по протоколу LACP:
XMG1930(config)# trunk T1 lacp
Теперь пропишем, что в этом транке будет два физических интерфейса (например, порты 21 и 22):
XMG1930(config)# trunk T1 interface 21,22
Выходим из режима конфигурирования:
XMG1930(config)# exit
Проверяем состояние транка T1:
XMG1930# sh trunk group T1 Group ID T1: active Criteria : src-dst-mac Status: LACP Member number: 2 Member:21 22
Окидываем взглядом конфиг:
XMG1930# sh run
Втыкаем оба линка. Посмотрим на состояние агрегированного канала:
XMG1930# sh lacp group T1 AGGREGATOR INFO: ID: 1 [(ffff,f4-4d-5c-69-ed-fa,0001,00,0000)][(ffff,c4-ad-34-bc-99-f0,0009,00,0000)] LINKS : [21]-[22]- SYNCS : [21]-[22]-
Видим, что линк есть на обоих портах и они оба настроены на работу с LACP. В строке вывода отображается MAC-адрес партнёра. С другой стороны можем посмотреть, как это будет выглядеть на Mikrotik:
[admin@MikroTik] > interface/bonding/print
Flags: X - disabled; R - running
0 R ;;; LACP_Uplink
name="WAN" mtu=1500 mac-address=C4:AD:34:BC:99:F0 arp=enabled
arp-timeout=auto slaves=ether1,ether2 mode=802.3ad primary=none
link-monitoring=mii arp-interval=100ms arp-ip-targets=""
mii-interval=100ms down-delay=0ms up-delay=0ms lacp-rate=30secs
transmit-hash-policy=layer-2 min-links=0
Буква R говорит о том, что интерфейс запущен. Теперь посмотрим на состояние портов:
[admin@MikroTik] > interface/bonding/monitor WAN
mode: 802.3ad
active-ports: ether1,ether2
inactive-ports:
lacp-system-id: C4:AD:34:BC:99:F0
lacp-system-priority: 65535
lacp-partner-system-id: F4:4D:5C:69:ED:FA
Здесь всё хорошо, оба порта в статусе Active, а в графе lacp-partner-system-id отображается MAC-адрес нашего коммутатора. Теперь этот агрегированный интерфейс будет увеличивать пропускную способность и резервировать канал на случай потери любого из линков.
Веб-интерфейс
Главная страница встречает нас наиболее важными параметрами коммутатора. Так, например, мы сразу видим наличие линка на портах, скорость соединения, утилизацию процессора и памяти, а также потребляемый PoE «бюджет». Нажав на любой порт, его можно включить или выключить, там же есть и выключатель для PoE:
На дашборде также отображаются некоторые полезные данные, вроде хостнейма, версий прошивки, аптайма, наличие алертов по температуре и работе вентиляторов. Ещё можно сделать собственную небольшую подборку из десяти быстрых ссылок на наиболее важные для вас части веб-интерфейса. Например, просмотр статуса агрегированных линков:
В прошлой статье про этот коммутатор мы уже упоминали, что у него есть два режима работы. По-умолчанию работает Standalone-режим, но при этом коммутатор периодически проверяет доступность централизованной системы управления сетью Nebula. Светодиод CLOUD на передней панели при этом мигает жёлтым раз в секунду. Чтобы запретить коммутатору взаимодействовать с Nebula, достаточно отключить соответствующую опцию NCC Discovery. Индикатор CLOUD при этом погаснет, а вы сможете использовать коммутатор только в локальном режиме:
Важно также сразу заглянуть в раздел Remote management и отключить те способы управления, которые могут быть небезопасными. Тот же Telnet, например, вообще никак не шифрует данные, что может стать проблемой безопасности. Тем не менее, все ключевые производители телекоммуникационного оборудования продолжают встраивать поддержку этого протокола в свои устройства и он почти всегда включен по-умолчанию.
Точно также, как в Cisco вы привыкаете выполнять команду # wr mem, имеет смысл выработать привычку нажимать на кнопку сохранения конфигурации. Без этого установленная конфигурация будет работать лишь до перезапуска. Наверное её стоило бы как-то выделить в веб-интерфейсе, возможно это допилят в будущих версиях прошивки.
Особенность штатного веб-интерфейса в том, что максимально используются штатные HTML-элементы, такие как чекбоксы, выпадающие списки и поля для ввода данных. Это сильно снижает риск того, что в разных браузерах страница будет выглядеть по-разному. Понятное дело, что в каком-нибудь Internet Explorer 6, вам уже вряд ли удасться что-нибудь настроить. Но в любом более-менее современном браузере, с поддержкой JavaScript, страницы уже будут отображаться корректно.
При заходе с мобильного устройства, страница отображается в десктопной версии. Какой-либо адаптации под экраны мобильных устройств нет. Это скорее плюс, чем минус, ведь это позволяет системному администратору пользоваться единым интерфейсом и на смартфоне, и на обычном компьютере. Это значит, что не придётся искать, куда же дизайнеры интерфейсов запихнули ту или иную функцию в мобильной версии.
Управление по SNMP
Протокол SNMP применяется для мониторинга и управления сетями более трёх десятков лет и встречается практически во всех сетевых устройствах. Мы не будем касаться сейчас архитектуры и безопасности этого протокола, а посмотрим исключительно с утилитарной точки зрения. Для начала, настроим параметры работы SNMP: заменим строки Community на собственные и создадим тестового юзера:
Чтобы получить идентификаторы объектов (OIDs) нам понадобятся MIB-таблицы. Это иерархические сборники идентификаторов, обеспечивающий каждый аспект мониторинга и управления устройством. Скачать их можно там же, где и драйверы, на странице загрузок. В архиве будет коллекция из более чем сотни MIB-таблиц. Загрузив её в какой-нибудь iReasoning MIB Browser можно посмотреть какие OID за что отвечают:
Сделав Get-запрос мы получим актуальное значение выбранного OID. Выставив нужное значение через Set-запрос, есть возможность управлять коммутатором. Так, например, если выставить OID .1.3.6.1.4.1.890.1.15.3.2.1 в значение 1, то коммутатор отправится в перезагрузку. Ну, а если присвоить .1.3.6.1.4.1.890.1.15.3.2.3 значение 1, то это сбросит текущую конфигурацию к заводским настройкам.
Разумеется, есть возможность настройки SNMP «ловушек», что позволяет оперативно мониторить состояние портов, доступность IP-адресов и в целом отслеживать базовые параметры системы. Поддержка SNMP есть во всех популярных системах мониторинга, так что с интеграцией не должно возникнуть проблем.
Управление через Nebula
В заключение расскажем ещё об одном способе управления, который будет удобен в определённых ситуациях. Zyxel встроил в эти устройства поддержку своей централизованной системы управления Nebula. Это позволяет выполнять забавный трюк, когда вы можете предварительно настроить новый коммутатор, даже не вынимая его из коробки.
Вот заказали вы новое оборудование для филиалов. Оно пришло к вам в центральный офис и теперь стоит задача его распаковать, заранее сконфигурировать и отправить туда, где оно будет стоять. Но в случае с Zyxel можно сделать ещё интереснее. Достаточно лишь открыть приложение Nebula на смартфоне, зайти в аккаунт и отсканировать все QR-коды с упаковки приобретённых устройств. Этим действием они будут добавлены в аккаунт:
Мы уже упоминали выше, что поиск Nеbula Control Center активирован по-умолчанию и как только устройство выйдет в интернет, то автоматически подключится к Nebula. Это даст полный контроль над ним и сможете сконфигурировать его удалённо через свой аккаунт.
Стандартные реквизиты доступа (admin/1234) будут автоматически заменены на те, которые вы укажете в настройках Конфигурация > Настройка площадки. Это затрагивает, как Web-интерфейс, так и CLI:
В остальном, управление через Nebula можно назвать даже более удобным, чем через штатный веб-интерфейс. Здесь также присутствует карта портов, через которую можно открыть настройки любого конкретного порта и изменить их по своему усмотрению.
Nebula явно задумывалась, как система «одного окна» в которой можно решать сразу административные и сетевые задачи. Инвентаризация — легко, все данные об устройствах накапливаются в одном месте. Понадобилось перенести их в другую систему — выгрузили в CSV или XML для дальнейшего импорта в другие приложения.
Там же расположен простой мониторинг, накапливающий в себе статистику утилизации аплинка и PoE «бюджета». Это позволяет оптимально планировать сеть и лучше понимать профиль нагрузки на каждое отдельное устройство. Nebula умеет автоматически строить топологию сети, а после недавнего обновления в ней появилось отображение клиентских устройств. Это очень удобно, ведь просто взглянув на карту, вы сразу понимаете в какой порт воткнуто то или иное устройство.
Естественно, сразу становится проще настройка уведомлений. Системный администратор может настроить автоматическое получение отчётов по E-mail. Что-то пошло не так — без промедления получили push-уведомление в приложении на смартфоне. Опять же, все логи вы найдёте там же, в Nebula.
В следующей статье мы расскажем про то, как в этом коммутаторе реализована поддержка технологии AV over IP и как с её помощью раздавать видеопотоки в высоком качестве.
