3. Enterprise nettverksdesign på Extreme-svitsjer

God ettermiddag, venner! I dag fortsetter jeg serien dedikert til Ekstreme brytere artikkel om design av bedriftsnettverk.

I denne artikkelen vil jeg prøve å være så kortfattet som mulig:

• beskrive en modulær tilnærming til nettverksdesign i Etnterprise
• vurder konstruksjonstypene til en av de viktigste modulene i bedriftsnettverket - ryggradsnettverket (IP-campus)
• beskrive fordeler og ulemper ved alternativer for redundans av kritiske nettverksnoder
• bruk av et abstrakt eksempel for å designe/oppdatere et lite bedriftsnettverk
• velg Extreme-svitsjer for å implementere det designede nettverket
• jobbe med fibre og IP-adressering

Denne artikkelen vil være mer interessant for nettverksingeniører og nettverksadministratorer for bedrifter som akkurat har startet sin karriere som nettverksbyggere, enn for erfarne ingeniører som har jobbet i mange år i telekomoperatører eller store selskaper med geografisk distribuerte nettverk.

Uansett er interesserte velkommen til å lese videre.

Modulær tilnærming til nettverksdesign

Jeg vil starte artikkelen min med en ganske populær modulær tilnærming til nettverksdesign, som lar deg sette sammen et puslespill fra nettverksbrikker til ett komplett bilde.

Først, litt abstraksjon – jeg forestiller meg ofte denne tilnærmingen som en zoom på geokart, hvor landet er synlig i den første tilnærmingen, regionene i den andre, byene i den tredje, osv.

La oss som et eksempel vurdere følgende:

• 1. tilnærming - hele bedriftsnettverket er et sett med forskjellige nivåer:
  • stamnettverk eller campus
  • grensenivå
  • teleoperatørnivå
  • avsidesliggende områder

• 2. tilnærming - hvert av disse nivåene er detaljert i separate moduler
  • Stamnettverket eller campusen består av:
    • 3- eller 2-nivåmodul som beskriver bedriftsnettverket og dets nivåer - tilgang, distribusjon og/eller kjerne
    • modul som beskriver datasenteret (i hovedsak serverdelen av infrastrukturen)

  • Grensenivået består igjen av:
    • Internett-tilkoblingsmodul
    • WAN- og MAN-moduler, som er ansvarlige for å koble til geografisk distribuerte bedriftsobjekter
    • modul for bygging av VPN-tunneler og fjerntilgang
    • Ofte har mange små bedrifter flere av disse modulene, eller til og med alle, kombinert til én.

  • leverandørnivå:
    • Dette nivået inkluderer forbindelser «til omverdenen» – mørke optiske fibre (fiberleasing fra operatører), kommunikasjonskanaler (Ethernet, G.703, etc.), internettilgang.

  • Fjernnivå:
    • For det meste er dette grener av en bedrift som er distribuert innenfor en by, region, land eller til og med kontinent.
    • Denne sonen kan også inkludere et backup-datasenter som dupliserer arbeidet til hovedsenteret.
    • og selvfølgelig blir telearbeidere (fjernarbeidsplasser) stadig mer populære i det siste.

• 3. tilnærming – hver modul er delt inn i mindre moduler eller nivåer. For eksempel, i et campusnettverk:
  • 3-lagsnettverket er delt inn i:
    • tilgangsnivå
    • distribusjonsnivå
    • kjernenivå

  • I mer komplekse tilfeller kan datasenteret deles inn i:
    • 2- eller 3-nivå nettverksdel
    • serverdel

  Jeg skal prøve å vise alt det ovennevnte i den følgende forenklede figuren:

  
  
  Som du kan se av figuren ovenfor, bidrar den modulære tilnærmingen til å detaljere og strukturere helhetsbildet i bestanddeler som deretter kan arbeides med.

  I denne artikkelen vil jeg fokusere på Campus Enterprise-nivået og beskrive det mer detaljert.

  Typer IP-CAMPUS-nettverk

  Da jeg jobbet for en leverandør, og spesielt senere – da jeg jobbet som integrator, møtte jeg ulik «modenhet» i kundenes nettverk. Det er ikke uten grunn at jeg bruker begrepet modenhet, siden det ganske ofte er tilfeller der nettverksstrukturen vokser i takt med veksten til selve selskapet, og dette er i prinsippet naturlig.

  I et lite selskap som ligger i én bygning, kan bedriftsnettverket bestå av bare én grenseruter som fungerer som brannmur, flere tilgangssvitsjer og et par servere.

  Jeg kaller et slikt nettverk for meg selv et "enkeltlags" nettverk - det har absolutt ikke noe åpenbart kjernenettverksnivå, distribusjonsnivået er flyttet til grenseruteren (med brannmur, VPN og muligens proxy-funksjoner), og tilgangsbrytere betjener både ansattes datamaskiner og servere.

  
  
  Ved bedriftsvekst – en økning i antall ansatte, tjenester og servere – er det ofte nødvendig å:

  • øke antallet svitsjer i nettverket og tilgangsporter
  • øke serverkapasiteten
  • bekjemp kringkastingsdomener - implementer nettverkssegmentering og ruting mellom segmenter
  • bekjempe nettverksfeil som forårsaker nedetid for ansatte, da dette medfører ekstra økonomiske kostnader for ledelsen (den ansatte er inaktiv, lønnen utbetales, men arbeidet er ikke gjort)
  • I prosessen med å håndtere feil, bør du vurdere å sikkerhetskopiere kritiske nettverksnoder – rutere, svitsjer, servere og tjenester
  • stramme inn sikkerhetsreglene, ettersom kommersielle risikoer kan oppstå, og igjen – for mer stabil nettverksdrift

  Alt dette fører til at ingeniøren (nettverksadministratoren) før eller siden tenker på riktig konstruksjon av nettverket og kommer frem til en 2-nivåmodell.

  Denne modellen skiller allerede tydelig mellom to nivåer – tilgangsnivået og distribusjonsnivået, som også er kjernenivået (collapsed-core).

  Det kombinerte distribusjons- og kjernelaget utfører følgende funksjoner:

  • samler lenker fra tilgangsbrytere
  • introduserer nettverkssegmentruting - det er så mange brukere og enheter at de ikke passer inn i et enkelt /24-nettverk, og hvis de gjør det, forårsaker kringkastingsstormer konstante feil (spesielt hvis brukere hjelper dem ved å lage løkker)
  • sørger for kommunikasjon mellom tilstøtende brytersegmenter (via raskere lenker)
  • sørger for kommunikasjon mellom brukere og deres enheter og serverfarmen, som på dette tidspunktet også begynner å bli tildelt et eget nettverkssegment - datasenteret.
  • begynner å gi, sammen med tilgangsbryterne, i en eller annen grad, sikkerhetspolicyen som bedriften begynner å utvikle på dette tidspunktet. Selskapet vokser, kommersielle risikoer vokser også (her mener jeg ikke bare bestemmelser om forretningshemmeligheter, differensiering av tilgangspolicyer osv., men også om elementært nettverk og nedetid for ansatte).

  Dermed vokser nettverket før eller siden til en 2-lags modell:

  
  
  Denne modellen introduserer spesielle krav for både tilgangsnivåsvitsjer, som aggregerer koblinger fra brukere og nettverksenheter (skrivere, tilgangspunkter, VoIP-enheter, IP-telefoner, IP-kameraer osv.), og for distribusjons- og kjernenivåsvitsjer.

  Tilgangssvitsjer må bli mer intelligente og i stand til å møte krav til nettverksytelse, sikkerhet og fleksibilitet, og må:

  • ha ulike typer tilgangsporter og hovedporter – helst med mulighet for reservasjon for trafikkvekst, samt for antall porter
  • ha tilstrekkelig svitsjekapasitet og båndbredde
  • ha den nødvendige sikkerhetsfunksjonaliteten som vil tilfredsstille gjeldende sikkerhetspolicy (og ideelt sett veksten i dens videre krav)
  • ha muligheten til å drive vanskelig tilgjengelige nettverksenheter med muligheten til å starte dem på nytt eksternt via strømforsyning (PoE, PoE+)
  • kunne reservere din egen strømforsyning for å bruke den på steder der det er behov for den
  • ha (hvis mulig) ytterligere potensial for vekst i funksjonalitet - et vanlig eksempel når en tilgangssvitsj til slutt blir til en distribusjonssvitsj

  I sin tur må distribusjonsbryterne også oppfylle følgende krav:

  • både når det gjelder nedlinkporter for trunk mot tilgangssvitsjer, og mot peer-grensesnitt til nærliggende distribusjonssvitsjer (og senere mulige opplinkgrensesnitt mot kjernen)
  • i de funksjonelle delene L2 og L3
  • når det gjelder sikkerhetsfunksjonalitet
  • når det gjelder å sikre feiltoleranse (redundans, klynging og redundans i strømforsyningen)
  • når det gjelder å sikre fleksibilitet i trafikkbalansering
  • ha (hvis mulig) ytterligere potensial for vekst i funksjonalitet (transformasjon over tid av aggregeringsenheten til en kjerne)
  • I noen tilfeller kan det være passende å bruke PoE- og PoE+-porter på distribusjonssvitsjer.

  Og så er det mer: Hvis ledelsen fører en politikk med aktiv vekst og utvikling av bedriften, vil nettverket også fortsette å utvikle seg i fremtiden – bedriften kan begynne å leie nabobygg, bygge egne bygninger eller absorbere mindre konkurrenter, og dermed øke antallet arbeidsplasser for ansatte. Samtidig vokser også nettverket, noe som krever:

  • Tilby ansatte arbeidsstasjoner – nye tilgangsbrytere med tilgangsporter er nødvendig
  • tilgjengeligheten av nye distribusjonsbrytere for aggregering av koblinger fra tilgangsbrytere
  • bygging av nye og modernisering av eksisterende kommunikasjonslinjer

  Som et resultat øker trafikken av følgende årsaker:

  • på grunn av økningen i tilgangsporter og dermed nettverksbrukere
  • på grunn av økningen i trafikk fra relaterte delsystemer som velger bedriftsnettverket som transportmiddel – telefoni, sikkerhet, ingeniørsystemer osv.
  • på grunn av innføring av tilleggstjenester – etter hvert som personalet vokser, dukker det opp nye avdelinger som krever spesifikk programvare
  • Datasenterets datakraft øker for å møte krav til infrastruktur og applikasjoner
  • Sikkerhetskravene for nettverk og informasjon vokser – den berømte CIA-triaden (spøk), men seriøst, CIA – konfidensialitet, integritet og tilgjengelighet:
    • I denne forbindelse dukker det opp ytterligere krav til feiltoleranse og redundans på kritiske nettverksnivåer – distribusjons- og datasentre
    • igjen er det en økning i trafikken på grunn av innføringen av nye sikkerhetssystemer - for eksempel RKVI, osv.

  Før eller siden vil veksten i trafikk, tjenester og antall brukere føre til behovet for å implementere et ekstra nettverkslag – en kjerne som skal utføre høyhastighets bytte/ruting av pakker ved hjelp av høyhastighetskommunikasjonslenker.

  På dette tidspunktet kan bedriften gå over til en 3-lags nettverksmodell:

  
  
  Som det fremgår av figuren ovenfor, har et slikt nettverk et kjernenivå som aggregerer høyhastighetskoblinger fra distribusjonssvitsjer. Dermed har kjernesvitsjer også krav til:

  • grensesnittbåndbredde - 1GE, 2.5GE, 10GE, 40GE, 100GE
  • Koblingskapasitet og videresendingsytelse
  • grensesnitttyper - 1000BASE-T, SFP, SFP+, QSFP, QSFP+
  • antallet og settet med grensesnitt
  • redundansalternativer (stabling, klynging, redundans i kontrollkort (relevant for modulære svitsjer), redundans i strømforsyning osv.)
  • funksjonalitet

  På dette nivået av nettverket er teknisk modifikasjon definitivt nødvendig:

  • redundans av noder og kjernelenker (veldig, veldig, veldig ønskelig)
  • redundans av noder og lenker på distribusjonsnivåforbindelser (avhengig av kritikalitet)
  • redundans av kommunikasjonsforbindelser mellom tilgangsbrytere og distribusjonsnivået (hvis nødvendig)
  • introduksjon av dynamiske rutingsprotokoller
  • trafikkbalansering både i kjernen og på distribusjons- og tilgangsnivåene (om nødvendig)
  • implementering av tilleggstjenester – både transport- og sikkerhetstjenester (om nødvendig)

  så vel som juridisk, som definerer bedriftens nettverkssikkerhetspolicy, som utfyller den generelle sikkerhetspolicyen med tanke på:

  • krav til implementering og konfigurasjon av visse sikkerhetsfunksjoner på tilgangs- og distribusjonssvitsjer
  • krav til tilgang, overvåking og administrasjon av nettverksutstyr (protokoller for fjerntilgang, nettverkssegmenter som er tillatt for administrasjon, loggføringsinnstillinger osv.)
  • reservasjonskrav
  • krav til dannelse av minimum nødvendig reservedelssett

  I denne delen beskrev jeg kort utviklingen av nettverket og bedriften fra flere svitsjer og et par dusin ansatte til flere dusin (og kanskje hundrevis av svitsjer) og flere hundre (eller til og med tusenvis) ansatte som jobber direkte i bedriftsnettverket (og det finnes også produksjonsavdelinger og ingeniørnettverk).
  Det er tydelig at en slik «mirakuløs» og rask utvikling av bedriften i virkeligheten ikke forekommer.
  Det tar vanligvis år for en bedrift og et nettverk å vokse fra sitt opprinnelige nivå 1 til nivå 3 jeg beskriver.

  Hvorfor skriver jeg alle disse selvinntrykkene? Fordi jeg her vil nevne et begrep som ROI – return-on-investment (avkastning/inntjening av investeringer) og vurdere den siden av det som direkte angår valg av nettverksutstyr.

  Når nettverksingeniører og deres ledere velger utstyr, velger de ofte utstyr basert på to faktorer – utstyrets nåværende pris og den minimale tekniske funksjonaliteten som for øyeblikket er nødvendig for å løse en eller flere spesifikke oppgaver (jeg vil snakke om kjøp av utstyr for sikkerhetskopiering senere).

  Samtidig vurderes mulighetene for ytterligere "vekst" av utstyret sjelden. Når det oppstår en situasjon der utstyret har uttømt seg selv når det gjelder funksjonalitet eller ytelse, kjøpes kraftigere og mer funksjonelt utstyr, og det gamle leveres til et lager eller et sted på nettverket i henhold til prinsippet om "slik at det står" (forresten, dette er også grunnen til at det dukker opp en stor dyrehage med utstyr og kjøpet av en haug med informasjonssystemer som fungerer med det).

  I stedet for å kjøpe lisenser for ekstra funksjonalitet og ytelse, som er mye billigere enn nytt, mer effektivt utstyr, må du derfor kjøpe ny maskinvare og betale for mye av følgende grunner:

  • Nettverket vokser ofte sakte, og utvidelsen av funksjonalitet eller ytelsen til nettverkssvitsjen din kan være tilstrekkelig i lang tid.
  • Det er ingen hemmelighet at utstyr fra utenlandske leverandører er knyttet til utenlandsk valuta (dollar eller euro). For å være ærlig, fører veksten i dollaren eller euroen (eller periodisk mini-devaluering av rubelen, avhengig av hvordan man ser på det) til at dollaren for 10 år siden og dollaren nå er helt forskjellige ting fra rubelens synspunkt.

  For å oppsummere alt det ovennevnte, vil jeg bemerke at det å kjøpe nettverksutstyr med bredere funksjonalitet nå kan føre til besparelser i fremtiden.
  Her vurderer jeg kostnadene ved å kjøpe utstyr i sammenheng med å investere i nettverket og infrastrukturen min.

  Dermed følger mange leverandører (ikke bare Extreme) prinsippet om betal-etter-vekst, og legger til rette for en rekke funksjoner og muligheter for å øke grensesnittytelsen i utstyret, som deretter aktiveres ved å kjøpe separate lisenser. De tilbyr også modulære svitsjer med et bredt utvalg av grensesnitt- og prosessorkort, og muligheten til å øke både antallet og ytelsen konsekvent.

  Redundans av kritiske noder

  I denne delen av artikkelen vil jeg kort beskrive de grunnleggende prinsippene for redundans i så viktige nettverksnoder som kjernesvitsjer, datasentre eller distribusjoner. Og jeg vil begynne med å vurdere de generelle typene redundans - stabling og klynging.

  Hver metode har sine fordeler og ulemper, som jeg gjerne vil snakke om.

  Nedenfor er en generell oppsummeringstabell som sammenligner de to metodene:

  
  

  • administrasjon – som det fremgår av tabellen, har stabling en fordel i denne forbindelse, siden en stabel med flere svitsjer fra et administrasjonssynspunkt er representert av én svitsj med et stort antall porter. I stedet for å administrere for eksempel 8 forskjellige svitsjer under klynging, kan du bare administrere én under stabling.
  • avstand – for øyeblikket er fordelen med klynging strengt tatt ikke så åpenbar, siden det har dukket opp teknologier for å stable svitsjer via stablingsporter eller dobbeltfunksjonsporter (for eksempel SummitStack-V for Extreme, VSS for Cisco, osv.), som også avhenger av typene transceivere. Her gis fordelen til klynging basert på prinsippet om at det ved stabling finnes alternativer som krever bruk av vanlige stablingsporter, som ofte er koblet til spesielle kabler med begrenset lengde – 0.5, 1, 1.5, 3 eller 5 meter.
  • programvareoppdatering – her ser vi at klynging har en fordel fremfor stabling, og poenget er følgende – når du oppdaterer utstyrets programvareversjon med stabling, oppdaterer du programvaren på hovedbryteren, som deretter tar på seg rollen med å plassere den nye programvaren på reservebryterne i stakken. På den ene siden gjør dette arbeidet enklere, men oppdatering av programvaren krever ofte en omstart av maskinvaren på utstyret, noe som fører til en omstart av hele stakken og dermed til et avbrudd i driften og alle tjenester knyttet til den i en periode = omstartstid. Vanligvis er dette svært kritisk for kjernen og datasenteret. Med klynging – har du to enheter uavhengig av hverandre, hvor du kan oppdatere programvaren sekvensielt etter hverandre. I dette tilfellet kan avbrudd i tjenester unngås.
  • konfigurasjonsinnstillinger – her er fordelen selvsagt med stabling, siden du i tilfelle administrasjon bare trenger å redigere innstillingene for én enhet og dens konfigurasjonsfil. Ved klynging vil antallet konfigurasjonsfiler være lik antallet klyngenoder.
  • feiltoleranse — her er begge teknologiene omtrent like, men klynging har fortsatt en liten fordel. Årsaken til dette er følgende — hvis vi ser på stakken fra synspunktet til kjørende prosesser og protokoller, vil vi se følgende:
    • det finnes en hovedbryter som alle hovedprosessene og protokollene kjører på (for eksempel den dynamiske rutingsprotokollen - OSPF)
    • det finnes andre slave-svitsjer, der hovedprosessene som er nødvendige for å jobbe i stakken og betjene trafikken som går gjennom dem, kjører.
    • Når en hovedbryter svikter, registrerer den neste slavebryteren med høyest prioritet hovedbryterens feil.
    • den starter seg selv som en master og starter alle prosessene som kjørte på masteren (inkludert OSPF-protokollen vi observerer)
    • etter en viss tid med prosessstart (vanligvis ganske kort), begynner selve OSPF-protokollen å fungere
    • Dermed vil OSPF jobbe litt raskere ved feil på en av nodene under klynging enn under stabling (for tiden som kreves for å starte og initialisere prosesser og protokoller på stakk-slave-svitsjen). Selv om jeg bør bemerke at moderne stablingsprotokoller og svitsjer fungerer veldig raskt, tar ofte varigheten av trafikkavbruddet under stakk-svitsjing mindre enn ett sekund, men fortsatt nominelt vinner klynging i denne parameteren.

  • kompleksitet – som det fremgår av tabellen, gevinster ved stabling når det gjelder kompleksitet. Dette er en direkte konsekvens av elementene «administrasjon» og «innstillinger og konfigurasjon». En enkelt node tar mye kortere tid å konfigurere og administrere. Ved klynging er det også ofte nødvendig å konfigurere ytterligere rutingsprotokoller eller redundansprotokoller for gatewayer – VRRP, HSRP og andre.
  • utskifting av enheter — her har stabling en klar fordel. Svært ofte, for å erstatte en bryter i en stack, er det nødvendig å utføre minimum nødvendige utstyrsinnstillinger, for eksempel:
    • oppdater programvaren til den nye svitsjen til versjonen av stabelprogramvaren (og dette kan gjøres umiddelbart etter mottak av svitsjene i reservedelssettet)
    • sette opp noen grunnleggende kommandoer for stabling (og for noen typer svitsjer er kanskje ikke dette nødvendig)
    • fjern den defekte stakkbryteren og koble til en ny
    • koble til strømforsyning og patchkabler

  • elastisitet — Jeg anser det som en av hovedparametrene. Generelt er elastisitet en kompleks egenskap, som betyr egenskapen til noe å endre seg under påvirkning av en belastning og gå tilbake til sin opprinnelige form etter at det forsvinner. Merkelig nok vil den for klynging være høyere selv om man tar hensyn til poengsummen på 4:3 i egenskaper i favør av stabling. Det handler om den menneskelige faktoren. Ja, ja, ikke bli overrasket – styrken til slike stablingsparametere som enhetlig kontroll, konfigurasjon av innstillinger og forenklet kompleksitet er der svakheten ved stabling ligger når den menneskelige faktoren kommer inn i bildet.

  I arbeidet mitt innen IT har jeg opplevd mange situasjoner (og, ærlig talt, jeg har til og med gjort den samme feilen selv, spesielt tidlig) der en ingeniør, under konfigurasjonen av en stakk, gjorde en feil da han skrev inn en kommando eller aktiverte/deaktiverte en funksjon på utstyret, noe som resulterte i at hele stakken krasjet og krevde en manuell omstart. Det er verdt å nevne fansen av Putty-appen for... Windows (åh, denne høyreklikk-kopieringen).

  I virkeligheten er begge teknologiene ganske gode (spesielt sammenlignet med ingen redundans), og hver har sine egne styrker og svakheter, men for kjernenivået og for et tungt belastet datasenter ville jeg fortsatt foretrukket å bruke klynging.

  Selv om dette bare er min mening. Mange profesjonelle ingeniører som har jobbet profesjonelt med nettverksstøtte i mange år, kan bruke begge teknologiene like mye – alt avhenger av erfaring og kvalifikasjoner.

  I tillegg til teknologiene for stabling og redundans av nettverksnoder, finnes det også generelle prinsipper for redundans av deler av selve nettverksnoden og forbindelser mellom noder:

  Med redundans i en nettverksnode mener jeg:

  • redundante strømforsyninger – å installere to strømforsyninger som dupliserer hverandre (og helst koblet til den første strømforsyningskategorien) kan gjøre livet ditt mye enklere.
  • redundans av kontrollkort - hovedsakelig relatert til modulære brytere, som gir mulighet for tilkobling av flere dupliserte kontrollkort.
  • redundans for grensesnittkort – gjelder også hovedsakelig for modulære svitsjer.

  Redundans av forbindelser/lenker forstås hovedsakelig som tilstedeværelsen av dupliserte kabelruter (eller radiolenker i tilfelle åpne områder) med:

  • distribuert gjennom forskjellige kabelsjakter og kanaler inne i bygningen
  • geografisk fordeling over territoriet på nivå med 2 eller flere bygninger, en by, region eller land (de såkalte volumetriske ringene)

  I dette tilfellet, når du bygger backup-kommunikasjonskoblinger, er det nødvendig å følge en rekke anbefalinger for utstyret:

  • Ved duplisering av grensesnittkortene til en modulær svitsj, eller i nærvær av en stabel, er det nødvendig å fordele koblinger mellom enhetene - grensesnittkort i tilfelle modulære svitsjer og svitsjer i tilfelle en stabel.
  • Det anbefales å bruke protokoller for lenkeaggregering (LACP, MLT, PAgP, osv.) for å kombinere lenker i grupper og balansere belastningen mellom dem.
  • bruk rutere som støtter ECMP-protokoller (Equal-Cost-Multi-Path) – når flere pakker leveres langs én rute, og disse pakkene ikke går gjennom én beste bane (og grensesnitt), men fordeles over flere beste baner (og flere grensesnitt), som bestemmes av likheten i metrikkene til rutingsprotokollen, som igjen er ansvarlig for å fylle den endelige rutingstabellen.

  Og nå, som lovet, skal jeg beskrive et reelt tilfelle fra min praksis og prinsippet om lagring når man reserverer kritiske noder, noe som skjedde for flere år siden:

  • Ett selskap, jeg kaller det X, hadde en standard 3-lags nettverksmodell:
    • med flere kjerner
    • flere dusin aggregeringer
    • flere tusen tilgangsbrytere
    • av flere titusenvis av brukere

  • Nettverket ble bygget ganske komplekst:
    • med en rekke dynamiske rutingsprotokoller og protokoller - OSPF, MP-BGP, MPLS, PIM, IGMP, IPv6, etc.
    • en rekke tjenester - internettilgang, L2 og L3 VPN, VoIP, IPTV, dedikerte linjer, osv.

  • men det var én flaskehals i nettverket – grenseruteren, som kombinerte funksjonene til en BGP-grenseruter og avsluttet noen brukertjenester.
  • Ja, det kostet like mye som en flyvinge (flere millioner rubler)
  • Ja, på den tiden var det en av de beste enhetene i rekken til den mest kjente nettverksleverandøren.
  • Ja, den måtte være veldig pålitelig – med en utmerket MTBF-vurdering
  • Ja, den hadde 4 strømforsyninger, montert i henhold til 2x2-skjemaet og koblet fra forskjellige UEPS og innganger.

  Men alt dette endret ikke det faktum at han var et enkelt feilpunkt i nettverket.

  Og en dag, langt fra fantastisk for meg og mine kolleger, ga denne ruteren opp ånden (senere fant vi ut at det var en slags feil på strømforsyningsledningen gjennom UEPS, noe som førte til samtidig feil på 2 strømforsyninger, og samtidig brant en av forsyningene ut RP-modulen til ruteren og grensesnittkortet, som var koblet til enhetens felles databussen).

  Vi hadde ingen reservekort – RP og grensesnittkort, men vi hadde en kontrakt for å erstatte utstyr eller dets komponenter med en av partnerne under NBD-ordningen.

  Dessverre hadde partnerne på den tiden bare grensesnittkortet på lager, men ikke noe RP-kort, det kom bare noen få dager senere (3 dager senere).

  Som et resultat resulterte tilstedeværelsen av et enkelt feilpunkt i nettverket (selv med en supportkontrakt og utskifting av utstyr) i følgende økonomiske kostnader:

  • Andelen av selskapets tjenester, relatert til eller knyttet til denne grensen, var omtrent 60–70 %
  • Som det senere ble beregnet, var den daglige fortjenesten omtrent 900 tusen rubler (omtrent) på den tiden
  • dermed, i løpet av 3 dager med nedetid, gikk teoretisk sett en fortjeneste på mellom 1 million 620 tusen rubler og 1 million 890 tusen rubler tapt

  Nettotapene var selvfølgelig mindre, siden kompensasjonen for de fleste brukerne ikke ble returnert i form av penger, men i form av tjenester, men de eksisterte fortsatt:

  • del av kompensasjonen for bedriftsbrukere
  • økte kostnader for bedriftens ansatte som jobbet alle 3-4 dager for fullt – overtid, nattskift, økte skift osv.
  • omdømmetap, noe som heller ikke er ubetydelig
  • og aller viktigst – nervene til både ledelse og ansatte, så vel som kunder

  Som et resultat ble selskapets policy revidert:

  • nektet erstatningskontrakten under NBD-vilkåret
  • forlot den vanlige servicekontrakten
  • kjøpte en duplikatruter verdt omtrent 1–1.3 millioner rubler for å sikkerhetskopiere 90 % av funksjonaliteten til hovedruteren

  Deretter gjorde innkjøp av tilleggsutstyr og sikkerhetskopiering av hovedutstyret det mulig for oss å balansere belastningen på eksterne lenker, trafikk og brukere mellom dem, og ga en sikkerhetsmargin for selskapet i fremtidige ulykker.

  Eksempel på design av bedriftsnettverk

  I denne delen av artikkelen vil jeg forsøke å skissere hovedpunktene i beregningen av bedriftens stamnettverk. Jeg vil ikke overbelaste deg med hele PPDIOO-metodikken (Prepare-Planning-Design-Implement-Operate-Optimize), men bare skissere hovedpunktene:

  • Forberedelse/Forberedelse – du må bestemme deg sammen med ledelsen om målene for nettverksmodernisering som du ønsker å oppnå – øke feiltoleransen, implementere nye tjenester eller teknologier. Jeg vil hoppe over å definere begrensningene – tekniske og organisatoriske – her, siden jeg antar at du er ansatt i organisasjonen og har mye tid til å overvinne dem. Jeg kommer tilbake til temaet budsjett nedenfor.
  • Planlegging/PLANYA — her må du lage en fullstendig beskrivelse av ditt nåværende nettverk (hvis du ikke kjenner det ennå), dvs. beskrive nettverket slik det er nå:
    • mengde og type utstyr
    • antall og typer porter
    • eksisterende kabelruter og koblingssystemer i og mellom bygninger
    • strømforsyningsordninger
    • L2- og L3-adressering
    • lag Wi-Fi-nettverkskart med tilgangspunkter og kontrollere
    • beskriv serverfarmen din
    • Det er lurt å beskrive alle tjenestene dine og forbindelsene mellom dem
    • Hvis du allerede har implementert en nettverkssikkerhetspolicy og en policy for nettverkstilgangskontroll i en eller annen form, må du ta hensyn til det når du utformer
    • Jeg vil umiddelbart bemerke at det andre trinnet i hovedsak er en fullstendig oversikt over nettverket, fra kabelinfrastrukturen og strømforsyningsskjemaene, og til slutt tjenester (applikasjoner og deres porter). Dette trinnet er veldig, veldig arbeidskrevende og noen ganger til og med kjedelig. Hvis du eller din forgjenger ikke førte dokumentasjon eller et elementært overvåkingssystem, er det på tide å tenke over det. Nettverket har en tendens til å endre seg over tid i et eller annet tempo, og bare det å opprettholde oppdatert dokumentasjon eller et overvåkingssystem kan hjelpe deg med å spore tilstanden og legge til rette for administrasjonen. Men dette gjelder allerede for driftstrinnet.

  • Design/Designing – bevæpnet med full kunnskap om nettverket ditt, tilegnet i forrige trinn, setter du deg endelig ned og tenker på hvordan du skal oppgradere nettverket ditt. Nedenfor vil jeg prøve å demonstrere et lite eksempel på nettverksberegning.

  For meg selv har jeg satt sammen en liten liste med innledende data som jeg skal bruke når jeg beregner og utformer støttenettverket.

  La oss forestille oss forberedelsestrinnet som en liste over hva vi har tilgjengelig og hva vi planlegger å gjøre:

  • Det er en ganske stor bedrift med et omtrentlig antall arbeidsplasser, rundt 700–800 ansatte (her mener jeg de ansatte som trenger tilgang til bedriftsnettverket)
  • Det er flere separate bygninger innenfor bedriftens territorium:
  • Hovedbygninger:
    • antall bygninger - 2 stk.
    • Antall etasjer i bygningen - 7
    • antall telekommunikasjonsskap per etasje i én bygning - 3 (totalt 21) stk.
    • antall ansatte i bygningen = ~ 250 personer

  • Ekstra boliger:
    • antall bygninger - 10 stk.
    • antall etasjer i bygningen/verkstedet - 2 stk.
    • Antall telekommunikasjonsskap i bygningen - 3 stk.
    • antall ansatte i bygningen = ~ 20 personer

  • Det nåværende nivået på nettverkskjernen (forresten, et veldig vanlig opplegg som jeg har møtt mer enn én gang i en eller annen form og i portenes sammensetning) presenteres:
    • 2 L2-brytere:
      • 1 Gb RJ-45-porter – 24 stk.
      • 1 Gb SFP-porter - 4 stk.
    • 1. L2-bryter:
      • 1 Gb SFP-porter - 24 stk.
    • kjernetopologi - ring
    • Peer-to-peer-koblinger mellom svitsjer aktiveres ved hjelp av optiske fibre
    • Svitsjene er plassert i små serverrom med skap
  • Nåværende distribusjonsnivå:
    • kombinert med nettverkets kjernenivå når det gjelder aggregering av lenker fra tilgangssvitsjer
    • L3-adressering flyttes til grenseruteren og/eller brannmuren
  • Nåværende tilgangsnivå:
    • L2-svitsjer med 16 x 100 Mb RJ-45-tilgangsporter og 2 Gigabit uplink-kombinerte RJ-45/SFP-porter
    • Bryterne er plassert i skapene i etasjene
    • tilgangsbrytertopologi:
      • stjerne (hub-and-spoke) med en kjerne-/distribusjonsbryter i midten
      • bjelke/eike er en gren av brytere i etasjer - 3 stk i en kjede
    • det finnes uadministrerte tilgangsbrytere
    • Brytere i 9 ytterligere tilfeller er koblet til via medieomformere (optiske signal-til-elektriske signalomformere)
  • Nåværende kabelinfrastruktur:
    • Kabelsystem mellom bygninger:
      • Det er en optisk kabel mellom de to hovedbygningene med en kapasitet på 2 fibre
      • Det er én optisk kabel mellom en av tilleggsbygningene (der kjernebryteren er installert) og hver av hovedbygningene med en kapasitet på 1 fibre hver.
      • Det er 1 optisk kabel mellom tilleggsskap og skap med installerte kjernebrytere med en kapasitet på 4 fibre (fordelingen deres vises på bildet nedenfor)
      • fibertypen i alle kabler er single mode/SMF
      • 2-fiber single-mode SFP-transceivere brukes
      • Noen kabler termineres ved optiske fordelingsrammer (ODF) i separate rom (tverrrom/serverrom), og noen kabler termineres ved kontrollrom i gulvnivå

    • Kabelsystem inne i bygninger:
      • Det er en blandet kabelstruktur mellom serverrommene og de første skapene i etasjene:
      • kobberkabler Cat5e - 10 stk (eller 100 par kabler)
      • fiberoptisk multimodus/MMF-kabel for 4 eller 8 fibre - 1 stk.
      • 4-fiber multimodus/MMF fiberoptisk kabel mellom gulvskap
      • Cat5e kobberkabler mellom gulvskap og stikkontakter
    • Nåværende datasenter:
      • det er flere serveringssteder, for eksempel 6 stk.
      • inkluderte 1 Gb-porter i kjernesvitsjen i den første hovedbygningen
      • Alle bedriftsapplikasjoner flyttes til servere
    • L2, L3 adressering og ruting:
      • Det er flere VLAN-er i nettverket – 2,3 per bygning
      • servere er allokert til et separat /24-nettverk
      • For interne behov brukes grå klasse B-nettverk, som er inkludert i området - 172.16.0.0/16
      • L3-adresser avsluttes ved grenseruteren og/eller brannmuren
      • statisk ruting brukes
    • tilleggsinformasjon:
      • telefoni:
        • Tradisjonell telefoni med gammeldags digital PBX (ikke IP-PBX) har blitt tatt i bruk i bygninger og noen enheter.
        • Det er nødvendig å tilby telefoner til nye bygninger, uten kostnadene ved å legge dyre kobberkabellinjer med en viss kapasitet og bygge et duplikat SCS for telefoni inne i bygninger
        • Over tid er det planlagt å implementere IP-telefoni i hele bedriften, kombinere det med CRM-systemer og overføre alle ansatte til det.
      • Havnekapasitet:
        • Det er nødvendig å analysere den nåværende kapasiteten til trunkporter og aksessporter, og reservere minst 25–30 % til fremtidige behov.
        • analysere tilstrekkeligheten av den nåværende gjennomstrømningen til tilgangsporter og trunk-lenker
        • sørge for PoE/PoE+ tilgangsporter for enheter fra tilstøtende systemer – videoovervåking og telefoni
      • videoovervåking:
        • Det er planlagt å bruke bedriftsnettverket som transportmiddel for videoovervåkingsnettverket.
        • Det er nødvendig å tilby PoE-porter for CCTV-kameraer
      • trådløse systemer:
        • I fremtiden er det planlagt å implementere en trådløs infrastruktur for ansattes mobilitet
        • Det er nødvendig å tilby PoE-porter for tilgangspunkter
      • budsjett, tidsfrister og utstyrskrav:
        • Få mest mulig ut av ditt eksisterende utstyr
        • Når du designer et nettverk, ta hensyn til muligheten for å utvide nettverkskapasiteten i N år fremover.
        • Når du designer et nettverk, bør du ta hensyn til støtte for alle mulige sikkerhetsfunksjoner – her er en liste over funksjonalitet, fra portsikkerhet til autentisering og autorisasjon av brukere via 802.1x.
        • i størst mulig grad reservere kritiske nettverksnoder av primær betydning – kjernen og datasenteret, og legge til rette for muligheten til å reservere noder av sekundær betydning – distribusjonsnoder
        • Prosjektbudsjettet bør gi rom for sekvensiell finansiering i flere trinn
        • budsjettbeløp - her bestemmer hver bedrift for seg selv, styrt av sine økonomiske indikatorer
        • vilkår - i det mest ideelle tilfellet vil det ikke være noen eksplisitte vilkår, siden dette er et internt prosjekt i selskapet, som implementeres av de ansatte, eller de vil være relativt komfortable - for eksempel 1 år (eller mer). I verste fall - kan det være fra 3 måneder til seks måneder.
      • feilsøke nåværende nettverksproblemer:
        • pakketap
        • DHCP-problemer på mer eller mindre intelligente tilgangsbrytere relatert til bruk av STP-protokollfamilien for å bekjempe løkker på tilgangsporter.
        • bli kvitt tilstedeværelsen av et DHCP-servergrensesnitt i hvert ansattes VLAN
        • fremveksten av koblingssløyfer knyttet til uautorisert aktivering av administrerte/ikke-administrerte svitsjer på kontorer og tilkobling av alle slags enheter til dem
        • listen fortsetter og fortsetter ...

      Planleggingstrinnet – å karakterisere tilstanden til ditt nåværende nettverk, som jeg allerede skrev, avhenger av tilgjengeligheten av et kvalitetsovervåkingssystem og graden av dokumentasjon av det. På dette trinnet må du:

      • i det minste skissere det eksisterende nettverket for videre analyse
      • samle inn data fra utstyr:
        • trafikk på hovedporter
        • feil på porter
        • CPU-belastning og minneforbruk på svitsjer og rutere
        • beskriv L2-L3-skjemaer etter VLAN-er og IP-adresser
      • hev kabelrutediagrammer:
        • fiberoptiske diagrammer og koblingsskjemaer for optiske krysskoblinger
        • Kobberkabelfordelingssystemer mellom serverrom og etasjer
        • Kobberkabelfordelingssystemer mellom etasjer og kontorer
        • sjekk tilstedeværelsen av optiske kryss og patchpaneler i serverrom og skap
      • sjekk strømforsyningskretsene i server- og gulvskapene
      • sjekk tilstedeværelsen av UPS og batterier på kritiske noder
      • analyser alle data

      Basert på dataene fra forberedelsesfasen kom jeg opp med et grovt logisk diagram:

      
      
      Deretter, etter den modulære tilnærmingen, er det nødvendig å identifisere nivåene og modulene i virksomheten:

      
      
      Jeg vil ikke berøre Edge i denne artikkelen, men vil kort gjengi de grunnleggende tesene for hver av Campus-modulene:

      • Tilgang – på dette nivået må det sikres:
        • det nødvendige antallet porter for at brukere skal få tilgang til nettverket
        • implementering av sikkerhetspolicyer - filtrering av trafikk og protokoller
        • Kompresjon av kringkastingsdomener og nettverkssegmentering ved hjelp av VLAN-er
        • Implementering av separate VLAN-er for taletrafikk
        • QoS-støtte
        • støtte for PoE-tilgangsporter
        • Støtte for IP-multicast
        • feiltoleranse for opplinker i forbindelse med distribusjonslaget (ønskelig)
      • Distribusjon – på dette nivået bør følgende sikres:
        • det nødvendige antallet porter for tilkobling av tilgangsbrytere
        • aggregering og redundans av tilgangssvitsjekoblinger
        • IP-ruting
        • pakkefiltrering
        • QoS-støtte
        • feiltoleranse på lenke-, maskinvare- og strømforsyningsnivå (svært ønskelig)
      • Kjernen må sørge for:
        • høyhastighetssvitsjing og pakkeruting
        • det nødvendige antallet porter for tilkobling av distribusjonsbrytere
        • støtte for IP-ruting og dynamiske rutingsprotokoller med rask nettverkskonvergens
        • QoS-støtte
        • sikkerhetsfunksjonalitet for å beskytte tilgang til utstyr og kontrollplan
        • Feiltoleranse for maskinvare og strømforsyning (obligatorisk)
      • Datasenter – nettverkslaget i denne modulen må tilby:
        • høyhastighetskommunikasjonslenker
        • det nødvendige antallet porter for å koble til servere
        • redundans av kommunikasjonskoblinger både mellom servere og datasentersvitsjer, og mellom datasentersvitsjer og nettverkskjernen (påkrevd)
        • utstyr og strømforsyningsbackup (påkrevd)
        • QoS-støtte

      Deretter må vi telle portene og kommunikasjonskoblingene våre og bestemme kravene.
      Tilgangsnivå - Portberegningstabell

      Så har vi mottatt data om fordelingen av tilgangsporter per bygning. Nå må vi analysere kravene til tilgangsnivå og kommentarer, og skissere løsningsalternativene.
      Tilgangsnivå – Krav og løsningsalternativer

      Deretter skal vi beregne portene og kommunikasjonslenkene for følgende nivåer:

      Distribusjonsnivå

      Kjernenivå

      Datasenternivå

      Ved beregningen fikk vi følgende:

      • tilgangsnivå — 24- og 48-porters tilgangssvitsjer er nødvendige, helst med 1 Gb tilgangsporter og med SFP optiske uplink-porter med PoE-støtte og bred funksjonalitet:
        • Totalt vil de tilby 504 tilgangsporter, som i prinsippet vil dekke behovet for ekstra porter dersom det besluttes å bruke 2 porter per arbeidsstasjon – en IP-telefon og en dataport.
        • Det er mulig å bruke én 48-porters svitsj med PoE-funksjonalitet i hver etasje, som gir tilgangsporter for følgende krav:
          • reserve - omtrent 102 reserveporter (22 %) på hovedbygningene. For tilleggsbygninger litt mer - 25 %.
          • videoovervåking
          • trådløst nettverk
      • distribusjonsnivå — svitsjer med et sett med SFP-porter fra 12 til 48 porter med minst 2 SFP+-porter, med mulighet for stabling og utvidet funksjonalitet, samt tilstedeværelse av backup-strømforsyninger er nødvendig.
      • kjernenivå — Høyhastighetssvitsjer med 12 til 24 SFP/SFP+-porter med støtte for både stabling og klynging med MC-LAG-støtte er nødvendig. Jeg bør nevne at det også er mulig å bruke rutingsverktøy for trafikkbalansering. De nyeste generasjonene av L3-svitsjer og rutere støtter ECMP med trafikkbalansering over 4 eller flere ruter med samme metrikk.
      • datasenternivå — svitsjer med 8 til 24 SFP/SFP+-porter med støtte for både stabling og klynging med MC-LAG-støtte er nødvendig.

      Målnettverksplanen ble endelig oppnådd slik

      Valg av ekstreme brytere for prosjektimplementering

      Vel, her kommer vi til hovedsaken – tidspunktet for å velge brytere for implementeringen av prosjektet vårt. Følgende ekstreme brytere er egnet for det resulterende målskjemaet:

      Nivå
      modell
      porter
      beskrivelse

      kjerne
      x620-16x-Base*

      x670-G2-48x-4q-Base*
      16 x 10GE SFP+
       
       
       
      48x10GE SFP+ og 4x40GE QSFP+
      For kjernens behov:

      • høyhastighetskoblinger
      • Avansert ruting- og sikkerhetsfunksjonalitet
      • strømforsyningsbackup med ekstra strømforsyninger
      • støtte for stabling og klynging

      Svitsjen i x620-serien vil gjøre jobben for minimumskrav.
      For utvidede krav til antall porter og bredere funksjonalitet, er det verdt å vurdere svitsjene i x670-G2-serien.

      Datasenter

      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+

      For datasenterets grunnleggende behov:

      • høyhastighetskoblinger
      • strømforsyningsbackup med ekstra strømforsyninger
      • støtte for stabling og klynging

      Svitsjen i x620-serien vil gjøre jobben for minimumskrav.
      Ved utvidede krav til antall porter og bredere funksjonalitet, er det verdt å vurdere svitsjene 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+

      For grunnleggende distribusjonsbehov:

      • nødvendig antall optiske porter
      • strømforsyningsbackup med ekstra strømforsyninger
      • støtte for stabling og klynging
      • nødvendig L3-funksjonalitet

      Svitsjene i x460-G2-serien er ideelle. Tilstedeværelsen av redundante strømforsyninger med muligheten til å utvide og legge til 10G-, CX- (for stabling)- og QSFP+-porter gjør dem til ideelle svitsjer for distribusjonslaget med porter opptil 1 Gb.

      adgang

      X440-G2-24p-10GE4*

      X440-G2-24t-10GE4*

      X440-G2-48t-10GE4*

      X440-G2-48p-10GE4*

      24x1000BASE-T (4 x SFP-kombinasjon), 4x10GE SFP+ (PoE-budsjett 380 W)
       
      24x1000BASE-T (4 x SFP-kombinasjon), 4x10GE SFP+
       
       
      24x1000BASE-T (4 x SFP-kombinasjon), 4x10GE SFP+-kombinasjonsporter
       
      48 x 1000BASE-T (4 x SFP-kombinasjon), 4 x 10GE SFP+-kombinasjonsporter (PoE-budsjett 740 W)

      For tilgangsbehov:

      • nødvendig antall tilgangsporter
      • PoE/PoE+-støtte
      • funksjonalitet og portutvidelsesmuligheter
      • en ekstra bonus i form av støtte for stabling av 10 Gb-porter «rett ut av esken»

      Jeg anbefaler å være oppmerksom på denne linjen med tanke på fleksibiliteten når det gjelder porter, ytelse og funksjonalitet.

      *Spesifikasjonene for de valgte bryterne finner du i den første artikkelen i serien — Anmeldelse av Extreme Switches

      Jeg kunne avsluttet artikkelen her, men jeg vil gjerne fremheve to tilleggsaspekter som enhver ingeniør vil støte på når de utvikler eller oppgraderer nettverket sitt:

      • arbeid med kabelruter - fibre og kobberledninger
      • IP-adressering

      Arbeid med fibre

      Ovenfor har jeg gitt målskjemaet som det er nødvendig å komme frem til. For implementeringen er følgende antall tilkoblinger for utstyr nødvendig:

      antall kommunikasjonslenker

      Som det fremgår av tabellen, er minimum antall fibre som kreves for å sikre feiltoleranse på nettverksnivåer (kjernemodul, datasenter og distribusjon i 2 bygninger) 10 stk.

      I nettverkskarakteriseringsfasen fant vi ut at kabelen mellom bygningene bare har 8 fibre. Hva skal man gjøre i denne situasjonen?

      Jeg vil gi noen løsninger:

      • Det første åpenbare steget er å bruke reservefibrene i kabelen mellom bygning 1 - bygning 1 og bygning 1 - bygning 2 (som det fremgår av tabellen, brukes bare 2 av de 8 fibrene i hver kabel). For å gjøre dette er det nok å installere optiske krysskoblinger mellom krysskoblingene i bygning 1, og om nødvendig bruke SFP-moduler med en reserve av optisk budsjett.
      • Det andre trinnet er å bruke CWDM-teknologi – multipleksing av bærebølgelengder innenfor en enkelt fiber. Denne teknologien er mye billigere enn DWMD og er ganske enkel å implementere. Kravene er hovedsakelig til kvaliteten på optiske fibre og SFP/SFP+-transceivere med en viss lengde og budsjett. Som jeg sa i forrige artikkel – svitsjers evne til å gjenkjenne tredjeparts transceivere kan forenkle livene våre betraktelig og redusere kapitalkostnadene for bygging av ekstra optiske kabler.
      • Det tredje trinnet er å vurdere muligheten for å øke antallet fibre ved å legge flere optiske kabler.

      Deretter ser vi på antall fibre mellom bygninger med installerte fordelingsbrytere og tilleggsbygninger 2–10. Heller ikke her er alt så klart:

      • for det første er det ikke nok fibre til å implementere målskjemaet vårt - 2 fibre for hver bryter (som vi husker, har vi kabler med 4 OB for hvert tilfelle)
      • For det andre, selv om det er et tilstrekkelig antall fibre mellom bygninger, brukes MMF-fibre inne i bygningene, noe som ikke lar oss bare koble sammen SMF- og MMF-fibre (jeg snakker om avstander mellom bygninger over 300–400 meter).

      I slike tilfeller kan følgende alternativer vurderes:

      • Forsyner hver SMF-bryter med fibre:
        • Hvis avstanden tillater det, kan du forlenge ekstra lange patchkabler mellom svitsjene. En gang brukte vi patchkabler som var 30–50 m lange.
        • legge relativt billig optisk SMF-kabel med lav kapasitet mellom skapene
        • som en siste utvei, bruk forskjellige SMF-MMF-omformere
      • For å minimere mengden fiber som brukes mellom bygninger, kan du:
        • bruk stablingsfunksjonaliteten til x440-G2-tilgangssvitsjer – samtidig som du bruker 1 SMF-fiber til hver svitsj på gulvet, noe som tillater bruk av 6 fibre og porter på hver side i stedet for 3 fibre og porter
        • Bruk to fibre til å koble sammen den første svitsjen i grenen og den siste. Samle lenker på kanttilgangssvitsjene og bruk STP-protokoller i den resulterende ringen.

      IP-adressering

      Her vil jeg gi en omtrentlig beregning av adressering for ordningen vår.

      For øyeblikket har vi flere klasse B-nettverk - 172.16.0.0/16. Når jeg beregner IP-adresseområdet, vil jeg la meg veilede av følgende hensyn:

      • De fire bitene i den andre oktetten vil representere bygningene - 4/172.16.0.0.
      • Oktett 3 vil angi etasjenummeret i bygningen.
      • 3 oktetter = 255 vil bli tildelt for punkt-til-punkt-koblinger mellom utstyr og kontrollnettverk.
      • ett administrasjons-VLAN per etasje for administrasjon av svitsjer.
      • ett bruker-VLAN per svitsj (24 porter i gjennomsnitt).
      • ett Voice VLAN per svitsj (24 porter i gjennomsnitt).
      • ett VLAN for videoovervåkingssystem per etasje.
      • ett VLAN for Wi-Fi-enheter per etasje.

      Jeg fikk tabeller som så omtrent slik ut:
      nettverk 172.16.0.0/14
      nettverk 172.20.0.0/14

      I tabellen ovenfor har jeg gitt en omtrentlig fordeling av nettverk etter bygninger og etasjer på den ene siden, og nettverk (bruker, administrasjon og tjeneste) på den andre.

      Faktisk er det ikke mest optimalt å velge det grå nettverket 172.16.0.0/12, siden det begrenser oss i antall nettverk (fra 16 til 31) for bygninger, og det finnes også eksterne kontorer som også må kutte nettverksblokker. Kanskje et mer optimalt alternativ ville være å bruke 10.0.0.0/8-nettverk, eller felles bruk av 172.16.0.0/12-nettverk (for eksempel for tjenestebehov og servere) og 10.0.0.0/8 (for brukernettverk).

      Generelt sett er tilnærmingen til tildeling av IP-nettverk også modulær, og det er ønskelig å følge reglene for å oppsummere delnett til ett sammendragsnettverk på distribusjonsnivåer, så vel som rutere på kanten i eksterne grener. Dette gjøres av flere grunner:

      • for å minimere rutingstabeller på rutere
      • for å minimere tjenestetrafikk for rutingsprotokoller (alle typer oppdateringsmeldinger når nestede delnett ikke er tilgjengelige)
      • for å forenkle administrasjonen og forbedre lesbarheten til L3-nettverk

      Selv om det er verdt å merke seg angående de to første punktene at kapasiteten til moderne rutere er mye høyere enn for 2–15 år siden, og lar dem inneholde store rutingstabeller i RAM-en, har forholdet mellom pris og båndbredde for kommunikasjonskanaler sunket sammenlignet med prisene på den tiden med utbredt bruk av E20/T1-strømmer (G.1).

      Konklusjon

      Venner, i denne artikkelen prøvde jeg å fortelle så kort som mulig om de grunnleggende prinsippene for utforming av campusnettverk. Ja, det var ganske mye materiale, og dette til tross for at jeg ikke berørte emner som:

      • organisering av bedriftsgrensen (og dette er en egen historie med egne svitsjer, grenser, brannmur, IPS/IDS-systemer, DMZ, VPN og andre ting)
      • Organisering av Wi-Fi-nettverk
      • Organisering av VoIP-nettverk
      • datasenterorganisasjon
      • sikkerhet (og dette er også en egen verden, som når det gjelder volum og krav ikke er dårligere enn utformingen av en ren nettverksinfrastruktur, og noen ganger til og med overgår den)
      • kraftteknikk
      • listen fortsetter og fortsetter

      Faktisk er det å designe og bygge et bedriftsnettverk en ganske møysommelig oppgave som krever mye tid og ressurser.

      Men jeg håper artikkelen min vil hjelpe deg med å evaluere og forstå på et grunnleggende nivå hvordan du skal gripe an denne oppgaven.

      Dette er langt fra den siste artikkelen om Ekstreme nettverk, så følg med (Telegram, Facebook , VK, TS Løsningsblogg)!

Kilde: www.habr.com