[terrible]

1) найти описание на telnet-команды гораздо легче, чем snmp mib'ы,

т.е. работающий результат получается намного быстрее ("вам шашечки или ехать?"),

Просто вам лениво это искать и делать всё на SNMP

 

3) управление по snmp требует предварительной настройки коммутаторов,

а routers_mgmt разрабатывалась так, чтобы не требовать от существующей сети

никаких предварительных переделок.

Хана такой сети, если везде и всюду используется private/public

И что вы называете предварительной настройкой? прописать 1 нужный comm-string + trusted-subnet? Не считаю это проблемой, даже если в сети несколько тысяч свичей.

[Ilya Evseev]

> Просто вам лениво это искать и делать всё на SNMP

 

Любой каприз за ваши деньги.

 

> Хана такой сети

 

Спасибо. Вашими молитвами.

 

> Не считаю это проблемой

 

Ну раз вы так не считаете, тогда конечно.

[troyand]

Managing Cisco programatically; Telnet vs SNMP?

То есть, если для вытягивания информации из железа програмным способом SNMP подойдет практически в любом случае, то для конфигурирувания его не всегда достаточно, и приходится делать велосипеды с Telnet/Expect и аналогами. Однако последний вариант может таить за собой немало подводных камней: так я сравнительно долго вылавливал баг в expect'овом скрипте: при конфигурирувании вводилась строка со знаком "#", этот же символ ловился как признак введеной строки. Также часто может действовать правило: "Если у вас есть проблема, и вы решаете ее с помощью регекспов, то у вас появляется вторая проблема".

Единственное, что могу посоветовать, это писать высокоуровневый код с помощью соответсвующих SNMP-библиотек. Так, для Python, мне больше всего импонирует snimpy, уверен для других языков есть аналоги.

[Ilya Evseev]

По просьбам трудящихся выкладываю несколько примеров:

1) просмотра информации об управляемом коммутаторе - http://svn1.homelinux.net/viewcvs/*checkou...ot=routers_mgmt

2) просмотр информации об IP-адресе: http://svn1.homelinux.net/viewcvs/*checkou...ot=routers_mgmt

3) о MAC-адресе: http://svn1.homelinux.net/viewcvs/*checkou...ot=routers_mgmt

4) порт устройства: http://svn1.homelinux.net/viewcvs/*checkou...ot=routers_mgmt

 

Все данные читаются из базы.

В базу они попадают во время сканирований сети.

Сканирование производится утилитой routers_mgmt/scripts/update_bindings

 

P.S. Ссылка на таблицу стилей из примеров вырезана, поэтому для лучшей читабельности

рекомендуется нажать Ctrl-"-" и смотреть в 90% масштабе :)

[xcme]

Просто вам лениво это искать и делать всё на SNMP

В том то и дело, что ВСЁ на snmp сделать нельзя. Вот, например, что нельзя сделать на snmp в случае с длинковскими железками:

1. Нельзя управлять параметрами snmp по snmp по дефолту - в телнет залезть таки придется. (хотя здесь как вариант - влить конф файл по snmp =)

2. Нельзя управлять учетными записями.

3. На 3028 (на других моделях не знаю) нельзя обновить (равно как и узнать) bootprom

4. В ряде случаев, телнет-команды могут быть одинаковыми, а вот OID - разными (управление портами 3028 и 3028G, например)

5. Новый функционал сначала разрабатывается для CLI и уже потом для SNMP

6. MIB'ы для новых фич надо спрашивать у саппорта, которые, в свою очередь, запрашивают их у ШК =), в то время, как в случае с CLI можно просто посмотреть хэлп

7. Не всегда корректно работает вывод (лечится новыми прошивками), например коммутатор может вернуть данные в Hex, а может в String - как ему захочется.

8. Иногда требуется разом задать несколько параметров. В случае net-snmp проблем нет, а та же php'шная snmpset - не умеет. Приходится приспосабливаться.

 

Соглашусь с troyand в том, что SNMP замечательно подходит для мониторинга, но не всегда для управления.

 

У телнет-варианта наоборот, бОльшие сложности как раз с мониторингом - необходимость парсинга и необходимость подстраиваться под регулярно меняющиеся форматы вывода данных в CLI. Так что, имхо, все должно упираться не в идеологию, а в конкретные задачи.

 

P.S. Ссылка на таблицу стилей из примеров вырезана, поэтому для лучшей читабельности

рекомендуется нажать Ctrl-"-" и смотреть в 90% масштабе :)

Сама система - бесплатна, а css-ка - только за деньги? :)

[terrible]

8. Иногда требуется разом задать несколько параметров. В случае net-snmp проблем нет, а та же php'шная snmpset - не умеет. Приходится приспосабливаться.

я в этих случаях пользуюсь exec, там хоть 20 параметров задавай. Актуально для создания ACL, в частности ip профилей и PCF.

[Dyr]

Что за exec?

[Ilya Evseev]

Что за exec?

Ищем в Гугле (хотя здесь и без него всё ясно): "php exec"

Находим:

http://php.net/manual/en/function.exec.php

"exec — Execute an external program"

 

Утилиты net-snmp вызываются из скриптового языка вместо встроенных функций.

Точно такой же подход используется в routers_mgmt.

[Dyr]

А, я не догадался о связи exec с php.

 

[Blood Win]

Вставлю свои пять копеек в холивар :)

 

ИМХО, по SNMP следует брать все, что можно взять по СТАНДАРТНЫМ OID-ам. Все, что требует проприетарных OID-ов - фтопку, ибо телнет-команды внутри одного вендора в большинстве случаев для разных моделей совпадают, в то время как проприетарные OID-ы - нет, в 99% случаев.

 

Так что все что можно считать по стандартным OID - считывает по SNMP, все остальное делается по Telnet.

[Dyr]

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

Я и ты знаем одного вендора, у которого разные команды не просто для разных моделей, а даже для разных прошивок, не правда ли? ;)

Особенно порадовала команда "copy cfg_toTFTP <ipaddr> <filename>", которая после обновления прошивки превратилась в "copy cfg_toTFTP <ipaddr> src_file <filename>".

К слову, у цисок тоже хватает проприетарных OID'ов...

Изменено 4 марта, 2010 пользователем Dyr

[terrible]

по стандартным OID вообще мало что можно получить от железки

[xcme]

Думаю, для более активного обсуждения в эту тему надо добавить еще фоток Blood Win =)

[Dyr]

И удалить текст, мешающий рассматривать фотки, да? ;)

[Blood Win]

Я и ты знаем одного вендора, у которого разные команды не просто для разных моделей, а даже для разных прошивок, не правда ли? ;)

Особенно порадовала команда "copy cfg_toTFTP <ipaddr> <filename>", которая после обновления прошивки превратилась в "copy cfg_toTFTP <ipaddr> src_file <filename>".

К слову, у цисок тоже хватает проприетарных OID'ов...

На самом деле все не так плохо :) Show vlan - оно на всех коммутаторах отрабатывает. А вот OID для каждой железки будет уже разный.

 

Впрочем для каждой задачи нужно рассматривать возможности отдельно.

Я лично все чтение стараюсь делать по SNMP, запись - пока только telnet.

[s.lobanov]

Я и ты знаем одного вендора, у которого разные команды не просто для разных моделей, а даже для разных прошивок, не правда ли? ;)

Особенно порадовала команда "copy cfg_toTFTP <ipaddr> <filename>", которая после обновления прошивки превратилась в "copy cfg_toTFTP <ipaddr> src_file <filename>".

К слову, у цисок тоже хватает проприетарных OID'ов...

На самом деле все не так плохо :) Show vlan - оно на всех коммутаторах отрабатывает. А вот OID для каждой железки будет уже разный.

Ну и какой смысл от того, что sh vlan есть много где? Всё равно вывод команды везде разный, например на циске 4 колонки, на edge-core 2 и т.д., поэтому всё равно парсить вывод надо каждый раз по разному и получается что от того, что это команда называется одинаково на разных железках нет особо пользы с точки зрения автоматизации обработки этих данных.

 

А вот посмотреть какие порты в каких вланах по SNMP оказывается проще, тут 2 основных вариантах - циско и не циско, либо битовый массив вланы на порт, либо наоборот - какие порты включены в тот или иной влан. То, что OID'ы разные ничего страшного - заменил одну переменную в классе и все дела, за то все функции для разбора полученных данных одинаковые(которые, очевидно, нужно писать в классе-родителе) и не надо думать о том сколько колонок в выводе команды sh vlan и не придётся перестраиваться к новой прошивке, если где-нибудь точку заменят на запятую, SNMP намного более формализован, чем telnet, где вывод команд human-readable.

Изменено 5 марта, 2010 пользователем s.lobanov

[s.lobanov]

почему был выбран вариант с telnet ? SNMP же как-то прогрессивней

3) управление по snmp требует предварительной настройки коммутаторов,

а routers_mgmt разрабатывалась так, чтобы не требовать от существующей сети

никаких предварительных переделок.

Если есть список ip адресов и типов железок, то элементарно делается скрипт, который прописывает snmp-community(если v1/v2), акссес-листы и т.д. на всех доступных на текущий момент железках за 5 минут. Примерно так выглядет.

 

#!/bin/bash

(echo user;sleep 2;echo password;echo 3;echo en;sleep 2;echo "conf t";sleep 2;echo "snmp-server...";....;"copy run start";sleep 30;echo "quit";sleep 1) | telnet device1 2>&1 >log1 &
(echo user;sleep 2;echo password;echo 3;echo en;sleep 2;echo "conf t";sleep 2;echo "snmp-server...";....;"copy run start";sleep 30;echo "quit";sleep 1) | telnet device2 2>&1 >log2 &
(echo user;sleep 2;echo password;echo 3;echo en;sleep 2;echo "conf t";sleep 2;echo "snmp-server...";....;"copy run start";sleep 30;echo "quit";sleep 1) | telnet device3 2>&1 >log3 &
......
sleep 200

 

[Pretender]

А почему были опущены модели dgs 3100 от длинка, или они просто не встречались в работе?

[Ilya Evseev]

А почему были опущены модели dgs 3100 от длинка, или они просто не встречались в работе?

Встречались и поддерживаются.

Хотя лучше бы мы их не встречали - настолько у них своеобразный CLI.

[Pretender]

А почему были опущены модели dgs 3100 от длинка, или они просто не встречались в работе?

Встречались и поддерживаются.

Хотя лучше бы мы их не встречали - настолько у них своеобразный CLI.

странно, в README

Not supported:

D-Link 3226,3100

 

[Ilya Evseev]

А почему были опущены модели dgs 3100 от длинка, или они просто не встречались в работе?

Встречались и поддерживаются.

Хотя лучше бы мы их не встречали - настолько у них своеобразный CLI.

странно, в README

Not supported:

D-Link 3226,3100

README устарел. 3100 давно поддерживаются, 3226 - нет. Хотя если будет сильно надо,

то можно добавить поддержку и для них. Всё делать только по SNMP, без Telnet'a.

 

[Abram]

Вопрос к Илье.

Можно простенький HOWTO, что и где дописывать для поддержки новых моделей коммутаторов?

[Abram]

Так, насколько я понимаю, порядок приблизительно таков:

1) Добавить тип в Routers.pm.

2) Создать TPLink.Pm, реализовать необходимые ф-ции (а какие из них необходимые?).

[Ilya Evseev]

Так, насколько я понимаю, порядок приблизительно таков:

1) Добавить тип в Routers.pm.

2) Создать TPLink.Pm, реализовать необходимые ф-ции (а какие из них необходимые?).

Добавил описание процесса:

http://svn1.homelinux.net/viewcvs/docs/New...amp;view=markup

 

1) Создать модуль libs/TPLink.pm по мотивам модулей DLink.pm, Cisco.pm, EdgeCore.pm.

 

2) Перед созданием базы в network_devices.sql и libs/NetworkDevices.pm добавить 'TPLINK' после 'EDGECORE'.

Если база уже есть - дополнительно сделать "alter table network_devices change column typ ...".

 

3) В libs/AnyRouter.pm и scripts/add_dlink сделать для слов TPLink и TPLINK копии всех строк, содержащих слова EdgeCore и EDGECORE.

4) В подкаталоге scripts сделать "ln -s add_dlink add_tplink".

5) В libs/syncheck добавить "use TPLink;" и запускать его до тех пор, пока он не напишет "./syncheck syntax OK".

 

После того, как всё заработает, не помешает сделать...

svn add libs/TPLink.pm

svn diff > /tmp/routers_mgmt_tplink.patch

...и выслать нам с Анной Аркадьевной полученный файл.

[Abram]

Ilya Evseev,

Спасибо.

Пункты с 1 по 4 допёр сделать сам =). Назвал, правда, не TPLINK, а TPLWEB - у меня Web Smart, для Managed будет всё по-другому.

 

Насколько я понял, можно в кач-ве примера взять DLink.pm и вырезать все ф-ции, относящиеся к телнету - останутся только те, что надо реализовать?

 

Патч сделаю hg diff. Мне так привычнее.