Jump to content
Калькуляторы

mikrotik в роле BRAS биллинг - mikrotik через radius

Разговор пошел не по теме, по прежнему хочется поговорить с теме у кого mikrotik работает в роле BRAS в схеме DHCP RADIUS, плиз откликнитесь..

А для остальных объясню свою позицию по данному вопросу.

1. Почему IPoE а PPTP или L2TP: снизить нагрузку на тех поддержку, дабы не объяснять клиенту как создавать подключение, и избавить самого клиента от проблем с созданием подключения.

2. Почему RADIUS, а не управление через SSH или Mikrotik API: во первых Radius универсальный протокол, для связи NAS с биллингом, т.к. в сети присутствуют и cisco 7206, во вторых присутствует метод авторизации по порту (82 Options) - не нужно держать отдельный DHCP сервер, и опять снимает лишнюю нагрузку с техподдержки когда у клиента меняется MAC ( переавторизация абонента ) - хотя последнее реализуемо но опять костылями - будем считать спорный момент, для тех кто любит костыли.

3.По поводу аккаутинга - блюстители порядка все равно требуют хранить netflow логи, ну и за одно и траф посчитаем ( + 5 % нагрузке на сервер)

4.И на последок по чему именно mikrotik, т.к. он позволяет на меньшие деньги прожевать максимальное количество траффика, и держать резервный для ZIP не так дорого, но опять там где нужно проживать меньше 500 Мбит/c, лучше возьму cisco 7206 NPE-G1, т.к. шас не очень дорого стоит.

 

К стати хочу напомнить любителям VPN, в вашем случае авторизации абонент без проблем передает свой пароль другому абоненту, отключается, и другой абонент спокойно пользуется интернетом, при таких возможностях теряется 3%-4% денег, которые абонент заплатил бы за использование.

Итого, исходя из всех пунктов получается не плохая экономия денежных средств (на ТП, ZIP, оборудование) + удобство абонента, из минусов вижу только качество mikrotik в плане долговечности и зависаний, но это вопрос компенсируется наличием дешевого ZIP и возможностью, удаленно через GSM перегрузить всю стойку )))

 

По поводу VLAN на абонента, ну хороший вариант, но к сожалению не все оборудование по сети поддерживает QinQ, да есть ещё проблемы с DHCP и прочие мелкие нюансы.

 

Да и хочу уточнить и в случае cisco и в случае mikrotik, не там не там не идет вопрос о BGP, т.к. приходиться держать 3-5 full view, c этой задачей хорошо и дешево справляется софтовый роутер.

 

P.S. По поводу BG-Billing не будем спорить кому что понравилось и на что было денег, тот то и выбрал.

Share this post


Link to post
Share on other sites

"По поводу VLAN на абонента, ну хороший вариант, но к сожалению не все оборудование по сети поддерживает QinQ, да есть ещё проблемы с DHCP и прочие мелкие нюансы"

 

Для QinQ не обязательно чтобы все оборудование его поддерживало. Хватит только агрегации. Главное удобство в том,что с qinq весь доступ имеет одинаковую конфигурацию

Share this post


Link to post
Share on other sites

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

 

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

 

или чтобы сдать СОРМ...

 

Зачем сорму радиус? Он вполне нормально и IP трафик обрабатывает, при условии что адреса абонентов статические, или могут отправляться сопоставления.

 

А вот тут не надо гнать! BGBilling один из лучших биллингов на сегодняшний день!

И если Вы, уважаемый, зациклились на одном Микротике и больше ничего не знаете и не умеете, то хоть помолчите, сойдете за умного!

 

В этом биллинге даже контекстного меню вставить/скопировать нет, о чем можно еще говорить?

 

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

 

В моей схеме привязки к маку нет, он держится только на время аренды адреса, обычно это 5 минут. Вообще привязка к маку говорит о не верном планировании сети. Обычно в таких случаях ее разбивают на сегменты и устанавливают микротики на промежуточных узлах, далее трафик гонят по IP в центр.

Share this post


Link to post
Share on other sites

"Микротик - нищеброд, колхоз

Циска - мажор и труёвый админ"

Не не ... самые умные осваивают микротик... им там есть где себя показать... и есть так сказать коммюнити соответствующее...

остальные или на джунипере или на циске или на ерикосоне.... ну на худой конец на тазике ipoe в accel-ppp прикрутят (неплохо работает к слову и так как надо).

 

Что-то вот только РТК со своим дорогим оборудованием бегает по совим юр. клиентам и умоляет их не подключаться к "колхозу".

ну да ... ну да ... куда там РТК к таким специалистам... так и будут всю жизнь за колхозом в хвосте плестись... только РТК умоляет или еще есть претенденты за колхозом плестись ?

Каждый использует оборудование по фин возможностям.

угу...

Share this post


Link to post
Share on other sites

у вас ip unnumbered?

 

если так его можно назвать в микротике.

и как реализовано?

Share this post


Link to post
Share on other sites

У нас в ядре в качестве BRAS стоит Mikrotik CCR1036-12G-4S, на доступе Mikrotik RB2011/Mikrotik CRS CRS226-24G-2S+IN. Вся сеть routed с редкими участками L2 в режиме legacy. Между всеми микротиками OSPF +MPLS (LDP). До каждого абонента поднят VPLS туннель. Со стороны BRAS на интерфейсе vpls поднят dhcp сервер с пулом в один адрес и лизой в 3 минуты (как у Saab). В каждый vpls тунель в зависимости от запросов абонента смотрят либо реальные адреса с маской 32 (aka ip unnumbered) либо серые адреса с использованием NAT.

При данной схеме можем выдать абонентам 1,2,3,4 и т.д. – сколько угодно реальных адресов, не теряя лишних в отличие от выделения подсетей. Скорость режется через queue tree по IP адресам согласно тарифу, либо если в vpls тунель светим больше 1 адреса, используем simple queue на vpls интерфейс.

Для подключения абонента необходимо прописать несколько команд только на BRAS и микротике, который на доступе. При большом масштабе сети – очень удобно и если сравнить vpls с vlan per user, то отличием будет то,что vpls поднимается двумя командами на конечных PE роутерах MPLS облака и не нужно настраивать промежуточные устройства). При этом промежуточные устройства почти не тратят ресурсы процессора на обработку пакетов, т.к. используется т.н. fastpath mpls в микротиках.

При использовании адресов с маской 32 (unnumbered) включаем proxy-arp, чтобы абоненты с реальными адресами друг друга видели.

Сейчас работаем над интеграцией с биллингом, мучаем интеграторов Carbon Billing чтобы по событиям автоматизировать все.

Пример: в биллинге добавляем микротик доступа, привязываем абонента к порту, указываем BRAS (если их несколько), выдаем абоненту адрес из пула (серый или реальный в зависимости от подключенных услуг)

– и биллинг поднимает vpls туннель, dhcp сервер на vpls интерфейсе, выставляет адрес с 32 маской, бриджует на микротике доступа vpls туннель и физический порт абонента, добавляет адрес абонента в необходимый адрес лист в соответствии с тарифом. По событию отриц баланс – перекидывание в список перенаправления на заглушку с сообщением «пополните счет» и т.д.

Работаем в основном с юр. лицами и данная схема позволяет без проблем предоставлять полноценные L2, L3 vpn с помощью mpls/vpls.

Если кому вдруг интересно, можем приложить схему и примерные конфиги. Опять же, с удовольствием выслушаем критику.

Edited by alor

Share this post


Link to post
Share on other sites

Не не ... самые умные осваивают микротик... им там есть где себя показать... и есть так сказать коммюнити соответствующее...

 

Конкурс на самого умного не объявляли, расслабьтесь.

Share this post


Link to post
Share on other sites

Сейчас работаем над интеграцией с биллингом, мучаем интеграторов Carbon Billing чтобы по событиям автоматизировать все.

Пример: в биллинге добавляем микротик доступа, привязываем абонента к порту, указываем BRAS (если их несколько), выдаем абоненту адрес из пула (серый или реальный в зависимости от подключенных услуг)

– и биллинг поднимает vpls туннель, dhcp сервер на vpls интерфейсе, выставляет адрес с 32 маской, бриджует на микротике доступа vpls туннель и физический порт абонента, добавляет адрес абонента в необходимый адрес лист в соответствии с тарифом. По событию отриц баланс – перекидывание в список перенаправления на заглушку с сообщением «пополните счет» и т.д.

и закончится эта "автоматизированная интеграция" серией костыльных скриптов.....

Share this post


Link to post
Share on other sites

У нас в ядре в качестве BRAS стоит Mikrotik CCR1036-12G-4S, на доступе Mikrotik RB2011/Mikrotik CRS CRS226-24G-2S+IN. Вся сеть routed с редкими участками L2 в режиме legacy. Между всеми микротиками OSPF +MPLS (LDP). До каждого абонента поднят VPLS туннель. Со стороны BRAS на интерфейсе vpls поднят dhcp сервер с пулом в один адрес и лизой в 3 минуты (как у Saab). В каждый vpls тунель в зависимости от запросов абонента смотрят либо реальные адреса с маской 32 (aka ip unnumbered) либо серые адреса с использованием NAT.

 

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

 

Вам проще - доступ только одного типа. Нам же на Carbon Billing требуется обслуживать и PPPoE, и трафик по IP, в последнем случае задействовали галочку OPT 82, т.к. с ее помощью можно сообщать скрипту обработки событий, что нужно отправлять команды на соответствующий роутер для работы с абонентами по IP, если галочка не стоит, отправлять команды для PPPoE. Соответственно в случае работы по IP, в биллинге просто добавляются все роутеры, к которым подключены клиенты, при заведении абонента указывается нужный роутер из списка, ставится галочка OPT 82, указывается адрес абонента и на роутер прилетают необходимые команды. Соответственно блокировка по отрицательному балансу так же на этом роутере, а не в центре.

 

и закончится эта "автоматизированная интеграция" серией костыльных скриптов.....

 

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

Share this post


Link to post
Share on other sites
Гнать все в центр в туннелях не нужно, достаточно на роутерах, к которым подключены абоненты, сразу их же и терминировать. Тогда в центре вообще ничего добавлять не потребуется, кроме ограничения скорости, если оно, конечно, не будет установлено на терминаторах.

 

2 Saab95 - я думаю что у человека не маленький траф, и схема выбрана правильно, потому как в Л3 CRS и 2011 унылое Г.. )) а вот в Л2 еще может поработать.

 

2 alor - очень интересно взглянуть на конфиги

Share this post


Link to post
Share on other sites

Ну схема alor больше для корпоративных пользователей подходит, а для нескольких тыщ хомячков - это повеситься можно )))

Share this post


Link to post
Share on other sites

Ну схема alor больше для корпоративных пользователей подходит, а для нескольких тыщ хомячков - это повеситься можно )))

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

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

Share this post


Link to post
Share on other sites

До каждого абонента поднят VPLS туннель.

И на доступе бриджем с ether портом сделан?

Проц на доступе не жрет?

 

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

Share this post


Link to post
Share on other sites

И на доступе бриджем с ether портом сделан?

Проц на доступе не жрет?

Да, верно. Физический порт абонента бриджуется с vpls интерфейсом. Процессор на доступе не выполняет таких ресурсоемких задач, как обработка таблиц firewall и queues, поэтому - запас по производительности большой. Особенно радует недавно анонсированный Wire-speed static ip routing на моделях CRS.

2 alor - очень интересно взглянуть на конфиги

 

 

Хотел выложить сюда чуть измененные конфиги с описанием, но понял, что лучше, чем данная статья (http://wiki.mikrotik.com/wiki/MPLSVPLS) описать настройку OSPF MPLS LDP не смогу.

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

 

Имеем подсеть реальных адресов 123.4.4.0/24 и хотим выдавать абонентам по одному адресу на vpls интерфейс:

/ip address

add address=123.4.4.1/32 interface=vpls1 network=123.4.4.2

add address=123.4.4.1/32 interface=vpls2 network=123.4.4.3

и т.д.

В настройке vpls интерфейса указываем использовать proxy-arp.

 

DHCP server

/ip pool add name=pool-vpls1 ranges=123.4.4.2

/ip pool add name=pool-vpls2 ranges=123.4.4.3

/ip dhcp-server add address-pool=pool-vpls1 disabled=no interface=vpls1 lease-time=3m name=\

dhcp-vpls1

/ip dhcp-server add address-pool=pool-vpls2 disabled=no interface=vpls2 lease-time=3m name=\

dhcp-vpls2

/ip dhcp-server network add address=123.4.4.0/24 dns-server=123.4.4.1 gateway=\

123.4.4.1 netmask=24

 

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

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

Share this post


Link to post
Share on other sites

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

схема и вправду интересная но ИМХО не для массовых продаж услуги ... т.к. нет стандартных решений по авторизации, нет нормальной совместимости с другими производителями оборудования (речь не про мплс-вплс а о костылях, которые приклеят к биллингу) и т д поэтому микротик в плане ipoe браса (и в такой реализации ) не самое лучшее решение

Share this post


Link to post
Share on other sites

схема и вправду интересная но ИМХО не для массовых продаж услуги ... т.к. нет стандартных решений по авторизации, нет нормальной совместимости с другими производителями оборудования (речь не про мплс-вплс а о костылях, которые приклеят к биллингу) и т д поэтому микротик в плане ipoe браса (и в такой реализации ) не самое лучшее решение

 

3 команды в скрипте биллинга теперь называются костылями?

Share this post


Link to post
Share on other sites

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

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

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

Если нет денег на "взрослый" брас - я бы все таки делал брас на том же accel pptpd + RADIUS (которые так не любит сааб) + простой доступ, от которого требуется только VLAN (которые тоже так не любит сааб).

Вы скажите - в чем разница - скрипты могут и на центральной железке заглючить. Да, могут. Но сравните - мониторить/конфигурить/дебажить/бэкапить/восстанавливать/актуализировать одну железку в центре и сотни/тысячи разного говна по всей сети - это совсем другая разница, как говорят у нас в Одессе ))).

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

Это мнение в качестве альтернативы сааб-религии - для неопределившихся... (Если нет мозга/скила или желания делать на линухе и ли фряшечке - попробуйте хотя бы Vyatta и LEAF : )

P.S. Микротик имеет свою нишу - офисы/радио - но не BRAS и вообще не ISP! (Микротик падает - любая сборка - я гарантирую это, на любом железе - без всякой системы)

(видимо, я просто неправильно настраивал, скажет нам сааб :)

Edited by nobody4097

Share this post


Link to post
Share on other sites

схема и вправду интересная но ИМХО не для массовых продаж услуги ... т.к. нет стандартных решений по авторизации, нет нормальной совместимости с другими производителями оборудования (речь не про мплс-вплс а о костылях, которые приклеят к биллингу) и т д поэтому микротик в плане ipoe браса (и в такой реализации ) не самое лучшее решение

 

3 команды в скрипте биллинга теперь называются костылями?

не-не - это СТАНДАРТ! который абсолютно нормально совместим и поддерживается на железе любого вендора ... накатал студент костыльчик к билингу на свежевыученном языке (поддержка и обслуживание - просто копейки, много есть студентов которые за бутерброд еше один скриптик накатают)... и нет больше проблем - будет работать с чем угодно

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

 

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

 

Его придумали тогда, когда не было доступных железок для L3 доступа. Теперь не нужно все тянуть в центр.

 

Если нет денег на "взрослый" брас - я бы все таки делал брас на том же accel pptpd + RADIUS (которые так не любит сааб) + простой доступ, от которого требуется только VLAN (которые тоже так не любит сааб).

 

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

 

Вы скажите - в чем разница - скрипты могут и на центральной железке заглючить. Да, могут. Но сравните - мониторить/конфигурить/дебажить/бэкапить/восстанавливать/актуализировать одну железку в центре и сотни/тысячи разного говна по всей сети - это совсем другая разница, как говорят у нас в Одессе ))).

 

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

 

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

 

Вы их видимо и не юзаете. Заметьте, вся критика микротика от тех, кто с ним толком и не работал. Зато у всех засели старые стандарты - линукс, консоль, вланы.

 

Это мнение в качестве альтернативы сааб-религии - для неопределившихся... (Если нет мозга/скила или желания делать на линухе и ли фряшечке - попробуйте хотя бы Vyatta и LEAF : )

 

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

 

P.S. Микротик имеет свою нишу - офисы/радио - но не BRAS и вообще не ISP! (Микротик падает - любая сборка - я гарантирую это, на любом железе - без всякой системы)

(видимо, я просто неправильно настраивал, скажет нам сааб :)

 

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

Share this post


Link to post
Share on other sites

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

лол... жгите ещё...

Стоит намного дешевле конкурентов, а по возможностям и производительности обходит на голову.

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

Share this post


Link to post
Share on other sites

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

 

Вот по этому я и писал, что никто ничего не знает про микротик а уже наговаривают. ip unnumbered он поддерживает.

Share this post


Link to post
Share on other sites
Актуализация конфигов не требуется - они типовые на всех устройствах, отличаются только IP адресами. При этом биллинг, прежде чем произвести изменения, сначала удаляет, а потом создает правила, то есть никаких задвоений и т.п. просто быть не может. За много лет работы никогда не было проблем с тем, что биллинг не достучался до удаленного устройства. Ведь если он не отправил команду - она помещается в буфер повторных отправок и выполнится как только связь восстановится.

Это байки из сферической вселенной в вакууме.

 

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

Это байки из сферической вселенной в вакууме.

 

Его придумали тогда, когда не было доступных железок для L3 доступа. Теперь не нужно все тянуть в центр.

Это байки из сферической вселенной в вакууме.

L3 на доступе не нужен.

Вы тогда уже сразу прокси на доступе включите, чо.

 

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

Это байки из сферической вселенной в вакууме.

 

Вы их видимо и не юзаете. Заметьте, вся критика микротика от тех, кто с ним толком и не работал. Зато у всех засели старые стандарты - линукс, консоль, вланы.

Юзал очень плотно в приличных масштабах. И сейчас юзаю. Я перерос микротики. Не знаю, почему вы линукс ругаете. Ваш микротик - это и есть линукс. Только зажатый в жуткие рамки.

Я разочаровался в микротиках. Я их настравиал миллион раз в различных конфигурациях и масштабах. И x86 на широком спектре железа и RB. (некоторые RB приезжали из коробки просто мертвые).

Я сам был влюблен в них (эффект хромой утки). Но их уровень - маленькие сетки (или средние сетки по вашему дизайну на палках и веревках).

 

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

Детский лепет.

Один раз настраиваются данные свичи при проектировании и строительстве сети, делается бэкап конфигов и все. Никаких костылей и скриптов.

 

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

Чушь.

логиниться по сотням говнороутеров и визуально проверять правильность правил - это отстой.

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

 

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

"некие манипуляции" Детский лепет.

Везде нужно произвести некие манипуляции.

Надежность микротик роутеров вызывает у меня сомнения (обжегся пару раз на CCR).

Да и в руках они выглядят как настоящие мыльницы - 100 грам весят.

И толку в 36 ядрах, когда ни фаер ни дерево очередей не параллелиться...

И x86 крашится на средней нагрузке периодически на любом железе и любой версии микротика (ну нет у меня ни одного аптайма больше 100 дней, и у моих знакомых админов)

 

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

Это сферические тесты в вакууме. На реальной конфигурации надежность и производительность просто в 10 раз меньше - если взять тоже железо и запилить туда стабильный дистр линухи и стабильный accel pptpd (либо любые другие варианты - прожевывают в 50 раз больше pps с реальной конфигурацией, шейперами, и сотнями правил в фаере).

 

Сааб - вы во власти своей религии. Вы совсем не хотите признавать недостатки микротов и вашей схемы с L3 доступом, распределенной херней со скриптами. И обсиранием линукса, хотя ваш микрот лишь красивая морда над очень кастрированном и изнасилованном линуксом (чтобы хоть как-то взлетал на говножелезках).

Либо вы реально понимаете проблемы, но скрываете - ибо ничего личного, просто бизнес -> просто вам идет хороший профит от продажи микротов?

 

Впрочем у меня дежа вю - из года в год мы трем одно и тоже )))

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

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

 

Начинающие админы - учите *никс оси, это вам пригодится в любом случае (это вам не мышкой в винбоксе тыкать). Читайте про функции современных коммутаторов, маршрутизаторов, брасов. Рассматривайте альтернативные мнения и дизайны сетей. Микротик - это не золотая пуля. Чудес за 5 копеек и 100 грам веса - не бывает ))))

Edited by nobody4097

Share this post


Link to post
Share on other sites

Сааб - вы во власти своей религии. Вы совсем не хотите признавать недостатки микротов и вашей схемы с L3 доступом, распределенной херней со скриптами. И обсиранием линукса, хотя ваш микрот лишь красивая морда над очень кастрированном и изнасилованном линуксом (чтобы хоть как-то взлетал на говножелезках).

 

У микротика нет недостатков. Особенно учитывая его стоимость.

 

Либо вы реально понимаете проблемы, но скрываете - ибо ничего личного, просто бизнес -> просто вам идет хороший профит от продажи микротов?

 

У микротика нет никаких проблем, все из-за не правильной настройки или не верной схемы построения сети.

 

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

 

Тоже поработал, лучше микротика по всем параметрам пока нет железа.

 

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

 

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

 

Начинающие админы - учите *никс оси, это вам пригодится в любом случае (это вам не мышкой в винбоксе тыкать). Читайте про функции современных коммутаторов, маршрутизаторов, брасов. Рассматривайте альтернативные мнения и дизайны сетей. Микротик - это не золотая пуля. Чудес за 5 копеек и 100 грам веса - не бывает ))))

 

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

Share this post


Link to post
Share on other sites
А глючит все только на линуксах, потому что специалист на микротике пощелкает мышкой и найдет причину, а на линуксе уйдет в консоль на час, потому что у него очень мало инструментов для поиска неполадок.

Утащу, пожалуй, в мемориз.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this