Инструменты пользователя

Инструменты сайта


Боковая панель

Разделы

Общее описание
История изменений
Рекомендации к обновлению
Планы на будущее
Известные проблемы
Онлайн демо
Случайная статья
Видео
Помощь проекту
Люди

FAQ



Редактировать сайдбар

switchpoller

Опрос свичей посредством SNMP

В Ubilling начиная с релиза 0.4.1 появилась возможность опроса активного сетевого оборудования посредством SNMP (требует установленного net-snmp). Механика опроса шаблонизирована и позволяет опрашивать оборудование по любым OID-ам. Также модуль «Опрос свичей» использует в своей работе кеширование результатов, что позволяет сделать отображение результатов приемлемым по времени.

Поддерживаемое из коробки оборудование

  • ZyXEL GS-4012F
  • ZyXEL GS-3012F
  • ZyXEL ES-2108
  • ZyXEL ES-2108G
  • Zyxel GS-2200-24
  • Cisco Catalyst 3500
  • Cisco Catalyst WS-C3548-XL-EN
  • Cisco-2940-8TT-S
  • Cisco Catalyst 3750G-24TS-S
  • Cisco Catalyst 3750-24TS-S
  • Cisco Catalyst 3560-24TS-S
  • Cisco SF300-24
  • Cisco Catalyst 2960-24TC-L
  • Cisco Catalyst C2960-48TC-L
  • Foxgate S6248-S4
  • Foxgate S6224-S4
  • Foxgate S6208-S1
  • Foxgate S6424-S2C2
  • Foxgate-S6224-S2
  • Foxgate-S-6008-S1L2
  • D-Link DES-3200-10
  • D-Link DES-3200-18
  • D-Link DES-3200-26
  • D-Link DES-3200-28
  • D-Link DES-3526
  • D-Link DES-1228/ME
  • D-Link DGS-1100-6/ME
  • D-Link DGS-3120-24sc
  • D-Link DES-3200-28F
  • D-Link DGS-1510-52
  • D-Link-DGS-1210-20
  • D-Link-DES-2108
  • D-Link-DES-3010G
  • D-Link-DES-3026
  • D-Link-DES-3226S
  • D-Link-DGS-3100-24TG
  • D-Link-DGS-1500-20
  • D-Link-DGS-3000-10TC
  • D-Link-DGS-3024
  • D-Link-DGS-3200-10
  • D-Link-DES-3028
  • Dlink-DES-1210-26
  • Dlink-DES-1210-28
  • Dlink-DGS-1210-10
  • Dlink-DGS-1210-12TS
  • Dlink DGS-3000-28SC
  • HP ProCurve Switch 2626
  • HP ProCurve Switch 2650
  • HP ProCurve Switch 2524
  • HP ProCurve Switch 2824
  • Dell PowerConnect 5324
  • Alcatel LS-5224
  • Huawei S2326TP
  • Extreme Networks Summit 200-24
  • ZIZITRA
  • TP-LINK TL-SG5412F
  • TP-LINK TL-SL5428E v2
  • Edge-Core ECS3510-28T
  • Huawei s232tp_c05
  • Eltex MES1124MB
  • Eltex MES2124MB
  • Eltex MES2124F
  • Eltex MES3108F
  • 3COM-3250

И много-много других, о которых мы уже задолбались писать. Давайте вы сами посмотрите что будет работать из коробки заглянув в директорию config/snmptemplates?

Настройка

В общем случае настройка сводиться к добавлению модели свича с правильным шаблоном SNMP

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

Если все добавлено верно - у свича в колонке действия должна появиться иконка «Опрос при помощи SNMP»

Набор параметров запрашиваемых с устройства, полностью зависит от выбранного шаблона и может быть практически произвольным. Также возможно отображение FDB с устройства.

Учитывая, что опрос устройства происходит не слишком быстро, для ускорения отображения результатов используется механика кеширования. Для периодического опроса всех устройств, с целью заполнения кеша сырых данных следует использовать вызов swpoll из API удаленного вызова процедур.

Формат шаблона для опроса устройства

Шаблоны всех устройств лежат в /config/snmptemplates/ и имеют например какой-то такой вид:

megaswitch9000
[define]
DEVICE="ZIZITRA MegaSwitch-9000 2ports"
FDB=true
FDB_MODE=default
 
[PORTSTATE]
NAME="Port states"
OIDS=".1.3.6.1.2.1.2.2.1.8.1,.1.3.6.1.2.1.2.2.1.8.2"
PARSER=sp_parse_zyportstates
 
[UPTIME]
NAME="Uptime"
OIDS=".1.3.6.1.2.1.1.3.0"
PARSER=sp_parse_raw

или такой для OLT:

BDCOM_GP3608
[define]
DEVICE="BDCOM OLT GP3600-8"
PON_ONU_PORT_MAX=128
 
[signal]
SIGNALMODE="GPBDCOM"
SIGINDEX=".1.3.6.1.4.1.3320.10.3.4.1.2"
MACINDEX=".1.3.6.1.4.1.3320.10.3.3.1.2"
SIGVALUE="INTEGER:"
MACVALUE="STRING:"
OFFSET="10"
OFFSETMODE="div"
DOWNVALUE="2147483648"
 
[misc]
ONUINDEX=".1.3.6.1.4.1.3320.10.3.3.1.2"
ONUVALUE="STRING:"
FDBINDEX=".1.3.6.1.2.1.17.7.1.2.2.1.1"
FDBVALUE="Hex-STRING:"
FDBDEVINDEX=".1.3.6.1.2.1.17.7.1.2.2.1.2"
FDBDEVVALUE="INTEGER:"
DISTINDEX=".1.3.6.1.4.1.3320.10.3.1.1.33"
DISTVALUE="INTEGER:"
INTERFACEINDEX=".1.3.6.1.2.1.2.2.1.2"
INTERFACEVALUE="STRING:"
RTTINDEX=".1.3.6.1.4.1.3320.101.11.1.1.8"
 
[system]
CPULOAD=".1.3.6.1.2.1.25.3.3.1.2"

Как видим файл состоит из секций.
Секция [define] является обязательной. В ней описываются такие характеристики устройства как DEVICE (полное наименование модели) и булевый параметр FDB - означающий, что для устройства следует попытаться достать FDB а также необязательный параметр FDB_MODE указывающий на метод опроса FDB таблиц. Он может принимать значения default (по-умолчанию) или dlp (для некоторых моделей свитчей Dlink) и tlp5428ev2 для соответствующего tp-link. В случае, если параметр FDB_MODE не указан, по-умолчанию будет считаться, что он установлен в значение default.
Также существуют необязательные параметры:

  • FDB_ALLOW_ONLY_PORTS - указывает, что исключительно те MAC адреса, которые находятся за этими портами, будут учтены при парсинге FDB.
  • FDB_IGNORE_PORTS - указывает порты, MAC адреса находящиеся за которыми будут исключены при парсинге FDB.

Следует отметить, что параметр FDB_ALLOW_ONLY_PORTS имеет преимущество и, если номер порта будет указан одновременно в обеих этих опциях - преимущество будет за FDB_ALLOW_ONLY_PORTS и МАСи с этого порта таки попадут в FDB-кэш.

Далее каждая из секций описывает уникальный набор параметров, по которому будет опрашиваться устройство. Имя секции особого значения не имеет и просто должно быть уникальным. Каждая секция состоит из как минимум трех обязательных переменных. Это NAME - отображаемое название опрашиваемой характеристики (будет локализовано), OIDS - список OID-ов через запятую которые будут опрошены для конкретной модели и PARSER - парсер данных, через который будут пропущены данные полученные от каждого OID-а в текущей секции. Из вышеприведенного примера можно заключить, что данный шаблон будет отображать состояние двух первых портов свича и его аптайм а также пытаться показывать таблицу соответствия MAC-ов по портам.
Начиная с релиза Ubilling 0.8.5 также можно хранить ваши шаблоны в content/documents/mysnmptemplates/. Они будут иметь приоритет перед базовыми и будут нормально переживать обновления биллинга. Также, если вам требуется изменить поведение какого-то существующего шаблона (например игнорируемые FDB порты) потрудитесь перед модификацией, скопировать его в content/documents/mysnmptemplates/ и редактировать его уже там.

На данный момент доступны следующие парсеры полученных из OID данных:

  • sp_parse_raw - данные показываются как есть без особой обработки
  • sp_parse_raw_sanitized - данные будут показаны как есть, просто с выкушенным типом.
  • sp_parse_zyportbytes - счетчики байт/пакетов на портах
  • sp_parse_zyportdesc - строковые описания портов
  • sp_parse_zyportstates - состояние портов
  • sp_parse_ciscocpu - нагрузка на CPU в %
  • sp_parse_ciscomemory - количество занятой памяти в Мб
  • sp_parse_eltex_acpower - напряжение AC питания свитчей Eltex
  • sp_parse_eltex_dcpower - напряжение DC питания свитчей Eltex
  • sp_parse_eltex_battery - уровень заряда АКБ свитчей Eltex
  • sp_parse_fxportstates - состояние портов для некоторых Foxgate 60xx
  • sp_parse_fxportbytes - счетчики байт/пакетов на портах для некоторых Foxgate 60xx
  • sp_parse_cable_tester - парсер кабельного тестера для свитчей Dlink
  • sp_parse_time_seconds - парсер времени из секунд в человеко-читабельный вид
  • sp_parse_power - парсер наличия электроэнергии (1/0).
  • sp_parse_eping_temp - парсер температуры с Equicom ping3 (да, она тупо делиться на 10)
  • sp_parse_eping_temp_gauge - нормальный такой градусник для Equicom ping3

Также доступны следующие режимы FDB:

  • default
  • dlp
  • tlp5428ev2
  • tlp2428
  • tlp2210
  • flp
  • ciscoebobo

Формат "кумулятивного" шаблона для опроса устройства

Полностью базируется на базовом формате шаблонов, но имеет свои особенности, о которых будет рассказано ниже. Собственно вся «кумулятивность» заключается в том, что нам не нужно указывать конкретный порт для каждой секции в конце OID'а - мы указываем только OID необходимой нам таблицы, будь то dot1dFdb, dot1qFdb, банальный ifDescr или чуть менее банальный ifAlias. А дальше наш модуль уже самостоятельно переберет все имеющиеся порты и по их индексам постарается достать все, что сможет(ну, из того, что мы укажем в шаблоне, конечно).

Итак, новые параметры секции [define]:

  • POLLMODE должен быть всегда cumulative, если мы хотим именно «кумулятивно обрабатывать шаблон»
  • FDB_MODE должен быть всегда sw_cumulative, если мы хотим попытаться достать описания интерфейсов и номера VLAN
  • SFPSTARTPORT, SFPENDPORT - полезны для устройств, имеющих на борту как медные, так и SFP-порты, для которых вы собираетесь в шаблоне использовать секции [SFP….], такие как [SFPTXPOWER], [SFPRXPOWER], [SFPWAVELENGTH] и прочие. Нужны они главным образом для того, чтобы избежать визуализации пустых значений для медных портов.
  • POESTARTPORT, POEENDPORT - используются ровным счетом для тех же целей, что и предыдущие два параметра, только на этот раз с их помощью мы определяем PoE порты устройства. То бишь порты, с которых опрашиваемый девайс может питать другие девайсы. Для корректного опроса таких портов нам понадобятся секции [POE….]
    • Примеры секций [SFP….] и [POE….] вы найдете ниже, в шаблоне для примера

Далее немного об «особенных» секциях:

PORTIFACE - в этой секции указываются OID'ы для получения индексов портов, дескрипшинов и алиасов портов. На закономерный вопрос: «А зачем и дескрипшины, и алиасы?» - даем не менее закономерный ответ: «А зачем они вообще существуют по отдельности?». Но, если серьезно - логика здесь весьма проста: некоторые девайсы хранят наименования интерфейсов в ifDescr, а некоторые - в ifAlias. Потому наш модуль сначала пытается найти описание порта в ifDescr, а если не находит - тогда уже в ifAlias. И нам абсолютно не нужно над этим заморачиваться. Удобно, не правда ли?

[PORTIFACE]
PORTINDEX=".1.3.6.1.2.1.2.2.1.1"
PORTDESCR=".1.3.6.1.2.1.2.2.1.2"
PORTALIAS=".1.3.6.1.2.1.31.1.1.1.18"

PORTDESC - как и следует из комментария к этой секции, в кумулятивных шаблонах - это просто заглушка. Когда кумулятивный обработчик «встречает» в шаблоне эту секцию - он просто запускает специальный парсер для обработки описаний/наименований портов устройства.

[PORTDESC]
; just a placeholder
NAME="Desc"

PORT.1D_FDB, PORT.1Q_FDB - еще две секции, характерные только для кумулятивного режима обработки и не предполагающие использования какого-либо парсера. Предназначены для получения FDB-таблицы девайса. Таблица PORT.1Q_FDB, как более подробная и детальная, используется для получения номеров VLAN для МАС адресов с опрашиваемых портов.

[PORT.1D_FDB]
PORTTABLE=".1.3.6.1.2.1.17.4.3.1.2"
PORTSTATUS=".1.3.6.1.2.1.17.4.3.1.3"
 
[PORT.1Q_FDB]
PORTTABLE=".1.3.6.1.2.1.17.7.1.2.2.1.2"
PORTSTATUS=".1.3.6.1.2.1.17.7.1.2.2.1.3"

А ещё мы теперь можем указывать в секциях единицы измерения и величину, на которую нужно поделить возвращённое OID'ом значение, используя параметры DIV и UNITS. Эти параметры могут жить абсолютно раздельно, то есть: для любой секции мы можем указать только один из них. Например, если OID нам возвращает сразу корректное значение, которое не нужно ни на что делить и нам нужно только прицепить к нему единицы измерения, то для секции достаточно указать только один лишь параметр UNITS. Так же стоит отметить, что для корректной обработки этого всего нужно использовать новые парсеры. Выглядит это как-то так:

[SFPTXPOWER]
NAME="SFP TX power"
OIDS=".1.3.6.1.4.1.14988.1.1.19.1.1.9"
DIV=1000
UNITS="dBm"
PARSER=sp_parse_division_units
 
[CPU TEMP]
NAME="CPU temperature"
SECTPOLLMODE="noncumulative"
OIDS=".1.3.6.1.4.1.14988.1.1.3.11.0"
DIV=10
UNITS="C"
PARSER=sp_parse_division_units_noport

Новые парсеры:

  • sp_parse_raw_trim_tab - то же, что и sp_parse_raw, только возвращает одно лишь значение OID'а, обкусывая всё лишнее и в ячейке таблицы.
  • sp_parse_division_units - обрабатывает параметры DIV и UNITS, если таковые есть в секции и производит соответствующие операции деления и «приклеивания» единиц измерения к распарсенному значению. Делает этого для каждого найденного порта, согласно индексу портов и возвращает значение в виде:
    номер порта ⇒ значение_OID + единицы измерения
  • sp_parse_division_units_noport - то же, что и sp_parse_division_units, но ничего не знает о портах и их индексах, обрабатывает одиночное значение. Полезен для вывода информации о таких штуках, как заргузка/температура CPU, температура девайса, скорость оборотов вентилятора и прочей информации о «здоровье» девайса.
  • sp_parse_mikrotik_poe - как несложно догадаться из названия - предназначен для шаблонов устройств Mikrotik с поддержкой питания других устройств по PoE.
  • sp_parse_sw_port_idx - собственно - сердце кумулятивного опроса, задача которого - «построить» индекс портов девайса. Мало полезен для отдельностоящего обособленного использования.
  • sp_parse_sw_port_descr - как и предыдущий парсер - предназначен больше для «служебных» целей. Строит массив описаний/наименований портов, «добывая» их из ifDescr или ifAlias.

Так как же в итоге будет выглядеть кумулятивный шаблон для устройства? Покажем на примере довольно известного девайса Mikrotik RB260GSP / CSS106-1G-4P-1S:

[define]
DEVICE=Mikrotik-CSS106_RB260GSP_SW_SFP
POLLMODE=cumulative
SFPSTARTPORT=5
SFPENDPORT=5
POESTARTPORT=2
POEENDPORT=5
FDB=true
FDB_MODE=sw_cumulative
FDB_ALLOW_ONLY_PORTS=
FDB_IGNORE_PORTS=
 
[PORTIFACE]
PORTINDEX=".1.3.6.1.2.1.2.2.1.1"
PORTDESCR=".1.3.6.1.2.1.2.2.1.2"
PORTALIAS=".1.3.6.1.2.1.31.1.1.1.18"
 
[PORT.1D_FDB]
PORTTABLE=".1.3.6.1.2.1.17.4.3.1.2"
PORTSTATUS=".1.3.6.1.2.1.17.4.3.1.3"
 
[PORT.1Q_FDB]
PORTTABLE=".1.3.6.1.2.1.17.7.1.2.2.1.2"
PORTSTATUS=".1.3.6.1.2.1.17.7.1.2.2.1.3"
 
[PORTSTATE]
NAME="Port states"
OIDS=".1.3.6.1.2.1.2.2.1.8"
PARSER=sp_parse_zyportstates
 
[PORTDESC]
; just a placeholder
NAME="Desc"
 
[PORTTX]
NAME="Bytes transmitted"
OIDS=".1.3.6.1.2.1.2.2.1.16"
PARSER=sp_parse_zyportbytes
 
[PORTRX]
NAME="Bytes received"
OIDS=".1.3.6.1.2.1.2.2.1.10"
PARSER=sp_parse_zyportbytes
 
[PORTERRTX]
NAME="TX errors"
OIDS=".1.3.6.1.2.1.2.2.1.20"
PARSER=sp_parse_zyportbytes
 
[PORTERRRX]
NAME="RX errors"
OIDS=".1.3.6.1.2.1.2.2.1.14"
PARSER=sp_parse_zyportbytes
 
[PORTMULTTX]
NAME="Multicast TX"
OIDS=".1.3.6.1.2.1.31.1.1.1.12"
PARSER=sp_parse_zyportbytes
 
[PORTMULTRX]
NAME="Multicast RX"
OIDS=".1.3.6.1.2.1.31.1.1.1.8"
PARSER=sp_parse_zyportbytes
 
[PORTBRODTX]
NAME="Broadcast TX"
OIDS=".1.3.6.1.2.1.31.1.1.1.13"
PARSER=sp_parse_zyportbytes
 
[PORTBRODRX]
NAME="Broadcast RX"
OIDS=".1.3.6.1.2.1.31.1.1.1.9"
PARSER=sp_parse_zyportbytes
 
[SFPWAVELENGTH]
NAME="SFP wave length"
OIDS=".1.3.6.1.4.1.14988.1.1.19.1.1.5"
DIV=100
UNITS="nm"
PARSER=sp_parse_division_units
 
[SFPTEMP]
NAME="SFP temperature"
OIDS=".1.3.6.1.4.1.14988.1.1.19.1.1.6"
UNITS="C"
PARSER=sp_parse_division_units
 
[SFPVOLTAGE]
NAME="SFP voltage"
OIDS=".1.3.6.1.4.1.14988.1.1.19.1.1.7"
DIV=1000
UNITS="V"
PARSER=sp_parse_division_units
 
[SFPCURRENT]
NAME="SFP current"
OIDS=".1.3.6.1.4.1.14988.1.1.19.1.1.8"
UNITS="mA"
PARSER=sp_parse_division_units
 
[POESTATUS]
NAME="POE status"
OIDS=".1.3.6.1.4.1.14988.1.1.15.1.1.3"
PARSER=sp_parse_mikrotik_poe
 
[POECURRENT]
NAME="POE current"
OIDS=".1.3.6.1.4.1.14988.1.1.15.1.1.5"
UNITS="mA"
PARSER=sp_parse_division_units
 
[POEPOWER]
NAME="POE power"
OIDS=".1.3.6.1.4.1.14988.1.1.15.1.1.6"
DIV=10
UNITS="W"
PARSER=sp_parse_division_units
 
[UPTIME]
NAME="Uptime"
SECTPOLLMODE="noncumulative"
OIDS=".1.3.6.1.2.1.1.3.0"
PARSER=sp_parse_raw_trim_tab
 
[SYSTEM VOLTAGE]
NAME="System voltage"
SECTPOLLMODE="noncumulative"
OIDS=".1.3.6.1.4.1.14988.1.1.3.8.0"
DIV=10
UNITS="V"
PARSER=sp_parse_division_units_noport
 
[SYSTEM TEMP]
NAME="System temperature"
SECTPOLLMODE="noncumulative"
OIDS=".1.3.6.1.4.1.14988.1.1.3.10.0"
DIV=10
UNITS="C"
PARSER=sp_parse_division_units_noport
 
[SYSTEM VERSION]
NAME="System version"
SECTPOLLMODE="noncumulative"
OIDS=".1.3.6.1.2.1.1.1.0"
PARSER=sp_parse_raw_trim_tab

А если требуется делать еще и snmpset?

Начиная с релиза 0.8.4 появилась возможность в процессе опроса, делать устройствам snmp set. Для этого в каждой секции за исключением «define» добавлена возможность указать опцию SETOIDS в формате:

SETOIDS="oid|type|value,oid|type|value"

Где oid является собственно oid-ом, value является значением которое будет установлено, а type указывает на тип и может принимать следующие значения:

  • i INTEGER
  • u INTEGER UNSIGNED
  • s STRING
  • x HEX STRING
  • d DECIMAL STRING
  • n NULLOBJ
  • o OBJID
  • t TIMETICKS
  • a IPADDRESS
  • b BITS

Следует также заметить, что секция с SETOIDS может быть самодостаточной и не требует указания других опций, таких как NAME, OIDS или скажем PARSER. В таком случае, она просто проведет по очереди все write операции и завершит свою работу. Вот пример указания port description для двух портов:

[portnames]
SETOIDS=".1.3.6.1.2.1.31.1.1.1.18.4|s|testport1,.1.3.6.1.2.1.31.1.1.1.18.5|s|testport2"

Хотя да, никто не запрещает быть ей при этом обычной интерактивной секцией и показывать в процессе своей работы какие-то результаты. Например как-то так:

[portnames]
SETOIDS=".1.3.6.1.2.1.31.1.1.1.18.4|s|testport1,.1.3.6.1.2.1.31.1.1.1.18.5|s|testport2"
NAME="Ports"
OIDS=".1.3.6.1.2.1.31.1.1.1.18.4,.1.3.6.1.2.1.31.1.1.1.18.5"
PARSER=sp_parse_raw

В таком случае, следует всегда помнить о том, что сначала всегда выполняются все snmp set операции, а потом уже производиться опрос и рендер указанных в опции OIDS данных.

[define]
PON_ONU_PORT_MAX=128

Если вы используете две технологии ПОН у себя в сети и вам нужно перекрыть глобальный обязательный параметр alter.ini PON_ONU_PORT_MAX - то добавьте этот параметр в SNMP шаблоны для OLT и у вас будет нормально отображаться статистика и другие параметры.

Генератор шаблонов

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

switchpoller.txt · Последние изменения: 2021/03/24 11:27 — nightfly