Gå til innhold

Broadcast fra 1Gb til 10Mb ødelegger nettverket


Anbefalte innlegg

Jeg er på ett system som har over 100 PC'er.

Det er en server som dytter ut en del broadcast. Nettkortet i serveren er riktignok 1Gb, men selv broadcast mengden er bare på rundt 20 - 40 Mb, så jeg overdrev litt i emnetittelen.

 

Switchene jeg bruker er HP Procurve 2810-48G

 

Det som skjer er at noen ganger så er det en eller flere maskiner på systemet som er skrudd av, men pga. de skal kunne startes med WOL, så er nettkortet aktivt, men da bare i 10Mb mode. Det virker som om switchen prøver å sende til disse maskinene, men siden de ikke har båndbredde til å ta unna trafikken, så fylles buffer'et i switchen, og hele nettverket går i stå.

 

Jeg har lest litt om Flow Control, og lurer på om det kan løse problemet, men alle plasser jeg har lest om det så virker det som om det begrenser hvor mye senderen kan sende. Det kan jeg ikke ha, for resten av systemet trenger alle meldingene.

Det jeg er ute etter er muligheten til å kaste pakker om mottageren ikke klarer å ta unna.

Om det innebærer at jeg må bytte switch, så kan det være akseptabelt.

Lenke til kommentar
Videoannonse
Annonse

Du sender 20-40 mbit med broadcasts fra en maskin? Hvorfor i all verden trenger den sende så mye?

 

Du har to valg;

- Gjøre slik at den serveren sender mindre broadcasts. Om mulig, send multicast istedet, så kan de klientene som trenger denne infoen "abonnere" på den multicastgruppen.

- Legge aksesslister på svitsjen din, som hindrer de klientene dette gjelder, fra å få disse broadcastene.

Lenke til kommentar

Du sender 20-40 mbit med broadcasts fra en maskin? Hvorfor i all verden trenger den sende så mye?

 

Du har to valg;

- Gjøre slik at den serveren sender mindre broadcasts. Om mulig, send multicast istedet, så kan de klientene som trenger denne infoen "abonnere" på den multicastgruppen.

- Legge aksesslister på svitsjen din, som hindrer de klientene dette gjelder, fra å få disse broadcastene.

Du aner ikke hvor mange ganger jeg har spurt det samme spørsmålet...

Problemet er at det er ett stort simulator system, der de forskjellige stasjonene skal ha oppdateringer mange ganger i sekundet. Jeg skriver litt om systemet her om du er interessert.

Aksesslister kan også være problematisk, for de samme maskinene skal ha pakkene når de er påskrudd. Men da går jo nettkortene på 1Gb/s.

 

Det kunne sikkert vært laget annerledes sånn at oppdateringer bare ble sendt til de stasjonene det gjelder, eller som du sier brukt multicast. Men dette er nå sånn det er laget, og siden det er ett temmelig stort og komplekst system, så vil det koste alt for mye å endre på alt nå.

Uansett så har ikke jeg kontroll over hvordan utvikling lager programvaren, jeg er i produksjon, og jeg må bare løse problemet...

Lenke til kommentar

Dere bør få litt kommunikasjon mellom utviklere og drift. Dette er definitivt ett utviklerproblem, hvis de baserer seg på broadcasts.

 

Men, i ett forsøk på å være hjelpsom;

Hva mener du egentlig med at nettet går i stå? At svitsjene ikke lenger sender videre pakker for noen av portene?

En svitsj skal jo i teorien kunne virke, selv om en port ikke klarer å svelge unna. Husk dog på om at pakker på en port må droppes, så kan denne pakken være WOL-pakken din, og da vil ikke maskinen starte.

 

Dobbelsjekk at pakkene ikke faktisk allerede er multicast og. Multicast oppfører seg nemlig som broadcast på nett som ikke er konfigurert for multicast. Med litt flaks, så kan jo utviklerene faktisk ha vært litt smarte :)

 

Kan og nevnes at vi har en haug ProCurve (3500, 6600, 5412), og vi sliter med at de gjør litt festlige ting. Spesielt når buffre går fulle, så det kan være verdt å prøve deg på en skikkelig svitsj, for å se om det hjelper.

Lenke til kommentar
  • 3 uker senere...

Del inn lanet ditt i flere vlan. Dvs server på ett vlan og klienter på et eget. Da slipper du broadcast trafikk mellom servere og klienter.

 

Jeg er ikke kjent med HP switcher, men på cisco kan du også sette på storm-control for broadcast meldinger. Dvs hvor mange prosent av interfacet sin båndbredde som max kan gå til broadcast før pakkene blir droppet.

 

Broadcast storm control is a feature of many managed switches in which the switch intentionally ceases to forward all broadcast traffic if the bandwidth consumed by incoming broadcast frames exceeds a designated threshold. Although this does not resolve the root broadcast radiation problem, it limits broadcast radiation intensity and thus allows a network manager to communicate with network equipment to diagnose and resolve the root problem.
Lenke til kommentar

Del inn lanet ditt i flere vlan. Dvs server på ett vlan og klienter på et eget. Da slipper du broadcast trafikk mellom servere og klienter.

 

Jeg er ikke kjent med HP switcher, men på cisco kan du også sette på storm-control for broadcast meldinger. Dvs hvor mange prosent av interfacet sin båndbredde som max kan gå til broadcast før pakkene blir droppet.

Problemet er at klientene faktisk skal ha all broadcast trafikken, bare ikke når maskinen er av..

 

Broadcast storm control tror jeg heller ikke passer så bra. Sånn jeg forstår den teksten (mener jeg prøvde å lese litt om det før også) så vil all broadcast droppes om den totale mengden overstiger en gitt verdi.

 

Problemet med det er det samme som over. At alle de andre klientene må ha all den broadcasten, bortsett fra de få, eller den ene maskinen som står avskrudd med nettkortet i 10Mb WOL modus.

Lenke til kommentar

Problemet er at klientene faktisk skal ha all broadcast trafikken, bare ikke når maskinen er av..

 

Broadcast storm control tror jeg heller ikke passer så bra. Sånn jeg forstår den teksten (mener jeg prøvde å lese litt om det før også) så vil all broadcast droppes om den totale mengden overstiger en gitt verdi.

 

Problemet med det er det samme som over. At alle de andre klientene må ha all den broadcasten, bortsett fra de få, eller den ene maskinen som står avskrudd med nettkortet i 10Mb WOL modus.

 

Jeg mener at storm-control kan funke. hvis du setter storm-control på 50% så vil switchen droppe all broadcast trafikk til interfacet hvis broadcast trafikken overstiger grensen. Når nettverkskortet da står i 10mb vil det ikke motta broadcast, men WOL pakken vil komme frem siden denne ikke er broadcast. Når pcen starter opp og kortet blir satt tilbake til 1gb vil ikke broadcast trafikk overstige 50% og alt vil fungere som normal.

Lenke til kommentar

Jeg mener at storm-control kan funke. hvis du setter storm-control på 50% så vil switchen droppe all broadcast trafikk til interfacet hvis broadcast trafikken overstiger grensen. Når nettverkskortet da står i 10mb vil det ikke motta broadcast, men WOL pakken vil komme frem siden denne ikke er broadcast. Når pcen starter opp og kortet blir satt tilbake til 1gb vil ikke broadcast trafikk overstige 50% og alt vil fungere som normal.

Ah. Da kan jeg ha missforstått hvordan broadcast storm-control funker. Jeg trodde den forkastet broadcast fra senderen om den overstiger en grense. Men det er altså kun klient pakkene på den ene klienten som ikke håndterer det som blir kastet?
Lenke til kommentar

Det kommer veldig an på svitsjmodell. Noen lar deg sette begrensing på N pps, andre på x%.

 

HP ProCurve 3500yl lar deg sette begrensingen på x% på innkommende broadcasts, men ikke utgående. Hva 2810 kan vet jeg ikke, men tviler litt på at den kan mer... :)

 

EDIT: Sjekka og på en 6600ml, og den kan og kun begrense innkommende broadcasts.

Endret av ZeRKoX
Lenke til kommentar
Det kommer veldig an på svitsjmodell. Noen lar deg sette begrensing på N pps, andre på x%. HP ProCurve 3500yl lar deg sette begrensingen på x% på innkommende broadcasts, men ikke utgående. Hva 2810 kan vet jeg ikke, men tviler litt på at den kan mer... :) EDIT: Sjekka og på en 6600ml, og den kan og kun begrense innkommende broadcasts.

 

Det funker jo det, sette begrensninger på inkommende broadcast på det interfacet som går ut til klienten?

Lenke til kommentar

Siden det er svitsjen du konfigurerer, så er det selvsagt i forhold til dens synspunkt du avgjør innkommende og utgående.

 

Og siden det er til en klient vi vil begrense broadcastene, så er det eventuelt utgående broadcasts til klientene du vil begrense. Begrenser du antall broadcasts innn fra serveren, vil ikke de klientene som faktisk trenger broadcastene få de, så innkommende rate-limiting er ikke et alternativ.

 

Når det er sagt, så vil jeg fremdeles påstå at en bedre løsning vil være å finne en bedre løsning på softwaren som kjører på dette nettverket. Å basere seg på så mye broadcast er total idioti. Jeg ville bedt utviklere å vurdere f.eks multicast, slik at de klienter som trenger dataene kan få de, mens de andre ikke trenger å se den.

Lenke til kommentar
  • 1 måned senere...

Vel, da har jeg endelig kommet meg på site igjen og har fått mulighet til å teste. Satte broadcast limit til 90% på alle portene, men det hadde ingen betydning for ytelsen. Så prøvde jeg å sette den til 50%, så til 5%. Ytelsen sank betraktelig på 50, og døde så og si fullstendig på 5. Så det virker som om det er senderen som begrenses, ikke mottageren..

 

Jeg er helt enig i at multicast nok ville vært en mye bedre løsning. Men sånn jeg har forstått det så er det enklere å skrive kode for broadcast. Dessuten har vi aldri hatt så store systemer før, og derfor ikke støtt på akkurat denne problematikken. Det gjør at de ikke har sett problemet med å lage systemet på denne måten, føt nå..

Å skrive om alt til å bruke multicast er nok litt jobb. Det innebærer tid og penger.

Men jeg har hørt litt snakk om at det vurderes å ta den kosten. Så jeg lever i håpet.

Lenke til kommentar

En liten og kjent 'nettverksregle' er

 

"Switches limit collision domains, while routers limit broadcast domains",

 

du har ikke vurdert aa sette en router mellom switch'en og de enhetene som skal snakke paa 10mbit da?

 

edit: eventuelt om du jobber ett av disse stedene som er 'just get it done', hvorfor ikke kjope en L3+ switch naar du forst er i gang? Juniper har noen fine som er baade router og switch i ett, samme med Extreme og Cisco. HP har ogsaa noen, men har ikke noen videre erfaring med disse.. Siden du her bare skal route mellom subnets og ikke mellom porter maatte jo en slik losning vaert optimal?

Endret av [Infected]
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...