Jump to content
Калькуляторы

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

Всем привет,

 

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

 

Спасибо.

Share this post


Link to post
Share on other sites

perl + telnet/snmp

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

Share this post


Link to post
Share on other sites

perl + telnet/snmp

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

 

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

Share this post


Link to post
Share on other sites

perl + telnet/snmp

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Edited by MiB

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

+1

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this