Основные этапы обработки отказа:

Сбор общей информации о неисправности

Устранение любого отказа следует начинать со сбора информации. Источниками информации об отказе, могут быть:

  1. Сообщения о предупреждениях (по e-mail, jabber, sms);
  2. Панель предупреждений (приложение Список предупреждений (Alarm list) в web-интерфейсе или вывод команды /cluster/mediator/md1/alarms/list);
    Подробнее см. Просмотр текущих предупреждений в системе, Примеры предупреждений и способы их решения;
  3. Жалобы и замечания клиентов;
    При получение жалоб и замечаний от абонента, следует получить максимально подробную информацию о проблеме: Алгоритм сбора информации от абонента;
  4. Аварийные и информационные сообщения на взаимодействующих устройствах и системах (шлюзы, SBC, Softswitch);
  5. Статистика предоставленных услуг;
  6. Статистика потребляемых ресурсов.

Первые два источника информации являются более достоверными. Источники 4, 5, и 6 являются косвенными источниками информации о неисправности.

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

Источник "Панель предупреждений" является наиболее достоверным и предоставляет следующую информацию:

  • уникальный идентификатор предупреждения (id);
  • дата и время возникновения предупреждения (date);
  • уровень важности предупреждения (severity);
  • класс предупреждения (class);
  • тип предупреждения (type);
  • местоположение подсистемы, которая сгенерировала предупреждение (location);
  • сообщение о предупреждения (message).

Подробнее в разделе Описание структуры предупреждения.

Классификация неисправности

По уровню важности предупреждения делятся на:

  • критическое предупреждения (critical);
  • важный уровень предупреждения (major);
  • незначительный уровень предупреждения (minor);
  • оповещение (warning);
  • уровень предупреждения не определен (indeterminate);
  • предупреждение сброшено (cleared).

По типу предупреждения делятся на:

  • предупреждения, связанные с коммуникациями (communicationsAlarm);
  • предупреждения, связанные с качеством сервиса (qualityOfServiceAlarm);
  • предупреждения, связанные с обработкой (processingErrorAlarm);
  • предупреждения, связанные с оборудованием (equipmentAlarm);
  • предупреждения, связанные с окружением (environmentalAlarm);
  • предупреждения, связанные с неконсистентной информацией (integrityViolation);
  • предупреждения, связанные с некорректной работой (operationalViolation);
  • предупреждения, связанные с физическими нарушениями (например, выход оборудования из строя) (physicalViolation);
  • предупреждения, связанные с безопасностью (например, несанкционированный доступ) (securityServiceOrMechanismViolation);
  • предупреждения, связанные с возникновением несвоевременных или запрещенных событий (timeDomainViolation);
  • другая (не отнесена к выше перечисленным) (other).

Локализация неисправности

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

  • Плечо А — содержит участок сети от вызывающего абонента (далее абонента А) до системы ECSS-10; ПО шлюза или телефона <--> сетевой стек оп. системы <--> линия связи <--> сетевой стек оп. системы <--> протокол адаптер ECSS (pa-sip, megaco)
  • Ядро системы ECSS-10 и Media Server. Ядро содержит сервисы управляющие логикой обработки вызова, медиасервер — выполняет функции трансляции, транскодирования, записи и смешивания медиа-трафика.
  • Плечо Б — содержит участок сети от системы ECSS-10 до вызываемого абонента (далее абонента Б);

Протокол адаптер ECSS (pa-sip, megaco);Далее приведены примеры определения причины отказа на участках прохождения вызова касающихся системы ECSS-10:В случае если об отказе нет записи в панели предупреждений, локализацию неисправности следует производить методом последовательной проверки всех участков прохождения вызовов.Протокол адаптер ECSS (pa-sip, megaco) <--> сетевой стек оп. системы <--> линия связи <--> сетевой стек оп. системы <--> ПО шлюза или телефона

  • Ядро ECSS-10;
  • Media Server.

При локализации проблемы необходимо учитывать следующие ситуации:

  • Проблема возникла на новом направлении. Если направление новое, необходимо проверить маршрутизацию, регистрацию и авторизацию абонентов;
  • Проблема возникла на ранее созданном направлении (проверенном, работающем). Если направление было введено в работу ранее, протестировано и успешно работало, вероятно, что существуют проблемы с транспортной сетью между системой ECSS-10 и взаимодействующим шлюзом, либо проблема во взаимодействующем устройстве.

Сбор детальной информации об отказе (log-файлы, трассировки, дампы)

Набор требуемой детальной информации зависит от шага Локализация неисправности. Так например, если отказ был локализован в ядре ECSS-10, то дополнительно необходимо будет снять log-файлы ядра необходимых сервисов. Список log-файлов, которые необходимо снять, сообщат сотрудники сервисного центра (См. Включение и отключение систем логирования служб).

Алгоритм проверки в случае непрохождения вызова:

  1. Проверить все ли сервисы ECSS-10 запущены (sudo systemctl status <service_name>)  (См. Проверка статуса сервисов);
  2. Проверить прослушивает ли ECSS необходимые порты (sudo netstat) (См. Проверка открытых портов);
  3. Проверить доступность взаимодействующих элементов, шлюзов, телефонов, других softswitch(ping) (См. Проверка доступности направлений А и Б);
  4. Если пункты 1-3 не выявили неисправности, следует сделать тестовый вызов с включенными трассировками (внешними и внутренними) (См. Снятие трассировок ядра, Снятие дампа сетевого трафика);
  5. Снятие log-файлов ядра и протокол адаптеров или других нод по требованию сервисного центра (См. Включение и отключение систем логирования служб).

Определение причины отказа

Локализировав отказ и собрав необходимую информацию (log-файлы, трассировки, дампы) возможно определить причину неисправности. Если квалификации персонала обслуживающего ECSS-10 недостаточно, то полученные сведения необходимо передать для анализа в сервисный центр.

Устранение отказа

Устранить отказ можно после того как выполнен пункт Определение причины отказа.
Для проверки действий по устранению отказа можно использовать:

  • Проверочные вызовы;
  • Нагрузочное тестирование.

Если отказ не был устранён, то следует повторно выполнить этапы 3, 4, 5.

Инструкции

Просмотр текущих предупреждений в системе

Первым этапом анализа проблем является просмотр активных предупреждений в системе ECSS-10.

Для оперативной реакции обслуживающего персонала на возникшие предупреждения реализован следующий функционал: при возникновении аварий (major и/или critical) prompt в консоли CoCon-а будет подсвечиваться в желтый (major) или красный (critical) цвет:

Когда все major и critical аварии будут зачищены — отобразится надпись No more active alarms", и Prompt примет обычный цвет.

Prompt поменяет цвет только при следующей отрисовке (по факту, когда будет нажат Enter).

В web-конфигураторе также есть панель "Системная информация":

Она не закрывается, не скрывается (хотя и может быть перекрыта другим окном). Кроме того, на web в случае возникновении аварии звучит аварийная сигнализация. В стандартном режиме web-конфигуратора в футтере есть информация об авариях в системе.

Просмотреть список предупреждений можно через интерфейс командной строки CLI или web-конфигуратор. В web-конфигураторе список приводится в приложении Список предупреждений (Alarm list).

Список текущих предупреждений в командной консоли CLI отображается при помощи следующих команд:

  • /system-status — информация о состоянии нод, медиасерверов и список активных аварий;
  • /cluster/mediator/<CLUSTER>/alarms/list all — просмотр всех предупреждений в системе. Команда доступна администратору системы ECSS-10.
  • /domain/<DOMAIN>/alarms/list all  — просмотр предупреждения виртуальной АТС с именем <DOMAIN>. Команда доступна администратору виртуальной АТС.

где:

  • <CLUSTER> — имя ноды MEDIATOR, для которой выполняется команда;
  • <DOMAIN> — имя виртуальной АТС.
По умолчанию выводится 25 последних предупреждений.

Подробное описание команд CLI системы сбора и отображения предупреждений приведено в разделе Команды управления аварийной сигнализацией.

Для просмотра описания по сбору и отображению предупреждений можно подключиться к командной консоли управления операционной системы CoCon и воспользоваться командой man:

man cluster/mediator/md1/alarms/list all
man domain/<DOMAIN>/alarms/list all

Описание предупреждений и действий, необходимых для решения, приведены в разделе Действия при возникновении предупреждений.

Примеры предупреждений и способы их решения

Предупреждение "Application "slapd" is not running"

DateSeverityCauseClassInstanceMessage
21.12 14:09:11
critical
softwareError
host::applicati
slapd
Application "slapd" is not running

Данное предупреждение обозначает, что приложение slapd не запущено. В базе данных LDAP хранится информация о логинах и паролях SIP-абонентов ECSS-10. Из-за данной проблемы будет невозможна авторизация SIP-абонентов

Решение:

Указанные команды выполняются из командной консоли управления операционной системы Linux (shell).

Запустить приложение slapd командой:

sudo systemctl start slapd.service

Просмотреть состояние работы приложения slapd командой:

sudo ps aux | grep slapd
sudo systemctl status slapd.service

Если приложение slapd снова завершит свою работу, то необходимо обратиться за помощью в сервисный центр (СЦ) компании Элтекс.

Предупреждение "Network interface "bond1:2" is down"

Date
Severity
Cause
Class
Instance
Message
21.12 20:06:13
critical
lanError
hw::interfaces
bond1:2
Network interface "bond1:2" is down

Авария сетевого интерфейса bond1:2 является критической. Если данный интерфейс используется для работы VoIP-телефонии и в системе нет резервных интерфейсов, то система ECSS-10 не сможет обслуживать вызовы.

Все SIP-направления и абоненты не смогут совершать вызовы.

Решение:

Указанные команды выполняются из командной консоли управления операционной системы Linux (shell).

  • Система с резервированием:
    Произведите перезапуск службы keepalived командами:

    sudo systemctl stop keepalived.service
sudo systemctl start keepalived.service

    Проверить:

    sudo systemctl status keepalived.service

  • Система без резервирования:
    Произведите перезапуск сетевой службы командами:

    sudo systemctl restart systemd-networkd.service

Log-файл работы сетевой службы хранится в файле syslog. Путь к файлу: /var/log/syslog.

Предупреждение "Node core1@ecss1 of "core1" cluster is down"

Date
Severity
Cause
Class
Instance
Message
21.12 20:41:44
major
outOfService
ecss::cluster::node
core1@ecss1
Node core1@ecss1 of "core1" cluster is down

Предупреждение о падении ноды является критической аварией. Если система без резервирования и нет возможности перезапустить приложение, система ECSS-10 не сможет оказывать услуги.

Решение:

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

  1. Нужно проверить статус работы ноды командной (команда выполняется через интерфейс командной строки CLI):

    /node/<NODE>/service

    где <NODE> — имя ноды.

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

    Если напротив всех служб стоит символ “+” перейдите к пункту С.

  2. Запустить ноды в ручном режиме можно при помощи команды (команда выполняется в shell linux):

    sudo systemctl start ecss-<node_name>

  3. Для поиска причины аварийного завершения работы приложения и устранения проблем нужно передать log-файл работы ноды в сервис-центр компании ЭЛТЕКС.

Предупреждение "Response 500 Server error"

Date
Severity
Cause
Class
Instance
Message
29.04 15:09:26
major
softwareError
ecss::pa::sip::
temp_voip-rsw-med
Response 500 Server error

Завершение обслуживания вызова, выдача ответа 500 от SIP-адаптера.

Предупреждение может возникнуть вследствие причин:

  • нестандартный формат, поле и значение параметра в SIP-сообщении;
  • нестандартный алгоритм обмена сообщениями;
  • ошибка в работе приложений;
  • транзит 500 сообщения от встречной стороны.

Решение:
В данной ситуации необходимо снять TCP dump, core cp лог, лог SIP-адаптера и ядра. Передать данную информацию для разбора причины проблемы в сервис-центре компании ЭЛТЕКС.

Предупреждение "Call process down. Reason: anormal_termnate"

Date
Severity
Cause
Class
Instance
Message
28.08 17:55:28
major
softwareError
ecss::cluster::core::cp 
pa.sip-t->32343034-6338-3531-3437-623761663333
Call process down. Reason: anormal_terminate

Не штатное завершение вызова.

Предупреждение может возникнуть вследствие следующих причин:

  • нестандартный формат, поле и значение параметра в SIP-сообщении;
  • нестандартный алгоритм обмена сообщениями;
  • ошибка в работе приложений;
  • прочие.

В данной ситуации необходимо снять TCP dump, core cp лог, лог SIP-адаптера и ядра. Передать данную информацию для разбора причины проблемы в сервис-центре компании ЭЛТЕКС.

Предупреждение "Wrong authentication"

Date
Severity
Cause
Class
Instance
Message
24.04 10:07:59
major
softwareError
ecss::pa::sip::
8612001057@krasno
Wrong authentication

Попытка аутентификации завершилась неудачно.

Предупреждение может возникнуть вследствие причин:

  • настроен неверный логин и пароль у SIP-абонента;
  • имеет место быть попытка взлома учетной записи SIP-абонента.

Решение:
В данной ситуации необходимо сравнить настройки SIP-абонента и учетной записи клиента в ECSS-10. Если попытки зарегистрироваться выполняются от неизвестного пользователя, необходимо предпринять меры для ограничения данного злоумышленника к SIP-адаптеру.
Возможные действия:

  • добавить IP-адрес в черный список fail2ban на SBC;
  • добавить правило на удаление трафика, поступающего с IP-адреса злоумышленника в iptables на SBC;
  • добавить правило на удаление трафика, поступающего с IP-адреса злоумышленника в iptables в системе ECSS-10.

Предупреждение "Disk almost full: 97 %"

Date
Severity
Cause
Class
Instance
Message
20.08 17:20:00
major
storageCapacityProblem 
HW::Disks
/var/log/ecss
Disk almost full: 97 %

Переполнен раздел с логами ECSS-10.

Решение:

Необходимо удалить отладочную информацию в разделе /var/log/ecss/.

Предупреждение "The licence "lab_303 (2012/09/19 01:34:50)" will be expired at 2013/02/01 02:02:02."

Date
Severity
Cause
Class
Instance
Message
02.01 09:09:35
warning
outOfService
ecss::licence
lab_303 (2012/09/19 01:34:50)
The licence "lab_303 (2012/09/19 01:34:50)" will be expired at 2013/02/01 02:02:02.

Лицензия ECSS-10 истекает 2013/02/01, после истечения срока действия система перейдет на лицензии с активным сроком или на заводскую лицензию.

В заводской лицензии максимальная длительность вызова ровна одной минуте, отключена запись CDR-файлов и функция СОРМ, база данных останавливается через каждые 5 минут.

Для продления лицензии необходимо обратиться в коммерческий отдел компании ЭЛТЕКС и проинсталлировать новые лицензии. Подробное описание приведено в разделе Начальное конфигурирование системы.

Алгоритм сбора информации от абонента

При получении жалоб от абонентов системы ECSS-10 необходимо получить от них следующую информацию:

  1. Номер вызывающего абонента;
  2. Номер вызываемого абонента;
    По данной информации определить к какому шлюзу подключен абонент, проверить работу шлюза. Если абонент использует SIP телефон или софтфон — определить модель (в таком случае возможно проблема на стороне абонента).
  3. Точное время, дату вызова или интервал времени;
    По данной информации можно получить трассировку вызова, если она была включена и не удалена по исчерпанию лимита на количества трассировок.
  4. Повторяется ли проблема на телефонные номера;
  5. Если вызов не проходит только на определенные номера, узнать список номеров на которые не проходит вызов. Исходя из данной информации по плану маршрутизации определить исходящий транк;
  6. Выяснить в какое время не проходят вызовы: в любое время или в определенные часы. Если в определенные часы — проверить маршрутизацию по времени.

Включение и отключение систем логирования служб

В системе ECSS-10 каждая нода имеет в своём составе определенный набор служб, ответственных за те или иные процессы. Также имеет набор заранее определенных правил, которые определяют в каком виде записывать log-файлы и для отдельных служб. Большинство правил по умолчанию отключено, так как в не аварийном состоянии системы они не нужны. В процессе определения причины отказа может потребоваться включить те или иные правила.

где:

  • <node_name> — имя ноды (сообщат сотрудники СЦ); 
  • <rule_name> — имя правила (сообщат сотрудники СЦ).
Существуют правила с постфиксом _bin, что означает что запись будет вестись в бинарном формате, перекодировать в текстовый можно с помощью утилиты binarylog2text.

  • После активации, соответствующий этому правилу файл будет наполнятся записями, и находится он по следующему пути:

    /var/log/ecss/<node_name>/<date>/<rule_name>

  • Деактивация правила выполняется командой:

    node/<node_name>/log/config rule <rule_name> off

  • Просмотр статуса и настроек правил логирования для определенной ноды:

    node/<node_name>/log/config show

В первом столбце указано состояние правила: "+" — правило включено, "-" — правило выключено.

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

Проверка статуса сервисов

Проверить запущены ли все сервисы ECSS-10 можно командой:

sudo systemctl status <service name>

где <service name> может принимать следующие значения:

  • ecss-autoprovision-core.service
  • ecss-autoprovision-ui.service
  • ecss-core.service
  • ecss-mediator.service
  • ecss-restfs.service
  • ecss-ds.service
  • ecss-mycelium.service
  • ecss-subscriber-portal.service
  • ecss-media-server.service
  • ecss-pa-sip.service
  • ecss-pa-megaco.service
  • ecss-erlang.slice
  • ecss-glusterfs-mount.service
  • ecss-web-conf.service
  • ecss-web-socket.service

Результат выполнения команды для всех сервисов должен быть:

● ecss-core.service - daemon ecss-core of ecss-10.
   Loaded: loaded (/lib/systemd/system/ecss-core.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-02-23 17:13:42 +07; 1 day 17h ago

Дополнительно можно посмотреть состояние процесса и потребляемые ресурсы системы сервисом:

ps aux | grep <service name>

Если при выполнении команды sudo service <service name> status получили результат:

* <service name> is not running

То следует попытаться запустить сервис вручную:

sudo systemctl start <service name>

Причин по которой сервис или сервисы ECSS-10 не запускаются много.

Пример: Все сервисы не запущены и не запускаются, и log-файлы не пишутся.
Следует проверить объем свободного пространства на накопителе:

df -h

Возможно раздел с точкой монтирования /var/log/ecss заполнен и ECSS-10 не может запуститься. 

Решение данной проблемы следующее:

  1. Найти причину по которой произошло заполнение;
  2. Устранить причину;
  3. Освободить раздел от ненужных log-записей.

Проверка открытых портов

Проверить прослушиваются ли используемые для сигнализации порты можно при помощи команды netstat. Команда выполняется из командной консоли управления операционной системы Linux (shell).

Пример. Проверка порта 5060

netstat -na | grep 5060
udp        0      0 192.168.18.111:5060     0.0.0.0:*
udp        0      0 192.168.18.113:5060     0.0.0.0:*

Команда показывает, что на данном сервере порт 5060 открыт на двух интерфейсах. Данная ситуация возможна если на сервере установлено несколько приложений, использующих порт 5060 на разных интерфейсах. Важно, чтобы порты были открыты на интерфейсе, который использует SIP-адаптер системы ECSS-10.

Причины, по которым порт не открыт:

  • Порт используется другим приложением. Необходимо устранить конфликт, например, изменить диапазон используемых портов.
  • IP-адреса, назначенные нодам для IP-телефонии, отсутствует на сервере или находится не в работе.
  • Ошибка применения конфигурации SIP-адаптера. Необходимо выполнить перезапуск SIP-адаптера, log-файл загрузки передать в СЦ компании Элтекс.
    Также стоит проверить порт 5040 на котором по умолчанию слушает media-server.

Проверить настройки SIP-адаптера можно следующей командой:

/domain/<DOMAIN>/sip/network/info

Необходимо обратить внимание на корректность следующих параметров:

  • node_ip — IP-адреса, назначенные на нодах для открытия портов VoIP-телефонии;
  • listen_ports — диапазон портов, открытых для VoIP-телефонии.

Задать параметры можно в командной консоли CLI, при помощи команды sip/network/set.

Пример:

/domain/<DOMAIN>/sip/network/set listen_ports list [5081]

Подробное описание приведено в разделе Описание работы SIP-адаптера.

Проверка доступности направлений А и Б

В данном разделе описан способ проверки доступности направлений А и Б.

Необходимо проверять сетевые интерфейсы, используемые для VoIP-телефонии.

Для проверки доступности встречного направления нужно выполнить ping-запрос на IP-адрес тестируемого устройства. Команда выполняется из командной консоли управления операционной системы Linux (shell):

ping x.x.x.x

где x.x.x.x — IP-адрес устройства, до которого нужно проверить доступ.

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

ssw@ecss1:~$ ping 192.168.18.9
PING 192.168.18.9 (192.168.18.9) 56(84) bytes of data.
64 bytes from 192.168.18.9: icmp_req=1 ttl=128 time=0.162 ms
64 bytes from 192.168.18.9: icmp_req=2 ttl=128 time=0.136 ms
...

Если все сетевые участвующие в вызове устройства доступны, необходимо проверить сетевые порты.

Снятие трассировок ядра

Core_cp_trace — отладочный log-файл ядра, в котором хранится история обмена сообщениями между приложениями ECSS-10. Данный log-файл позволяет рассмотреть историю обслуживания вызова и проанализировать причины разъединения.

По умолчанию ведение данного log-файла отключено. Не рекомендуется оставлять core_cp_trace постоянно включенным в системе, которая находится в коммерческой эксплуатации.

Для активации функции снятия трассировок необходимо ввести команду set mode:

domain/test_domain/trace/properties/set mode full_compressed
Указанные команды выполняются через интерфейс командной строки CLI.

Режимы трассировок описаны в Команды настройки подсистемы трассировки вызовов.

Для отключения core_cp_trace необходимо выполнить следующие команды:

domain/<DOMAIN>/trace/properties/set mode disabled

Для просмотра списка трассировок используется команда list:

domain/test_domain/trace/list

Пример вывода списка трассировок:

Short ID
Start
Stage
Original CgPN
Original CdPN
CgPN
CdPN
M
Duration
Release
ISUP release
F
45cc5735
28.07.2016 10:51:58
released
1000
1005
1000
1005
n
9s
normal 
16/0

Для просмотра трассировки определенного вызова необходимо найти этот вызов используя значения следующих столбцов:

  • Start (Время начала вызова);
  • Original CgPN (Номер вызывающего абонента);
  • Original CdPN (Номер вызываемого абонента);
  • Duration (Продолжительность вызова).

В первом столбце таблице указывается Short ID, по значению которого можно вывести трассировку для этого вызова.

Стоит обратить внимание на последний столбец "F", отметка в данном столбце означает что вызов был завершен по причине падения ядра ESCC-10. В данном случае необходимо будет передать в техническую поддержку Элтекс дамп падения.

Вывод трассировки выполняется командой show:

domain/test_domain/trace/show --Te 45cc5735

Для более подробного вывода используется аргумент --payload, если необходимо вывести на экран только одно сообщение то команда show дополняется аргументом --desired N, где N — это номер сообщения. Например, команда domain/test_domain/trace/show --Te 45cc5735 выведет трассировку вызова с Short ID равным 45cc5735.

Анализ данного log-файла требует определенной подготовки. Для начала анализа log-файла необходимо найти сообщение "ReleaseReq" и посмотреть причину. Далее искать решение проблемы в зависимости от причины разъединения.
Пример сообщения "ReleaseReq":

13. out/amqp/<<"8004dc055d1b4dcb">>: 0 00:00:02.889 (2013/05/06 11:45:01.882506): 7130/62877
---------------------
Type: cast ref
Mandatory: false
Cmd: {'message.transfer',"ecss.call.data.ex",0,0}
Payload:
{'AcpMessage',<<"111@192.168.18.113">>,3502537240920379,
    {'ReleaseReq',
        {'ReleaseType',invalidNumber,system,"799",
            <<128,156>>,
            [{causeDescription,
                 {'AdditionalCauseDescription',undefined,
                     "Rule \"default_no_route\" finished with no route (isup cause: undefined)"}}],
            undefined,undefined,undefined,false,
            {1367,815501,870065}}}}
App ID: acp
Rk: ecss.pa.sip-t.pa_sip1.pa.sip-t->34333034-6463-3035-3563-656631373934.rk
TTL: 30000
Reply ex: ecss.call.data.ex
Reply rk: core.cp.core1.7.3.rk
sid: pa.sip-t->34333034-6463-3035-3563-656631373934
Result: {<0.2021.0>,#Ref<0.0.57.164013>}

>>>>>>>>>>>>>>>>>>>>>

Поле "_causeDescription, {'AdditionalCauseDescription',undefined, "Rule \"default_no_route\" finished with no route (isup cause: undefined)"}"_ указывает на то, что вызов был завершен по причине отсутствия маршрута до вызываемого абонента.

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

При анализе log-файла необходимо помнить, что существует возможность сопоставить log-файл ядра с TCP dump. В log-файл ядра присутствует параметр "Сall ref", используемый уровнем SIP-адаптера (секция AdditionalInfo).

Для сохранения трассировок в файл используется команда save-trace, аргументами которой являются:

  • --Te — для указания Short ID;
  • --dets или --text — для указания формата хранения файла (dets внутренний формат для ECSS-10, text для просмотра независимо от системы ECSS-10);
  • --filename — имя сохраняемого файла.
domain/test_domain/trace/save-trace --Te 45cc5735 --text --filename trace_45cc5735

Найти сохранённый файл можно в директории /var/lib/ecss/cp/test_domain/traces/.

Снятие дампа сетевого трафика

В системе ECSS-10 возможно снять log-файл TCP dump следующими способами:

  • включить запись TCP dump в CLI на SIP-адаптере;
  • включить запись TCP dump в Shell Linux;
  • использовать логи SIP-адаптера — siptrace.bin.

При решении проблем, связанных с "потерей" сообщений, рекомендуется снять TCP dump на ECSS-10 и удаленной стороне.

SIP-адаптер позволяет снять дамп обмена сообщениями двумя способами:

  1. TCP dump с сетевого интерфейса (pcap, используется внешний вызов tcpdump с заданными командой параметрами);
  2. файл siptrace.bin дамп (log-файл) SIP-адаптера.

TCP dump — log-файл, содержащий в себе обмен сетевыми пакетами и позволяющий произвести анализ сетевого трафика, проходящего через сервер, на котором работает система ECSS-10. Таким образом кроме сигнальных сообщений можно проверить работу RTP.

Log-файл SIP-адаптера — лог siptrace, содержащий сообщения протокола SIP, которые были получены портом SIP-адаптера, частично протранслированы на предмет соответствия протоколу. Если на SIP-адаптере происходят ошибки работы с сокетами или в настройках маршрутизации на хосте есть ошибка, то в TCP dump будут входящие запросы, а в логе SIP-адаптера — нет (и наоборот для исходящих). Если в TCP dump есть сообщения, а в логе SIP-адаптера нет и при этом в логе "errors" также нет сообщений, то необходимо проверить сетевые настройки хоста на наличие ошибок в конфигурации keepalive или vrrp.

Анализ причины непрохождения вызова необходимо начать с рассмотрения обмена сообщениями в плече А. Если проблема не обнаружена, необходимо рассмотреть обмен сообщениями в плече Б. Для детального анализа логов необходимо обратиться к рекомендациям, описывающим взаимодействие по протоколам SIP, Megaco (H.248), RTCP и т.д.

Запись сетевого дампа в CLI на SIP-адаптере

Запуск трассировки внешних сообщений из CLI CoCon:

cluster/adapter/sip1/pcap-trace/start sip1@ecss1 bond0.8 port = 5060

где:

  • sip1@ecss1 — имя ноды sip адаптера;
  • bond0.8 — сетевой интерфейс;
  • port = 5060 — порт с которого необходимо захватить трафик.

В данном случае будет захватываться трафик с 5060 порта. Если необходимо захватить весь трафик, то тогда команда будет выглядеть:

cluster/adapter/sip1/pcap-trace/start sip1@ecss1 bond0.8

Снятые дампы сохраняются в директории /var/log/ecss/.
Более подробно о запуске tcpdump см. раздел Команды трассировки.

Запись TCP dump в Shell Linux

Для снятия сетевых дампов рекомендуется использовать утилиту tcpdump. Приведем пример для снятия sip трафика между ESCC-10 и узлом сети 192.168.8.207.

sudo tcpdump -i bond0.8 -w sipdump.pcap port 5060 and host 192.168.8.207

где:

  • -i bond0.8 — сетевой интерфейс с которого снимается дамп; 
  • -w sipdump.pcap — запись снятого дампа в файл sipdump.pcap; 
  • port 5060 and host 192.168.8.207 — фильтр пакетов, сохранять пакеты с портом назначения или источника 5060 и IP адресом назначения или источника 192.168.8.207.

Сохранённый дамп можно посмотреть в консоле с помощью tcpdump:

sudo tcpdump -v -r sipdump.pcap

Полученный дамп можно также открыть с помощью Wireshark.

Логи SIP-адаптера — siptrace.bin

Путь к логу SIP-адаптера: /var/log/ecss/pa_sip/.

SIP-адаптер автоматически записывает все входящие и исходящие сообщения протокола SIP. Данный файл хранится в бинарном виде. Данный бинарный файл можно перевести в текстовой с помощью утилиты binarylog2text, которая входит в состав пакета ecss-utils.
Перевести siptrace.bin в текстовый siptrace.log можно командой:

cd /var/log/ecss/pa_sipt/YYYY_MM_DD_hh_mm_ss_sip1@<hostname>/
binarylog2text siptrace.bin siptrace.log

В то время как binaryfold2text конвертирует все файлы в каталоге в *.log , если конвертация прошла успешно, то изначальные *.bin будут удалены. 

Есть возможность сохранять трассировку siptrace сразу в текстовом виде, для этого в файле /etc/ecss/ нужно найти следующую запись:

,{siptrace,     [{file, "siptrace.bin", binary}
                      %%,{udp, {"192.168.23.23", 5090}, binary}
                     ]}

и поменять её на:

,{siptrace,     [{file, "siptrace.log"}
                      %%,{udp, {"192.168.23.23", 5090}}
                     ]}

При возникновении проблем полученные трассировки дают необходимую информацию для устранения проблемы.
При получении заголовка Warning в SIP-сообщении можно определить внутреннюю системную причину разъединения, подробнее см. Приложение Г. Описание внутренних причин разъединения.
Также в трассировке SIP-адаптера (TCP dump или файле с логом siptrace.bin) в заголовке P-Eltex-Info содержится ссылка на внутренний Call Ref, по которой можно определить Call ID вызова. В сообщении, содержащем заголовок P-Eltex-Info с нужным Call Ref, будет присутствовать заголовок Call ID, по которому можно найти все сообщения, относящиеся к данному вызову.

При завершении вызова, в ответе о невозможности установить соединение или запросе о разрушении соединения указана причина согласно рекомендации Q.850.

Например:

Reason: Q.850;cause=16;text="Normal call clearing"

или

Reason: Q.850;cause=21;text="Call rejected"

Значения кодов ответов согласно Q.850.

Также в ответах протокола SIP может содержатся заголовок Warning. Расшифровка заголовка приведена в Приложение Г. Описание внутренних причин разъединения.

Например при получении ответа с заголовком:

Warning: 399 ecss "system: Call is rejected by destination's leg"
Внутренняя причина (external_acp_causes)calledPartyRejected
Значение причины согласно рекомендации Q.85021
isup cause<<128,21>>
Информаторundefined
Описаниевызов к абоненту запрещен, например, анонимный вызов на абонента с активным сервисом ACB
Заголовок WarningCall is rejected by destination's leg

Краткий список проблем, которые можно обнаружить при анализе трассировки сигнализации

  1. На запрос INVITE от шлюза А система ECSS-10 отправляет ответ 100, затем ответ 486 Busy Here с Reason: Q.850;cause=17;text="User busy" — данное сообщение говорит о том, что абонент Б занят другим вызовом или у него снята трубка.
  2. На запрос INVITE от шлюза А система ECSS-10 отправляет ответ 100, затем ответ 484 Address Incomplete с кодом разъединения Reason: Q.850;cause=28;text="Invalid number format (address incomplete)" — сообщение указывает на то, что нет маршрута до абонента Б. Либо абонент А набрал не полный номер, либо не найден маршрут. Для решения проблемы воспользуйтесь разделом Проверка маршрутизации вызова
  3. На запрос INVITE от шлюза А система ECSS-10 отправляет ответ 100, затем ответ 500 Internal Server Error с внутренней причиной отбоя от SIP-адаптера Error-Info: <Exit call by npi_undefined> — данное сообщение говорит о том, что у абонента Б не задано свойство npi (свойство алиаса), необходимо настроить это свойство.
  4. На запрос INVITE от шлюза А (TCP dump запущен на шлюзе А или на пограничном устройстве) приходит сообщение по протоколу ICMP Port unreachable — данное сообщение говорит о том, что в системе ECSS-10 не доступен или не открыт порт, на который шлюз А отправляет сообщение INVITE. Для решения проблемы воспользуйтесь разделом Проверка доступности направлений А и Б.
  5. На запрос INVITE от шлюза А система ECSS-10 отправляет ответ 401 Unauthorized, шлюз повторно отправляет запрос INVITE с данными авторизации, на что система ECSS-10 передает ответ 403 Forbidden со внутренней причиной отбоя от SIP-адаптера Error-Info: <Unknown uri>. Данное сообщение указывает на некорректный логин и пароль, с которыми абонент А пытается авторизоваться на ECSS-10.

  6. На запрос REGISTER от шлюза А система ECSS-10 отправляет ответ 401 Unauthorized, шлюз повторно отправляет запрос REGISTER с данными авторизации, на что система ECSS-10 передает ответ 403 Forbidden с внутренней причиной отбоя от SIP-адаптера Error-Info: <Unknown uri>. Данное сообщение указывает на некорректный логин и пароль, с которыми абонент А пытается зарегистрироваться на ECSS-10.

    При регистрации SIP-абонента с некорректным логином и паролем SIP-адаптер может не отправить ответ 403, если в настройках SIP-адаптера параметр "silent-mode" установлен в значение "true" и при этом в системе активны соответствующие аварии.
  7. На запрос REGISTER от шлюза А система ECSS-10 отправляет ответ 403 Forbidden с внутренней причиной отбоя от SIP-адаптера Error-Info: <Wrong authentication: no auth configuration for subscriber>. Данное сообщение указывает на ошибку в конфигурации абонента ECSS-10. У абонента включена авторизация, но не задан логин или пароль.
  8. На запрос INVITE от шлюза А система ECSS-10 отправляет ответы 100, 180, затем ответ 502 Bad Gateway с причиной отбоя Reason: Q.850;cause=27;text="Destination out of order". Данное сообщение указывает на недоступность направления до абонента Б. Возможно, что шлюз абонента Б не доступен или абонент Б не зарегистрирован (разделы Проверка доступности направлений А и Б, Проверка регистрации SIP-абонентов системы ECSS-10).

  9. На запрос INVITE приходит ответ с кодом 500 и содержащим следующие заголовки:

    Reason: Q.850;cause=127;text="Interworking unspecified" 
    P-Eltex-Info: Internal system error: systemFailure by core 
    P-Eltex-Info: test_domain 1005@test_domain/- 2878128063 sip1@ecss1 <0.736.0>/3 incoming 
    Warning: 399 ecss "system: Internal error" 
    Warning: 399 ecss "system: Release from MSR"

    Заголовок Reason: сообщает нам Q.850 cause=127 это Interworking, unspecified, под данным кодом может быть описано множество неопределенных ошибок.
    Дополнительно присутствуют заголовки Warning в которых присутствует следующая информация

    399 ecss "system: Internal error" — 399 это код ошибки

    где

    • system — автор сообщения ядро

    • Internal error — внутренняя ошибка

    • Release from MSR — освобождения канала от медиасервера

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

sudo systemctl status ecss-media-server

Запустить командой:

sudo systemctl start ecss-media-server

Проверка регистрации SIP-абонентов системы ECSS-10

Нужно проверить зарегистрированы ли абоненты. Если абоненты не зарегистрированы, то проблема, из-за которой абоненты не могут зарегистрироваться, возможно, связана с неправильной конфигурацией. При неуспешной аутентификации нужно сравнить настройки авторизации SIP-абонентов в системе ECSS-10 и на шлюзе.

Проверка регистрации SIP-абонентов

Указанные команды выполняются через интерфейс командной строки CLI.
Просмотреть зарегистрированных SIP-абонентов на ECSS-10 можно командой:

/domain/<DOMAIN>/sip/user/registered <GROUP> <INTERFACE>

где

  • <DOMAIN> — имя виртуальной АТС;
  • <GROUP> — название группы пользователей. Символ "*" используется для указания всех групп; 
  • <INTERFACE> — название интерфейса, задается в формате: Имя_пользователя@Домен_SIP_регистрации. Символ "*" используется для указания всех интерфейсов.

Проверка настроек SIP-абонентов

Просмотреть информацию о всех SIP-абонентах ECSS-10 можно командой:

/domain/<DOMAIN>/sip/user/info * *

Просмотреть подробную информацию об определенном SIP-абоненте в системе ECSS-10 можно командой:

/domain/<DOMAIN>/sip/user/info <GROUP> <INTERFACE> --complete

где

  • <DOMAIN> — имя виртуальной АТС;
  • <GROUP> — название группы пользователей. Символ "*" используется для указания всех групп;
  • <INTERFACE> — название интерфейса, задается в формате: Имя_пользователя@Домен_SIP_регистрации. Символ "*" используется для указания всех интерфейсов.

Проверка логина и пароля SIP-абонентов

Посмотреть логины и пароли у всех SIP-абонентов ECSS-10 можно командой:

/domain/<DOMAIN>/sip/user/info * * --ldap-account

/domain/<DOMAIN>/sip/user/authentication *

Посмотреть логины и пароли у определенного SIP-абонента в системе ECSS-10 можно командой:

/domain/<DOMAIN>/sip/user/info <GROUP> <INTERFACE> --ldap-account

/domain/<DOMAIN>/sip/user/authentication <GROUP> <INTERFACE>

где

  • <DOMAIN> — имя виртуальной АТС;
  • <GROUP> — название группы пользователей. Символ "*" используется для указания всех групп;
  • <INTERFACE> — название интерфейса, задается в формате: Имя_пользователя@Домен_SIP_регистрации. Символ "*" используется для указания всех интерфейсов.

В текущей версии ПО кроме сервера LDAP параметры аутентификации (логин, пароль) могут хранится на DS. В этом случае ключ "--ldap-account" не предлагается для ввода, так как не нужен дополнительный запрос на сервер.

Проверка маршрутизации вызова

Необходимо проверить соответствует ли контекст маршрутизации на сервере файлам, импортированным в базу данных ECSS-10.

Контексты маршрутизации не импортируются автоматически. После внесения изменений в контекст маршрутизации необходимо заново импортировать контекст маршрутизации в базу данных ECSS-10.

Контексты маршрутизации расположены на сервере по следующему пути: /var/lib/ecss/routing/ctx/src.

Посмотреть контекст маршрутизации в ОС Linux можно командой cat.

Посмотреть контекст маршрутизации в командной консоли ECSS-10 можно при помощи команды show.

/domain/<DOMAIN>/routing/show <CONTEXT>
где

  • <DOMAIN> — имя виртуальной АТС;
  • <CONTEXT> — имя контекста маршрутизации.

Если контексты не соответствуют, необходимо импортировать контекст маршрутизации в базу данных ECSS-10.
Импорт контекстов маршрутизации выполняется при помощи команды import.

/domain/<DOMAIN>/routing/import <HOST> <FILE>
где

  • <DOMAIN> — имя виртуальной АТС;
  • <HOST> — имя хоста, на котором созданы контексты маршрутизации;
  • <FILE> — имя файла с контекстом маршрутизации, который необходимо импортировать.

Если контексты маршрутизации соответствуют, необходимо проверить возможность маршрутизации вызова с такими же параметрами, что и в неуспешном вызове. Трассировка вызова выполняется при помощи команды trace.

/domain/<DOMAIN>/routing/trace iface=<INTERFACE> cdpn.<PARAM>=value [<OPT1>=<VALUE1> [ ... [<OPTN>=<VALUEN>]]]
где

  • <DOMAIN> — имя виртуальной АТС;
  • <INTERFACE> — интерфейс вызывающего абонента;
  • <PARAM> — параметры вызываемого абонента (cdpn.digits, cdpn.incomplete, cdpn.inni, cdpn.nai, cdpn.ni, cdpn.npi);
  • <OPT1>..<OPTN> — опциональные параметры — набор входных данных об устанавливаемом телефонном соединении;
  • <VALUE1>..<VALUEN> — значение опционального параметра.

В итоге выполнения команды для входных данных вызова (интерфейс абонента А, контекст абонента А, время суток, день недели, номер абонента А, номер абонента Б) на выходе будут получены следующие данные: интерфейс абонента А, домен абонента А, контекст абонента А, номер абонента А (возможно модифицированный), номер абонента Б (возможно модифицированный), интерфейс абонента Б.

Пример

/domain/test.domain/routing/trace cgpn.digits=5000 cdpn.digits=700 mode=enblock

Возможны следующие результаты маршрутизации:

  • local — вызов на абонента зарегистрированного на ECSS-10, результат является нормальным; 
  • external — вызов на внешнее направление (Trunk0), результат является нормальным; 
  • no route — отсутствие правил маршрутизации с данными параметрами вызовами. Необходимо внести корректировки в контекст маршрутизации, чтобы вызов с данными параметрами осуществлялся успешно. 
  • no access — отсутствие права доступа с данными параметрами вызова. Необходимо внести корректировки в правила ограничения доступа (access_group, access_type, regime), чтобы вызов с данными параметрами осуществлялся успешно. 
  • no_b_iface — интерфейс может быть неактивен. В случае использования протокола SIP это либо незарегистрированный абонент, либо по транку нет ответа на периодически передаваемые запросы OPTIONS.

Протоколирование действий администратора в консоли web на внешний syslog-сервер

Настройка rsyslog

Для того чтобы включить поддержку принятия syslog-ов по UPD, следует раскомментировать следующие строки (/etc/rsyslog.conf — в случае использования rsyslogd):

module(load="imudp")

input(type="imudp" port="514").

Для того чтобы в выводе сообщения отображались миллисекунды, нужно определить новый шаблон в /etc/rsyslog.conf:

$ActionFileDefaultTemplate TraditionalFileFormat

$template TraditionalFileFormat,"%TIMESTAMP%.%timestamp:::date-subseconds%%HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n"

Настройка sys.config

Для приложения chronica включить правило:

{cocon_audit, "cocon_audit_exec|cocon_audit_session|cocon_audit_apply", trace, [syslog], on}

Возможные теги для записей: * cocon_audit_exec — выполнение команды через ssh shell; * cocon_audit_session — login/logout пользователя; * cocon_audit_apply — выполнение команды со стороны web-configurator; * cocon_audit_result — результат выполнения команды; * cocon_audit — все остальные.

Для того чтобы отображались все записи, в качестве тега следует указывать: cocon_audit*

Настройка dnsmasq

Для того чтобы задать IP адрес куда будут направляться записи, нужно переопределить имя хоста «syslog.ecss» в /etc/dnsmasq.d/ecss-syslog. По умолчанию используется адрес 127.0.0.1.

Протоколирование действий пользователей на сервере с установленным ECSS-10

При установке пакета ecss-security, автоматически создается папка /var/log/ecss/security/, в которой будет храниться вся история команд и подключений к серверу.

Перечень выполняемых функций:

  1. Логирование всех выполняемых команд в bash;
  2. Логирование входа/выхода в систему;
  3. Логирование удаленных авторизаций;
  4. Еженедельная ротация логов;
  5. Ограничивает количество подключений в Cocon до 5 в минуту.

Создаваемые лог файлы не возможно удалить или отредактировать, они доступны только для просмотра. Все старые лог файлы сжимаются и перемещаются в каталог /var/log/ecss-security/<год>-<месяц>/.

Пример:

Dec  6 15:04:35 ecss1 ecss-security[6124]: tester : TTY=pts/1 ; PWD=/home/tester ; USER=tester; RETURN=0 ; COMMAND=ssh admin@localhost -p8023
Dec  6 15:04:36 ecss1 ecss-security[6124]: tester : TTY=pts/1 ; PWD=/home/tester ; USER=tester; RETURN=0 ; COMMAND=ssh admin@localhost -p8023
Dec  6 15:05:16 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/home/tester ; USER=root; RETURN=0 ; COMMAND=sudo apt update
Dec  6 15:05:16 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/home/tester ; USER=root; RETURN=0 ; COMMAND=sudo apt update
Dec  6 15:05:24 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/var/log/ecss/pa-sip/sip1@ecss1 ; USER=tester; RETURN=0 ; COMMAND=cd /var/log/ecss/pa-sip/sip1@ecss1/
Dec  6 15:05:25 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/var/log/ecss/pa-sip/sip1@ecss1 ; USER=tester; RETURN=0 ; COMMAND=cat error.log
Dec  6 15:05:26 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/var/log/ecss/pa-sip/sip1@ecss1 ; USER=tester; RETURN=0 ; COMMAND=l
Dec  6 15:05:32 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/var/log/ecss/pa-sip/sip1@ecss1 ; USER=tester; RETURN=0 ; COMMAND=cat restart.log

Systemd сервис для захвата и сохранения служебного трафика

Ecss-captraf — скрипт для захвата сетевого трафика и его записи. Используется для записи служебного трафика (либо всего, либо только по voip: http/sip/rtp).

Осуществляет запись трафика пользователя с перезаписью файлов в зависимости от заданных параметров:

  • максимальное количество файлов;
  • максимальный размер файла;
  • максимальное время записи в один файл.

При превышении максимального количества файлов начинается перезапись с первого файла. Запись в новый файл начинается либо при превышении максимального размера, либо при превышении времени записи.
Запись осуществляется в директорию, указанную в конфигурации. При отсутствии директории происходит её создание.

Для работы необходимо задать имя сетевого интерфейса (одного или нескольких), с которого будет осуществляться захват трафика, либо any, обозначающее любой интерфейс.

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

Скрипт может работать в двух режимах:

  • full — захват всего трафика;
  • voip — захват трафика только с протоколами http, sip, rtp.

В режиме voip для захвата HTTP трафика используется фильтр непустых tcp-пакетов с порта tcp 80.
SIP трафик: фильтр udp-пакетов с порта udp 5060;
RTP трафик: фильтр udp-пакетов с чётными номерами портов, в которых первые два бита "полезных данных" соответствуют корректному номеру версии RTP (2 версия). Однако, под этот фильтр могут попадать не только RTP-пакеты. Также в фильтре исключается трафик с 53 порта (DNS).
Кроме того, в обоих режимах исключается SSH-трафик (22 порт) и cisco-net-mgmt/irdmi (8023 порт).

Параметры для настройки находятся в файле конфигурации /etc/ecss/ecss-captraf.conf, в котором заданы следующие значения:

  • Размер отдельного файла дампа (100 миллионов байт)
    FILE_SIZE=100
  • Количество отдельных файлов дампа (200 файлов)
    FILE_COUNT=200
  • Макс. время записи в файл (1800 секунд, или 30 мин.)
    FILE_ROTATION=1800
  • Имя сетевого интерфейса (любой интерфейс)
    INTERFACE=any
  • Режим работы: full/voip (захват всего трафика)
    MODE=full
  • Путь, по которому будут записываться файлы дампов (/var/cache/ecss/ecss-captraf/)
    DUMP_PATH=/var/cache/ecss/ecss-captraf/

Имена дампов содержат название хоста, на котором запущен сервис, название интерфейса и время начала записи в файл (при условии, что задано ограничение по времени записи).

Запуск осуществляется через systemd сервис — ecss-captraf.service.