BiTel

В модулях Dialup и IPN устройства можно было закрывать датой.
Как поступать при расформировании устройства в модуле Inet?
Удалять, мне кажется, неправильно - ведь на договорах остаются закрытые датой сервисы, привязанные к этому устройству. По ним должна быть возможность получить детализацию flow, например, или radius-логи.
Оставлять тоже некошерно - для устройства создаются разные объекты в памяти в BGInetAccess и BGInetAccounting, например, во FlowAgentInterfaceMap.agentMap.
Логично было бы закрывать датой.

Discuss?

Логично. А еще меня интересует вопрос миграции устройств. Вот было устройство X (коммутатор к примеру), мы меняем его на устройство Y (коммутатор другой модели). Вот как тут поступать?

В смысле, с сохранением IP-адреса?
Тоже интересный вопрос.
А в чём разница для биллинга между этими устройствами? Тип устройства меняется? Конфиги, порты?

Ну поменять тип устройства и достаточно так думаю.

А вот насчет вывода из эксплуатации - тут да, не учтен этот момент. Вариантов 2 сходу вижу
1) Классический период
2) Галка активно/неактивно

В любом случае их не нужно подгружать АА-серверам и еще сделать галку "Показывать неактивные", по умолчанию их не отображать в дереве, а при отображении показывать бледными (зачеркнутыми).

Увы, поменять тип устройства просто так не получается, начинается какая-то опа с интерфейсами

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

2 snark, borisk
А можно поподробнее - что именно в биллинге должно поменяться при замене железки?
У нас, если ставят железку той же модели на то же место с тем же конфигом - биллингу без разницы, ничего не меняется.

Представь, что у тебя:

• Стоял свич на 10 портов, а на его место ты поставил свич на 24 порта - тут еще как-то понятно - на устройстве просто увеличится кол-во портов.
• Стоял свич на 24 порта, а на его место ты поставил свич на 10 портов - что произойдет в этом случае?
  В такой ситуации, по идее, надо закрывать все сервисы с отсутствующих портов, но как себя поведет БГБ пока не ясно.

Ну я бы во втором случае перед заменой перенёс с даты все сервисы с "лишних" портов на другое устройство или порт, затем все эти порты в устройстве пометил статусом "зарезервировано" в свойствах интерфейса с комментарием "недоступно", чтобы нельзя было заводить новые сервисы.
Тут индивидуально надо подходить к замене устройства - я не вижу в биллинге универсального рецепта, т.к. непонятно, что в конкретном случае требуется от BG.

А вот расформирование - вполне очевидная вещь.

Установка нового, замена (причин over 9k) и снятие оборудования - стандартные процедуры, IMHO.

Так а от биллинга что в "стандартном" случае требуется?

На самом деле понятно, что автоматизировать такое не представляется возможным. А вот помочь биллинг в этом случае может. Вводим процедуру "замена оборудования", биллинг открывает два окна, где мы можем переносить сервисы со старого на новое оборудование, изменяя (возможно) какие-то параметры сервисов (например порты)

Такое окно называется скрипт

Мы вот сейчас в IPN перенос делаем с роутера на роутер, так у меня 4 скрипта для этого написано: получение конфига, генерация нового конфига циски, заведение портов и получение их ifindex, заведение диапазонов в биллинге, затем shutdown/no shutdown каждого диапазона с одновременным закрытием старого датой.
Плюс куча подкотовки на самих цисках.
Это всегда индивидуально.


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

И вообще, не угоняйте тему!

Мы тут про расформирование вообще-то.

События же. Поставил/поменял/удалил устройство - лови событие.


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

События полезны для стандартных действий.
У вас каждый день меняются устройства и при этом в биллинге нужно делать кучу типовых операций? Тогда может быть...
Но тут стоит задуматься - может вы что-то неправильно делаете?

У нас при стандартных заменах в биллинге вообще ничего не меняется - просто ставится такое же оборудование с тем же конфигом.

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

Короче, пример приведите, когда это действительно нужно.

Как быть, если замена вроде бы и стандартная, но не совсем? Например раньше были свичи DES-3526, в которых 26 портов, но т.к. они из-за старости порой отправляются в ремонт (БП дохнут), а порой и просто умирают, то на их место ставится DES-1228ME, в последних ревизиях (rev.В) которого 28 портов. Переткнуть порт-в-порт не проблема, что, собственно, и делается, но получается такая ситуация, что мы получаем 2 "лишних" порта. Если оставить тип устройства DES-3526, то вообще ничего, кроме перетыкания, делать не нужно, но если мы хотим использовать эти 2 порта, то тип устройства таки надо менять.
Пример, может быть, и не самый удачный, но это первое что в голову пришло.

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

Короче, я понял: вам нужна групповая операция модуля Inet - "Перенос сервисов между устройствами с даты".
Ну да, это может быть полезно

Я думаю нам всем не помешали бы события "Изменение устр-ва" и "Удаление устр-ва" - тогда можно было что-то скриптами делать.

UP!
Вот мы сняли циску - как её расформировать в Inet?

Сюда же: не могу поставить интерфейсу статус "зарезервирован", если на нём в прошлом были подписчики - пишет:
"Вы не можете зарезервировать интерфейс, т.к. на него есть подписчики", хотя в текущий момент клиентов на нём нет.

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

TODO?
- расформирование устройств
- расформирование интерфейсов устройств

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

плюсану сюда ещё 1 момент
Обработчик управления устройством
http://bgbilling.ru/v6.0/doc/ch18s06s03.html
если устройство недоступно, то отправляется аларм, тоесть его полюбому нада оставить и полюбому нада сделать неактивным так что я за то что выше написал кромешник!!!

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Кстати, да. Как раз сегодня хотел завести свой DeviceManager для cisco, теперь задумался...

и ещё, для группы устройств (папки) чтоб сразу все можно было разформировать

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Насчёт интерфейсов устройств.
Предположим, у нас был интерфейс на циске, скажем Gi0/0.123, с ifIndex=456. На нём в разное время были разные подписчики (сервисы на договоре). Мог меняться ifIndex (при замене самой циски, например). А затем его взяли и расформировали.
Закрыть датой в биллинге я его не могу. Поставить "зарезервирован" - тоже. Но даже если бы и мог "зарезервировать", то на нём останется висеть ifIndex, который может потом пересечься с другими интерфейсами.
Пока для себя вижу один выход - вешать ifIndex=0 на такие с даты расформирования и писать в комментарии "расформирован", чтобы не заводили на нём новых сервисов.
А вообще - разработчикам на заметку. Скорее всего, нужно закрывать датой.

зы. В IPN мы поступали топорно - при изменении в ifIndex устройств запускали скрипт, который удалял все интерфейсы в справочнике, затем получал новые по snmp и создавал их заново с правильными ifIndex. Для всех действующих диапазонов IPN на договорах, у которых сменился ifIndex, делался wrap диапазона на том же договоре со вчерашней даты.
Это работало, поскольку диапазоны к интерфейсам привязываются не по Id биллинга, а по паре sourceId+ifindex (ipn_user_source_<mid>), т.е. даже с удалённым из справочника интерфейсом переобсчёты и т.п. корректно работали.

Сейчас пишу подобный скрипт через SnmpDeviceManager для Inet.

Привязка чего? Netflow? Ну так имя ещё проще поменять вроде.
Проблема скорее в том, что ifIndex выдаётся черным ящиком и не присутствует в конфиге интерфейса, отчего при замене роутера или ребуте без persist он плавает.

Шоб я так помнил, как ты меня спрашиваешь, чего там в ipn к ifIndex привязывают


Дескрипшен - да, меняется без проблем, а вот имя ... interface "Vlan 123" (в snmp это "Vl123") или там "Loopback 123" (в snmp это "Lo123") можно обозвать только так как ящик даст и никак иначе.


Угу. Вот и непонятно мне - зачем вообще привязываться к величинам, которые могут плавать?

Ну это не Бител придумал, если речь об этом.