Kringkast trafikk av NetWare-nettverk. Dataoverføringstyper

Legg igjen en kommentar 6,950

Båndbredden til enhver lokal nettverkskobling er begrenset av den maksimale effektive båndbredden til koblingsprotokollen som brukes. Hvis en del av dette båndbredde brukes ikke for å overføre brukerdata, men for å overføre tjenestetrafikk, så reduseres den effektive nettverksgjennomstrømningen ytterligere. Vanligvis blir en del av den tilgjengelige nettverksbåndbredden tatt bort fra brukerdata av kringkastet overhead-trafikk, som er en integrert del av nesten alle protokollstabler som kjører i lokale nettverk.

Kringkasting av rammer og pakker brukes av protokoller slik at ressurser kan bli funnet på nettverket ikke ved å huske deres numeriske adresser, men ved å bruke mer brukervennlige symbolske navn. En til på en praktisk måteå søke etter ressurser på nettverket er å skanne dem automatisk og gi brukeren en liste over oppdagede ressurser med symbolske navn. Brukeren kan se en liste over gjeldende nettverksressurser - filservere, databaseservere eller delte skrivere - og velge hvilken som helst av dem å bruke.

Begge metodene ovenfor for en bruker å jobbe med ressurser er vanligvis basert på en eller annen type kringkastingstrafikk, når en node som surfer på nettverket sender forespørsler med en kringkastingsadresse, og spør om tilstedeværelsen av visse servere på nettverket. Etter å ha mottatt en slik forespørsel, svarer serveren på den forespørrende noden med en rettet pakke der den rapporterer sin eksakte adresse og beskriver tjenestene levert av serveren.

Støtte for kringkastingstrafikk på koblingsnivå

Nesten alle protokoller som brukes i lokale nettverk støtter kringkastingsadresser (unntatt ATM-protokoller). En adresse som består av alle (111...1111) har samme betydning for Ethernet, TokenRing, FDDI, FastEthernet, 100VG-AnyLAN-protokollene: en ramme med en slik adresse må aksepteres av alle nettverksnoder. Med tanke på spesiell type og den vanlige karakteren til kringkastingsadressen, sannsynligheten for generering som et resultat av feil bruk av utstyret ( nettverksadapter, repeater, bro, switch eller ruter) viser seg å være ganske høy. Noen ganger genereres feilsendingstrafikk som følge av feil drift programvare, som implementerer funksjonene til protokoller på øvre nivå.

Broadcast-trafikk til lenkelaget distribueres ikke bare innenfor segmentet som dannes av passiven kabelsystem eller flere repeatere/huber, men også innenfor et nettverk bygget ved hjelp av broer og switcher. Driftsprinsippene til disse enhetene krever at de sender en ramme med en kringkastingsadresse til alle porter bortsett fra den som denne rammen kom fra. Denne måten å behandle kringkastingstrafikk på skaper effekten for alle noder koblet til hverandre ved hjelp av repeatere, broer og brytere delt nettverk, der alle klienter og servere "ser" hverandre.

Send Storm

Vanligvis er protokoller utformet slik at nivået av kringkastingstrafikk er en liten brøkdel av den totale nettverksgjennomstrømningen. Det antas at det normale nivået av kringkastingstrafikk ikke bør overstige 8% - 10% av nettverkskapasiteten. Men når terskelen på 5 % er nådd, anses det som hensiktsmessig å analysere nodene som genererer den største andelen kringkastingstrafikk – kanskje de trenger omkonfigurering.

Hver kildeprotokoll for kringkastingspakker genererer oftest kringkastingstrafikk med konstant intensitet, ettersom den sender pakker til nettverket fast størrelse med visse intervaller. For eksempel annonserer SAP-protokollen eksistensen av en bestemt fil eller utskriftstjeneste hvert 60. sekund ved hjelp av en kringkastingsmelding med fast størrelse. Vi kan gi et eksempel på en kilde som genererer kringkastingstrafikk med variabel intensitet. En slik kilde er rutinginRIP, som sender innholdet i rutingtabellen over nettverket en gang hvert 30. eller 60. sekund, og siden denne tabellen kan ha en variabel størrelse, vil intensiteten til trafikken som genereres. RIP-protokoll, kan endre seg.

Den totale intensiteten av kringkastingstrafikk på et nettverk vil bli bestemt av to faktorer - antall kilder til slik trafikk og gjennomsnittlig intensitet for hver kilde. Lokale nettverksprotokoller ble utviklet på begynnelsen av 80-tallet basert på et relativt lite antall datamaskiner som genererer kringkastingstrafikk, samt tar hensyn til den store reservekapasiteten til lokale nettverkskanaler (10 Mb/s) sammenlignet med behovene filtjeneste minidatamaskiner og stasjonære datamaskiner den tiden. Derfor gjorde protokollstakker som ble designet eksklusivt for bruk på lokale nettverk - NovellNetWareIPX/SPX og NetBIOS/SMB-stakken fra IBM og Microsoft - utstrakt bruk av kringkastinger for å skape maksimal bekvemmelighet for brukere som ikke trengte å huske servernavn og -adresser.

TCP/IP-stakken ble designet for å fungere i alle miljøer - både på lokale nettverk og i globale nettverk med lavhastighetskanaler. Derfor er TCP/IP-stakken mye mindre vanlig kringkaste beskjeder- stort sett bare når det er absolutt nødvendig. Dette garanterer TCP/IP-stakken et akseptabelt kringkastingsnivå selv på lavhastighetskoblinger, mens på NetWare-nettverk er kringkastingsnivået globale kanaler kan nå et uønsket tall på 20 %.

Overskridelse av kringkastingstrafikken med mer enn 20 % kalles kringkastingsstorm (broadcaststorm). Dette fenomenet er ekstremt uønsket, da det fører til en økning i nettverksutnyttelsen, og følgelig til en kraftig økning i ventetiden for tilgang.

I IP-nettverk er det 3 hovedmetoder for dataoverføring: Unicast, Broadcast, Multicast.

Unicast(unicast) – prosessen med å sende en pakke fra en vert til en annen vert.

Multicast(multicast) – prosessen med å sende en pakke fra én vert til en begrenset gruppe verter.

Kringkaste(kringkasting) – prosessen med å sende en pakke fra én vert til alle verter på nettverket.

Disse 3 typene dataoverføring brukes til forskjellige formål, la oss ta en nærmere titt.

Unicast

Unicast-dataoverføringstypen brukes for normal vert-til-vert-dataoverføring. Unicast-metoden fungerer i klient-server og peer-to-peer-nettverk.

I unicast-pakker brukes den spesifikke IP-adressen til enheten som denne pakken er ment for, som destinasjons-IP-adressen. IP-adressen til en spesifikk enhet består av en del av nettverksadressen (der denne enheten er plassert) og en del av vertsadressen (delen som bestemmer denne spesifikke plasseringen i nettverket). Alt dette fører til muligheten til å rute unicast-pakker gjennom nettverket.

Multicast- og kringkastingspakker har, i motsetning til unicast-pakker, sine egne spesielle (reserverte) IP-adresser for bruk i pakkehodet som destinasjon. På grunn av dette er kringkastingspakker stort sett begrenset til det lokale nettverket. Multicast-trafikk kan også begrenses til grensene til lokalnettet, men på den annen side kan den også rutes mellom nettverk.

I IP-nettverk er en unicast-adresse en adresse, det vil si adressen til en sluttenhet (for eksempel en datamaskin). For unicast-dataoverføringstypen tildeles vertsadresser til to sluttenheter og brukes som kilde-IP-adresse og destinasjons-IP-adresse.

Under innkapslingsprosessen plasserer avsenderverten sin IP-adresse i unicast-pakkehodet som kildeadresse, og mottakervertens IP-adresse plasseres i overskriften som destinasjonsadresse. Ved å bruke disse to IP-adressene kan unicast-pakker overføres over hele nettverket (dvs. på tvers av alle undernett).

Multicast

Multicast-overføringstypen ble utviklet for å spare båndbredde i IP-nettverk. Denne typen reduserer trafikken ved å la verter sende en enkelt pakke til en valgt gruppe verter. For å nå flere destinasjonsverter ved bruk av unicast-dataoverføring, må kildeverten sende den samme pakken til hver destinasjonsvert. Med multicast-dataoverføringstypen kan kildeverten sende bare én pakke, som kan nå tusenvis av destinasjonsverter.

Eksempler på multicast-dataoverføring:

video- og lydutsendelser
utveksling av ruteinformasjon brukt i rutede protokoller.
programvaredistribusjon
nyhetsfeeds

Multicast-klienter

Verter som ønsker å motta spesifikke multicast-data kalles multicast-klienter. Multicast-klienter bruker initierte tjenester klientprogrammer for å sende multicast-data til grupper.

Hver multicast-gruppe representerer én multicast-destinasjons-IP-adresse. Når en vert kringkaster data for en multicast-gruppe, legger verten multicast-IP-adressen i pakkeoverskriften (i destinasjonsdelen).

Dedikert for multicast-grupper spesiell blokk IP-adresser, fra 224.0.0.0 til 239.255.255.255.

Kringkaste

Fordi kringkastingsoverføringstypen brukes til å sende pakker til alle verter på nettverket, bruker pakkene en spesiell kringkastings-IP-adresse. Når en vert mottar en pakke med en kringkastingsadresse i overskriften, behandler den pakken som om den var en unicast-pakke.

Når en vert trenger å overføre noe informasjon til alle verter på nettverket, brukes kringkastingsdataoverføringsmetoden. Selv når adressen spesielle tjenester(tjenester) eller enheter er ukjent på forhånd, da brukes også kringkasting for deteksjon.

Eksempler når kringkastet dataoverføring brukes:

lage et adressetilknytningskart toppnivå til de nederste (for eksempel hvilken IP-adresse som er på spesifikk enhet med hans MAC-adresse)
adresseforespørsel (ARP-protokollen kan tas som eksempel)
rutingprotokoller utveksler ruteinformasjon (RIP, EIGRP, OSPF)

Når en vert trenger informasjon, sender den en forespørsel til kringkastingsadressen. Alle andre verter på nettverket vil motta og behandle denne forespørselen. En eller flere verter vil vedlegge den forespurte informasjonen og svare på forespørselen. De som svarer på forespørselen vil bruke unicast som dataoverføringstype.

På samme måte, når en vert trenger å sende informasjon til alle verter på nettverket, oppretter den en kringkastingspakke med informasjonen og overfører den til nettverket.

I motsetning til unicast-overføring, hvor pakker kan rutes over hele nettverket, er kringkastingspakker vanligvis begrenset til det lokale nettverket. Denne grensen avhenger av ruterkonfigurasjonen, som begrenser nettverket og overvåker typen kringkasting (kringkasting).

Det finnes to typer kringkastingsdataoverføring: rettet kringkasting og begrenset kringkasting.

Retningsrettet sending

En rettet sending sendes til alle verter på et spesifikt nettverk. Denne typen kringkasting er nyttig for å sende kringkastingstrafikk til alle verter utanfor det lokale nettverket.

For eksempel, en vert ønsker å sende en pakke til alle verter på 172.16.5.0/24-nettverket, men selve verten er på et annet nettverk. I i dette tilfellet avsenderverten vil inkludere kringkastingsadressen 172.16.5.255 i pakkeoverskriften somn. Selv om rutere må begrense (ikke overføre) dirigert kringkastingstrafikk, kan de konfigureres til å tillate kringkastingstrafikk.

Begrenset sending

Begrenset kringkasting brukes til å overføre data til alle verter på det lokale nettverket. I slike pakker er IP-adressen 255.255.255.255 satt inn som destinasjon. Rutere overfører ikke slik kringkastingstrafikk. Pakker som sendes av en begrenset kringkasting vil kun bli distribuert på det lokale nettverket. Av denne grunn kalles IP-LAN også kringkastingsdomener. Rutere danner grensen for kringkastingsdomenet. Uten en grense vil pakker bli distribuert over hele nettverket, til hver vert, noe som reduserer ytelsen nettverksenheter og tette båndbredden til kommunikasjonskanaler.

La meg gi deg et eksempel på en begrenset kringkasting: verten er inne i 172.16.5.0/24-nettverket og ønsker å kringkaste en pakke til alle verter på nettverket sitt. Ved å bruke IP-adressen 255.255.255.255 som destinasjon, sender den en kringkastingspakke. Denne pakken vil kun mottas og behandles av alle verter på dette lokale nettverket (172.16.5.0/24).

En forferdelig ting skjedde i organisasjonen vår - nettverket fungerte, fungerte, og plutselig, tilsynelatende uten spesiell grunn, begynte det å fungere ustabilt. Det hele så veldig merkelig ut (for første gang jeg støtt på et emneproblem) - noen datamaskiner på nettverket (det er et lite antall av dem) sluttet å motta IP-adresser (loggene sier at det ikke ble mottatt noe svar fra DHCP), noen i om morgenen, andre om ettermiddagen - brukere De ringer og bekymrer seg, men vi forstår ingenting.

Hvis dette maskinvarefeil, da, ifølge alle kanonene, burde den være plassert på et sted, eller i det minste manifestere seg mer massivt (som for eksempel med en ring i Ethernet), men her er det noen sjeldne utbrudd (ca. 5 av 300), men generelt fungerer alt. Mer detaljert analyse Geografien til syke datamaskiner viste at de er plassert på brytere 3 eller flere køer fra gatewayen (Figur 1).

Figur 1. Geografi av problemet.

Søk og identifikasjon

Hypotesen om et problem med maskinvaren ble ikke umiddelbart forlatt - de slo av nedstrømsbryterne, og så ut til å få en mer eller mindre kortsiktig forbedring, men problemet forsvant ikke helt.

Naturligvis dukket det opp en versjon om at dette er en slags virus på PC-en - det hindrer dem i å motta en IP-adresse. Hun ble avvist etter at adressen ikke ble mottatt nettverksskriver. Som det viste seg, var det forgjeves (eller rettere sagt, nesten forgjeves).

Parallelt med dette forsøkte de å analysere trafikken, men på grunn av spesialistenes uerfarenhet ble det kun analysert DHCP-trafikk.

Så de første dagene ga ingen løsning på problemet. Jeg måtte utvide snifferens synsfelt. Og i dette øyeblikket ble årsaken til problemet oppdaget - når man analyserte all kringkastingstrafikk, ble det oppdaget at mer enn 80% av forespørslene lette etter en bestemt server - i betydningen den samme.

Hvordan. senere lærte vi av Internett, heter det dette problemet kringkastet flom.
Eh... hvis jeg bare hadde visst om dette tidligere.

Det viste seg at en bestemt tjeneste kalt "PcounterPrint" veldig hysterisk prøver å finne serveren sin, som merkelig nok ikke eksisterer. Tjenesten reviderer utskrift av konsernansatte, og er kjent i verden som FollowMe Printing. Som det viste seg senere, ble serveren til denne tjenesten tatt ut av drift, naturlig nok uten varsel, av senior bedriftssystemadministratorer.
I hovedsak fungerte brukernes PC-er som roboter for et DDOS-angrep på nettverksutstyret vårt.

Det eneste som gjenstår er å kvele denne tjenesten på brukernes PC-er.

Massesletting

Heldigvis var det nødvendig å gi denne oppgaven til de som er beskrevet ovenfor systemadministratorer, men det er også interessant, og så, etter et 25-minutters søk på Internett, ble et manus født i power-shell:

Her er skriptkoden

hovedfunksjon main ( $computers = Get-Content C:\Scripts\Computers.txt $service = "PcounterPrint" foreach ($computer i $computers) ((Write-Host "computer - $computer") if (ping-host $ datamaskin) ( $srv = (gwmi win32_service -datamaskinnavn $datamaskin -filter "name="$service"") if ($srv -ne $null) ( $result = $srv.stopservice() $result = $srv.ChangeStartMode ("Deaktivert") (Write-Host "Tjenesten er deaktivert") ) else ( (Write-Host "Ingen tjeneste") ) ) else ( (Write-Host "Ingen vert") ) ) ) funksjon ping-host ( param( $computer) $status = Get-WmiObject -Class Win32_PingStatus -Filter "Address="$computer"" if($status.statuscode -eq 0) (retur 1 ) else (retur 0) )

Variabelen $computers mottar en liste over datamaskiner fra en fil, skriptet omgår sekvensielt alle PC-er fra denne listen og deaktiverer den skjebnesvangre tjenesten på dem.

Naturligvis begynte nettverket etter dette å fungere stabilt.

konklusjoner

Som de sier i en velkjent preferansevits: for dette trenger du en kandelaber på hodet ...

Generelt vil jeg ikke skrive administrative konklusjoner her, selv om det er disse som stort sett tyder på seg selv.

Fra et teknisk synspunkt er det flere tiltak for å forhindre denne katastrofen:
1. Segmenter nettverket i flere virtuelle nettverk
2. Bruk det første elementet for å redusere nettverksdybden
3. Installer smartere brytere

Selv om dette, selvfølgelig, er disse tiltakene kontroversielle: er det nødvendig, fordi du må bruke tid og penger, spesielt siden personalet nå er kjent med denne situasjonen og i fremtiden raskt vil kunne overvinne den, selv om hvem vet ...

Kringkaste

Når en vert trenger å overføre noe informasjon til alle verter på nettverket, brukes kringkastingsdataoverføringsmetoden. Selv når adressen til spesielle tjenester eller enheter er ukjent på forhånd, brukes kringkasting også for deteksjon.

Eksempler når kringkastet dataoverføring brukes:

· lage et kart over medlemskapet av adresser på øvre nivå til lavere (for eksempel hvilken IP-adresse som er på en bestemt enhet med MAC-adressen)
· adresseforespørsel (ARP-protokollen kan tas som eksempel)
· rutingprotokoller utveksler informasjon om ruter (RIP, EIGRP, OSPF)

På samme måte, når en vert trenger å sende informasjon til alle verter på nettverket, oppretter den en kringkastingspakke med informasjonen og overfører den til nettverket.

Det finnes to typer kringkastingsdataoverføring: rettet kringkasting og begrenset kringkasting.

Retningsrettet sending.

En rettet sending sendes til alle verter på et spesifikt nettverk. Denne typen kringkasting er nyttig for å sende kringkastingstrafikk til alle verter utanfor det lokale nettverket.

For eksempel, en vert ønsker å sende en pakke til alle verter på 172.16.5.0/24-nettverket, men selve verten er på et annet nettverk. I dette tilfellet vil avsenderverten inkludere adressen 172.16.5.255 i pakkeoverskriften somn. Selv om rutere må begrense (ikke overføre) dirigert kringkastingstrafikk, kan de konfigureres til å tillate overføring av kringkastingstrafikk.

Begrenset sending.

Begrenset kringkasting brukes til å overføre data til alle verter på det lokale nettverket. I slike pakker er IP-adressen 255.255.255.255 satt inn som destinasjon. Rutere overfører ikke slik kringkastingstrafikk. Pakker som sendes av en begrenset kringkasting vil kun bli distribuert på det lokale nettverket. Av denne grunn kalles IP-LAN også kringkastingsdomener. Rutere danner grensen for kringkastingsdomenet. Uten grensen ville pakker bli distribuert over hele nettverket, til hver vert, noe som reduserer ytelsen til nettverksenheter og blokkerer båndbredden til kommunikasjonskanalene.

Det er tre hovedmetoder for å overføre trafikk i IP-nettverk: Unicast, Broadcast og Multicast.

Å forstå forskjellen mellom disse metodene er svært viktig for å forstå fordelene med IP-TV og for den praktiske organiseringen av kringkasting av video over et IP-nettverk.

Hver av disse tre overføringsmetodene bruker Forskjellige typer tilordne IP-adresser i samsvar med oppgavene deres, og det er stor forskjell i graden av deres innflytelse på mengden trafikk som forbrukes.

Unicast-trafikk (en-formålspakkeoverføring) brukes primært til "personlige" tjenester. Hver abonnent kan be om personlig videoinnhold når som helst som passer for ham.

Unicast-trafikk rutes fra én kilde til én destinasjons-IP-adresse. Denne adressen tilhører kun én enkelt datamaskin eller abonnent STB på nettverket som vist i figuren nedenfor.

Antall abonnenter som kan motta unicast-trafikk samtidig er begrenset av strømningsbredden (strømhastigheten) som er tilgjengelig i ryggraden i nettverket. For anledningen Gigabit Ethernet nettverksteoretisk maksimal bredde dataflyt kan nærme seg 1 Gb/sek minus båndbredden som kreves for overføring av tjenesteinformasjon og reserver for teknologisk utstyr. La oss anta at i ryggradsdelen av nettverket, for eksempel, kan vi ikke tildele mer enn halvparten av båndbredden til tjenester som krever unicast-trafikk. Det er enkelt å beregne for tilfellet med 5 Mb/sek på TV-kanal MPEG2, at antall abonnenter som samtidig mottar unicast-trafikk ikke kan overstige 100.

Kringkast trafikk ( kringkaste pakker) bruker en spesiell IP-adresse for å sende den samme datastrømmen til alle abonnenter på et gitt IP-nettverk. For eksempel kan en slik IP-adresse ende på 255, for eksempel 192.0.2.255, eller ha 255 i alle fire feltene (255.255.255.255).

Det er viktig å vite at kringkastingstrafikk mottas av alle påslåtte datamaskiner (eller STB-er) på nettverket, uavhengig av brukerens ønsker. Av denne grunn brukes denne typen overføring hovedsakelig til tjenesteinformasjon nettverkslaget eller for overføring av annen eksklusivt smalbåndsinformasjon. Selvfølgelig brukes ikke kringkastingstrafikk til å overføre videodata. Et eksempel på kringkasting av trafikkoverføring er vist i figuren nedenfor.

Multicast-trafikk (overføring av flere pakker) brukes til å overføre strømme video, når det er nødvendig å levere videoinnhold til et ubegrenset antall abonnenter uten å overbelaste nettverket. Dette er den mest brukte typen dataoverføring i IPTV-nettverk, når et stort antall abonnenter ser det samme programmet.

Multicast-trafikk bruker en spesiell klasse av destinasjons-IP-adresser, for eksempel adresser i området 224.0.0.0 ..... 239.255.255.255. Dette kan være IP-adresser i klasse D.

I motsetning til unicast-trafikk, kan ikke multicast-adresser tildeles individuelle datamaskiner (eller STB-er). Når data sendes over en av multicast IP-adressene, kan den potensielle mottakeren av dataene bestemme seg for å akseptere det eller ikke, det vil si om abonnenten vil se denne kanalen eller ikke. Denne metoden for overføring betyr at hodet IPTV utstyr operatøren vil overføre én enkelt datastrøm til mange destinasjoner. I motsetning til tilfellet med kringkasting, har abonnenten et valg om å motta data eller ikke.

Det er viktig å vite at for å implementere multicast-overføring, må et IP-nettverk ha rutere som støtter multicast. Rutere bruker IGMP-protokollen til å spore den nåværende tilstanden til distribusjonsgrupper (nemlig gruppemedlemskapet til en bestemt endenode på nettverket).

De grunnleggende reglene for drift av IGMP-protokollen er som følger:

- sluttnoden til nettverket sender en IGMP-rapporttypepakke for å sikre at prosessen med å koble til distribusjonsgruppen startes;
- noden sender ingen tilleggspakker når koblet fra en distribusjonsgruppe;
- multicast-ruteren sender IGMP-forespørsler til nettverket med bestemte tidsintervaller. Disse spørringene lar deg bestemme Nåværende situasjon distribusjon grupper;
- noden sender en IGMP-svarpakke for hver distribusjonsgruppe så lenge det er minst én klient i denne gruppen.

trafikknettverksserverkringkasting

Belastningen på ryggraden til multicast-nettverket med trafikk avhenger kun av antall kanaler som sendes i nettverket. I Gigabit-situasjonen Ethernet-nettverk, forutsatt at vi kan allokere halvparten av hovedtrafikken til multicast-overføring, får vi omtrent 100 MPEG-2 TV-kanaler, hver med en dataflythastighet på 5 Mb/sek.

Selvfølgelig, i IPTV-nettverk alle 3 typer trafikk er tilstede samtidig: kringkasting, multicast og unicast. Operatøren må, når den planlegger den optimale mengden nettverkskapasitet, ta hensyn til ulike påvirkningsmekanismer ulike teknologier IP-adressering for trafikkvolum. For eksempel må operatøren tydelig forstå at det å tilby en video-on-demand-tjeneste et stort antall abonnenter krever svært høy båndbredde ryggradsnettverk. En løsning på dette problemet er desentralisering i nettverket av videoservere. I dette tilfellet erstattes den sentrale videoserveren med flere lokale servere, adskilt fra hverandre og nær de perifere segmentene til den hierarkiske flernivåarkitekturen til IP-nettverket.

Kringkast trafikk på NetWare-nettverk

NetWare-nettverksprotokollstabelen bruker det største antallet forskjellige typer kringkastingstrafikk:

SAP (Service Advertising Protocol). Inkluderer to typer meldinger - meldinger fra servere om tjenestene de leverer og forespørsler fra klientstasjoner om å søke etter tilsvarende tjenester på nettverket. Servermeldinger inkluderer informasjon om servernavnet, typen tjeneste (for eksempel filtjeneste eller utskriftstjeneste) og den fullstendige nettverksadressen til tjenesten, inkludert nettverksnummer, vertsnummer og socketnummer. Servermeldinger distribueres en gang hvert 60. sekund.

RIP IPX (Routing Information Protocol). Distribuerer informasjon over Internett om de konstituerende IPX-nettverkene som er kjent for en gitt ruter, samt avstanden fra denne ruteren til hvert nettverk. Informasjon distribueres hvert 60. sekund. Siden hver NetWare-server alltid er en ruter, er nivået av RIPIPX-trafikk direkte proporsjonalt med antall NetWare-servere på Internett, som også skal legges til antall installerte maskinvarerutere som bruker RIP-protokollen.

NLSP (NetWare Link State Protocol). En ny rutingprotokoll som NetWare-servere og tredjeparts IPX-rutere kan bruke i stedet for RIP. NLSP-protokollen genererer et lavere nivå av kringkastingstrafikk, siden hoveddelen av kringkastingsmeldingene er meldinger om endringer i tilstanden til tilkoblinger i nettverket og tilstanden til selve ruterne. Det er åpenbart at i pålitelig nettverk Slike meldinger genereres ganske sjelden. NLSP-protokollen produserer også periodisk trafikk, men den brukes kun til å teste forbindelser mellom naborutere og genererer pakker med svært kort lengde.

NDS (NetWare Directory Services). NetWare NDS er en sentralisert katalogtjeneste som lagrer informasjon om alle brukere og ressurser på et nettverk. Hvis det er en server på nettverket som utfører NDS-funksjoner, er det ikke nødvendig å konstant generere SAP-protokolltrafikk av andre servere på nettverket. Imidlertid bruker NDS-serveren selv SAP-protokollen slik at NetWare-klienter automatisk kan lære om dens eksistens og adresse. Derfor oppretter NDS sin egen kringkastingstrafikk på nettverket for å erstatte trafikken som genereres av individuelle servere. Det kan være flere NDS-servere på nettverket som implementerer en distribuert og redundant helpdesk-struktur, så nivået av NDS-kringkastingstrafikk kan være betydelig.

Keepalive-pakker av NCP-protokollen (et annet navn er watchdog). Med denne typen pakke kommuniserer serveren og klienten til hverandre at de kjører og har til hensikt å opprettholde en logisk forbindelse. Keepalive-pakker brukes mellom server og klient lang tid(mer enn 5 minutter) er det ingen utveksling av andre data, noe som skjer når brukeren forlater datamaskinen sin i lang tid og lar den være slått på.

Kringkast trafikk av TCP/IP-nettverk

Som allerede nevnt, brukes kringkastingstrafikk mye sjeldnere på TCP/IP-nettverk enn på NetWare-nettverk. Kringkastingstrafikk i TCP/IP-nettverk skapes av IP-adresseoppløsningsprotokollene ARP og RARP (omvendt ARP), samt rutinginfRIPIP og OSPF. ARP-protokoller og RARP brukes bare i lokale nettverk der kringkasting støttes på lenkelaget. RIPIP er fundamentalt det samme som RIPIPX, og OSPF er en link-state-protokoll som NLSP, så den produserer mye mindre kringkastingstrafikk enn RIP.

Kringkast trafikk av NetBIOS-nettverk

NetBIOS-protokollen er mye brukt i små nettverk som ikke er atskilt av rutere. Denne protokollen støttes på WindowsforWorkgroups og WindowsNT operativsystemer Microsoft, IBMs OS/2 Warp-operativsystem, og noen versjoner av Unix. NetBIOS brukes ikke bare som en kommunikasjonsprotokoll, men også som et grensesnitt til protokoller som utfører transportfunksjoner på nettverket, for eksempel, TCP-protokoller, UDP eller IPX. Denne sistnevnte rollen til NetBIOS skyldes det faktum at i operativsystemer som tradisjonelt brukte NetBIOS som kommunikasjonsprotokoll, ble mange applikasjoner og protokoller på applikasjonsnivå skrevet basert på APIen levert av NetBIOS-protokollen. Da de erstattet NetBIOS-protokollen med andre transportprotokoller, ønsket applikasjons- og OS-utviklere å la programvareproduktene være uendret, så implementeringer av NetBIOS-grensesnittet dukket opp, skilt fra funksjonene som en kommunikasjonsprotokoll, og fungerte som et slags lag som oversetter forespørsler fra en API til en annen.

Hovedkilden til kringkastingstrafikk på nettverk som bruker NetBIOS enten som et grensesnitt eller som en protokoll er tjenesteprotokollen for navneoppløsning, som tilordner datamaskinens symbolske navn til MAC-adressen. Alle datamaskiner som støtter NetBIOS sender med jevne mellomrom NameQuery og NameRequest-forespørsler og svar over nettverket, ved hjelp av dette vedlikeholdes denne korrespondansen. På store mengder datamaskiner, kan nivået av kringkastingstrafikk være ganske høyt.

Rutere tillater vanligvis ikke NetBIOS kringkastingstrafikk mellom nettverk.

For å redusere denne trafikken må du bruke en sentralisert navnetjeneste som Microsofts WINS-tjeneste.

Kringkast trafikk av broer og svitsjer som støtter SpanningTree-algoritmen

Broer og svitsjer bruker SpanningTree-algoritmen for å opprettholde redundante koblinger i nettverket og bytte til dem hvis en av primærkoblingene svikter. Driftsalgoritmen til broer og brytere tillater ikke bruk av redundante tilkoblinger i hoveddriftsmodusen (med en slik topologi av tilkoblinger kan rammer sløyfes eller dupliseres), derfor er hovedoppgaven til SpanningTree-algoritmen å finne et tre topologi som dekker den opprinnelige nettverkstopologien.

For å lage en trelignende konfigurasjon, utveksler broer og brytere som støtter SpanningTree-algoritmen konstant spesielle tjenesterammer, som er innebygd i rammer på MAC-nivå. Disse rammene sendes til alle portene på broen/svitsjen, bortsett fra den de kom på, akkurat som RIP- eller OSPF-protokollpakker av rutere. Basert på denne overheadinformasjonen, plasseres noen broporter i en standby-tilstand, og skaper derved en overspennende tretopologi.

Når denne topologien er etablert, stopper ikke SpanningTree-algoritmens kringkastingstrafikk. Broer/svitsjer fortsetter å distribuere SpanningTree-protokollrammer over hele nettverket for å overvåke helsen til tilkoblinger i nettverket. Hvis en bro/bryter slutter å motta slike rammer med jevne mellomrom, vil den igjen aktivere konstruksjonsprosedyren for overspennende tre-topologi.

Nivået på SpanningTree-protokollkringkastingstrafikken er direkte proporsjonal med antall broer og svitsjer installert i nettverket.

Rutere overfører ikke SpanningTree-algoritmetrafikk, noe som begrenser spenntre-topologien til ett nettverk.

Begrense nivået av kringkastingstrafikk i sammensatte nettverk ved å bruke forfalskningsteknikker

Hvis nivået på kringkastingstrafikken er for høyt, kan du redusere det på to måter. Den første er å bruke andre protokoller som kringkaster sjeldnere, for eksempel TCP/IP-stakken. Dette er imidlertid ikke alltid mulig, siden applikasjoner eller operativsystemer kanskje bare kan fungere med visse protokoller. I dette tilfellet kan du bruke en annen metode - spoofing-teknikken.

Denne teknikken ble utviklet av produsenter av kommunikasjonsutstyr som kobler sammen lokale nettverk over lavhastighets bredområdeforbindelser, nemlig produsenter av eksterne broer og rutere.

Forfalskningsteknikken er basert på å redusere intensiteten av overføring av tjenestemeldinger over en global kanal, mens lokale nettverk mottar disse meldingene med den nødvendige frekvensen. Rutere og eksterne broer som støtter spoofing, genererer selv tjenestepakker for det lokale nettverket som er koblet til dem med nødvendig intensitet, men på vegne av noder i det eksterne nettverket.

For eksempel kan SAP- og RIP-pakker overføres over en lavhastighetskanal bare én gang - når kommunikasjon etableres mellom sentralkontoret og filialen. Deretter genereres disse pakkene av grenens lokale nettverksruter, og simulerer meldinger som opprinnelig ville ha kommet fra ekte enheter på sentralkontoret. Når det er endringer i nettverksstrukturen, sendes en oppdatert SAP/RIP-pakke til nettverket, som igjen begynner å bli generert av ruteren med den aksepterte perioden i denne protokollen, for eksempel 60 sekunder.

Det finnes ulike implementeringer av spoofing. Det enkleste alternativet er ganske enkelt å eliminere et visst antall sykluser med overføring av tjenestepakker mellom nettverk, når for eksempel bare hver 5. eller 10. SAP-pakke som kommer fra det opprinnelige lokale nettverket blir overført til et annet nettverk.

Spoofing kan også brukes i et lokalt sammensatt nettverk for å redusere nivået av kringkastingstrafikk.

Spoofing-teknikken kan føre til ikke bare økt, men også redusert nettverksytelse. Dette kan skje når et par forfalskede rutere eller broer har ulike parametere innstillinger for denne algoritmen. Så hvis en ruter er konfigurert til å overføre hver 10. SAP-pakke, og den andre ruteren venter på ankomsten av en ny SAP-pakke hver 5. perioder med normal overføring, vil den andre ruteren med jevne mellomrom vurdere forbindelsen med serverne til den første nettverk som går tapt og kunngjøre dette i det andre nettverket, noe som vil føre til brudd på logiske forbindelser mellom klienter og servere i ulike nettverk, og derfor til et tap av produktivitet. Det samme resultatet vil resultere når den ene ruteren støtter spoofing-modus, men den andre ikke.

1. V.G.Olifer, N.A.Olifer. Datanettverk: Prinsipper, teknologier, protokoller. Lærebok for universiteter. SPb:. Peter, 2010.– 944 s.

2. V. Stallinger. Moderne datanettverk. SPb:. Peter, 2003. – 783 s.

3. Michael J. Martin. Introduksjon til nettverksteknologi. En praktisk guide til nettverksbygging. M., 2002.- 546 s.

4. M. Sportak, F. Poppas. Datanettverk og nettverksteknologier. Kiev, 2002.- 736 s.

5. V. Stallings. Dataoverføringssystemer for data. Moskva, 2002.-928 s.

6. Michael Palmer, Robert Bruce Sinclair. Design og implementering datanettverk. Treningskurs. SPb:. Peter, 2004.- 578 s.

7. Shinder Debra Littlejohn. Grunnleggende om datanettverk. M., 2003.- 623 s.

8. Sheen Odom, Henson Nottingham. CISCO brytere. M., Kudits-Obraz, 2003.- 528 s.

9. I. Rudenko. CISCO-rutere for IP-nettverk. M., Kudits-Obraz, 2003.- 656 s.

10. Clark Kennedy, Hamilton Kevin. Prinsipper for å bytte lokalt Cisco-nettverk. M., Kudits-Obraz, 2003.- 976 s.

11. Semenov A.B. Design og beregning av strukturerte kabelsystemer og deres komponenter. M, IT, 2003.- 416 s.

Pedagogisk utgave

Forelesningsnotater for kurset

"Dataoverføringssystemer"

For studenter som studerer i retning