🥇Как да поемем контрол върху мрежовата инфраструктура. Глава втора. Почистване и документиране

Тази статия е втората в серия статии „Как да контролиране на мрежовата инфраструктура“. Съдържанието на всички статии от серията и връзки могат да бъдат намерени тук..

Нашата цел на този етап е да подредим документацията и конфигурацията.
На изхода на този процес трябва да имате необходимия комплект документи и мрежа, конфигурирана в съответствие с тях.

Сега няма да говорим за одит на сигурността – това ще бъде темата на третата част.

Сложността на задачата на този етап, разбира се, варира значително в зависимост от компанията.

Идеалната ситуация е, когато

вашата мрежа е изградена в съответствие с проекта и имате пълен комплект документи
във вашата компания е внедрена процес на контрол и управление на промените за мрежата
в съответствие с този процес разполагате с документи (включително всички необходими схеми), предоставящи пълна информация за актуалното положение на нещата

В такъв случай задачата ви е сравнително проста. Трябва да прегледате документите и да прегледате всички изменения, които са направени.

В най-лошия вариант ще имате

мрежа, изградена без проект, без план, без одобрение, от инженери, които нямат достатъчно ниво на квалификация,
с хаотични, незадокументированные промени, с много „боклук“ и неоптимални решения.

Разбира се, вашата ситуация е някъде между двете, но за съжаление, вероятността да се окажете по-близо до по-лошия край на тази скала е голяма.

В такъв случай от вас ще се изисква и умение да четете мисли, тъй като ще трябва да научите какво са искали да постигнат „дизайнерите“, да възстановите тяхната логика, да довършите онова, което не е завършено, и да премахнете „боклука“.
И разбира се, ще трябва да коригирате техните грешки, да променяте (на този етап по възможност минимално) дизайна и да променяте или създавате заново схемите.

Тази статия по никакъв начин не претендира за изчерпателност. Тук ще опиша само основните принципи и ще се спра на някои разпространени проблеми, с които се налага да се справим.

Комплект документи

Да започнем с пример.
По-долу са посочени някои документи, които обикновено се създават в компанията Cisco Systems при проектиране.
CR – Сustomer 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
…

Разумно е да имате няколко схеми, които дават както обща картина (как трафикът преминава между всички тези сегменти), така и подробно обяснение на всеки отделен сегмент.

Тъй като в съвременните мрежи може да има много логически нива, възможно е добър (но не задължителен) подход да бъде направена различна схема за различни нива, например, в случая на overlay подхода, тези схеми могат да бъдат:

overlay
L1/L2 underlay
L3 underlay

Разбира се, най-важната схема, без която не можете да разберете идеята на вашия дизайн, е схемата за маршрутизиране.

Схема на маршрутизиране

Най-малко на тази схема трябва да бъде отразено

какви маршрутизиращи протоколи и къде се използват
основна информация за настройките на маршрутизиращия протокол (area/AS номер/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 коренът ще бъде определен случайно (въз основа на MAC адреса), а пътят на трафика ще бъде неоптимален
портовете, свързани с хостовете, няма да бъдат настроени като edge (portfast), което ще доведе до пренапряждане на STP при включване/изключване на крайни станции
мрежата няма да бъде сегментирана на ниво L1/L2, в резултат на което проблемите с който и да е комутатор (например, претоварване на захранването) ще доведат до пренапряждане на топологията на STP и спиране на трафика във всички VLAN на всички комутатори (включително и в критичния за непрекъснатостта на услугата сегмент)

Примери за грешки в проектирането на L3 (OSI)

Някои характерни грешки на начинаещи мрежови специалисти:

често използване (или само използване) на статичен рутинг
използване на неоптимални за този дизайн протоколи за рутинг
неоптимална логическа сегментация на мрежата
неоптимално използване на адресното пространство, което не позволява агрегиране на маршрути
липса на резервни маршрути
липса на резервиране за default gateway
асиметрично маршрутизиране при реконструкция на маршрутите (може да е критично в случай на NAT/PAT, stateful firewalls)
проблеми с MTU
при реконструкция на маршрутите трафик преминава през други security зони или дори други фаерволове, което води до това трафикът да бъде блокиран
лоша мащабируемост на топологията

Критерии за оценка на качеството на дизайна

Когато говорим за оптималност/неоптималност, трябва да разберем от гледна точка на какви критерии можем да оценим това. От моята гледна точка най-съществени (но не всички) критерии (и разшифровка, приложима към протоколите за маршрутизиране):

мащабируемост (scalability)
Например, решили сте да добавите още един дата център. Колко лесно можете да го направите.
удобство в управлението (managability)
Колко лесно и безопасно се правят оперативни промени, например обявяване на нова мрежа или филтриране на маршрутите
достъпност (availability)
Какъв процент от времето вашата система предоставя необходимото ниво на услуга
сигурност (security)
Насколько защитени са предаваните данни
цена

Промени

Основният принцип на този етап може да се изрази с формулата „не вреди“.
Следователно, дори и да не сте напълно съгласни с дизайна и избраната реализация (конфигурация), не винаги е целесъобразно да правите промени. Разумният подход е да се оценят всички идентифицирани проблеми по два параметъра:

колко лесно може да бъде решен този проблем
колко голям риск носи

На първо място, трябва да се отстрани това, което в момента снижава предоставянето на услугата до допустимото ниво, например проблеми, водещи до загуба на пакети. След това отстранявайте онези, които са най-лесни и безопасни за решаване, в ред на намаляване на сериозността на риска (от проблеми в дизайна или конфигурацията, носещи големи рискове, към по-малки).

Перфекционизмът на този етап може да бъде вреден. Приведете дизайна до задоволително състояние и синхронизирайте конфигурацията на мрежата съобразно него.

Източник: habr.com