17/08/11 09:25
Beste WHT-ers,
Ik ben in het bezit van een HP J9280A - ProCurve Switch 2510G-48. Nu ben ik een beetje aan het einde van de open poorten en wil een uitbereiding aanschaffen, liefst dezelfde switch.
Mijn vraag is , wat is verstandiger: aansluiten met meerdere netwerkkabels en dan poort teamen, of aansluiten via GBIC? Volgens mij haal je meer snelheid met de poort teamen? De switches komen onder elkaar te hangen dus afstand is niet een issue.
gr,
Armando
17/08/11 09:30
Als ik me niet vergis, dan zitter en toch stackpoorten op die switch? Dan is het beste via die te stacken.
Edit: Toch niet beschikbaar! http://h30094.www3.hp.com/product.as...0A&pagemode=ca
Laatst gewijzigd door GlobalServe; 17/08/11 om 09:32.
17/08/11 09:33
het enige wat er volgens mij te stacken valt is dit:
Single IP Address Management: provides single IP address management for a virtual stack of up to 16 switches
:P
17/08/11 10:19
Maar de vraag is dus: via netwerk poort(en) aansluiten en dan eventueel teamen , of via GBIC ? (weet iemand of dit ook te teamen valt? is uberhaupt de GBIC aansluiting sneller / meer bandbreedte ?
17/08/11 10:22
Wel, als je gigabit doet met die GBIC, is dat meer dan 2/4/8 * 100 Mb...Oorspronkelijk geplaatst door Armando23
Bovendien wordt bij poort bundelen het verkeer gemiddeld verdeeld op basis van flows. Hetzij een hash van src/dst mac, of soms op basis van L3/L4 (IP src/dst + poorten) informatie. (weet niet of deze procurves dat kunnen).
Het betekent dat een enkele flow nooit meer bandbreedte kan gebruiken dan een enkele link.
Als je pech hebt, kunnen een paar stevige flows toevallig op dezelfde link uit komen, en kan dus één link uit een bundel overvol zitten terwijl er op de andere link(en) capaciteit over is.
Kortom, als je kunt kiezen voor GigE is dat een betere keus dan bundelen van FE.
Voor deze situatie met twee switches boven elkaar zou ik daarvoor kiezen; In deze situatie zou voor mij het argument "redundante connectie" wat je dan nog kunt maken voor gebundelde FEs niet voldoende zwaar wegen.
17/08/11 10:50
2510G-48, het is een gigabit switch
17/08/11 10:54
Ja het is een gigabit switch met 4 gigabit BIC poorten... dus qua snelheid zijn ze het zelfde ?
Laatst gewijzigd door Armando23; 17/08/11 om 10:56.
17/08/11 11:20
Ja, dat is gelijk. Je kan die gbic poorten ook gewoon teamen, 't is een poort net als elke andere alleen kan je er meerdere types interface in prikken.
Ik zou de gbic poorten pas gebruiken als daar noodzaak voor is (bijv. omdat je een fiber uplink krijgt), niet om deze switches nu te koppelen.
17/08/11 11:38
Ah, overheen gekeken; Ik had wel op de link die Globalserve postte geklikt, en die was dus voor de 2510-48 ... :-(2510G-48, het is een gigabit switch
Qua snelheid is er geen verschil tussen de poorten.
(ik kan geen architectuur beschrijving vinden of groepen poorten misschien oversubscribed zijn op asics, en of misschien sommige poorten geen asic delen. In de lower-end access switches wil dit nog wel eens het geval zijn. Aan de andere kant, als je je eenmaal daar zorgen over aan het maken bent , ben je je switches wel fors zwaar aan het belasten).
17/08/11 12:28
17/08/11 22:41
Hallo Armando,
Wij hebben ditzelfde princiepe ook op onze switches.
Onze access switches zijn dmv trunks verbonden met onze coreswitches.
Elke access switch heeft een trunk (standaard trunk) met de core switch, waar 2x 1gbit dus 1x 2gbit word.
Hij doet dan aan loadbalancing, ziet hij dat één link meer in gebruik is, dan doet hij een volgende connectie openen via de tweede link.
Hierdoor kun je in theorie 2gbit's tussen je 2 switches hebben, echter is dit zelden haalbaar.
Wijzelf hebben met intensieve test (met meerdere servers) ~1.8gbit/s over de trunklijn kunnen krijgen.
Denk er ook aan dat zoals Visser al zegt niet meer dan 1gbit/s per sessie mogelijk is (dus 1 op 1 transfer is nooit 2gbits, maar maximaal 1gbit/s)
Het is ons wel gelukt om dit met een setje 2910al-24G's voor elkaar te krijgen, 2x 1gbit link kan dan wel 2gbit's per sessie met LACP trunking, echter dient je server dit dan ook te ondersteunen dmv nic teaming of bonding van interface kaarten.
De 2910al-24g's ondersteunen basic layer 3, iets wat de 2510 serie niet doet dus gaat dat waarschijnlijk niet lukken.
Kwa snelheid maakt het niet uit of je de fiber poorten of de ethernet poorten gebruikt.
Neem goede kwaliteit CAT6 kabel, en er zal geen merkbaar verschil zijn.
Hopelijk heb je er iets aan.
Laatst gewijzigd door Mick-X; 17/08/11 om 22:44.
17/08/11 23:55
Hier twijfel ik toch wat aan, dat loadbalancing zou kijken naar load op de link. Ik heb het niet kunnen terugvinden in diverse Procurve manuals.
Zoals je het omschrijft is het iets wat nogal veel CPU intelligentie zou vergen.
Alles wat ik kon vinden is precies wat ik al schreef, een hash op basis van mac adressen of L3/L4 informatie.
Dat is gebruikelijk, voorspelbaar, en kan supersnel in asics.
Met als nadeel dat als de load bestaat uit maar weinig sessies die wel zwaar zijn, je statistisch pech kunt hebben en één link overvol kan zijn.
Kortom, heb je een link naar HP docs die je uitleg ondersteunen dat bestaande load op een link meetelt het toewijzen van een link aan een sessie ?
19/08/11 14:38
Hallo Visser,
Ik heb helaas geen link naar een procurve manual.
Wij hebben tiental van deze procurves draaien, van 2810-48G tot 2910al-48G.
Wat ik typte was voornamelijk gebaseerd op mijn eigen ervaring / indruk wat het trunking op mij achter heeft gelaten.
Wij hebben het getest met een vijftal servers: 10mb bins, 100mb bins en 1000mb bins, random vanaf twee server naar 5 andere servers, allen gigabit.
Het lijkt erop dat de load netjes verdeeld word, oke ik moet toegeven dat het niet precies 50/50 was maar de resultaten wat ik zag waren adequaat genoeg om het in te voeren in ons hele netwerk.
Ook als ik nu de interfaces bekijk, dan is de verdeling niet helemaal 50/50 het gaat een beetje heen en weer.
Hoe de switch het precies doet weet ik niet, maakt mij ook niet zoveel uit, als het maar "werkt"
19/08/11 20:39
Ok. Zoals ik schreef, het zou me om een aantal redenen verbaasd hebben als het op die manier zou werken, maar aangezien ik de procurve lijn niet goed ken, had het natuurlijk gekund dat ik een optie niet ken.
De manuals ervan staan wel online, en in degenen die ik dan even bekeken had voor loadsharing staat ook alleen de hash gebaseerde verdeling.
Oh, zodra je "iets meer dan een handvol" flows hebt komt het ook gemiddeld prima uit.
Wij hebben het getest met een vijftal servers: 10mb bins, 100mb bins en 1000mb bins, random vanaf twee server naar 5 andere servers, allen gigabit.
Het lijkt erop dat de load netjes verdeeld word, oke ik moet toegeven dat het niet precies 50/50 was maar de resultaten wat ik zag waren adequaat genoeg om het in te voeren in ons hele netwerk.
Ook als ik nu de interfaces bekijk, dan is de verdeling niet helemaal 50/50 het gaat een beetje heen en weer.
Hoe de switch het precies doet weet ik niet, maakt mij ook niet zoveel uit, als het maar "werkt"
Weten hoe het werkt is nuttig/nodig voor de randgevallen waarin je moet begrijpen waarom de verdeling soms heel scheef kan zijn.
Als je bijvoorbeeld twee heel zware flows hebt en verder 3x niks (backup jobs, of storage verkeer of zo), kunnen die best toevallig [50% kans] op dezelfde link uitkomen.
(ook nuttig om te weten : Cisco noemt gebundelde poorten 'EtherChannels' , met bundel interface PortChannel, en gebruikt de term Trunk voor een poort waarop VLAN tags gebruikt worden)
Likes: 
Quote