|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (12)
просмотр истории страницы... |
* При управлении оборудованием по ssh или telnet могут возникать проблемы: ssh может работать недостаточно быстро, telnet часто имеет ограничение на одновременное количество сессий{note} |
h2. Еще немного технических деталей Все службы биллинга (radius, rtsh, и тд) формирующие события на отправку добавляют их сначала в таблицу базы данных EVENTS_STACK_COMPACT, указывая при этом основные данные - что сделать (cmd), с какой учтеной записью (user_id), абонентом (abonent_id), на какой NAS отправить команду (nas_ip), при необходимости по какой услуге (usluga_id) и если это события RADIUS - то ID сессии (acct_session_id). [Ядро биллинга|CarbonBilling:Worker (ядро биллинга)] обрабатывает компактный стек, собирая большой набор переменых для передачи скрипту управления и перемещает их в основной стек (EVENTS_STACK). h3. Конструктор отчетов Используемые таблицы: EVENTS_STACK_COMPACT, EVENTS_STACK. Вряд ли Вам потребуется их использовать в конструкторе отчетов, стеки динамические, но это может быть полезно при отладке из командной строки. h3. API Используемые модели: EventsStackCompact, EventsStack. |
h1.Настройка |
... |
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 #* *PARAMS* - набор переменных, передаваемый в скрипт событий |
#* *OWNER_SCRIPT* - подсистема [воркера|CarbonBilling:Worker] [воркера|Worker (ядро биллинга)] добавившая событие в стек |
#* *OWNER_FUNCTION* - функция этой под системы в которой вызвано добавление события в стек #* *NAS_ID* - ID NAS/BRAS |
... |
Например, на 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 минут. |
Если медленней, то: * Попробуйте увеличить количество форков (описано выше в статье) |
... |
* *1375* - ID абонента * event_*1424*.log - название файла, где 1424 - ID учетной записи. |
|
По этим логам можно попробовать диагностировать проблему на конкретном абоненте, что может существенно снизить время поиска решения. |
h1. Кейcы решения проблем или различных задач h2. Как массово отправить команды по абонентам Вам потребуется создать скрипт: * Получите данные абонентов и учетных записей по заданным параметрам [SQL-запросом командой sqlexec|CarbonBilling:Конструктор отчетов] и передайте полученные данные (ID абонентов, учетных записей, IP-адреса и тд) в команду которой управляется оборудование (SSH, RADIUS CoA и тд) * Так же получить данные с sqlexec и передайте их по API создавая объекты в моделе EventsStackCompact, например так: \\ \\ {code}#/bin/bash sqlexec "set list; select id from users u where nas_id=1112" | awk '$2{print $2}' | while read user_id; do curl -XPOST 'http://169.254.80.82:8082/rest_api/v2/EventsStackCompact/' -d 'method1=objects.create&arg1={"user_id": '$user_id',"cmd":"user_redirect_cancel"}' done 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) |