3. Design av företagsnätverk på kommutatorer från Extreme

Hej, vänner! Idag fortsätter jag serien som handlar om Extreme switchar en artikel om design av företagsnätverk.

I artikeln kommer jag att försöka hålla mig kort:

• beskriva den modulära metoden för att designa företagsnätverk
• diskutera typer av konstruktion av en av de viktigaste modulerna i företagets nätverk — kärnnätverket (ip-campus)
• beskriva fördelar och nackdelar med alternativ för reservdelning av kritiska noder i nätverket
• på ett abstrakt exempel designa/uppdatera ett litet företagsnätverk
• välja Extreme switchar för att implementera det designade nätverket
• arbeta med fiber och IP-adressering

Denna artikel kommer att vara av större intresse för nätverksingenjörer och nätverksadministratörer på företag som just börjar sin resa som 'nätverkare', snarare än för erfarna ingenjörer som har arbetat i många år inom telekommunikation eller i stora företag med geografiskt distribuerade nätverk.

Hur som helst, intresserade är välkomna under kat.

Modulär metod för nätverksdesign

Jag börjar min artikel med den ganska populära modulära metoden för nätverksdesign, som gör det möjligt att sätta ihop ett pussel av nätverkets bitar till en enhetlig helhet.

Låt oss börja med lite abstraktion — jag föreställer ofta denna metod som en zoom på geokartor, där man i första hand ser ett land, i andra hand regioner, i tredje hand städer osv.

Som exempel kan vi överväga följande exempel:

• 1:a närheten — hela företagets nätverk utgörs av en uppsättning olika nivåer:
  • kärnnätverket eller campus
  • gränsnivå
  • nivå för telekommunikatörer
  • avlägsna zoner

• 2:a närheten — varje av dessa nivåer detaljeras i separata moduler
  • kärnnätverket eller campuset består av:
    • en 3- eller 2-nivå modul som beskriver företagets nätverk och dess nivåer — åtkomst, distribution och/eller kärna
    • en modul som beskriver datacenter — databehandlingscentret (i själva verket serverdelen av infrastrukturen)

  • gränsnivån består i sin tur av:
    • en modul för Internet-anslutning
    • en modul för WAN och MAN, som ansvarar för anslutningen av geografiskt distribuerade enheter inom företaget
    • en modul för att bygga VPN-tunnlar och fjärråtkomst
    • ofta har många små företag flera av dessa moduler eller till och med alla av dem, sammanslagna i en

  • leverantörsnivå:
    • Denna nivå inkluderar förbindelserna "till den yttre världen" — mörka fiberoptiska kablar (uthyrning av fibrer från operatörer), kommunikationskanaler (Ethernet, G.703 etc.), Internetåtkomst.

  • Fjärrnivå:
    • I de flesta fall är detta filialer till företaget, som är spridda inom en stad, ett län, ett land eller till och med kontinenten.
    • Denna zon kan också innefatta en reservdatacenter som duplicerar huvudkontorets arbete.
    • Och naturligtvis de som har ökat i popularitet på senare tid — telearbeiter (fjärrarbetsplatser).

• Den tredje närmandet — varje modul delas upp i mindre moduler eller nivåer. Till exempel i campusnät:
  • Treenivåsnittet delas upp i:
    • åtkomstnivå
    • distributionsnivå
    • kärnnivå

  • Datacentret kan i mer komplexa fall delas in i:
    • två- eller tre-nivå nätverksdel
    • serverdel

  Jag kommer att försöka återge allt ovanstående i följande förenklade bild:

  
  
  Som man kan se i bilden ovan, hjälper det modulära tillvägagångssättet till att detaljera och strukturera den övergripande bilden i beståndsdelar som man sedan kan arbeta med.

  I denna artikel kommer jag att fokusera på Campus Enterprise-nivån och beskriva den mer i detalj.

  Typer av IP-CAMPUS-nätverk

  Under min tid som anställd hos en tjänsteleverantör och särskilt senare — i arbetet som integratör, har jag stött på olika "mognadsnivåer" av kunders nätverk. Jag använder termen mognad med avsikt, eftersom det ganska ofta förekommer fall där nätverksstrukturen växer i takt med att företaget växer, och det är i princip logiskt.

  I ett litet företag som är beläget inom ett enda byggnad kan företagets nätverk bestå av en enda gränsrouter, som fungerar som en brandvägg, några åtkomstswitchar och ett par-tre servrar.

  Jag kallar ett sådant nätverk för en "enkelnivå" nätverk — det finns helt klart ingen tydlig kärnnivå av nätverket, distributionsnivån är förskjuten till gränsroutern (med funktioner för brandvägg, VPN och kanske proxy), och åtkomstswitcharna betjänar både anställdas datorer och servrar.

  
  
  När företaget växer — antalet anställda, tjänster och servrar ökar, måste man ofta:

  • öka antalet switchar i nätverket och åtkomstportar
  • öka serverkapaciteten
  • att kämpa mot broadcast-domäner innebär att införa nätverkssegmentering och rutting mellan segmenten
  • att bekämpa nätverksstörningar som orsakar stillestånd för anställda, eftersom detta medför ytterligare kostnader för ledningen (anställda står stilla, lön betalas, men arbetet utförs inte)
  • i kampen mot störningar, överväga att redundanta kritiska nätverkspunkter - routrar, switchar, servrar och tjänster
  • strama åt säkerhetspolicyn, då kommersiella risker kan uppstå och återigen - för en mer stabil nätverksdrift

  Allt detta leder till att en ingenjör (nätverksadministratör) förr eller senare funderar på hur man korrekt bygger nätverket och så småningom kommer till en 2-nivåmodell.

  Denna modell skiljer tydligt mellan två nivåer - åtkomstnivå och distributionsnivå, som samtidigt också är kärnnivån (collapsed-core).

  Den kombinerade distributions- och kärnnivån utför följande funktioner:

  • aggregerar länkar från åtkomstswitchar
  • inför routing av nätverkssegment - användare och enheter blir så många att de inte får plats i ett nätverk /24, och om de får plats, så orsakar broadcast-stormar ständiga störningar (särskilt om användarna hjälper till genom att skapa loopar)
  • säkerställer kommunikation mellan angränsande segment av switchar (genom snabbare länkar)
  • garanterar kommunikation mellan användare och deras enheter och serverfarmar, som också vid den tiden börjar särskiljas i ett eget nätverkssegment - datacenter.
  • börjar tillsammans med åtkomstswitchar i viss mån genomföra säkerhetspolicyn, som börjar dyka upp hos företaget vid denna tid. Företaget växer, kommersiella risker ökar också (här menar jag inte bara bestämmelser om affärshemligheter, åtkomstpolicyer etc., utan även om grundläggande stillestånd av nätverk och anställda).

  Således växer nätverket förr eller senare till en 2-nivåmodell:

  
  
  I denna modell finns speciella krav på både accessswitchar som aggregerar länkar från användare och nätverksenheter (skrivare, accesspunkter, VoIP-enheter, IP-telefoner, IP-kameror m.m.) samt på distributions- och kärn-switchar.

  Accessswitcharna måste vara mer intelligenta och funktionella för att uppfylla kraven på prestanda, säkerhet och flexibilitet i nätverket, och måste:

  • ha olika typer av access- och backboneportar - helst med möjlighet till kapacitetsöverskott både när det gäller trafikflöden och antalet portar.
  • ha tillräcklig switchingkapacitet och bandbredd.
  • ha nödvändiga säkerhetsfunktioner som uppfyller aktuella säkerhetspolicyer (och i bästa fall även framtida krav).
  • ha möjlighet att mata ström till svåruppnåeliga nätverksenheter med möjlighet till fjärråterställning av strömmen (PoE, PoE+).
  • ha möjlighet att reservera egen elektricitet för användning i de områden där det behövs.
  • ha, om möjligt, vidare potential för funktionell tillväxt - ett vanligt exempel är när en accessswitch över tid förvandlas till en distributionsswitch.

  Det finns också motsvarande krav på distributionsswitcharna:

  • både när det gäller backboneportarna nedåt mot accessswitcharna och riktning mot peergränssnitt hos angränsande distributionsswitchar (och i framtiden möjliga uplink-gränssnitt mot kärnan).
  • när det gäller L2- och L3-funktionalitet.
  • när det gäller säkerhetsfunktionalitet.
  • när det gäller att säkerställa redundans (reservkraft, klustring och strömförsörjningsreserv).
  • när det gäller flexibilitet vid trafikbalansering.
  • ha, om möjligt, vidare potential för funktionell tillväxt (förvandling över tid från aggregationsenhet till kärna).
  • i vissa fall kan det vara lämpligt att använda PoE, PoE+-portar på distributionsswitchar.

  Framåt — mer: om ledningen genomför en politik för aktiv tillväxt och utveckling av företaget, kommer nätverket även fortsättningsvis att utvecklas — företaget kan börja hyra grannbyggnader, bygga egna lokaler eller förvärva mindre konkurrenter, vilket ökar antalet arbetstillfällen för anställda. Samtidigt sker också en tillväxt av nätverket, vilket kräver:

  • säkerställande av anställdas arbetsplatser — nya accessswitchar med accessportar behövs
  • nya fördelningsswitchar för aggregering av länkar från accessswitchar
  • uppbyggnad av nya såväl som modernisering av befintliga kommunikationslinjer

  Som en följd av detta ökar trafiken av följande anledningar:

  • på grund av ökningen av accessportar och därmed användare i nätverket
  • på grund av ökad trafik från angränsande system som väljer företagets nätverk som transport — telefoni, säkerhet, ingenjörssystem etc.
  • på grund av implementering av ytterligare tjänster — med ökad personal tillkommer nya avdelningar som kräver särskild programvara
  • kapaciteterna i datacentret ökar för att möta krav från infrastrukturen och applikationerna
  • kraven på nätverkets och informationens säkerhet ökar — den berömda triaden av CIA (skämt), men på allvar, så handlar det om Confidentiality, Integrity and Availability:
    • i samband med detta tillkommer nya krav på redundans och säkerhet på kritiska nivåer av nätverket — distribution och datacenter
    • igen ökar trafiken på grund av implementering av nya säkerhetssystem — till exempel är säkerhetsutrustningar etc.

  Förr eller senare kommer ökningen av trafik, tjänster och antalet användare att leda till behovet av att införa en ytterligare nätverksnivå — kärnan som kommer att utföra hög hastighetsväxling/routing av paket med hjälp av hög hastighetslänkar.

  I det här skedet kan företaget övergå till en 3-nivå nätverksmodell:

  
  
  Som syns i den ovanstående bilden — i ett sådant nätverk finns det en kärnnivå som aggregerar snabba länkar från distributionsswitchar. Således ställs också krav på kärnswitchar gällande:

  • bandbredden på gränssnitten — 1GE, 2.5GE, 10GE, 40GE, 100GE
  • växlarens prestanda (switching capacity och forwarding performance)
  • gränssnittstyper — 1000BASE-T, SFP, SFP+, QSFP, QSFP+
  • antalet och uppsättningen av gränssnitt
  • möjligheter för redundans (stackning, klustring, redundant styrkort (gäller modulära switchar), redundans i strömförsörjning etc.)
  • funktionalitet

  På en sådan nivå i nätverket är det definitivt nödvändigt med både tekniska modifieringar:

  • redundans av kärnens noder och länkar (mycket, mycket, mycket önskvärt)
  • redundans av noder och länkar på distributionsnivån (beroende på kritikalitet)
  • redundans av länkar mellan åtkomstswitchar och distributionsnivån (vid behov)
  • introduktion av protokoll för dynamisk routning
  • trafikbalansering både i kärnan och på distributions- och åtkomstnivåer (vid behov)
  • implementering av ytterligare tjänster — både transporttjänster och säkerhetstjänster (vid behov)

  såväl som juridiska aspekter som definierar företagets säkerhetspolicy, vilken kompletterar den övergripande säkerhetspolicyn i fråga om:

  • krav på implementering och konfiguration av olika säkerhetsfunktioner på åtkomst- och distributionsswitchar
  • krav på åtkomst, övervakning och hantering av nätverksutrustning (protokoll för fjärråtkomst, tillåtna nätverkssegment för hantering, loggningsinställningar etc.)
  • krav på redundans
  • krav på att forma den minimalt nödvändiga Zip-satsen

  I det här avsnittet har jag kort beskrivit nätverkets och företagets evolution från ett par switchar och ett par dussin anställda till flera dussin (kanske till och med hundratals switchar) och flera hundra (eller till och med tusentals) enbart de anställda som arbetar direkt i företagets nätverk (naturligtvis finns det även produktionsavdelningar och ingenjörsnätverk).
  Det är uppenbart att en sådan "mirakulös" och snabb utveckling av företaget i verkligheten inte inträffar.
  Det tar vanligtvis år för ett företag och nätverk att växa från sin initiala nivå 1 till 3, som jag beskriver.

  Varför skriver jag alla dessa uppenbara sanningar? För att jag vill nämna termen ROI — return-on-investment (återbetalning/avkastning på investeringar) och diskutera den sida som direkt påverkar valet av nätverksutrustning.

  När nätverksingenjörer och deras chefer väljer utrustning, gör de oftast sitt val utifrån två faktorer — den aktuella kostnaden för utrustningen och den minimala tekniska funktionaliteten som för närvarande behövs för att lösa en specifik uppgift eller uppgifter (jag kommer att berätta mer om inköp av utrustning för reservdelar senare).

  Sällan beaktas dock möjligheterna till framtida ”tillväxt” av utrustningen. När situationen uppstår där utrustningen blir otillräcklig när det gäller funktionalitet eller prestanda köps det kraftfullare och mer funktionella alternativ, medan den gamla läggs i lager eller någonstans i nätverket för att ”ligga och stå” (detta bidrar för övrigt också till uppkomsten av en stor variation av utrustning och till inköp av många informationssystem som arbetar med den).

  Således, istället för att köpa licenser för extra funktionalitet och prestanda, vilket är mycket billigare än att investera i ny hårdvara med högre prestanda, tvingas man köpa ny utrustning och betala mer av följande skäl:

  • nätverket växer ofta långsamt, och expansion av funktionalitet eller prestanda hos din nätverkslösning kan räcka länge till
  • det är ingen hemlighet att utrustningen från utländska leverantörer ofta är kopplad till utländsk valuta (dollar eller euro). För att vara ärlig — ökningen av dollar eller euro (eller den periodiska mini-devalveringen av rubeln, beroende på perspektiv) gör att en dollar för tio år sedan och en dollar nu är helt olika saker sett ur rubelns perspektiv

  Sammanfattningsvis vill jag påpeka att köp av nätverksutrustning med bredare funktionalitet idag kan leda till besparingar i framtiden.
  Här betrakta kostnaderna för inköp av utrustning i sammanhanget av investeringar i sitt eget nätverk och infrastruktur.

  Därför följer många leverantörer (inte bara Extreme) principen pay-as-you-grow, och bygger in mycket funktionalitet och kapacitet för att öka prestandan hos gränssnitten, vilka sedan aktiveras genom köp av separata licenser. De erbjuder också modulära switchar med ett brett utbud av gränssnitt och processor kort, samt möjlighet till successiv ökning av både mängd och prestanda.

  Reserv av kritiska noder

  I denna del av artikeln vill jag kort beskriva de grundläggande principerna för reservsystem av viktiga nätverksnoder som kärnkommutatorer, datacenter eller distributionssystem. Jag vill börja med att gå igenom de allmänna typerna av reservsystem - stapling och klustring.

  Varje metod har sina fördelar och nackdelar, som jag vill diskutera.

  Nedan följer en sammanfattande tabell som jämför de två metoderna:

  
  

  • hantering — som framgår av tabellen har stapling fördelar när det gäller hantering, eftersom en stapel av flera kommutatorer framstår som en enda kommutator med många portar. Istället för att hantera till exempel 8 olika kommutatorer vid klustring kan du hantera bara en vid stapling.
  • avstånd — för närvarande är fördelen med klustring, strikt talat, inte så tydlig, eftersom det har utvecklats staplingsteknologier för kommutatorer via staplingsportar eller portar med dubbla ändamål (t.ex. SummitStack-V från Extreme, VSS från Cisco, etc.), vilket också beror på typen av transceivrar. Här ges fördelar till klustring på grund av att det vid stapling finns alternativ där vanliga staplingsportar måste användas, vilka ofta ansluts med speciella kablar av begränsad längd - 0,5, 1, 1,5, 3 eller 5 meter.
  • programuppdatering — här ser vi att klustring har en fördel över stapling, eftersom följande gäller - vid uppdatering av programvaruversionen på enheten när det gäller stapling uppdaterar du programvaran på masterkommutatorn, som senare tar på sig rollen att installera ny programvara på standby-medlemmarna i stapeln. Å ena sidan underlättar detta ditt arbete, men programuppdateringar kräver ofta en hårdvaruåterstart, vilket leder till att hela stapeln startas om, vilket på så sätt innebär avbrott i dess drift och alla tjänster kopplade till den under tiden = tiden för omstart. Detta är ofta mycket kritiskt för kärnan och datacentret. Vid klustring har du två oberoende enheter som du kan uppdatera programvaran på i tur och ordning. Detta gör att avbrott i tjänster kan undvikas.
  • konfiguration av inställningar Här är fördelen med stapling, eftersom du vid administration bara behöver justera inställningarna för en enhet och dess konfigurationsfil. Vid klustring däremot kommer antalet konfigurationsfiler att motsvara antalet noder i klustret.
  • felsäkerhet Här är båda teknologierna ungefär lika, men klustring har en liten fördel. Anledningen till detta är följande — om vi ser på stacken ur perspektivet av aktiva processer och protokoll, kommer vi att se följande:
    • det finns en master-switch där alla huvudsakliga processer och protokoll körs (till exempel dynamisk routingprotokoll — OSPF)
    • det finns andra slave-switchar där de huvudsakliga processerna som krävs för att fungera i stacken och hantera den trafik som passerar genom dem körs
    • om master-switchen slutar fungera, upptäcker den nästa prioriterade slave-switchen att mastern har fallit
    • den initierar sig själv som master och startar alla processer som kördes på mastern (inklusive det observerade protokollet OSPF)
    • efter en viss tid av processstart (vanligtvis ganska kort), börjar OSPF-protokollet att fungera
    • på så sätt kommer OSPF vid ett misslyckande av en av noderna i klustring att fungera något snabbare än vid stapling (tiden som krävs för att starta och initiera processer och protokoll på slave-switchar i stacken). Jag måste dock påpeka att moderna staplingprotokoll och switchar fungerar mycket snabbt; ofta tar avbrottet i trafik vid växling av stacken mindre än en sekund, men nominellt sett vinner klustring på denna parameter.

  • komplexitet Som vi ser i tabellen, vinner stapling när det gäller komplexitet. Detta är en direkt följd av punkterna 'hantering' och 'konfiguration av inställningar'. En enda nod tar mycket mindre tid för inställningar och hantering. Vid klustring måste man dessutom ofta konfigurera ytterligare routingprotokoll eller protokoll för redundanta gateways — VRRP, HSRP och andra.
  • utbyte av noder — här har stapling en tydlig fördel. Ofta krävs endast minimalt nödvändiga inställningar av utrustningen för att byta en switch i en stack, till exempel:
    • att uppdatera mjukvaran på den nya switchen till versionen av stackens mjukvara (och detta kan göras direkt när switcharna kommer till lagret)
    • att ställa in några grundläggande kommandon för stapling (och för vissa typer av switchar kan det till och med krävas inget sådant)
    • att ta ut den trasiga switchen från stacken och ansluta en ny
    • att ansluta strömförsörjning och patchkablar

  • elasticitet — jag betraktar som en av de viktigaste parametrarna. Generellt är elasticitet en komplex egenskap som innebär att något ändras under påverkan av belastning och återgår till sitt ursprungliga tillstånd efter att belastningen försvinner. Förvånande nog är den för klustring högre även med hänsyn till 4:3 i fördel av stapling. Allt handlar om den mänskliga faktorn. Ja, ja, bli inte förvånad — i styrkan av sådana parametrar för stapling, såsom enhetlig hantering, konfiguration av inställningar och minskad komplexitet, ligger svagheten i staplingen när den mänskliga faktorn kommer in i bilden.

  Under min karriär inom IT har jag flera gånger stött på situationer (ja, jag ska inte sticka under stol med att jag själv har snubblat på dessa samma hinder, särskilt i början) där ingenjören vid inställningen av stacken gjorde fel vid inmatning av något kommando eller vid på- och avstängning av någon funktion på utrustningen, vilket ledde till att hela stacken slutade fungera och fick manuell omstart. Det är värt att nämna älskare av Putty-appen för Windows (oj, det där med att kopiera med höger musknapp).

  I själva verket är båda teknologierna ganska bra (särskilt jämfört med bristen på redundans) och var och en har sina styrkor och svagheter, men för kärnnivå och för högbelastade datacenter skulle jag ändå föredra att använda klustring.

  Även om det bara är min åsikt. Många professionella ingenjörer som har arbetat på professionell nivå med nätverksunderhåll i många år kan lika väl använda båda teknologierna — här beror allt på erfarenhet och kompetens.

  Förutom teknologier för stapling och reservkoppling av nätverksnoder finns det också allmänna principer för reservkoppling av delar av själva nätverksnoden och förbindelser mellan noder:

  Med reservkoppling inom nätverksnoden menar jag:

  • reservkoppling av strömförsörjning — installation av 2 strömförsörjningar som duplicerar varandra (helst anslutna till kategori 1 av strömförsörjning) kan avsevärt underlätta ditt liv.
  • reservkoppling av styrkort — gäller främst modulära switchar som har stöd för anslutning av flera duplicerande styrkort.
  • reservkoppling av gränssnittskort — detta gäller även i hög grad modulära switchar.

  Med reservkoppling av förbindelser/linkar avses främst att ha duplicerande kabelbanor (eller radiolänk i öppna utrymmen) med:

  • fördelning mellan olika kabelkanaler och schakt inuti byggnaden
  • geografisk fördelning över området i nivåer av 2 eller fler byggnader, städer, regioner eller länder (så kallade volymringar)

  Vid byggandet av reservlinkar måste dock ett antal rekommendationer för utrustningen följas:

  • i fallet med duplicering av gränssnittskort i en modulär switch, eller vid stapling, är det nödvändigt att fördela länkarna mellan enheterna — gränssnittskort vid modulära switchar och switchar vid stapling.
  • det är önskvärt att använda protokoll för länkaggregering (LACP, MLT, PAgP osv.) för att kombinera länkar i grupper och balansera lasten mellan dem.
  • använda routrar som stöder protokoll för ECMP (Equal-Cost-Multi-Path) — när flera paket skickas över en rutt, går dessa paket inte över en enda bästa väg (eller gränssnitt), utan distribueras över flera bästa vägar (och flera gränssnitt) som bestäms baserat på likhet i routingprotokollets mätvärden, vilket i sin tur ansvarar för att fylla den slutliga routingtabellen.

  Och nu, som lovat, kommer jag att beskriva ett verkligt fall från min praktik och principen för besparingar vid reservkoppling av kritiska noder, som inträffade för några år sedan:

  • I ett företag, som jag kallar X, fanns det en standard tre-nivåmodell för nätverk:
    • med flera kärnor
    • och flera dussin aggregat
    • flera tusen access-switchar
    • tio tusen användare

  • nätverket var ganska komplext att bygga:
    • med en mängd dynamiska routningsprotokoll och protokoll — OSPF, MP-BGP, MPLS, PIM, IGMP, IPv6 osv.
    • med många tjänster — internetåtkomst, L2 och L3 VPN, VoIP, IPTV, dedikerade linjer osv.

  • men det fanns en flaskhals i nätverket — gränsrutern som kombinerade BGP-borderfunktionen och terminerade vissa användartjänster
  • ja, den kostade som ett flygplansvinge (några miljoner rubel)
  • ja, på den tiden var det en av de toppmoderna enheterna från den mest kända nätverksleverantören
  • ja, den borde vara mycket pålitlig — med utmärkta MTBF-värden
  • ja, den hade 4 strömförsörjningar, konstruerade enligt 2x2-schema och anslutna till olika UPS och strömingångar.

  Men allt detta ändrade inte på det faktum att den var en enda felpunkt i nätverket.

  Och en dag, som absolut inte var vacker för mig och mina kollegor, slutade denna router att fungera (senare kom vi fram till att det genomfördes ett fel i strömlinjen genom UPS, vilket ledde till att 2 strömförsörjningar gick sönder samtidigt och en av dem brände RP-modulen i routern och interface-kortet som var anslutna till en gemensam databus).

  Vi hade inga reservkort — RP och interface-kort, men vi hade ett kontrakt för ersättning av utrustning eller dess komponenter med en av partnerna enligt NBD-schema.

  Tyvärr hade partnerna i lager endast interface-kortet vid den tiden, men inget RP-kort, vilket kom först efter några dagar (efter 3 dagar).

  Som resultat av att ha en enda felpunkt i nätverket (även med ett stödkontrakt och utrustningsersättning) blev de följande finansiella kostnaderna:

  • andelen av företagets tjänster som relaterade till eller hade att göra med denna border utgjorde cirka 60-70%
  • som beräknades senare, var den dagliga vinsten cirka 900 000 rubel (ungefär) vid den tiden
  • således gick den potentiella vinsten under 3 dagars stillestånd teoretiskt förlorad och uppgick till mellan 1 620 000 och 1 890 000 rubel

  Självklart var de rena förlusterna mindre, eftersom en del av ersättningarna till de främsta användarna återbetalades inte i form av pengar, utan i form av tjänster, men de var fortfarande närvarande:

  • en del av ersättningarna till företagskunder
  • ökar kostnader för företagets anställda som har arbetat alla dessa 3-4 dagar i full styrka – övertid, nattjänstgöring, utökade skift, osv.
  • ryktesskador, vilket också är viktigt
  • och det viktigaste – nervositet, både hos ledningen och anställda, liksom hos kunderna

  Som ett resultat reviderades företagets politik:

  • man avstod från kontrakt för ersättning enligt NBD-villkoret
  • man behöll det vanliga servicekontraktet
  • man köpte en reservrouter till ett värde av ungefär 1 – 1,3 miljoner rubel för att säkerställa 90% av funktionaliteten hos den primära.

  I framtiden gjorde inköpet av ytterligare utrustning och reservdelar det möjligt att balansera belastningen mellan dem när det gäller externa länkar, trafik och användare, och gav ytterligare säkerhetsmarginaler för företaget vid framtida incidenter.

  Exempel på design av ett företagsnätverk

  I denna del av artikeln kommer jag att försöka presentera huvudpunkterna vid beräkning av företagets huvudnätverk. Jag kommer inte att belasta er med hela metoden PPDIOO (Prepare-Planning-Design-Implement-Operate-Optimize), utan endast markera dess viktigaste punkter:

  • Prepare / Förberedelse – du måste komma överens med din ledning om målen för nätverksuppgraderingen som du vill uppnå – öka redundansen, införa nya tjänster eller teknologier. Jag hoppar över begränsningarna – tekniska och organisatoriska, eftersom jag utgår från att du är anställd i organisationen och har gott om tid för att övervinna dem. Jag återkommer till budgetfrågan nedan.
  • Planning / Planering – här måste du skapa en komplett karaktärsbeskrivning av ditt nuvarande nätverk (om du inte redan känner till det), det vill säga beskriva nätverket som det är just nu:
    • antal och typ av utrustning
    • antal och typer av portar
    • existerande kabeldragningar och kopplingsscheman inom byggnader och mellan dem
    • elförsörjningsscheman
    • L2 och L3 adressering
    • skapa kartor över Wi-Fi-nätverk med angivande av åtkomstpunkter och kontrollenheter
    • beskriva din serverfarm
    • det är önskvärt att beskriva alla dina tjänster och relationer mellan dem
    • om du redan har implementerat någon form av nätverkssäkerhetspolicy och nätverksåtkomstbegränsningar, se till att beakta dessa vid designen.
    • Jag vill genast påpeka att det andra steget i huvudsak innebär en fullständig inventering av nätverket, från kabelinfrastrukturen och strömförsörjningsscheman till tjänster (applikationer och deras portar). Det här steget är mycket, mycket arbetsintensivt och kan ibland vara tråkigt. Om du eller din föregångare inte har hållit dokumentation eller ens ett grundläggande övervakningssystem, är det hög tid att tänka på detta. Nätverket har en tendens att förändras över tid med olika hastigheter och endast aktuell dokumentation eller ett övervakningssystem kan hjälpa dig att hålla koll på dess tillstånd och underlätta administrationen. Men det hör redan till steget operate.

  • Design / Projekttering — beväpnad med fullständig kunskap om ditt nätverk, som du fått från föregående steg, sätter du dig äntligen ner och funderar på hur du ska modernisera ditt nätverk. Nedan kommer jag att försöka demonstrera ett litet exempel på nätverksberäkning.

  För mig har jag sammanställt en liten lista med grundläggande data som jag kommer att följa vid beräkning och projektering av det grundläggande nätverket.

  Låt oss föreställa oss steget Prepare som en lista över vad vi har tillgängligt och vad som är planerat att göras:

  • det finns ett ganska stort företag med cirka 700-800 arbetsplatser (här menar jag de anställda som behöver tillgång till företagets nätverk)
  • det finns flera fristående byggnader inom företagets område:
  • Huvudbyggnader:
    • antal byggnader — 2 st
    • antal våningar i byggnaden — 7 st
    • antal telekommunikationsskåp per våning i en byggnad — 3 (totalt 21) st
    • antal anställda i byggnaden =~ 250 personer

  • Ytterligare byggnader:
    • antal byggnader — 10 st
    • antal våningar i byggnaden / verkstad — 2 st
    • antal telekommunikationsskåp i byggnaden — 3 st
    • antal anställda i byggnaden =~ 20 personer

  • Den nuvarande kärnnivån i nätverket (för övrigt en mycket vanlig konfiguration som jag har stött på flera gånger i olika former och portkompositioner) presenteras:
    • med 2 L2-switchar:
      • 1Gb portar av typ RJ-45 — 24 st
      • 1Gb SFP-portar — 4 st
    • med 1 L2-switch:
      • 1Gb SFP-portar — 24 st
    • topologin för kärnet — ring
    • peer-to-peer-länkar mellan switchar är aktiverade med hjälp av optiska fibrer
    • switcharna är placerade i små serverrum med skåp
  • Den nuvarande distributionsnivån:
    • kompilerad med kärnnivå i del av aggregering av länkar från åtkomstswitchar
    • L3 adressering har flyttats till gränsrutern och/eller brandväggen
  • Aktuell åtkomstnivå:
    • L2-switchar med 16 x 100 Mb åtkomstportar RJ-45 och 2 gigabit uppkopplingskombinationsportar RJ-45/SFP
    • switcharna finns i skåp på våningarna
    • topologi för åtkomstswitchar:
      • stjärna (hub-and-spoke — nav och spikar) med kärn-/distributionsswitch i mitten
      • grenen/spoket utgör en kedja av switchar på våningarna — 3 stycken i kedjan
    • det finns icke-hanterade åtkomstswitchar
    • switcharna i 9 ytterligare skåp är anslutna via mediakonverterare (omvandlare av optisk signal till elektrisk)
  • Aktuell kablinfrastruktur:
    • Kabelsystem mellan byggnaderna:
      • det finns en optisk kabel mellan de 2 huvudbyggnaderna med kapacitet för 8 fibrer
      • det finns en optisk kabel mellan ett av de ytterligare skåpen (där kärnswitch är installerad) och var och en av de huvudsakliga byggnaderna med kapacitet för 8 fibrer vardera
      • det finns en optisk kabel mellan do. skåpen och skåpen med installerade kärnswitchar med kapacitet för 4 fibrer (deras distribution visas på bilden nedan)
      • typ av fibrer i alla kablar — enkelmodiga/SMF
      • används 2-fiber enskilda SFP-transceivrar
      • en del av kablarna termineras på optiska cross-connects (ODF) i separata utrymmen (cross-lokaler/serverrum), och en del av kablarna i våningsskåp

    • Kabelsystem inuti byggnaderna:
      • det finns en blandad kabelstruktur mellan serverrum och de första skåpen på våningarna:
      • kopparkablar Cat5e — 10 stycken (eller 100 par kablar)
      • optisk multimode/MMF-kabel med 4 eller 8 fibrer — 1 styck
      • optisk multimode/MMF-kabel med 4 fibrer mellan våningsskåpen
      • kopparkablar Cat5e mellan våningsskåpen och åtkomstuttag
    • aktuell datacenter:
      • det finns flera servrar, till exempel 6 stycken
      • anslutna med 1Gb portar till kärnswitchen i 1:a huvudbyggnaden
      • alla företagsapplikationer har flyttats till servrar
    • adressiering L2, L3 och ruttningssystem:
      • i nätverket finns flera VLAN — 2–3 stycken per byggnad
      • servrarna har fördelats i ett separat /24-nät
      • för interna behov används grå nät klass B, som ligger inom intervallet — 172.16.0.0/16
      • L3-adresser termineras på gränsrouter och/eller brandvägg
      • använder statisk ruttning
    • ytterligare information:
      • telefoni:
        • i byggnader och vissa hus har traditionell telefoni implementerats med gamla digitala PBX-system (inte IP-PBX)
        • det är nödvändigt att telefonisera nya byggnader utan kostnader för att dra dyra kopparledningar av viss kapacitet och bygga redundanta SCN för telefoni inuti byggnader
        • med tiden planeras implementación av IP-telefoni över hela företagets område, integrera den med CRM-system och överföra alla anställda till den
      • portkapacitet:
        • det är nödvändigt att analysera den nuvarande kapaciteten hos backbone-portarna och access-portarna, och reservera minst 25-30% för framtida behov
        • analysera tillräckligheten av den nuvarande bandbredden hos access-portarna och backbone-länkarna
        • förutse närvaron av PoE/PoE+-accessportar för enheter från angränsande system – videoövervakning och telefoni
      • videoövervakning:
        • det planeras att använda företagets nätverk som transport för videoövervakningsnätverket
        • det är nödvändigt att förutse närvaron av PoE-portar för videoövervakningskameror
      • trådlösa system:
        • i framtiden planeras implementering av en trådlös infrastruktur för att öka mobiliteten för anställda
        • det är nödvändigt att förutse närvaron av PoE-portar för åtkomstpunkter
      • budget, tidsramar och krav på utrustning:
        • använda befintlig utrustning maximalt
        • vid nätverksdesign, ta hänsyn till möjligheten att utöka nätverkets kapacitet under N år framöver
        • vid nätverksdesign, ta hänsyn till stöd för alla typer av säkerhetsfunktioner – här är en lista över funktionalitet, från port-säkerhet till autentisering och auktorisering av användare via 802.1x.
        • reservera så mycket som möjligt av kritiska nätverksnoder av högsta betydelse – kärna och datacenter, och se till att det finns möjlighet att reservera sekundära viktiga noder – distributionsnoder
        • projektbudgeten måste förutsätta gradvis finansiering i flera etapper
        • budgetbelopp – här avgör varje företag för sig, baserat på sina ekonomiska indikatorer
        • Tidsramar - i det mest ideala fallet kommer det inte att finnas några tydliga tidsramar här, eftersom detta är ett internt projekt för företaget som genomförs av sina anställda, eller så kommer de att vara relativt bekväma - till exempel 1 år (eller mer). I sämre fall kan det vara från 3 månader till ett halvt år.
      • Åtgärda nuvarande problem i nätverket:
        • paketförluster
        • problem med DHCP på mer eller mindre intelligenta acces-switchar, relaterade till användningen av STP-protokollfamiljen för att bekämpa loopar på accessportarna.
        • ta bort behovet av en DHCP-server i varje VLAN för anställda
        • förekomsten av switch-loopar, relaterade till att hanterade / ohanterade switchar kopplas in i kontor och att olika enheter ansluts till dem
        • listan kan fortsätta och fortsätta...

      Planeringssteget - tillståndet på ditt nuvarande nätverk, som jag redan har nämnt, beror på kvaliteten av övervakningssystemet och dess dokumentationsnivå. Under detta steg kommer du att behöva:

      • minst skissa på det befintliga nätverket för vidare analys
      • insamla data från utrustningen:
        • trafik på huvudportarna
        • fel på portarna
        • CPU-användning och minnesanvändning på switchar och routrar
        • skissa L2-L3 diagram över VLAN och IP-adresser
      • lyfta fram kabeldragningarna:
        • fiberdiagram och diagram för patchning av optiska kopplingar
        • diagram för kopparkabeldistribution mellan servrar och våningar
        • diagram för kopparkabeldistribution mellan våningar och kontor
        • kontrollera förekomsten av optiska kopplingar och patchpaneler i servrar och skåp
      • kontrollera elkraftdiagram i server- och våningsskåp
      • kontrollera förekomsten av UPS och batterier vid kritiska noder
      • analysera all data

      Med hjälp av data från förberedelsestadiet har jag fått fram ett ungefärligt logiskt schema:

      
      
      Därefter, följande en modulär metod, är det nödvändigt att särskilja nivåer och moduler för företaget:

      
      
      Jag kommer inte att beröra gränser (Edge) i denna artikel, utan kort påminna om grundläggande punkter för varje modul inom Campus:

      • Åtkomst - på denna nivå ska följande säkerställas:
        • nödvändigt antal portar för användarnas åtkomst till nätverket
        • genomförande av säkerhetspolicyer - filtrering av trafik och protokoll
        • komprimering av sändande domäner och segmentering av nätverket med hjälp av VLAN
        • implementering av separata VLAN för rösttrafik
        • stöd för QoS
        • stöd för PoE-åtkomstdon
        • stöd för IP multicast
        • återhållbarhet för uppströms kommunikationslänkar tillsammans med distributionslaget (önskvärt)
      • Distributionslagret – på denna nivå ska följande säkerställas:
        • nödvändigt antal portar för anslutning av åtkommbryggor
        • aggregering och redundans av åtkommbryggers länkar
        • IP-routing
        • paketfiltrering
        • stöd för QoS
        • återhållbarhet på länk, utrustning och strömnivå (mycket önskvärt)
      • Kärnan – ska möjliggöra:
        • hög hastighet av paketkommutering och routing
        • nödvändigt antal portar för anslutning av distributionsbryggor
        • stöd för IP-routing och dynamiska routingprotokoll med snabb nätverkskonvergens
        • stöd för QoS
        • säkerhetsfunktioner för att skydda åtkomsten till utrustningen och kontrollplanet
        • återhållbarhet på nivå av utrustning och strömförsörjning (obligatoriskt)
      • Datacenter – det nätverkslagret i denna modul ska säkerställa:
        • höghastighetskommunikationslänkar
        • nödvändigt antal portar för anslutning av servrar
        • redundans av kommunikationslänkar både mellan servrar och datacenterbryggor, liksom mellan datacenterbryggor och kärnnätverket (obligatoriskt)
        • redudans av utrustning och strömförsörjning (obligatoriskt)
        • stöd för QoS

      Därefter måste vi räkna våra portar och kommunikationslänkar och definiera kraven.
      Åtkommningsnivå – portberäkningstabell

      Så vi har fått datan om fördelningen av åtkomstportar mellan byggnader. Nu måste vi analysera åtkomstnivåkraven och noteringarna och skissa på lösningsalternativ.
      Åtkommningsnivå – krav och lösningsalternativ

      Därefter räknar vi portar och kommunikationslänkar för följande nivåer:

      Distributionsnivå

      Kärnnivå

      Datacenternivå

      Vid beräkningen har vi fått följande:

      • åtkomstnivå – vi behöver 24- och 48-portars åtkommbryggor, helst med 1Gb åtkomstportar och optiska uplinkportar SFP med stöd för PoE och bred funktionalitet:
        • totalt ger de 504 åtkomstportar, vilket i princip täcker kraven för reservportar, om beslutet tas att använda 2 portar per arbetsplats – IP-telefon och dataport.
        • det är möjligt att använda en 48-portars switch med PoE-funktionalitet på varje våning, som tillhandahåller åtkomstportar för kraven:
          • reservkapacitet — ungefär 102 reservportar (22%) i huvudbyggnaderna. För de ytterligare byggnaderna något mer — 25%.
          • övervakning
          • trådlöst nätverk
      • distributionsnivå — switches med ett antal SFP-portar från 12 till 48 portar med minst 2 SFP+-portar, som har möjlighet till stackning och utökat funktionalitet, samt med reservkraftsblock.
      • kärnnivå — kräver högpresterande switchar från 12 till 24 SFP/SFP+-portar med stöd för både stackning och klustring med MC-LAG-stöd. Det bör noteras att routrar också kan användas för trafikbalansering. Senaste generationens L3-switchar och routrar stödjer ECMP med trafikbalansering över 4 eller fler rutter med samma metrik.
      • nivå av datacenter — kräver switchar från 8 till 24 SFP/SFP+-portar med stöd för både stackning och klustring med MC-LAG-stöd.

      Den slutliga målschemat för nätverket blev en sådan

      Val av Extreme-switchar för implementeringen av projektet

      Nu har vi kommit till huvudfrågan — valet av switchar för att genomföra vårt projekt. För den resulterande målschemat passar följande Extreme-switchar:

      Nivå
      Modell
      Portar
      Beskrivning

      kärna
      x620-16x-Base *

      x670-G2-48x-4q-Base*
      16 x 10GE SFP+
       
       
       
      48x10GE SFP+ och 4×40 GE QSFP+
      För grundläggande behov i kärnan:

      • högpresterande länkar
      • utökat funktionalitet för routing och säkerhet
      • reservkraft med extra nätdelar
      • stöd för stackning och klustring

      Med minimala krav passar switchen i x620-serien.
      Om mer omfattande krav på antal portar och bredare funktionalitet finns, bör switcharna i x670-G2-serien övervägas.

      datacenter

      x620-16x-Base*

      x590-24x-1q-2c*

      x670-G2-48x-4q-Base*

      16 x 10GE SFP+
       
       
       
      24x10GE SFP, 1xQSFP+, 2xQSFP28
       
       
      48x10GE SFP+ och 4×40 GE QSFP+

      För grundläggande behov i datacentret:

      • högpresterande länkar
      • reservkraft med extra nätdelar
      • stöd för stackning och klustring

      Med minimala krav passar switchen i x620-serien.
      Om mer omfattande krav på antal portar och bredare funktionalitet finns, bör switcharna i x670-G2- och x590-24x-1q-2c-serierna övervägas.

      distribution

      X460-G2-24x-10GE4-Base*

      X460-G2-48x-10GE4-Base*

      24x1GE SFP, 8×1000 RJ-45, 4x10GE SFP+
       
       
       
      48x1GE SFP, 4x10GE SFP+

      För grundläggande behov inom distribution:

      • nödvändigt antal optiska portar
      • reservkraft med extra nätdelar
      • stöd för stackning och klustring
      • nödvändigt L3-funktionalitet

      De perfekta switcharna är från x460-G2-serien. Med reservdelar för strömförsörjning och möjlighet till att utöka och lägga till 10G-portar, CX (för stapling) och QSFP+ gör dem till idealiska switchar för distributionsnivån med portar upp till 1 Gb.

      åtkomst

      X440-G2-24p-10GE4*

      X440-G2-24t-10GE4*

      X440-G2-48t-10GE4*

      X440-G2-48p-10GE4*

      24x1000BASE-T(4 x SFP combo), 4x10GE SFP+ (PoE budget 380 W)
       
      24x1000BASE-T(4 x SFP combo), 4x10GE SFP+
       
       
      24x1000BASE-T(4 x SFP combo), 4x10GE SFP+ kombinationsportar
       
      48x1000BASE-T(4 x SFP combo), 4x10GE SFP+ kombinationsportar (PoE budget 740 W)

      För åtkomstbehov:

      • nödvändigt antal åtkomstportar
      • stöd för PoE/PoE+
      • funktionalitet och möjlighet för portutvidgning
      • en ytterligare bonus i form av stöd för stapling med 10Gb-portar "out of the box"

      Jag rekommenderar att man tittar på denna serie med tanke på dess flexibilitet när det kommer till portar, prestanda och funktionalitet.

      *specifikationerna för de valda switcharna kan ses i den första artikeln i serien — översikt av Extreme-switchar

      Här skulle jag kunna avsluta artikeln, men jag vill gärna belysa ytterligare två aspekter som varje ingenjör kommer att stöta på vid utveckling eller uppgradering av nätverket:

      • arbete med kabelsystem — fiber och kopparlinjer
      • IP-adressering

      Arbete med fiber

      Ovan har jag angett den målstruktur som vi behöver nå. För att realisera den krävs följande antal anslutningar för utrustningen:

      antal länkar

      Som framgår av tabellen är det minimala antalet fibrer som krävs för att säkerställa nätverksnivåernas redundans (kärnmodul, datacenter och distribution i två byggnader) — 10 stycken.

      Vid nätverkskarakteriseringen upptäckte vi att det finns totalt 8 fibrer i kabeln mellan byggnaderna. Vad ska man göra i sådana situationer?

      Jag kommer att ge några lösningar:

      • Det första uppenbara steget är att använda lediga fibrer i kabeln mellan byggnad 1 — byggnad 1 och byggnad 1 — byggnad 2 (som framgår av tabellen används endast 2 av 8 fibrer i varje kabel). För detta behövs det bara installera optiska kopplingar mellan brytarna i byggnad 1 och vid behov använda SFP-moduler med ett överskott av optisk budget.
      • Det andra steget är möjligheten att använda CWDM-teknik – sammanslagning av bärande våglängder inom en och samma fiber. Denna teknik är betydligt billigare än DWDM och ganska enkel att implementera. Det finns främst krav på kvaliteten på de optiska fibrerna och SFP/SFP+-transceivers av viss längd och budget. Som jag nämnt i den tidigare artikeln – möjligheten för switchar att känna igen transceivers från tredje part kan verkligen underlätta för oss och minska kapitalutgifterna för att bygga ytterligare optiska kablar.
      • Det tredje steget är att överväga möjligheten att öka antalet fibrer genom att dra ytterligare optiska kablar.

      Vidare tittar vi på antalet fibrer mellan byggnader med installerade distributionsswitchar och extra hus 2-10. Här är det inte heller så entydigt:

      • För det första saknas fibrer för att genomföra vårt mål – två fibrer per switch (som vi minns har vi kablar med fyra OV per hus).
      • För det andra, även om det finns tillräckligt med fibrer mellan byggnaderna, används MMF-fibrer inuti husen, vilket inte tillåter oss att enkelt koppla ihop SMF- och MMF-fibrer (jag talar om avstånd mellan byggnader som överstiger 300-400 meter).

      I sådana fall kan följande alternativ övervägas:

      • förse varje switch med SMF-fibrer:
        • om avståndet tillåter – kan du dra ytterligare långa patchkablar mellan switcharna. Tidigare använde vi patchkablar med längd på 30-50 m.
        • dra en relativt billig optisk SMF-kabel med låg kapacitet mellan skåpen.
        • som yttersta alternativ använda olika SMF-MMF-omvandlare.
      • För att minimera de använda fibrerna mellan byggnaderna kan man:
        • använda funktionaliteten för stapling av access-switchar x440-G2 – samtidigt som man använder 1 SMF-fiber till varje switch på varje våning, vilket gör att man istället för 6 fibrer och portar kan använda 3 fibrer och portar på varje sida.
        • använda 2 fibrer för att ansluta den första switchen i grenen och den sista. Aggregat länkar på gränsswitcharna för access och använda STP-protokoll i den resulterande ringen.

      IP-adressering

      Här ger jag ett förslag på adressering för vår schema.

      För närvarande har vi flera klass B-nät — 172.16.0.0/16. När jag beräknar IP-adressutrymmet kommer jag att basera mig på följande överväganden:

      • 4 bitar av den andra oktetten kommer att beteckna byggnader — 172.16.0.0/12.
      • Tredje oktett kommer att beteckna våningsnumret i byggnaden.
      • Tredje oktett = 255 kommer att avsättas för point-to-point-länkar mellan utrustning och nätverksstyrning.
      • en management VLAN per våning för att hantera switchar.
      • ett användar VLAN per switch (i genomsnitt 24 portar).
      • ett Voice VLAN per switch (i genomsnitt 24 portar).
      • ett VLAN för övervakningssystem per våning.
      • ett VLAN för Wi-Fi-enheter per våning.

      Jag fick ungefär sådana här tabeller:
      nätverk 172.16.0.0/14
      nätverk 172.20.0.0/14

      I den ovanstående tabellen har jag gett ett ungefärligt exempel på fördelningen av nätverk mellan byggnader och våningar på ena sidan och nätverken (användare, styrning och tjänster) på andra sidan.

      I själva verket är valet av det grå nätet 172.16.0.0/12 inte optimalt, eftersom det begränsar oss i antalet nätverk (från 16 till 31) för byggnader, och det finns även fjärrkontor som också behöver segmentera nätverksblock, ett mer optimalt alternativ kan vara att använda 10.0.0.0/8-nät, eller en kombination av 172.16.0.0/12-nät (till exempel för tjänstebehov och servrar) och 10.0.0.0/8 (för användarnät).

      Övergripande är tillvägagångssättet för tilldelning av IP-nät också modulärt, och det är önskvärt att följa reglerna för sammanställning av undernät till ett summary-nät på distributionsnivåer, samt på gränsroutrar i fjärrkontor. Detta görs av flera skäl:

      • för att minimera routingtabellerna på routrar
      • för att minimera tjänstetrafiken från routingprotokoll (alla möjliga uppdateringsmeddelanden, när undernät inte är tillgängliga)
      • för att förenkla administrationen och förbättra läsbarheten av L3-nät

      Även om det i de första två punkterna bör noteras att kraften hos moderna routrar är mycket högre än de som fanns för 15-20 år sedan och de kan hålla stora routingtabeller i sitt RAM-minne, och dessutom har relationen mellan pris och bandbredd för kommunikationskanaler minskat jämfört med priserna under den tid då E1/T1-strömmar användes i stor skala (G.703).

      Slutsats

      Vänner, i denna artikel har jag försökt att sammanfatta de grundläggande principerna för design av campusnät så kort som möjligt. Ja, materialet blev ganska omfattande och detta eftersom jag inte berörde ämnen som:

      • organisation av företagsgränser (och det är en egen historia med sina egna switchar, gränssnitt, brandväggar, IPS/IDS-system, DMZ, VPN och andra grejer)
      • organisation av Wi-Fi-nät
      • organisation av VoIP-nät
      • organisation av datacenter
      • säkerhet (och det är också en egen värld som inte står tillbaka för designen av ren nätverksinfrastruktur i omfattning och krav, utan ibland till och med överträffar den)
      • energi
      • listan kan fortsätta och fortsätta

      Faktiskt är design och byggande av företagsnät en ganska mödosam uppgift som kräver mycket tid och resurser.

      Men jag hoppas att min artikel hjälper er att bedöma och på en grundläggande nivå förstå hur man kan närma sig denna uppgift.

      Detta är långt ifrån den sista artikeln om Extreme Networks, så håll utkik efter uppdateringar (Telegram, Facebook, VK, TS Solution Blog)!

Källa: habr.com