Перейти к содержимому
Калькуляторы

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

pptp

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

 

Accel-ppp

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

не верно

Не верно.

 

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

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

 

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

Не обладает.

 

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

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

 

 

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

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

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

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

mikrotik.jpg

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Сюрприз в том, что клиент получит не статический, а динамический адрес?

Это все же лучше, чем ничего.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.