Користувальницькькі налаштування

Налаштування сайту


Сайдбар

Розділи

Загальний опис
Історія змін
Рекомендації до оновлення
Плани на майбутнє
Відомі проблеми
Онлайн демо
Відео
Допомога проекту
Люди
Трохи про безпеку

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
  • D-Link DES-1210-26
  • D-Link DES-1210-28
  • D-Link DGS-1210-10
  • D-Link DGS-1210-12TS
  • D-Link DGS-3000-28SC
  • D-Link DGS-3627G
  • HP ProCurve Switch 2626
  • HP ProCurve Switch 2650
  • HP ProCurve Switch 2524
  • HP ProCurve Switch 2824
  • Dell PowerConnect 5324
  • Dell EMC Networking N1148T-ON
  • 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
  • Mikrotik-CSS326-24G-2S

І багато-багато інших, про які ми вже задовбалися писати. Давайте ви самі подивитеся що буде працювати з коробки заглянувши в директорію 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
  • sp_parse_division_temperature - універсальний градусник з розподілом значень на DIV і форматом шкали у вигляді UNITS=“min|max|yellow|red”

Також доступні наступні режими 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 · Востаннє змінено: 2023/06/19 09:29 повз borisov