софт для хранения конфигурации вланов на коммутаторах

[ichthyandr]

Всем привет,

 

вопрос такой - есть ли софт для хранения конфигурации вланов на коммутаторах? Мне нужно реализовать схему c-vlan/s-vlan. Когда клиентов тысячи c-vlan-ов соотвественно. Необходимо чтобы с коммутаторов доступа снимался конфиг, парсился и складывался в БД. При замене коммутатора из БД генерился бы конфиг вланов. Есть нечто подобное?

 

Спасибо.

[pppoetest]

perl + telnet/snmp

[ichthyandr]

perl + telnet/snmp

что perl + telnet/snmp? 3 банки пива и бутылка шампуня?

[StSphinx]

perl + telnet/snmp

что perl + telnet/snmp? 3 банки пива и бутылка шампуня?

 

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

[ichthyandr]

perl + telnet/snmp

что perl + telnet/snmp? 3 банки пива и бутылка шампуня?

 

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

это есть хреново, спасибо

[Sergeylo]

Можно обратить внимание на велосипед по имени NOC (nocproject.org), эту задачу решает. Правда, попутно решает оно ещё тыщщу задач, и вообще сверх-избыточно.

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

[BETEPAH]

http://www.kiwisyslog.com/products/kiwi-cattools/product-overview.aspx

[Abram]

У меня на PHP скрипт + MySQL база.

При заведении коммутатора выдаются номера c-vlan и складываются в базу, при замене - забираются оттуда же.

Выдирать их из коммутатора, как оказалось, совсем не нужно - нужно знать, куда что выдано ранее.

 

Да, вопрос решается банками пивно-шампунного коктейля.

[MiB]

у меня формула расчета диапазона вланов для определенного коммутатора в завивимоти от его положения относительно узла агрегации:

VLANID = 1500 + 500 * (Номер кольца на УА - 1) + 50 * (номер УД в кольце - 1) + номер порта.

и скрипт для SecureCRT на визуал басике.

нигде ничего не храню, конфигурация УД стандартизирована и не меняется.

конфигурации УА и выше собираются RANCID раз в сутки целиком.

Edited September 21, 2014 by MiB

[Night_Snake]

Либо самосбор, либо NOC. ИМХО.

Первое гибко, второе функционально - вопрос нужна ли вам она.

[terrible]

Может быть я конечно не в тему со своим велосипедом, но данная задача, как мне кажется, должна решаться на уровне биллинга, а именно:

 

Согласно БД биллинговой системы, биллинг должен иметь ТРЕБОВАНИЯ на tag/untag комутацию тех или иных вланов на портах тех или иных свичей.

Ну и далее, костыль, который проверяет соответствие конфигурации вланов на свичах и БД биллинговой системы.

 

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

 

Идея норм или я опять чушь несу?

[xcme]

Поддержу предыдущего оратора. Всегда должна быть точка отсчета, биллинг вполне подходит.

У меня что-то похожее, хоть и не для вланов. В БД хранится статус порта (абонентский, аплинк, даунлинк, вип, оборудование, сгоревший и т.д.). На основе этой инфы демон генерирует конфиг под конкретный свичик - добавляет/удаляет ACL, настраивает MVR, LBD и все такое.

[zi_rus]

Может быть я конечно не в тему со своим велосипедом, но данная задача, как мне кажется, должна решаться на уровне биллинга, а именно:

 

Согласно БД биллинговой системы, биллинг должен иметь ТРЕБОВАНИЯ на tag/untag комутацию тех или иных вланов на портах тех или иных свичей.

Ну и далее, костыль, который проверяет соответствие конфигурации вланов на свичах и БД биллинговой системы.

 

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

 

Идея норм или я опять чушь несу?

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

[Abram]

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

У кого-то он только деньги считает, у кого-то - портами управляет, заявками, конфигурациями оборудования и т.д.

[pppoetest]

У кого-то он только деньги считает, у кого-то - портами управляет, заявками, конфигурациями оборудования и т.д.

+1

[zi_rus]

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

У кого-то он только деньги считает, у кого-то - портами управляет, заявками, конфигурациями оборудования и т.д.

а кто-то строит сети на мыльницах, но это не значит что это правильно

[pppoetest]

Ну если оно самописное, то пуркуа па?

[ichthyandr]

Поддержу предыдущего оратора. Всегда должна быть точка отсчета, биллинг вполне подходит.

У меня что-то похожее, хоть и не для вланов. В БД хранится статус порта (абонентский, аплинк, даунлинк, вип, оборудование, сгоревший и т.д.). На основе этой инфы демон генерирует конфиг под конкретный свичик - добавляет/удаляет ACL, настраивает MVR, LBD и все такое.

не подходит, когда через сеть тянутся другие операторские вланы

[terrible]

Дык другой операторский влан это тот-же клиент со своими требованиями к этому влану, не?

[ichthyandr]

У меня на PHP скрипт + MySQL база.

При заведении коммутатора выдаются номера c-vlan и складываются в базу, при замене - забираются оттуда же.

Выдирать их из коммутатора, как оказалось, совсем не нужно - нужно знать, куда что выдано ранее.

 

Да, вопрос решается банками пивно-шампунного коктейля.

плохо что писать придется, мне конечно лень, и так писанины хватает. Лично я б мускуль не использовал бы, а взял например постгрес от 9.3 и выше - он умеет аля "nosql" json представления записывать, очень удобно из телнета длинковского конфиги вланов сливать

 

Дык другой операторский влан это тот-же клиент со своими требованиями к этому влану, не?

не, они разбросаны "хаотично" по сети, с биллингом никак не пеересекаются их их уже неск сотен

[Negator]

Мы конфиги храним, но пользуемся редко.

Обычно конфиг коммутатора генерируется на лету биллингом.