Den här artikeln är den andra i en serie artiklar "Hur du tar kontroll över din nätverksinfrastruktur." Innehållet i alla artiklar i serien och länkar finns .
Vårt mål i detta skede är att få ordning på dokumentationen och konfigurationen.
I slutet av denna process bör du ha den nödvändiga uppsättningen dokument och ett nätverk konfigurerat i enlighet med dem.
Nu kommer vi inte att prata om säkerhetsrevisioner - detta kommer att bli föremål för den tredje delen.
Svårigheten att slutföra uppdraget i detta skede varierar naturligtvis mycket från företag till företag.
Den ideala situationen är när
- ditt nätverk skapades i enlighet med projektet och du har en komplett uppsättning dokument
- har implementerats i ditt företag för nätverk
- i enlighet med denna process har du dokument (inklusive alla nödvändiga diagram) som ger fullständig information om det aktuella läget
I det här fallet är din uppgift ganska enkel. Du bör studera dokumenten och granska alla ändringar som har gjorts.
I värsta fall har du
- ett nätverk skapat utan ett projekt, utan en plan, utan godkännande, av ingenjörer som inte har en tillräcklig kvalifikationsnivå,
- med kaotiska, odokumenterade förändringar, med mycket "skräp" och suboptimala lösningar
Det är klart att din situation ligger någonstans mittemellan, men tyvärr, på den här skalan av bättre – sämre, är det stor sannolikhet att du kommer närmare den sämsta änden.
I det här fallet behöver du också förmågan att läsa tankar, eftersom du måste lära dig att förstå vad "designerna" ville göra, återställa sin logik, avsluta det som inte var färdigt och ta bort "skräp".
Och naturligtvis måste du korrigera deras misstag, ändra (i detta skede så minimalt som möjligt) designen och ändra eller återskapa scheman.
Denna artikel gör inte anspråk på att vara komplett. Här kommer jag endast att beskriva de allmänna principerna och fokusera på några vanliga problem som måste lösas.
Uppsättning av dokument
Låt oss börja med ett exempel.
Nedan finns några dokument som vanligtvis skapas hos Cisco Systems under design.
CR – Kundkrav, kundkrav (tekniska specifikationer).
Den skapas tillsammans med kunden och bestämmer nätverkskraven.HLD – High Level Design, högnivådesign baserad på nätverkskrav (CR). Dokumentet förklarar och motiverar de arkitektoniska beslut som tagits (topologi, protokoll, val av hårdvara,...). HLD innehåller inte designdetaljer, såsom gränssnitt och IP-adresser som används. Den specifika hårdvarukonfigurationen diskuteras inte heller här. Snarare är detta dokument avsett att förklara viktiga designkoncept för kundens tekniska ledning.
LLD – Low Level Design, lågnivådesign baserad på högnivådesign (HLD).
Den bör innehålla alla detaljer som behövs för att genomföra projektet, till exempel information om hur man ansluter och konfigurerar utrustningen. Detta är en komplett guide för att implementera designen. Detta dokument bör ge tillräcklig information för dess genomförande även av mindre kvalificerad personal.Något, till exempel IP-adresser, AS-nummer, fysiskt kopplingsschema (kablage), kan ”läggas ut” i separata dokument, som t.ex. NIP (Nätverksimplementeringsplan).
Konstruktionen av nätverket börjar efter skapandet av dessa dokument och sker i strikt enlighet med dem och kontrolleras sedan av kunden (tester) för överensstämmelse med designen.
Naturligtvis kan olika integratörer, olika kunder och olika länder ha olika krav på projektdokumentation. Men jag skulle vilja undvika formaliteter och överväga frågan i dess meriter. Det här steget handlar inte om design, utan om att ställa saker i ordning, och vi behöver en tillräcklig uppsättning dokument (diagram, tabeller, beskrivningar...) för att slutföra våra uppgifter.
Och enligt min mening finns det ett visst absolut minimum, utan vilket det är omöjligt att effektivt kontrollera nätverket.
Det här är följande dokument:
- diagram (logg) över fysisk omkoppling (kablage)
- nätverksdiagram eller diagram med viktig L2/L3-information
Fysiskt kopplingsdiagram
I vissa små företag är arbete relaterat till installation av utrustning och fysisk koppling (kablage) ansvaret för nätverksingenjörer.
I det här fallet löses problemet delvis genom följande tillvägagångssätt.
- använd en beskrivning på gränssnittet för att beskriva vad som är kopplat till det
- administrativt stänga av alla oanslutna nätverksutrustningsportar
Detta ger dig möjligheten att, även i händelse av problem med länken (när cdp eller lldp inte fungerar på detta gränssnitt), snabbt avgöra vad som är anslutet till denna port.
Du kan också enkelt se vilka portar som är upptagna och vilka som är lediga, vilket är nödvändigt för att planera anslutningar av ny nätverksutrustning, servrar eller arbetsstationer.
Men det är klart att om du förlorar tillgången till utrustningen så kommer du också att förlora tillgången till denna information. Dessutom kommer du på detta sätt inte att kunna spela in så viktig information som vilken typ av utrustning, vilken strömförbrukning, hur många portar, vilket rack den sitter i, vilka patchpaneler finns och var (i vilket rack/patchpanel ) de är anslutna. Därför är ytterligare dokumentation (inte bara beskrivningar på utrustningen) fortfarande mycket användbar.
Det idealiska alternativet är att använda applikationer som är utformade för att fungera med denna typ av information. Men du kan begränsa dig till enkla tabeller (till exempel i Excel) eller visa den information som du anser vara nödvändig i L1/L2-diagram.
Viktigt!
En nätverksingenjör kan förstås ganska väl känna till invecklarna och standarderna för SCS, typer av rack, typer av avbrottsfri strömförsörjning, vad en kall och varm gång är, hur man gör ordentlig jordning... precis som han i princip kan känna till elementarpartiklars fysik eller C++. Men man måste ändå förstå att allt detta inte är hans kunskapsområde.
Därför är det god praxis att ha antingen dedikerade avdelningar eller dedikerade personer för att lösa problem relaterade till installation, anslutning, underhåll av utrustning, samt fysisk omkoppling. Vanligtvis för datacenter är detta datacenteringenjörer, och för ett kontor är det helpdesk.
Om sådana uppdelningar tillhandahålls i ditt företag, är frågorna om att logga fysisk växling inte din uppgift, och du kan begränsa dig endast till beskrivning av gränssnittet och administrativ avstängning av oanvända portar.
Nätverksdiagram
Det finns ingen universell metod för att rita diagram.
Det viktigaste är att diagrammen ska ge en förståelse för hur trafiken kommer att flöda, genom vilka logiska och fysiska delar av ditt nätverk.
Med fysiska element menar vi
- aktiv utrustning
- gränssnitt/portar för aktiv utrustning
Under logisk -
- logiska enheter (N7K VDC, Palo Alto VSYS, ...)
- VRF-förlängning
- Vilans
- undergränssnitt
- tunnlar
- zon
- .
Dessutom, om ditt nätverk inte är helt elementärt kommer det att bestå av olika segment.
Till exempel
- datacenter
- Internet
- WAN
- Fjärranslutning
- kontors LAN
- DMZ
- .
Det är klokt att ha flera diagram som ger både den stora bilden (hur trafiken flyter mellan alla dessa segment) och en detaljerad förklaring av varje enskilt segment.
Eftersom det i moderna nätverk kan finnas många logiska lager, är det kanske ett bra (men inte nödvändigt) tillvägagångssätt att göra olika kretsar för olika lager, till exempel, i fallet med en överlagringsmetod kan detta vara följande kretsar:
- överlagring
- L1/L2 underlägg
- L3 underlag
Naturligtvis är det viktigaste diagrammet, utan vilket det är omöjligt att förstå idén med din design, routingdiagrammet.
Routningsschema
Detta diagram bör åtminstone återspegla
- vilka routingprotokoll som används och var
- grundläggande information om routingprotokollinställningar (område/AS-nummer/router-id/...)
- på vilka enheter sker omfördelning?
- där filtrering och ruttaggregering sker
- standardruttinformation
Dessutom är L2-schemat (OSI) ofta användbart.
L2-schema (OSI)
Detta diagram kan visa följande information:
- vilka VLAN
- vilka portar som är trunkportar
- vilka portar som är aggregerade till eterkanal (portkanal), virtuell portkanal
- vilka STP-protokoll som används och på vilka enheter
- grundläggande STP-inställningar: root/root backup, STP-kostnad, portprioritet
- ytterligare STP-inställningar: BPDU-skydd/filter, rotskydd...
Typiska designfel
Ett exempel på ett dåligt sätt att bygga ett nätverk.
Låt oss ta ett enkelt exempel på att bygga ett enkelt kontors-LAN.
Med erfarenhet av att undervisa studenter i telekom kan jag säga att praktiskt taget alla studenter i mitten av andra terminen har nödvändiga kunskaper (som en del av kursen som jag undervisade) för att sätta upp ett enkelt kontors-LAN.
Vad är det som är så svårt med att koppla switchar till varandra, sätta upp VLAN, SVI-gränssnitt (när det gäller L3-switchar) och ställa in statisk routing?
Allt kommer att fungera.
Men samtidigt frågor relaterade till
- säkerhet
- bokning
- nätverksskalning
- produktivitet
- genomströmning
- pålitlighet
- .
Då och då hör jag påståendet att ett kontors-LAN är något väldigt enkelt och jag brukar höra detta från ingenjörer (och chefer) som gör allt utom nätverk, och de säger detta så självsäkert att bli inte förvånad om LAN-nätverket görs av människor med otillräcklig övning och kunskap och kommer att göras med ungefär samma misstag som jag kommer att beskriva nedan.
Vanliga L1 (OSI) designmisstag
- Om du ändå är ansvarig för SCS, så är ett av de obehagligaste arven du kan få ett slarvigt och ogenomtänkt byte.
Jag skulle också klassificera som typ L1-fel relaterade till resurserna för den utrustning som används, till exempel,
- otillräcklig bandbredd
- otillräcklig TCAM på utrustning (eller ineffektiv användning av den)
- otillräcklig prestanda (ofta relaterat till brandväggar)
Vanliga L2 (OSI) designmisstag
Ofta, när det inte finns någon bra förståelse för hur STP fungerar och vilka potentiella problem det för med sig, kopplas switchar kaotiskt, med standardinställningar, utan ytterligare STP-inställning.
Som ett resultat har vi ofta följande
- stor STP-nätverksdiameter, vilket kan leda till sändningsstormar
- STP-rot kommer att bestämmas slumpmässigt (baserat på mac-adress) och trafikvägen kommer att vara suboptimal
- portar som är anslutna till värdar kommer inte att konfigureras som edge (portfast), vilket kommer att leda till STP-omräkning när man slår på/stänger av slutstationer
- nätverket kommer inte att segmenteras på L1/L2-nivån, vilket resulterar i att problem med någon switch (till exempel strömöverbelastning) kommer att leda till en omräkning av STP-topologin och stoppa trafiken i alla VLAN på alla switchar (inklusive en kritisk ur synvinkel av kontinuitetstjänstsegmentet)
Exempel på misstag i L3 (OSI) design
Några typiska misstag för nybörjare:
- Frekvent användning (eller endast användning) av statisk routing
- användning av suboptimala routingprotokoll för en given design
- suboptimal logisk nätverkssegmentering
- suboptimal användning av adressutrymme, vilket inte tillåter ruttaggregering
- inga backuprutter
- ingen reservation för standardgateway
- asymmetrisk routing vid ombyggnad av rutter (kan vara kritisk i fallet med NAT/PAT, statefulla brandväggar)
- problem med MTU
- när rutter byggs om går trafiken genom andra säkerhetszoner eller till och med andra brandväggar, vilket leder till att denna trafik släpps
- dålig topologi skalbarhet
Kriterier för bedömning av designkvalitet
När vi talar om optimalitet/icke-optimalitet måste vi förstå utifrån vilka kriterier vi kan utvärdera detta. Här, från min synvinkel, är de viktigaste (men inte alla) kriterierna (och förklaringen i förhållande till routingprotokoll):
- skalbarhet
Till exempel bestämmer du dig för att lägga till ett annat datacenter. Hur lätt kan du göra det? - användarvänlighet (hanterbarhet)
Hur enkla och säkra är operativa förändringar, som att annonsera ett nytt nät eller filtreringsvägar? - tillgänglighet
Hur många procent av tiden ger ditt system den nödvändiga servicenivån? - säkerhet
Hur säker är den överförda informationen? - pris
Förändringar
Grundprincipen i detta skede kan uttryckas med formeln "gör ingen skada."
Därför, även om du inte är helt överens med designen och den valda implementeringen (konfigurationen), är det inte alltid lämpligt att göra ändringar. Ett rimligt tillvägagångssätt är att rangordna alla identifierade problem enligt två parametrar:
- hur lätt kan detta problem lösas
- hur stor risk tar hon?
Först och främst är det nödvändigt att eliminera det som för närvarande minskar tjänstenivån under den acceptabla nivån, till exempel problem som leder till paketförlust. Fixa sedan det som är enklast och säkrast att fixa i fallande ordning efter riskens allvarlighetsgrad (från design- eller konfigurationsproblem med hög risk till lågriskproblem).
Perfektionism i detta skede kan vara skadligt. Få designen till ett tillfredsställande tillstånd och synkronisera nätverkskonfigurationen därefter.
Källa: will.com