BiTel

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

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

ап

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

В рандомной энтропии БГБ порядок невозможен

а какой нужен порядок?

1. Адреса должны выдаваться последовательно, с 1-го по последний.
   
2. БГБ должен освобождать динамически выданный IP адрес, в случае если этот IP адрес выдан как статический.
   
   1. По дефолту мы всем выдаем из одного большого пула;
   2. Когда клиент приходит и просит статический адрес - мы не меняя пула выдаем ему 1-й свободный адрес с начала пула;
   3. Если этот адрес занят абонентом как динамический - БГБ "сбрасывает" (сбрасывает/отказывает в продлении аренды) этого пользователя и выдает этот адрес тому, кому мы указали его как статический.

Зачем весь этот геморрой?
Дело в том, что IP адреса сейчас очень ценный ресурс и просто так дробить сети выделяя адреса на "для статики" и "для динамики" - это, мягко говоря, расточительно.
Например, если мы имея сетку /23 разбиваем ее на 2 сетки /24 (одну для статики, другую для динамики), но при этом у нас статикой выдано 3 адреса, а динамикой выдано 240 адресов. Это "сейчас", а сколько понадобится "завтра" не известно, т.е. "завтра" нам может понадобится 20 или 60 статических адресов и 260 или 300 динамических адресов. Что делать? Каждый раз резать сети и менять пулы?

snark аж плюс влупил, все по делу и верно, именно по этому и озаботились

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

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

Есть.

Вот этого вроде бы пока нет.

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


Надо бы, а то мы запросто можем попасть примерно в такую ситуацию

• "Вася" сидит в инете и ему выдан адрес 1.1.1.1
• "Петя" тоже сидит в инете и ему выдан адрес 1.1.1.2
• Петя говорит: "хочу статический адрес!" - мы прописываем ему адрес 1.1.1.1
• БГБ скидывает Петю, тем самым освобождая адрес 1.1.1.2 и выдает ему адрес 1.1.1.1
• Прилетает "апдейт" (RADIUS апдейт/netflow/т.д.) с трафиками для адреса 1.1.1.1 и БГБ видя 2 одинаковые сессии сначала думает: "ЙОПТ! ТЫКТОА?!", а потом такой: "да пох! запишу обоим, а то чет посоны расслабились там"

После чего мы сидим, смотрим на растущие счетчики трафика и понимаем, что нас ждет восхитительный секс, вот только девки на лабутенах нах и в о#уительных штанах тут совсем ни при чем.

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

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

_________________
Клиент: вер. 7.2.198 / 19.08.2019 19:30:12
Сервер: вер. 7.2.1061 / 19.08.2019 19:32:26
card: вер. 7.2.201 / 24.07.2019 03:56:11
dialup: вер. 7.2.303 / 04.07.2019 17:11:44
inet: вер. 7.2.639 / 19.08.2019 19:32:59
ipn: вер. 7.2.232 / 19.08.2019 19:32:53
mps: вер. 7.2.177 / 08.08.2019 16:32:31
npay: вер. 7.2.174 / 25.07.2019 19:48:57
phone: вер. 7.2.260 / 08.08.2019 16:32:32
reports: вер. 7.2.203 / 12.08.2019 21:56:13
trayinfo: вер. 7.2.160 / 25.06.2019 16:47:08
voice: вер. 7.2.63 / 19.08.2019 19:33:01
voiceip: вер. 7.2.176 / 25.06.2019 16:46:56

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

У вас другая проблема. Так не должно быть. Это надо у вас разбираться на месте.

Может и у нас другая проблема? В логах у тех у кого выданы статические адреса при разрыве пишет

За сутки бывает примерно по 5 разрывов у всех кому выданы статические адреса. У тех у кого динамика разрывов нет. Статику выдаем из того же пула, что и динамика.

_________________
Клиент: вер. 7.2.198 / 19.08.2019 19:30:12
Сервер: вер. 7.2.1061 / 19.08.2019 19:32:26
card: вер. 7.2.201 / 24.07.2019 03:56:11
dialup: вер. 7.2.303 / 04.07.2019 17:11:44
inet: вер. 7.2.639 / 19.08.2019 19:32:59
ipn: вер. 7.2.232 / 19.08.2019 19:32:53
mps: вер. 7.2.177 / 08.08.2019 16:32:31
npay: вер. 7.2.174 / 25.07.2019 19:48:57
phone: вер. 7.2.260 / 08.08.2019 16:32:32
reports: вер. 7.2.203 / 12.08.2019 21:56:13
trayinfo: вер. 7.2.160 / 25.06.2019 16:47:08
voice: вер. 7.2.63 / 19.08.2019 19:33:01
voiceip: вер. 7.2.176 / 25.06.2019 16:46:56