Kako prevzeti nadzor nad svojo omrežno infrastrukturo. Drugo poglavje. Čiščenje in dokumentacija

Ta članek je drugi v seriji člankov z naslovom »Kako prevzeti nadzor nad svojo omrežno infrastrukturo«. Vsebino vseh člankov v seriji in povezave najdete tukaj.

Kako prevzeti nadzor nad svojo omrežno infrastrukturo. Drugo poglavje. Čiščenje in dokumentacija

Naš cilj v tej fazi je urediti dokumentacijo in konfiguracijo.
Na koncu tega postopka bi morali imeti zahtevani nabor dokumentov in omrežje, konfigurirano v skladu z njimi.

O varnostnih pregledih zdaj ne bomo govorili – o tem bomo govorili v tretjem delu.

Zahtevnost dokončanja naloge, zastavljene v tej fazi, se seveda od podjetja do podjetja zelo razlikuje.

Idealna situacija je, ko

  • vaše omrežje je bilo zgrajeno v skladu s projektom in imate celoten nabor dokumentov
  • je bil uveden v vašem podjetju proces nadzora in upravljanja sprememb za omrežje
  • V skladu s tem postopkom imate na voljo dokumente (vključno z vsemi potrebnimi diagrami), ki zagotavljajo popolne informacije o trenutnem stanju.

V tem primeru je vaša naloga precej preprosta. Pregledati morate dokumente in pregledati vse spremembe, ki so bile narejene.

V najslabšem primeru boste imeli

  • omrežje, zgrajeno brez projekta, brez načrta, brez odobritve, s strani inženirjev, ki nimajo zadostne ravni kvalifikacij,
  • s kaotičnimi, nedokumentiranimi spremembami, z veliko "smeti" in neoptimalnimi rešitvami

Jasno je, da je vaša situacija nekje vmes, a žal ste na tej lestvici boljšega in slabšega verjetno bližje najslabšemu koncu.

V tem primeru boste potrebovali tudi sposobnost branja misli, saj se boste morali naučiti razumeti, kaj so želeli "oblikovalci" narediti, obnoviti njihovo logiko, dokončati nedokončano in odstraniti "smeti".
In seveda boste morali popraviti njihove napake, spremeniti (na tej stopnji čim manj) zasnovo in spremeniti ali ponovno ustvariti sheme.

Ta članek nikakor ni izčrpen. Tukaj bom opisal le splošna načela in izpostavil nekaj pogostih vprašanj, ki jih je treba obravnavati.

Komplet dokumentov

Začnimo s primerom.

Spodaj je navedenih nekaj dokumentov, ki se običajno ustvarijo med načrtovanjem v podjetju Cisco Systems.

CR – Zahteve strank, zahteve naročnika (tehnične specifikacije).
Ustvarjen je skupaj s stranko in opredeljuje zahteve za omrežje.

HLD – Visokonivojska zasnova, visokonivojska zasnova, ki temelji na omrežnih zahtevah (CR). Ta dokument pojasnjuje in utemeljuje sprejete arhitekturne odločitve (topologija, protokoli, izbira strojne opreme itd.). Visokonivojski dokument ne vsebuje podrobnosti zasnove, kot so uporabljeni vmesniki in naslovi IP. Prav tako ne obravnava specifičnih konfiguracij strojne opreme. Namen tega dokumenta je razložiti ključne koncepte zasnove tehničnemu vodstvu stranke.

LLD – Nizkonavnostno načrtovanje, nizkonivojsko načrtovanje, ki temelji na visokonivojskem načrtovanju (HLD).
Vsebovati mora vse podrobnosti, potrebne za izvedbo projekta, kot so informacije o priključitvi in ​​konfiguraciji opreme. Gre za celovit vodnik za izvedbo načrtovanja. Ta dokument mora zagotoviti dovolj informacij za izvedbo tudi manj usposobljenemu osebju.

Nekaj, kot so IP-naslovi, številke AS-jev, fizična komutacijska shema (kabiranje), je mogoče »premakniti« v ločene dokumente, kot na primer NIP (Načrt za izvedbo omrežja).

Gradnja omrežja se začne po izdelavi teh dokumentov in poteka v strogem skladu z njimi, nato pa jo stranka preveri (preizkusi) glede skladnosti z zasnovo.

Seveda imajo lahko različni integratorji, različne stranke in različne države različne zahteve glede projektne dokumentacije. Vendar se želimo izogniti formalnostim in obravnavati zadevno težavo. V tej fazi ne gre za načrtovanje, temveč za vzpostavitev reda, zato potrebujemo zadosten nabor dokumentov (diagramov, tabel, opisov itd.), da lahko opravimo svoje naloge.

In po mojem mnenju obstaja določen absolutni minimum, brez katerega je nemogoče učinkovito nadzorovati omrežje.

To so naslednji dokumenti:

  • fizični diagram ožičenja (kabliranje)
  • omrežni diagram ali diagrami z bistvenimi informacijami o L2/L3

Fizični preklopni diagram

V nekaterih majhnih podjetjih so dela, povezana z namestitvijo opreme in fizičnim preklapljanjem (kabliranjem), odgovornost omrežnih inženirjev.

V tem primeru je problem delno rešen z naslednjim pristopom.

  • Z opisom na vmesniku opišite, kaj je z njim povezano.
  • administrativno zaprl vsa nepovezana vrata na omrežni opremi

To vam bo omogočilo, da tudi v primeru težav s povezavo (ko cdp ali lldp ne deluje na tem vmesniku) hitro ugotovite, kaj je povezano s temi vrati.
Prav tako lahko preprosto vidite, katera vrata so zasedena in katera prosta, kar je potrebno za načrtovanje povezav za novo omrežno opremo, strežnike ali delovne postaje.

Jasno pa je, da če izgubite dostop do opreme, boste izgubili tudi dostop do teh informacij. Poleg tega na ta način ne boste mogli beležiti pomembnih informacij, kot so vrsta opreme, poraba energije, število vrat, lokacija omare, razdelilne plošče in kje (v katero omaro/razdelilno ploščo) so priključene. Zato je dodatna dokumentacija (ne le opisi opreme) zelo koristna.

Idealna možnost je uporaba aplikacij, zasnovanih za delo s tovrstnimi informacijami. Lahko pa se omejite tudi na preproste tabele (na primer v Excelu) ali pa prikažete informacije, ki se vam zdijo potrebne, v diagramih L1/L2.

Pomembno!

Omrežni inženir je seveda lahko precej dobro podkovan v zapletenosti in standardih strukturiranih kabelskih sistemov, vrstah omar, vrstah neprekinjenih napajalnikov, kaj je topel in hladen prehod, pravilni ozemljitvi in ​​tako naprej, tako kot morda pozna fiziko delcev ali C++. Vendar je pomembno razumeti, da nič od tega ni njegovo področje strokovnega znanja.

Zato je dobra praksa imeti namenske oddelke ali namenske ljudi za naloge, povezane z namestitvijo, priključitvijo in vzdrževanjem opreme ter fizičnim preklapljanjem. Za podatkovne centre to običajno pomeni inženirje podatkovnih centrov, za pisarno pa službo za pomoč uporabnikom.

Če so v vašem podjetju takšne enote na voljo, potem težave z beleženjem fizičnega preklapljanja niso vaša odgovornost in se lahko omejite le na opis vmesnika in administrativno zaustavitev neuporabljenih vrat.

Omrežni diagrami

Ni univerzalnega pristopa k risanju diagramov.

Najpomembneje je, da diagrami omogočajo razumevanje, kako bo promet tekel in skozi katere logične in fizične elemente vašega omrežja.

S fizičnimi elementi mislimo

  • aktivna oprema
  • vmesniki/vrata aktivne opreme

Logično -

  • logične naprave (N7K VDC, Palo Alto VSYS, …)
  • VRF
  • vilani
  • podvmesniki
  • tuneli
  • cona
  • ...

Prav tako bo, razen če vaše omrežje ni povsem osnovno, sestavljeno iz različnih segmentov.
Na primer

  • podatkovno središče
  • Internet
  • WAN
  • oddaljeni dostop
  • pisarniško lokalno omrežje (LAN)
  • DMZ
  • ...

Smiselno je imeti več diagramov, ki zagotavljajo tako splošno sliko (kako promet teče med vsemi temi segmenti) kot tudi podrobno razlago vsakega posameznega segmenta.

Ker imajo lahko sodobna omrežja veliko logičnih ravni, je morda dober (vendar ne potreben) pristop, da se za različne ravni uporabijo različne sheme, na primer v primeru prekrivnega pristopa so to lahko naslednje sheme:

  • prekrivni
  • Podloga L1/L2
  • Podloga L3

Seveda je najpomembnejši diagram, brez katerega je nemogoče razumeti idejo vaše zasnove, diagram usmerjanja.

Shema usmerjanja

Ta diagram bi moral vsaj odražati

  • Kateri usmerjevalni protokoli se uporabljajo in kje?
  • Osnovne informacije o nastavitvah usmerjevalnega protokola (območje/številka AS/ID usmerjevalnika/…)
  • Na katerih napravah pride do prerazporeditve?
  • kjer se izvaja filtriranje in združevanje poti
  • privzete informacije o poti

Prav tako je shema L2 (OSI) pogosto uporabna.

Shema L2 (OSI)

Ta diagram lahko odraža naslednje informacije:

  • katera VLAN-a
  • Katera vrata so trunk vrata?
  • Katera vrata so združena v eteričnem kanalu (kanal vrat), virtualnem kanalu vrat
  • Kateri STP protokoli se uporabljajo in na katerih napravah?
  • Osnovne nastavitve STP: varnostno kopiranje root/root, stroški STP, prioriteta vrat
  • Dodatne nastavitve STP: zaščita/filter BPDU, zaščita korenskega strežnika…

Tipične napake pri oblikovanju

Primer slabega pristopa k gradnji omrežja.

Vzemimo preprost primer izgradnje preprostega pisarniškega lokalnega omrežja.

Ker imam izkušnje s poučevanjem telekomunikacij študentom, lahko rečem, da ima praktično vsak študent do sredine drugega semestra potrebno znanje (v okviru predmeta, ki sem ga poučeval) za postavitev preprostega pisarniškega lokalnega omrežja.

Kaj je tako težkega pri povezovanju stikal med seboj, nastavljanju VLAN-ov, SVI vmesnikov (v primeru stikal L3) in nastavljanju statičnega usmerjanja?

Vse bo delovalo.

Toda hkrati vprašanja, povezana z

  • varnost
  • rezervacija
  • skaliranje omrežja
  • produktivnost
  • prepustnost
  • zanesljivost
  • ...

Občasno slišim, da je pisarniško lokalno omrežje (LAN) nekaj zelo preprostega, in to ponavadi slišim od inženirjev (in menedžerjev), ki se ukvarjajo z vsem razen z omrežji, in to govorijo s tako samozavestjo, da se ne presenetite, če lokalno omrežje zgradijo ljudje z nezadostnimi izkušnjami in znanjem ter je zgrajeno s približno enakimi napakami, ki jih bom opisal spodaj.

Tipične napake pri načrtovanju L1 (OSI)

  • Če ste odgovorni za SCS, je ena najbolj neprijetnih zapuščin, ki jih lahko podedujete, neprevidno in slabo premišljeno preklapljanje.

Napake, povezane z viri uporabljene opreme, bi prav tako uvrstil v vrsto L1, na primer,

  • nezadostna pasovna širina
  • nezadosten TCAM na strojni opremi (ali neučinkovita uporaba le-te)
  • slaba zmogljivost (pogosto povezana s požarnimi zidovi)

Tipične napake pri načrtovanju L2 (OSI)

Pogosto, ko ni dobrega razumevanja delovanja STP in morebitnih težav, ki jih prinaša, so stikala priključena naključno, s privzetimi nastavitvami, brez dodatnega uglaševanja STP.

Posledično imamo pogosto naslednje

  • velik premer omrežja STP, kar lahko povzroči nevihte oddajanja
  • Koreni STP bodo določeni naključno (na podlagi MAC naslova) in pot prometa ne bo optimalna.
  • Vrata, povezana z gostitelji, ne bodo konfigurirana kot robna (portfast), kar bo povzročilo ponovni izračun STP, ko bodo končne postaje omogočene/onemogočene.
  • Omrežje ne bo segmentirano na ravni L1/L2, zaradi česar bodo težave s katerim koli stikalom (na primer preobremenitev) povzročile ponovni izračun topologije STP in zaustavitev prometa v vseh VLAN-ih na vseh stikalih (vključno s tistimi v segmentu, ki je kritičen za neprekinjeno delovanje storitve).

Primeri napak pri oblikovanju L3 (OSI).

Nekaj ​​tipičnih napak, ki jih delajo začetniki v mreženju:

  • pogosta uporaba (ali samo uporaba) statičnega usmerjanja
  • uporaba usmerjevalnih protokolov, ki niso optimalni za dano zasnovo
  • neoptimalna logična segmentacija omrežja
  • neoptimalna uporaba naslovnega prostora, ki ne omogoča združevanja poti
  • pomanjkanje rezervnih poti
  • pomanjkanje redundance za privzeti prehod
  • asimetrično usmerjanje pri ponovni izgradnji poti (lahko je ključnega pomena v primeru NAT/PAT, požarnih zidov z upoštevanjem stanja)
  • Težave z MTU-jem
  • Pri preusmerjanju promet poteka skozi druga varnostna območja ali celo druge požarne zidove, kar vodi do izgube tega prometa.
  • slaba skalabilnost topologije

Kriteriji za ocenjevanje kakovosti oblikovanja

Ko govorimo o optimalnosti/neoptimalnosti, moramo razumeti merila, po katerih lahko to ocenimo. Tukaj so po mojem mnenju najpomembnejša (vendar ne vsa) merila (in njihova razlaga, ko se uporabljajo za usmerjevalne protokole):

  • skalabilnost
    Na primer, odločili ste se dodati še en podatkovni center. Kako enostavno bi bilo to?
  • enostavnost uporabe (vodljivost)
    Kako enostavno in varno je izvajati operativne spremembe, kot je najava novega omrežja ali filtriranje poti?
  • razpoložljivost
    V kolikšnem odstotku časa vaš sistem zagotavlja zahtevano raven storitve?
  • varnost
    Kako varni so posredovani podatki?
  • Cena

Spremembe

Glavno načelo na tej stopnji lahko izrazimo s formulo "ne škoduj".
Zato tudi če se z zasnovo in izbrano implementacijo (konfiguracijo) ne strinjate v celoti, ni vedno priporočljivo izvajati sprememb. Razumen pristop je, da vse ugotovljene težave razvrstite na podlagi dveh parametrov:

  • kako enostavno je mogoče odpraviti to težavo
  • kako veliko tveganje to prinaša?

Najprej obravnavajte vse težave, ki trenutno znižujejo raven storitev pod sprejemljivo raven, na primer težave, ki povzročajo izgubo paketov. Nato obravnavajte najlažje in najvarnejše težave v padajočem vrstnem redu tveganja (od težav z zasnovo ali konfiguracijo, ki predstavljajo največje tveganje, do tistih, ki predstavljajo najmanjše).

Perfekcionizem v tej fazi je lahko škodljiv. Zasnovo pripeljite do zadovoljivega stanja in ustrezno sinhronizirajte konfiguracijo omrežja.

Vir: www.habr.com

Kupite zanesljivo gostovanje za strani z DDoS zaščito, VPS VDS strežniki 🔥 Kupite zanesljivo spletno gostovanje z zaščito DDoS, VPS VDS strežniki | ProHoster