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

В системе 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-10.
Перевести siptrace.bin в текстовый siptrace.log можно командой:

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

Есть возможность сохранять трассировку 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-сообщении можно определить внутреннюю системную причину разъединения, подробнее см. 3.11 Приложение Г. Описание внутренних причин разъединения.
Также в трассировке 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. Расшифровка заголовка приведена в 3.11 Приложение Г. Описание внутренних причин разъединения.

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

Warning: 399 ecss "system: Call is rejected by destination's leg"