====== Опитування світчів за допомогою 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
{{ :swmodeladdsnmp.png? |}}
Після чого слід додати пристрій із потрібною моделькою і зазначеним SNMP ком'юніті, а також підрядком SWPOLL в описі, який сигналізує Ubilling про те, що для цього пристрою слід застосувати стандартні механізми опитування щодо обраного шаблону.
{{ :switchsnmpadd.png? |}}
Якщо все додано правильно - у світча в колонці дії має з'явитися іконка "Опитування за допомогою SNMP"
{{ :switchsnmpactions.png? |}}
Набір параметрів, що запитуються з пристрою, повністю залежить від обраного шаблону і може бути практично довільним. Також можливе відображення FDB з пристрою.
{{:swpolln0.png?200 |}}
{{:swithcsnmpdatadisplay.png?200 |}}
{{:foxgatesnmpmonitored.png?200 |}}
Враховуючи, що опитування пристрою відбувається не надто швидко, для прискорення відображення результатів використовується механіка кешування. Для періодичного опитування всіх пристроїв, з метою заповнення кешу сирих даних слід використовувати виклик **swpoll** з [[remoteapi|API віддаленого виклику процедур]].\\
====== Формат шаблону для опитування пристрою ======
Шаблони всіх пристроїв лежать у **/config/snmptemplates/** і мають, наприклад, якийсь такий вигляд:
[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:
[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
Якщо ви використовуєте дві технології ПОН у себе в мережі і вам потрібно перекрити глобальний обов'язковий параметр [[alteriniconf|alter.ini]] PON_ONU_PORT_MAX - то додайте цей параметр у SNMP-шаблони для OLT, і у вас буде нормально відображатися статистика та інші параметри.
====== Генератор шаблонів ======
Також камрад [[http://local.com.ua/forum/user/16245-demonidze/|DemonidZe]] запилив [[http://swgen.ubilling.net.ua/|генератор шаблонів опитування обладнання]], для тих, кому ліньки самому розбиратися.