Безопасный debug в Cisco

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

Некоторые команды debug, например
debug ip packet detail
могут привести к недоступности маршрутизатора во время вывода данных на консоль. Зачастую, это случается из-за большого объема данных при медленной скорости подключения 9600 бод.

Таким образом, отключим эту функцию!
config t
no logging console
Однако, с момента "замирания" данных на экране информация debug режима не очень полезна. Таким образом, можно подключиться к маршрутизатору при помощи telnet клиента и запустить
terminal monitor
для отправки всех сообщений режима debug клиенту. Уже лучше, но это все так же может привести к печальным последствиям.

Необходимо только переместить все сообщения debug режима в буфер
logging buffered

после чего их можно просмотреть при помощи
show log

Есть и другая опция, которая помогает при отладке:
debug ip packet

которая является безопасней при применении списка доступа(access-list) для анализа необходимого трафика. Например:
access-list 100 permit ip any host 1.1.1.1
access-list 100 permit ip host 1.1.1.1 any

debug ip packet detail 100
В этом примере можно увидеть детальную информацию по IP пакетам от хоста(1.1.1.1) или к этому хосту.

Решаем проблему совместимости Cisco и SFP

Столкнулся недавно с проблемой. А суть ее такова: есть коммутатор Cisco 3560E и в нем есть модуль для подключения SFP. Если вставить родные SFP от Cisco, то все работает; если же подключить SFP модуль стороннего производителя, тогда этот модуль не будет принимать коммутатор.

При подключении SFP модуля стороннего производителя в логи коммутатор пишет вот что:

00:40:35: %GBIC_SECURITY_CRYPT-4-VN_DATA_CRC_ERROR: GBIC in port Gi0/25 has bad crc
00:40:35: %PHY-4-UNSUPPORTED_TRANSCEIVER: Unsupported transceiver found in Gi0/25
00:40:40: %GBIC_SECURITY_CRYPT-4-VN_DATA_CRC_ERROR: GBIC in port Gi0/26 has bad crc
00:40:40: %PHY-4-UNSUPPORTED_TRANSCEIVER: Unsupported transceiver found in Gi0/26

Решить эту проблему достаточно просто. Заходим на коммутатор и "заставляем" коммутатор принять наши модули стороннего производителя при помощи команд:

service unsupported-transceiver
no errdisable detect cause gbic-invalid
no errdisable detect cause sfp-config-mismatch

Перенаправление сообщений из EventLog Windows на удалённый syslog

Для установки нужно скачать архив со страницы проекта(https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys/index_html) и распаковать его в директорию %systemroot%\system32 (Обычно это C:\Windows\system32).

После распаковки нужно запустить командную строку: «Пуск» -> «Программы» -> «Стандартные» -> «Командная строка». И выполнить в ней следующие команды:
%SystemDrive%
cd %SystemRoot%\System32
evtsys -i -h 192.168.2.1
net start evtsys
Первыми двумя командами осуществляется переход в директорию с файлами утилиты, третья устанавливает evtsys как системную службу (она получит имя "Eventlog to Syslog"). Последняя команда запускает эту службу.

После этого системные логи из EventLog начнут дублироваться в удалённый Syslog.

Если по какой-то причине нужно удалить evtsys то в командной строке нужно выполнить следующие команды:
%SystemDrive%
cd %SystemRoot%\System32
net stop evtsys
evtsys -u
del evtsys.*
Здесь сначала останавливается служба, потом удаляется запись о ней из реестра системы и наконец удаляются сами файлы утилиты.

Отдельно нужно оговориться о том, что в русской версии Windows сообщения пересылаются в кодировке cp1251, потому для чтения логов на сервере сбора логов имеет смысл воспользоваться примерно такой командой:
iconv -f cp1251 192.168.2.201-notice.log | less