BiTel

Сразу извиняюсь за неизбежное свое ламерство, но найти хорошего специалиста дорого и не просто, да и не в политике партии. Собираемся заняться некрупным провайдингом - до 2k абонентов на первом этапе. Точнее на первом этапе планируем подключить несколько сотен. Тарификация стандартно - по трафику/абонентка с возможностью снимать деньги за внутрисетевой трафик между районами (сегментами).

Посмотрев различные биллинги, остановился на бителовском. Поставил на тестовую машину с Ubuntu, потестил, разобрался с документацией. Тут особых вопросов пока не возникает. Планирую использовать модуль Dial-Up и NPay.

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

В данный момент мой тестовый стенд располагает:
- компьютер с Ubuntu 10.4 (для сервера(ов) планирую использовать Server Edition)
- свич 3-го уровня Extreme Summit 48si (SMNP, Radius, NetFlow, BGP)
- 2 свичa 2-го уровня 3Com 4400
- неуправляемые свичи и "абонентские" компьютеры при необходимости.

Примерно такое (это) же б/у-шное активное оборудование и планируем использовать. Если сильно поможет, можем взять и юзаное сиско.

Варианты организации:

1) Изначально я планировал подключать так:
Абонент -> Неуправляемый Свич [на него 1 VLAN] -> L2-Свич -> Центральный Узел [L3-Свич -> Сервер(а)] -> Интернет
Топология - звезда.
Непонятки начинаются с центральным узлом - можно ли из L3 сделать NAS и/или роутер и как его в этом случае стыковать с серверами. И ведь при данной конфигурации весь межсегментный трафик нужно будет пропускать через него. А с авторизацией PPPoE, как я понимаю, будет происходить два адресных преобразования - одно на сервере доступа, другое в интернет-роутере. Кстати, еще не решен вопрос белизны IP, из-за этого мне не понятно, где должны выделяться из пула, и можно ли внутрисетевые и внешние сделать одинаковыми для пользователя в случае белых при такой авторизации.

2)Умные люди посоветовали:
Ставить по NASу (и роутеру) после каждого свича L2, чтобы разгрузить центральный узел. В центральном узле, получается, останется только сервера биллинга (радиус, сам и прочие свистелки).
Звездовая в этом случае топология видимо уже не подразумевается.
Но я не думаю, что у нас будет такой большой межсегментный трафик. Предлагать планируется в первую очередь именно хороший интернет. Но теперь я не уверен в осуществимости или разумности первого варианта.

Как я сейчас понимаю, мне нужно:
1. как-то настроить сервер доступа (он же PPPoE-сервер)
2. скоммутировать его с сервером bg-радиуса
3. последний настроить под сервер биллинга (или наоборот)
4. подключить к NASу и настроить интернет-шлюз (железкой или какой-нибудь Quagga'ой).

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

Как человек, занимавшийся мониторингом и саппортом, скажу, что перед юзером должен стоять управляемый свитч. Тогда и диагностировать проще, и порт отключить можно, и флуд отслеживать. Port isolation, понятное дело... PPPoE intermediate agent .. и прочие няки

Cromeshnic
Да, это соблазнительно - контролировать подключение по физическому порту. Я рассматривал этот вариант.

Плюсы:
- простая настройка, даже очень простая, только правильно роутер настроить требуется.

Минусы:
- от 500 рублей затрат в расчете на одного пользователя, или б/у в большом количестве искать.
- лицензия на ipn дороже dialUp.
- чтобы избежать физического воровства трафика все же нужна какая-то авторизация (Вы про это сказали), а это, в принципе, сводит на нет простоту настройки.

Забыл сказать. Не смотря на запланированную VPN-авторизацию, я думаю привязать пользователя по IP и маку (может быть и если получится). Настройка айпишника у пользователя не большая обуза, если все равно настраивать VPN.

Я это написал без мысли о биллинге. У нас тоже массово используется pppoe, кое-где ipn. Но ipn рулится полностью на магистральном роутере - либо отключается интерфейс (если указан), либо добавляется роут в null.
Но перед клиентом все равно управляемые L2 коммутаторы - проще траблшутинг и мониторинг. Про погасить порт - я имел в виду руками, если нужно.

Так вы pptp хотите? Т.е. пользователи изначально в общей локалке должны быть?

Видимо да. В пределах одного порта L2-свича (районного) они и так в неконтролируемой общей локалке будут. А дальше, вдруг!, мне непонятно стало. Не хотелось бы гонять трафик в пределах одного районного свича через центральный узел.

Дело в том, что я невольно за референс беру своего, далеко не идеального, кстати, провайдера. У него вся сеть поделена на сегменты без ограничений скорости с бесплатным трафиком внутри, а каждый сегмент состоит из нескольких адресных пространств, и белый айпишник выставляется на карте абонента, плюс кастомная программа авторизации. ВПН у них тоже есть (подключить то на чем прога авторизации не запустится) - на неуправляемое канальное пространство назначено адресное типа 10.0.0.X.

Но я-то хочу всех через PPPoE авторизовывать. Да и возможности внутрисетевого обмена не интересуют сильно. Но если два абонента с одного районного свича торрентятся, то, чтобы трафик не ходил через центральный роутер, нужно ставить по районному роутеру. Самый дешевый вариант такого роутера, слабенький ПК или какой-нибудь Микротик, я все правильно понимаю?

если верить даташиту то там

т.е. с БГБ несовместимо


L3 свич умеет роутить пакеты из коробки, а вот сделать из него NAS не получится - не умеет оно этого


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


L3 свич пережует и даже не заметит - у него роутинг аппаратный, в этом его основное отличие от софтварных роутеров (цискороутеры в 99% случаев софтварные)


умные? скорее всего они Вам посоветовали использовать Ваш саммит как свич ядра сети, т.е. классическую схему:

т.е. ставить РРРоЕ сервер(а) на уровне агрегации, но на самом деле тут возникает вопрос - что делать с межсегментным трафиком? он то всеравно пойдет в ядро и тут не поможет установка РРРоЕ сервера(ов) вне ядра, т.к. РРРоЕ - протокол 2-го уровня, а Вашему свичу, чтобы его использовать как роутер между сегментами, надо видеть МАС-и юзеров, т.е. получается что РРРоЕ до него всеравно дойдет ... где тут разгрузка?


кто это Вам сказал?


схема

в аккурат попадает, повторюсь, в классическую схему:

только, как уже было сказано выше, на доступе лучше ставить не тупые мыльницы, а управляемые свичи, я бы рекомендовал D-Link DES-3526 и DES-3028 ... что подразумевается под "L2-Свич" я не знаю, но если это некий оптический агрегатор (надеюсь Вы не решили в районах свичи доступа с агрегацией медью соединять), то я бы посоветовал взять D-Link DGS-3100-24TG, т.к. дешевле агрегатора для оптики я не знаю ... в качестве РРРоЕ NAS/BRAS смело ставьте FreeBSD 7.3 (чтоб поставить 1-го диска хватит!) + MPD

Ммм. Ладно.


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


Изначально я имел в виду, можно ли его тогда использовать в качестве агрегатора и! роутера инета. То есть подключить к нему с одной стороны наши сети, а с другой канал от магистрального провайдера, поднять NAS и биллинг на ПК и подключить к нему же. То есть к этому коммутатору звездой будут подключены сети, инет и сервер доступа. Хотя, насколько я сейчас понимаю, обсчитать трафик так не получится.


То, что он пережует, я так же думаю. Просто ширина каналов у него ограничена - 100Мб/с. Но это уже в первую очередь ограничение топологии.


Долго думал над вашим комментарием и все равно не понимаю, почему пойдет через ядро? То есть через центральный свич внутрисетевой трафик в этой схеме (звезда) пойдет, но и только - никакого мощного NASа для прокачки не потребуется. Зачем ему видеть маки, если он коммутирует на 3-м уровне? Может еще дальнейшие мои ответы прояснят что-нибудь?


Это я сам придумал. Я имею в виду, что если делать так и ориентироваться на внутрисетевой трафик, то нужно соединять районные маршрутизаторы (они же NASы) кольцом или все-со-всеми (в идеальном варианте) и, соответственно, снимать показания трафика (как внутрисетевого так и инет) с них. А на/с центральный узел маршрутизировать только трафик интернета и центральных сервисов, ну и показания пользования трафика и контроль подключения по NetFlow и Radius.


В этой классической схеме ядро будет выглядеть так(?):

То есть получается, что локальный трафик пройдет через свич, через сервер доступа до роутера, тот его развернет и пустит его обратно через сервер доступа, через свич? Все L3 (маршрутизационные) функции свича оказываются ненужны? Серверы биллинга нужно подключить именно так, или лучше по другому? Хотя для испытательного стенда (как минимум) я вообще хочу объединить NAS, Router, RadServ и Billing в одном ПК. А в реальности, наверное, лучше совместить NAS и маршрутизатор в одном ПК, или нескольких, которые объединить дополнительным роутером. Хороший современный ПК вроде пару тысяч подключений должен потянуть.



Если будет возможность, что немаловероятно, будем ставить/менять на управляемые. L2-свич, вроде устоявшийся термин - управляемый коммутатор с поддержкой VLAN, но без функций маршрутизации. Вот эти же D-Link'и, а у меня сейчас упомянутые выше 3Com'ы. Медь, естественно, только непосредственно до абонента, а так везде оптика. За ссылки на дистрибутивы, спасибо. Я, наверное, все же для начала попробую поднять все на лине - инструкции есть, а FreeBSD я еще и не видел даже.

snark, спасибо большое за такой ответ развернутый!

именно так и использовать L3 свич у меня у самого блинковский DGS всю локалку и интернеты роутит и ничо - даже не замечает ни мегабитов ни pps ...


неправильно понимаете! трафик считать очень даже получится, т.к. Вы планируете использовать РРРоЕ то оно Вам и будет обеспечивать учет интернет трафика, ну а если Вы надумаете еще и локальный считать, то тут уже будем думать что делать (пересылку пакетов с помощью flow-fanout?) ...


когда дорастете до гигабита (по клиентам/скоростям/бабкам) - у Вас будут деньги на гигабитник мы же щас рассматриваем стартап или что?


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


да, NAS действительно не нужен, т.к. свич будет заниматься маршрутизацией локального трафика, но чтобы маршрутизировать ему нужно видеть МАС-и тех кого он роутит, т.е. локальных юзеров, а как Вы себе это представляете без видимости оных? давайте чтоб было проще понять - L3 свич - это тот же самый L2 свич только он еще роутить умеет ... L2 свичу нужны МАС-и? нужны (он вообще без них не заработает)! и L3 свичу они тоже нужны! смотрите:

юзер1, для связи с юзер2 не нужен МАС юзер2, т.к. пакеты будут роутится через свич, но юзер1 и юзер2 нужен МАС свича, чтобы слать ему пакеты, точно так же и свичу нужны МАС-и юзер1 и юзер2 чтоб слать пакеты им в ответ ... так понятнее?


давайте не путать теплое с мягким понятия "маршрутизатор" и "NAS", т.к. в данном случае это 2 принципиально разных вещи! на "NAS" терминируются РРРоЕ сессии, а "маршрутизатор" роутит пакеты ... NAS конечно тоже роутит, но это ... э-э-э ... не "езернет" маршрутизатор что ли ... короче - "маршрутизатор", он же "роутер" _не_ занимается РРРоЕ и поэтому он не "NAS"


в общем приближении схема как раз такая какая и должна быть, но ... Вы точно уверены что Вам надо считать локальный трафик? снимать netflow со 0,1/1 Гбит и обсчитывать его - это достаточно большая и, скорее всего, ненужная нагрузка на биллинг ... подумайте как нить на досуге, может оно Вам и не так нужно ...


если NAS не будет находится во всех VLAN-ах, то РРРоЕ через L3 свич работать _никогда_ не будет, т.к. РРРоЕ - протокол 2-го уровня, т.е. понятие "маршрутизация" в нем отсутствует как класс, если же NAS будет находится во всех VLAN, то трафик пойдет так:
локальный - через "районные свичи" и "L3-Свич"
интернет - юзер коннектится, получает адрес не из локальной сети (белый или серый - речь не об этом - главное чтоб не из локальных адресов) и его трафик отправляется на "Router" и далее в "интернет"


я бы предложил сделать так:

ну а между "L3-Свич" и "интернет" всегда можно воткнуть "Router" при необходимости


это еще почему?


да нормально ....


любой роутер/nas убивает не кол-во подключений, а кол-во пакетов в секунду



для фряхи и здесь, в вики есть инструкция, а то что оных в интернете over 9000 даже говорить как то не хочется

Да, спасибо, понятно. Виноват затупил.


Я не путаю, я имею в виду совместную установку:



Хотелось бы иметь такую возможность - помегабайтные тарифы-то нужны (кому-то еще ), и за пользование внутренними ресурсами в этом случае как-то надо снимать плату. Можно, конечно, абонентскую ввести.


Ага, раз так будет работать, то замечательно. Так вот в этой схеме трафик от пользователя в инет и обратно пойдет по схеме(?):

или напрямую(?):

То есть, NAS сам будет "маршрутизировать" в смысле пущать или не пущать пакеты через себя и считать их, или он будет(может) управлять Свичем по SMNP и Radius и снимать с него данные по трафику? NAS ведь еще должен из пула IP-адреса выдавать, а еще где-то нужно эти адреса маршрутизировать в адреса интернета.


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


Пока я хочу поставить и настроить все на одной машине, на которой стоит Убунту. А потом попробую поднять на фре, может быть для начала, тоже все сразу на одном ПК, благо биллинг позволяет.

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

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

Когда-то читал книжку Building Scalable Cisco Networks.
Там хорошо описана трехуровневая структура сети с примерами. В т.ч. обсуждается, как гонять трафик внутри сегмента. Правда речь идёт о более масштабных сетях. Есть ли она на русском - не в курсе.

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

Да, точно DC! Я мне ее уже советовали.


snark, спасибо за помощь и проявленное терпение. Собственно ваша подсказка уже является достаточным ответом. А вообще, я сюда на форум обратился не в первую очередь, просто в инете непросто (плохо искал?) найти цельные и четкие последовательные ответы и решения.

На русском она есть, спасибо за совет. Но я думаю мне пару недель назад больше бы подошла Развертывание Абонентских Сетей для Чайников. Жаль, что такие не выпускают. Хотя принципиальных вопросов уже не осталось.

Вам _РЕАЛЬНО_ поможет книга Аллан Леинванд, Брюс Пински - Конфигурирование маршрутизаторов Cisco, 2-е издание



в интернетах находится вообще без особого труда

из которой, если разумно подойдете к ее чтению и будете откидывать из нее части касающиеся настроек кошаков и их (котов) особенности Вы почерпнете МАССУ полезной информации о маршрутизации и многих других вещах

так же не стоит забывать про замечательнейшее, просто таки настольное, пособие г-на Семенова

когда прочитаете - приходите - будем дальше разговоры разговаривать

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

Кстати, есть возможность заиметь Catalyst 3550-24. Может стоит его поставить в ядро, если разобраться попроще будет?

Попробовал поднять PPPoE-сервер на u10.4 по разным инструкциям вроде этой, этой или этой, и ни фига - вроде поднимается, но клиент при подключении выдает 734 ошибку - Протокол управления PPP-связью был прерван. Думал дело в ошибке /dev/hands, оказалось не только у меня и, видимо, именно из-за 10.4. Так что, если ничего лучше не придумаю, буду организовывать отдельный ПК под NAS на фряхе.

Апну темку.
Присматриваемся к сабжу, сходу насыпалось несколько вопросов, кому не сложно проясните плиз.
1.Вопрос по железу и Оси для сервера не стоит, Ось Фри.
2.Сегмент построен на тупых свичах, не пинать) и не предлогать перестроить)
3.Авторизация абонента PPPOE - для этого нужен какой нить модуль ? если да просьба указать какой
4.Модуль оплаты, тут все понятно, (точнее модуль оплаты через терминал qiwi)
5.Может кто подсказать как правильно подсчитать минимальную конфигурацию в калькуляторе биллинга ?
7.Из коробки без модулей какие функции доступны ? интересует до 500абонентов

По итогу нужно уметь биллингу: за промежуток времени 1месяц без привязки к дате посчитать абонплату, по завершении приостановить услугу, не начисляя дальнейшую абонплату, после пополнения возобновить услугу, авторизация PPPOE, создать месячный отчет оказанных услуг, остальные плюшки хотса но дорого.

Постановка на правильные рельсы приветствуется.

ОС под биллинг - CentOS. Нет, не фря! На фре он без бубна не живет, ибо ява.



Сразу смотрите в сторону модуля inet.



Модуль mps, но Вы это уже и так поняли



Тут поставить галочку в "V" возле интересующего модуля, в "Количество договоров", напротив модуля ввести кол-во договоров и нажать внизу кнопку "Посчитать".
На 500 договоров модули:
inet - для РРРоЕ
npay - для начисления абоненток
reports - для отчетов
обойдутся в 36030 руб.

Если не будет хитрых абоненток или Вы не боитесь писать скрипты, то можно сэкономить на npay.
Если какие-то особые отчеты, кроме "кол-во принятого/переданного трафика" не нужны - можете сэкономить на reports.
Если сэкономите на этих 2-х модулях - БГБ Вам обойдется в 20 тыр.



Все, отмеченные в "V" тут. Скажу сразу - RADIUS для РРРоЕ не доступен.



м?

Бубен для Оси есть в наличии


Подразумевал посчитать за месяц денег начислено, снято, итого.


Вот тут огромнейшая благодарность, пришло просветление
Т.е. чтоб у абона был доступен ЛК без этого модули никак ? я верно понял ?
Тарифный план абон может изменить сам из своего ЛК ?


У меня получилось
Модуль Inet 500 20000.00
Модуль MPS 12000.00
Модуль NPay 500 8030.00
Модуль Reports 8000.00
Итого: 48030.00
Можно конечно вместо MPS взять киви онли 7тр экономии.
А можно взять со старта Inet на 200дог. 10тр, потом за 10тр докупить 300дог. ?

Модуль npay я так понял мне просто необходим, подскажите я правильно понял с его помощью
у меня будет возможность выполнять
поставленное условие:за промежуток времени 1месяц без привязки к дате посчитать абонплату...

вообще нисколько не взаимозаменяемые модули
можно

_________________
I'm clever. I've got a computer.

Меня интересует оплата в qiwi only, в mps есть оплата ОСМП а это и есть qiwi, или я заблуждаюсь ? http://osmp.ru
Cпс, при докупке 300 доплатить нужно будет 10тр ?

БГБ это делает и без модулей, но с модулем reports ... удобнее что ли ...



Нет, не верно. ЛК доступен всегда, а вот посмотреть свои сессии без модуля не сможет, т.к. сами сессии только модулем и позволяют появляться



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



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



Т.е. некий "плавающий месяц" не привязанный к календарному? Нет, этого в БГБ, ЕМНИМС, нету и когда будет не известно Видите тут dimOn-а? Берите и пинайте его до тех пор пока он не скажет, когда такое будет.

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

В точку.

Я удаленно подсмотрел говорят умеет, мне пока непонятно где это все смотреть в админке ?


Это и есть "мой плавающий" не привязанный к календарному месяц, если я правильно понимаю.

Да, он списывает $, но делает это только календарными месяцами, т.е. с 1-го и по 13-е последний день месяца

Тогда NPay мне не нужен.

Вам же подсказали:

stark писал(а):

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

Берете skn за грудки и выспрашиваете, когда мы увидим модуль subcription, который похоже будет делать то, что Вам, как и многим тут, надо.

модуль доступен для загрузки (5.2), желающие могут потестить

Модуль по функционалу аналогичен модулю Npay, за следущим исключением, настраеваемый период от секунды до бесконечности , активация нового периода только при условие достаточности средств.