BiTel

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

Access-Request для этих сессий приходит в одно и тоже время, поэтому, как я подозреваю, при приходе Access-Request от второй сессии первой ещё не существует, поэтому он создаёт сразу две сессии.

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

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

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

У обоих сессий при этом состояние "подключено"?

Да, активна и подключено. Логин, реалм, мак, идентификатор, время начала - всё совпадает. Отличаются устройство (как повезёт), IP-адрес и время последней активности.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

В выводе access.sh conlist есть обе сессии?
В логе InetAccess ошибок нет?
authorization.sessionCountCheck в конфигурации модуля не указано?

В выводе "access.sh conlist" есть обе сессии.
В логе только классические "Connection not found with id".
В конфигурации authorization.sessionCountCheck нету, т. к. я не знаю, что это такое и в документации такого нет.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

А сколько активных сессий максимум, примерно?

У абонентов сейчас максимум две одинаковые сессии. Но никто не мешает им настроить роутер так, чтобы было больше сессий.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Я имел ввиду всего сессий в мониторе текущих.

Много, больше ? тыс.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Похоже причина в том, что поток проверки на превышение кол-ва отрабатывает очень редко.

Но на всякий случай посмотрите также, есть ли в логах InetAccess строчки:
SessionCountManager - Session count 2>1. Send connection state modify event.
Перед этой строчкой должен быть вывод сессий. Желательно проверить, что одна из них примерно в это же время была сброшена.

В логах такие строчки присутствуют. Вот времена появления этих строчек в последнем логе:

Соответствующие сессии имеют продолжительность 50 мин, 1 час, 1 час 30 мин (посмотрел всего три).

После этих строк вторая сессия реально отключается. Но после отключения второй сессии приходит Acces-Request, у которого в логах

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

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Кстати, в логах нашёл двойные сессии, которые жили 20 часов.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Что указано в radius.connection.checkDuplicate?
calling-station-id (с номера) у этих сессий разный?

calling-station-id, естественно, одинаковый. К сессиям, где он разный, и вопросов нет.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Попробуйте переключить на новую проверку кол-ва сессий.

Для этого в конфигурации модуля нужно указать А также переместить параметр accounting.deviceTypeIds из inet-access.xml в конфигурацию модуля. Т.е. строчку в inet-access.xml <param name="accounting.deviceTypeIds" value=""/> закомментировать, а значение прописать в конфигурации модуля (это мы рекомендуем делать и в других случаях).

В конфигурации корневого устройства, где прописаны accounting.worker.1.... добавить еще один:

И перезапустить InetAccess и InetAccounting.
Судя по истории все необходимые изменения уже есть в вашем билде.


Что делает authorization.sessionCountCheck=2? Он меняет логику проверки на кол-во сессий. Во-первых, проверка начинает работать независимо для разных типов соединений - это для схем DHCP + IP Subscription, когда у абонента сразу две сессии, одна DHCP и вторая с ASR - раньше нужно было указывать ограничение в две сессии, с этим же режимом нужно указывать ограничение в одну сессию - проверка идет отдельно по кол-ву DHCP-сессий и отдельно по кол-ву RADIUS-сессий (а в будущем - отдельно по кол-ву DHCPv6-сессий).
Во-вторых, проверка текущих активных сессий начинает работать не в InetAccess, а в InetAccounting.
В-третьих, можно указать worker и его параметры - как часто запускается проверка, сколько сервисов Inet проверяет за раз.


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


По поводу же переподключений абонента - попробуйте указать radius.connection.checkDuplicate=5 или radius.connection.checkDuplicate=8

И я должен всё это сделать на живом биллинге??? Шутите?

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Не понял, что - всё. Всего лишь написал как нужно поменять конфиги, чтобы проверяло кол-во сессий чаще. И описал подробнее что именно меняется.
Второй вариант - обновляться на последний билд, там добавили параметры для старого режима проверки кол-ва сессий
connection.sessionCountCheck.batchSize=
connection.sessionCountCheck.delay=
Третий вариант - оставить так как есть.

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

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Обновил биллинг до последней сборки: сессия нормально отключается, пока всё работает замечательно. Параметры

не задавал - настройки по-умолчанию устраивают.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91