nas_event_daemon

Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (11)

просмотр истории страницы
Используемые таблицы: EVENTS_STACK_COMPACT, EVENTS_STACK.

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

h3. API
root 27122 2.0 0.0 748333 8230 ? SN 15:47 0:00 /usr/bin/python2.7 /usr/local/bin/send_mikrotik_cmd -s 10.0.0.1 carbon carbon /ip firewall address-list remove numbers=192.168.1.10_crb_blocked{code}

Процессы не должны обрабатываться не более 50 секунд. Если Вы наблюдаете эту ситуацию изменении ситуацию, изменение количества форков не окажет положительного влияния. Необходимо решать проблему с обработкой команд со стороны оборудования.

h1. Отладка

h2. Проверьте, запущен ли демон

Выполните команду "ps aux | grep nas_event_daemon" в терминале, вывод должен быть приблизительно следующим:
root 14291 0.0 0.0 103320 920 pts/0 S+ 10:40 0:00 grep nas_event_daemon
{code}
Первая строка "*/bin/bash /usr/local/sbin/nas_event_daemon*" говорит о том, что демон запущен.


h2. Проверьте стек событий на отправку

Узнать количество команд в стеке с группировкой по типу команды можно, выполнив скрипт *event_count.sh*:
{code}chroot /app/asr_billing/ event_count.sh{code}
Вывод будет приблизительно следующий:

Структура таблиц:
# *compact stack* (таблица базы данных EVENTS_STACK_COMPACT) - изначально команды для отправки на оборудование добавляются в compact stack, его наполняют различные подсистемы (radiusd, sync_nasd) базовыми данными по событию, которое нужно отправить на оборудование и обработчик абонентов переносит их в main stack, дополняя нужными данными:
#* *ABONENT_ID* - ID абонента
#* *USER_ID* - ID учетной записи
#* *ABONENT_ID* - ID абонента
#* *USER_ID* - ID учетной записи
#* *EVENT_TYPE* - [Команда для выполнения|CarbonBilling:Состояния пользователей, услуг и команды управления интернет] (то же что CMD в compact stack)
#* *NAS_TYPE* - ID [типа NAS или OSS схемы|CarbonBilling:Интеграция оборудования интернет]
#* *EVENT_DATE* - дата добавления события в main stack
Например, на NAS 1000 абонентов. Сразу после перезагрузки NAS может скопиться до 5000 событий из-за большого количества авторизаций в короткий срок.

Если при выполнении проверки в стеке событий *compact stack* наблюдается большое количество команд и их число не уменьшается (растет) с каждой последующей проверкой, как указано в примере:
{code}# compact stack
COUNT CMD
7774 rad_acc_start
6762 rad_acc_stop
10827 rad_simul
1736 try_double_login
4 user_accept
97 user_add
50 user_del
249 user_rate_set
148 user_redirect_cancel
TOTAL
COUNT
27647{code}

необходимо сделать следующее:
* Проверить текущую нагрузку на биллинге командой top;
* Проверить, что сервер выполнял перезагрузку несколько минут назад, так как после перезагрузки может наблюдаться массовая авторизация абонентов;
* Проверить сервер на соответствие [системным требованиям|CarbonBilling:Системные требования];
* Убедиться, что в последнее время не вносили изменения в настройки NAS и в некоторых случаях проверить, что опция "Не посылать user_disconnect при получении Radius Stop" включена, для предотвращения зацикливания обработки radius-пакетов биллингом, получаемых от NAS.

При скоплении событий в стеке *main stack*, они должны отправляться на оборудование со скоростью около 1000 за 5 минут.
Если медленней, то:
* Попробуйте увеличить количество форков (описано выше в статье)
По этим логам можно попробовать диагностировать проблему на конкретном абоненте, что может существенно снизить время поиска решения.

h1. Кейcы решения проблем или различных задач

h2. Как массово отправить команды по абонентам
Вам потребуется создать скрипт:

exit 0{code}

h2. NAS не инициализирован или не выбрана схема, но назначены абоненты

h3. Как диагностировали:

# Проверили по каким NAS скопились команды
{code:title=Команда}sqlexec "select count(*), nas_id from events_stack group by nas_id order by 1"{code}
{code:title=Вывод} COUNT NAS_ID
============ ============
5 -170000
1513 1127 {code}
# Выяснили что в очереди скопились команды по NAS ID 1127
# Посмотрели в настройки
{code:title=Команда}sqlexec -l "select n.name,uf_ip2string(n.ip),n.OSS_PATHNAME,'',nt.name,'',ns.name,n.nas_scheme_ver from nas n left join nas_scheme ns on n.nas_scheme_id=ns.id left join nas_type nt on n.nas_type=nt.id where n.id=1127"{code}
{code:title=Вывод}NAME MY_NAS
UF_IP2STRING 10.0.0.1
OSS_PATHNAME /var/oss/core/MY_NAS
CONSTANT
NAME <null>
CONSTANT
NAME <null>
NAS_SCHEME_VER <null>{code}
# Оказалось, что не выбран ни тип NAS, ни OSS схема.

Команды не знали куда отправляться, так как nas_event_daemon необходим путь до скрипта управления - он понимает его из настроек NAS в биллинге.

h3. Решение

# В настройках установили OSS схему "*Пользовательская*"
# Перезапустили nas_event_daemon чтобы он подхватил настройки
{code:title=Команда}chroot /app/asr_billing/ service nas_event_daemon restart{code}

h2. NAS инициализирован, но команды копятся в стеке и не передаются на NAS.

h3. Проведение диагностики:

# Проверили по каким NAS скопились команды
{code:title=Команда}sqlexec "select count(*), nas_id from events_stack group by nas_id order by 1"{code}
{code:title=Вывод} COUNT NAS_ID
============ ============
240 1115
273 1114 {code}
# Проверим, для примера, какая команда висит неотправленной для NAS 1114
{code:title=Команда}sqlexec "set list; select first 1 abonent_id, event_type, nas_id from events_stack where NAS_ID=1114"{code}
{code:title=Вывод}
ABONENT_ID 13550
EVENT_TYPE usluga_deactivated
NAS_ID 1114 {code}

h3. Решение
# Необходимо убедиться, что данный абонент не находится в корзине, если удален, в таком случае, в настройках учетной записи удалите NAS и сохраните изменения.
# Если абонент не удален, необходимо проверить доступность этого NAS и его настройки.

h2. Ошибка назначения политики средствами аккаунтинга

h3. Диагностика

# Посмотрели лог учётной записи и обнаружили ошибку:
{code}
2020-05-28 10:06:22 localhost.localdomain session[6084] 367336 1449: user_accept
...
2020-05-28 10:06:22 localhost.localdomain session[6084] 367336 1449: echo 'Cisco-Account-Info="S192.0.2.1.:vrf-id=global", cisco-avpair+="subscriber:service-name=FWPOL_BLOCKED_TRUSTED", cisco-avpair+="subscriber:command=deactivate-service"'
2020-05-28 10:06:22 localhost.localdomain session[6084] 367336 1449: __radclient coa
2020-05-28 10:06:22 localhost.localdomain session[6084] 367336 1449: radclient -c 1 -r 2 -t 1 -x 198.51.100.1:3799 coa servicemode
2020-05-28 10:06:22 localhost.localdomain session[6084] 367336 1449: res='Sending CoA-Request of id 28 to 198.51.100.1 port 3799
Cisco-Account-Info = "S192.0.2.1:vrf-id=global"
Cisco-AVPair += "subscriber:service-name=FWPOL_BLOCKED_TRUSTED"
Cisco-AVPair += "subscriber:command=deactivate-service"
rad_recv: CoA-NAK packet from host 198.51.100.1 port 3799, id=28, length=101
Reply-Message = "Push invoke failed"
Error-Cause = Unsupported-Service
Cisco-Command-Code = "\02057;;FWPOL_BLOCKED_TRUSTED"
Cisco-Account-Info = "S192.0.2.1"'
{code}
# Из лога отправки команд нас интересует строка:
{code}
rad_recv: CoA-NAK packet from host 198.51.100.1 port 3799, id=28, length=101
{code}
# Ответ *CoA-NAK* с Reply-Message "Push invoke failed" означает, что брас не обновил состояние сесии, то есть не удалось назначить политику *FWPOL_BLOCKED_TRUSTED* для сессии *192.0.2.1*.

h3. Решение

Для решения проблемы нужно сравнить настойки оборудования и НАС с настройками [стандартных схем|Стандартные схемы]. Возможно на оборудовании была изменена конфигурация сервисов и политик, либо они не были натсроены вовсе.

h2. На NAS некорректно присваиваются абонентам политики Service

h3. Диагностика

При смене статуса "Разблокирован"/"Заблокирован" в логе nas_event_daemon.log фиксируется ошибка:
{code}
rad_verify: Received CoA-ACK packet from home server 10.10.1.248 port 3799 with invalid signature! (Shared secret is incorrect.)
radclient: no response from server for ID 234 socket 3
{code}

h3. Решение

Необходимо проверить, корректно ли указаны пароли на NAS и в биллинге, в настройках этого NAS, в файле main.ini. (/var/oss/core/_NAS_/main.ini)