vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

Cisco IOS Embedded Packet Capture на службе технической поддержки 1

Дата публикации: 10.04.2017
Количество просмотров: 3199

Периодически для диагностики проблем со связью у абонента нужно иметь возможность быстро снять дамп трафика для его дальнейшего анализа. Такими проблемами могут быть: деградация сервиса от CPE до определенного сервера в удаленной сети (игра, веб-сайт или VPN-сервер); общая неудовлетворенность услугой доступа к сети у абонента; тестирование настроек QoS и т.д.

Также к похожим проблемам можно отнести DDOS. Чтобы определить, кого именно отправлять в blackhole (Remotely triggered black hole), нужно снять дамп входящего трафика и проанализировать его. В качестве полуавтоматического анализа в таком случае можно использовать сортировку по количеству переданных пакетов/байт в меню Wireshark Statistics > Endpoints.

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

Имея в качестве пограничного маршрутизатора cisco ASR1000, для себя я решил проблему автоматического получения дампа трафика с помощью Embedded Packet Capture, Embedded Event Manager (EEM), remote shell (rsh) и САП UserSide.

В САП UserSide в карточке абонента с помощью штатного функционала создается дополнительная вкладка, которая ссылается на некий php-скрипт. Это вкладка может выглядеть так:

В обработчике события нажатия на ссылку средствами php описываются действия "Снять дамп", "Экспортировать" и т.д. в зависимости от степени автоматизации процесса снятия дампа, которую вы выбираете. Скрипт по rsh передает команды и IP-адрес абонента на пограничный маршрутизатор. Например, это может выглядеть так:

 

 

На маршрутизаторе уже должен быть настроен rsh. Допустим, что веб-сервер работает от пользователя apache, тогда настройка rsh на cisco IOS XE может выглядеть таким образом:

 

 

Если после настройки rsh не удается подключиться к маршрутизатору, активируйте debug следующей командой:

debug ip tcp rcmd

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

По команде скрипта с сервера на cisco ASR запускается applet EEM, который сначала останавливает запись, на случай если она уже ведется. Далее аплет удаляет буфер и создает новый с нужными параметрами. В случае если старого буфера не было, в логике EEM ничего не меняется, и точно так же создается новая запись с нужными параметрами. В моем примере используются следующие параметры: размер буфера 100 Мегабайт, длительность записи 120 секунд, максимальная скорость записи равна 10000 пакетов в секунду. В результате запись остановится через 2 минуты или при достижении максимального размера буфера — зависит от того, какое событие наступит первым. Аплету EEM необходимо передать в качестве аргумента IP-адрес нашего абонента. Аргумент попадает в переменную $_none_arg1, которая, в свою очередь,  используется при создании extended ACL. Так выглядит рабочий аплет конфигурации буфера:

 

 

Если используется NAT, нужно указывать интерфейс, который подключен к локальной сети (Downlink). В моем случае это: 

TenGigabitEthernet0/2/0.111.

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

 

 

При работе буфера мною не замечено никакого влияния на общую производительность устройства, за исключением уменьшения доступной памяти RAM на величину, равную размеру буфера. Это касается и случая снятия дампа одного абонента и случая снятия дампа с внешнего интерфейса при DDOS.

После заполнения буфера, его нужно куда-то экспортировать. Удобно это делать на FTP-сервер, который доступен и с компьютера оператора и с маршрутизатора. Для автоматического экспорта я так же использовал EEM.

Аплет автоматического экспорта "ждет", когда в логе устройства появится сообщение о том, что запись закончена. Далее с помощью регулярного выражения "вынимает" из команды sh ip access-lists ID-ACL-USER | i permit ip any host IP-адрес и помещает его в переменную ip, которая используется для формирования имени дампа. В переменной $_event_pub_sec хранится время возникновения события. В данном случае на FTP-сервер экспортируется файл с именем 203.0.113.11-1490202603.pcap. Средствами FTP-клиента можно отсортировать файлы по дате создания и таким образом найти нужный дамп. Так выглядит рабочий аплет автоматического экспорта:

 

 

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

debug event manager action cli

и снова дать команду на старт записи. В логах устройства появится информация о происходящем.

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

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

event manager run ID-START-CAPTURE 203.0.113.11

После недолгого ожидания дамп будет ждать на FTP-сервере.


 

Ссылки:

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/article/31434/cisco-ios-embedded-packet-capture-na-slujbe-tehnicheskoy-podderjki.html

Комментарии:(1) комментировать

7 апреля 2017 - 19:32
Robot_NagNews:
#1

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

Полный текст


7 апреля 2017 - 19:32
catalist:
#2

Побольше бы таких статей


Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться