Troubleshooting Juniper MX и не только, диагностика и анализ использования ресурсов

Что делать когда Juniper сам по себе перезагрузился? Каким образом проверить использование системных ресурсов на устройстве? Как выполнять Troubleshooting работы Juniper?


1. Самое первое, что стоит проверить после перезагрузки устройства - show chassis routing-engine значение "Last reboot reason" в котором в штатном режиме должно быть - "Router rebooted after a normal shutdown" Но, стоит понимать, что это определение не говорит о том, что проблем не было, это лишь поможет понять, увидел ли проблему JunOS или нет, что может упростить процесс анализа.
Я на своей практике замечал следующие состояние: "could not be determined", "panic:ehci_abort_xfer: not in process context", "0x1:power cycle/failure".

На правах рекламы совета, большинство падений оборудования связано с недавно внесенными изменениями в сеть/работу устройства и т.д. Какие действия выполнялись на Juniper можно проверить по commits (история внесений изменений в конфигурацию устройства):
show system commit  - кто и когда коммитил
show configuration | compare rollback 2 - сравнить текущую конфигурацию системы с конфигурацией в файле  rollback 2
show system rollback compare 4 3 - сравнить 2 файла конфигурации

2. Проверим файлы с логами: show log messages | find "FreeBSD Project". Не забываем, что если у нас устройство генерирует большое количество записей, то просматриваем все имеющиеся файлы логов (messages.0.gz, messages.1.gz и тд.) пока не найдем желаемое. Читаем логи за 15 минут до падения устройства и анализируем.
Для того чтобы удобно работать с логами, необходимо использовать достаточный уровень логирования, например - set system syslog file messages any notice. Рекомендуется не включать полное логирование "any any", такое логирование со временем просто "убьет" flash drive на routing-engine. Если мы хотим логировать всё-всё-всё - syslog сервер нам в помощь.

Заметим, что в случае, если устройство перезагружено администратором в логах будет следующие записи:
May 17 17:15:04  EX3200 mgd[45517]: UI_REBOOT_EVENT: System rebooted by 'admin'
May 17 17:15:10  EX3200 shutdown: reboot by admin:

В случае, если мы замечаем, что устройство жалуется на конкретный процесс (daemon), в KB Juniper мы можем найти описание процессов: List of Junos OS Processes

Не мало важный момент это - использование traceoptions на Juniper (debug). Включение traceoptions для сервисов, протоколов, процессов и тд. значительно помогает в настройке/troubleshooting, но, это может вылезть "боком", трейсы довольно трудоемкий процесс и кушает много системных ресурсов. Поэтому, в штатном режиме использовать traceoptions не стоит и + это убьет flash drive в 10 раз быстрее... Когда flash drive плохо, возникает похожая ошибка - g_vfs_done():da1s1f[WRITE(offset=962772992, length=16384)]error = 5, она может возникнуть в процессе работы, загрузки устройства, либо работы с файловой системой.
Проверяем не было ли создано системой core-dumps файлов (это дампы памяти, которая система может сделать в случаи crash определенного демона rpd, etc).
show system core-dumps

Содержание данных файлов трудно проанализировать самостоятельно, поэтому, зачастую создается тикет в JTAC и данные файлы заливаются на FTP Juniper, в последующем анализируются инженерам. FAQ в KB Juniper по добавления файлов.
TT (trouble ticket) можно открыть при наличии активного сервисного контракта у Juniper Networks - Serial Number Entitlement Search

3. Проверим версию установленного JunOS:
show version

Не нужно гнаться за самой последней веткой и версией софта а использовать recommend (http://kb.juniper.net/InfoCenter/index?page=content&id=KB21476&actp=search)
Важный момент, возможно уже существует описание бага по причине которого и произошла перезагрузка оборудования, данную информацию можно проверить в в PROBLEM REPORT SEARCH - https://prsearch.juniper.net/InfoCenter/index?page=prsearch. Для входа требуется регистрация.
Информация и FAQ по обновлению JunOS

3. Большинство устройств Juniper имеют модульную архитектуру и разделение по плоскости управления и обработки трафика (control & data plane), правда это разделение не всегда аппаратное. Выполняем типичную проверку состояния компонентов устройства (Routing-engine, Flexible PIC Concentrator, tfeb, ethernet-switch, компоненты и функции устройства могут отличаться в зависимости от серии и модели устройства). Таким образом мы попытаемся локализовать проблему.

show chassis hardware - список всех компонентов (само шасси, платы (модуля), блоки питания, фаны). Это исключительно список активных компонентов. Если карта сейчас упала или перезагружается здесь она отображена не будет, пока она полностью не загрузиться и не будет инициализирована.

show chassis routing-engine  - состояние Routing-engine (мозгов устройства), если используется резервирование, одна RE в состоянии Master, вторая RE в состоянии Backup. Здесь обращаем внимание на использование оперативной памяти и CPU.
Рекомендации по настройка отказоустойчивость по RE - Configuring Routing Engine Redundancy

show chassis alarms и show system alarms - комментарии излишни, система сама может показать проблему, если она ее заметила.

show chassis fpc detail - информация о состоянии и нагрузки линейных карт.

show chassis fpc pic-status - информация о состоянии pic модулей, которые вставлены в fpc карты.

show chassis pic fpc-slot 0 pic-slot 2 - информация о состоянии и загрузки конкретной pic карты, в примере это MS-MIC-16G на mx10-t.

show chassis environment - температура ASIC чипов (LU (XL), MQ (XM), QX (XQ) - это типы чипов на Juniper Trio Chipset для MX) тип чипа зависит от модели и архитектуры устройства). При нормальных условиях функционирования устройства температура не должна превышать 60 градусов по Цельсию. Если все блоки питания подключены к сети, напротив PEM будет указано - OK, если блок питания присутствует, но питание не подается - Absent. В штатном режиме, все fan должны крутиться на нормальной скорости, это отображается как - Spinning at normal speed.

На больших железках MX240 +  все участвующие в обработке трафика компоненты связываются между собой через встроенный в SCB ethernet-switch. Выполнив команду show chassis ethernet-switch statistics мы можем посмотреть нет ли ошибок на служебных интерфейсах.

5. Настройки защиты control plane. По умолчанию, Juniper MX например, не имеет никаких ограничений по протоколам, портам, к которым могут обращаться снаружи. Учитывая тот факт, что существует большое количество уязвимостей как JunOS CVE Vulnerability Juniper, так и уязвимостей в протоколах. Правильное решение данной проблемы - настроить фильтры для трафика, который может обращаться к control plane нашего устройства.
Официально у Juniper есть следующая литература:
http://www.juniper.net/us/en/training/jnbooks/day-one/fundamentals-series/securing-routing-engine/