[Saab95]

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

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

 

PPPoE это и есть интерфейс. Никаких привязок скоростей к логинам нет. Если клиент отключается, то автоматически удаляется правило шейпера, если используется ограничение скорости через PPPoE. Если клиент отключился и включился по новой, то через событие в биллинге ему сразу отдадут нужную скорость. Поэтому многие провайдеры и делают изменение скорости с обрывом сессий. Есть один крупный провайдер, так в нем после изменения тарифа нужно ждать до 4 часов изменения скорости, и это сама техподдержка говорит. Никто не жалуется, по крайней мере клиентов у него море.

[NiTr0]

PPPoE это и есть интерфейс. Никаких привязок скоростей к логинам нет.

Неправильно интерпретировал логин в

find name=\"<pppoe-$login>\"

. Если это таки номер интерфейса (а не логин) - тогда да, жопа с race condition во весь рост.

 

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

Ну у кого руки не стоят - да, делают. Клиентов это в восторг приводит, и они толпами будут бежать к конкуренту, который им предложит то же но "без разрыва". Думаю, вы догадываетесь, как много счастья геймеру приносит обрыв связи в процессе рейда на босса? Или что случается с деньгами в онлайн казино при этом?

 

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

Может, у него конкуренции нет?

[^rage^]

Неуправляемые сегменты обычно содержат не более 10-20 клиентов. Из них процентов 40 платят не регулярно. А перед ними уже все заблокировано. Даже если некоторые умники насобирают паролей, то доступ все равно безлимитный, если клиент включит комп а соединение не проходит он тут же позвонит и сообщит о неисправности, вот только таких случаев еще не было.

 

кто позвонит, вы о чём? размер сегмента влияет лишь на масштабы последствий. когда у ваших 20 клиентов "утекут" почти всё что ходило в plain text, вопросы будут к провайдеру в первую очередь.

 

Ну тогда нужно отказаться от ограничения скорости на PPPoE интерфейсах и резать ее через PCQ по разным направлениям.

а как эта pcq работает вы можете рассказать?

 

Создается правило ограничения скорости, где указывается лимит входящей и исходящей. Создается адрес-лист куда добавляются адреса клиентов, которые должны пользоваться этим тарифом. Далее если нужно поменять скорость, например увеличить в 2 раза, просто меняются параметры этого правила одной командой, у всех сразу увеличивается скорость. Вдобавок PCQ буферизует данные, а не отбрасывает, поэтому нет потерь на дропы.

 

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

 

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

 

детский сад. без лицензии? ;) незаконная предпринимательская деятельность.

 

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

жалоба в надзорный орган. и микротик - это всё-таки linux.

[Saab95]

PPPoE это и есть интерфейс. Никаких привязок скоростей к логинам нет.

Неправильно интерпретировал логин в

find name=\"<pppoe-$login>\"

. Если это таки номер интерфейса (а не логин) - тогда да, жопа с race condition во весь рост.

 

Это не номер интерфейса, а имя, хотя в принципе одно и то же.

 

Поясните тогда суть вашей проблемы более понятно. Т.к. в текущей схеме с микротиком нет никаких проблем со скоростью и ее изменением. Все работает четко и быстро. Например биллинг выдает 2 команды в секунду по SSH, что бы изменить скорость 500 клиентам требуется менее 5 минут. Если клиент отключится и тут же подключится, он получит уже измененную скорость.

 

 

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

Может, у него конкуренции нет?

 

Есть. Только никто не видит проблемы в этом. Ночное ускорение включается быстро, в 0 часов с задержкой максимум 5 минут, тариф меняют раз в месяц, поэтому для клиентов нет никаких проблем подождать несколько часов. Кстати у него на доступе циски стоят=)

[Saab95]

Неуправляемые сегменты обычно содержат не более 10-20 клиентов. Из них процентов 40 платят не регулярно. А перед ними уже все заблокировано. Даже если некоторые умники насобирают паролей, то доступ все равно безлимитный, если клиент включит комп а соединение не проходит он тут же позвонит и сообщит о неисправности, вот только таких случаев еще не было.

 

кто позвонит, вы о чём? размер сегмента влияет лишь на масштабы последствий. когда у ваших 20 клиентов "утекут" почти всё что ходило в plain text, вопросы будут к провайдеру в первую очередь.

 

Да никто не ворует пароли. У всех прямо как будто в сети только хакеры сидят и круглые сутки пароли норовят утащить. Придумали проблему на пустом месте.

 

Обычно если ставят не управляемое оборудование, то там клиенты не утекают, т.к. других провайдеров нет или качество их услуги заведомо ниже. Возьмите для примера какой-то поселочек в 10км от города, где всего 10 двух этажных домов и клиентов максимум 20 человек. У них кроме 3G и ADSL нет альтернатив, но они не могут конкурировать даже с пионерсетью на хабах за 400р и витухой с чердака на чердак. Обслуживанием всего хозяйства обычно занимается 1-2 местных парня, которые получают за это не большую денежку и бесплатный интернет. Все что они могут это витуху протянуть и обжать да коммутатор в случае выхода из строя заменить.

 

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

 

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

 

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

 

детский сад. без лицензии? ;) незаконная предпринимательская деятельность.

 

А что им еще остается? Если никто не хочет к ним в поселок идти? Купят канал интернета у провайдера в городе и по радио заберут, внутри своего поселка самостоятельно распределяют. Лицензия им ни к чему.

 

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

жалоба в надзорный орган. и микротик - это всё-таки linux.

 

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

[NiTr0]

Это не номер интерфейса, а имя, хотя в принципе одно и то же.

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

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

 

Все работает четко и быстро. Например биллинг выдает 2 команды в секунду по SSH, что бы изменить скорость 500 клиентам требуется менее 5 минут.

Четко и быстро - это 50-100 запросов в секунду, как в нормальном CoA. А то, что у вас - зовется бег на костылях...

[Saab95]

Это не номер интерфейса, а имя, хотя в принципе одно и то же.

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

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

 

В микротике у PPP нет номеров интерфейсов, а есть имя, с которым система и работает, например pppoe-vasia, pppoe-petia и т.п. Состоит он из логина клиента и приписки, по какому протоколу он подключился. pppoe, pptp, sstp, после через дефис следует логин клиента. Если клиент отключился и включился снова, то имя будет такое же. При отключении все ограничения скорости удаляются. Соответственно нет никакой проблемы с присвоением не правильной скорости другому пользователю. Множественные сессии разрешать нет смысла, поэтому изначально разрешено подключаться только одному пользователю. Поэтому совершенно нет никаких проблем с какими-то не правильными скоростями.

 

 

Все работает четко и быстро. Например биллинг выдает 2 команды в секунду по SSH, что бы изменить скорость 500 клиентам требуется менее 5 минут.

Четко и быстро - это 50-100 запросов в секунду, как в нормальном CoA. А то, что у вас - зовется бег на костылях...

 

Ничего не мешает отдавать команды чаще. Такое ограничение сделано для совместимости со всеми устройствами. Ведь авторизацию может делать и какой-нито RB750, который обслуживает 10 клиентов. В нормальной схеме с OSPF между роутерами появляется отказоустойчивость. Каждый микротик, работающий в роли PPPoE сервера собирает себе в локальную базу все учетки клиентов, которые через него ходят. И в случае полного отключения центрального узла и обрыва всех кабелей до него, оставшиеся узлы могут самостоятельно обслуживать и принимать соединения от клиентов, пуская в интернет через резервные каналы во всех частях сети.

 

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

[alkanaft]

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

[NiTr0]

В микротике у PPP нет номеров интерфейсов, а есть имя, с которым система и работает

Как быть с 2-3 сессиями с одной учетки?

 

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

С чего это вы взяли? А если это - корпоративный впн, куда сотрудник подключается и из филиала, и из дому, и с ноута на обеде если что-то срочное?

 

Ничего не мешает отдавать команды чаще.

Мешает. Скорость генерации сессионных ключей.

 

Ведь авторизацию может делать и какой-нито RB750, который обслуживает 10 клиентов.

Угу. На каждую команду только уйдет секунд 5 :)

 

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

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

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

 

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

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

[nuclearcat]

Множественные сессии разрешать нет смысла, поэтому изначально разрешено подключаться только одному пользователю. Поэтому совершенно нет никаких проблем с какими-то не правильными скоростями.

Есть такие забавные роутеры - TP-Link, которые любят подключаться дважды. Причем если одну сессию рубить - инет падает.

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

Провайдеры любители микротиков таких клиентов теряют, а если учесть распространенность TP-link (из-за дешевизны) - я даже написал программку, которая следит за _настоящими_ множественными сессиями по потреблению траффика на моих кастомных pppoe и хорошо торгую такими фичами.

[Saab95]

В микротике у PPP нет номеров интерфейсов, а есть имя, с которым система и работает

Как быть с 2-3 сессиями с одной учетки?

 

Если нужно несколько сессий, то тогда после имени интерфейса будет приписываться цифра, например pppoe-vasia2, pppoe-vasia3 и т.п. Микротик знает о всех именах при авторизации по радиусу, для него это разные интерфейсы, тут уже биллинг должен сам обсчитывать и управлять сессиями.

 

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

С чего это вы взяли? А если это - корпоративный впн, куда сотрудник подключается и из филиала, и из дому, и с ноута на обеде если что-то срочное?

 

При чем тут корпоративный впн и PPPoE для подключения к инету? На корпоративных вообще дают каждому свой логин и выдают адреса из пула без привязки, тут хоть пусть 100 раз подключается, никаких проблем. Все ограничения или едины для всех, или обсчитываются системой управления по радиусу. Если нужна многосессионность то микротик тут тоже даст фору любой циске.

 

 

Ничего не мешает отдавать команды чаще.

Мешает. Скорость генерации сессионных ключей.

 

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

 

 

Ведь авторизацию может делать и какой-нито RB750, который обслуживает 10 клиентов.

Угу. На каждую команду только уйдет секунд 5 :)

 

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

 

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

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

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

 

Вы видимо не понимаете принцип работы PPPoE. Никаких пулов там нет. Все адреса раздаются по командам из биллинга. Какой последний адрес биллинг выдал, под тем клиент и будет работать. Биллинг сам следит что бы адреса не повторялись. В случае проблем все адреса внутри сети, даже белые, начинают работать через NAT, либо по L2TP туннелям все бежит например в датацентр, если там есть резервный выход в сеть под реальниками.

 

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

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

 

Получается все только в центр и резервы линков. В случае PPPoE можно строит децентрализованные системы со многими точками слива трафика к вышестоящему оператору. Что по факту имеет более высокую отказоустойчивость. При грамотном планировании, выноса BGP в один или несколько датацентров и организации обмена маршрутами по OSPF перерыва в предоставлении услуги вообще не будет.

 

Множественные сессии разрешать нет смысла, поэтому изначально разрешено подключаться только одному пользователю. Поэтому совершенно нет никаких проблем с какими-то не правильными скоростями.

Есть такие забавные роутеры - TP-Link, которые любят подключаться дважды. Причем если одну сессию рубить - инет падает.

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

Провайдеры любители микротиков таких клиентов теряют, а если учесть распространенность TP-link (из-за дешевизны) - я даже написал программку, которая следит за _настоящими_ множественными сессиями по потреблению траффика на моих кастомных pppoe и хорошо торгую такими фичами.

 

У нас тоже есть различные тп-линки, никаких жалоб еще не поступало. В логах только бывает они долбятся на авторизацию каждые 2-3 секунды.

[NiTr0]

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

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

 

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

На каком тазике?

 

Ключи один раз создаются и сохраняются на устройствах.

Эти ключи используются только для аутентификации (хендшейка). Для шифрования данных генерится сессионный ключ. Так что - не в тему.

 

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

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

 

Получается все только в центр и резервы линков. В случае PPPoE можно строит децентрализованные системы со многими точками слива трафика к вышестоящему оператору. Что по факту имеет более высокую отказоустойчивость. При грамотном планировании, выноса BGP в один или несколько датацентров и организации обмена маршрутами по OSPF перерыва в предоставлении услуги вообще не будет.

Что по факту будет иметь меньшую отказоустойчивость ввиду чрезмерного усложнения системы, особенно - при наличии нескольких аплинков. Хотел бы я посмотреть на подобную систему, подключенную к 4-5 различным аплинкам, с выдачей белых адресов... И какой апокалипсис случится при проблемах с бгп сервером.

О том, что более-менее крупные провы с трафиком порядка 4-5 гбит уже арендуют себе лямбду у одного или нескольких магистралов до точки обмена траффиком (где собссно берут и мир/IX), и децентрализовать это невозможно в принципе - помолчу.

[Saab95]

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

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

 

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

 

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

На каком тазике?

 

i3 3.4GHz

 

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

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

 

Я разговор вел про то, что биллинг полностью отключится (все резервные сервера биллинга тоже перестанут быть доступными). При этом никаким образом адреса уже не будут перераспределятся и вся сеть будет функционировать самостоятельно на локальных базах каждого сервера. В самом крайнем случае, когда например BGP полностью отключится и не будет связи по белым адресам, все переключается на НАТ через каналы вышестоящих операторов. У них нужно обязательно заказывать хотя бы один белый адрес для этих целей.

 

Получается все только в центр и резервы линков. В случае PPPoE можно строит децентрализованные системы со многими точками слива трафика к вышестоящему оператору. Что по факту имеет более высокую отказоустойчивость. При грамотном планировании, выноса BGP в один или несколько датацентров и организации обмена маршрутами по OSPF перерыва в предоставлении услуги вообще не будет.

Что по факту будет иметь меньшую отказоустойчивость ввиду чрезмерного усложнения системы, особенно - при наличии нескольких аплинков. Хотел бы я посмотреть на подобную систему, подключенную к 4-5 различным аплинкам, с выдачей белых адресов... И какой апокалипсис случится при проблемах с бгп сервером.

О том, что более-менее крупные провы с трафиком порядка 4-5 гбит уже арендуют себе лямбду у одного или нескольких магистралов до точки обмена траффиком (где собссно берут и мир/IX), и децентрализовать это невозможно в принципе - помолчу.

 

Ну если у них сломается система, как было некоторое время с одним довольно крупным провайдером, получается простой на несколько часов, при этом не работает даже сайт=) И нет вообще никаких возможностей пустить что-то в обход. Конечно такие проблемы бывают редко, но всегда очень метко.

[nuclearcat]

Я разговор вел про то, что биллинг полностью отключится (все резервные сервера биллинга тоже перестанут быть доступными). При этом никаким образом адреса уже не будут перераспределятся и вся сеть будет функционировать самостоятельно на локальных базах каждого сервера. В самом крайнем случае, когда например BGP полностью отключится и не будет связи по белым адресам, все переключается на НАТ через каналы вышестоящих операторов. У них нужно обязательно заказывать хотя бы один белый адрес для этих целей.

Если потом один из этих юзеров напишет "я ваш Кремль шатал, скороварку с порохом ложил" - вы потом откуда будете вытягивать, кто это сделал?

Биллинг _не должен падать_, должно быть грамотное резервирование.

Кстати когда тут полиция по таким поводам приходит к микротиколюбителям - это отдельное шоу. Нормальных логов у них обычно нет, и дрючат их во все дыры :)

[^rage^]

Неуправляемые сегменты обычно содержат не более 10-20 клиентов. Из них процентов 40 платят не регулярно. А перед ними уже все заблокировано. Даже если некоторые умники насобирают паролей, то доступ все равно безлимитный, если клиент включит комп а соединение не проходит он тут же позвонит и сообщит о неисправности, вот только таких случаев еще не было.

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

[vr.bersek]

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

[snark]

мне нужна конфигурация оборудования, которая реально будет работать

 

Еще на 1-й странице ответили:

 

 

Вот такие платформы - http://www.nix.ru/autocatalog/server_systems_asustek/ASUS_1U_RS100X7_90S7GA0000500UET_LGA1155_C202_PCIE_2xGbLAN_4DDRIII_220W_137216.html - только предыдущие версии, нормально лопатят гигабит с внешней 2-х портовой интеловской сетевушкой.

 

 

 

у кого реально похожая ситуация и у кого что стоит?!

...

улыбнуло про маршрутизатор за 300 000р, а че не за пол милииона?!

 

У меня 3к онлайна на нескольких (для redundancy + low load) серверах с MPD и трафика бОльше 1Гбит/с - я склонен считать, что у нас немного похожая ситуация.

Я для себя выбрал SE100 вместо этих + новых серверов, т.к. в соотношении цена/производительность это самое выгодное решение (ASR тупо дроже) + железное решение стоит чуть дороже, чем замена старых и покупка новых серверов. Вы можете продолжать улыбаться дальше, пытаясь вкорячить все 3к онлайна на один сервер да еще и с МТ, а я буду спокойно работать и развиваться на железном решении.

[Saab95]

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

 

А вот тут список чего понимает - http://wiki.mikrotik.com/wiki/Supported_Hardware

[^rage^]

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

Не хотел ввязываться... Но микротик есть воры ибо GPL v2 и GPL v3 они нарушают и при этом выдумывают какие-то "уровни", они сами ниже плинтуса.

 

Не смотря на все "приимущества" и прочее, перелицензирование и закрытие кода под GPL невозможно. И в данной теме обсуждение как купить у вора и использовать вне закона вызывает только недопонимание.

 

В общем свинство, оно и в африке свинство. Давил и буду давить fsf на тему "разбирательств" с микротик и ворами около них.

отсюда

[Картуччо]

Собака лает, караван идёт. Сфстудио брызгал слюной в 2009, до сих пор с микротиком ничего не случилось.

[vr.bersek]

мне нужна конфигурация оборудования, которая реально будет работать

 

Еще на 1-й странице ответили:

 

 

Вот такие платформы - http://www.nix.ru/autocatalog/server_systems_asustek/ASUS_1U_RS100X7_90S7GA0000500UET_LGA1155_C202_PCIE_2xGbLAN_4DDRIII_220W_137216.html - только предыдущие версии, нормально лопатят гигабит с внешней 2-х портовой интеловской сетевушкой.

 

 

 

у кого реально похожая ситуация и у кого что стоит?!

...

улыбнуло про маршрутизатор за 300 000р, а че не за пол милииона?!

 

У меня 3к онлайна на нескольких (для redundancy + low load) серверах с MPD и трафика бОльше 1Гбит/с - я склонен считать, что у нас немного похожая ситуация.

Я для себя выбрал SE100 вместо этих + новых серверов, т.к. в соотношении цена/производительность это самое выгодное решение (ASR тупо дроже) + железное решение стоит чуть дороже, чем замена старых и покупка новых серверов. Вы можете продолжать улыбаться дальше, пытаясь вкорячить все 3к онлайна на один сервер да еще и с МТ, а я буду спокойно работать и развиваться на железном решении.

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

[NiTr0]

i3 3.4GHz

Попробуйте на атоме. Потом - попробуйте на RB750. Удивитесь...

 

Я разговор вел про то, что биллинг полностью отключится (все резервные сервера биллинга тоже перестанут быть доступными). При этом никаким образом адреса уже не будут перераспределятся и вся сеть будет функционировать самостоятельно на локальных базах каждого сервера. В самом крайнем случае, когда например BGP полностью отключится и не будет связи по белым адресам, все переключается на НАТ через каналы вышестоящих операторов. У них нужно обязательно заказывать хотя бы один белый адрес для этих целей.

Если биллинг полностью отключился - с какой радости микротик должен пускать абонов? Откуда ему знать, что абон Вася, не оплативший 100500 лет назад инет, теперь его оплатил и пользуется? А может - и не оплатил, но решил подключиться проверить- вдруг инет есть? И почему это биллинг будет недоступен, а сервера с БГП - доступными?

Вклчение ната при падении бгп - если сервер работает с нагрузкой проца более 50% без ната, как думаете, к чему приведет включение ната? ;)

 

И опять же, нарисуйте, как будет работать ваша вундервафля с десятком каналов к аплинкам при необходимости использовать 4 разных апстрима, и растянуть поверх этого одну-единственную подсеть /24 (ну или любую другую) в случае потери связи с центром? Чо, трафик побежит на бордюр, а потом с него - через канал апстрима чудом смаршрутизируется на брасы? Или EoIP городить еще? И чем это лучше резервного л2 транспорта в ядро через аплинк с STP?

 

Ну если у них сломается система, как было некоторое время с одним довольно крупным провайдером, получается простой на несколько часов, при этом не работает даже сайт=) И нет вообще никаких возможностей пустить что-то в обход. Конечно такие проблемы бывают редко, но всегда очень метко.

Чтобы система не ломалась, используется резервирование. Или на железках (дублирование всех блоков в рамках одного шасси), или софтовое.

Наша практика показывает, что аплинки падают на порядок чаще, чем тазики. И на несколько порядков чаще, чем свичи ядра (с которыми проблем практически не было).

[vadimus]

Вот нагрузка на таких серверах (ASUS 1U RS100-X7 с i3 3.3) , как описывает Saab95, все работает на встроенных сетевых Intel 82574L и ubuntu 12.10.

http://89.222.135.129:8080/

http://89.222.135.191:8080/

NAT на них же. На 3000 абонентов выходит дешевле чем SE100 и при выходе из строя одного легко перебросить абонентов на другой.

[snark]

На 3000 абонентов выходит дешевле чем SE100

 

Я ведь правильно понимаю, что у Вас там и СоА, и посервисный аккаунтинг, и деление скоростей мир/локалка, и некий аналог ISG/CLIPS и много чего еще из коробки и без костылей работает, верно?

 

 

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

 

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

 

 

P.S. Я не продавец и мне фиолетово что купит ТС. Просто я не хочу, чтобы он, по прошествии некоторого времени, подумал "надо было брать железку ...".

[vadimus]

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