Перейти к содержимому
Калькуляторы

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

Всем привет,

 

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

 

Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

perl + telnet/snmp

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

perl + telnet/snmp

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

perl + telnet/snmp

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Изменено пользователем MiB

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

+1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.