Ошибки молодости нашей. Или как сетевой инженер познаёт природу консоли
Всем привет! Сегодня хотел бы поговорить о стандартных ошибках, которые мы совершаем при настройке сетевого оборудования. Думаю, всем знакомо чувство, когда ты вводишь очередную команду в консоль и вдруг понимаешь, что консоль прекратила откликаться, а оборудование на другой стороне Земли (которое ты как раз и настраивал) больше не пингуется. В этот момент на секунду замирает дыхание, ты начинаешь отчётливо слышать биение своего сердца. Обострённый слух полностью сосредотачивается на телефонном вызове, который вот-вот раздастся. Организм съеживается и ты понимаешь, что это конец. Перебор, конечно же, не конец, а начало героического преодоления той ситуации, в которую ты себя только что загнал. А дальше будет подвиг, рассказ о твоём подвиге и, возможно, даже овации со стороны коллег. И самое главное, ты в очередной раз дашь себе зарок, что больше НИКОГДА так не будешь делать. Многие мне возразят, что это не про них и что они, настоящие профессионалы, такого не допускают. Это прекрасно, и я искренне рад за них. Но настоящими профессионалами не рождаются и не становятся в одночасье.
Сегодня хотел бы рассмотреть ситуации, о которых рассказывают на курсах молодого бойца с консолью, но которые начинают иметь реальное значение, только после того как на них «наступишь». Изначально хотел остановиться на каких-то конкретных ляпах при настройке оборудования Cisco, но в процессе подготовки статьи решил рассмотреть более общие моменты. Кому-то они покажутся банальными, кто-то вспомнит украдкой, что он когда-то так делал, а кто-то, может быть, воспользуется ими, чтобы лишний раз не попадать в неприятную ситуацию.
Давай сделаем это по-тихому
Нужно что-то поменять в работе сети. Решаем сделать это по-тихому, никого не предупредив. Вдруг пронесёт и не придётся согласовывать перенастройку, тратить на это время. Ведь если согласовывать переконфигурацию в сети, могут, во-первых, попросить провести эти работы в нерабочее время. А, во-вторых, в большинстве случаев при согласовании даже небольших по объёму работ требуется подготовить развёрнутый регламент с указанием рисков, временных интервалов, инструкций по откату к предыдущей рабочей конфигурации и плану по тестированию новой конфигурации. В итоге, для того, чтобы применить одну-две команды нужно провести огромную подготовительную работу. А так можно прямо сразу настроить и забыть. Нужно-то небольшой пустяк поменять. Но, по всем известному закону, провести перенастройку по-тихому не всегда удаётся. И хорошо, если всё случилось быстро и пострадавших мало. Хуже, если о вашей небольшой перенастройке сети узнаёт генеральный директор компании.
Рекомендация
Не стоит торопиться, лучше всё ещё раз взвесить и по возможности предупредить окружающих. Так сказать, предупреждён, значит вооружён. И если не до конца уверен в том, что всё пройдёт гладко, перенести работы на наименее болезненное время. И даже если работы проводятся в нерабочее время, лучше всё равно оповестить об этом других. Возможно, кто-то именно сегодня решил задержаться на работе и потрудиться допоздна.
Сто бед — один ресет
Ты, уверенный полностью в своих силах, решаешь изменить какие-то важные настройки на оборудовании удалённо. Причём устройство находится в далёком и прекрасном городе нашей Родины. Не ехать же туда ради этого. Хотя можно было бы, но начальство не поймёт. Поэтому вооружаемся удалённым доступом. Выбираем время, когда допустимы небольшие перебои в работе сети. Подключаемся. Клац, клац. И тут неожиданно для себя мы теряем доступ к устройству. Причин может быть много: от банальной невнимательности (в адресе вместо единицы указал двойку), до недостаточной осведомлённости о работе той или иной технологии (ну, не дочитал, с каждым бывает). Не беда, сейчас надо кого-нибудь попросить перезагрузить устройство. Ведь конфигурацию я не успел сохранить. Но выясняется, что удалённо перезагрузить устройство не получиться. Банально там сейчас уже ночь и никого нет, так как совсем другой часовой пояс. Придётся ждать утра. А утро там начнётся, когда у нас будет ночь. В общем «за дурною головою и всему остальному телу покоя нет».
Рекомендация
Можно использовать команду автоматической перезагрузки устройства через определённое время:
cbs-rtr#reload in 10
* В указанном примере маршрутизатор перезагрузится через 10 минут
Если что-то пойдёт не так, и вы потеряете доступ к устройству, через заданное время оно перезагрузится и можно будет начать всё сначала. Безусловно, использовать данную команду, можно только в том случае, если перезагрузка устройства допустима.
Не стоит забывать отключать автоматическую перезагрузку устройства. А то она может стать небольшой неожиданностью в процессе дальнейшей работы:
cbs-rtr#reload cancel
Сейчас как задебажу
Очень часто в процессе решения проблемы необходимо запустить на устройстве отладчик (дальше будет использоваться более привычное слово «дебаг»). Иногда нужный нам дебаг генерирует очень много сообщений, особенно если он запускается на устройстве, которое активно отрабатывает свой хлеб. Итак, запускаем дебаг, предварительно включив его отображение в терминальной сессии. Ну как же, мы ведь хотим сразу же найти ошибку, анализируя прямо на ходу. Но тут консоль начинает подтормаживать. Ты в одночасье забываешь о том, что у тебя до этого была какая-то небольшая проблема. И хорошо, если со скрипом удаётся вбить заветные «undebug all». Хуже, если единственное, что ты можешь наблюдать — это статическая картинка зависшей консоли.
Рекомендация
Рекомендуем осуществлять вывод дебага исключительно в буфер. При этом предварительно задав его размер. Он не должен быть маленьким (а то не все заветные строчки туда попадут), а также не слишком большим (а то нашему устройству может поплохеть, так как все лог-сообщения сохраняются в оперативной памяти устройства).
cbs-rtr (config)#logging console informational //Убираем логирование сообщений дебага в консоль
cbs-rtr (config)#logging buffered debugging //Включаем логирование сообщений дебага в буфер устройства
cbs-rtr (config)#logging buffered 100000 //Задаём размер буфера, в нашем случае он равен 100 000 байт
Когда лог-записей от дебага совсем много, можно настроить передачу этой информации на самый обычный syslog-сервер, чтобы их вообще не хранить на устройстве:
cbs-rtr (config)#logging host 10.0.0.1 //Указываем IP-адрес syslog-сервера
cbs-rtr (config)#logging trap debugging //Включаем отправку сообщений дебага на syslog-сервер
Так, а что это у нас такое?
Сеть как живой организм, все время меняется. Появляются новые сервисы, подключается новое оборудование, отключается старое. Всё время приходится вносить какие-то правки. Запомнить всё невозможно. Поэтому иногда, подключившись на устройство, теряешь достаточно много времени на то, чтобы просто вспомнить, для чего был когда-то настроен этот маршрут. Или зачем нужна эта строчка в списке доступа (ACL). Ситуация усугубляется, если сетью управляют несколько человек. Так что же делать? Первый ответ — документировать. Согласен, без этого никуда. Но в реальной жизни ой как тяжело всё время поддерживать в актуальном состоянии документацию. В особенности, если она детальная. Поэтому как некий компромиссный вариант в качестве «напоминалки» подойдёт сама конфигурация устройства.
Рекомендация
В процессе настройки различных сущностей в конфигурации рекомендуем использовать «говорящие» названия. Например, если мы делаем ACL, который будет висеть на внешнем интерфейсе маршрутизатора в направлении in, назвать его можно, например так: «FW-OUTSIDE-IN». Далее просматривая конфигурацию, и увидев в ней ACL с таким именем, сразу станет ясно, почему он тут живёт. Такие названия можно делать также для class-map, policy-map, object-group, route-map и т.д.
Второй момент: не забывать добавлять описание к тем или иным строчкам в конфигурации. Это можно сделать, например, с помощью следующих команд:
- для интерфейса — description;
- для crypto map — description;
- для route-map — description;
- для ACL — remark;
- для статического маршрута — name.
Нет ничего более постоянного, чем временное
При решении каких-либо проблем иногда приходится запускать различные дебаги, захватывать трафик (задействовать capture), зеркалировать трафик (SPAN/RSPAN/ERSPAN), использовать тестовые ACL и пр. Причём, как только проблема решена, наступает облегчение (иногда даже эйфория, ведь ты только что стал повелителем цисок), и уже нет особого желания разбираться со всеми временными настройками. Усугубляется это ещё в том случае, когда борьба с проблемой идёт сразу на нескольких фронтах. И слава одержанной победы на одном из них не позволяет обратить внимание на остальные фронты, где брошенные в атаку дебаги, кепчеры и другие средства героически ведут бой с уже несуществующим врагом. Я думаю, не стоит сильно расписывать, к чему это может привести. Как минимум к возникновению дополнительной нагрузки на устройство и даже на всю сеть, которая потом может сыграть против нас в самый неподходящий момент.
Ещё одна сторона борьбы с проблемами — это временные схемы маршрутизации или обработки трафика, отключённые функции (когда мы пытаемся определить проблему методом исключения) и пр. Не всегда просто потом вспомнить, что ты в панике пытался сделать или что отключить для решения проблемы в сети.
Рекомендация
Не забывать отключать debug, capture, удалять тестовые ACL и прочую временную конфигурацию. Необходимо обратно активировать все функции, которые были отключены при поиске проблемы.
Опять проблемы…
Иногда сеть отказывает. Да, и такое случается. Главное, чтобы пореже. В этот момент очень важно не паниковать, а с холодной головой пытаться найти проблему. Если выяснить причину удаётся достаточно быстро, данный инцидент проходит практически без последствий, не нарушая твоё психологическое состояние. Совсем другое дело, когда все попытки понять, почему не работает, и исправить ситуацию, оказываются тщетными. В этом случае панические настроения увеличиваются прямо пропорционально времени, прошедшему с момента обнаружения неисправности. Дополнительным катализатором становятся различного рода просьбы со стороны коллег о том, что крайне важно всё починить как можно раньше, иначе… Думаю, вариаций после слова «иначе» достаточно много и как слова поддержки их вряд ли можно рассматривать.
В такой ситуации главное структурировать процесс траблшутинга (поиска неисправности) и ни в коем случае не пытаться бессистемно подкрутить то тут, то там в надежде, что удастся угадать, где болит. Такое поведение очень часто приводит к тому, что человек входит в некий цикл, постоянно пытаясь решить проблему, делая примерно одно и то же.
Рекомендация
Процесс траблшутинга крайне желательно предварительно продумать, разбив на этапы и выбрав определённую схему действия (например, снизу-вверх, начинаем с проверки физического уровня IOS и далее поступательно подымаемся вверх). Очень важно постоянно анализировать полученные результаты с целью корректировки дальнейших шагов. В конечном итоге вам удастся, как минимум, локализовать проблему. Ну, а дальше решить её или же придумать какой-то обходной вариант.
Новый не значит лучший
Замена IOS — обычная процедура. Мы её выполняем с целью победить какую-то проблему, или же нам необходимо получить новый функционал. Но далеко не всегда более новый IOS является более надёжным. Бывает так, что, заменив IOS, в котором решён нужный нам баг (bug), мы получаем новый в подарок. Так сказать, «одно лечим, другое калечим». Конечно, это происходит не так часто, но к такой ситуации стоит быть готовым. Не зря в больших сетях обычно используются определённые эталонные версии IOS. И вопрос их замены является достаточно проблематичным.
Рекомендация
В случае замены IOS рекомендуется проверить корректность выполнения функций устройством. Конечно, проверить сразу всё не удастся. Да и не стоит, иначе это будет выглядеть чуточку параноидально. Поэтому достаточно держать в голове тот факт, что, если в ближайшее время на данном устройстве будет проблема, одной из причин её возникновения может быть недавняя замена IOS.
Заключение
Ах, как было бы здорово, прочитать о всех таких ситуациях и сразу начать настраивать правильно. Но в ИТ очень часто приходится несколько раз самому наступить на все эти грабли, прежде чем начинаешь продумывать последствия каждого своего шага. Только после этого, прочувствовав каждую ситуацию на себе, сможешь не допускать их в будущем.
