Как да поемете контрола над вашата мрежова инфраструктура. Глава втора. Почистване и документация

Тази статия е втората от поредица от статии "Как да поемете контрола над вашата мрежова инфраструктура." Можете да намерите съдържанието на всички статии от цикъла и връзките тук.

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

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

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

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

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

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

В най-лошия случай ще имате

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

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

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

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

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

Да започнем с един пример.

По-долу са някои от документите, които обикновено се създават в Cisco Systems по време на проектирането.

CR – Изисквания на клиента, изисквания на клиента (техническо задание).
Създава се съвместно с клиента и определя изискванията към мрежата.

HLD – Дизайн на високо ниво, дизайн на високо ниво, базиран на мрежовите изисквания (CR). Документът обяснява и обосновава взетите архитектурни решения (топология, протоколи, избор на оборудване,...). HLD не включва подробности за дизайна, като използвани интерфейси и IP адреси. Освен това конкретната хардуерна конфигурация не се обсъжда тук. По-скоро този документ има за цел да обясни ключови концепции за дизайн на техническото ръководство на клиента.

LLD – Дизайн на ниско ниво, дизайн на ниско ниво, базиран на високо ниво (HLD).
Той трябва да съдържа всички подробности, необходими за изпълнението на проекта, като информация за това как да свържете и настроите оборудването. Това е пълно ръководство за изпълнение на дизайна. Този документ трябва да предоставя достатъчно информация за прилагането му дори от не особено квалифициран персонал.

Нещо, например IP адреси, AS номера, схема за физическо превключване (окабеляване), може да бъде "рендирано" в отделни документи, като напр. НИП (План за внедряване на мрежата).

Изграждането на мрежата започва след създаването на тези документи и се извършва в строго съответствие с тях и след това се проверява от клиента (тестове) за съответствие с проекта.

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

И според мен има определен абсолютен минимум, без който е невъзможно да се контролира ефективно мрежата.

Това са следните документи:

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

Физическа схема на превключване

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

В този случай проблемът се решава частично чрез следния подход.

• използвайте описание на интерфейс, за да опишете какво е свързано с него
• изключете административно всички несвързани портове на мрежово оборудване

Това ще ви даде възможност, дори ако има проблем с връзката (когато cdp или lldp не работи на този интерфейс), бързо да определите какво е свързано към този порт.
Можете също така лесно да видите кои портове са заети и кои са свободни, което е необходимо за планиране на връзки за ново мрежово оборудване, сървъри или работни станции.

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

Идеалният вариант е да използвате приложения, предназначени да работят с този вид информация. Но можете да се ограничите до прости таблици (например в Excel) или да покажете информация, която смятате за необходима в диаграми L1 / L2.

Важно!

Мрежовият инженер, разбира се, може да познава доста добре тънкостите и стандартите на SCS, видовете стелажи, видовете непрекъсваеми захранвания, какво е студен и горещ коридор, да направи правилното заземяване, ... точно както по принцип може познават физиката на елементарните частици или C ++. Но все пак трябва да разберем, че всичко това не е неговата област на познание.

Затова е добра практика да има или специализирани отдели, или специализирани хора, които да решават проблеми, свързани с инсталирането, свързването, поддръжката на оборудването, както и физическото превключване. Обикновено за центрове за данни това са инженери на центрове за данни, а за офиса - бюро за помощ.

Ако във вашата компания има такива разделения, тогава проблемите с регистрирането на физическото превключване не са ваша задача и можете да се ограничите до описание на интерфейса и административно изключване на неизползваните портове.

Мрежови диаграми

Няма универсален подход за рисуване на диаграми.

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

Под физически елементи имаме предвид

• активно оборудване
• интерфейси/портове на активно оборудване

Под логично -

• логически устройства (N7K VDC, Palo Alto VSYS, ...)
• VRF разширение
• Wealans
• подинтерфейси
• тунели
• зона
• ...

Освен това, ако вашата мрежа не е напълно елементарна, тя ще се състои от различни сегменти.
Например

• център за данни
• Интернет
• WAN
• отдалечен достъп
• офис LAN
• DMZ
• ...

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

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

• подложка
• L1/L2 подложка
• L3 подложка

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

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

Като минимум тази диаграма трябва да показва

• какви протоколи за маршрутизиране се използват и къде
• основна информация за настройките на протокола за маршрутизиране (област/AS номер/router-id/...)
• На какви устройства се разпространява?
• където се извършва филтриране и агрегиране на маршрути
• информация за маршрута по подразбиране

Също така схемата L2 (OSI) често е полезна.

L2 схема (OSI)

Тази диаграма може да показва следната информация:

• кои VLAN мрежи
• кои портове са магистрални портове
• кои портове са агрегирани в ether-channel (портов канал), виртуален портов канал
• какви STP протоколи се използват и на какви устройства
• основни STP настройки: root/root архивиране, STP цена, приоритет на порта
• допълнителни STP настройки: BPDU guard/filter, root guard…

Често срещани грешки при проектирането

Пример за лош подход за изграждане на мрежа.

Нека вземем прост пример за изграждане на проста офисна локална мрежа.

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

Какво е толкова трудно в свързването на комутатори помежду си, конфигуриране на VLAN, SVI интерфейси (в случай на L3 комутатори) и настройка на статично маршрутизиране?

Всичко ще работи.

Но в същото време въпроси, свързани с

• сигурност
• резервация
• мащабиране на мрежата
• производителност
• пропускателна способност
• надеждност
• ...

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

Типични грешки в дизайна на L1 слой (OSI)

• Ако все пак вие също сте отговорни за SCS, тогава едно от най-неприятните наследства, които можете да получите, е небрежното и необмислено превключване.

Бих включил и грешки, свързани с ресурсите на използваното оборудване, напр.

• недостатъчна честотна лента
• недостатъчен TCAM на оборудването (или неефективното му използване)
• недостатъчна производителност (често наричани защитни стени)

Типични грешки в дизайна на L2 слой (OSI)

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

В резултат на това често имаме следното

• голям диаметър на STP мрежата, което може да доведе до излъчване на бури
• STP root ще бъде определен на случаен принцип (въз основа на mac адрес) и пътят на трафика ще бъде неоптимален
• портовете, свързващи се с хостове, няма да бъдат конфигурирани като edge (portfast), което ще доведе до преизчисляване на STP, когато крайните станции са включени / изключени
• мрежата няма да бъде сегментирана на ниво L1 / L2, в резултат на което проблемите с който и да е комутатор (например претоварване на мощността) ще доведат до преизчисляване на STP топологията и спиране на трафика във всички VLAN на всички комутатори (включително този, който е критичен от гледна точка на непрекъснатостта на сегмента на услугата)

Примери за грешки в дизайна на L3 (OSI)

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

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

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

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

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

промени

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

• колко лесно може да се отстрани този проблем
• колко риск носи

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

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

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