Ez a cikk a második a „Hogyan veheti át az irányítást a hálózati infrastruktúra felett” című cikksorozatban. A sorozat összes cikkének tartalma és linkjei megtalálhatók .
Célunk ebben a szakaszban a dokumentáció és a konfiguráció rendbetétele.
A folyamat végén rendelkeznie kell a szükséges dokumentumkészlettel és az ezeknek megfelelően konfigurált hálózattal.
Most nem a biztonsági auditokról fogunk beszélni – ez lesz a harmadik rész témája.
Az ebben a szakaszban kiosztott feladat elvégzésének nehézsége természetesen vállalatonként nagyon eltérő.
Az ideális helyzet az, amikor
- hálózatát a projektnek megfelelően hozták létre, és rendelkezik egy teljes dokumentumkészlettel
- bevezetésre került az Ön cégében hálózathoz
- ennek a folyamatnak megfelelően rendelkezik olyan dokumentumokkal (beleértve az összes szükséges diagramot), amelyek teljes körű tájékoztatást nyújtanak a dolgok jelenlegi állásáról
Ebben az esetben az Ön feladata meglehetősen egyszerű. Tanulmányoznia kell a dokumentumokat, és át kell tekintenie az összes végrehajtott változtatást.
A legrosszabb esetben meglesz
- projekt nélkül, terv nélkül, jóváhagyás nélkül, megfelelő képesítéssel nem rendelkező mérnökök által létrehozott hálózat,
- kaotikus, dokumentálatlan változtatásokkal, sok „szeméttel” és szuboptimális megoldásokkal
Nyilvánvaló, hogy a helyzeted valahol a kettő között van, de sajnos ezen a jobb - rosszabb skálán nagy a valószínűsége annak, hogy közelebb kerülsz a legrosszabb véghez.
Ebben az esetben a gondolatok olvasásának képességére is szükség lesz, mert meg kell tanulnia megérteni, mit akartak a „tervezők”, visszaállítani a logikáját, befejezni azt, ami nem készült el, és el kell távolítania a „szemetet”.
És természetesen ki kell javítania a hibáikat, meg kell változtatnia (ebben a szakaszban a lehető legkisebb mértékben) a tervezést, és módosítania kell vagy újra kell alkotnia a sémákat.
Ez a cikk semmiképpen sem állítja, hogy teljes. Itt csak az általános elveket írom le, és néhány közös problémára összpontosítok, amelyeket meg kell oldani.
Dokumentumok halmaza
Kezdjük egy példával.
Az alábbiakban bemutatunk néhány dokumentumot, amelyeket a Cisco Systems rendszerint a tervezés során hoz létre.
CR – Vevői követelmények, ügyféligények (műszaki előírások).
Az ügyféllel közösen jön létre, és meghatározza a hálózati követelményeket.HLD – Magas szintű tervezés, magas szintű tervezés a hálózati követelményeken (CR) alapul. A dokumentum magyarázza és indokolja a meghozott építészeti döntéseket (topológia, protokollok, hardverválasztás stb.). A HLD nem tartalmaz olyan tervezési részleteket, mint a használt interfészek és IP-címek. Ezenkívül a konkrét hardverkonfigurációt itt nem tárgyaljuk. Ennek a dokumentumnak inkább az a célja, hogy elmagyarázza a kulcsfontosságú tervezési koncepciókat az ügyfél műszaki vezetése számára.
LLD – Alacsony szintű tervezés, alacsony szintű tervezés magas szintű tervezésen (HLD) alapul.
Tartalmaznia kell a projekt megvalósításához szükséges összes részletet, például a berendezés csatlakoztatásával és konfigurálásával kapcsolatos információkat. Ez egy teljes útmutató a tervezés megvalósításához. Ennek a dokumentumnak elegendő információt kell adnia annak végrehajtásához, még kevésbé képzett személyzet számára is.Valamit, például IP-címeket, AS-számokat, fizikai kapcsolási sémát (kábelezést), külön dokumentumokba „ki lehet rakni”, mint pl. NIP (Hálózati megvalósítási terv).
A hálózat kiépítése ezen dokumentumok elkészítése után kezdődik és szigorúan azokkal összhangban történik, majd a megrendelő ellenőrzi (tesztek), hogy megfelel-e a tervnek.
Természetesen a különböző integrátorok, különböző ügyfelek és különböző országok eltérő követelményeket támasztanak a projektdokumentációval szemben. De szeretném elkerülni a formalitásokat, és érdemben megvizsgálni a kérdést. Ez a szakasz nem a tervezésről szól, hanem a rendbetételről, és kellő dokumentumkészletre (diagramok, táblázatok, leírások...) van szükségünk feladataink elvégzéséhez.
És véleményem szerint van egy bizonyos abszolút minimum, amely nélkül lehetetlen hatékonyan irányítani a hálózatot.
Ezek a következő dokumentumok:
- a fizikai kapcsolás (kábelezés) diagramja (log)
- hálózati diagram vagy diagramok lényeges L2/L3 információkkal
Fizikai kapcsolási diagram
Egyes kis cégeknél a berendezések telepítésével és a fizikai kapcsolással (kábelezéssel) kapcsolatos munka a hálózatmérnökök feladata.
Ebben az esetben a problémát részben megoldja a következő megközelítés.
- az interfészen található leírás segítségével írja le, mi kapcsolódik hozzá
- adminisztratív módon állítsa le az összes nem csatlakoztatott hálózati eszköz portját
Ez lehetőséget ad még a hivatkozással kapcsolatos probléma esetén is (amikor a cdp vagy az lldp nem működik ezen az interfészen), hogy gyorsan megállapítsa, mi csatlakozik ehhez a porthoz.
Könnyen megtekintheti azt is, hogy mely portok foglaltak és melyek szabadok, ami az új hálózati berendezések, szerverek vagy munkaállomások csatlakozásának tervezéséhez szükséges.
De nyilvánvaló, hogy ha elveszíti a hozzáférést a berendezéshez, akkor ehhez az információhoz is hozzáfér. Ráadásul így nem fog tudni olyan fontos információkat rögzíteni, mint hogy milyen berendezés, milyen áramfelvétel, hány port, milyen rackben van, milyen patch panelek vannak és hol (milyen rackben/patch panelben) ) össze vannak kötve. Ezért a kiegészítő dokumentáció (nem csak a berendezés leírása) továbbra is nagyon hasznos.
Az ideális megoldás az ilyen típusú információk kezelésére tervezett alkalmazások használata. De korlátozhatja magát egyszerű táblázatokra (például Excelben), vagy megjelenítheti a szükségesnek tartott információkat az L1/L2 diagramokban.
Fontos!
Egy hálózati mérnök természetesen elég jól ismerheti az SCS-ek bonyolultságait és szabványait, a rack típusokat, a szünetmentes tápegységek típusait, mi az a hideg-meleg folyosó, hogyan kell a megfelelő földelést elvégezni... ahogy elvileg tudja. ismeri az elemi részecskék vagy a C++ fizikáját. De még mindig meg kell érteni, hogy mindez nem az ő tudásterülete.
Ezért jó gyakorlat, ha vagy dedikált részlegek, vagy dedikált emberek állnak rendelkezésre a berendezések telepítésével, csatlakoztatásával, karbantartásával, valamint a fizikai átkapcsolással kapcsolatos problémák megoldására. Általában az adatközpontok esetében ez az adatközponti mérnökök, az irodáknál pedig a help-desk.
Ha az Ön cégénél ilyen felosztás van, akkor a fizikai átkapcsolások naplózásának kérdése nem az Ön feladata, és csak az interfész leírására és a nem használt portok adminisztratív leállítására korlátozódhat.
Hálózati diagramok
A diagramok rajzolásának nincs univerzális megközelítése.
A legfontosabb dolog az, hogy a diagramok megértsék a forgalom áramlását, a hálózat mely logikai és fizikai elemein keresztül.
Fizikai elemek alatt azt értjük
- aktív berendezés
- aktív berendezések interfészei/portjai
logikai alatt -
- logikai eszközök (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- alinterfészek
- alagutak
- zóna
- ...
Továbbá, ha a hálózat nem teljesen elemi, akkor különböző szegmensekből fog állni.
Például
- adatközpont
- Internet
- WAN
- távoli hozzáférés
- irodai LAN
- Demilitarizált zóna
- ...
Célszerű több diagrammal rendelkezni, amelyek egyrészt átfogó képet adnak (hogyan folyik a forgalom ezen szegmensek között), másrészt részletes magyarázatot adnak az egyes szegmensekről.
Mivel a modern hálózatokban sok logikai réteg létezhet, talán jó (de nem szükséges) megközelítés a különböző rétegekhez különböző áramkörök elkészítése, például overlay megközelítés esetén a következő áramkörök lehetnek:
- borítás
- L1/L2 alátét
- L3 alátét
Természetesen a legfontosabb diagram, amely nélkül lehetetlen megérteni a tervezés gondolatát, az útválasztási diagram.
Útválasztási séma
Ennek a diagramnak legalább tükröznie kell
- milyen útválasztási protokollokat használnak és hol
- alapvető információk az útválasztási protokoll beállításairól (terület/AS-szám/router-azonosító/…)
- mely eszközökön történik újraelosztás?
- ahol a szűrés és az útvonal-összevonás történik
- alapértelmezett útvonal információ
Ezenkívül az L2 séma (OSI) gyakran hasznos.
L2 séma (OSI)
Ez a diagram a következő információkat jelenítheti meg:
- milyen VLAN-ok
- mely portok a fővonali portok
- mely portok aggregálódnak ether-channel (port channel), virtuális port csatornává
- milyen STP protokollokat használnak és milyen eszközökön
- alapvető STP beállítások: root/root backup, STP cost, port priority
- további STP beállítások: BPDU védő/szűrő, gyökérvédő…
Tipikus tervezési hibák
Példa a hálózatépítés rossz megközelítésére.
Vegyünk egy egyszerű példát egy egyszerű irodai LAN felépítésére.
A hallgatók telekommunikáció oktatásában szerzett tapasztalataim alapján elmondhatom, hogy a második félév közepéig gyakorlatilag minden hallgató rendelkezik a szükséges ismeretekkel (az általam tanított kurzus részeként) egy egyszerű irodai LAN felállításához.
Mi olyan nehéz a kapcsolók egymáshoz csatlakoztatásában, a VLAN-ok, SVI interfészek (L3 switchek esetén) és a statikus útválasztás beállításában?
Minden működni fog.
De ugyanakkor a kapcsolódó kérdések
- Biztonság
- foglalás
- hálózati méretezés
- termelékenység
- áteresztőképesség
- megbízhatóság
- ...
Időnként hallom azt a kijelentést, hogy az irodai LAN valami nagyon egyszerű dolog, és ezt általában olyan mérnököktől (és vezetőktől) hallom, akik mindent megtesznek, kivéve a hálózatokat, és ezt olyan magabiztosan mondják, hogy ne lepődj meg, ha a LAN lesz. elégtelen gyakorlattal és tudással rendelkező emberek csinálták, és megközelítőleg ugyanazokkal a hibákkal fogják elkövetni, mint amelyeket alább leírok.
Gyakori L1 (OSI) tervezési hibák
- Ha ennek ellenére Ön is felelős az SCS-ért, akkor az egyik legkellemetlenebb örökség, amit kaphat, a gondatlan és átgondolatlan váltás.
Az L1 típusba sorolnám a használt berendezések erőforrásaival kapcsolatos hibákat is, pl.
- elégtelen sávszélesség
- elégtelen TCAM a berendezésen (vagy annak nem megfelelő használata)
- elégtelen teljesítmény (gyakran tűzfalakkal kapcsolatos)
Gyakori L2 (OSI) tervezési hibák
Gyakran, amikor nem ismerik megfelelően az STP működését és milyen lehetséges problémákat hoz magával, a kapcsolók kaotikusan, alapértelmezett beállításokkal kapcsolódnak össze, további STP-hangolás nélkül.
Ennek eredményeként gyakran a következőket tapasztaljuk
- nagy STP hálózati átmérő, ami sugárzott viharokhoz vezethet
- Az STP gyökér meghatározása véletlenszerűen történik (a Mac-cím alapján), és a forgalmi útvonal nem lesz optimális
- a gazdagépekhez csatlakoztatott portok nem lesznek beállítva élként (portfast), ami az STP újraszámításához vezet a végállomások be- és kikapcsolásakor
- a hálózat nem lesz szegmentálva L1/L2 szinten, aminek következtében bármely kapcsolóval kapcsolatos problémák (például túlterhelés) az STP topológia újraszámítását és a forgalom leállítását eredményezik az összes VLAN-ban az összes switchen (beleértve a egy kritikus a folyamatos szolgáltatási szegmens szempontjából)
Példák az L3 (OSI) tervezés hibáira
Néhány tipikus hiba a kezdő hálózatépítőknek:
- Statikus útválasztás gyakori (vagy csak) használata
- szuboptimális útválasztási protokollok használata egy adott tervezéshez
- szuboptimális logikai hálózatszegmentáció
- a címtér szuboptimális használata, ami nem teszi lehetővé az útvonal-összesítést
- nincsenek tartalék útvonalak
- nincs foglalás az alapértelmezett átjáróhoz
- aszimmetrikus útválasztás az útvonalak újjáépítésénél (kritikus lehet NAT/PAT, állapotteljes tűzfalak esetén)
- problémák az MTU-val
- az útvonalak újjáépítésekor a forgalom más biztonsági zónákon vagy akár más tűzfalakon megy keresztül, ami a forgalom megszűnéséhez vezet
- rossz topológia skálázhatóság
A tervezési minőség értékelésének kritériumai
Amikor optimalitásról/nem-optimalitásról beszélünk, meg kell értenünk, hogy milyen szempontok alapján tudjuk ezt értékelni. Nézőpontom szerint itt vannak a legjelentősebb (de nem minden) kritériumok (és magyarázatok az útválasztási protokollokkal kapcsolatban):
- méretezhetőség
Például úgy dönt, hogy hozzáad egy másik adatközpontot. Milyen könnyen meg tudod csinálni? - könnyű kezelhetőség (kezelhetőség)
Mennyire egyszerűek és biztonságosak a működési változtatások, például egy új rács bejelentése vagy az útvonalak szűrése? - elérhetőség
Az Ön rendszere az idők hány százalékában biztosítja a szükséges szolgáltatási szintet? - Biztonság
Mennyire biztonságosak a továbbított adatok? - ár
változások
Az alapelv ebben a szakaszban a „ne árts” formulával fejezhető ki.
Ezért még ha nem is ért teljesen egyet a tervezéssel és a választott megvalósítással (konfigurációval), nem mindig érdemes változtatásokat végrehajtani. Egy ésszerű megközelítés az összes azonosított problémát két paraméter szerint rangsorolni:
- milyen könnyen orvosolható ez a probléma
- mekkora kockázatot vállal?
Mindenekelőtt meg kell szüntetni azt, ami jelenleg az elfogadható szint alá csökkenti a nyújtott szolgáltatás színvonalát, például a csomagvesztéshez vezető problémákat. Ezután a kockázat súlyosságának csökkenő sorrendjében javítsa azt, ami a legkönnyebben és a legbiztonságosabb módon javítható (a magas kockázatú tervezési vagy konfigurációs problémáktól az alacsony kockázatúakig).
A perfekcionizmus ebben a szakaszban káros lehet. Állítsa a tervezést kielégítő állapotba, és ennek megfelelően szinkronizálja a hálózati konfigurációt.
Forrás: will.com