Denne artikel er den anden i en serie af artikler "Sådan tager du kontrol over din netværksinfrastruktur." Indholdet af alle artikler i serien og links kan findes .
Vores mål på dette stadium er at bringe orden i dokumentationen og konfigurationen.
Ved afslutningen af denne proces bør du have det nødvendige sæt dokumenter og et netværk konfigureret i overensstemmelse med dem.
Nu vil vi ikke tale om sikkerhedsrevisioner - dette vil være emnet for tredje del.
Sværhedsgraden ved at udføre den opgave, der er tildelt på dette stadium, varierer naturligvis meget fra virksomhed til virksomhed.
Den ideelle situation er hvornår
- dit netværk blev oprettet i overensstemmelse med projektet, og du har et komplet sæt dokumenter
- er implementeret i din virksomhed til netværk
- i overensstemmelse med denne proces har du dokumenter (herunder alle de nødvendige diagrammer), der giver fuldstændige oplysninger om den aktuelle situation
I dette tilfælde er din opgave ret enkel. Du bør studere dokumenterne og gennemgå alle de ændringer, der er foretaget.
I værste fald vil du have
- et netværk skabt uden et projekt, uden en plan, uden godkendelse, af ingeniører, der ikke har et tilstrækkeligt kvalifikationsniveau,
- med kaotiske, udokumenterede forandringer, med en masse "skrald" og suboptimale løsninger
Det er klart, at din situation er et sted midt imellem, men desværre er der på denne skala af bedre – værre stor sandsynlighed for, at du kommer tættere på den værste ende.
I dette tilfælde har du også brug for evnen til at læse tanker, fordi du bliver nødt til at lære at forstå, hvad "designerne" ønskede at gøre, genoprette deres logik, afslutte det, der ikke var færdigt og fjerne "skrald".
Og selvfølgelig skal du rette deres fejl, ændre (på dette stadium så minimalt som muligt) designet og ændre eller genskabe ordningerne.
Denne artikel hævder på ingen måde at være komplet. Her vil jeg kun beskrive de generelle principper og fokusere på nogle almindelige problemer, der skal løses.
Sæt af dokumenter
Lad os starte med et eksempel.
Nedenfor er nogle dokumenter, der normalt oprettes hos Cisco Systems under design.
CR – Kundekrav, kundekrav (tekniske specifikationer).
Den oprettes i fællesskab med kunden og bestemmer netværkskravene.HLD – High Level Design, high-level design baseret på netværkskrav (CR). Dokumentet forklarer og begrunder de trufne arkitektoniske beslutninger (topologi, protokoller, hardwarevalg,...). HLD indeholder ikke designdetaljer, såsom de anvendte grænseflader og IP-adresser. Den specifikke hardwarekonfiguration er heller ikke diskuteret her. Dette dokument er snarere beregnet til at forklare centrale designkoncepter til kundens tekniske ledelse.
LLD – Low Level Design, lavt niveau design baseret på high-level design (HLD).
Den skal indeholde alle de detaljer, der er nødvendige for at implementere projektet, såsom oplysninger om, hvordan man tilslutter og konfigurerer udstyret. Dette er en komplet guide til implementering af designet. Dette dokument bør give tilstrækkelige oplysninger til, at det kan implementeres, selv af mindre kvalificeret personale.Noget, f.eks. IP-adresser, AS-numre, fysisk koblingsskema (kabling), kan "lægges ud" i separate dokumenter, som f.eks. NIP (Netværksimplementeringsplan).
Opbygningen af netværket begynder efter oprettelsen af disse dokumenter og sker i nøje overensstemmelse med dem og kontrolleres derefter af kunden (tests) for overensstemmelse med designet.
Selvfølgelig kan forskellige integratorer, forskellige kunder og forskellige lande have forskellige krav til projektdokumentation. Men jeg vil gerne undgå formaliteter og overveje spørgsmålet på dets realiteter. Denne fase handler ikke om design, men om at bringe tingene i orden, og vi har brug for et tilstrækkeligt sæt dokumenter (diagrammer, tabeller, beskrivelser...) for at udføre vores opgaver.
Og efter min mening er der et vist absolut minimum, uden hvilket det er umuligt effektivt at kontrollere netværket.
Det er følgende dokumenter:
- diagram (log) over fysisk kobling (kabler)
- netværksdiagram eller diagrammer med væsentlige L2/L3-oplysninger
Fysisk skiftediagram
I nogle små virksomheder er arbejde relateret til installation af udstyr og fysisk kobling (kabler) ansvaret for netværksingeniører.
I dette tilfælde er problemet delvist løst ved følgende fremgangsmåde.
- brug en beskrivelse på grænsefladen til at beskrive, hvad der er forbundet med den
- administrativt lukke alle ikke-tilsluttede netværksudstyrsporte
Dette vil give dig mulighed for, selv i tilfælde af et problem med linket (når cdp eller lldp ikke virker på denne grænseflade), hurtigt at bestemme, hvad der er forbundet til denne port.
Du kan også nemt se, hvilke porte der er optaget og hvilke der er ledige, hvilket er nødvendigt for planlægning af tilslutninger af nyt netværksudstyr, servere eller arbejdsstationer.
Men det er klart, at hvis du mister adgangen til udstyret, mister du også adgangen til disse oplysninger. Derudover vil du på denne måde ikke være i stand til at registrere så vigtige oplysninger som hvilken slags udstyr, hvilket strømforbrug, hvor mange porte, hvilket rack det er i, hvilke patchpaneler er der og hvor (i hvilket rack/patch panel) ) de er forbundet. Derfor er yderligere dokumentation (ikke kun beskrivelser på udstyret) stadig meget nyttig.
Den ideelle mulighed er at bruge applikationer designet til at arbejde med denne type information. Men du kan begrænse dig til simple tabeller (for eksempel i Excel) eller vise de oplysninger, som du anser for nødvendige i L1/L2-diagrammer.
Vigtigt!
En netværksingeniør kan selvfølgelig ret godt kende til forviklingerne og standarderne for SCS, typer af stativer, typer af uafbrydelige strømforsyninger, hvad en kold og varm gang er, hvordan man laver korrekt jordforbindelse... ligesom, i princippet, han kan kende elementarpartiklers fysik eller C++. Men man må stadig forstå, at alt dette ikke er hans vidensområde.
Derfor er det god praksis at have enten dedikerede afdelinger eller dedikerede folk til at løse problemer i forbindelse med installation, tilslutning, vedligeholdelse af udstyr samt fysisk omskiftning. Normalt for datacentre er dette datacenteringeniører, og for et kontor er det help-desk.
Hvis sådanne opdelinger er tilvejebragt i din virksomhed, er problemerne med at logge fysisk skift ikke din opgave, og du kan kun begrænse dig til beskrivelse på grænsefladen og administrativ lukning af ubrugte porte.
Netværksdiagrammer
Der er ingen universel tilgang til at tegne diagrammer.
Det vigtigste er, at diagrammerne skal give en forståelse af, hvordan trafikken vil flyde, gennem hvilke logiske og fysiske elementer i dit netværk.
Med fysiske elementer mener vi
- aktivt udstyr
- interfaces/porte af aktivt udstyr
Under logisk -
- logiske enheder (N7K VDC, Palo Alto VSYS, ...)
- VRF forlængelse
- Vilans
- undergrænseflader
- tunneler
- zone
- ...
Desuden, hvis dit netværk ikke er helt elementært, vil det bestå af forskellige segmenter.
For eksempel
- datacenter
- Internet
- WAN
- fjernadgang
- kontor LAN
- DMZ
- ...
Det er klogt at have flere diagrammer, der både giver det store billede (hvordan trafikken flyder mellem alle disse segmenter) og en detaljeret forklaring af hvert enkelt segment.
Da der i moderne netværk kan være mange logiske lag, er det måske en god (men ikke nødvendig) tilgang at lave forskellige kredsløb til forskellige lag, for eksempel i tilfælde af en overlejringstilgang kunne dette være følgende kredsløb:
- overlay
- L1/L2 underlag
- L3 underlag
Selvfølgelig er det vigtigste diagram, uden hvilket det er umuligt at forstå ideen om dit design, rutediagrammet.
Ruteplan
Som minimum bør dette diagram afspejle
- hvilke routingprotokoller der bruges og hvor
- grundlæggende oplysninger om routingprotokolindstillinger (område/AS-nummer/router-id/...)
- på hvilke enheder sker omfordeling?
- hvor filtrering og ruteaggregation finder sted
- standard ruteoplysninger
Også L2-skemaet (OSI) er ofte nyttigt.
L2-skema (OSI)
Dette diagram kan vise følgende oplysninger:
- hvilke VLAN'er
- hvilke porte er trunk porte
- hvilke porte er aggregeret i ether-kanal (portkanal), virtuel portkanal
- hvilke STP-protokoller der bruges og på hvilke enheder
- grundlæggende STP-indstillinger: root/root backup, STP-omkostninger, portprioritet
- yderligere STP-indstillinger: BPDU guard/filter, root guard...
Typiske designfejl
Et eksempel på en dårlig tilgang til at opbygge et netværk.
Lad os tage et simpelt eksempel på at bygge et simpelt kontor-LAN.
Efter at have erfaring med at undervise studerende i telekommunikation, kan jeg sige, at stort set enhver studerende i midten af andet semester har den nødvendige viden (som en del af det kursus, jeg underviste) til at oprette et simpelt kontor-LAN.
Hvad er så svært ved at forbinde switches til hinanden, opsætte VLAN'er, SVI-grænseflader (i tilfælde af L3 switches) og opsætte statisk routing?
Alt vil fungere.
Men samtidig spørgsmål vedr
- sikkerhed
- reservation
- netværksskalering
- produktivitet
- gennemløb
- pålidelighed
- ...
Fra tid til anden hører jeg udsagnet om, at et kontor-LAN er noget meget simpelt, og jeg hører normalt dette fra ingeniører (og ledere), der laver alt andet end netværk, og de siger dette så selvsikkert, at du ikke bliver overrasket, hvis LAN-netværket bliver lavet af mennesker med utilstrækkelig praksis og viden og vil blive lavet med omtrent de samme fejl, som jeg vil beskrive nedenfor.
Almindelige L1 (OSI) designfejl
- Hvis du alligevel også er ansvarlig for SCS, så er en af de mest ubehagelige arv, du kan modtage, et skødesløst og ugennemtænkt skifte.
Jeg vil også klassificere som type L1 fejl relateret til ressourcerne i det anvendte udstyr, f.eks.
- utilstrækkelig båndbredde
- utilstrækkelig TCAM på udstyr (eller ineffektiv brug af det)
- utilstrækkelig ydeevne (ofte relateret til firewalls)
Almindelige L2 (OSI) designfejl
Ofte, når der ikke er nogen god forståelse af, hvordan STP virker, og hvilke potentielle problemer det fører med sig, forbindes switches kaotisk med standardindstillinger uden yderligere STP-tuning.
Som følge heraf har vi ofte følgende
- stor STP-netværksdiameter, hvilket kan føre til broadcast-storme
- STP-roden vil blive bestemt tilfældigt (baseret på mac-adressen), og trafikstien vil være suboptimal
- porte, der er tilsluttet værter, vil ikke blive konfigureret som edge (portfast), hvilket vil føre til STP-genberegning ved tænd/sluk for slutstationer
- netværket vil ikke blive segmenteret på L1/L2-niveau, som et resultat af hvilket problemer med enhver switch (f.eks. strømoverbelastning) vil føre til en genberegning af STP-topologien og stoppe trafikken i alle VLAN'er på alle switche (inklusive en kritisk ud fra et kontinuitetsservicesegment)
Eksempler på fejl i L3 (OSI) design
Et par typiske fejl hos nybegyndere:
- Hyppig brug (eller kun brug) af statisk routing
- brug af suboptimale routingprotokoller til et givet design
- suboptimal logisk netværkssegmentering
- suboptimal brug af adresseplads, som ikke tillader rutesammenlægning
- ingen backup-ruter
- ingen reservation for standard gateway
- asymmetrisk routing ved genopbygning af ruter (kan være kritisk i tilfælde af NAT/PAT, statefull firewalls)
- problemer med MTU
- når ruter genopbygges, går trafikken gennem andre sikkerhedszoner eller endda andre firewalls, hvilket fører til, at denne trafik droppes
- dårlig topologi skalerbarhed
Kriterier for vurdering af designkvalitet
Når vi taler om optimalitet/ikke-optimalitet, skal vi forstå ud fra hvilke kriterier vi kan vurdere dette. Her er fra mit synspunkt de mest betydningsfulde (men ikke alle) kriterier (og forklaring i forhold til routingprotokoller):
- skalerbarhed
For eksempel beslutter du dig for at tilføje et andet datacenter. Hvor nemt kan du gøre det? - brugervenlighed (håndterbarhed)
Hvor nemme og sikre er driftsændringer, såsom annoncering af et nyt net eller filtreringsruter? - tilgængelighed
Hvor stor en procentdel af tiden giver dit system det nødvendige serviceniveau? - sikkerhed
Hvor sikre er de overførte data? - pris
ændringer
Det grundlæggende princip på dette stadium kan udtrykkes med formlen "gør ingen skade."
Derfor, selvom du ikke er helt enig i designet og den valgte implementering (konfiguration), er det ikke altid tilrådeligt at foretage ændringer. En rimelig tilgang er at rangere alle identificerede problemer efter to parametre:
- hvor nemt kan dette problem løses
- hvor stor risiko løber hun?
Først og fremmest er det nødvendigt at eliminere det, der i øjeblikket reducerer serviceniveauet til under det acceptable niveau, for eksempel problemer, der fører til pakketab. Ret derefter, hvad der er nemmest og sikrest at rette i faldende rækkefølge af risikoens sværhedsgrad (fra højrisikodesign- eller konfigurationsproblemer til lavrisikoproblemer).
Perfektionisme på dette stadium kan være skadeligt. Bring designet til en tilfredsstillende tilstand og synkroniser netværkskonfigurationen i overensstemmelse hermed.
Kilde: www.habr.com