BiTel

Привет всем.

Есть странная ситуация. Перешли постепенно с UTM5 на BGbilling т.к. сеть большая установлено около 20 НАСов в отдаленых районах, переводили по районно. Последним был переведен большой район на который работает 2 НАСа Cisco 7206. Клиенты авторизуются, работают, все нормально. Но если для ранее переведенных мы можем выгрузить детализацию трафика по сессии, то для последнего большого района это не работает. Приходит нулевой отчет. Конфигурация настроек аналогичная, netflow на коллектор PPPoE модуля летит, а статистика нулевая.

Подскажите куды копать. И как можно добыть трафик из файлов коллектора IPN.

А скрины с этим насом нетфлоу можно??

_________________

Код:

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

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

Этот конфиг нужен?

числовые коды услуг времени, трафика входящего и исходящего
nas.port_time.default.*=1
nas.port_traffic.default.*=19:COLLECTOR;20:COLLECTOR;22:COLLECTOR;23:COLLECTOR
#интервал между посылками на вышибание клиента
nas.inspector.sleep_time=240
#SNMP порт и пароль
#nas.inspector.snmp.port=161
#nas.inspector.snmp.community=userdrop
#nas.inspector.snmp.kill.max_messages=3
#разрешение активировать все типы карточек на этом NASе
card.activate.service=0
#поддержка CallBack (1-включите)
callback.support=0
#принудительный разрыв соединений на границе месяца
month.break=1
snmp.version=2
nas.inspector.class=bitel.billing.server.processor.PoDNASConnectionInspector
nas.inspector.pod.host=11.111.11.1
nas.inspector.pod.port=1700
nas.inspector.pod.secret=ххххххххххх
nas.inspector.pod.attributes=Acct-Session-Id
#nas.inspector.radius.attributes=User-Name;Framed-IP-Address;Acct-Session-Id
#nas.inspector.class=bitel.billing.server.processor.SNMPNASConnectionInspectorCisco
#nas.inspector.snmp.kill.oid=1.3.6.1.4.1.9.9.150.1.1.3.1.5
#nas.inspector.snmp.check.oid=1.3.6.1.4.1.9.9.150.1.1.3.1.2
#nas.inspector.snmp.drop.sleep.timeout=3600
#интервал между посылками на проверку либо сброс соединения в секундах
#nas.inspector.sleep_time=60
#Fake-пул для заблокированных пользователей
nas.pools.inetoff=10.20.0.1-10.20.0.254
#максимальное число попыток сброса соединения
#nas.inspector.kill.max_messages=5
drop.sleep.timeout=3600
netflow.receive.from=11.111.11.1
#session.mode=hex4
ipn.module.id=2
ipn.source.id=3

Выяснил один свой косяк, один из НАСов имел не настроеное NTP и стояла левая дата-время - 2002 год. В логах было как раз похоже на нее. Сейчас выставим дату-время и поглядим результат.

а) этот источник точно есть? т.е. он netflow шлет?

б) в netflow_ipn.properties

в "<список>" помимо прочих источникво источник с id-м 3 есть? попросту говоря - цифра 3 там есть?

в) коллектор после изменения "<список>" п. "в" перегружали?

Все есть. В общем дело было все таки в дате на НАСе. Внутре flow пакетов стояла неправильная дата, они складывались в правильные архивы из которых детализация выбиралась по правильной дате, а ее и не было. Видимо когда сессия на НАСе с настроенным временем, я бы увидел детализацию, а когда на втором ее и не было.

В общем сейчас все работает, всем спасибо.