Помилки молодості нашої. Або як мережевий інженер пізнає природу консолі



Всім привіт! Сьогодні хотів би поговорити про стандартні помилки, які ми здійснюємо під час налаштування мережевого обладнання. Думаю, всім знайоме відчуття, коли ти вводиш чергову команду в консолі і раптом розумієш, що консоль припинила відгукуватися, а обладнання на іншій стороні Землі (яке ти як раз і налаштовував) більше не пінгуєтся. У цей момент на секунду завмирає подих, ти починаєш чітко чути биття свого серця. Загострений слух повністю зосереджується на телефонний виклик, який ось-ось пролунає. Організм зморщується, і ти розумієш, що це кінець. Перебір, звичайно ж, не кінець, а початок героїчного подолання тієї ситуації, в яку ти себе тільки що загнав. А далі буде подвиг, розповідь про твій подвиг і, можливо, навіть овації з боку колег. І найголовніше, ти в черговий раз даси собі слово, що більше НІКОЛИ так не будеш робити. Багато хто мені заперечить, що це не про них і що вони, справжні професіонали, такого не допускають. Це прекрасно, і я щиро радий за них. Але справжніми професіоналами не народжуються і не стають відразу.

Сьогодні хотів би розглянути ситуації, про яких розповідають на курси молодого бійця з консоллю, але які починають мати реальне значення, тільки після того, як на них «наступити». Спочатку хотів зупинитися на якихось конкретних ляпи при налаштуванні обладнання 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.

Висновок

Ах, як було б здорово, прочитати про всіх таких ситуаціях і відразу почати налаштовувати правильно. Але в ІТ дуже часто доводиться кілька разів самому наступити на ці граблі, перш ніж починаєш продумувати наслідки кожного свого кроку. Тільки після цього, відчувши кожну ситуацію на собі, зможеш не допускати їх у майбутньому.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.