Ця стаття є другою у циклі статей «Як взяти мережеву інфраструктуру під свій контроль». Зміст усіх статей циклу та посилання можна знайти .
Наша мета на даному етапі – наведення порядку у документації та конфігурації.
На виході цього процесу у вас має бути необхідний комплект документів та мережа, налаштована відповідно до них.
Зараз ми не говоритимемо про аудит безпеки – цьому буде присвячена третина.
Складність виконання поставленої цьому етапі завдання, звісно, сильно варіюється від компанії до компанії.
Ідеальна ситуація – це коли
- ваша мережа була створена відповідно до проекту і ви маєте повний комплект документів
- у вашій компанії було впроваджено для мережі
- відповідно до цього процесу ви маєте в своєму розпорядженні документи (у тому числі і всі необхідні схеми), що надають повну інформацію про актуальний стан речей
І тут ваше завдання досить проста. Ви повинні вивчити документи і переглянути всі зміни, які були зроблені.
У найгіршому варіанті у вас буде
- мережа, створена без проекту, без плану, без узгодження, інженерами, які не мають достатнього рівня кваліфікації,
- з хаотичними, не задокументованими змінами, з великою кількістю «сміття» та неоптимальних рішень
Зрозуміло, що ваша ситуація десь між, але, на жаль, на цій шкалі краще – гірше з великою ймовірністю, ви знаходитиметеся ближче до гіршого кінця.
У цьому випадку, від вас буде потрібно навіть вміння читати думки, тому що вам доведеться навчитися розуміти, а що ж хотіли зробити "дизайнери", відновлювати їх логіку, доробляти те, що не було закінчено і видаляти «сміття».
І, звичайно, вам потрібно буде усунути їх помилки, змінювати (на цьому етапі по можливості мінімально) дизайн і змінювати або створювати заново схеми.
Ця стаття жодною мірою не претендує на повноту. Тут я опишу лише загальні принципи та зупинюся на деяких поширених проблемах, які доводиться вирішувати.
Набір документів
Почнемо із прикладу.
Нижче наведено деякі документи, які прийнято створювати в компанії Cisco Systems під час проектування.
CR – Суstomer Requirements, вимоги клієнта (тех. завдання).
Створюється разом із замовником та визначає вимоги до мережі.HLD – High Level Design, високорівневий дизайн на основі вимог до мережі (CR). Документ пояснює та обґрунтовує прийняті архітектурні рішення (топологія, протоколи, вибір обладнання,…). HLD не містить деталей дизайну, наприклад, про використовувані інтерфейси та IP-адреси. Також тут не обговорюється конкретна конфігурація устаткування. Цей документ скоріше призначений для пояснення технічного управління замовника ключових концепції дизайну.
LLD - Low Level Design, низькорівневий дизайн на основі високорівневого (HLD).
Він повинен містити всі деталі, необхідні для реалізації проекту, такі як інформація про те, як підключити та налаштувати обладнання. Це повний посібник з реалізації дизайну. Цей документ має надавати достатню інформацію щодо його реалізації навіть не дуже кваліфікованим персоналом.Щось, наприклад, IP-адреси, номери AS, схема фізичної комутації (cabling), може бути винесено в окремі документи, такі як NIP (Network Implementation Plan).
Побудова мережі починається після створення цих документів і відбувається у суворій відповідності до них і потім перевіряється замовником (тести) на відповідність до дизайну.
Звичайно, у різних інтеграторів, у різних клієнтів, у різних країнах вимоги до проектної документації можуть бути різними. Але хотілося б уникнути формальностей та розглянути питання по суті. Цей етап — не про проектування, а про наведення ладу і нам потрібен достатній для виконання наших завдань набір документів (схем, таблиць, описів…).
І на мій погляд, існує абсолютний мінімум, без якого неможливо ефективно контролювати мережу.
Це такі документи:
- схема (журнал) фізичної комутації (cabling)
- схема або схеми мережі із суттєвою L2/L3 інформацією
Схема фізичної комутації
У деяких невеликих компаніях роботи, пов'язані з встановленням обладнання та фізичною комутацією (cabling), перебувають у зоні відповідальності мережевих інженерів.
І тут завдання частково вирішується наступним підходом.
- використовуйте дескрипцію на інтерфейсі для опису того, що до нього підключено
- адміністративно вимкніть (shutdown) усі непідключені порти мережного обладнання
Це дасть вам можливість навіть у випадку проблеми з лінком (коли на цьому інтерфейсі не працює cdp або lldp), швидко визначити, що підключено до цього порту.
Так само ви легко зможете побачити, які порти у вас зайняті, а які вільні, що необхідно для планування підключень нового мережевого обладнання, серверів або робочих станцій.
Але зрозуміло, що якщо ви втратите доступ до обладнання, то ви втратите доступ до цієї інформації. До того ж таким чином ви не зможете запротоколювати таку важливу інформацію, як що за обладнання, з якою споживаною потужністю, з якою кількістю портів, у якій стійці знаходиться, які там патч-панелі та куди (у яку стійку/патч-панель) вони скомутовані . Тому все ж таки додаткове документування (не тільки дескрипції на устаткуванні) дуже корисне.
Ідеальним варіантом є використання додатків, створених для роботи з такою інформацією. Але можна обмежитися і простими таблицями (наприклад, Excel) або відобразити інформацію, яку ви вважаєте необхідною в L1/L2 схемах.
Важливо!
Мережевий інженер, звісно, може досить добре знати тонкощі і стандарти СКС, типи стійок, типи джерел безперебійного живлення, що таке холодний і гарячий коридор, робити правильне заземлення,… як і у принципі може знати фізику елементарних частинок чи C++. Але треба розуміти все ж таки, що все це не є його областю знання.
Тому гарною практикою є для вирішення завдань пов'язаних із встановленням, підключенням, підтримкою працездатності обладнання, а так само фізичною комутацією мати або виділені відділи або виділених людей. Зазвичай для дата центрів це дата центр інженери, а для офісу - help-desk.
Якщо такі підрозділи передбачені у вашій компанії, то питання ведення журналу фізичної комутації не є вашим завданням, і ви можете обмежитися лише дескрипцією на інтерфейсі та адміністративним виключенням портів, що не використовуються.
Схеми мережі
Нема універсального підходу до малювання схем.
Найважливіше — схеми повинні давати розуміння того, як ходитиме трафік, через які логічні та фізичні елементи вашої мережі.
Під фізичними елементами ми маємо на увазі
- активне обладнання
- інтерфейси/порти активного обладнання
Під логічними
- логічні пристрої (N7K VDC, Palo Alto VSYS, …)
- Розширення VRF
- вілани
- сабінтерфейси
- тунелі
- зони
- ...
Так само, якщо ваша мережа не є зовсім елементарною, вона складатиметься із різних сегментів.
Наприклад
- дата центр
- інтернет
- WAN
- віддалений доступ
- офісна LAN
- DMZ
- ...
Розумно матиме кілька схем, що дають як загальну картину (як трафік ходить між усіма цими сегментами), і докладне пояснення кожного окремого сегмента.
Оскільки в сучасних мережах може бути багато логічних рівнів, то, можливо, хорошим (але не обов'язковим) підходом є робити різні схеми для різних рівнів, наприклад, у разі оверлейного підходу це можуть бути такі схеми:
- накладення
- L1/L2 underlay
- L3 underlay
Звичайно, найважливішою схемою, без якої неможливо зрозуміти ідею вашого дизайну, є схема маршрутизації.
Схема маршрутизації
Як мінімум на цій схемі має бути відображено
- які протоколи маршрутизації та де використовуються
- основна інформація про налаштування протоколу маршрутизації (area/AS number/router-id/…)
- на яких пристроях відбувається редистрибуція
- де відбувається фільтрація та агрегація маршрутів
- інформація про дефолтний маршрут
Також часто корисною є L2 схема (OSI).
L2 схема (OSI)
На цій схемі може бути відображена така інформація:
- які VLAN
- які порти є trunk портами
- які порти агреговані в ether-channel (port channel), virtual port channel
- які протоколи STP і на яких пристроях використовуються
- основні налаштування STP: root/root backup, STP cost, port priority
- додаткові налаштування STP: BPDU guard/filter, root guard...
Характерні помилки при проектуванні
Приклад поганого підходу до побудови мережі.
Давайте візьмемо простий приклад побудови простої офісної локальної мережі.
Маючи досвід викладання телекому студентам, можу сказати, що фактично будь-який студент до середини другого семестру має необхідне знання (в рамках курсу, який вів я) для того, щоб налаштувати просту офісну LAN.
Що складного в тому, щоб підключити один до одного комутатори, налаштувати VLAN, SVI інтерфейси (у разі L3 комутаторів) та прописати статичний роутинг?
Все працюватиме.
Але при цьому залишаються осторонь питання, пов'язані з
- безпекою
- резервуванням
- масштабуванням мережі
- продуктивністю
- пропускною здатністю
- надійністю
- ...
Часом я чую твердження, що офісна LAN - це щось дуже просте і чую це зазвичай від інженерів (і менеджерів), які займаються всім чим завгодно, але не мережами, і кажуть вони це настільки впевнено, що не дивуйтеся, якщо LAN буде зроблено людьми з недостатньою практикою та знаннями та буде зроблено приблизно з тими помилками, які я опишу трохи нижче.
Характерні помилки дизайну рівня L1 (OSI)
- Якщо все ж таки ви відповідаєте навіть за СКС, то однією з найнеприємніших спадщин, яка вам може дістатися - це недбала і не продумана комутація.
Так само до типу L1 я б відніс помилки, пов'язані з ресурсами використовуваного обладнання, наприклад,
- недостатня смуга пропускання
- недостатній TCAM на устаткуванні (або неефективне його використання)
- недостатня продуктивність (часто відноситься до фаєрволів)
Характерні помилки дизайну рівня L2 (OSI)
Часто, коли немає хорошого розуміння, як працює STP, які потенційні проблеми він несе із собою, комутатори підключаються хаотично, з налаштуваннями за умовчанням, без додаткового тюнінгу STP.
В результаті часто маємо таке
- великий STP діаметр мережі, що може призводити до бродкастних шторм
- STP root буде визначено випадково (на основі mac адреси) і шлях трафіку буде неоптимальним
- порти, що підключаються до хостів, не будуть налаштовані як edge (portfast), що призведе до перерахунку STP при включенні/вимкненні кінцевих станцій
- мережа не буде сегментована на рівні L1/L2, внаслідок чого проблеми з будь-яким комутатором (наприклад, перевантаження по живленню) призводитиме до перерахунку STP топології та зупинки трафіку у всіх VLAN на всіх комутаторах (у тому числі й у критичному з точки зору безперервності). сервісу сегменті)
Приклади помилок у проектуванні L3 (OSI)
Декілька характерних помилок мережевиків-початківців:
- часте використання (або використання тільки) статичного роутингу
- використання неоптимальних для даного дизайну протоколів маршрутизації
- неоптимальна логічна сегментація мережі
- неоптимальне використання адресного простору, що не дозволяє агрегувати маршрути
- відсутність резервних маршрутів
- відсутність резервування для default gateway
- асиметричний роутинг при перебудові маршрутів (може бути критичним у разі NAT/PAT, statefull firewalls)
- проблеми з MTU
- при перебудові маршрутів трафік йде через інші security зони або навіть інші фаєрволи, що призводить до того, що цей трафік драпається
- погана масштабованість топології
Критерії оцінки якості дизайну
Коли ми говоримо про оптимальність/не оптимальність, ми повинні розуміти з погляду яких критеріїв ми можемо оцінити це. Ось на мій погляд найбільш істотні (але не всі) критерії (і розшифровка стосовно протоколів маршрутизації):
- масштабованість (scalability)
Наприклад, ви вирішили додати ще один дата-центр. Наскільки легко ви можете це зробити. - зручність в управлінні (managability)
Наскільки легко та безпечно робляться операційні зміни, наприклад, анонсування нової сітки чи фільтрація маршрутів - доступність (availability)
Який відсоток часу ваша система надає потрібний рівень сервісу - безпека (security)
Наскільки захищені дані, що передаються - ціна
Зміни
Основний принцип цьому етапі можна висловити формулою «не нашкодь».
Тому, навіть якщо ви не цілком згодні з дизайном і обраною реалізацією (конфігурацією), то не завжди доцільно робити зміни. Розумним підходом є ранжування всіх виявлених проблем за двома параметрами:
- наскільки легко ця проблема може бути виправлена
- наскільки великий ризик вона несе
Перш за все потрібно усунути те, що в даний час знижує рівень сервісу, що надається нижче допустимого, наприклад, проблеми, що призводять до втрат пакетів. Потім усувайте те, що найлегше і безпечніше усунути в порядку зменшення серйозності ризику (від проблем у дизайні або конфігурації, що несуть більші ризики у бік менших).
Перфекціонізм цьому етапі може бути шкідливий. Приведіть дизайн до задовільного стану та синхронізуйте конфігурацію мережі відповідно до нього.
Джерело: habr.com