BiTel

Вообщем вопрос в следующем.
Планируемая реализация.

Интернет — Шлюз (на базе FreeBSD) — Свич 3 уровня — Свич 3 уровня (уровень агрегации района) — Свич 2 уровня (уровень агрегации квартала) — Свич 2 уровня (домовой узел доступа) — Клиент

Вопрос в том как реализовать на этом биллинге лучше. Какие настройки оборудования более подходят и каким образом будет идти управление сетью?

Домовой узел. Обеспечивает управлением VLANов на уровне портов. В обычной ситуации все клиенты в общедомовом VLANе (на каждый дом или группу домов свой), в случае блокировки клиента по недостатку средств или в иных случаях он попадает в отдельный VLAN из которого он не видит других клиентов и в котором ему доступна только страница статистики.

На сколько я понимаю на уровне агрегации квартала самое главное что бы оборудование было прозрачное для всех VLANов, главное большое количество SFP портов.

На уровне агрегации района управлять принимаемыми VLANами, маршрутизировать подсети с кварталов.

На уровне узла сети — принимать все VLANы с узла агрегации района и маршрутизировать районы между собой и пиринг.

Или есть еще такой вариант в котором используется PON по принципу оптика до дома (не до клиента) то в этом случае отпадает необходимость в уровне агрегации квартала.
В этом случае на одном волокне сможет сидеть порядка 20-30 домов а PON будет приходить на дом и разводиться по меди свичем второго уровня.

Вообщем как это реализовано в биллинге по работе с оборудованием.

Предпологаемое оборудование D-Link DGS-3627G, D-Link DES-3526, ZyXEL ES-2024A, ZyXEL GS-3012F, ZyXEL GS-4012F, ZyXEL ES-2008, PON оборудование от www.gdc.ru с 8,16,24 100 Мбит/с портами на абонентских устройствах.

Вообще не могли бы описать какова рекомендуемая схема настройки биллинга. Использование модуля IPN или использовать PPPoE или есть еще какой то способ реализации? Вообщем каждый биллинг имеет свои положительные стороны и хотелось бы знать какова схема работы именно этого биллинга?

Да планируется внутренних IP для клиентов не использовать. Все клиенты на внешних. NAT не используется

Если Вы дружите с явой и Вас не пугает написание/правка скриптов под разношерстное оборудование, то никаких проблем нет БГБ будет прекрасно управлять железом уровня доступа, НО! Вам понадобится нечто (цискороутер, цискосвич, РС-юк, ХЗ) что сможет отдавать Вам данные посредством netflow, т.к., IMO, использовать sFlow, а только он есть в DGS-ах, для биллинга (читай - учета трафика) - в Росии пока что не стоит ...


IMHO нет никакой рекомендуемой схемы настройки - Вы просто настраиваете биллинг под Ваши задачи ... Если Вы хотите использовать простой роутинг - Вам нужен модуль IPN, если Вы хотите использовать туннелирование (РРРоЕ, РРТР, L2TP) - Вам нужен модуль dialup ... тут только Вам решать как именно Вы будете осуществлять доступ в инет/локалку/ХЗ и из этого и исходить

БГБ не работает с sFlow?

Вообщем примерная схема получается такой




Авторизация пользователей через opt82 на порту оборудования. Тарифов по трафику как таковых не планируется. Внутрисетевой трафик не считается, может использоваться только для просмотра нагрузки на внутренние каналы. Ну соответственно и интернетовский траф как таковой нужен только для обсчета нагрузки на канал.
Если есть какие то замечания или советы то готов их принять.

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

работает! просто сам протокол sFlow не совсем точно считает, в отличие от netflow, но т.к.то Вас это не должно беспокоить


я бы не советовал ... почему? а если в доме 2 компьютера? а если 3? тянуть каждому кабель? если да, то Вы сами себе удорожаете сеть, т.к. на любой железке строго ограниченное кол-во портов и каждый из них стоит денег (цена порта ~= цена железки / кол-во портов) ... если же говорить об установке роутера, то тогда как считать каждый РС в отдельности? поверьте, раздельный учет компьютеров в квартире - это не миф, лично мне (точнее моему биллингу) приходится это делать прямо сейчас ... например когда квартиру снимает группа студентов или теща хочет чтобы зять сам платил за свой инет (ну или наоборот )


SNMP в лице MRTG или Cacti (при большом кол-ве объектов мониторинга кактус, IMHO, удобнее) гораздо лучше подойдет для учета нагрузки и на каналы и на само железо (графики загрузки CPU, памяти и т.д. и т.п.)


какие могут быть замечания к столь правильной схеме постоения сети? разве что на схеме не видно закольцованности, для обеспечения отказоустойчивости, но это тема для отдельного разговора и точно вне рамок тематики этого форума
а вот насчет того как предоставлять услуги и соответственно какие модули использовать - тут надо смотреть что именно Вы хотите и как вам будет удобнее ...

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



Нормальной и удобной утилиты яувы не видел. Кактус все хорошо НО! очень не удобен в заполнении. Там просто все через одно место сделано. Кстати это как информация к размышлению по поводу улучшения биллинга.



Вот в том то и дело что я привел используемое оборудование, и прицип построения сети и хотел бы увидить какие то примеры настройки и советы по настройке оборудования.

Вот вы нарисовали схему ..теперь привидите примеры команд на
-открытие клиента
-закрытие клиента
и на каких шлюзах вы хотите это производить ?
если управлять то только роутером(freebsd + ipfw) , то можно использовать manad - им будет управлять биллинг, а настрйока всей остальной сети - это ваша забота . Если вы хотите автоматизировать еще как-то управление шлюзами, то напишите какие шлюзы и как ..как бы вы это делали если бы вам вручную пришлось прописывать все команды

а я об этом и не говорил, да и из схемы понятно что его не будет ...


я не думаю что разработчики будут делать в БГБ мониторинг, т.к. не дело биллинга мониторить железки, его дело деньги считать ...


примеры и советы по настройке тут смогут дать только в отношении БГБ, а что касается железа, то, IMHO, ситуация такая - если кто либо из форумчан использует железо аналогичное Вашему - он поделится своими знаниями и опытом, если таковых не найдется - то увы, но настраивать все придется Вам самостоятельно ... взять меня - я могу помочь с настройкой DGS-3627G, а в остальном - только посоветовать как настроить железо, но готовых конфигов я дать не смогу, т.к. у меня банально нет зухелей

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

Вы не правы, IMHO, т.к. биллинг считает деньги пользователей и наличие в нем средств общения с пользователями таких как CPM и Хелпдеск - это насущная необходимость ...


не скажите ... иногда, в довольно редких случаях, надо просто банально посчитать трафик сертифицированной программой, а иногда надо программно-аппаратный комплекс с фичей "сбегать за пивом" (кстати, как тут скриптами это устроить?)