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

[weedman]

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

Edited June 1, 2024 by weedman

[DeLL]

ключ show-sensitive для 7 версии

[weedman]

1 час назад, DeLL сказал:

ключ show-sensitive для 7 версии

Большое спасибо

[VolanD666]

А почему они у вас не в Радиусе или там их мало?

[weedman]

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

А почему они у вас не в Радиусе или там их мало?

около 400, радиуса нет

[VolanD666]

20 часов назад, weedman сказал:

около 400, радиуса нет

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

[weedman]

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

 

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

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

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

 

Edited June 5, 2024 by weedman

[Saab95]

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

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

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

 

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

 

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

[VolanD666]

В 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 точки отказа, поэтому нет смысла использовать такую схему.

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

[Saab95]

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

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

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

 

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

 

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

 

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

 

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

[VolanD666]

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

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

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

 

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

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

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

 

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

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

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

[Saab95]

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

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

 

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

 

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

 

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

 

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

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

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