Hur du tar kontroll över din nätverksinfrastruktur. Kapitel två. Städning och dokumentation

Den här artikeln är den andra i en artikelserie med titeln ”Hur du tar kontroll över din nätverksinfrastruktur”. Innehållet i alla artiklar i serien och länkar finns här.

Vårt mål i detta skede är att skapa ordning i dokumentationen och konfigurationen.
I slutet av den här processen bör du ha den nödvändiga uppsättningen dokument och ett nätverk konfigurerat enligt dem.

Vi kommer inte att prata om säkerhetsrevision nu – detta kommer att tas upp i den tredje delen.

Komplexiteten i att slutföra den givna uppgiften i detta skede varierar naturligtvis kraftigt 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ändringskontroll och ledningsprocess för nätverket
• 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 granska dokumenten och se alla ändringar som har gjorts.

I värsta fall kommer du att ha

• ett nätverk skapat utan ett projekt, utan en plan, utan godkännande, av ingenjörer som inte har tillräckliga kvalifikationer,
• med kaotiska, odokumenterade förändringar, med mycket "skräp" och suboptimala lösningar

Det är tydligt att din situation ligger någonstans mittemellan, men tyvärr, på den här bättre-sämre-skalan, är du sannolikt närmare den värsta ä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 "designers" ville göra, återställa deras logik, avsluta det som inte var klart och ta bort "skräpet".
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 på något sätt anspråk på att vara fullständig. Här kommer jag endast att beskriva de allmänna principerna och fokusera på några vanliga problem som behöver åtgärdas.

Uppsättning av dokument

Låt oss börja med ett exempel.

Nedan följer några av de dokument som vanligtvis skapas på Cisco Systems under designprocessen.

CR – Kundkrav, kundkrav (tekniska specifikationer).
Den skapas tillsammans med kunden och definierar kraven för nätverket.

HLD – Högnivådesign, högnivådesign baserad på nätverkskrav (CR). Dokumentet förklarar och motiverar de arkitektoniska beslut som fattats (topologi, protokoll, val av utrustning,...). HLD innehåller inte designdetaljer som de gränssnitt och IP-adresser som används. Den specifika hårdvarukonfigurationen diskuteras inte heller här. Detta dokument är snarare avsett att förklara de viktigaste designkoncepten för kundens tekniska hantering.

LLD – Lågnivå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, såsom 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 implementering även av mindre kvalificerad personal.

Något som IP-adresser, AS-nummer, fysiskt kopplingsschema (kablage) kan "extraheras" till separata dokument, t.ex. NIP (Nätverksimplementeringsplan).

Byggandet 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å designdokumentation. Men jag vill undvika formaliteter och pröva frågan i sak. Det här steget handlar inte om att designa, utan om att få ordning på saker och ting, och vi behöver en uppsättning dokument (diagram, tabeller, beskrivningar etc.) som är tillräckliga 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.

Dessa är följande dokument:

• logg för 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 omkoppling (kablage) nätverksingenjörernas ansvar.

I det här fallet löses problemet delvis med följande tillvägagångssätt.

• använd beskrivningen på gränssnittet för att beskriva vad som är anslutet till det
• administrativt stänga av alla oanslutna portar på nätverksutrustning

Detta ger dig möjligheten, även vid länkproblem (när cdp eller lldp inte fungerar på det här gränssnittet), att snabbt avgöra vad som är anslutet till den här porten.
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 åtkomsten till utrustningen, så förlorar du också åtkomsten till denna information. Dessutom kommer du på det här sättet inte att kunna registrera så viktig information som vilken typ av utrustning det är, vilken strömförbrukning den har, hur många portar den har, vilket rack den sitter i, vilka patchpaneler den har och var (till vilket rack/patchpanel) de är anslutna. Därför är ytterligare dokumentation (inte bara beskrivningar av utrustningen) fortfarande mycket användbar.

Det ideala alternativet är att använda applikationer som skapats för att arbeta med den här typen av information. Men du kan begränsa dig till enkla tabeller (till exempel i Excel) eller visa den information som du anser nödvändig i L1/L2-scheman.

Viktigt!

En nätverksingenjör kan naturligtvis känna till SCS:s invecklade detaljer och standarder, typer av rack, typer av avbrottsfria strömförsörjningar, vad en kall och varm gång är, hur man gör korrekt jordning, ... precis som han i princip kan känna till fysiken hos elementarpartiklar eller C++. Men man måste fortfarande 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 en helpdesk.

Om sådana avdelningar finns i ditt företag, är det inte din uppgift att upprätthålla en fysisk switchlogg, och du kan begränsa dig till endast en 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 element i ditt nätverk.

Med fysiska element menar vi

• aktiv utrustning
• aktiva utrustningsgränssnitt/portar

Genom logisk -

• logiska enheter (N7K VDC, Palo Alto VSYS, …)
• VRF-förlängning
• vilaner
• delgränssnitt
• tunnlar
• zon
• .

Om ditt nätverk inte är helt grundläggande kommer det också att bestå av olika segment.
Till exempel

• datacenter
• Internet
• WAN
• fjärråtkomst
• kontors-LAN
• DMZ
• .

Det är klokt att ha flera diagram som ger både helhetsbilden (hur trafiken flyter mellan alla dessa segment) och en detaljerad förklaring av varje enskilt segment.

Eftersom moderna nätverk kan ha många logiska nivåer kan det vara en bra (men inte nödvändig) metod att skapa olika scheman för olika nivåer, till exempel, i fallet med en overlay-metod, kan dessa vara följande scheman:

• överlagring
• L1/L2 underlag
• L3 underlag

Naturligtvis är det viktigaste diagrammet, utan vilket det är omöjligt att förstå idén bakom din design, rutningsdiagrammet.

Routningsschema

Som ett minimum bör detta diagram återspegla

• vilka routingprotokoll används och var
• grundläggande information om inställningar för routingprotokoll (område/AS-nummer/router-ID/…)
• på vilka enheter sker omdistributionen
• där filtrering och ruttaggregering sker
• standardruttinformation

Dessutom är L2-schemat (OSI) ofta användbart.

L2-schema (OSI)

Detta diagram kan återspegla följande information:

• vilka VLAN
• vilka portar är trunkportar
• vilka portar aggregeras i ether-channel (portkanal), virtuell portkanal
• vilka STP-protokoll används och på vilka enheter
• Grundläggande STP-inställningar: root/root-säkerhetskopiering, STP-kostnad, portprioritet
• ytterligare STP-inställningar: BPDU-skydd/filter, rotskydd…

Typiska designfel

Ett exempel på en dålig metod för att bygga ett nätverk.

Låt oss ta ett enkelt exempel på hur man bygger ett enkelt lokalt nätverk på ett kontor.

Med erfarenhet av att undervisa studenter i telekom kan jag säga att praktiskt taget vilken student som helst i mitten av andra terminen har den kunskap som krävs (inom den kurs jag undervisade) för att sätta upp ett enkelt kontors-LAN.

Vad är svårt med att koppla switchar till varandra, konfigurera VLAN, SVI-gränssnitt (i fallet med L3-switchar) och konfigurera statisk routing?

Allt kommer att fungera.

Men samtidigt frågor relaterade till

• säkerhet
• bokning
• nätverksskalning
• produktivitet
• genomströmning
• pålitlighet
• .

Jag hör då och då påståendet att ett kontors-LAN är något väldigt enkelt, och jag hör det oftast från ingenjörer (och chefer) som gör allt utom nätverk, och de säger det med sådan självsäkerhet att man inte blir förvånad om LAN-et görs av personer med otillräcklig erfarenhet och kunskap, och görs med ungefär samma misstag som jag kommer att beskriva nedan.

Typiska L1 (OSI) designmisstag

• Om du är ansvarig för SCS är ett av de mest obehagliga arven du kan ärva slarviga och ogenomtänkta byten.

Jag skulle också klassificera fel relaterade till resurserna hos den utrustning som används som typ L1, till exempel,

• otillräcklig bandbredd
• otillräcklig TCAM på hårdvaran (eller ineffektiv användning av den)
• dålig prestanda (ofta relaterat till brandväggar)

Typiska L2 (OSI) designmisstag

Ofta, när man inte har någon god förståelse för hur STP fungerar, vilka potentiella problem det medför, är switcharna kaotiskt anslutna, med standardinställningar, utan ytterligare STP-justering.

Som ett resultat har vi ofta följande

• stor STP-nätdiameter, vilket kan leda till sändningsstormar
• STP-rötter kommer att bestämmas slumpmässigt (baserat på MAC-adress) och trafikvägen kommer att vara suboptimal
• Portar anslutna till värdar kommer inte att konfigureras som edge (portfast), vilket kommer att orsaka omberäkning av STP när slutstationer aktiveras/inaktiveras.
• nätverket kommer inte att segmenteras på L1/L2-nivå, vilket leder till att problem med någon switch (till exempel överbelastning) kommer att leda till omberäkning av STP-topologin och att trafiken stoppas i alla VLAN på alla switchar (inklusive i det segment som är kritiskt för tjänstens kontinuitet)

Exempel på misstag i L3 (OSI) design

Några typiska misstag för nybörjare i nätverksteknik:

• frekvent användning (eller endast användning) av statisk routing
• användning av routingprotokoll som inte är optimala för en given design
• suboptimal logisk nätverkssegmentering
• suboptimal användning av adressutrymme, vilket inte tillåter ruttaggregering
• brist på reservvägar
• ingen reservation för standardgateway
• asymmetrisk routing vid ombyggnad av rutter (kan vara avgörande vid NAT/PAT, statefull-brandväggar)
• MTU-problem
• Vid ombyggnad av rutter går trafiken genom andra säkerhetszoner eller till och med andra brandväggar, vilket leder till att denna trafik tappas bort
• dålig topologisk 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, ur min synvinkel, är de viktigaste (men inte alla) kriterierna (och en uppdelning i relation till routingprotokoll):

• skalbarhet
  Till exempel bestämmer du dig för att lägga till ytterligare ett datacenter. Hur lätt kan du göra det.
• användarvänlighet (hanterbarhet)
  Hur enkelt och säkert är det att göra operativa förändringar, som att tillkännage ett nytt nätverk eller filtrera rutter?
• tillgänglighet
  Hur stor andel av tiden tillhandahåller ert system den erforderliga servicenivån?
• säkerhet
  Hur säker är den överförda informationen?
• pris

Förändringar

Huvudprincipen i detta skede kan uttryckas med formeln "gör ingen skada".
Därför, även om du inte helt håller med om designen och den valda implementeringen (konfigurationen), är det inte alltid lämpligt att göra ändringar. En rimlig metod är att rangordna alla identifierade problem enligt två parametrar:

• hur enkelt kan detta problem åtgärdas
• hur stor risk det innebär

Först och främst är det nödvändigt att eliminera det som för närvarande sänker servicenivån under den acceptabla nivån, till exempel problem som leder till paketförlust. Åtgärda sedan det som är enklast och säkrast att åtgärda i fallande riskgradsordning (från design- eller konfigurationsproblem som utgör högre risker till lägre risker).

Perfektionism i detta skede kan vara skadligt. Få designen att fungera och synkronisera nätverkskonfigurationen i enlighet med den.

Källa: will.com