[ShyLion]

Крайняя прошивка на сиське из ветки 15.4(3)S6a

 

[root@net-mon-01 /usr/home/lion]# snmpbulkget -Cr100 10.0.6.24 .1.0.8802.1.1.2.1.3.7.1.2
.1.0.8802.1.1.2.1.3.7.1.2.1 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.2 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.3 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.4 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.5 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.6 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.1 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.2 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.3 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.4 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.5 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.6 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.1 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.2 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.3 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.4 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.5 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.6 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.1 = INTEGER: interfaceName(5)
.1.0.8802.1.1.2.1.3.7.1.2.2 = INTEGER: interfaceName(5)
и так далее по кругу...

 

Включишь контроль последовательности - сраный BDCOM выдает таблицы не сортированые.

Все вендоры, с которыми работал, имеют те или иные проблемы с SNMP.

 

Это не вопрос был, а пятиминутка ненависти.

[dr Tr0jan]

У Хуавея вообще нельзя использовать камьюнити public и private. Камьюнити обязательно должно быть буквенно-циферным.

[ShyLion]

Добавил в своего опрашивателя проверку циклов.

[Alex/AT]

Присоединяюсь к пятиминутке. Сам SNMP архитектурно, конечно, редкостное убожество.

Увы, вменяемой альтернативы (чего-нибудь типа агента key-value, где key таки текстовые и в виде путей с возможными выборками типа /interfaces/*/counters) ни у кого нет.

А уж подобие SQL было бы вообще манной небесной.

 

SELECT ig.interfaceName, ig.lineCardNumber, id.portNumber, ig.runningState, ic.trafficIn, ic.trafficOut FROM interfaces.general ig INNER JOIN interfaces.counters ic ON (ig.id = ic.id) WHERE (ig.type = 'physical') AND (ig.interfaceName LIKE 'Gigabit%') AND (ig.adminState <> 'shutdown')

 

SELECT ps.powerSupplyName, ps.slotNumber, ps.unitNumber, ps.currentPowerAmps, cp.maxPowerAmps FROM hardware.powerSupplies ps

 

Мечты, мечты...

 

И ведь железо по производительности такие финты давно позволяет делать. Даже эмбедовка. Ээээх. А пользоваться приходится древнющим тормозным монструозным ASN.1-based.

[NiTr0]

Включишь контроль последовательности - сраный BDCOM выдает таблицы не сортированые.

bulkwalk юзайте или скармливайте набор параметров, которые хотите получить (второе правильнее).

 

Сам SNMP архитектурно, конечно, редкостное убожество.

архитектура вполне себе ок, для тех девайсов под которые он разрабатывался. в сотню байт RAM и пару килобайт кода без особого напряга влазит v1, и скорее всего даже v2.

 

то, что нормально много кто не осилил спеки почитать (+ сами спеки нормальные найти проблематично) - это да...

 

ну и отдельных лучей поноса заслуживает AFAIK безальтернативный net-snmp демон. разжирел до невозможности, и при >1k интерфейсов безбожно тупит.

[uxcr]

У Хуавея вообще нельзя использовать камьюнити public и private. Камьюнити обязательно должно быть буквенно-циферным.

undo snmp community complexity-check

Как-то так.

[sol]

Увы, вменяемой альтернативы (чего-нибудь типа агента key-value, где key таки текстовые и в виде путей с возможными выборками типа /interfaces/*/counters) ни у кого нет.

А это и есть SNMP... Только текстовые поля заменены на индексы из словаря. И словарь этот находится на опрашивающей стороне. Называется MIB... Чем это принципиально лучше/хуже, чем текстовые key я не понимаю. Разве что маски и регэкспы нельзя использовать. Но, со времён v2 запросы кучей стали дёшевы и проще спросить больше, чем надо и выкинуть лишнее, чем реализовывать регэкспы на стороне железки.

 

А уж подобие SQL было бы вообще манной небесной.

 

SELECT ig.interfaceName, ig.lineCardNumber, id.portNumber, ig.runningState, ic.trafficIn, ic.trafficOut FROM interfaces.general ig INNER JOIN interfaces.counters ic ON (ig.id = ic.id) WHERE (ig.type = 'physical') AND (ig.interfaceName LIKE 'Gigabit%') AND (ig.adminState <> 'shutdown')

 

SELECT ps.powerSupplyName, ps.slotNumber, ps.unitNumber, ps.currentPowerAmps, cp.maxPowerAmps FROM hardware.powerSupplies ps

Те же йяйтса. Только вместо регэкспов арифметика больше/меньше стайл. И также решается избытком запросов (копеечных) и сортировкой на опрашивающей стороне.

 

Иначе, дело пахнет ксеонами в свичках.

[GrandPr1de]

Иначе, дело пахнет ксеонами в свичках

зато удобно :D

[ShyLion]

Включишь контроль последовательности - сраный BDCOM выдает таблицы не сортированые.

bulkwalk юзайте или скармливайте набор параметров, которые хотите получить (второе правильнее).

Что? Я пример в самом начале привел. Какой такой "набор параметров", когда я таблицу получаю?

[dmvy]

Бывают вендоры корявые. Нормальные вендоры SNMP поддерживают и при необходимости подправляют (D-Link и Eltex нормально принимают багрепорты и исправляют). https://habrahabr.ru/post/206612/

[vurd]

Кстати более глючного снмп чем на гепоне элтекса не видел. Вот там ад и израиль, тормоза, неустановка значений после сета...

[GrandPr1de]

Ну не глючность скорее, а странность.

ЗТЕ шасси с220\с300\с320, вот где АДъ и израиль.

Если просто надо достать данные, то всё довольно просто. А вот сет пипец какой неоднозначный. Что б сменить влан нужно сеты отправлять строгой очередности. И при том одним пакетом по несколько штук оидов за раз.

[Alex/AT]

Увы, вменяемой альтернативы (чего-нибудь типа агента key-value, где key таки текстовые и в виде путей с возможными выборками типа /interfaces/*/counters) ни у кого нет.

А это и есть SNMP... Только текстовые поля заменены на индексы из словаря. И словарь этот находится на опрашивающей стороне. Называется MIB... Чем это принципиально лучше/хуже, чем текстовые key я не понимаю. Разве что маски и регэкспы нельзя использовать. Но, со времён v2 запросы кучей стали дёшевы и проще спросить больше, чем надо и выкинуть лишнее, чем реализовывать регэкспы на стороне железки.

 

Иначе, дело пахнет ксеонами в свичках.

Неа. SNMP это /path/*, а не /path/*/path например. Ну и какие ксеоны если копеечный pi1 допустим вполне тянет полноценный mysql. А тут вообще речь об упрощенном диалекте и инмемори. Но что имеем то имеем, жрем кактус. Про балк отдельная тема, там тоже не все гладко - многие агенты (вся циска например) оптимизировать их внутри в балк не умеют, и все равно выгребают по 1 итему за заход. Т.е. нагрузка на цпу железки единофигственна и тормоза те же, только запрос-ответ типа оптом.

 

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

[Alex/AT]

ну и отдельных лучей поноса заслуживает AFAIK безальтернативный net-snmp демон. разжирел до невозможности, и при >1k интерфейсов безбожно тупит.

Потому что идеология - 1 итем за заход. А чтобы было шустрее - надо кешировать, а кеша нету да и лейтенси. Я для нетснмп делал прослойку в мемкачед из за этого.

[NiTr0]

Я пример в самом начале привел

вы юзали bulkget. а не bulkwalk.

 

Какой такой "набор параметров", когда я таблицу получаю?

набор OID'ов которые надо получить. списком. а не "получить все".

 

Потому что идеология - 1 итем за заход. А чтобы было шустрее - надо кешировать, а кеша нету да и лейтенси.

там вроде не только в этом дело. 10-40% процессорного времени постоянно отожрано при 1к интерфейсов (причем - system) - как по мне бред. ушел на заббикс агент, все стало ок.

[Saab95]

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

 

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

[ShyLion]

Я пример в самом начале привел

вы юзали bulkget. а не bulkwalk.

 

snmpbulkwalk это такая команда из известного набора утилит. В протоколе метод GetBulkRequest, которые использут как snmpbulkwalk, так и моя, написаная на С утилита.

 

Какой такой "набор параметров", когда я таблицу получаю?

набор OID'ов которые надо получить. списком. а не "получить все".

В курсе, что в дереве MIB бывают таблицы? Таблица интерфейсов например?

Что далеко не всегда можно заранее знать количество и ifIndex всех имеющихся интерфейсов?

Также надеюсь очевидно, что агент не должен выдавать на getBulkRequest повторяющиеся циклично OIDы?

 

SNMP устаревшая технология

...

[Tau]

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

Можете привести пример?

[ShyLion]

Блин, у истории продолжение - агент зацикливается на встроенных шести интерфейсах и дополнительные просто не отдает.

[CNick]

Иначе, дело пахнет ксеонами в свичках.

Так уже давно ксеоны и прочие коры с гигабайтами ram, SSD и линуксом :)

[edo]

CNick, ну не во всех пока ;)

[NiTr0]

В курсе, что в дереве MIB бывают таблицы? Таблица интерфейсов например?

и чо?

 

Что далеко не всегда можно заранее знать количество и ifIndex всех имеющихся интерфейсов?

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

[Alex/AT]

практически всегда. ну как минимум

Ну как минимум сопоставить индекс интерфейса с dot3 индексом - та ещё благодать. Join'ов в SNMP не придумано, выборок по одному из полей таблицы - тоже.

При этом в пределах одного вендора разные железки могут не поддерживать половину вроде бы очевидных и необходимых счётчиков, или расположить их в совершенно другом дереве.

Вот в точно том же формате, но в другом дереве - особенно D-Link этим болеет. А выборок вида .1.2.3.4.5.<any>.1.2.3.1.1 - нет.

Если проще - древнющее гуано мамонта, которым, увы, приходится пользоваться. Никто ж тогда ещё не думал, что в него сотни взаимосвязанных параметров запихиваться будут. Не говоря уже о тысячах.

MIB'ы тоже... имеют читабельность, сходную с читабельностью наскальных иероглифических рисунков эпохи тех самых мамонтов.

[sol]

Ну так расположение одних и тех-же параметров в разных ветвях дерева не есть проблема протокола. Это проблема альтернативно одарённого вендора, а не SNMP.

 

А MIBы, их вообще "читать" не надо. Есть MIB браузер, им и смотрте.

[vurd]

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

 

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

 

Пробовал использовать API. Неудачно, документации почти нет, стандарт свой, библиотек нет. То что есть не работает с ходу. Спасибо, не надо.