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

Переход с 1036 на chr, перенос профилей pppoe

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

Edited by weedman

Share this post


Link to post
Share on other sites

Не работал с ним никогда, обдумаю, спасибо

 

4 часа назад, VolanD666 сказал:

Ну я б завел, чем 400 учеток хранить на железке.

Не работал с ним никогда, обдумаю, спасибо

 
Edited by weedman

Share this post


Link to post
Share on other sites

В 05.06.2024 в 11:37, VolanD666 сказал:

Ну я б завел, чем 400 учеток хранить на железке.

Радиус нужен для управления большим количеством оборудования. Для резервирования. Например 2 радиус сервера и десятка 2 серверов доступа, тут да, понятно зачем радиус нужен.

 

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

 

Более того, можно статикой держать по 2000+ учеток на каждом микротике, изменять их из биллинга и все.

Share this post


Link to post
Share on other sites

В 07.06.2024 в 02:05, Saab95 сказал:

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

Не нужно мне рассказывать зачем нужен радиус.

 

В 07.06.2024 в 02:05, Saab95 сказал:

Например 2 радиус сервера и десятка 2 серверов доступа, тут да, понятно зачем радиус нужен.

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

 

В 07.06.2024 в 02:05, Saab95 сказал:

Более того, можно статикой держать по 2000+ учеток на каждом микротике, изменять их из биллинга и все.

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

 

В 07.06.2024 в 02:05, Saab95 сказал:

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

Есть смысл. Но видимо в данном случае, радиус- это устаревшая технология? Верно?

Share this post


Link to post
Share on other sites

В 10.06.2024 в 10:17, VolanD666 сказал:

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

Про радиус пишите, а 2000 учеток на оборудовании без бекапа.

 

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

 

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

 

Если взять абонентскую базу даже в 5000 абонентов, то 3500 абонентов вообще не меняются и не создают никакой нагрузки на биллинг, еще 1000 меняют тариф редко или иногда уходят в минус, и только 500 абонентов постоянно при смене месяца блокируются.

 

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

Share this post


Link to post
Share on other sites

В 14.06.2024 в 23:41, Saab95 сказал:

Про радиус пишите, а 2000 учеток на оборудовании без бекапа.

Мне табличку "Сарказм" поднимать надо было?

 

В 14.06.2024 в 23:41, Saab95 сказал:

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

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

 

В 14.06.2024 в 23:41, Saab95 сказал:

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

Ну если биллинг стоит на системнике под столом бухгалтера, то тут согласен- ничего не поделаешь.

Share this post


Link to post
Share on other sites

10 часов назад, VolanD666 сказал:

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

 

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

 

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

 

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

 

10 часов назад, VolanD666 сказал:

Ну если биллинг стоит на системнике под столом бухгалтера, то тут согласен- ничего не поделаешь.

Такое может быть только у мелких провайдеров.

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.