Bekijk Volledige Versie : Broadcast
Besten :)
Ik heb een colobak in een bepaald netwerk staan (deze laat ik het liefst even buiten beschouwing), waarbij een andere klant veel broadcastverkeer (tot 10 mbit per piek, meerdere pieken per dag) veroorzaakt. De hoster zegt er weinig aan te kunnen doen (na overleg met de klant). Ik vind het persoonlijk heel lastig, want de grafieken geven nu niet meer weer wat mijn eigen dataverkeer is, maar worden vertroebeld door die pieken. Hoewel de hoster zegt dat hij het niet gaat doorberekenen aan mij, vind ik het toch heel storend.
Wat moet ik hier nu mee? Is er iets wat mijn hoster kan doen (hij heeft de broadcaststormcontrol al op 250 pps gezet)? Is er iets wat ik kan doen? Is er iets wat die klant kan doen (deze beweert zelf dat hij daar niets van weet / niets aan kan doen)? Hoe zouden jullie hier mee omgaan?
Ohja: :lovewht:
Je hoster kan hier heel veel aan doen. Een VLAN aanmaken! Ik mag niet hopen dat jij bij andere klanten in hetzelfde VLAN zit. Immers, configureer je nu de boel verkeerd en geef je de server het IP van de Gateway dan, ik zal het netjes zeggen, heb niet alleen jij last van je eigen fout.
Je hoster kan hier heel veel aan doen. Een VLAN aanmaken! Ik mag niet hopen dat jij bij andere klanten in hetzelfde VLAN zit. Immers, configureer je nu de boel verkeerd en geef je de server het IP van de Gateway dan, ik zal het netjes zeggen, heb niet alleen jij last van je eigen fout.Maak jij voor elke losse colo een apart VLAN aan? Dan ben je een beste IP verspiller.
VLAN per /24 kan prima.
Maak jij voor elke losse colo een apart VLAN aan? Dan ben je een beste IP verspiller.
VLAN per /24 kan prima.
Om nou al je klanten een /24 te geven? Niet echt een oplossing. De bron achter halen en proberen dit te stoppen. Echter veel meer zou je niet kunnen doen.
Om nou al je klanten een /24 te geven? Niet echt een oplossing. De bron achter halen en proberen dit te stoppen. Echter veel meer zou je niet kunnen doen.Dat bedoel ik ook niet.
Maar als je een colo rack hebt, dan kan dat prima in 1 VLAN.
Dat bedoel ik ook niet.
Maar als je een colo rack hebt, dan kan dat prima in 1 VLAN.
Daarom, echter wat er binnen die vlan gebeurt komt wel voor ieder zijn rekening. Stel de Topic Start zit in een shared colorack met een /25 of een /24 dan kan je vrij weinig doen. Je zou eventueel kwart racks wel in een aparte vlan kunnen proppen met een eigen /26 of iets in die richting.
Maarja, probleem moet gewoon worden opgelost.
MediaServe
30/09/06, 16:33
Een VLAN op Layer 2 heeft alleen weinig zin.
Dan moet je dus alleen nog Layer 3 gebruiken :)
Een VLAN op Layer 2 heeft alleen weinig zin.
Dan moet je dus alleen nog Layer 3 gebruiken :)
Wil je ze kunnen opsplitsen dan heb je inderdaad layer3 nodig, echter lijkt mij layer3 ook wel een must zodra er meerdere racks worden aangesloten, vol met shared hosting. Foundry heeft leuke layer2 en 3 switches. Edge Iron gebruiken wij daarvoor, moet ik nog eens een keer goed mee spelen voordat wij dat in productie gaan brengen.
Maak jij voor elke losse colo een apart VLAN aan? Dan ben je een beste IP verspiller.
VLAN per /24 kan prima.
De meeste klanten van me hebben twee of meer servers dus moeten toch al naar eeb eigen VLAN om het totaalverkeer te meten. Kunnen ze meteen gratis ondelring tussen de servers verkeer uitwisselen.
IP's verspillen valt wel mee. 138 IP's voor 4 racks. Maar moet vaak toch een /29 (soms /28) aanvragen voor $klant omdat we de IP's meteen netjes op naam bij RIPE afleveren.
Dat vraag ik me ook af: zijn er uberhaupt hosters die layer 2 gebruiken ipv layer 3, en wat is voor hun het voordeel daarvan? Met layer3 kan je toch zoveel meer instellen?
OT: Weet die klant/de hoster wat voor applicatie er wordt gebruikt die zoveel broadcast verkeer genereert?
Dat vraag ik me ook af: zijn er uberhaupt hosters die layer 2 gebruiken ipv layer 3, en wat is voor hun het voordeel daarvan? Met layer3 kan je toch zoveel meer instellen?
OT: Weet die klant/de hoster wat voor applicatie er wordt gebruikt die zoveel broadcast verkeer genereert?
Is het niet juist andersom? Vrij weinig hosters werken met Layer3.
Vooral om je infrastructuur een boost te geven (ookal is het alleen switching) _kan_ het handig(er) zijn om bijvoorbeeld op layer 3 te gaan switchen/routeren. (BGP bijvoorbeeld).
Vooral de kennis is vaak niet aanwezig om met layer3 om te gaan. Layer2 is voor veel bedrijven letterlijk, stekkertje er in en stekkertje er uit. Ze gebruiken de switchen dan ook letterlijk als hup die op haar beurt weer zijn verbonden met de core switches van het netwerk, waar ze op een vlan staan waar het netwerk een ip range van bijvoorbeeld een /24 op deligeerd.
Met layer 3 kan je dus zelf die /24 in stukken hakken en zelf vlans aanmaken met ip blokken.
Erg offtopic =) :)
MediaServe
30/09/06, 23:12
Layer 2 is sneller, goedkoper en gemakkelijker :)
De meeste providers switchen op Layer 2, mocht je teveel op hetzelfde niveau moeten switchen, dan kun je de Layer 2 switches beter op een Layer 3 coreswitch gaan verdelen en grotere klanten rechtstreeks op je Layer 3 core.
Ook hierbij is het een afweging tussen prijs en functionaliteit :)
Aan de topicstarter, laat je provider met bijvoorbeeld Cacti of Ethereal uitzoeken waar de packets vandaan komen. Laat hem dan die klant op een hoger niveau switchen in een Layer 3 VLAN.
Het is wel degelijk mogelijk om als co-locatie reseller (zonder eigen netwerk) al je klanten in een eigen 'dedicated' vlan neer te zetten.
Koop een switch (eg hp/Cisco) welke proxy_arp ondersteund. Enable dit, geef iedere klant een eigen VLAN en maak een ip-adres aan per vlan. Verdeel je eigen /24 (welke je wellicht toegewezen hebt gekregen van je netwerk leverancier) in kleine blokken bijvoorbeeld een /29 per colocatie klant. Op deze manier zit iedere klant in een eigen subnet en eigen VLAN. Iedere moderne switch support dit tegenwoordig.
EDIT: In je eigen vlan heb je dus ook geen last van broadcast verkeer.
EDIT (2): Zowiezo vind ik dat als je als kwaliteits colocatie leverancier/reseller (als je dus een rack huurt bij een provider en daar co-locatie in aanbied) je iedere klant in een eigen vlan moet zetten. Dit om risico's uit te sluiten. Je kunt hiermee ip conflicten voorkomen (als een klant bijvoorbeeld perongelijk een configuratiefout maakt in zijn ip-configuratie op de server). Je kunt op deze manier hogere garanties bieden aan je colocatie klant. Er kan altijd een klant tussen zitten die perongeluk een fout maakt.. je wilt niet dat de rest daar de dupe van word.