[Gonarh]

Мастерам привет, требуется небольшая консультация нубу.

Хотим сделать сетку примерно до 1000 абонов, из железа: думаем ставить дэлинковские: основной L3, L2 на подъезд.

Есть несколько вопросов:

1. Полазив по форуму, вижу что народ в основном юзает фрибсд. Будет ли биллинг нормально работать на убунту?

2. Погуглив на тему фриварных биллинг софтин, убедился что есть туева хуча разного рода хлама(в основном либо сырые либо необходим аддон в виде танцев с бубном). Какой посоветуете? (Что нужно: отчёты по абонам, автоотключение должников, клиентский вэб интерфейс с возможностью просмотра объёма сожранного трафа, само собой админка)

3. Буду очень признателен если кто даст линки на инфу для чайников о: ВЛане, конфигурировании маршрутизаторов и т.д.

4. Ну по мелочи, кто еще чего подскажет, в каких местах заострить внимание, возможность узких мест, и т.д.

Заранее спасибо всем откликнувшимся. :)

Изменено 2 марта, 2010 пользователем Gonarh

[EvilShadow]

1. Полазив по форуму, вижу что народ в основном юзает фрибсд. Будет ли биллинг нормально работать на убунту?

Нет, это Jab юзает фрибсд. А народ - что удобнее.

2. Погуглив на тему фриварных биллинг софтин, убедился что есть туева хуча разного рода хлама(в основном либо сырые либо необходим аддон в виде танцев с бубном). Какой посоветуете? (Что нужно: отчёты по абонам, автоотключение должников, клиентский вэб интерфейс с возможностью просмотра объёма сожранного трафа, само собой админка)

Ищите по форуму, множество тем о сравнении биллингов было.

3. Буду очень признателен если кто даст линки на инфу для чайников о: ВЛане, конфигурировании маршрутизаторов и т.д.

http://google.com, http://nag.ru/projects/book/

 

[Gonarh]

Нет, это Jab юзает фрибсд. А народ - что удобнее.

А что удобнее с вашей точки зрения?

 

[EvilShadow]

Нет, это Jab юзает фрибсд. А народ - что удобнее.

А что удобнее с вашей точки зрения?

Лично я предпочитаю дебиан. Но это исключительно вопрос вкуса, при достаточно прямых руках практически всё будет нормально работать.

[Gonarh]

Лично я предпочитаю дебиан...

Ясно, убунта - это дочка дебиана, так что думаю, будем строить на ней

[martin74]

Вам удобнее гвозди зеленым молотком забивать, или оранжевым?

 

ОС - это инструмент. Что лучше знаете - то и используйте...

[Ilya Evseev]

> 1. Полазив по форуму, вижу что народ в основном юзает фрибсд. Будет ли биллинг нормально работать на убунту?

 

Биллингу это безразлично. Основные различия проявляются при настройке шлюза:

файрволл, nat, шейперы и подсчёт трафика в Линуксе и FreeBSD не имеют почти ничего общего.

 

> 2. Погуглив на тему фриварных биллинг софтин, убедился что есть туева хуча разного рода хлама

 

Abills, NoDeny, StarGazer, NetAMS, TraffPro - вот и весь выбор.

 

> 3. Буду очень признателен если кто даст линки на инфу для чайников о: ВЛане, конфигурировании маршрутизаторов и т.д.

 

www.google.ru

Для более конкретных ответов нужны более конкретные вопросы.

 

> 4. Ну по мелочи, кто еще чего подскажет, в каких местах заострить внимание, возможность узких мест, и т.д.

 

1) не швырять деньги на Цыски,

2) не экономить копеечку на домовых коммутаторах, сразу устанавливать как минимум dlink 3010/3026 и использовать port_security/address_binding,

3) делать сегментированную сеть "один дом=один vlan",

4) завести отдельный сервер для игр, dc++, форума и файлопомойки, каждому пользователю при подключении показывать, как ими пользоваться,

5) не заморачиваться с vpn/pppoe.

[Gonarh]

2) не экономить копеечку на домовых коммутаторах, сразу устанавливать как минимум dlink 3010/3026 и использовать port_security/address_binding,

задумывались 3028

3) делать сегментированную сеть "один дом=один vlan",

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

5) не заморачиваться с vpn/pppoe.

то есть?

[Ilya Evseev]

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

 

Для этой цели можно использовать "d-link asymmetric vlan".

 

>> не заморачиваться с vpn/pppoe.

> то есть?

 

Многие провайдеры предпочитают использовать vpn и pppoe для выхода пользователей в Интернет

по причине нехватки управляемого оборудования или управляющего софта.

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

[EvilShadow]

Многие провайдеры предпочитают использовать vpn и pppoe для выхода пользователей в Интернет

по причине нехватки управляемого оборудования или управляющего софта.

А ещё по причине простейшей настройки шейпера на каждом отдельном туннельном интерфейсе вместо кучи правил на одном физическом. И более простой авторизации и аккаунтинга. И возможности предоставления доступа определённому клиенту из любой точки сети. И более простому подсчёту трафика.

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

А это как посмотреть. Kernel-mode pppoe (или accel-pptp) не оказывает такого уже негативного влияния на производительность. Разумеется, если не использовать всяческие mppe/mppc.

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

[Ivan_83]

И более простому подсчёту трафика

Также считается как на физ интерфейсе.

 

 

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

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

 

А минус PPPoE/VPN в том, что клиенту у себя нужно делать настройки этого подключения, и не в каждом железе оно есть.

Например в SPA2102 нет VPN только PPPoE/статик/дхцп.

[Ilya Evseev]

> А ещё по причине простейшей настройки шейпера на каждом отдельном туннельном интерфейсе вместо кучи правил на одном физическом.

 

Вы про Линукс или FreeBSD?

Во FreeBSD за весь шейпинг отвечают два правила:

pipe tablearg ip from any to table(11) in

pipe tablearg ip from table(12) to any in

Плюс некоторое множество пайпов-шаблонов, по одному для каждой входящей и исходящей скорости,

а также две синхронизируемые из биллинга таблицы с привязкой ip-адресов к номерам этих пайпов.

 

Это чуть сложнее, чем чтение radattrs и назначение sfq на ppp-интерфейс в /etc/ppp/ip-up, зато универсальнее :)

 

> И более простой авторизации и аккаунтинга.

 

Ещё два правила:

allow ip from table(10) to any

allow ip from any to table(10)

Таблица периодически синхронизируется из биллинга.

Не сложнее, чем настроить Радиус.

 

> И возможности предоставления доступа определённому клиенту из любой точки сети.

 

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

В крайнем случае, можно поднять VPN ради одного такого клиента, но остальных-то за что?

 

> И более простому подсчёту трафика.

 

Без vpn трафик считается один раз на внешнем интерфейсе до NAT'а.

 

> Kernel-mode pppoe (или accel-pptp) не оказывает такого уже негативного влияния на производительность.

 

В любом случае, это дополнительная точка отказа.

Радиус сглючит, или pptp выкушает tcp sockets/bufs, или ещё что-нибудь.

 

> А плюс в том, что клиенту нередко проще включать и выключать интернеты, когда нужно,

 

Кнопка в Веб-интерфейсе (ярлык с прямым URL на Рабочем столе) или утилита-информер в system tray.

 

> не ставить себе всяческие файрволы и искать, "куда трафик пропал".

 

При нынешнем разгуле безлимитных тарифов это некритично.

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

Зато не будет ошибок 624, 629, 678, 691, 741, 800, слетевших локальных маршрутов, забытых vpn-паролей и прочих кошмариков.

[EvilShadow]

> А ещё по причине простейшей настройки шейпера на каждом отдельном туннельном интерфейсе вместо кучи правил на одном физическом.

 

Вы про Линукс или FreeBSD?

Во FreeBSD за весь шейпинг отвечают два правила:

pipe tablearg ip from any to table(11) in

pipe tablearg ip from table(12) to any in

Плюс некоторое множество пайпов-шаблонов, по одному для каждой входящей и исходящей скорости,

а также две синхронизируемые из биллинга таблицы с привязкой ip-адресов к номерам этих пайпов.

 

Это чуть сложнее, чем чтение radattrs и назначение sfq на ppp-интерфейс в /etc/ppp/ip-up, зато универсальнее :)

С Фрёй незнаком, что делают эти правила, не понимаю, поэтому возразить не могу :) Могу говорить только о tc. Повесить по одной-две дисциплины на каждый интерфейс намного проще, чем городить монстров на одном физическом интерфейсе с уймой классов и фильтров.

> И более простой авторизации и аккаунтинга.

 

Ещё два правила:

allow ip from table(10) to any

allow ip from any to table(10)

Таблица периодически синхронизируется из биллинга.

Не сложнее, чем настроить Радиус.

Это даёт ответ на вопрос, когда клиент подключился или отключился?

 

> И более простому подсчёту трафика.

 

Без vpn трафик считается один раз на внешнем интерфейсе до NAT'а.

Каким образом считается? Через netflow? Acct-Input/Output-Octets абсолютно однозначны и не имеют задержек сбора статистики и прочих особенностей netflow.

 

> Kernel-mode pppoe (или accel-pptp) не оказывает такого уже негативного влияния на производительность.

 

В любом случае, это дополнительная точка отказа.

Радиус сглючит, или pptp выкушает tcp sockets/bufs, или ещё что-нибудь.

С равным успехом сглючить может часть, добавляющая-удаляющая правила файрвола, приведённые выше. С чего радиусу глючить?

> А плюс в том, что клиенту нередко проще включать и выключать интернеты, когда нужно,

 

Кнопка в Веб-интерфейсе (ярлык с прямым URL на Рабочем столе) или утилита-информер в system tray.

Утилита есть не везде, а веб-интерфейс куда сложнее ярлыка дозвонщика, куда надо тыкнуть один раз. В веб-интерфейс ещё логиниться надо, а время жизни кук тоже не бесконечное.

> не ставить себе всяческие файрволы и искать, "куда трафик пропал".

 

При нынешнем разгуле безлимитных тарифов это некритично.

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

Зато не будет ошибок 624, 629, 678, 691, 741, 800, слетевших локальных маршрутов, забытых vpn-паролей и прочих кошмариков.

Будут забытые пароли к веб-интерфейсу? :)

Что за слетевшие локальные маршруты? Куда они слетают? Почему?

Список ошибок некорректен. Та же 800 для pptp означает неработающий ДНС. Думается мне, с неработающим ДНСом трафик у Ваших абонентов тоже ходить не будет.

 

 

 

 

Также считается как на физ интерфейсе.

Не так, если у Вас нет интерфейса на абонента. При разделяемом между несколькими узлами интерфейсе нужен механизм съёма статистики (тот же netflow), а при интерфейсе на абонента - всего лишь счётчики трафика на интерфейсе.

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

Отключается. Вместе с локальной сетью. Которая нужна не только для интернетов.

А минус PPPoE/VPN в том, что клиенту у себя нужно делать настройки этого подключения, и не в каждом железе оно есть.

Например в SPA2102 нет VPN только PPPoE/статик/дхцп.

Чем Вам pppoe не vpn? Есть в указанной железке pppoe - вот и славно. Я же не предлагаю пользоваться исключительно pptp :)

[Ilya Evseev]

>> Таблица периодически синхронизируется из биллинга.

>> Не сложнее, чем настроить Радиус.

 

> Это даёт ответ на вопрос, когда клиент подключился или отключился?

 

Отдельно для Интернета такого понятия нет.

Есть link up/link down на порту коммутатора, читаемый через syslog или snmptrap,

и есть учёт Интернет-активности на шлюзе.

 

>> Без vpn трафик считается один раз на внешнем интерфейсе до NAT'а.

> Каким образом считается? Через netflow?

 

Через что больше нравится: netflow, ipacct и т.д.

 

> веб-интерфейс куда сложнее ярлыка дозвонщика, куда надо тыкнуть один раз.

> В веб-интерфейс ещё логиниться надо, а время жизни кук тоже не бесконечное.

 

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

http://www.homelink.ru/forum/viewtopic.php?p=43236#43236

 

> Что за слетевшие локальные маршруты? Куда они слетают? Почему?

 

Если сеть сегментированная, нужны статические маршруты, чтобы локалка не отваливалась

при установленном vpn-соединении, т.к. оно назначает себя шлюзом по умолчанию.

Куда слетали - надо было у Винды спросить :)

 

> Список ошибок некорректен. Та же 800 для pptp означает неработающий ДНС.

 

А также:

1) отсутствует физическое подключение к локальной сети,

2) в свойствах VPN-соединения неверно указано имя VPN-сервера,

3) в свойствах локальной сети указаны неправильные параметры: IP-адрес, маска, шлюз, DNS.

http://www.homelink.ru/wiki/index.php5/Типовые_проблемы

 

> При разделяемом между несколькими узлами интерфейсе нужен механизм съёма статистики (тот же netflow),

> а при интерфейсе на абонента - всего лишь счётчики трафика на интерфейсе.

 

Есть такая обязательная вещь, как детальная статистика: ip-адреса, протоколы, порты.

 

> Есть в указанной железке pppoe - вот и славно.

 

Pppoe не работает через layer-3, т.е. либо в клиентском сегменте должен присутствовать pppoe relay,

либо клиентский vlan должен быть дотянут до BRAS'ов. И то, и другое означает лишний труд.

Вдобавок, pppoe соединения трудно балансировать между bras'ами.

Не считая сложностей в настройке *никсов и старых версий Windows у клиентов.

Изменено 4 марта, 2010 пользователем Ilya Evseev

[EvilShadow]

>> Таблица периодически синхронизируется из биллинга.

>> Не сложнее, чем настроить Радиус.

 

> Это даёт ответ на вопрос, когда клиент подключился или отключился?

 

Отдельно для Интернета такого понятия нет.

Есть link up/link down на порту коммутатора, читаемый через syslog или snmptrap,

и есть учёт Интернет-активности на шлюзе.

Тем не менее, клиента этот вопрос часто интересует.

> веб-интерфейс куда сложнее ярлыка дозвонщика, куда надо тыкнуть один раз.

> В веб-интерфейс ещё логиниться надо, а время жизни кук тоже не бесконечное.

 

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

http://www.homelink.ru/forum/viewtopic.php?p=43236#43236

Что крайне небезопасно.

> Что за слетевшие локальные маршруты? Куда они слетают? Почему?

 

Если сеть сегментированная, нужны статические маршруты, чтобы локалка не отваливалась

при установленном vpn-соединении, т.к. оно назначает себя шлюзом по умолчанию.

Куда слетали - надо было у Винды спросить :)

Ну назначает и назначает. Клиент получает сетевой адрес по DHCP и вместе с ним пачку маршрутов. Подключается по pppoe и получает только маршрут по умолчанию. Локалка никуда не девается.

> Список ошибок некорректен. Та же 800 для pptp означает неработающий ДНС.

 

А также:

1) отсутствует физическое подключение к локальной сети,

2) в свойствах VPN-соединения неверно указано имя VPN-сервера,

3) в свойствах локальной сети указаны неправильные параметры: IP-адрес, маска, шлюз, DNS.

2 - для pppoe неактуально, 1 и 3 - клиент до шлюза не доберётся. Всё равно не будет работать, что с ВПНом, что без него :)

> При разделяемом между несколькими узлами интерфейсе нужен механизм съёма статистики (тот же netflow),

> а при интерфейсе на абонента - всего лишь счётчики трафика на интерфейсе.

 

Есть такая обязательная вещь, как детальная статистика: ip-адреса, протоколы, порты.

Во-первых, не все посетители форума живут в России, где эта вещь обязательна. А во-вторых, такую статистику можно снимать и отправлять куда-нибудь на flow-capture, который будет складывать её в архив. При этом использовать её для учёта в реальном времени - намного более ресурсоёмкая задача, чем пользоваться счётчиками интерфейсов. Например, у меня такая статистика собирается, но в биллинге используется только для тех абонентов, кто не пользуется впном. Это имеет смысл, поскольку анализ множества сессий в реальном времени - штука прожорливая. Статистика же для всех остальных лежит в архиве до той поры, пока она может понадобиться.

> Есть в указанной железке pppoe - вот и славно.

 

Pppoe не работает через layer-3, т.е. либо в клиентском сегменте должен присутствовать pppoe relay,

либо клиентский vlan должен быть дотянут до BRAS'ов. И то, и другое означает лишний труд.

Ну тогда и DHCP использовать - лишний труд, поскольку он работает на бродкастах :)

Вдобавок, pppoe соединения трудно балансировать между bras'ами.

Почему? Поставил ещё одну машинку, залил туда образ ОС, подправил сетевые настройки и имя хоста и вперёд.

Не считая сложностей в настройке *никсов и старых версий Windows у клиентов.

А для этого у меня клиенты могут подключаться через pppoe, pptp и даже вовсе без туннелей. Зачем упираться в одну технологию, если можно предоставить то, что удобнее клиенту?

[jp1111]

> 2. Погуглив на тему фриварных биллинг софтин, убедился что есть туева хуча разного рода хлама

 

Abills, NoDeny, StarGazer, NetAMS, TraffPro - вот и весь выбор.

Хм, любопытный совет однако ...

Статью походу люди зря писали http://www.nag.ru/articles/article/17373/faq-billing.html

[Ilya Evseev]

> 2. Погуглив на тему фриварных биллинг софтин, убедился что есть туева хуча разного рода хлама

 

Abills, NoDeny, StarGazer, NetAMS, TraffPro - вот и весь выбор.

Хм, любопытный совет однако ...

Статью походу люди зря писали http://www.nag.ru/articles/article/17373/faq-billing.html

Статья, насколько я понял, рассказывает о закрытых платных биллингах, а вопрос был про фриварные.

[jp1111]

Статья, насколько я понял, рассказывает о закрытых платных биллингах, а вопрос был про фриварные.

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

[Ilya Evseev]

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

Если речь идёт про РФ, то для суда играет роль не фриварность биллинга, а наличие сертификата РСТ.

Тем не менее, многие достаточно крупные провайдеры с десятками тысяч клиентов

используют несертифицированные биллинги, например, NeXeT или самописные поделия (которые подчас ужасны).

Про мелких и не говорю - используют Abills, TraffPro, NoDeny и живы-здоровы.