Denne artikkelen er den andre i en serie artikler "Hvordan ta kontroll over nettverksinfrastrukturen din." Innholdet i alle artiklene i serien og lenker finner du .
Vårt mål på dette stadiet er å bringe orden i dokumentasjonen og konfigurasjonen.
På slutten av denne prosessen bør du ha det nødvendige settet med dokumenter og et nettverk konfigurert i samsvar med dem.
Nå skal vi ikke snakke om sikkerhetsrevisjoner - dette vil være tema for tredje del.
Vanskeligheten med å fullføre oppgaven som er tildelt på dette stadiet, varierer selvfølgelig veldig fra bedrift til bedrift.
Den ideelle situasjonen er når
- nettverket ditt ble opprettet i samsvar med prosjektet, og du har et komplett sett med dokumenter
- har blitt implementert i din bedrift for nettverk
- i samsvar med denne prosessen har du dokumenter (inkludert alle nødvendige diagrammer) som gir fullstendig informasjon om den nåværende situasjonen
I dette tilfellet er oppgaven din ganske enkel. Du bør studere dokumentene og gjennomgå alle endringene som er gjort.
I verste fall har du det
- et nettverk opprettet uten et prosjekt, uten en plan, uten godkjenning, av ingeniører som ikke har et tilstrekkelig kvalifikasjonsnivå,
- med kaotiske, udokumenterte endringer, med mye «søppel» og suboptimale løsninger
Det er klart at situasjonen din er et sted midt i mellom, men dessverre, på denne skalaen fra bedre – verre, er det stor sannsynlighet for at du kommer nærmere den verste enden.
I dette tilfellet trenger du også evnen til å lese tanker, fordi du må lære å forstå hva "designerne" ønsket å gjøre, gjenopprette logikken deres, fullføre det som ikke var ferdig og fjerne "søppel".
Og selvfølgelig må du rette opp feilene deres, endre (på dette stadiet så minimalt som mulig) designet og endre eller gjenopprette ordningene.
Denne artikkelen hevder på ingen måte å være fullstendig. Her vil jeg kun beskrive de generelle prinsippene og fokusere på noen vanlige problemer som må løses.
Sett med dokumenter
La oss starte med et eksempel.
Nedenfor er noen dokumenter som vanligvis opprettes hos Cisco Systems under design.
CR – Kundekrav, kundekrav (tekniske spesifikasjoner).
Den opprettes i fellesskap med kunden og bestemmer nettverkskravene.HLD – High Level Design, høynivådesign basert på nettverkskrav (CR). Dokumentet forklarer og begrunner de arkitektoniske beslutningene som er tatt (topologi, protokoller, maskinvarevalg,...). HLD inneholder ikke designdetaljer, slik som grensesnitt og IP-adresser som brukes. Den spesifikke maskinvarekonfigurasjonen er heller ikke diskutert her. Snarere er dette dokumentet ment å forklare sentrale designkonsepter til kundens tekniske ledelse.
LLD – Lavt nivådesign, lavnivådesign basert på høynivådesign (HLD).
Den skal inneholde alle nødvendige detaljer for å implementere prosjektet, for eksempel informasjon om hvordan du kobler til og konfigurerer utstyret. Dette er en komplett guide for implementering av designet. Dette dokumentet bør gi tilstrekkelig informasjon for implementeringen selv av mindre kvalifisert personell.Noe, for eksempel IP-adresser, AS-nummer, fysisk koblingsskjema (kabling), kan «settes ut» i separate dokumenter, som f.eks. NIP (Nettverksimplementeringsplan).
Byggingen av nettverket begynner etter opprettelsen av disse dokumentene og skjer i strengt samsvar med dem og blir deretter kontrollert av kunden (tester) for samsvar med designet.
Selvfølgelig kan forskjellige integratorer, forskjellige kunder og forskjellige land ha forskjellige krav til prosjektdokumentasjon. Men jeg vil gjerne unngå formaliteter og vurdere saken på dens meritter. Dette stadiet handler ikke om design, men om å sette ting i orden, og vi trenger et tilstrekkelig sett med dokumenter (diagrammer, tabeller, beskrivelser...) for å fullføre oppgavene våre.
Og etter min mening er det et visst absolutt minimum, uten hvilket det er umulig å effektivt kontrollere nettverket.
Dette er følgende dokumenter:
- diagram (logg) over fysisk svitsjing (kabling)
- nettverksdiagram eller diagrammer med viktig L2/L3-informasjon
Fysisk koblingsskjema
I enkelte små bedrifter er arbeid knyttet til utstyrsinstallasjon og fysisk kobling (kabling) ansvaret for nettverksingeniører.
I dette tilfellet er problemet delvis løst ved følgende tilnærming.
- bruk en beskrivelse på grensesnittet for å beskrive hva som er koblet til det
- administrativt slå av alle ikke-tilkoblede nettverksutstyrsporter
Dette vil gi deg muligheten til, selv i tilfelle et problem med koblingen (når cdp eller lldp ikke fungerer på dette grensesnittet), raskt å finne ut hva som er koblet til denne porten.
Du kan også enkelt se hvilke porter som er opptatt og hvilke som er ledige, noe som er nødvendig for planlegging av tilkoblinger av nytt nettverksutstyr, servere eller arbeidsstasjoner.
Men det er klart at dersom du mister tilgangen til utstyret, mister du også tilgangen til denne informasjonen. I tillegg vil du på denne måten ikke kunne registrere så viktig informasjon som hva slags utstyr, hvilket strømforbruk, hvor mange porter, hvilket rack det er i, hvilke patchpaneler er det og hvor (i hvilket stativ/patchpanel ) de er koblet sammen. Derfor er ytterligere dokumentasjon (ikke bare beskrivelser på utstyret) fortsatt svært nyttig.
Det ideelle alternativet er å bruke applikasjoner designet for å fungere med denne typen informasjon. Men du kan begrense deg til enkle tabeller (for eksempel i Excel) eller vise informasjonen du anser som nødvendig i L1/L2-diagrammer.
Viktig!
En nettverksingeniør kan selvfølgelig kjenne ganske godt innviklene og standardene til SCS, typer stativer, typer avbruddsfri strømforsyning, hva en kald og varm gang er, hvordan man gjør riktig jording... akkurat som han i prinsippet kan kjenne til fysikken til elementærpartikler eller C++. Men man må likevel forstå at alt dette ikke er hans kunnskapsområde.
Derfor er det god praksis å ha enten dedikerte avdelinger eller dedikerte folk til å løse problemer knyttet til installasjon, tilkobling, vedlikehold av utstyr, samt fysisk kobling. Vanligvis for datasentre er dette datasenteringeniører, og for et kontor er det help-desk.
Hvis slike divisjoner er gitt i bedriften din, er ikke problemene med å logge fysisk veksling din oppgave, og du kan begrense deg til beskrivelse av grensesnittet og administrativ avslutning av ubrukte porter.
Nettverksdiagrammer
Det er ingen universell tilnærming til å tegne diagrammer.
Det viktigste er at diagrammene skal gi en forståelse av hvordan trafikken vil flyte, gjennom hvilke logiske og fysiske elementer i nettverket ditt.
Med fysiske elementer mener vi
- aktivt utstyr
- grensesnitt/porter til aktivt utstyr
Under logisk -
- logiske enheter (N7K VDC, Palo Alto VSYS, ...)
- VRF utvidelse
- Vilans
- undergrensesnitt
- tunneler
- sonen
- ...
Dessuten, hvis nettverket ditt ikke er helt elementært, vil det bestå av forskjellige segmenter.
For eksempel
- datasenter
- Internett
- WAN
- fjerntilgang
- kontor LAN
- DMZ
- ...
Det er lurt å ha flere diagrammer som gir både det store bildet (hvordan trafikken flyter mellom alle disse segmentene) og en detaljert forklaring av hvert enkelt segment.
Siden det i moderne nettverk kan være mange logiske lag, er det kanskje en god (men ikke nødvendig) tilnærming å lage forskjellige kretser for forskjellige lag, for eksempel, i tilfelle en overleggstilnærming kan dette være følgende kretser:
- overlegg
- L1/L2 underlag
- L3 underlag
Selvfølgelig er det viktigste diagrammet, uten hvilket det er umulig å forstå ideen om designet ditt, rutediagrammet.
Ruteopplegg
Som et minimum bør dette diagrammet reflektere
- hvilke rutingprotokoller som brukes og hvor
- grunnleggende informasjon om rutingprotokollinnstillinger (område/AS-nummer/ruter-id/...)
- på hvilke enheter skjer omfordeling?
- hvor filtrering og ruteaggregering skjer
- standard ruteinformasjon
Også L2-ordningen (OSI) er ofte nyttig.
L2-skjema (OSI)
Dette diagrammet kan vise følgende informasjon:
- hvilke VLANer
- hvilke porter som er trunkporter
- hvilke porter er aggregert i eter-kanal (portkanal), virtuell portkanal
- hvilke STP-protokoller som brukes og på hvilke enheter
- grunnleggende STP-innstillinger: root/root backup, STP-kostnad, portprioritet
- ekstra STP-innstillinger: BPDU-beskyttelse/filter, rotbeskyttelse...
Typiske designfeil
Et eksempel på en dårlig tilnærming til å bygge et nettverk.
La oss ta et enkelt eksempel på å bygge et enkelt kontor-LAN.
Etter å ha erfaring med å undervise studenter i telekom, kan jeg si at praktisk talt alle studenter ved midten av andre semester har den nødvendige kunnskapen (som en del av kurset jeg underviste) for å sette opp et enkelt kontor-LAN.
Hva er så vanskelig med å koble brytere til hverandre, sette opp VLAN, SVI-grensesnitt (når det gjelder L3-svitsjer) og sette opp statisk ruting?
Alt vil fungere.
Men samtidig spørsmål knyttet til
- sikkerhet
- reservasjon
- nettverksskalering
- produktivitet
- gjennomstrømning
- pålitelighet
- ...
Fra tid til annen hører jeg påstanden om at et kontor-LAN er noe veldig enkelt, og jeg hører vanligvis dette fra ingeniører (og ledere) som gjør alt annet enn nettverk, og de sier dette så selvsikkert at du ikke blir overrasket om LAN-en blir gjort av personer med utilstrekkelig praksis og kunnskap og vil bli gjort med omtrent de samme feilene som jeg vil beskrive nedenfor.
Vanlige L1 (OSI) designfeil
- Hvis du likevel også er ansvarlig for SCS, så er en av de mest ubehagelige arvene du kan motta uforsiktig og lite gjennomtenkt bytte.
Jeg vil også klassifisere som type L1 feil relatert til ressursene til utstyret som brukes, for eksempel,
- utilstrekkelig båndbredde
- utilstrekkelig TCAM på utstyr (eller ineffektiv bruk av det)
- utilstrekkelig ytelse (ofte relatert til brannmurer)
Vanlige L2 (OSI) designfeil
Ofte, når det ikke er noen god forståelse av hvordan STP fungerer og hvilke potensielle problemer det fører med seg, kobles brytere kaotisk, med standardinnstillinger, uten ekstra STP-innstilling.
Som et resultat har vi ofte følgende
- stor STP-nettverksdiameter, noe som kan føre til kringkastingsstormer
- STP-roten vil bli bestemt tilfeldig (basert på mac-adressen) og trafikkbanen vil være suboptimal
- porter koblet til verter vil ikke bli konfigurert som edge (portfast), noe som vil føre til STP omberegning når du slår på/av endestasjoner
- nettverket vil ikke bli segmentert på L1/L2-nivået, som et resultat av at problemer med enhver svitsj (for eksempel strømoverbelastning) vil føre til en omberegning av STP-topologien og stoppe trafikk i alle VLAN-er på alle svitsjer (inkludert en kritisk sett fra et kontinuitetstjenestesegment)
Eksempler på feil i L3 (OSI) design
Noen typiske feil for nybegynnere i nettverk:
- Hyppig bruk (eller kun bruk) av statisk ruting
- bruk av suboptimale rutingprotokoller for et gitt design
- suboptimal logisk nettverkssegmentering
- suboptimal bruk av adresserom, som ikke tillater ruteaggregering
- ingen reserveruter
- ingen reservasjon for standard gateway
- asymmetrisk ruting ved gjenoppbygging av ruter (kan være kritisk i tilfelle av NAT/PAT, statefull brannmurer)
- problemer med MTU
- når ruter bygges om, går trafikken gjennom andre sikkerhetssoner eller til og med andre brannmurer, noe som fører til at denne trafikken droppes
- dårlig topologi skalerbarhet
Kriterier for vurdering av designkvalitet
Når vi snakker om optimalitet/ikke-optimalitet, må vi forstå ut fra hvilke kriterier vi kan vurdere dette. Her, fra mitt synspunkt, er de mest betydningsfulle (men ikke alle) kriteriene (og forklaringen i forhold til rutingprotokoller):
- skalerbarhet
For eksempel bestemmer du deg for å legge til et annet datasenter. Hvor enkelt kan du gjøre det? - brukervennlighet (håndterbarhet)
Hvor enkle og sikre er driftsendringer, som å annonsere et nytt nett eller filtrere ruter? - tilgjengelighet
Hvor mange prosent av tiden gir systemet ditt det nødvendige servicenivået? - sikkerhet
Hvor sikre er de overførte dataene? - pris
endringer
Grunnprinsippet på dette stadiet kan uttrykkes med formelen "gjør ingen skade."
Derfor, selv om du ikke er helt enig med designet og den valgte implementeringen (konfigurasjonen), er det ikke alltid tilrådelig å gjøre endringer. En rimelig tilnærming er å rangere alle identifiserte problemer i henhold til to parametere:
- hvor enkelt kan dette problemet løses
- hvor stor risiko har hun?
Først av alt er det nødvendig å eliminere det som for øyeblikket reduserer tjenestenivået som tilbys under det akseptable nivået, for eksempel problemer som fører til pakketap. Deretter fikser det som er enklest og tryggest å fikse i synkende rekkefølge av risikoens alvorlighetsgrad (fra høyrisikodesign eller konfigurasjonsproblemer til lavrisikoproblemer).
Perfeksjonisme på dette stadiet kan være skadelig. Få designet til en tilfredsstillende tilstand og synkroniser nettverkskonfigurasjonen deretter.
Kilde: www.habr.com