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

Проблемы c BRAS Mikrotik CCR1036 потери пакетов

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

Share this post


Link to post
Share on other sites

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

а кто спорит что надо :) просто оно есть и работает, причём по моему мнению работает нормально. какая разница какой тип авторизации - если услуга предоставляется стабильно абоненту пофиг на это

Share this post


Link to post
Share on other sites

Вовсе не пофиг.

1. Абонент чайник: в случае IPoE он просто любой роутер втыкает, жмёт ресет и оно работает.

2. Абоне не чайник: нет секса с настройкой, нет проблем с тем что некоторые роутеры до сих пор не умеют дуал аксес.

 

Я уже молчу про отсутствие просадок производительности, просадку мту и прочее.

Меня уже тошнит от того что PPP приходится почти везде поднимать.

Share this post


Link to post
Share on other sites

Возвращаясь к теме, хотел бы узнать как устранить, один неприятный недостаток в реализации, когда шейпер PCQ и микротику посылают атрибут Mikrotik-Address-List со значением к примеру 12345k, так как 12345k на микротике нет именованного адреса в /ip firewall address-list, то клиент получает всю ширину канала .

Share this post


Link to post
Share on other sites

Возвращаясь к теме, хотел бы узнать как устранить, один неприятный недостаток в реализации, когда шейпер PCQ и микротику посылают атрибут Mikrotik-Address-List со значением к примеру 12345k, так как 12345k на микротике нет именованного адреса в /ip firewall address-list, то клиент получает всю ширину канала .

 

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

Share this post


Link to post
Share on other sites

Скорее, микротик не предназначен для доступа абонентов в сеть через PPTP :)

 

А как именно сносило? у нас есть пара /24 сеток с пптп, всё никак руки не доходят убить их возьни много, древнее это всё.

Share this post


Link to post
Share on other sites

В микротике PPTP в юзерспейсе. Из-за чего тормозной и жручий.

Share this post


Link to post
Share on other sites

В микротике PPTP в юзерспейсе. Из-за чего тормозной и жручий.

 

На данный момент согласен, пришлось микротики подальше выбросить, вернулся на Accel-ppp

pptp

Микротик CCR1036-12G - максимум 500 сессий тянет, после через сам перезагружается, тарифные скорости это от 2мбит до 15мбит, cpu доходит до 85%

 

Accel-ppp

CentOS 6, 4 ведра по 1200мгц

500 сессий, нагрузка на CPU примерно 5-10%, это все при NAT+шейпер+Netflow

Share this post


Link to post
Share on other sites

как так...имею тот же микротик, 400+ активных сессий pppoe + nat, simple queue на каждого, дневные/ночные тарифы по расписанию, некоторые ограничения для торрента, трифы 5-40 мбит, загрузка 2-3% в час пики

Share this post


Link to post
Share on other sites

как так...имею тот же микротик, 400+ активных сессий pppoe + nat, simple queue на каждого, дневные/ночные тарифы по расписанию, некоторые ограничения для торрента, трифы 5-40 мбит, загрузка 2-3% в час пики

Про pptp разговор был.

Share this post


Link to post
Share on other sites

Про pptp разговор был.

 

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

Share this post


Link to post
Share on other sites

Правильно настроить оборудование, сделать правильный дизайн сети.

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

 

Правильное оборудование, дизайн сети и технологии это какие?

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

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites

Правильно настроить оборудование, сделать правильный дизайн сети.

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

 

Правильное оборудование, дизайн сети и технологии это какие?

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

 

А в чём проблема выгружать, например раз в час, скриптом ppp secrets disable=yes. Нагрузка нулевая и себе же спокойнее.

Share this post


Link to post
Share on other sites

не верно

Не верно.

 

накладно по ресурсам

Бессмысленно.

 

не обладает повышенной отказоустойчивостью

Не обладает.

 

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

Я такую ситуацию нормальной не считаю.

 

 

А в чём проблема выгружать, например раз в час, скриптом ppp secrets disable=yes.

Проблема не в том, как выгружать.

Мне казалось, что это очевидно.

Это выглядит примерно так:

mikrotik.jpg

 

Кроме того, биллинг — это не только логины и пароли.

Биллинг это также деньги, тарифы и управление услугами.

Share this post


Link to post
Share on other sites

Кроме того, биллинг — это не только логины и пароли.

Биллинг это также деньги, тарифы и управление услугами.

 

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

Share this post


Link to post
Share on other sites

Для таких случаев нормальные BRAS могут давать какие-нибудь N мегабит в каждые руки, если биллинг/радиус не отвечают.

Share this post


Link to post
Share on other sites

Для таких случаев нормальные BRAS могут давать какие-нибудь N мегабит в каждые руки, если биллинг/радиус не отвечают.

 

в этом топике вроде как речь о МТ в роли BRAS

Share this post


Link to post
Share on other sites

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

Я такую ситуацию нормальной не считаю.

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

В случае проведения профилактики на биллинге

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

Тогда и резервный RADIUS не потребуется.

Share this post


Link to post
Share on other sites

Нахрен это все тянуть на BRAS?

Наверное потому, что в сетях с микротиком сервер - он один, причем где-то в кладовке :)

Share this post


Link to post
Share on other sites

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

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

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