Когда скидываю сессию с помощью монитора в логах
/usr/local/BGR/log/connection.log
Код:
08-06/13:46:22 INFO [Thread-107] connections - [ XXXXXX; test; 67328 ] Killing connection by user request
08-06/13:46:22 INFO [Thread-8] connections - [ XXXXXX; test; 67328 ] sendKillRequest
08-06/13:46:22 INFO [Thread-8] connections - [ XXXXXX; test; 67328 ] SNMP reset request: set 1.3.6.1.4.1.2021.255.1 i 1716
08-06/13:46:24 INFO [XXX.X.X.X_161_null_v1_Trans9] connections - SNMP response [ SNMP1, host=XXX.X.X.X, msg=uk.co.westhawk.snmp.stack.AgentException cannot be cast to uk.co.westhawk.snmp.stack.varbind, recived object=uk.co.westhawk.snmp.stack.AgentException: Timed out ]
08-06/13:46:24 INFO [XXX.X.X.X_161_null_v1_Trans19] connections - SNMP response [ SNMP1, host=XXX.X.X.X, msg=uk.co.westhawk.snmp.stack.AgentException cannot be cast to uk.co.westhawk.snmp.stack.varbind, recived object=uk.co.westhawk.snmp.stack.AgentException: Timed out ]
08-06/13:46:24 INFO [Thread-8] connections - [ XXXXXX; test; 67328 ] sendKillRequest
08-06/13:46:24 INFO [Thread-8] connections - [ XXXXXX; test; 67328 ] SNMP reset request: set 1.3.6.1.4.1.2021.255.1 i 1716
В tcpdump видно что пакеты ходят:
Код:
13:52:17.295949 IP XXX.X.X.X.snmp > YYY.Y.Y.Y.32854: C=SECRET GetResponse(30) .1.3.6.1.4.1.2021.255.10832="2"
13:52:17.519476 IP XXX.X.X.X.snmp > YYY.Y.Y.Y.32854: C=SECRET GetResponse(31) .1.3.6.1.4.1.2021.255.28832=[|snmp]
13:52:17.616004 IP YYY.Y.Y.Y.32854 > XXX.X.X.X.snmp: C=SECRET GetRequest(29) .1.3.6.1.4.1.2021.255.10832
13:52:17.616135 IP YYY.Y.Y.Y.32854 > XXX.X.X.X.snmp: C=SECRET GetRequest(29) .1.3.6.1.4.1.2021.255.13525
13:52:17.616205 IP YYY.Y.Y.Y.32854 > XXX.X.X.X.snmp: C=SECRET GetRequest(30) .1.3.6.1.4.1.2021.255.28832
13:52:17.618817 IP YYY.Y.Y.Y.32854 > XXX.X.X.X.snmp: C=SECRET GetRequest(29) .1.3.6.1.4.1.2021.255.13096
13:52:17.618894 IP YYY.Y.Y.Y.32854 > XXX.X.X.X.snmp: C=SECRET GetRequest(29) .1.3.6.1.4.1.2021.255.12077
13:52:17.619169 IP YYY.Y.Y.Y.32854 > XXX.X.X.X.snmp: C=SECRET GetRequest(30) .1.3.6.1.4.1.2021.255.31290
13:52:17.619209 IP YYY.Y.Y.Y.32854 > XXX.X.X.X.snmp: C=SECRET GetRequest(30) .1.3.6.1.4.1.2021.255.20381
13:52:17.800729 IP XXX.X.X.X.snmp > YYY.Y.Y.Y.32854: C=SECRET GetResponse(31) .1.3.6.1.4.1.2021.255.17683=[|snmp]
13:52:18.029869 IP XXX.X.X.X.snmp > YYY.Y.Y.Y.32854: C=SECRET GetResponse(31) .1.3.6.1.4.1.2021.255.30063=[|snmp]
13:52:18.149033 IP XXX.X.X.X.34438 > YYY.Y.Y.Y.wizard: UDP, length 1464
13:52:18.149227 IP XXX.X.X.X.34438 > YYY.Y.Y.Y.wizard: UDP, length 1464
13:52:18.170364 IP XXX.X.X.X.34438 > YYY.Y.Y.Y.wizard: UDP, length 1464
13:52:18.170512 IP XXX.X.X.X.34438 > YYY.Y.Y.Y.wizard: UDP, length 1464
13:52:18.170635 IP XXX.X.X.X.34438 > YYY.Y.Y.Y.wizard: UDP, length 1464
13:52:18.170756 IP XXX.X.X.X.34438 > YYY.Y.Y.Y.wizard: UDP, length 1464
13:52:18.170879 IP XXX.X.X.X.34438 > YYY.Y.Y.Y.wizard: UDP, length 1464
13:52:18.171002 IP XXX.X.X.X.34438 > YYY.Y.Y.Y.wizard: UDP, length 1464
13:52:18.172708 IP XXX.X.X.X.34438 > YYY.Y.Y.Y.wizard: UDP, length 1128
Во время тестов работало хорошо, как оказалось оно работает когда загрузки нет никакой, т.е. например не более 50 соединений, когда больше 50 соединений то он перестает корректно работать. Соединение рвется со временем через полчаса час, в зависимости от нагрузки. Сервер и NAS (NAS на Linux`e) подключены напрямую каналом 1gb/с.
В логах радиус сервера указанных выше есть строка:
Код:
08-06/13:46:24 INFO [XXX.X.X.X_161_null_v1_Trans9] connections - SNMP response [ SNMP1, host=XXX.X.X.X, msg=uk.co.westhawk.snmp.stack.AgentException cannot be cast to uk.co.westhawk.snmp.stack.varbind, recived object=uk.co.westhawk.snmp.stack.AgentException: Timed out ]
Вопрос почему SNMP1? В конфигах:
NAS:Код:
card.activate.service=0
callback.support=0
month.break=1
nas.inspector.kill.max_messages=10
nas.inspector.sleep_time=10
nas.inspector.snmp.port=161
nas.inspector.snmp.community=SECRET
nas.inspector.snmp.kill.max_messages=5
# IN & OUT буфер в мегабайтах
nas.inspector.snmp.buffer.in=4
nas.inspector.snmp.buffer.out=4
nas.port_time.default.*=XX
nas.port_traffic.default.*=X:COLLECTOR;X:COLLECTOR;X:COLLECTOR;XX:COLLECTOR;XX:MAX(X,X);XX:MAX(X,XX)
#Unix PPP (vendor=2021)
snmp.version=2
pppd.version=2.4.3
nas.inspector.class=bitel.billing.server.processor.SNMPNASConnectionInspectorPPPD
nas.inspector.snmp.kill.oid=1.3.6.1.4.1.2021.255.1
nas.inspector.snmp.check.oid=1.3.6.1.4.1.2021.255
netflow.receive.from=XXX.X.X.X
drop.sleep.timeout=3600
month.break=1
ipn.module.id=XXX
ipn.source.id=XXX
Radius:
Код:
update.time=10
run.sleep=3
dialup.workmode=2
snmp:
Код:
com2sec billing XXX.X.X.X SECRET
com2sec local localhost public
com2sec local XXX.X.X.X SECRET
group groupbill v2c billing
group groupbill v2c local
view all included .1.3.6.1.4.1.2021.255 ff.f0
# context sec.model sec.level prefix read write notify
access groupbill "" v2c noauth prefix all all none
pass .1.3.6.1.4.1.2021.255 /bin/sh /usr/local/utils/passtest.sh
passtest.sh стандартный из мануала...
В это же время перестает считаться время, точнее
время входа = время выхода после закрытия сессии данные о времени записываются в логи. Искал проблему наткнулся в мануале на следующее:
Цитата:
9.4.4. Поведение BGRadiusDialup при критических нагрузках
На порты авторизационных и аккаунтинговых запросов в BGRadiusDialup определён пул потоков-обработчиков размерами, задаваемыми переменными radius.properties auth.thread.count и acct.thread.count соответственно. Каждый пришедший запрос обрабатывается в одном из свободных потоков пула.
По мере роста числа запросов авторизации если число свободных потоков пула станет ниже значения, определённого переменной radius.properties auth.thread.must.be.free.count RADIUS сервер начинает "проглатывать" запросы авторизации без обработки, предотвращая тем самым накопление устаревших запросов в буфере приёма сетевой подсистемы и обрабатывая только самые свежие запросы.
По мере роста числа запросов аккаунтинга если число свободных потоков пула станет ниже значения, определённого переменной radius.properties acct.thread.must.be.free.count RADIUS сервер начинает "проглатывать" Update запросы, оставив оставшиеся потоки для обработки запросов старта и стопа, т.к. они критичнее.
Изменяя параметры количества потоков, следует также изменять количество максимальных активных соединений с базой данных, т.к. ожидание свободного соединения с базой данных блокирует потоки обработки запросов.
похоже на мою проблему в связи с этим попробовал увеличивать:
Код:
auth.thread.count=50
acct.thread.count=50
db.maxIdle=50
db.maxActive=400
не помогло.
Пробовал обновить радиус.. Не помогло, менял версии net-snmp не помогло. Вот radius_status в момент начала глюков:
Код:
version 4.6 build 214 from 23.06.2009 12:38:06
06.08.2009 14:17:55 78 0 78 0
Request accounts per minute start: 0; stop: 1; update: 1
Request auths per minute accept: 0; reject: 0
Netfow packets per minute: 386
Ignore per minute auth: 0; update: 0
Antispam ban count: 0; used per minute: 0
FlowListener: queue_size: 0; threads_active: 0; largest: 8; core: 8; pool_size: 8; recv_socket_buf_size: 131 071; recv_buf_size: 8 388 608; packets: 30682
Started: 06.08.2009 13:20:43 Uptime: 0 d 00:57:11
Memory total: 8 101 888; max: 266 403 840; free: 3 029 080
Trees in cache: 4
Connections pool to Master status Idle: 5; Active: 0; maxActive: 400; maxIdle: 50
Прошу помощи, не знаю уже куда копать, и похоже что узкое место в одном компоненте, а где и кто он, не могу понять...
Я пробовал ставить workmode на UPDATE но в этом случае он вообще не обновлял информацию о трафике и времени, как будто UPDATE пакеты вообще не ходили.. В документации написанно что NAS должен поддерживать UPDATE пакеты, NAS на линуксе поддерживает их? И что нужно сделать для того что бы можно было включить режим UPDATE?
Заранее спасибо
Вход
Регистрация
FAQ
Поиск
UP