ichthyandr Опубликовано 19 сентября, 2014 · Жалоба Всем привет, вопрос такой - есть ли софт для хранения конфигурации вланов на коммутаторах? Мне нужно реализовать схему c-vlan/s-vlan. Когда клиентов тысячи c-vlan-ов соотвественно. Необходимо чтобы с коммутаторов доступа снимался конфиг, парсился и складывался в БД. При замене коммутатора из БД генерился бы конфиг вланов. Есть нечто подобное? Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 19 сентября, 2014 · Жалоба perl + telnet/snmp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 19 сентября, 2014 · Жалоба perl + telnet/snmp что perl + telnet/snmp? 3 банки пива и бутылка шампуня? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
StSphinx Опубликовано 19 сентября, 2014 · Жалоба perl + telnet/snmp что perl + telnet/snmp? 3 банки пива и бутылка шампуня? Вам намекнули, что готового решения нет и каждый пишет свой костыль. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 19 сентября, 2014 · Жалоба perl + telnet/snmp что perl + telnet/snmp? 3 банки пива и бутылка шампуня? Вам намекнули, что готового решения нет и каждый пишет свой костыль. это есть хреново, спасибо Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergeylo Опубликовано 19 сентября, 2014 · Жалоба Можно обратить внимание на велосипед по имени NOC (nocproject.org), эту задачу решает. Правда, попутно решает оно ещё тыщщу задач, и вообще сверх-избыточно. Про пиво-шампунь можно просто конкретизировать - да, сваять приблуду для аггрегации данных из конфигов займёт не более недели, если уйти с ушами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 19 сентября, 2014 · Жалоба http://www.kiwisyslog.com/products/kiwi-cattools/product-overview.aspx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 19 сентября, 2014 · Жалоба У меня на PHP скрипт + MySQL база. При заведении коммутатора выдаются номера c-vlan и складываются в базу, при замене - забираются оттуда же. Выдирать их из коммутатора, как оказалось, совсем не нужно - нужно знать, куда что выдано ранее. Да, вопрос решается банками пивно-шампунного коктейля. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MiB Опубликовано 21 сентября, 2014 (изменено) · Жалоба у меня формула расчета диапазона вланов для определенного коммутатора в завивимоти от его положения относительно узла агрегации: VLANID = 1500 + 500 * (Номер кольца на УА - 1) + 50 * (номер УД в кольце - 1) + номер порта. и скрипт для SecureCRT на визуал басике. нигде ничего не храню, конфигурация УД стандартизирована и не меняется. конфигурации УА и выше собираются RANCID раз в сутки целиком. Изменено 21 сентября, 2014 пользователем MiB Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Night_Snake Опубликовано 23 сентября, 2014 · Жалоба Либо самосбор, либо NOC. ИМХО. Первое гибко, второе функционально - вопрос нужна ли вам она. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 23 сентября, 2014 · Жалоба Может быть я конечно не в тему со своим велосипедом, но данная задача, как мне кажется, должна решаться на уровне биллинга, а именно: Согласно БД биллинговой системы, биллинг должен иметь ТРЕБОВАНИЯ на tag/untag комутацию тех или иных вланов на портах тех или иных свичей. Ну и далее, костыль, который проверяет соответствие конфигурации вланов на свичах и БД биллинговой системы. Сбор конфигов свичей без проверки соответствия этих конфигов требованиям биллинговой системы считаю слишком поверхностным решением задачи замены комутаторов. Идея норм или я опять чушь несу? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 23 сентября, 2014 · Жалоба Поддержу предыдущего оратора. Всегда должна быть точка отсчета, биллинг вполне подходит. У меня что-то похожее, хоть и не для вланов. В БД хранится статус порта (абонентский, аплинк, даунлинк, вип, оборудование, сгоревший и т.д.). На основе этой инфы демон генерирует конфиг под конкретный свичик - добавляет/удаляет ACL, настраивает MVR, LBD и все такое. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 23 сентября, 2014 · Жалоба Может быть я конечно не в тему со своим велосипедом, но данная задача, как мне кажется, должна решаться на уровне биллинга, а именно: Согласно БД биллинговой системы, биллинг должен иметь ТРЕБОВАНИЯ на tag/untag комутацию тех или иных вланов на портах тех или иных свичей. Ну и далее, костыль, который проверяет соответствие конфигурации вланов на свичах и БД биллинговой системы. Сбор конфигов свичей без проверки соответствия этих конфигов требованиям биллинговой системы считаю слишком поверхностным решением задачи замены комутаторов. Идея норм или я опять чушь несу? как мне кажется, биллингу все это должно быть до балды. у него есть связка клиент и влан. а дальше взаимодействие с внешней системой, которая или сообщает биллингу новый влан или следит чтобы у клиента был правильный влан. встраивать в биллинг эту внешнюю систему избыточно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 23 сентября, 2014 · Жалоба Здесь просто нужно решить - где начинается и где заканчивается биллинг. У кого-то он только деньги считает, у кого-то - портами управляет, заявками, конфигурациями оборудования и т.д. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 24 сентября, 2014 · Жалоба У кого-то он только деньги считает, у кого-то - портами управляет, заявками, конфигурациями оборудования и т.д. +1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 24 сентября, 2014 · Жалоба Здесь просто нужно решить - где начинается и где заканчивается биллинг. У кого-то он только деньги считает, у кого-то - портами управляет, заявками, конфигурациями оборудования и т.д. а кто-то строит сети на мыльницах, но это не значит что это правильно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 24 сентября, 2014 · Жалоба Ну если оно самописное, то пуркуа па? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 24 сентября, 2014 · Жалоба Поддержу предыдущего оратора. Всегда должна быть точка отсчета, биллинг вполне подходит. У меня что-то похожее, хоть и не для вланов. В БД хранится статус порта (абонентский, аплинк, даунлинк, вип, оборудование, сгоревший и т.д.). На основе этой инфы демон генерирует конфиг под конкретный свичик - добавляет/удаляет ACL, настраивает MVR, LBD и все такое. не подходит, когда через сеть тянутся другие операторские вланы Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 24 сентября, 2014 · Жалоба Дык другой операторский влан это тот-же клиент со своими требованиями к этому влану, не? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 24 сентября, 2014 · Жалоба У меня на PHP скрипт + MySQL база. При заведении коммутатора выдаются номера c-vlan и складываются в базу, при замене - забираются оттуда же. Выдирать их из коммутатора, как оказалось, совсем не нужно - нужно знать, куда что выдано ранее. Да, вопрос решается банками пивно-шампунного коктейля. плохо что писать придется, мне конечно лень, и так писанины хватает. Лично я б мускуль не использовал бы, а взял например постгрес от 9.3 и выше - он умеет аля "nosql" json представления записывать, очень удобно из телнета длинковского конфиги вланов сливать Дык другой операторский влан это тот-же клиент со своими требованиями к этому влану, не? не, они разбросаны "хаотично" по сети, с биллингом никак не пеересекаются их их уже неск сотен Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 24 сентября, 2014 · Жалоба Мы конфиги храним, но пользуемся редко. Обычно конфиг коммутатора генерируется на лету биллингом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...