Sådan får du kontrol over dit netværksinfrastruktur. Kapitel to. Rydde op og dokumentere

Denne artikel er den anden i en serie af artikler om "Sådan får du kontrol over dit netværksinfrastruktur". Du kan finde indholdet af alle artikler i serien og links her.

Vores mål på dette tidspunkt er at få orden i dokumentationen og konfigurationen.
Udfaldet af denne proces skal være et nødvendigt sæt dokumenter og et netværk konfigureret i overensstemmelse hermed.

Nu vil vi ikke tale om sikkerhedsaudit - det vil blive dækket i tredje del.

Sværhedsgraden af opgaven på dette stadium varierer naturligvis meget fra virksomhed til virksomhed.

Den ideelle situation er, når

• dit netværk er blevet oprettet i overensstemmelse med projektet, og du har et komplet sæt dokumenter
• din virksomhed har implementeret en proces for kontrol og ændringsadministration for netværket
• I overensstemmelse med denne proces har du dokumenter (herunder alle nødvendige diagrammer), der giver fuld information om den aktuelle situation

I dette tilfælde er din opgave ret enkel. Du skal studere dokumenterne og gennemgå alle de ændringer, der er blevet foretaget.

I det værste tilfælde har du

• et netværk oprettet uden projekt, uden plan, uden godkendelse, af ingeniører, der ikke har tilstrækkelig kvalifikation,
• med kaotiske, ikke-dokumenterede ændringer, med et stort antal "skrammel" og suboptimale løsninger

Det er klart, at din situation er et sted imellem, men desværre vil du med stor sandsynlighed befinde dig nærmere den værste ende på denne skala.

I dette tilfælde vil det kræve, at du også er i stand til at læse tanker, fordi du må lære at forstå, hvad "designerne" ønskede at gøre, genopbygge deres logik, færdiggøre det, der ikke blev afsluttet, og fjerne "skrammel".
Og selvfølgelig skal du beskytte dem mod deres fejl, ændre (på dette stadium så lidt som muligt) designen og ændre eller genoprette diagrammer.

Denne artikel gør på ingen måde krav på at være udtømmende. 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.

Her er nogle dokumenter, der typisk udarbejdes i Cisco Systems under designfasen.

CR – Kunde Krav, kundens krav (teknisk specifikation).
Udformet i samarbejde med kunden og definerer kravene til netværket.

HLD – High Level Design, højniveau design baseret på netværkskrav (CR). Dokumentet forklarer og retfærdiggør de arkitektoniske beslutninger, der er truffet (topologi, protokoller, valg af udstyr,…). HLD indeholder ikke detaljerne om designet, såsom de anvendte grænseflader og IP-adresser. Den specifikke konfiguration af udstyret drøftes heller ikke her. Dette dokument er mere beregnet til at forklare nøglebegreber i designet til kundens tekniske ledelse.

LLD – Low Level Design, lavniveau design baseret på højniveau (HLD).
Det skal indeholde alle de detaljer, der er nødvendige for at implementere projektet, såsom information om, hvordan man tilslutter og konfigurerer udstyret. Dette er en fuldstændig vejledning til at implementere designet. Dette dokument skal give tilstrækkelige oplysninger til at implementere det, selv for ikke særligt kvalificeret personale.

Nogle oplysninger, såsom IP-adresser, AS-numre, fysisk kablingsskema, kan "udskilles" i separate dokumenter, såsom NIP (Network Implementation Plan).

Opbygning af netværket begynder efter oprettelsen af disse dokumenter og udføres i strengt overensstemmelse med dem og kontrolleres derefter af kunden (tests) for overensstemmelse med designet.

Selvfølgelig kan de krav, der stilles til projektokumentation, variere mellem forskellige integratorer, kunder og lande. Men vi ønsker at undgå formaliteter og fokusere på substansen. Dette trin handler ikke om design, men om at skabe orden, og vi har brug for et tilstrækkeligt sæt dokumenter (diagrammer, tabeller, beskrivelser …) til at kunne udføre vores opgaver.

Og efter min mening findes der et absolut minimum, uden hvilket det ikke er muligt effektivt at kontrollere netværket.

Disse dokumenter er:

• diagram (journal) for fysisk kabling
• diagram eller diagrammer af netværket med væsentlige L2/L3 oplysninger

Diagram for fysisk kabling

I nogle mindre virksomheder ligger ansvaret for installation af udstyr og fysisk kabling inden for netværksingeniørers område.

I dette tilfælde løses opgaven delvist ved følgende tilgang.

• brug beskrivelsen på grænsefladen til at beskrive, hvad der er tilsluttet.
• administrativt sluk alle ikke-tilsluttede porte på netværksudstyret.

Dette vil give dig mulighed for hurtigt at identificere, hvad der er tilsluttet denne port, selv i tilfælde af problemer med linjen (når CDP eller LLDP ikke fungerer på denne grænseflade).
Du vil også nemt kunne se, hvilke porte der er optaget, og hvilke der er ledige, hvilket er nødvendigt for at planlægge tilslutningen af nyt netværksudstyr, servere eller arbejdsstationer.

Men det er klart, at hvis du mister adgangen til udstyret, vil du også miste adgangen til disse informationer. Desuden vil du på denne måde ikke kunne dokumentere sådanne vigtige oplysninger som hvilken udstyr der er, hvilken effekt det forbruger, hvor mange porte det har, hvilket rack det står i, hvilke patch-paneler der er der, og hvor (i hvilket rack/patch-panel) de er forbundet. Derfor er det ekstra dokumentation (ikke kun beskrivelser på udstyret) meget nyttigt.

Den ideelle løsning er at bruge applikationer, der er designet til at arbejde med denne type information. Men du kan også nøjes med enkle tabeller (f.eks. i Excel) eller præsentere informationen, som du finder nødvendig, i L1/L2 diagrammer.

Vigtigt!

En netværksingeniør kan selvfølgelig have en god forståelse for nuancerne og standarderne for struktureret kabling, typer racks, typer af UPS’er, hvad kold og varm gang er, og hvordan man foretager korrekt jording, … ligesom han i princippet kan kende til fysikken i elementarpartikler eller C++. Men man skal forstå, at det hele ikke nødvendigvis er hans område af viden.

Derfor er det en god praksis at have enten dedikerede afdelinger eller dedikerede personer til at løse opgaver relateret til installation, tilslutning, vedligeholdelse af udstyrets drift, såvel som fysisk kabling. Normalt er dette datacenteringeniører for datacentre og help-desk for kontorer.

Hvis sådanne enheder er inkluderet i din virksomhed, er spørgsmål vedrørende føring af log over fysisk kabling ikke din opgave, og du kan nøjes med beskrivelser på grænsefladen og administrativt slukke for ubenyttede porte.

Netværksdiagrammer

Der er ikke en 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.

Under fysiske elementer forstår vi

• aktivt udstyr
• grænseflader/porte på aktivt udstyr

Under logiske forstår vi

• logiske enheder (N7K VDC, Palo Alto VSYS, …)
• VRF
• VLANs
• subinterfaces
• tunneller
• zoner
• …

Hvis dit netværk ikke er helt enkelt, vil det bestå af forskellige segmenter.
For eksempel

• datacenter
• internet
• WAN
• fjernadgang
• kontor LAN
• DMZ
• …

Det ville være fornuftigt at have flere diagrammer, der giver både et overordnet billede (hvordan trafikken bevæger sig mellem alle disse segmenter) samt en detaljeret forklaring af hvert enkelt segment.

Da der i moderne netværk kan være mange logiske niveauer, kan det være en god (men ikke obligatorisk) tilgang at lave forskellige diagrammer for de forskellige niveauer; for eksempel, i tilfælde af et overlay-tilgang kan følgende diagrammer være relevante:

• overlay
• L1/L2 underlay
• L3 underlay

Selvfølgelig er det vigtigste diagram, uden hvilken man ikke kan forstå ideen bag dit design, rutediagrammet.

Rutediagram

Som minimum skal dette diagram vise

• hvilke rutingsprotokoller der anvendes og hvor
• grundlæggende information om konfigurationen af rutingsprotokoller (område/AS-nummer/router-id/…)
• på hvilke enheder redistribuering finder sted
• hvor filtrering og aggregering af ruter sker
• information om standardruten

Det er også ofte nyttigt at have et L2-diagram (OSI).

L2 diagram (OSI)

Dette diagram kan vise følgende information:

• hvilke VLANs
• hvilke porte der er trunk-porte
• hvilke porte der er aggregeret i ether-channel (port channel), virtual port channel
• hvilke STP-protokoller og på hvilke enheder der anvendes
• grundlæggende STP-indstillinger: root/root backup, STP cost, port priority
• yderligere STP-indstillinger: BPDU guard/filter, root guard…

Karakteristiske fejl ved design

Eksempel på en dårlig tilgang til at bygge et netværk.

Lad os tage et simpelt eksempel på oprettelse af et enkelt kontor LAN.

Med erfaring i undervisning i telekommunikation til studerende kan jeg sige, at næsten enhver studerende i midten af det andet semester har den nødvendige viden (inden for det kursus, jeg underviste i) til at kunne konfigurere et enkelt kontor LAN.

Hvad er der svært ved at forbinde switchene sammen, konfigurere VLAN, SVI-grænseflader (i tilfælde af L3-switches) og skrive statisk routing?

Det hele vil fungere.

Men der er stadig spørgsmål, der vedrører

• sikkerhed
• reserve
• netværksskala
• ydelsen
• båndbredde
• pålidelighed
• …

Nogle gange hører jeg påstanden om, at et kontor-LAN er noget meget enkelt, og jeg hører det normalt fra ingeniører (og ledere), der beskæftiger sig med alt muligt andet end netværk, og de siger det så selvsikkert, at man ikke skulle blive overrasket, hvis LAN bliver lavet af folk med utilstrækkelig praksis og viden og bliver lavet med de typiske fejl, som jeg vil beskrive lidt længere nede.

Karakteristiske designfejl på niveau L1 (OSI)

• Hvis du alligevel er ansvarlig for struktureret kabling, er en af de mest ubehagelige arv, du kan få, en sjusket og uigennemtænkt switching.

Type L1-fejl omfatter også fejl relateret til de anvendte udstyrs ressourcer, for eksempel

• utilstrækkelig båndbredde
• utilstrækkelig TCAM på udstyret (eller ineffektiv brug af det)
• utilstrækkelig ydeevne (ofte relateret til firewalls)

Karakteristiske designfejl på niveau L2 (OSI)

Ofte, når der ikke er en god forståelse af, hvordan STP fungerer, og hvilke potentielle problemer det medfører, tilsluttes switchene kaotisk, med standardindstillinger, uden yderligere tuning af STP.

Resultatet er ofte følgende

• stor STP-diameter i netværket, hvilket kan føre til broadcast-storme
• STP-roden vil blive bestemt tilfældigt (baseret på MAC-adresse), og trafikvejen vil være suboptimal
• porte, der tilsluttes til værter, vil ikke være konfigureret som edge (portfast), hvilket vil føre til genberegning af STP ved tænding/slukning af endestationer
• netværket vil ikke være segmenteret på niveau L1/L2, hvilket betyder, at problemer med enhver switch (for eksempel overbelastning af strøm) vil føre til genberegning af STP-topologien og stoppe trafikken i alle VLAN på alle switches (herunder i segmentet, der er kritisk for servicekontinuitet)

Eksempler på designfejl i L3 (OSI)

Nogle typiske fejl fra begyndere indenfor netværk:

• hyppig brug (eller kun brug af) statisk routing
• brug af suboptimale routingprotokoller til dette design
• suboptimal logisk segmentering af netværket
• suboptimal brug af adresseområdet, hvilket hindrer aggregationen af ruter
• mangel på backup-ruter
• mangel på redundant forbindelser for default gateway
• asymmetrisk routing ved opbygning af ruter (kan være kritisk i tilfælde af NAT/PAT, tilstandsafhængige firewalls)
• MTU-problemer
• ved ombygning af ruter passerer trafikken gennem andre sikkerhedszoner eller endda andre firewalls, hvilket fører til, at denne trafik bliver droppet
• dårlig skalerbarhed i topologien

Kriterier for vurdering af designkvalitet

Når vi taler om optimalitet/suboptimalitet, skal vi forstå hvilke kriterier vi kan vurdere dette ud fra. Her er de mest væsentlige (men ikke alle) kriterier (og forklaring relateret til routingprotokoller):

• skalerbarhed (scalability)
  For eksempel, hvis du beslutter at tilføje endnu et datacenter. Hvor nemt kan du gøre det?
• brugervenlighed
  Hvor nemt og sikkert kan operationelle ændringer, som annoncering af et nyt netværk eller filtrering af ruter, gennemføres?
• tilgængelighed
  Hvor stor en procentdel af tiden leverer dit system det krævede serviceniveau?
• sikkerhed (security)
  Hvor beskyttede er de overførte data?
• pris

Ændringer

Det grundlæggende princip på dette stadium kan udtrykkes med formlen "Gør ikke skade".
Så selvom du ikke helt er enig i designet og den valgte implementering (konfiguration), er det ikke altid hensigtsmæssigt at lave ændringer. En fornuftig tilgang er at rangordne alle identificerede problemer ud fra to parametre:

• hvor let det er at løse dette problem
• hvor stor risiko det medfører

Først og fremmest skal man fjerne det, som i øjeblikket reducerer serviceniveauet under acceptabelt, for eksempel problemer der fører til pakke tab. Derefter skal du fjerne det, der lettest og sikrest kan løses i rækkefølge efter faldende alvorlighedsgrad af risiko (fra problemer med design eller konfiguration, der indebærer større risici til mindre).

Perfektionisme på dette stadium kan være skadelig. Bring designet til en acceptabel tilstand og synkroniser netværkskonfigurationen i overensstemmelse hermed.

Kilde: habr.com