Dit artikel is it twadde yn in searje artikels "Hoe kinne jo kontrôle nimme oer jo netwurkynfrastruktuer." De ynhâld fan alle artikels yn 'e searje en keppelings is te finen .
Us doel op dit stadium is om oarder te bringen oan 'e dokumintaasje en konfiguraasje.
Oan 'e ein fan dit proses moatte jo de nedige set dokuminten hawwe en in netwurk konfigureare yn oerienstimming mei har.
No sille wy net prate oer befeiligingskontrôles - dit sil it ûnderwerp wêze fan it tredde diel.
De muoite fan it foltôgjen fan de taak tawiisd op dit stadium, fansels, ferskilt sterk fan bedriuw ta bedriuw.
De ideale situaasje is wannear
- jo netwurk is makke yn oerienstimming mei it projekt en jo hawwe in folsleine set fan dokuminten
- is ymplementearre yn jo bedriuw foar netwurk
- yn oerienstimming mei dit proses hawwe jo dokuminten (ynklusyf alle nedige diagrammen) dy't folsleine ynformaasje jouwe oer de aktuele stân fan saken
Yn dit gefal is jo taak frij simpel. Jo moatte de dokuminten studearje en alle wizigingen besjen dy't binne makke.
Yn it slimste gefal sille jo hawwe
- in netwurk makke sûnder in projekt, sûnder in plan, sûnder goedkarring, troch yngenieurs dy't net in foldwaande nivo fan kwalifikaasjes hawwe,
- mei chaotyske, undocumented feroarings, mei in protte "garbage" en suboptimale oplossings
It is dúdlik dat jo situaasje earne tusken sit, mar spitigernôch, op dizze skaal fan better - slimmer, is d'r in hege kâns dat jo tichter by it minste ein sille wêze.
Yn dit gefal sille jo ek de mooglikheid hawwe om gedachten te lêzen, om't jo moatte leare om te begripen wat de "ûntwerpers" woene dwaan, har logika weromsette, ôfmeitsje wat net klear wie en "ôffal" ferwiderje.
En, fansels, moatte jo har flaters korrigearje, feroarje (op dit stadium sa min mooglik) it ûntwerp en feroarje of opnij oanmeitsje de skema's.
Dit artikel beweart op gjin inkelde manier folslein te wêzen. Hjir sil ik allinich de algemiene prinsipes beskriuwe en fokusje op guon mienskiplike problemen dy't moatte wurde oplost.
Set fan dokuminten
Litte wy begjinne mei in foarbyld.
Hjirûnder binne guon dokuminten dy't gewoanlik wurde makke by Cisco Systems tidens ûntwerp.
CR - Klanteasken, klanteasken (technyske spesifikaasjes).
It wurdt makke tegearre mei de klant en bepaalt de netwurk easken.HLD - Untwerp op hege nivo, ûntwerp op heech nivo basearre op netwurkeasken (CR). It dokumint ferklearret en rjochtfeardiget de nommen arsjitektoanyske besluten (topology, protokollen, hardware seleksje, ...). HLD befettet gjin ûntwerpdetails, lykas de brûkte ynterfaces en IP-adressen. Ek de spesifike hardware-konfiguraasje wurdt hjir net besprutsen. Dit dokumint is leaver bedoeld om wichtige ûntwerpbegripen út te lizzen oan it technyske behear fan de klant.
LLD - Untwerp op leech nivo, ûntwerp op leech nivo basearre op ûntwerp op heech nivo (HLD).
It moat alle details befetsje dy't nedich binne om it projekt út te fieren, lykas ynformaasje oer hoe't jo de apparatuer ferbine en konfigurearje. Dit is in folsleine hantlieding foar it útfieren fan it ûntwerp. Dit dokumint moat genôch ynformaasje leverje foar de ymplemintaasje, sels troch minder kwalifisearre personiel.Iets, bygelyks, IP-adressen, AS-nûmers, fysyk skeakelskema (bekabeling), kinne yn aparte dokuminten "útsteld" wurde, lykas PIN (Netwurk ymplemintaasjeplan).
De bou fan it netwurk begjint nei it meitsjen fan dizze dokuminten en komt yn strikt oerienstimming mei har en wurdt dan kontrolearre troch de klant (tests) foar neilibjen fan it ûntwerp.
Fansels kinne ferskate yntegrators, ferskate kliïnten en ferskate lannen ferskillende easken hawwe foar projektdokumintaasje. Mar ik wol formaliteiten foarkomme en de kwestje op syn fertsjinsten beskôgje. Dit poadium giet net oer ûntwerp, mar oer it yn oarder bringe fan dingen, en wy hawwe in foldwaande set fan dokuminten (diagrammen, tabellen, beskriuwingen ...) nedich om ús taken te foltôgjen.
En nei myn miening is d'r in bepaald absolute minimum, sûnder dat it ûnmooglik is om it netwurk effektyf te kontrolearjen.
Dit binne de folgjende dokuminten:
- diagram (log) fan fysike skeakeljen (bekabeling)
- netwurk diagram of diagrammen mei essinsjele L2 / L3 ynformaasje
Fysike switching diagram
Yn guon lytse bedriuwen, wurk yn ferbân mei apparatuer ynstallaasje en fysike switching (bekabeling) is de ferantwurdlikheid fan netwurk yngenieurs.
Yn dit gefal wurdt it probleem foar in part oplost troch de folgjende oanpak.
- brûk in beskriuwing op de ynterface om te beskriuwen wat der mei ferbûn is
- bestjoerlik shutdown alle net ferbûn netwurk apparatuer havens
Dit sil jo de kâns jaan, sels yn it gefal fan in probleem mei de keppeling (as cdp of lldp net wurket op dizze ynterface), om fluch te bepalen wat is ferbûn mei dizze poarte.
Jo kinne ek maklik sjen hokker havens beset binne en hokker binne fergees, wat nedich is foar it plannen fan ferbiningen fan nije netwurkapparatuer, servers of wurkstasjons.
Mar it is dúdlik dat as jo ferlieze tagong ta de apparatuer, do silst ek ferlieze tagong ta dizze ynformaasje. Boppedat kinne jo op dizze manier net sokke wichtige ynformaasje opnimme as hokker soarte apparatuer, hokker enerzjyferbrûk, hoefolle havens, yn hokker rack it is, hokker patchpanielen binne der en wêr (yn hokker rack/patchpaniel ) se binne ferbûn. Dêrom is ekstra dokumintaasje (net allinich beskriuwingen op 'e apparatuer) noch heul nuttich.
De ideale opsje is om applikaasjes te brûken ûntworpen om te wurkjen mei dit soarte ynformaasje. Mar jo kinne josels beheine ta ienfâldige tabellen (bygelyks yn Excel) of de ynformaasje werjaan dy't jo nedich achtsje yn L1 / L2-diagrammen.
Wichtich!
In netwurkyngenieur kin fansels goed witte oer de fynsinnigens en noarmen fan SCS, soarten racks, soarten unûnderbrekkende stroomfoarsjenningen, wat in kâld en waarm gong is, hoe't jo in goede grûning dwaan kinne ... lykas hy yn prinsipe kin. ken de natuerkunde fan elemintêre dieltsjes as C++. Mar men moat dochs begripe dat dit alles net syn gebiet fan kennis is.
Dêrom is it in goede praktyk om of tawijde ôfdielingen of tawijde minsken te hawwen om problemen op te lossen yn ferbân mei ynstallaasje, ferbining, ûnderhâld fan apparatuer, lykas fysike skeakeljen. Meastentiids foar datasintra is dit datacenter-yngenieurs, en foar in kantoar is it helpdesk.
As sokke divyzjes yn jo bedriuw wurde levere, dan binne de problemen fan it registrearjen fan fysike skeakeljen net jo taak, en jo kinne josels allinich beheine ta beskriuwing oer de ynterface en bestjoerlike ôfsluting fan net brûkte havens.
Netwurk diagrammen
D'r is gjin universele oanpak foar it tekenjen fan diagrammen.
It wichtichste is dat de diagrammen in begryp moatte leverje oer hoe't ferkear sil streame, troch hokker logyske en fysike eleminten fan jo netwurk.
Mei fysike eleminten bedoele wy
- aktive apparatuer
- Schnittstellen / havens fan aktive apparatuer
Under logysk -
- logyske apparaten (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- subinterfaces
- tunnels
- gebieten
- ...
Ek as jo netwurk net folslein elemintêr is, sil it bestean út ferskate segminten.
Bygelyks
- datasintrum
- it ynternet
- WAN
- tagong op ôfstân
- kantoar LAN
- DMZ
- ...
It is ferstannich om ferskate diagrammen te hawwen dy't sawol it grutte byld jouwe (hoe't ferkear tusken al dizze segminten streamt) en in detaillearre útlis fan elk yndividueel segmint.
Om't yn moderne netwurken in protte logyske lagen kinne wêze, is it miskien in goede (mar net needsaaklike) oanpak om ferskate circuits foar ferskate lagen te meitsjen, bygelyks yn it gefal fan in overlay-oanpak kin dit de folgjende circuits wêze:
- overlay
- L1/L2 underlay
- L3 ûndergrûn
Fansels is it wichtichste diagram, sûnder dat it ûnmooglik is om it idee fan jo ûntwerp te begripen, it routingdiagram.
Routing skema
Op syn minst moat dit diagram reflektearje
- hokker routingprotokollen wurde brûkt en wêr
- basisynformaasje oer rûteprotokolynstellingen (gebiet/AS-nûmer/router-id/...)
- op hokker apparaten komt werferdieling foar?
- wêr't filterjen en rûteaggregaasje foarkomt
- standert rûte ynformaasje
Ek is it L2-skema (OSI) faak nuttich.
L2-skema (OSI)
Dit diagram kin de folgjende ynformaasje sjen litte:
- wat VLANs
- hokker havens binne romp havens
- hokker havens wurde aggregearre yn ether-kanaal (haven kanaal), firtuele haven kanaal
- hokker STP-protokollen wurde brûkt en op hokker apparaten
- basic STP ynstellings: root / root backup, STP kosten, port prioriteit
- Oanfoljende STP-ynstellingen: BPDU-guard/filter, root-guard ...
Typyske ûntwerpflaters
In foarbyld fan in minne oanpak foar it bouwen fan in netwurk.
Litte wy in ienfâldich foarbyld nimme fan it bouwen fan in ienfâldich kantoar LAN.
Mei ûnderfining mei it learen fan telekom oan studinten, kin ik sizze dat praktysk elke studint yn 'e midden fan' e twadde semester de nedige kennis hat (as ûnderdiel fan 'e kursus dy't ik learde) om in ienfâldich kantoar LAN op te stellen.
Wat is sa lestich oer it ferbinen fan skeakels mei elkoar, it ynstellen fan VLAN's, SVI-ynterfaces (yn it gefal fan L3-skeakels) en it opsetten fan statyske rûtes?
Alles sil wurkje.
Mar tagelyk, fragen yn ferbân mei
- feiligens
- reservaat
- netwurk skaalfergrutting
- produktiviteit
- trochslach
- betrouberens
- ...
Fan tiid ta tiid hear ik de útspraak dat in kantoar LAN wat hiel ienfâldich is en ik hear dit meastentiids fan yngenieurs (en managers) dy't alles dogge behalve netwurken, en se sizze dit sa mei fertrouwen dat jo net fernuverje as it LAN sil wêze makke troch minsken mei ûnfoldwaande praktyk en kennis en sil makke wurde mei sawat deselde flaters dy't ik hjirûnder sil beskriuwe.
Common L1 (OSI) Untwerp flaters
- As jo nettsjinsteande ek ferantwurdlik binne foar SCS, dan is ien fan 'e meast onaangename erfenissen dy't jo kinne ûntfange, is achteleas en ûngedachte oerstap.
Ik soe ek klassifisearje as type L1 flaters yn ferbân mei de middels fan de apparatuer brûkt, bygelyks,
- net genôch bânbreedte
- net genôch TCAM op apparatuer (of net effektyf gebrûk dêrfan)
- ûnfoldwaande prestaasjes (faak relatearre oan firewalls)
Common L2 (OSI) Untwerp flaters
Faak, as d'r gjin goed begryp is fan hoe't STP wurket en hokker potinsjele problemen it mei him bringt, wurde skeakels chaotysk ferbûn, mei standertynstellingen, sûnder ekstra STP-tuning.
As gefolch hawwe wy faak it folgjende
- grutte STP netwurk diameter, dat kin liede ta útstjoering stoarmen
- STP-root wurdt willekeurich bepaald (basearre op mac-adres) en it ferkearspaad sil suboptimaal wêze
- havens ferbûn mei hosts sille net wurde konfigureare as râne (portfast), wat sil liede ta STP-herberekkening by it yn-/útskeakeljen fan einstasjons
- it netwurk sil net segmentearre wurde op it L1 / L2-nivo, wêrtroch't problemen mei elke skeakel (bygelyks oerbelêsting fan macht) sille liede ta in opnij berekkening fan 'e STP-topology en it stopjen fan ferkear yn alle VLAN's op alle skeakels (ynklusyf de ien kritysk út it eachpunt fan kontinuïteitstsjinstsegment)
Foarbylden fan flaters yn L3 (OSI) design
In pear typyske flaters fan begjinnende netwurkers:
- Faak gebrûk (of allinich gebrûk) fan statyske routing
- gebrûk fan suboptimale routingprotokollen foar in opjûne ûntwerp
- suboptimale logyske netwurksegmentaasje
- suboptimaal gebrûk fan adresromte, dy't gjin rûteaggregaasje tastean
- gjin reservekopy rûtes
- gjin reservearring foar standert gateway
- asymmetryske routing by it werbouwen fan rûtes (kin kritysk wêze yn it gefal fan NAT / PAT, statefull firewalls)
- problemen mei MTU
- as rûtes wer opboud wurde, giet ferkear troch oare befeiligingssônes of sels oare firewalls, wat liedt ta dit ferkear
- min topology scalability
Kritearia foar it beoardieljen fan ûntwerpkwaliteit
As wy prate oer optimaliteit/net-optimaliteit, moatte wy begripe út it eachpunt fan hokker kritearia wy dit evaluearje kinne. Hjir binne, út myn eachpunt, de meast wichtige (mar net alle) kritearia (en útlis yn relaasje ta routingprotokollen):
- scalability
Jo beslute bygelyks in oar datasintrum ta te foegjen. Hoe maklik kinne jo it dwaan? - gemak fan gebrûk (behearberens)
Hoe maklik en feilich binne operasjonele feroarings, lykas it oankundigjen fan in nij raster of filterrûtes? - beskikberens
Hokker persintaazje fan 'e tiid jout jo systeem it fereaske nivo fan tsjinst? - feiligens
Hoe feilich binne de oerdroegen gegevens? - de priis
Feroarings
It basisprinsipe op dit stadium kin útdrukt wurde troch de formule "doch gjin kwea."
Dêrom, sels as jo it net folslein iens binne mei it ûntwerp en de keazen ymplemintaasje (konfiguraasje), is it net altyd oan te rieden om feroaringen te meitsjen. In ridlike oanpak is om alle identifisearre problemen te rangearjen neffens twa parameters:
- hoe maklik kin dit probleem wurde reparearre
- hoefolle risiko draacht se?
Alderearst is it nedich om te eliminearjen wat op it stuit it nivo fan tsjinstferliening fermindert ûnder it akseptabele nivo, bygelyks problemen dy't liede ta pakketferlies. Reparearje dan wat it maklikste en feilichste te reparearjen is yn ôfnimmende folchoarder fan risiko-earns (fan heechrisiko-ûntwerp- of konfiguraasjeproblemen oant leechrisiko-problemen).
Perfektionisme op dit stadium kin skealik wêze. Bring it ûntwerp nei in befredigjende steat en syngronisearje de netwurkkonfiguraasje neffens.
Boarne: www.habr.com