See artikkel on teine artiklite sarjast „Kuidas oma võrguinfrastruktuuri juhtimine enda kätte võtta”. Sarja kõigi artiklite sisu ja lingid leiate .
Meie eesmärk selles etapis on dokumentatsiooni ja konfiguratsiooni korrastamine.
Selle protsessi lõpus peaks teil olema vajalik dokumentide komplekt ja võrk, mis on nende järgi konfigureeritud.
Nüüd me ei räägi turvaaudititest - see on kolmanda osa teema.
Selles etapis antud ülesande täitmise raskus on ettevõtteti muidugi väga erinev.
Ideaalne olukord on siis, kui
- teie võrk loodi vastavalt projektile ja teil on täielik dokumentide komplekt
- on teie ettevõttes rakendatud võrgu jaoks
- vastavalt sellele protsessile on teil dokumendid (sealhulgas kõik vajalikud diagrammid), mis annavad täielikku teavet asjade hetkeseisu kohta
Sel juhul on teie ülesanne üsna lihtne. Peaksite tutvuma dokumentidega ja üle vaatama kõik tehtud muudatused.
Halvimal juhul saate seda teha
- võrk, mis on loodud ilma projektita, ilma plaanita, ilma heakskiiduta inseneride poolt, kellel ei ole piisavat kvalifikatsiooni taset,
- kaootiliste, dokumentideta muudatustega, rohke “prügi” ja ebaoptimaalsete lahendustega
On selge, et teie olukord on kuskil vahepeal, kuid paraku on sellel paremuse-halvema skaalal suur tõenäosus, et olete lähemal halvimale lõpule.
Sel juhul on teil vaja ka mõtete lugemise oskust, sest peate õppima mõistma, mida "disainerid" tahtsid teha, taastama nende loogika, viimistlema selle, mis pooleli jäi, ja eemaldama "prügi".
Ja loomulikult peate parandama nende vead, muutma (praegusel etapil võimalikult minimaalselt) kujundust ja muutma või uuesti looma skeeme.
See artikkel ei väida kuidagi, et see on täielik. Siin kirjeldan ainult üldpõhimõtteid ja keskendun mõnele levinud probleemile, mis tuleb lahendada.
Dokumendikomplekt
Alustame näitega.
Allpool on mõned dokumendid, mis tavaliselt Cisco Systemsis projekteerimise ajal luuakse.
CR – Kliendi nõuded, kliendi nõuded (tehnilised kirjeldused).
See luuakse koos kliendiga ja määrab võrgunõuded.HLD – Kõrgetasemeline disain, kõrgetasemeline disain, mis põhineb võrgunõuetel (CR). Dokumendis selgitatakse ja põhjendatakse tehtud arhitektuurilisi otsuseid (topoloogia, protokollid, riistvara valik jne). HLD ei sisalda disaini üksikasju, nagu kasutatavad liidesed ja IP-aadressid. Samuti ei käsitleta siin konkreetset riistvara konfiguratsiooni. Selle dokumendi eesmärk on pigem selgitada kliendi tehnilisele juhtkonnale peamisi disainikontseptsioone.
LLD – Madala taseme disain, madala taseme disain, mis põhineb kõrgetasemelisel disainil (HLD).
See peaks sisaldama kõiki projekti elluviimiseks vajalikke üksikasju, näiteks teavet seadmete ühendamise ja konfigureerimise kohta. See on täielik juhend disaini rakendamiseks. See dokument peaks andma piisavalt teavet selle rakendamiseks isegi vähem kvalifitseeritud töötajate poolt.Midagi, näiteks IP-aadresse, AS-i numbreid, füüsilist lülitusskeemi (kaabeldust), saab “välja panna” eraldi dokumentidesse, näiteks NIP (Võrgu rakenduskava).
Võrgu ehitamine algab pärast nende dokumentide koostamist ja toimub nende ranges vastavuses ning seejärel kontrollib klient (testid) projekti vastavust.
Loomulikult võivad erinevatel integraatoritel, erinevatel klientidel ja erinevates riikides olla projekti dokumentatsioonile erinevad nõuded. Kuid ma sooviksin vältida formaalsusi ja kaaluda seda küsimust sisuliselt. See etapp ei seisne disainis, vaid asjade korrastamises ning oma ülesannete täitmiseks vajame piisavat kogumit dokumente (skeemid, tabelid, kirjeldused...).
Ja minu arvates on olemas teatud absoluutne miinimum, ilma milleta on võimatu võrku tõhusalt juhtida.
Need on järgmised dokumendid:
- Füüsilise lülitamise (kaabelduse) skeem (logi)
- võrguskeem või diagrammid olulise L2/L3 teabega
Füüsiline lülitusskeem
Mõnes väikeettevõttes on seadmete paigaldamise ja füüsilise ümberlülitamise (kaabeldamisega) seotud tööd võrguinseneride ülesanne.
Sel juhul lahendatakse probleem osaliselt järgmise lähenemisviisiga.
- kasutage liidesel olevat kirjeldust, et kirjeldada, mis sellega on ühendatud
- administratiivselt sulgeda kõik ühendamata võrguseadmete pordid
See annab teile võimaluse isegi lingiga seotud probleemide korral (kui cdp või lldp sellel liidesel ei tööta) kiiresti kindlaks teha, mis selle pordiga on ühendatud.
Samuti on lihtne näha, millised pordid on hõivatud ja millised vabad, mis on vajalik uute võrguseadmete, serverite või tööjaamade ühenduste planeerimiseks.
Kuid on selge, et kui kaotate juurdepääsu seadmetele, kaotate juurdepääsu ka sellele teabele. Lisaks ei saa te sel viisil salvestada sellist olulist teavet, nagu mis tüüpi seadmed, milline voolutarve, mitu porti, mis rack see on, millised patch-paneelid seal on ja kus (millises rackis/patch-paneelis ) need on ühendatud. Seetõttu on lisadokumentatsioon (mitte ainult seadmete kirjeldused) endiselt väga kasulik.
Ideaalne võimalus on kasutada seda tüüpi teabega töötamiseks mõeldud rakendusi. Kuid võite piirduda lihtsate tabelitega (näiteks Excelis) või kuvada teavet, mida peate vajalikuks L1/L2 diagrammides.
Tähtis!
Võrguinsener võib muidugi üsna hästi teada SCS-i peensusi ja standardeid, rackide tüüpe, katkematute toiteallikate tüüpe, mis on külm ja kuum vahekäik, kuidas teha korralikku maandust... nii nagu põhimõtteliselt oskab. tunnevad elementaarosakeste füüsikat ehk C++. Kuid ikkagi tuleb mõista, et see kõik ei ole tema teadmiste valdkond.
Seetõttu on hea tava, kui seadmete paigaldamise, ühendamise, hoolduse ja ka füüsilise ümberlülitamisega seotud probleeme lahendavad kas spetsiaalsed osakonnad või pühendunud inimesed. Tavaliselt on andmekeskuste jaoks selleks andmekeskuse insenerid ja kontori jaoks kasutajatugi.
Kui teie ettevõttes on sellised jaotused ette nähtud, siis füüsilise ümberlülituse logimise küsimused pole teie ülesanne ja saate piirduda ainult liidese kirjeldamise ja kasutamata portide administratiivse sulgemisega.
Võrgu diagrammid
Diagrammide joonistamisel pole universaalset lähenemist.
Kõige tähtsam on see, et diagrammid annaksid arusaama sellest, kuidas liiklus liigub, mida läbivad teie võrgu loogilised ja füüsilised elemendid.
Füüsiliste elementide all peame silmas
- aktiivne varustus
- aktiivsete seadmete liidesed/pordid
Loogilise all -
- loogilised seadmed (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- alamliideseid
- tunnelid
- tsoon
- ...
Samuti, kui teie võrk pole täiesti elementaarne, koosneb see erinevatest segmentidest.
Näiteks
- andmekeskus
- Internet
- WAN
- kaugjuurdepääs
- kontori LAN
- DMZ
- ...
Mõistlik on omada mitut diagrammi, mis annavad nii üldise pildi (kuidas liiklus liigub kõigi nende segmentide vahel) kui ka üksikasjaliku selgituse iga üksiku segmendi kohta.
Kuna tänapäevastes võrkudes võib loogilisi kihte olla palju, siis on ehk hea (kuid mitte vajalik) lähenemine teha erinevatele kihtidele erinevad vooluringid, näiteks overlay lähenemise puhul võivad selleks olla järgmised ahelad:
- ülekatte
- L1/L2 aluskate
- L3 aluskate
Muidugi on kõige olulisem diagramm, ilma milleta on võimatu oma disaini ideest aru saada, marsruutimisskeem.
Marsruutimise skeem
See diagramm peaks vähemalt kajastama
- milliseid marsruutimisprotokolle ja kus kasutatakse
- põhiteave marsruutimisprotokolli sätete kohta (ala/AS number/ruuteri ID/…)
- millistel seadmetel toimub ümberjagamine?
- kus toimub filtreerimine ja marsruudi liitmine
- marsruudi vaiketeave
Samuti on sageli kasulik L2 skeem (OSI).
L2 skeem (OSI)
See diagramm võib näidata järgmist teavet:
- millised VLAN-id
- millised pordid on magistraalpordid
- millised pordid on koondatud eeterkanaliks (pordikanaliks), virtuaalseks pordikanaliks
- milliseid STP-protokolle ja millistes seadmetes kasutatakse
- STP põhiseaded: root/root backup, STP maksumus, pordi prioriteet
- STP lisaseaded: BPDU kaitse/filter, juurkaitse...
Levinud disainivead
Näide halvast lähenemisest võrgu ehitamisel.
Võtame lihtsa näite lihtsa kontori LAN ehitamisest.
Omades üliõpilastele telekommunikatsiooni õpetamise kogemust, võin öelda, et praktiliselt igal üliõpilasel on teise semestri keskpaigaks vajalikud teadmised (minu õpetatud kursuse raames) lihtsa kontori LAN seadistamiseks.
Mis keerulist on lülitite omavahelisel ühendamisel, VLAN-ide, SVI-liideste seadistamisel (L3-lülitite puhul) ja staatilise marsruutimise seadistamisel?
Kõik läheb korda.
Kuid samal ajal küsimused, mis on seotud
- turvalisus
- reservatsioon
- võrgu skaleerimine
- tootlikkus
- läbilaskevõime
- töökindlus
- ...
Aeg-ajalt kuulen väidet, et kontori LAN on midagi väga lihtsat, ja tavaliselt kuulen seda inseneridelt (ja juhtidelt), kes teevad kõike peale võrkude, ja nad ütlevad seda nii enesekindlalt, et ärge imestage, kui LAN on on tehtud ebapiisava praktika ja teadmistega inimeste poolt ning seda tehakse ligikaudu samade vigadega, mida allpool kirjeldan.
Levinud L1 (OSI) disainivead
- Kui sellegipoolest vastutate ka SCS-i eest, on üks ebameeldivamaid pärandeid, mille võite saada, hooletu ja läbimõeldud ümberlülitamine.
Samuti liigitaksin L1 tüübiks kasutatavate seadmete ressurssidega seotud vead, näiteks
- ebapiisav ribalaius
- seadmete ebapiisav TCAM (või selle ebatõhus kasutamine)
- ebapiisav jõudlus (sageli tulemüüridega seotud)
Levinud L2 (OSI) disainivead
Sageli, kui puudub hea arusaam STP toimimisest ja sellega kaasnevatest võimalikest probleemidest, ühendatakse lülitid kaootiliselt, vaikesätetega, ilma täiendava STP häälestamiseta.
Selle tulemusena on meil sageli järgmised
- suur STP võrgu läbimõõt, mis võib põhjustada eetritorme
- STP juur määratakse juhuslikult (mac-aadressi alusel) ja liiklustee on ebaoptimaalne
- hostidega ühendatud porte ei konfigureerita servana (portfast), mis viib lõppjaamade sisse-/väljalülitamisel STP ümberarvutamiseni
- võrku ei segmenteerita L1/L2 tasemel, mille tulemusena mis tahes lülitiga seotud probleemid (nt võimsuse ülekoormus) põhjustavad STP topoloogia ümberarvutamise ja liikluse peatamise kõigis VLAN-ides kõikidel kommutaatoritel (kaasa arvatud üks kriitiline järjepidevuse teenuse segmendi seisukohast)
Näited vigadest L3 disainis (OSI)
Mõned algajate võrgutootjate tüüpilised vead:
- Staatilise marsruutimise sagedane kasutamine (või ainult kasutamine).
- suboptimaalsete marsruutimisprotokollide kasutamine antud disaini jaoks
- suboptimaalne loogiline võrgu segmenteerimine
- aadressiruumi mitteoptimaalne kasutamine, mis ei võimalda marsruutide liitmist
- varumarsruute pole
- vaikelüüsi jaoks pole broneeringut
- asümmeetriline marsruutimine marsruutide ümberehitamisel (võib olla kriitiline NAT/PAT, olekutäielike tulemüüride puhul)
- probleeme MTU-ga
- marsruutide ümberehitamisel läbib liiklus teisi turvatsoone või isegi muid tulemüüre, mistõttu liiklus katkeb
- halb topoloogia skaleeritavus
Disaini kvaliteedi hindamise kriteeriumid
Kui me räägime optimaalsusest/mitteoptimaalsusest, siis peame aru saama, milliste kriteeriumide alusel saame seda hinnata. Siin on minu seisukohast kõige olulisemad (kuid mitte kõik) kriteeriumid (ja selgitused marsruutimisprotokollide kohta):
- skaleeritavus
Näiteks otsustate lisada teise andmekeskuse. Kui lihtsalt saate seda teha? - kasutusmugavus (juhitavus)
Kui lihtsad ja turvalised on operatiivmuudatused, näiteks uue võrgustiku väljakuulutamine või marsruutide filtreerimine? - kättesaadavus
Mitu protsenti ajast pakub teie süsteem vajalikul tasemel teenust? - turvalisus
Kui turvalised on edastatavad andmed? - hind
Muutused
Põhiprintsiipi selles etapis saab väljendada valemiga "ära kahjusta".
Seega, isegi kui te ei nõustu täielikult disaini ja valitud teostuse (konfiguratsiooniga), ei ole alati soovitatav muudatusi teha. Mõistlik lähenemisviis on järjestada kõik tuvastatud probleemid kahe parameetri järgi:
- kui lihtsalt saab seda probleemi lahendada
- kui suurt riski ta kannab?
Kõigepealt on vaja kõrvaldada see, mis praegu vähendab pakutava teenuse taset alla vastuvõetava taseme, näiteks probleemid, mis põhjustavad pakettide kadumist. Seejärel parandage riski raskusastme kahanevas järjekorras seda, mida on kõige lihtsam ja ohutum parandada (alates kõrge riskiga disaini- või konfiguratsiooniprobleemidest kuni madala riskiga probleemideni).
Perfektsionism võib selles etapis olla kahjulik. Viige disain rahuldavasse olekusse ja sünkroonige võrgu konfiguratsioon vastavalt.
Allikas: www.habr.com