Hogyan veheted ellenőrzésed alá a hálózati infrastruktúrát. Második fejezet. Tisztítás és dokumentálás.

Ez a cikk a "Hogyan vehetem kézbe a hálózati infrastruktúrát" ciklus második része. A ciklus minden cikkének tartalmát és linkjeit itt találja. itt.

A célunk ebben a szakaszban a dokumentáció és a konfiguráció rendbetétele.
A folyamat végén szüksége lesz a megfelelő dokumentumkészletre és a hálózatra, amely ennek megfelelően van konfigurálva.

Jelenleg nem beszélünk a biztonsági auditról – erre a harmadik rész fog foglalkozni.

A feladat összetettsége ebben a szakaszban természetesen vállalatról vállalatra változik.

Ideális esetben az a helyzet, amikor

• a hálózata a terv szerint készült, és rendelkezik a teljes dokumentációval.
• a cégében bevezetésre került a változások ellenőrzésének és irányításának folyamata a hálózat számára.
• E folyamatnak megfelelően rendelkezik a dokumentumokkal (beleértve minden szükséges ábrát), amelyek teljes körű információt nyújtanak az aktuális helyzetről.

Ebben az esetben a feladata meglehetősen egyszerű. Meg kell vizsgálnia a dokumentumokat és át kell néznie az összes végrehajtott változtatást.

A legrosszabb esetben

• a hálózata terv, tervrajz és összehangolás nélkül, elégtelen képesítéssel rendelkező mérnökök által lett létrehozva,
• kaotikus, nem dokumentált változtatásokkal, rengeteg "szeméttel" és nem optimális megoldással.

Nyilvánvaló, hogy az ön helyzete valahol a kettő között van, de sajnos ezen a skálán valószínűleg a rosszabb vége közelében fog állni.

Ebben az esetben önnek a gondolatok olvasásának képessége is szükséges lesz, mivel meg kell tanulnia, hogy mit akartak a "tervezők", helyreállítani a logikájukat, befejezni azt, ami nem került befejezésre, és eltávolítani a "szemetet".
És természetesen kezelnie kell a hibáikat, módosítani (ebben a fázisban lehetőleg minimálisan) a tervet, és módosítani vagy teljesen újra létrehozni az ábrákat.

Ez a cikk semmilyen formában nem állítja, hogy teljes körű. Csak az általános elveket írom le, és néhány gyakori problémát említek, amelyekkel szembesülni szokás.

Dokumentumkészlet

Kezdjük egy példával.

Az alábbiakban bemutatok néhány dokumentumot, amelyeket a Cisco Systems-nél szokás létrehozni a tervezés során.

CR – Ügyfélkövetelmények, a kliens követelményei (műszaki követelmény).
A megrendelővel közösen készül, és meghatározza a hálózati követelményeket.

HLD – High Level Design, magas szintű tervezés a hálózati követelmények alapján (CR). A dokumentum magyarázatot és indoklást nyújt az elfogadott architekturális döntésekről (topológia, protokollok, eszközválasztás, stb.). Az HLD nem tartalmazza a tervezési részleteket, például a használt interfészeket és IP-címeket. Ezenkívül nem tárgyaljuk az eszközök konkrét konfigurációját. Ez a dokumentum inkább a megrendelő technikai vezetésének szánt kulcsfontosságú tervezési koncepciók magyarázatára szolgál.

LLD – Low Level Design, alacsony szintű tervezés a magas szintű (HLD) alapján.
Tartalmaznia kell minden olyan részletet, amely a projekt megvalósításához szükséges, például az információt arról, hogyan kell csatlakoztatni és konfigurálni az eszközöket. Ez a tervezés megvalósításának teljes útmutatója. A dokumentumnak elegendő információt kell nyújtania a végrehajtásához még nem túl képzett személyzet számára is.

Például az IP-címek, AS számok, a fizikai kábelezés (cabling) terve külön dokumentumokba „kivezethető”, mint például NIP (Hálózati Megvalósítási Terv).

A hálózat felépítése a dokumentumok elkészítése után kezdődik, és szigorúan ezeknek megfelelően történik, majd a megrendelő általi ellenőrzés (tesztelés) következik a tervezésnek való megfelelésről.

Természetesen különböző integrátoroknál, különböző ügyfeleknél, különböző országokban a projekt dokumentációs követelményei eltérőek lehetnek. De szeretnénk elkerülni a formaságokat, és a lényegre fókuszálni. Ez a lépés nem a tervezésről szól, hanem a rendtartásról, és szükségünk van egy elegendő dokumentumhalmazra (modellek, táblázatok, leírások stb.) a feladataink végrehajtásához.

A véleményem szerint létezik egy abszolút minimum, amely nélkül nem lehet hatékonyan irányítani a hálózatot.

Ezek a következő dokumentumok:

• a fizikai kábelezési (cabling) napló ábrája
• a hálózat ábrája vagy ábrái lényeges L2/L3 információkkal

Fizikai kapcsolás ábrája

Néhány kisebb cégnél a berendezések telepítésével és a fizikai kábelezéssel (cabling) kapcsolatos feladatok a hálózati mérnökök felelősségi körébe tartoznak.

Ebben az esetben a feladat részben a következő megközelítéssel oldható meg.

• használja az interfész leírását arra, hogy leírja, mi van rá csatlakoztatva
• administratívan kapcsolja ki (shutdown) az összes csatlakozatlan hálózati portot.

Ez lehetővé teszi, hogy még akkor is, ha probléma merül fel a linken (amikor ezen a felületen a cdp vagy lldp nem működik), gyorsan meghatározhassa, mi van csatlakoztatva ehhez a porthoz.
Így könnyen láthatja, hogy mely portok foglaltak és melyek szabadok, ami szükséges az új hálózati berendezések, szerverek vagy munkaállomások csatlakoztatásának tervezéséhez.

De nyilvánvaló, hogy ha elveszíti a hozzáférést a berendezéshez, akkor ezt az információt is elveszíti. Ezenkívül így nem tudja dokumentálni az olyan fontos információkat, mint hogy milyen berendezés, mekkora a fogyasztása, hány portja van, melyik állván található, milyen patch panel-ek találhatók ott, és hova (milyen állvány/panel) vannak bekötve. Ezért a további dokumentáció (nemcsak a berendezéseken található leírások) nagyon hasznos.

Az ideális megoldás az, hogy olyan alkalmazásokat használjunk, amelyek a hasonló információk kezelésére lettek kifejlesztve. De egyszerű táblázatokkal (például Excelben) is megelégedhet, vagy megjelenítheti azokat az információkat, amelyeket fontosnak tart a L1/L2 séma szintjén.

Fontos!

A hálózati mérnök természetesen jól ismerheti az SCS részleteit és szabványait, a rack típusokat, az UPS típusokat, hogy mi a hideg és meleg folyosó, elvégezheti a helyes földelést, ... ahogyan alapvetően fizikai elveket, vagy akár a C++-ot is ismerheti. De meg kell érteni, hogy mindez nem tartozik a tudása területéhez.

Ezért jó gyakorlat az olyan feladatok megoldására, amelyek a berendezések telepítésével, csatlakoztatásával, működtetésének fenntartásával, valamint a fizikai kapcsolódással kapcsolatosak, vagy dedikált részlegeket, vagy dedikált embereket biztosítani. Általában az adatközpontok számára ez az adatközpont mérnökök, az irodák esetében pedig a helpdesk.

Ha a cégében ilyen osztályok találhatók, akkor a fizikai kapcsolatok naplózásának kérdése nem az Ön feladata, és csak a felületen lévő leírásra, valamint a nem használt portok adminisztratív letiltására korlátozódhat.

Hálózati sémák

Nincs egyetemes megközelítés a diagramok rajzolásához.

A legfontosabb az, hogy a diagramoknak meg kell mutatniuk, hogyan fog folyni a forgalom, milyen logikai és fizikai elemeket érint a hálózatában.

Fizikai elemek alatt az alábbiakat értjük:

• aktív berendezések
• aktív eszközök interfészei / portjai

Logikai alatt —

• logikai eszközök (N7K VDC, Palo Alto VSYS, …)
• VRF
• VLAN-ok
• al-interfészek
• alagút
• zónák
• …

Ha a hálózata nem teljesen egyszerű, különböző szegmensekből fog állni.
Például

• adatközpont
• internet
• WAN
• távoli hozzáférés
• irodai LAN
• DMZ
• …

Érdemes több diagramot készíteni, amelyek egyaránt bemutatják az átfogó képet (hogyan áramlik a forgalom ezeken a szegmenseken), és részletes magyarázatot adnak minden egyes szegmensekről.

Mivel a modern hálózatokban sok logikai szint lehet, hasznos (de nem kötelező) megközelítés lehet különféle diagramok készítése a különböző szintekhez; például egy overlay megközelítés esetében a következő diagramok lehetnek:

• overlay
• L1/L2 alátámasztás
• L3 alátámasztás

Természetesen a legfontosabb diagram, amely nélkül nem lehet megérteni a tervezését, a routing diagram.

Útvonalválasztási séma

Legalább ezen a diagramon tükrözve kell lennie

• mely routing protokollok és hol használatosak
• alapvető információ a routing protokolok beállításairól (area/AS number/router-id/…)
• mely eszközökön történik a redisztribúció
• hol történik az útvonalak szűrése és aggregálása
• információ a default route-ról

Gyakran hasznos lehet egy L2 diagram (OSI) is.

L2 séma (OSI)

Ezen a diagramon a következő információk tükrözhetők:

• mely VLAN-ok
• mely portok trunk portok
• mely portok aggregálva vannak ether-channel-ben (port channel), virtual port channel
• mely STP protokollok és mely eszközökön használatosak
• alapvető STP beállítások: root/root backup, STP cost, port priority
• további STP beállítások: BPDU guard/filter, root guard…

Jellemző hibák tervezéskor

Példa egy rossz megközelítésre a hálózat építésében.

Vegyünk egy egyszerű példát egy egyszerű irodai helyi hálózat felépítésére.

Tanítási tapasztalataim alapján elmondhatom, hogy szinte bármely diák a második szemeszter közepére rendelkezik a szükséges tudással (abban a kurzusban, amelyet tanítottam) ahhoz, hogy beállítsa egy egyszerű irodai LAN-t.

Mi nehéz abban, hogy összekapcsolja a switcheket, beállítsa a VLAN-t, SVI interfészeket (L3 switchek esetén) és beírja a statikus routingot?

Minden működni fog.

De közben vannak olyan kérdések, amelyek a következőkkel kapcsolatosak:

• biztonság
• tartalék
• a hálózat méretezése
• teljesítmény
• sávszélesség
• megbízhatóság
• …

Időnként hallom azt az állítást, hogy az irodai LAN nagyon egyszerű dolog, és ezt általában olyan mérnököktől (és menedzserektől) hallom, akik mindennel foglalkoznak, csak nem hálózatokkal, és olyan magabiztosan mondják, hogy ne lepődj meg, ha a LAN-t olyan emberek készítik el, akiknek hiányzik a gyakorlata és a tudása, és a hibák, amelyeket lentebb leírok, megjelennek benne.

Tipikus L1 (OSI) szintű tervezési hibák

• Ha mégis te vagy a felelős a struktúrált kábelrendszerért, akkor az egyik legrosszabb örökség, amit kaphatsz – a hanyag és megtervezhetetlen kapcsolás.

Az L1 típusú hibák közé tartoznak a használt berendezések erőforrásaival kapcsolatos hibák, például

• nem elegendő sávszélesség
• nem elegendő TCAM a berendezésen (vagy annak nem hatékony használata)
• nem megfelelő teljesítmény (gyakran a tűzfalakra vonatkozik)

Tipikus L2 (OSI) szintű tervezési hibák

Gyakran, amikor nincs jó megértés arról, hogyan működik az STP, és milyen potenciális problémákat hozhat magával, a kapcsolók kaotikusan csatlakoznak, az alapértelmezett beállításokkal, STP finomhangolása nélkül.

Ennek eredményeként gyakran az alábbiakat tapasztaljuk

• nagy STP átmérő a hálózatban, ami broadcast viharokhoz vezethet
• az STP root véletlenszerűen lesz meghatározva (a mac cím alapján), és a forgalom útja nem lesz optimális
• a hostokhoz csatlakozó portok nem lesznek edge (portfast) beállításúak, ami STP újraszámításhoz vezet a végállomások be-/kikapcsolásakor
• a hálózat nem lesz szegmentálva az L1/L2 szinten, így bármelyik kapcsoló problémája (például áramellátási túlterhelés) STP topológia újraszámításhoz és a forgalom leállításához vezet az összes VLAN-ban az összes kapcsolón (beleértve a folyamatos szolgáltatás szempontjából kritikus szegmenseket is)

Példák a L3 (OSI) tervezési hibákra

Néhány jellemző hiba kezdő hálózati szakemberek esetében:

• gyakori használat (vagy csak statikus routing használata)
• a designhoz nem optimális routing protokollok használata
• nem optimális logikai szegmentálás a hálózatban
• nem optimális címtér használat, ami megnehezíti az útvonalak aggregálását
• nincs tartalék útvonal
• nincs redundancia a default gateway számára
• aszimmetrikus útvonalválasztás útvonalak újraépítésekor (kritikus lehet NAT/PAT, állapotfüggő tűzfalak esetén)
• MTU problémák
• Út újraépítésekor a forgalom más biztonsági zónákon vagy akár más tűzfalakon halad át, ami miatt ez a forgalom eldobásra kerül
• a topológia rossz skálázhatósága

A tervezés minőségének értékelési kritériumai

Amikor az optimalitásról beszélünk, figyelembe kell vennünk, milyen szempontok alapján tudjuk ezt értékelni. Szerintem a legfontosabb (de nem minden) szempontok a következők (és azok kifejtése a routing protokollokkal kapcsolatban):

• skálázhatóság
  Például, ha úgy döntött, hogy hozzáad még egy adatközpontot. Mennyire könnyen tudja ezt megtenni?
• kezelhetőség
  Mennyire könnyen és biztonságosan végezhetők operatív változások, például új hálózat hirdetése vagy útvonalak kiszűrése
• elérhetőség
  A rendszerének hány százaléka tudja biztosítani a kívánt szolgáltatási szintet
• biztonság
  Mennyire védettek az átadott adatok
• ár

Változások

Az alapelv ezen a szakaszon a "ne árts" formulával kifejezhető.
Ezért, még akkor is, ha nem teljesen ért egyet a dizájnnal és a kiválasztott implementációval (konfigurációval), nem mindig indokolt módosításokat végrehajtani. Az ésszerű megközelítés az, ha a feltárt problémákat rangsoroljuk két paraméter alapján:

• mennyire könnyen javítható a probléma
• milyen nagy kockázatot jelent

Elsősorban el kell távolítani mindazt, ami jelenleg a szolgáltatási szintet a megengedett alá csökkenti, például a csomagvesztéshez vezető problémákat. Ezután távolítsa el a legkönnyebben és legbiztonságosabban orvosolható problémákat a kockázatok súlyosságának csökkenése szerint (a nagyobb kockázatok felé tartó tervezési vagy konfigurációs problémákból a kisebbek felé haladva).

A perfekcionizmus ebben a szakaszban káros lehet. Hozt ki a dizájnt egy kielégítő állapotba, és szinkronizálja a hálózat konfigurációját ennek megfelelően.

Forrás: habr.com