Hierdie artikel is die tweede in 'n reeks artikels "Hoe om beheer oor jou netwerkinfrastruktuur te neem." Die inhoud van alle artikels in die siklus en skakels kan gevind word .
Ons doel op hierdie stadium is om orde in die dokumentasie en konfigurasie te bring.
As gevolg van hierdie proses moet u die nodige stel dokumente en die netwerk in ooreenstemming daarmee opgestel hê.
Nou praat ons nie oor die sekuriteitsoudit nie – die derde deel sal hieraan gewy word.
Die kompleksiteit van die taak in hierdie stadium verskil natuurlik baie van maatskappy tot maatskappy.
Die ideale situasie is wanneer
- jou netwerk is geskep in ooreenstemming met die projek en jy het 'n volledige stel dokumente
- geïmplementeer in jou onderneming vir die netwerk
- in ooreenstemming met hierdie proses het jy dokumente (insluitend alle nodige diagramme) wat volledige inligting oor die huidige stand van sake verskaf
In hierdie geval is jou taak redelik eenvoudig. U moet die dokumente bestudeer en al die veranderinge wat aangebring is, hersien.
Op die ergste sal jy hê
- 'n netwerk geskep sonder 'n projek, sonder 'n plan, sonder koördinering, deur ingenieurs wat nie 'n voldoende vlak van kwalifikasie het nie,
- met chaotiese, ongedokumenteerde veranderinge, met baie "rommel" en suboptimale oplossings
Dit is duidelik dat jou situasie iewers tussenin is, maar ongelukkig, op hierdie skaal, beter - slegter met 'n hoë waarskynlikheid, sal jy nader aan die slegste kant wees.
In hierdie geval sal jy ook die vermoë nodig hê om gedagtes te lees, want jy sal moet leer verstaan wat die "ontwerpers" wou doen, hul logika herstel, klaarmaak wat nie klaar was nie en die "rommel" verwyder.
En natuurlik moet jy hul foute regstel, die ontwerp (op hierdie stadium so min as moontlik) verander en die skemas verander of herskep.
Hierdie artikel maak nie daarop aanspraak dat dit op enige manier volledig is nie. Hier sal ek slegs die algemene beginsels beskryf en stilstaan by 'n paar algemene probleme wat opgelos moet word.
Dokumentstel
Kom ons begin met 'n voorbeeld.
Die volgende is 'n paar van die dokumente wat gewoonlik tydens ontwerp by Cisco Systems geskep word.
CR – Kliëntvereistes, kliëntvereistes (tegniese opdrag).
Dit word saam met die kliënt geskep en definieer die vereistes vir die netwerk.HLD - Hoëvlakontwerp, hoëvlakontwerp gebaseer op netwerkvereistes (CR). Die dokument verduidelik en regverdig die argitektoniese besluite wat geneem is (topologie, protokolle, toerustingkeuse, ...). Die HLD bevat nie ontwerpbesonderhede soos koppelvlakke en IP-adresse wat gebruik word nie. Die spesifieke hardeware-konfigurasie word ook nie hier bespreek nie. Hierdie dokument is eerder bedoel om sleutelontwerpkonsepte aan die kliënt se tegniese bestuur te verduidelik.
LLD - Laevlakontwerp, laevlakontwerp gebaseer op hoëvlak (HLD).
Dit moet al die besonderhede bevat wat nodig is vir die implementering van die projek, soos inligting oor hoe om die toerusting aan te sluit en op te stel. Dit is 'n volledige gids vir ontwerpimplementering. Hierdie dokument moet voldoende inligting verskaf vir die implementering daarvan, selfs deur nie baie gekwalifiseerde personeel nie.Iets, byvoorbeeld IP-adresse, AS-nommers, fisiese skakelskema (bekabeling), kan in aparte dokumente "weergegee" word, soos bv. NIP (Netwerk-implementeringsplan).
Die konstruksie van die netwerk begin na die skepping van hierdie dokumente en vind plaas in streng ooreenstemming met hulle en dan nagegaan deur die kliënt (toetse) vir voldoening aan die ontwerp.
Natuurlik kan verskillende integreerders, verskillende kliënte, verskillende lande verskillende vereistes vir projekdokumentasie hê. Maar ek wil graag formaliteite vermy en die kwessie op meriete oorweeg. Hierdie stadium gaan nie oor ontwerp nie, maar om dinge in orde te stel, en ons benodig 'n stel dokumente (diagramme, tabelle, beskrywings ...) wat voldoende is om ons take te voltooi.
En na my mening is daar 'n sekere absolute minimum, waarsonder dit onmoontlik is om die netwerk effektief te beheer.
Dit is die volgende dokumente:
- skema (logboek) van fisiese skakeling (bekabeling)
- netwerkdiagram of diagramme met noodsaaklike L2/L3 inligting
Fisiese skakeldiagram
In sommige klein maatskappye is die werk wat verband hou met die installering van toerusting en fisiese skakeling (bekabeling) die verantwoordelikheid van netwerkingenieurs.
In hierdie geval word die probleem gedeeltelik opgelos deur die volgende benadering.
- gebruik 'n beskrywing op 'n koppelvlak om te beskryf wat daaraan gekoppel is
- alle ongekoppelde netwerktoerustingpoorte administratief afskakel
Dit sal jou die vermoë gee, selfs al is daar 'n probleem met die skakel (wanneer cdp of lldp nie op hierdie koppelvlak werk nie), om vinnig te bepaal wat aan hierdie poort gekoppel is.
Jy kan ook maklik sien watter poorte beset is en watter gratis is, wat nodig is vir die beplanning van verbindings vir nuwe netwerktoerusting, bedieners of werkstasies.
Maar dit is duidelik dat as jy toegang tot die toerusting verloor, jy toegang tot hierdie inligting sal verloor. Boonop sal u op hierdie manier nie sulke belangrike inligting kan aanteken soos watter soort toerusting, met watter kragverbruik, met hoeveel poorte, in watter rak dit geleë is, watter pleisterpanele daar is en waar (in watter rek / pleisterpaneel) is hulle verbind. Daarom is bykomende dokumentasie (nie net beskrywings op die hardeware nie) steeds baie nuttig.
Die ideale opsie is om toepassings te gebruik wat ontwerp is om met hierdie soort inligting te werk. Maar jy kan jouself beperk tot eenvoudige tabelle (byvoorbeeld in Excel) of inligting vertoon wat jy nodig ag in L1 / L2-diagramme.
Belangrik!
'n Netwerkingenieur kan natuurlik die ingewikkeldhede en standaarde van SCS, tipes rakke, tipes ononderbroke kragbronne, wat 'n koue en warm gang is, goed ken, die regte aarding doen, ... net soos hy in beginsel kan elementêre deeltjiefisika of C ++ ken. Maar ons moet nietemin verstaan dat dit alles nie sy gebied van kennis is nie.
Daarom is dit goeie praktyk om óf toegewyde departemente óf toegewyde mense te hê om probleme op te los wat verband hou met installering, verbinding, instandhouding van toerusting, sowel as fisiese skakeling. Gewoonlik vir datasentrums is dit datasentrumingenieurs, en vir die kantoor - hulptoonbank.
As sulke afdelings in u onderneming voorsien word, is die kwessies van die aanteken van die fisiese skakeling nie u taak nie, en u kan uself beperk tot 'n beskrywing oor die koppelvlak en administratiewe sluiting van ongebruikte poorte.
Netwerkdiagramme
Daar is geen universele benadering om diagramme te teken nie.
Die belangrikste is dat die skemas 'n begrip moet gee van hoe verkeer sal verloop, deur watter logiese en fisiese elemente van jou netwerk.
Met fisiese elemente bedoel ons
- aktiewe toerusting
- koppelvlakke/poorte van aktiewe toerusting
Onder logiese -
- logiese toestelle (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Wealans
- subkoppelvlakke
- tonnels
- sones
- ...
Ook, as jou netwerk nie heeltemal elementêr is nie, sal dit uit verskillende segmente bestaan.
Byvoorbeeld
- data sentrum
- Internet
- WAN
- afstand toegang
- kantoor LAN
- DMZ
- ...
Dit sal wys wees om verskeie diagramme te hê wat beide die groot prentjie (hoe verkeer tussen al hierdie segmente beweeg) en 'n gedetailleerde verduideliking van elke individuele segment gee.
Aangesien daar baie logiese vlakke in moderne netwerke kan wees, is dit waarskynlik 'n goeie (maar nie verpligte) benadering om verskillende skemas vir verskillende vlakke te maak, byvoorbeeld, in die geval van 'n oorlegbenadering, kan hierdie skemas wees:
- oortrek
- L1/L2 onderlaag
- L3 onderlaag
Natuurlik is die belangrikste skema, waarsonder dit onmoontlik is om die idee van jou ontwerp te verstaan, die roete-skema.
Routing skema
Hierdie diagram moet ten minste wys
- watter roeteringsprotokolle gebruik word en waar
- basiese inligting oor roeteringprotokolinstellings (area/AS-nommer/roeteerder-ID/...)
- Op watter toestelle word herverdeel?
- waar filtrasie en roete-aggregasie plaasvind
- verstek roete inligting
Die L2-skema (OSI) is ook dikwels nuttig.
L2-skema (OSI)
Hierdie diagram kan die volgende inligting toon:
- watter VLAN's
- watter poorte is stampoorte
- watter poorte saamgevoeg word in eter-kanaal (poortkanaal), virtuele poortkanaal
- watter STP-protokolle gebruik word en op watter toestelle
- basiese STP-instellings: wortel-/wortelrugsteun, STP-koste, poortprioriteit
- addisionele STP-instellings: BPDU-wag/filter, wortelskerm …
Algemene ontwerpfoute
'n Voorbeeld van 'n slegte benadering tot die bou van 'n netwerk.
Kom ons neem 'n eenvoudige voorbeeld van die bou van 'n eenvoudige kantoor-LAN.
Met ondervinding in die onderrig van telekommunikasie aan studente, kan ek sê dat feitlik enige student teen die middel van die tweede semester die nodige kennis het (binne die kursus wat ek aangebied het) om 'n eenvoudige kantoor-LAN op te stel.
Wat is so moeilik om skakelaars aan mekaar te koppel, VLAN's, SVI-koppelvlakke (in die geval van L3-skakelaars) op te stel en statiese roetering op te stel?
Alles sal werk.
Maar terselfdertyd, kwessies wat verband hou met
- sekuriteit
- bespreking
- netwerk skaal
- produktiwiteit
- deurset
- betroubaarheid
- ...
Van tyd tot tyd hoor ek die stelling dat die kantoor-LAN iets baie eenvoudig is en ek hoor dit gewoonlik van ingenieurs (en bestuurders) wat alles behalwe netwerke doen, en hulle sê dit so met selfvertroue dat jy nie verbaas moet wees as die LAN gemaak sal word nie. deur mense met onvoldoende oefening en kennis en sal gemaak word met ongeveer dieselfde foute as wat ek hieronder sal beskryf.
Tipiese L1-laagontwerpfoute (OSI)
- As jy nietemin ook verantwoordelik is vir die SCS, dan is een van die mees onaangename nalatenskappe wat jy kan kry, onverskillige en ondeurdagte omskakeling.
Ek sal ook foute insluit wat verband hou met die hulpbronne van die toerusting wat gebruik word, byvoorbeeld,
- onvoldoende bandwydte
- onvoldoende TCAM op toerusting (of ondoeltreffende gebruik daarvan)
- onvoldoende werkverrigting (dikwels na verwys as firewalls)
Tipiese L2-laagontwerpfoute (OSI)
Dikwels, wanneer daar geen goeie begrip is van hoe STP werk nie, watter potensiële probleme dit meebring, word skakelaars lukraak gekoppel, met verstekinstellings, sonder bykomende STP-instelling.
Gevolglik het ons dikwels die volgende
- groot STP netwerk deursnee, wat kan lei tot uitsaai storms
- STP-wortel sal ewekansig bepaal word (gebaseer op Mac-adres) en die verkeerspad sal suboptimaal wees
- poorte wat aan gashere koppel, sal nie as rand (portfast) gekonfigureer word nie, wat sal veroorsaak dat STP herbereken word wanneer die eindstasies aan / afgeskakel word
- die netwerk sal nie op die L1 / L2-vlak gesegmenteer word nie, as gevolg waarvan probleme met enige skakelaar (byvoorbeeld kragoorlading) sal lei tot die herberekening van die STP-topologie en verkeer in alle VLAN's op alle skakelaars (insluitend die een wat krities is vanuit die oogpunt van kontinuïteitsdienssegment)
Voorbeelde van foute in L3-ontwerp (OSI)
'n Paar tipiese foute van beginnernetwerkers:
- gereelde gebruik (of slegs gebruik) van statiese roetering
- gebruik van roeteringsprotokolle wat nie optimaal is vir 'n gegewe ontwerp nie
- suboptimale logiese netwerksegmentering
- suboptimale gebruik van adresruimte, wat nie roete-aggregasie toelaat nie
- gebrek aan rugsteunroetes
- geen oortolligheid vir verstekpoort nie
- asimmetriese roetering wanneer roetes herbou word (kan van kritieke belang wees in die geval van NAT/PAT, statefull firewalls)
- probleme met MTU
- by herroetering gaan verkeer deur ander sekuriteitsones of selfs ander brandmure, wat daartoe lei dat hierdie verkeer daal
- swak topologie skaalbaarheid
Ontwerpkwaliteit-evalueringskriteria
Wanneer ons praat van optimaliteit / nie-optimaliteit, moet ons verstaan in terme van watter kriteria ons dit kan evalueer. Hier, vanuit my oogpunt, is die belangrikste (maar nie alle nie) kriteria (en dekodering met betrekking tot roeteerprotokolle):
- skaalbaarheid
Byvoorbeeld, jy besluit om nog 'n datasentrum by te voeg. Hoe maklik kan jy dit doen. - gemak van bestuur
Hoe maklik en veilig is operasionele veranderinge wat gemaak moet word, soos die aankondiging van 'n nuwe maas of filterroetes - beskikbaarheid
Watter persentasie van die tyd lewer jou stelsel die vereiste vlak van diens? - sekuriteit
Hoe veilig is die oorgedrade data? - die prys
veranderinge
Die basiese beginsel op hierdie stadium kan uitgedruk word deur die formule "doen geen kwaad nie."
Daarom, selfs al stem jy nie ten volle saam met die ontwerp, en die gekose implementering (konfigurasie), is dit nie altyd raadsaam om veranderinge aan te bring nie. ’n Redelike benadering is om alle geïdentifiseerde probleme volgens twee parameters te rangskik:
- hoe maklik hierdie probleem opgelos kan word
- hoeveel risiko dit inhou
Eerstens moet jy dinge uitskakel wat tans die vlak van diens wat gelewer word tot onder die aanvaarbare vlak verlaag, byvoorbeeld probleme wat tot pakkieverliese lei. Maak dan reg wat die maklikste en veiligste is om reg te stel in volgorde van afnemende erns van risiko (van ontwerp- of konfigurasiekwessies wat 'n groter risiko tot 'n mindere een inhou).
Perfeksionisme op hierdie stadium kan skadelik wees. Bring die ontwerp tot 'n bevredigende toestand en sinchroniseer die netwerkkonfigurasie daarvolgens.
Bron: will.com