3. Enterprise netværksdesign på Extreme switches

God eftermiddag, venner! I dag vil jeg fortsætte serien dedikeret til Ekstreme kontakter artikel om Enterprise-netværksdesign.

I denne artikel vil jeg forsøge at gøre det så kort som muligt:

• beskrive en modulær tilgang til netværksdesign Etnterprise
• overvej typerne af konstruktion af et af de vigtigste moduler i virksomhedens netværk - backbone-netværket (IP-campus)
• beskrive fordele og ulemper ved muligheder for redundans af kritiske netværksknuder
• ved at bruge et abstrakt eksempel til at designe/opdatere et lille Enterprise-netværk
• vælg Extreme switches for at implementere det designede netværk
• arbejde med fibre og IP-adressering

Denne artikel vil være af mere interesse for netværksingeniører og virksomhedsnetværksadministratorer, der lige er begyndt på deres vej som netværker, snarere end for erfarne ingeniører, der har arbejdet i mange år i teleoperatører eller store virksomheder med geografisk distribuerede netværk.

Interesserede er i hvert fald velkomne til at læse med.

Modulær tilgang til netværksdesign

Jeg vil starte min artikel med en ret populær modulær tilgang til netværksdesign, som giver dig mulighed for at samle et puslespil fra netværksbrikker til 1 komplet billede.

Først lidt abstraktion - jeg forestiller mig ofte denne tilgang som en zoom på geo-kort, når i den første tilnærmelse er landet synligt, i den anden regionerne, i den tredje byer osv.

Lad os som et eksempel overveje følgende:

• 1. tilnærmelse - hele virksomhedens netværk er et sæt af forskellige niveauer:
  • backbone netværk eller campus
  • grænseniveau
  • teleoperatørniveau
  • fjerntliggende områder

• 2. tilnærmelse - hvert af disse niveauer er detaljeret i separate moduler
  • Rygradsnetværket eller campus består af:
    • 3- eller 2-niveaus modul, der beskriver virksomhedens netværk og dets niveauer - adgang, distribution og/eller kerne
    • modul, der beskriver databehandlingscenteret (i det væsentlige serverdelen af ​​infrastrukturen)

  • grænseniveauet består igen af:
    • internetforbindelsesmodul
    • WAN- og MAN-moduler, som er ansvarlige for at forbinde geografisk fordelte virksomhedsobjekter
    • modul til opbygning af VPN-tunneller og fjernadgang
    • Ofte har mange små virksomheder flere af disse moduler, eller endda dem alle sammen til ét

  • udbyder niveau:
    • Dette niveau inkluderer forbindelser "til omverdenen" - mørke optiske fibre (fiberleasing fra operatører), kommunikationskanaler (Ethernet, G.703, etc.), internetadgang.

  • Fjernniveau:
    • For det meste er disse filialer af en virksomhed, der er fordelt inden for en by, region, land eller endda kontinent.
    • Denne zone kan også omfatte et backup-datacenter, der dublerer arbejdet i det primære.
    • og selvfølgelig vinder telearbejdere (fjernarbejdspladser) popularitet for nylig.

• 3. tilnærmelse - hvert af modulerne er opdelt i mindre moduler eller niveauer. For eksempel i et campusnetværk:
  • Det 3-lags netværk er opdelt i:
    • adgangsniveau
    • distributionsniveau
    • kerneniveau

  • I mere komplekse tilfælde kan datacentret opdeles i:
    • 2- eller 3-niveau netværksdel
    • server del

  Jeg vil forsøge at vise alt ovenstående i følgende forenklede figur:

  
  
  Som du kan se af figuren ovenfor, hjælper den modulære tilgang med at detaljere og strukturere helhedsbilledet i konstituerende elementer, der så kan arbejdes med.

  I denne artikel vil jeg fokusere på Campus Enterprise-niveauet og beskrive det mere detaljeret.

  Typer af IP-CAMPUS netværk

  Da jeg arbejdede for en udbyder og især senere som integrator, stødte jeg på forskellige niveauer af "modenhed" af kundenetværk. Det er ikke for ingenting, at jeg bruger begrebet modenhed, da der ret ofte er tilfælde, hvor netværksstrukturen vokser i takt med virksomhedens vækst, og det er i princippet naturligt.

  I en lille virksomhed beliggende i en enkelt bygning kan virksomhedens netværk kun bestå af 1 grænserouter, der fungerer som en firewall, flere adgangsswitches og et par servere.

  Sådan et netværk kalder jeg for mig selv et "single-tier" netværk - det har absolut ikke noget åbenlyst kernenetværksniveau, distributionsniveauet flyttes til grænserouteren (med firewall, VPN og muligvis proxyfunktioner), og adgangsswitches betjener både medarbejdercomputere og servere.

  
  
  I tilfælde af virksomhedsvækst - en stigning i antallet af ansatte, tjenester og servere, er det ofte nødvendigt at:

  • øge antallet af switche i netværket og adgangsporte
  • øge serverkapaciteten
  • bekæmp broadcast-domæner - implementer netværkssegmentering og routing mellem segmenter
  • bekæmpe netværksfejl, der forårsager nedetid for medarbejderne, da dette medfører yderligere økonomiske omkostninger for ledelsen (medarbejderen er ledig, lønnen betales, men arbejdet er ikke udført)
  • i processen med at håndtere fejl, tænk på at sikkerhedskopiere kritiske netværksknuder - routere, switches, servere og tjenester
  • stramme sikkerhedspolitikkerne, da kommercielle risici kan opstå og igen - for mere stabil netværksdrift

  Alt dette fører til, at ingeniøren (netværksadministratoren) før eller siden tænker på den korrekte konstruktion af netværket og kommer til en 2-niveau model.

  Denne model skelner allerede tydeligt mellem to niveauer - adgangsniveauet og distributionsniveauet, som også er kerneniveauet (kollapseret-kerne).

  Det kombinerede distributions- og kernelag udfører følgende funktioner:

  • samler links fra adgangskontakter
  • introducerer netværkssegment-routing - der er så mange brugere og enheder, at de ikke passer ind i et enkelt /24-netværk, og hvis de gør det, forårsager broadcast-storme konstante fejl (især hvis brugere hjælper dem ved at skabe sløjfer)
  • giver kommunikation mellem tilstødende switch-segmenter (via hurtigere links)
  • leverer kommunikation mellem brugere og deres enheder og serverfarmen, som på dette tidspunkt også begynder at blive allokeret i et separat netværkssegment - datacentret.
  • begynder sammen med adgangskontakterne i en eller anden grad at give den sikkerhedspolitik, der begynder at dukke op i virksomheden på dette tidspunkt. Virksomheden vokser, og kommercielle risici vokser også (her mener jeg ikke kun bestemmelser om forretningshemmeligheder, afgrænsning af adgangspolitikker osv., men også om grundlæggende netværks- og medarbejdernedetid).

  Således vokser netværket før eller siden til en 2-tiers model:

  
  
  Denne model introducerer særlige krav til både adgangsniveau-switches, som samler links fra brugere og netværksenheder (printere, adgangspunkter, VoIP-enheder, IP-telefoner, IP-kameraer osv.), og til distributions- og kerneniveau-switches.

  Adgangskontakter skal være mere intelligente og i stand til at opfylde kravene til netværkets ydeevne, sikkerhed og fleksibilitet og skal:

  • have forskellige typer adgangsporte og trunkporte - gerne med mulighed for at reservere til trafikvækst, samt til antallet af havne
  • har tilstrækkelig koblingskapacitet og båndbredde
  • have den nødvendige sikkerhedsfunktionalitet, der ville tilfredsstille den nuværende sikkerhedspolitik (og ideelt set væksten af ​​dens yderligere krav)
  • har evnen til at forsyne svært tilgængelige netværksenheder med evnen til at fjernstarte dem via strømforsyning (PoE, PoE+)
  • være i stand til at reservere din egen strømforsyning til at bruge den på steder, hvor det er nødvendigt
  • har (hvis muligt) yderligere potentiale for vækst i funktionalitet - et almindeligt eksempel, når en adgangsswitch i sidste ende bliver til en distributionsswitch

  Til gengæld skal distributionsafbryderne også opfylde følgende krav:

  • både med hensyn til trunk-downlink-porte mod adgangsswitches og mod peer-grænseflader for nabodistributionsswitches (og senere, mulige uplink-grænseflader mod kernen)
  • i L2 og L3 funktionsdelene
  • med hensyn til sikkerhedsfunktionalitet
  • med hensyn til at sikre fejltolerance (redundans, clustering og strømforsyningsredundans)
  • i forhold til at sikre fleksibilitet i trafikafbalanceringen
  • har (hvis muligt) yderligere potentiale for vækst af funktionalitet (transformation over tid af aggregeringsenheden til en kerne)
  • I nogle tilfælde kan det være hensigtsmæssigt at bruge PoE, PoE+ porte på distributionsswitches.

  Og der er mere: Hvis ledelsen fører en politik med aktiv vækst og udvikling af virksomheden, vil netværket også fortsætte med at udvikle sig i fremtiden – virksomheden kan begynde at leje nabobygninger, bygge egne bygninger eller absorbere mindre konkurrenter og derved øge antallet af arbejdspladser til medarbejderne. Samtidig vokser netværket også, hvilket kræver:

  • At forsyne medarbejdere med arbejdsstationer - nye adgangskontakter med adgangsporte er nødvendige
  • tilgængelighed af nye distributionsswitches til at samle links fra adgangsswitches
  • anlæg af ny og modernisering af eksisterende kommunikationslinjer

  Som følge heraf stiger trafikken af ​​følgende årsager:

  • på grund af stigningen i adgangsporte og dermed netværksbrugere
  • på grund af stigningen i trafikken af ​​relaterede delsystemer, der vælger virksomhedens netværk som deres transport - telefoni, sikkerhed, tekniske systemer mv.
  • grundet indførelse af tillægsydelser - i takt med at medarbejderstaben vokser, dukker der nye afdelinger op, som kræver specifik software
  • Datacenterets computerkraft er stigende for at opfylde infrastruktur- og applikationskrav
  • Sikkerhedskravene til netværk og information vokser - den berømte CIA-triade (joke), men seriøst, CIA - Fortrolighed, Integritet og Tilgængelighed:
    • i denne henseende optræder yderligere krav til fejltolerance og redundans på kritiske netværksniveauer - distribution og datacentre
    • igen er der en stigning i trafikken på grund af indførelse af nye sikkerhedssystemer - fx RKVI mv.

  Før eller siden vil væksten i trafik, tjenester og antallet af brugere føre til behovet for at implementere et ekstra netværkslag - en kerne, der vil udføre højhastigheds-switch/routing af pakker ved hjælp af højhastighedskommunikationsforbindelser.

  På dette tidspunkt kan virksomheden gå over til en 3-lags netværksmodel:

  
  
  Som det kan ses i figuren ovenfor, har et sådant netværk et kerneniveau, der samler højhastighedsforbindelser fra distributionsswitches. Kerneafbryderne har således også krav til:

  • grænsefladebåndbredde - 1GE, 2.5GE, 10GE, 40GE, 100GE
  • Skiftekapacitet og videresendelsesydelse
  • grænsefladetyper - 1000BASE-T, SFP, SFP+, QSFP, QSFP+
  • antallet og sæt af grænseflader
  • redundansmuligheder (stabling, clustering, redundans på styrekort (relevant for modulære switches), strømforsyningsredundans osv.)
  • funktionalitet

  På dette niveau af netværket er dets tekniske modifikation absolut nødvendig:

  • redundans af noder og kernelinks (meget, meget, meget ønskeligt)
  • redundans af noder og links af distributionsniveauforbindelser (afhængig af kritikalitet)
  • redundans af kommunikationsforbindelser mellem adgangskontakter og distributionsniveauet (hvis nødvendigt)
  • introduktion af dynamiske routingprotokoller
  • trafikbalancering både i kernen og på distributions- og adgangsniveauerne (hvis nødvendigt)
  • implementering af yderligere tjenester - både transport- og sikkerhedstjenester (hvis nødvendigt)

  såvel som juridisk, definerer virksomhedens netværkssikkerhedspolitik, som supplerer den generelle sikkerhedspolitik med hensyn til:

  • krav til implementering og konfiguration af visse sikkerhedsfunktioner på adgangs- og distributionskontakter
  • krav til adgang, overvågning og styring af netværksudstyr (fjernadgangsprotokoller, netværkssegmenter tilladt til administration, logningsindstillinger osv.)
  • reservationskrav
  • krav til dannelsen af ​​det mindst nødvendige reservedelssæt

  I dette afsnit beskrev jeg kort udviklingen af ​​netværket og virksomheden fra flere switches og et par dusin ansatte til flere dusin (og måske hundredvis af switches) og flere hundrede (eller endda tusinder) af medarbejdere, der direkte arbejder i virksomhedens netværk (og der er også produktionsafdelinger og ingeniørnetværk).
  Det er klart, at en sådan "mirakuløs" og hurtig udvikling af virksomheden i virkeligheden ikke forekommer.
  Det tager normalt år for en virksomhed og netværk at vokse fra dets oprindelige niveau 1 til det niveau 3, jeg beskriver.

  Hvorfor skriver jeg alle disse sandheder? Så vil jeg her nævne et sådant udtryk som ROI — afkast på investering (afkast/tilbagebetaling af investeringer) og overveje den side af det, der direkte vedrører valget af netværksudstyr.

  Ved valg af udstyr vælger netværksingeniører og deres ledere ofte udstyr ud fra to faktorer – den aktuelle pris på udstyret og den minimale tekniske funktionalitet, der aktuelt er nødvendig for at løse en bestemt opgave eller opgaver (jeg vil fortælle om indkøb af udstyr til backup senere).

  Samtidig overvejes mulighederne for yderligere "vækst" af udstyr sjældent. Når der opstår en situation, hvor udstyret har opbrugt sin funktionalitet eller ydeevne, så købes mere kraftfuldt og funktionelt udstyr, og det gamle udstyr afleveres til et lager eller et sted på netværket i henhold til princippet om "så det står" (det er i øvrigt også årsagen til fremkomsten af ​​en stor zoo af udstyr og køb af en masse informationssystemer, der arbejder med det).

  Således i stedet for at købe nogle licenser for yderligere. funktionalitet og ydeevne, som er meget billigere end nyt, mere effektivt udstyr, skal du købe ny hardware og betale for meget af følgende årsager:

  • netværket vokser ofte langsomt, og udvidelsen af ​​funktionalitet eller ydeevnen af ​​din netværksswitch kan være tilstrækkelig i lang tid
  • Det er ingen hemmelighed, at udstyr fra udenlandske leverandører er bundet til udenlandsk valuta (dollar eller euro). For at være ærlig, så fører væksten i dollaren eller euroen (eller den periodiske mini-devaluering af rublen, alt efter hvordan man ser på det) til, at dollaren for 10 år siden og dollaren nu er helt forskellige ting set fra rublens synspunkt.

  For at opsummere alt ovenstående vil jeg gerne bemærke, at køb af netværksudstyr med bredere funktionalitet nu kan føre til besparelser i fremtiden.
  Her overvejer jeg omkostningerne ved indkøb af udstyr i forbindelse med investering i mit netværk og infrastruktur.

  Således overholder mange leverandører (ikke kun Extreme) princippet om at betale-som-du-vokser, og indbygger i udstyret en masse funktionalitet og muligheder for at øge ydeevnen af ​​grænseflader, som efterfølgende aktiveres ved at købe separate licenser. De tilbyder også modulære switches med en bred vifte af interface- og processorkort og muligheden for konsekvent at øge både deres antal og ydeevne.

  Redundans af kritiske knudepunkter

  I denne del af artiklen vil jeg gerne kort beskrive de grundlæggende principper for redundans af så vigtige netværksknuder som core switches, datacentre eller distribution. Og jeg vil starte med at se på de generelle typer af redundans – stabling og klyngedannelse.

  Hver metode har sine fordele og ulemper, som jeg gerne vil tale om.

  Nedenfor er en generel oversigtstabel, der sammenligner de to metoder:

  
  

  • ledelse — som det fremgår af tabellen, har stabling i denne henseende en fordel, da en stack af flere switches fra et ledelsessynspunkt fremstår som én switch med et stort antal porte. I stedet for at administrere f.eks. 8 forskellige switches i clustering, kan du kun administrere én i stabling.
  • afstand — i øjeblikket er fordelen ved clustering strengt taget ikke så åbenlys, da der er dukket teknologier til stacking af switche via stacking-porte eller dual-purpose porte op (f.eks. SummitStack-V for Extreme, VSS for Cisco osv.), som også afhænger af typen af ​​transceivere. Her foretrækkes clustering ud fra princippet om, at der ved stabling er muligheder, der kræver brug af almindelige stablingsporte, som ofte forbindes med specielle kabler af begrænset længde - 0.5, 1, 1.5, 3 eller 5 meter.
  • softwareopdatering — her ser vi, at clustering har en fordel i forhold til stabling, og pointen er denne: Når man opdaterer versionen af ​​udstyrssoftwaren under stabling, opdaterer man softwaren på master switchen, som så påtager sig rollen som at placere den nye software på standby-member switchene i stakken. På den ene side gør dette dit arbejde nemmere, men opdatering af software kræver ofte en hardwaregenstart af udstyret, hvilket fører til en genstart af hele stakken og dermed en pause i dens drift og alle tjenester knyttet til det i en tid = genstartstid. Dette er normalt meget kritisk for kerne- og datacenteret. Med klyngedannelse har du 2 uafhængige enheder, hvorpå du kan opdatere software sekventielt efter hinanden. I dette tilfælde kan afbrydelser i tjenester undgås.
  • konfigurationsindstillinger - her er fordelen selvfølgelig med stabling, da du i tilfælde af administration kun behøver at redigere indstillingerne for én enhed og dens konfigurationsfil. Ved klyngedannelse vil antallet af konfigurationsfiler være lig med antallet af klyngenoder.
  • fejltolerance — her er begge teknologier omtrent lige store, men clustering har stadig en lille fordel. Grunden til dette er, at hvis vi ser på stakken fra synspunktet om at køre processer og protokoller, vil vi se følgende:
    • der er en hovedswitch, hvorpå alle hovedprocesser og protokoller kører (for eksempel den dynamiske routingprotokol - OSPF)
    • der er andre slaveafbrydere, der kører de vigtigste processer, der er nødvendige for at arbejde i stakken og servicere trafikken, der passerer gennem dem
    • Når en masterswitch svigter, registrerer den næsthøjeste prioritet slaveafbryder fejlen i masteren
    • den starter sig selv som en master og starter alle de processer, der kørte på masteren (inklusive OSPF-protokollen, vi observerer)
    • efter nogen tids processtart (normalt ret kort), begynder selve OSPF-protokollen at virke
    • Hvis en af ​​noderne svigter under klyngedannelse, vil OSPF således arbejde lidt hurtigere end under stabling (i den tid, der kræves til at starte og initialisere processer og protokoller på stak-slaveswitchen). Selvom jeg skal bemærke, at moderne stablingsprotokoller og switches fungerer meget hurtigt, tager varigheden af ​​trafikpausen, når du skifter stakken, ofte mindre end et sekund, men stadig, nominelt, vinder klyngedannelse i denne parameter.

  • kompleksitet — som det kan ses af tabellen, vinder stabling med hensyn til kompleksitet. Dette er en direkte konsekvens af punkterne "styring" og "konfigurationsindstillinger". En enkelt node tager meget kortere tid at konfigurere og administrere. Også ved klyngedannelse er det ofte nødvendigt at konfigurere yderligere routingprotokoller eller gateway-redundansprotokoller - VRRP, HSRP og andre.
  • udskiftning af enheder — her har stabling en klar fordel. Meget ofte, for at udskifte en switch i en stak, er det nødvendigt at udføre de mindst nødvendige udstyrsindstillinger, for eksempel:
    • opdater softwaren på den nye switch til versionen af ​​stacksoftwaren (og dette kan gøres umiddelbart efter modtagelse af switchene i reservedelssættet)
    • opsæt et par grundlæggende kommandoer til stabling (og for nogle typer af switche er dette måske ikke nødvendigt)
    • fjern den mislykkede stakkontakt og tilslut en ny
    • tilslut strømforsyning og patch-ledninger

  • elasticitet — Jeg betragter det som et af hovedparametrene for mig selv. Generelt er elasticitet en kompleks egenskab, der betyder, at nogets egenskab ændrer sig under påvirkning af en belastning og vender tilbage til sin oprindelige form efter dets forsvinden. Mærkeligt nok vil det for klyngedannelse være højere, selv når man tager scoren på 4:3 i betragtning med hensyn til karakteristika til fordel for stabling. Det hele handler om den menneskelige faktor. Ja, ja, bliv ikke overrasket – styrken af ​​sådanne stablingsparametre som samlet kontrol, konfiguration af indstillinger og forenklet kompleksitet er, hvor svagheden ved stabling ligger, når den menneskelige faktor kommer i spil.

  I løbet af mit arbejde på IT-området er jeg stødt på mange situationer (og lad os være ærlige, jeg har selv trådt på den samme rake, især i begyndelsen), hvor en ingeniør ved opsætningen af ​​en stak lavede en fejl ved at indtaste en bestemt kommando eller aktivere/deaktivere en bestemt funktionalitet på udstyret, hvilket førte til fejl i hele stakken og dens manuelle genstart. Det er værd at nævne særskilt fansene af Putty-applikationen til Windows (åh, den højreklik-kopiering).

  I virkeligheden er begge teknologier ret gode (især sammenlignet med ingen redundans), og hver har sine egne styrker og svagheder, men for kerneniveauet og for et tungt belastet datacenter vil jeg stadig foretrække at bruge klyngedannelse.

  Selvom dette kun er min mening. Mange professionelle ingeniører, der har været professionelt involveret i netværkssupport i mange år, kan bruge begge teknologier lige godt – det hele afhænger af deres erfaring og kvalifikationer.

  Ud over teknologierne til stabling og redundans af netværksknuder er der også generelle principper for redundans af dele af selve netværksknuden og forbindelser mellem noder:

  Med redundans i en netværksknude mener jeg:

  • redundante strømforsyninger - installation af 2 strømforsyninger, der duplikerer hinanden (og gerne tilsluttet 1. strømforsyningskategori) kan gøre dit liv meget lettere.
  • redundans af styrekort - for det meste relateret til modulære switches, som sørger for tilslutning af flere duplikerede kontrolkort.
  • interfacekortredundans - gælder også mest for modulære switche.

  Redundans af forbindelser/forbindelser forstås hovedsageligt som tilstedeværelsen af ​​duplikerede kabelruter (eller radioforbindelser i tilfælde af åbne rum) med:

  • fordelt gennem forskellige kabelskakte og kanaler inde i bygningen
  • geografisk fordeling over territoriet på niveau med 2 eller flere bygninger, en by, region eller land (de såkaldte volumetriske ringe)

  I dette tilfælde, når du konstruerer backup-kommunikationslinks, er det nødvendigt at følge en række anbefalinger for udstyret:

  • i tilfælde af duplikering af interfacekort af en modulær switch, eller i nærværelse af en stak, er det nødvendigt at distribuere links mellem enheder - interfacekort i tilfælde af modulære switche og switche i tilfælde af en stak.
  • Det er tilrådeligt at bruge linkaggregeringsprotokoller (LACP, MLT, PAgP osv.) til at kombinere links i grupper og afbalancere belastningen mellem dem.
  • brug routere, der understøtter ECMP (Equal-Cost-Multi-Path) protokoller - når disse pakker, når de leverer flere pakker langs én rute, ikke går gennem én bedste sti (og interface), men er fordelt på flere bedste-stier (og flere interfaces), som bestemmes af ligheden mellem metrikerne for routingprotokollen, som igen er ansvarlig for routing-tabellen.

  Og nu, som lovet, vil jeg beskrive en reel sag fra min praksis og princippet om at spare ved reservation af kritiske noder, hvilket skete for flere år siden:

  • Et firma, jeg vil kalde det X, havde en standard 3-lags netværksmodel:
    • med flere kerner
    • flere dusin sammenlægninger
    • flere tusinde adgangskontakter
    • af flere titusindvis af brugere

  • netværket blev bygget ret komplekst:
    • med en masse dynamiske routingprotokoller og protokoller - OSPF, MP-BGP, MPLS, PIM, IGMP, IPv6 osv.
    • en masse tjenester - internetadgang, L2 og L3 VPN, VoIP, IPTV, dedikerede linjer osv.

  • men der var en flaskehals i netværket - grænserouteren, som kombinerede funktionerne fra en BGP grænserouter og afsluttede nogle brugertjenester
  • Ja, det kostede lige så meget som en flyvinge (flere millioner rubler)
  • Ja, på det tidspunkt var det en af ​​de bedste enheder i rækken af ​​den mest berømte netværksleverandør
  • Ja, den skulle være meget pålidelig - med en fremragende MTBF-vurdering
  • Ja, den havde 4 strømforsyninger, samlet i henhold til 2x2-skemaet og forbundet fra forskellige UEPS og indgange.

  Men alt dette ændrede ikke på det faktum, at han var et enkelt fejlpunkt i netværket.

  Og en dag, langt fra vidunderligt for mig og mine kolleger, opgav denne router spøgelsen (senere fandt vi ud af, at der var en form for fejl på strømforsyningsledningen gennem UEPS, hvilket førte til samtidig svigt af 2 strømforsyninger, og samtidig brændte en af ​​forsyningerne RP-modulet på routeren og interfacekortets databussen, som var forbundet til det fælles kort).

  Vi havde ikke nogen backup-kort - RP- og interfacekort, men vi havde en kontrakt om udskiftning af udstyr eller dets komponenter med en af ​​partnerne under NBD-ordningen.

  Desværre havde partnerne på det tidspunkt kun interfacekortet på lager, men ingen RP board, det ankom kun få dage senere (3 dage senere).

  Som følge heraf resulterede tilstedeværelsen af ​​et enkelt fejlpunkt i netværket (selv med en supportkontrakt og udskiftning af udstyr) i følgende økonomiske omkostninger:

  • andelen af ​​virksomhedens tjenester, relateret til eller forbundet med denne grænse, var omkring 60-70 %
  • som det senere blev beregnet, var den daglige fortjeneste omkring 900 tusind rubler (ca.) på det tidspunkt
  • I løbet af 3 dages nedetid gik der teoretisk tabt overskud i størrelsesordenen 1 million 620 tusind rubler til 1 million 890 tusind rubler

  Naturligvis var nettotabene mindre, da kompensationen for størstedelen af ​​brugerne ikke blev returneret i form af penge, men i form af tjenester, men de eksisterede stadig:

  • del af kompensationen til erhvervsbrugere
  • øgede omkostninger for virksomhedens medarbejdere, der arbejdede alle 3-4 dage i fuld kraft - overarbejde, nattevagter, øgede vagter mv.
  • tab af omdømme, hvilket heller ikke er uvæsentligt
  • og vigtigst af alt - nerverne hos både ledelse og medarbejdere, samt kunder

  Som følge heraf blev virksomhedens politik revideret:

  • afviste erstatningskontrakten under NBD-betingelserne
  • forlod den sædvanlige servicekontrakt
  • købte en dublet router til en værdi af cirka 1-1.3 millioner rubler for at sikkerhedskopiere 90% af funktionaliteten af ​​den vigtigste

  Efterfølgende har køb af ekstra udstyr og backup af hovedudstyret givet os mulighed for at balancere belastningen på eksterne links, trafik og brugere mellem dem, og det gav en sikkerhedsmargin for virksomheden i fremtidige ulykker.

  Enterprise Network Design Eksempel

  I denne del af artiklen vil jeg forsøge at skitsere hovedpunkterne ved beregning af virksomhedens backbone-netværk. Jeg vil ikke overbelaste dig med hele PPDIOO-metoden (Prepare-Planning-Design-Implement-Operate-Optimize), men vil kun skitsere dens hovedpunkter:

  • Forberedelse/Forberedelse — du skal sammen med din ledelse tage stilling til de mål for netværksmodernisering, du ønsker at opnå — øge fejltolerancen, implementere nye tjenester eller teknologier. Jeg vil springe over at definere begrænsningerne - tekniske og organisatoriske - her, da jeg går ud fra, at du er ansat i organisationen og har en stor tidsreserve til at overkomme dem. Jeg vender tilbage til emnet for budgettet nedenfor.
  • Planlægning/Плания - her skal du bygge en komplet beskrivelse af dit nuværende netværk (hvis du ikke kender det endnu), dvs. beskrive netværket, som det er nu:
    • mængde og type af udstyr
    • antal og typer af havne
    • eksisterende kabelføringer og skifteordninger inden for og mellem bygninger
    • strømforsyningsordninger
    • L2 og L3 adressering
    • oprette Wi-Fi-netværkskort med adgangspunkter og controllere
    • beskriv din serverfarm
    • Det er tilrådeligt at beskrive alle dine tjenester og forbindelserne mellem dem
    • Hvis du allerede har implementeret en netværkssikkerhedspolitik og netværksadgangskontrolpolitik i en eller anden form, skal du sørge for at tage det i betragtning, når du designer
    • Jeg vil gerne påpege med det samme, at det andet trin i det væsentlige repræsenterer en komplet opgørelse over netværket, startende fra kabelinfrastrukturen og strømforsyningskredsløbene og slutter med tjenester (applikationer og deres porte). Dette trin er meget, meget arbejdskrævende og nogle gange endda kedeligt. Hvis du eller din forgænger ikke havde dokumentation eller endda et grundlæggende overvågningssystem, er det nu, du skal tænke over det. Netværket har en tendens til at ændre sig over tid med varierende hastigheder, og kun opretholdelse af opdateret dokumentation eller et overvågningssystem kan hjælpe dig med at holde styr på dets status og gøre det nemmere at administrere. Men dette vedrører allerede operationstrinnet.

  • Design/design - bevæbnet med fuldstændig viden om dit netværk, opnået i det foregående trin, sætter du dig endelig ned og tænker over, hvordan du opgraderer dit netværk. Nedenfor vil jeg forsøge at demonstrere et lille eksempel på netværksberegning.

  Til mig selv har jeg samlet en lille liste over indledende data, som jeg vil bruge ved beregning og design af supportnetværket.

  Lad os forestille os forberedelsestrinnet som en liste over, hvad vi har til rådighed, og hvad vi planlægger at gøre:

  • der er en ret stor virksomhed med et omtrentligt antal arbejdspladser, omkring 700-800 stykker (her mener jeg de medarbejdere, der kræver adgang til virksomhedens netværk)
  • Der er flere separate bygninger inden for virksomhedens område:
  • Hovedbygninger:
    • antal bygninger - 2 stk
    • Antal etager i bygningen - 7
    • antal teleskabe pr. etage i én bygning - 3 (i alt 21) stk.
    • antal ansatte i bygningen =~ 250 personer

  • Yderligere huse:
    • antal bygninger - 10 stk
    • antal etager i bygningen/værkstedet - 2 stk.
    • Antal teleskabe i bygningen - 3 stk.
    • antal ansatte i bygningen =~ 20 personer

  • Det nuværende niveau af netværkskernen (forresten en meget almindelig ordning, som jeg har stødt på mere end én gang i en eller anden form og i sammensætningen af ​​havne) præsenteres:
    • 2 L2 kontakter:
      • 1Gb RJ-45 porte - 24 stk.
      • 1Gb SFP porte - 4 stk
    • 1. L2 switch:
      • 1Gb SFP porte - 24 stk
    • kernetopologi - ring
    • peer-to-peer-forbindelser mellem switches er aktiveret ved hjælp af optiske fibre
    • afbrydere er placeret i små serverrum med skabe
  • Nuværende distributionsniveau:
    • kombineret med netværkets kerneniveau med hensyn til aggregering af links fra adgangsswitches
    • L3-adressering flyttes til grænserouteren og/eller firewallen
  • Nuværende adgangsniveau:
    • L2-switche med 16 x 100 Mb RJ-45-adgangsporte og 2 Gigabit uplink combo RJ-45/SFP-porte
    • afbrydere er placeret i skabe på etagerne
    • adgangskontakttopologi:
      • stjerne (nav-og-eger) med en kerne/fordelingskontakt i midten
      • bjælke/eger er en gren af ​​afbrydere på gulve - 3 stk i en kæde
    • der er uadministrerede adgangskontakter
    • kontakter i yderligere 9 tilfælde er forbundet via mediekonvertere (optisk signal til elektriske signalomformere)
  • Nuværende kabelinfrastruktur:
    • Kabelsystem mellem bygninger:
      • der er et optisk kabel mellem de 2 hovedbygninger med en kapacitet på 8 fibre
      • der er 1 optisk kabel mellem en af ​​de ekstra bygninger (hvor kerneafbryderen er installeret) og hver af hovedbygningerne med en kapacitet på 8 fibre hver
      • der er 1 optisk kabel mellem add. etuier og etuier med installerede 4-fiberkerneswitche (deres fordeling er vist på billedet nedenfor)
      • fibertype i alle kabler er single mode/SMF
      • 2-fiber single-mode SFP transceivere anvendes
      • nogle kabler er termineret ved optiske fordelerrammer (ODF) i separate rum (krydsrum/serverrum), og nogle kabler er termineret ved kontrolrum på gulvniveau

    • Kabelsystem inde i bygninger:
      • Der er en blandet kabelstruktur mellem serverrummene og de første skabe på etagerne:
      • kobberkabler Cat5e - 10 stk (eller 100 par kabler)
      • fiberoptisk multimode/MMF kabel til 4 eller 8 fibre - 1 stk.
      • 4-fiber multimode/MMF fiberoptisk kabel mellem gulvskabe
      • Cat5e kobberkabler mellem gulvskabe og adgangsudtag
    • Nuværende datacenter:
      • der er flere servere, fx 6 stk
      • inkluderet 1Gb porte i kerneswitchen i 1. hovedbygning
      • Alle virksomhedsapplikationer flyttes til servere
    • L2, L3 adressering og routing:
      • Der er flere VLAN'er i netværket - 2,3 pr. bygning
      • servere er allokeret til et separat /24 netværk
      • til interne behov anvendes grå klasse B netværk, som indgår i sortimentet - 172.16.0.0/16
      • L3-adresser afsluttes ved grænserouteren og/eller firewallen
      • statisk routing anvendes
    • yderligere oplysninger:
      • telefoni:
        • Traditionel telefoni ved hjælp af gammeldags digital PBX (ikke IP-PBX) er blevet implementeret i bygninger og nogle enheder
        • det er nødvendigt at stille telefoner til rådighed for nye bygninger, uden omkostningerne ved at lægge dyre kobberkabelledninger af en vis kapacitet og bygge et duplikat SCS til telefoni inde i bygninger
        • Over tid er det planlagt at implementere IP-telefoni i hele virksomheden, kombinere det med CRM-systemer og overføre alle medarbejdere til det.
      • Havnekapacitet:
        • Det er nødvendigt at analysere den nuværende kapacitet af trunkporte og adgangsporte og reservere mindst 25-30 % til fremtidige behov
        • analysere tilstrækkeligheden af ​​den nuværende gennemstrømning af adgangsporte og trunklinks
        • sørge for tilstedeværelsen af ​​PoE/PoE+-adgangsporte til enheder fra tilstødende systemer - videoovervågning og telefoni
      • videoovervågning:
        • Det er planlagt at bruge virksomhedens netværk som transport for videoovervågningsnetværket
        • Det er nødvendigt at levere PoE-porte til CCTV-kameraer
      • trådløse systemer:
        • I fremtiden er det planen at implementere en trådløs infrastruktur til medarbejdermobilitet
        • Det er nødvendigt at levere PoE-porte til adgangspunkter
      • budget, deadlines og udstyrskrav:
        • få mest muligt ud af dit eksisterende udstyr
        • ved projektering af et netværk tages der højde for muligheden for at udvide netværkskapaciteten i N år frem
        • Når du designer et netværk, skal du tage højde for understøttelse af alle mulige sikkerhedsfunktioner - her er en liste over funktionalitet, startende fra portsikkerhed og slutter med autentificering og autorisation af brugere via 802.1x.
        • reserver så vidt muligt kritiske netværksknuder af primær betydning - kernen og datacentret, og giv mulighed for at reservere noder af sekundær betydning - distributionsknudepunkter
        • projektbudgettet bør sørge for sekventiel finansiering i flere faser
        • budgetbeløb - her bestemmer hver virksomhed sig selv, styret af sine finansielle indikatorer
        • deadlines - i det mest ideelle tilfælde vil der ikke være nogen eksplicitte deadlines, da dette er et internt projekt i virksomheden, som implementeres af dens ansatte, eller de vil være relativt komfortable - for eksempel 1 år (eller mere). I værste fald kan det være fra 3 måneder til seks måneder.
      • fejlfinding af aktuelle netværksproblemer:
        • pakketab
        • DHCP-problemer på mere eller mindre intelligente adgangsswitches relateret til brugen af ​​STP-protokolfamilien til at bekæmpe sløjfer på adgangsporte.
        • slippe af med tilstedeværelsen af ​​en DHCP-servergrænseflade i hver medarbejders VLAN
        • fremkomsten af ​​koblingssløjfer forbundet med uautoriseret aktivering af administrerede/ikke-administrerede kontakter på kontorer og forbindelsen af ​​alle slags enheder til dem
        • listen bliver ved og ved...

      Planlægningstrinnet - karakterisering af dit nuværende netværks tilstand, som jeg allerede skrev, afhænger af tilgængeligheden af ​​et overvågningssystem af høj kvalitet og graden af ​​dets dokumentation. I dette trin skal du:

      • i det mindste skitsere det eksisterende netværk til yderligere analyse
      • indsamle data fra udstyr:
        • trafik på trunkhavne
        • fejl på porte
        • CPU-belastning og hukommelsesforbrug på switche og routere
        • beskrive L2-L3-skemaer ved VLAN'er og IP-adresser
      • hæve kabelrutediagrammer:
        • fiberoptiske diagrammer og optiske krydsforbindelsesdiagrammer
        • kobberkabel distributionsordninger mellem serverrum og etager
        • kobberkabelfordelingsordninger mellem etager og kontorer
        • kontrollere tilstedeværelsen af ​​optiske kryds og patchpaneler i serverrum og kabinetter
      • kontrollere strømforsyningskredsløbene i serveren og gulvskabene
      • kontrollere tilstedeværelsen af ​​UPS og batterier på kritiske knudepunkter
      • analysere alle data

      Baseret på data fra forberedelsesstadiet kom jeg med et groft logisk diagram:

      
      
      Dernæst, efter den modulære tilgang, er det nødvendigt at identificere virksomhedens niveauer og moduler:

      
      
      Jeg vil ikke berøre Edge i denne artikel, men vil kort huske de grundlæggende teser for hvert af Campus-modulerne:

      • Adgang - på dette niveau skal sikre:
        • det nødvendige antal porte for brugere at få adgang til netværket
        • implementering af sikkerhedspolitikker - filtrering af trafik og protokoller
        • Broadcast domænekomprimering og netværkssegmentering ved hjælp af VLAN'er
        • Implementering af separate VLAN'er til taletrafik
        • QoS support
        • understøttelse af PoE-adgangsporte
        • IP multicast understøttelse
        • fejltolerance for uplinks i forbindelse med distributionslaget (ønskeligt)
      • Fordeling - på dette niveau bør følgende sikres:
        • det nødvendige antal porte til tilslutning af adgangskontakter
        • aggregering og redundans af adgangsswitchlinks
        • IP routing
        • pakkefiltrering
        • QoS support
        • fejltolerance på link-, hardware- og strømforsyningsniveau (højst ønskeligt)
      • Kernen skal give:
        • højhastigheds-omskiftning og pakkerouting
        • det nødvendige antal porte til tilslutning af distributionsafbrydere
        • understøttelse af IP-routing og dynamiske routingprotokoller med hurtig netværkskonvergens
        • QoS support
        • sikkerhedsfunktionalitet til at beskytte adgang til udstyr og kontrolfly
        • hardware og strømforsyning fejltolerance (obligatorisk)
      • Datacenter - netværkslaget i dette modul skal give:
        • højhastighedskommunikationsforbindelser
        • det nødvendige antal porte for at forbinde servere
        • redundans af kommunikationsforbindelser både mellem servere og datacenterswitches og mellem datacenterswitches og netværkskernen (påkrævet)
        • udstyr og strømforsyning backup (påkrævet)
        • QoS support

      Dernæst skal vi tælle vores havne og kommunikationsforbindelser og bestemme kravene.
      Adgangsniveau - Portberegningstabel

      Så vi har indhentet data om fordelingen af ​​adgangsporte efter bygninger. Nu er det nødvendigt at analysere adgangsniveaukravene og kommentarer og skitsere løsningsmuligheder.
      Adgangsniveau - krav og løsningsmuligheder

      Dernæst vil vi beregne portene og kommunikationsforbindelserne for følgende niveauer:

      Distributionsniveau

      Kerneniveau

      Datacenter niveau

      Ved beregningen fik vi følgende:

      • adgangsniveau — Der kræves 24- og 48-ports adgangsswitche, fortrinsvis med 1 Gb adgangsporte og med optiske uplink SFP-porte med PoE-understøttelse og bred funktionalitet:
        • i alt vil de give 504 adgangsporte, som i princippet vil dække kravene til reserveporte, hvis der besluttes at bruge 2 porte pr. arbejdsstation - en IP-telefon og en dataport.
        • Det er muligt at bruge én 48-ports switch med PoE-funktionalitet på hver etage, hvilket giver adgangsporte til kravene:
          • reserve - cirka 102 reservehavne (22%) på hovedbygningerne. For yderligere bygninger lidt mere - 25%.
          • videoovervågning
          • trådløst netværk
      • distributionsniveau — switches med et sæt SFP-porte fra 12 til 48 porte med mindst 2 SFP+-porte, med evnen til at stable og udvidet funktionalitet, samt tilstedeværelsen af ​​backup-strømforsyninger er påkrævet.
      • kerneniveau — højhastighedsswitche med 12 til 24 SFP/SFP+-porte med understøttelse af både stabling og clustering med MC-LAG-understøttelse er påkrævet. Jeg skal bemærke, at det også er muligt at bruge routingværktøjer til at balancere trafik. De seneste generationer af L3-switche og -routere understøtter ECMP med trafikbalancering på tværs af 4 eller flere ruter med samme metrik.
      • datacenterniveau — switches med 8 til 24 SFP/SFP+-porte med understøttelse af både stabling og clustering med MC-LAG-understøttelse er påkrævet.

      Målnetværksordningen blev endelig nået sådan

      Valg af ekstreme switche til projektimplementering

      Nå, nu er vi kommet til det vigtigste - tidspunktet for at vælge kontakter til implementeringen af ​​vores projekt. Følgende ekstreme kontakter er velegnede til det resulterende måldesign:

      Level
      Model
      havne
      beskrivelse

      kerne
      x620-16x-Base*

      x670-G2-48x-4q-Base*
      16 x 10GE SFP+
       
       
       
      48x10GE SFP+ og 4x40GE QSFP+
      Til kernens kernebehov:

      • højhastighedsforbindelser
      • Avanceret routing- og sikkerhedsfunktionalitet
      • ekstra strømforsyning backup strømforsyninger
      • støtte til stabling og klyngedannelse

      x620-seriens switch vil klare opgaven for minimumskrav.
      For udvidede krav til antallet af porte og bredere funktionalitet er det værd at overveje switchene i x670-G2-serien.

      Datacenter

      x620-16x-Base*

      x590-24x-1q-2c*

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

      16 x 10GE SFP+
       
       
       
      24x10GE SFP, 1xQSFP+, 2xQSFP28
       
       
      48x10GE SFP+ og 4x40GE QSFP+

      Til datacentrets basale behov:

      • højhastighedsforbindelser
      • ekstra strømforsyning backup strømforsyninger
      • støtte til stabling og klyngedannelse

      x620-seriens switch vil klare opgaven for minimumskrav.
      I tilfælde af udvidede krav til antallet af porte og bredere funktionalitet er det værd at overveje switchene i x670-G2 og x590-24x-1q-2c-serien.

      fordeling

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

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

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

      Til grundlæggende distributionsbehov:

      • det nødvendige antal optiske porte
      • ekstra strømforsyning backup strømforsyninger
      • støtte til stabling og klyngedannelse
      • påkrævet L3-funktionalitet

      x460-G2-seriens switche er ideelle. Tilstedeværelsen af ​​redundante strømforsyninger med mulighed for at udvide og tilføje 10G, CX (til stabling) og QSFP+ porte gør dem til ideelle switche til distributionslaget med porte op til 1 Gb.

      adgang

      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+ combo porte
       
      48x1000BASE-T(4 x SFP combo),4x10GE SFP+ combo porte (PoE budget 740 W)

      For adgangsbehov:

      • påkrævet antal adgangsporte
      • PoE/PoE+ understøttelse
      • funktionalitet og portudvidelsesmuligheder
      • en ekstra bonus i form af støtte til stabling af 10Gb-porte "ud af boksen"

      Jeg anbefaler at være opmærksom på denne linje med hensyn til dens fleksibilitet med hensyn til porte, ydeevne og funktionalitet.

      *specifikationen af ​​de valgte kontakter kan findes i den første artikel i serien — Gennemgang af ekstreme switches

      Jeg kunne afslutte artiklen her, men jeg vil gerne fremhæve to yderligere aspekter, som enhver ingeniør vil støde på, når de udvikler eller opgraderer deres netværk:

      • arbejde med kabelføringer - fibre og kobberledninger
      • IP-adressering

      Arbejde med fibre

      Ovenfor har jeg givet en målordning, der skal nås. For at implementere det kræves følgende antal forbindelser til udstyr:

      antal kommunikationslinks

      Som det kan ses af tabellen, er minimumsantallet af fibre, der kræves for at sikre fejltolerance af netværksniveauer (kernemodul, datacenter og distribution i 2 bygninger) 10 stk.

      Under netværkskarakteriseringsfasen fandt vi ud af, at der kun var 8 fibre i kablet mellem bygningerne. Hvad skal man gøre i sådan en situation?

      Jeg vil give nogle løsninger:

      • Det første oplagte trin er at bruge reservefibrene i kablet mellem Bygning 1 - Bygning 1 og Bygning 1 - Bygning 2 (som du kan se af tabellen, er der kun brugt 2 af de 8 fibre i hvert kabel). For at gøre dette er det nok at installere optiske krydsforbindelser mellem krydsforbindelserne i tilfælde 1 og om nødvendigt bruge SFP-moduler med et reserveoptisk budget.
      • Det andet trin er den mulige brug af CWDM-teknologi – multipleksing af bærebølgelængder inden for en enkelt fiber. Denne teknologi er meget billigere end DWMD og er ret enkel at implementere. Kravene er hovedsageligt til kvaliteten af ​​optiske fibre og SFP/SFP+ transceivere af en vis længde og budget. Som jeg nævnte i den forrige artikel, kan switches evne til at genkende tredjeparts transceivere gøre vores liv meget lettere og reducere kapitalomkostningerne ved at bygge yderligere optiske kabler.
      • Det tredje trin er at overveje muligheden for at øge antallet af fibre ved at lægge yderligere optiske kabler.

      Dernæst ser vi på antallet af fibre mellem bygninger med installerede distributionsafbrydere og tilføjer. bygninger 2-10. Heller ikke her er alt så klart:

      • for det første er der ikke nok fibre til at implementere vores målskema - 2 fibre for hver switch (som vi husker, har vi kabler med 4 OB for hvert tilfælde)
      • for det andet, selvom der er et tilstrækkeligt antal fibre mellem bygninger, bruges MMF-fibre inde i bygningerne, hvilket ikke vil tillade os blot at forbinde SMF- og MMF-fibre (jeg taler om afstande mellem bygninger over 300-400 meter)

      I sådanne tilfælde kan følgende muligheder overvejes:

      • Forsyning af hver SMF-switch med fibre:
        • Hvis afstanden tillader det, kan du forlænge yderligere lange patch-ledninger mellem kontakterne. På et tidspunkt brugte vi lappesnore 30-50 m lange.
        • lægge relativt billigt optisk SMF-kabel med lav kapacitet mellem skabene
        • som en sidste udvej, brug forskellige SMF-MMF-konvertere
      • For at minimere mængden af ​​fiber, der bruges mellem bygninger, kan du:
        • brug stable-funktionaliteten fra x440-G2-adgangsswitches - mens du bruger 1 SMF-fiber til hver switch på gulvet, hvilket vil tillade brug af 6 fibre og porte på hver side i stedet for 3 fibre og porte
        • brug 2 fibre til at forbinde den første switch i grenen og den sidste. Saml links på kantadgangskontakter og brug STP-protokoller i den resulterende ring.

      IP-adressering

      Her vil jeg give en omtrentlig beregning af adressering for vores ordning.

      I øjeblikket har vi flere klasse B netværk - 172.16.0.0/16. Når jeg beregner IP-adresserummet, vil jeg blive styret af følgende overvejelser:

      • De 4 bits af den anden oktet vil repræsentere bygningerne - 172.16.0.0/12.
      • Oktet 3 vil angive etagenummeret i bygningen.
      • 3 oktetter = 255 vil blive tildelt for punkt-til-punkt-forbindelser af udstyr og kontrolnetværk.
      • et styrings-VLAN pr. etage til styring af switches.
      • én bruger VLAN pr. switch (24 porte i gennemsnit).
      • et Voice VLAN pr. switch (24 porte i gennemsnit).
      • et VLAN til videoovervågningssystem pr. etage.
      • et VLAN til Wi-Fi-enheder pr. etage.

      Jeg har tabeller, der ser sådan ud:
      netværk 172.16.0.0/14
      netværk 172.20.0.0/14

      I tabellen ovenfor har jeg givet en omtrentlig fordeling af netværk på bygninger og etager på den ene side og netværk (bruger, forvaltning og service) på den anden side.

      Faktisk er det ikke det mest optimale at vælge det grå netværk 172.16.0.0/12, da det begrænser os i antallet af netværk (fra 16 til 31) for bygninger, og der er også fjernkontorer, der også skal skære netværksblokke, måske ville en mere optimal mulighed være at bruge 10.0.0.0/8 netværk til 172.16.0.0/12 fælles brug af .10.0.0.0 netværk, eller 8. for eksempel til servicebehov og servere) og XNUMX/XNUMX (til brugernetværk).

      Generelt er tilgangen til at allokere IP-netværk også modulær, og det er ønskeligt at overholde reglerne for at opsummere undernet i ét oversigtsnetværk på distributionsniveauer såvel som på grænseroutere i fjerntliggende filialer. Dette gøres af flere årsager:

      • for at minimere routingtabeller på routere
      • for at minimere servicetrafik af routingprotokoller (alle slags opdateringsmeddelelser, når indlejrede undernet ikke er tilgængelige)
      • for at forenkle administrationen og forbedre læsbarheden af ​​L3-netværk

      Selvom det er værd at bemærke med hensyn til de første 2 punkter, at kapaciteten af ​​moderne routere er meget højere end for 15-20 år siden og giver dem mulighed for at indeholde store routing-tabeller i deres RAM, og forholdet mellem pris og båndbredde af kommunikationskanaler er faldet sammenlignet med priserne i tider med udbredt brug af E1/T1 (G.703) flows.

      Konklusion

      Venner, i denne artikel forsøgte jeg at fortælle så kort som muligt om de grundlæggende principper for at designe campusnetværk. Ja, der var ret meget materiale, og det er på trods af, at jeg ikke har berørt emner som:

      • organisation af virksomhedens grænse (og dette er en separat historie med sine egne switche, grænser, firewall, IPS/IDS-systemer, DMZ, VPN og andre ting)
      • Wi-Fi-netværksorganisation
      • Organisering af VoIP-netværk
      • organisation af datacenter
      • sikkerhed (og dette er også en separat verden, som med hensyn til volumen og krav ikke er ringere end designet af en ren netværksinfrastruktur, og nogle gange endda overgår den)
      • energiteknik
      • listen bliver ved og ved

      Faktisk er design og opbygning af et virksomhedsnetværk en ret omhyggelig opgave, der kræver meget tid og ressourcer.

      Men jeg håber, at min artikel vil hjælpe dig med at evaluere og forstå på et grundlæggende niveau, hvordan du griber denne opgave an.

      Dette er langt fra den sidste artikel om Ekstreme netværk, så følg med (Telegram, Facebook, VK, TS Solution Blog)!

Kilde: www.habr.com