BiTel

Если в мониторе модуля ДиалАп разорвать соединения, то этого не происходит.
Сиску настроил по рекомендациям на сайте, да и в инете нашел кое-что. Только меня смушает параметр nas.inspector.snmp.kill.oid=1.3.6.1.4.1.9.9.150.1.1.3.1.5. Может для сиски 7301 нужен другой oid прописать.

Прописывайте как от 53 ей циски, aaa-session-mib.

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

Посмотрите processor.log какие уходят SNMP запросы. Попробуйте отправить их с помощью snmpset. Посмотрите, код сессии в запросе соответствует реальности или нет (сделайте snmpwalk по 1.3.6.1.4.1.9.9.150.1.1.3.1.5).

Странно, но в processor.log нет ничего, кроме процесса загрузки.

Виноват, connection.log

Вот строчка лога
если запустить команду
# snmpwalk -v 2c -c xxxxxx yyy.yyy.yyy.yy 1.3.6.1.4.1.9.9.150.1.1.3.1.5
то выдает
а команда # snmpset -v 2c -c xxxxxx yyy.yyy.yyy.yy 1.3.6.1.4.1.9.9.150.1.1.3.1.5.369 i 1 замечательно сбрасывает соединение.

Дайте соответсвие между значением атрибута Acct-Session-Id и значением oid а ветке 1.3.6.1.4.1.9.9.150.1.1.3.1.5 .

в логе радиуса NAS-Port=378
в логе connection.log SNMP check request: oid 1.3.6.1.4.1.9.9.150.1.1.3.1.5.378
Соответствие полное.
Для команды snmpset я и брал oid из лога

Нашел причину почему не отключает. Вот лог сиски 7301, когда отключение из монитора
А вот лог при отключении с помощью snmpset
У данной команды есть параметр i 1, который и говорит, что нужно отключать. Из монитора он не передается, в логе команда без параметра
Как теперь быть????????

У нас 7301, все нормально работает:

Конфиг циски таков:
http://wiki.bgbilling.ru/index.php/%D0% ... 1%80%D0%B5

почитал форум, у всех в логе connection.log отключение выглядит Есть параметр команды отключение. Почему у меня нет?????????

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

Дайте соответсвие между значением атрибута Acct-Session-Id и значением oid а ветке 1.3.6.1.4.1.9.9.150.1.1.3.1.5 .
Не Nas-Port, а Acct-Session-Id. У циски иногда бывает, что конечный OID является только частью от Acct-Session-Id.
Я думаю, это этот случай.

http://bgbilling.ru/v4.4/doc/ch07s08.html

Здесь все правильно, номер порта правильно определяется. У команды есть параметр i 1, в логах connection.log и логах сиски команда на отключение передается без него.
Если же точно такую же команду отправить ч/з snmpset, но с параметром i 1, то сессия отрубается.

Вы путаете check request - чтение из SNMP ветки с целью определить живость коннекта и kill request - запись в эту же ветку i 1. Для того, чтобы у вас в connection.log пошли kill запросы должна быть причина, например низкий баланс. Ну или сделайте ./radius.sh kill - начнет сбрасывать всех принудительно.

А что тогда происходит, при выборе команды сбросить в мониторе модуля диалап??????????
По моему сессия должна сбрасываться, а у меня происходит то, что описано ранее.

При команде сбросить тоже должен идти kill запрос. Предлагаю для начала выполить ./radius.sh kill. Сброс происходит?

Да, сбросило

Ну получается, команда сброса до радиуса не доходит. Радиус и сервер на одной машине, порт администрирования меняли в radius.properties?

Почему не доходит, если в connection.log появляется команда сброса snmp, но в команде не параметра i 1

Потому что это не команда сброса, а команда проверки живости.

Вообще-то команда 1.3.6.1.4.1.9.9.150.1.1.3.1.5.369 i 1 сбрасавает 369 сессию
Вот описание http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.4.1.9.9.150.1.1.3.1.5

дисконнект происходит при записи туда 1
а если сессии нет то значение не читается ...
что собственно бг и проверяет.
У нас это работает без проблем.

Чтение из ветки 1.3.6.1.4.1.9.9.150.1.1.3.1.5.369 - проверка живости.
Запись в ветку 1.3.6.1.4.1.9.9.150.1.1.3.1.5.369 единицы - сброс.

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

Вот вы уперлись "все должно работать", а между тем отъехали от темы:

Радиус и сервер биллинга стоят на одной машине.

Аналогичный случай:

Система:

[root@billing log]# uname -a
Linux billing.maglan.net 2.6.25.3-18.fc9.x86_64 #1 SMP Tue May 13 04:54:47 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

[root@billing local]# rpm -qa | grep snmp
net-snmp-utils-5.4.1-14.fc9.x86_64
net-snmp-5.4.1-14.fc9.x86_64
net-snmp-libs-5.4.1-14.fc9.x86_64
[root@billing local]# rpm -qa | grep java
java-1.5.0-gcj-1.5.0.0-21.fc9.x86_64
java-1.6.0-openjdk-plugin-1.6.0.0-0.13.b09.fc9.x86_64
java_cup-0.10-0.k.6jpp.2.x86_64
java-1.6.0-openjdk-1.6.0.0-0.13.b09.fc9.x86_64
tzdata-java-2008c-1.fc9.noarch

Сборка bgbilling:

bill вер. 4.4 сборка 88 от 08.09.2008 17:54:06
card вер. 4.4 сборка 54 от 05.09.2008 12:33:51
dba вер. 4.4 сборка 36 от 03.03.2008 14:48:29
dialup вер. 4.4 сборка 56 от 27.09.2008 16:14:05
ipn вер. 4.4 сборка 83 от 27.09.2008 16:13:10
mps вер. 4.4 сборка 48 от 23.07.2008 19:17:14
npay вер. 4.4 сборка 44 от 22.05.2008 15:56:13
reports вер. 4.4 сборка 57 от 10.09.2008 10:40:36
rscm вер. 4.4 сборка 39 от 03.03.2008 14:48:14
ru.bitel.bgbilling.plugins.crm вер. 4.4 сборка 75 от 24.09.2008 01:30:51
ru.bitel.bgbilling.plugins.documents вер. 4.4 сборка 16 от 13.08.2008 17:11:12
trayinfo вер. 4.4 сборка 40 от 05.05.2008 15:22:32
voiceip вер. 4.4 сборка 48 от 26.08.2008 11:14:46

radius connection настроен след. образом:

#настройка snmp
nas.inspector.snmp.port=161
snmp-server community=bgbilling_check
snmp.version=2
nas.inspector.class=bitel.billing.server.processor.SNMPNASConnectionInspectorType3
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.5

Cisco 2821 настроена след. образом

fw-1#sho run | incl snmp
snmp-server community bgbilling_check RW

Соединения авторизуются и устанавливаются:

fw-1#sho user
Line User Host(s) Idle Location
*322 vty 0 root idle 00:00:00 10.0.0.1

Interface User Mode Idle Peer Address
Vi3 danger PPPoVPDN 00:00:04 172.19.22.226
Vi4 danger PPPoVPDN 00:00:04 172.19.29.117

Проверка пользователей проходит:

[root@billing log]# snmpwalk -v 2c -c bgbilling_check 10.39.36.1 1.3.6.1.4.1.9.9.150.1.1.3.1.5
SNMPv2-SMI::enterprises.9.9.150.1.1.3.1.5.1 = INTEGER: 2
SNMPv2-SMI::enterprises.9.9.150.1.1.3.1.5.347 = INTEGER: 2
SNMPv2-SMI::enterprises.9.9.150.1.1.3.1.5.349 = INTEGER: 2

Сброс пользователя (сессия 349) проходит:

[root@billing log]# snmpset -v 2c -c bgbilling_check 10.39.36.1 1.3.6.1.4.1.9.9.150.1.1.3.1.5.349 i 1
SNMPv2-SMI::enterprises.9.9.150.1.1.3.1.5.349 = INTEGER: 1

fw-1#sho user
Line User Host(s) Idle Location
*322 vty 0 root idle 00:00:00 10.0.0.1

Interface User Mode Idle Peer Address
Vi4 danger PPPoVPDN 00:00:07 172.19.29.117

Включена отладка: log4j.logger.connections=ALL, A2

connection.log:

DEBUG 29.09.2008 21:26:52 [ 21; danger; 63542 ] DefaultNASConnection try setting session to KILL
INFO 29.09.2008 21:26:52 [ 21; danger; 63542 ] Set connection to KILL
DEBUG 29.09.2008 21:26:52 [ 21; danger; 63542 ] adding to inspector..
INFO 29.09.2008 21:26:53 [ 21; danger; 63542 ] sendKillRequest
ERROR 29.09.2008 21:26:53 [ 21; danger; 63542 ] SNMP reset ERROR [ SNMP ver.1, host=10.39.36.1, msg=null ]
INFO 29.09.2008 21:26:55 [ 21; danger; 63542 ] sendKillRequest
ERROR 29.09.2008 21:26:55 [ 21; danger; 63542 ] SNMP reset ERROR [ SNMP ver.1, host=10.39.36.1, msg=null ]
INFO 29.09.2008 21:26:57 [ 21; danger; 63542 ] sendKillRequest
ERROR 29.09.2008 21:26:57 [ 21; danger; 63542 ] SNMP reset ERROR [ SNMP ver.1, host=10.39.36.1, msg=null ]
INFO 29.09.2008 21:26:59 [ 21; danger; 63542 ] sendKillRequest
ERROR 29.09.2008 21:26:59 [ 21; danger; 63542 ] SNMP reset ERROR [ SNMP ver.1, host=10.39.36.1, msg=null ]
INFO 29.09.2008 21:27:01 [ 21; danger; 63542 ] sendKillRequest
ERROR 29.09.2008 21:27:01 [ 21; danger; 63542 ] SNMP reset ERROR [ SNMP ver.1, host=10.39.36.1, msg=null ]

Вопрос: почему при tcpdump -i eth0 udp port snmp от radius не уходят пакеты и почему в connection.log запись SNMP reset ERROR и как это лечить?
На голове стоять я уже пробовал.

P.S. Это обычный процесс настройки bgbilling?!?

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