[Infrastructuur] Te weinig glas voor goede uplinks

[MaanBanaan]

Ik ben een beetje in dubio...

De switches in een bepaalde patchruimte moeten wegens ouderdom vervangen worden. Ondanks dat het (nog) niet dringend nodig ist, wil ik graag gigabit naar alle clients. Layer 2+ switches, met dynamische VLANs, routing und QoS zijn vandaag de dag echt betaalbaar geworden (bijv. de HP V1910 serie). Het probleem wat ik hier heb is echter, dat ik in de patchruimte waar het over gaat 76 patchkabel aan moet sluiten, maar ik slechts 4 maal glas naar de serverruimte heb liggen.

Een gebrek aan ervaring ist de aanleiding dit topic te starten, ondanks dat ik veel nazoekwerk heb gedaan.
Dit topic leert me bijvoorbeeld, dat de meningen over de hoeveelheid poorten verdeelt zijn.

Wat ik heb:

- 4 fiberleidingen met GBIC-Modulen aan de andere kant
- 3COM 5500G-EI Coreswitches aan de andere kant

Nou kan je denken "vier maal glas is meer als voldoende", dat klopt ook. Maar als er aan de andere kant van die fibers slechts GBIC-modulen zijn, heb ik dus effektief maar 4Gbit uplink voor die 76 poorten. De GBIC-modulen in de Serverruimte steken in 3com 5500G-EI Switches die met zn 8-en in een snelle stack hangen, en die willen we niet vervangen. 10Gbit-Modulen aan de achterkant zijn te duur en overbodig. Met die vier 1Gbit fiber-uplinks moet ik het dus doen.

Zouden jullie twee 48-poorts gigabit switches kopen, die ik dan natuurlijk met ieder 2 fibers aan kan sluiten? Of toch vier 24-poorts gigabit switches, waar ik dan helaas maar 1 Gbit uplink per stuk zou hebben? In dat geval vraag ik me of het niet op bepaalde momenten langzamer ist als de huidige 100Mbit poorten met 1Gbit uplink, tenslotte zouden een of enkele clients de complete uplink kunnen dichttrekken (hoewel de servers bij ons praktisch alle gevirtualiseerd zijn, en geen van deze servers die volle 1000Mbit kan leveren).

Er spelen nog meerdere faktoren mee (PoE op kleine switches is goedkoper, SPOF-aspekt bij weinig grotere switches in vergelijking tot meerdere kleinere, etc.), maar die zijn minder belangrijk.

Niet op de zinsbouw letten, het leven in Duitsland zit teveel in de vingers

[DrFlash]

Ik zou gaan voor stackable switches waarbij de bundeling van poorten ook over de stack werkt. zo kan je gewoon je 96 poorten via een bundel van 4 gigabit poorten laten communiceren.

[MaanBanaan]

Dat is natuurlijk ook een goed idee, hoewel dan de switches in serie staan. Ligt de laatste in de stack eruit, loopt niets meer. Weet trouwens iemand of bij HP (daar heb ik me op vastgelegt), er een "echte" stack word gemaakt op de E4210 modellen, i.p.v. slechts een centraal management over een enkel IP? De 5500G-EI van HP (eigenlijk een 3com model) doet dat, maar van de andere modellen weet ik het niet. Heb zoiets ooit gehoord, daarom vraag ik dat even na.

[PeterPan]

HP kent geen stacking voor zover ik weet. Alleen 3COM en 1 serie van Cisco volgens mij.
Wel heeft HP natuurlijk de modulaire switches als de 5406zl serie met een snelle backplane tussen de modules.

[IcE_364]

PeterPan schreef op dinsdag 29 maart 2011 @ 13:16:
HP kent geen stacking voor zover ik weet. Alleen 3COM en 1 serie van Cisco volgens mij.
Wel heeft HP natuurlijk de modulaire switches als de 5406zl serie met een snelle backplane tussen de modules.

Ook de Juniper EX4200 kent stacking onder de noemen Virtual Chassis:
https://www.juniper.net/u...ion-guides/8010018-en.pdf

[Verwijderd]

Om even op je oorspronkelijke vraag terug te komen: 4gbit uplink (in etherchannel/portchannel/trunk, of hoe je het ook wil noemen afhankelijk van je vendor ) zal meer dan voldoende zijn voor connectiviteit tussen clients en servers. Zoals je zelf al aangeeft zal geen enkele server 1gbit effectief kunnen aanleveren in 1 enkele sessie, tenzij je met video/CAD-CAM/.. of iets dergelijks bezig bent. Moest er toch ergens een client zijn die sporadisch 1gbit kan voltrekken, zal er nog steeds 3gbit beschikbaar zijn. Via MAC of IP loadbalancing hebben de andere clients dan (in theorie) 25% kans om ook op de belaste link terecht te komen.

In short: ik zou dus inderdaad 2x 48 ports switches nemen die kunnen gestacked worden, met 1x 4gbit uplink naar je core switch(es). Vendor speelt daarbij minder een rol (Cisco, Nortel/Avaya, HP(?),...)

[CyBeR]

Neem 1000BASE-BX modules en je hebt opeens 8 uplinks.

[Predator]

JRTB schreef op dinsdag 29 maart 2011 @ 12:48:
Dat is natuurlijk ook een goed idee, hoewel dan de switches in serie staan. Ligt de laatste in de stack eruit, loopt niets meer.

Dat zie je verkeerd.
Er zijn stacks en er zijn stacks

De term wordt nogal verwarrend gebruikt door sommige fabrikanten.
Een stack is altijd een groep switches die zich als het ware als 1 switch profileren (1 mgmt IP van waaruit je alle poorten kan configureren). Niet alle stacks hebben echter een backplane interconnectie.

De stacks met een backplane interconnectie zijn wel interessant omdat je cross-stack-member LACP kan doen en ze HW redundantie hebben omdat de stackmaster functies en config overgenomen kunnen worden.

Ik ben zelf geen grote fan van stacks, o.a. omdat je meestal (althans bij Cisco) de stack volledig down moet als je upgraded (alle members moeten dezelfde software draaien). Als je servers moet redundante nic's over meerdere stack members spreid is dat wel een pain-in-the-ass als die dan toch beide down moeten gaan.
Van het oogpunt van redundantie is een stack ook niet 100% redundant. Als je stack bv routering doet, dan is die redundant (als je tenminste alle links ook op andere members hebt) voor HW, maar niet voor bv. config errors.

Voor clients maakt dat minder uit natuurlijk.

Maar aangezien stackable switches ook wat duurder zijn zou ikzelf gewoon 2x48p nemen en beide 2 uplinks geven. Client verkeer wordt zo vaak overschat. 2x1G zal voldoende zijn voor 48 normale clients zelfs als ze allemaal Gig hebben. Clients gaan geen TB's naar de fileserver pompen.

[Bl@ckbird]

Predator schreef op dinsdag 29 maart 2011 @ 21:43:
[...]

Ik ben zelf geen grote fan van stacks, o.a. omdat je meestal (althans bij Cisco) de stack volledig down moet als je upgraded (alle members moeten dezelfde software draaien). Als je servers moet redundante nic's over meerdere stack members spreid is dat wel een pain-in-the-ass als die dan toch beide down moeten gaan.
Van het oogpunt van redundantie is een stack ook niet 100% redundant. Als je stack bv routering doet, dan is die redundant (als je tenminste alle links ook op andere members hebt) voor HW, maar niet voor bv. config errors.

Als je volledige redundancy wil hebben en In Service Software Upgrade ( ISSU ) dan moet je naar een modulaire switch kijken. (4500, 6500, etc.) Een stack van 3750 switches is een goedkope oplossing hiervoor.
(Hoewel als je echt veel switch poorten wil hebben, een modulaire switch goedkoper is.)

Officieel moet je alle stack members voorzien van hetzelfde Enhanced L3 image als je dynamisch wil routeren. In de praktijk zie ik vaak dat twee stack members voorzien worden van Enhanced L3 image. Faalt een switch met een Enhanced L3 image, dan is er een tweede switch die dit kan overnemen.

PeterPan schreef op dinsdag 29 maart 2011 @ 13:16:
HP kent geen stacking voor zover ik weet. Alleen 3COM en 1 serie van Cisco volgens mij.
Wel heeft HP natuurlijk de modulaire switches als de 5406zl serie met een snelle backplane tussen de modules.

Cisco heeft de 3750 serie en de 2960S.
De 3750 kan je stacken op de backplane. Bij de oudere modellen en de 10/100Mbps model (3750, 3750G en de 3750v2) is dit 32Gbps. De nieuwe serie switches (3750X) is dit 64Gbps. De 3750X kan je ook voorzien van redundant voedingen en je kan StackPower gebruiken. (Stroom wordt zo verdeelt over meerdere stack members.)

De 2960S is de opvolger van de 2960 en 2960G en kan je ook stacken. Dit is niet op de backplane, maar deze switches heben hier wel speciale stacking modules voor. (Dit is 2x 10Gbps.)

JRTB schreef op dinsdag 29 maart 2011 @ 10:54:
[...]

Zouden jullie twee 48-poorts gigabit switches kopen, die ik dan natuurlijk met ieder 2 fibers aan kan sluiten? Of toch vier 24-poorts gigabit switches, waar ik dan helaas maar 1 Gbit uplink per stuk zou hebben?

Deze keuze liet ik vaak afhangen van het PoE budget wat de switch had. IEEE 802.3af PoE standaard ondersteund 15.4W per poort. Veel switches ondersteunen slechts 24x 15.4W = 370W per switch. Een andere mogelijk is 48x 7.7W = 370W per switch, maar het max. budget is 370W per switch.
Bij een 48 poorts switch bestaat dus de mogelijkheid dat men teveel PoE vraagt. (Vooral als men een hoop IP camera's, kleuren IP Phones en N-standaard access points gaat aansluiten.)

Met 2x 24 poorts switches weet je altijd zeker dat men niet teveel PoE vraagt.
Inmiddels zijn er ook switches die Full Power ondersteunen. Dus die 48x 15.4W ondersteunen.

Je zou kunnen kijken naar een 3560X (non stackable) of een 3750X (stackable) met L2 LAN Base licentie.
Twee switches die als Core dienen kan je voorzien van L3 IP Base licentie (statisch routeren) of IP Services licentie (dynamisch routeren m.b.v. OSPF, EIGRP, etc.)

De 3560X en 3750X kan je voorzien van één C3KX-NM-1G module per switch. Je hebt dan 4 SFP poorten voor glasvezel uplinks. Een andere mogelijkheid is de C3KX-NM-10G module. Deze heeft 4 SFP poorten. 2 hiervan ondersteunen standaard gigabit ethernet en 2 poorten ondersteunen SFP+ en 10 Gigabit Ethernet.

Dus de software opties (L2, L3 en Enhanced L3) als uplink mogelijkheden (1 of 10GE)
en voedingen (350, 715 en 1100W) zijn modulair.

In normale kantoor omgevingen is gigabit-to-the-desktop nog redelijk overkill.
De meeste applicaties gebruiken niet zoveel. (Meten is hierbij weten.)
Tenzij je met video of CAD tekeningen aan de slag gaat, zoals viper52b al aangaf.
Als je N access points uitrolt is het ook handig om gigabit switches te gebruiken, omdat je hier met meerdere clients aan zit. Maar je hebt natuurlijk niet alleen maar gigabit switches nodig, om enkele access points aan te sluiten.

[AK47]

@ JRTB: De stacking technologie van HP (oud H3C) in de A-Series is IRF. Als je daarbij gigabit voor je clients wil hebben dan zijn de volgende switches een optie:

- HP A5500-48G EI Switch (PoE model ook mogelijk) + 2 port 10GbE local connection module + CX4 kabel
- HP A5120-48G EI 2-slot switch (PoE model ook mogelijk) + 2 port 10GbE local connection module + CX4 kabel

Voor IRF geldt: dit moet bij de gigabit switch modellen lopen over de 10GbE poorten.

In de E-Series zitten de oude 3Com modellen met de XRN stacking technologie.

Als je de middelen hebt om voor de A-Series te gaan zou ik dat doen.


Een laatste optie kan eventueel een HP E5406zl chassis zijn met 2x een 24p gigabit module.

[ Voor 15% gewijzigd door AK47 op 30-03-2011 10:10 ]

[Verwijderd]

AK47 schreef op woensdag 30 maart 2011 @ 10:07:

[...]

Een laatste optie kan eventueel een HP E5406zl chassis zijn met 2x een 24p gigabit module.

De TS wil Gb naar de clients, omdat dit - volgens hem - tegenwoordig erg betaalbaar is. Een 5406zl mag dan niet extreem duur zijn, maar alles bij elkaar wordt dat toch een stuk duurder dan de 2 48-poorts V1910-switches die hij in eerste instantie zo betaalbaar vond. Voor een 5406zl kost 1 module met 20 koperpoorten en 4 SFP-slots alleen al 2000 euro ex. BTW. Daar moeten dan nog 4 SFP's bij à 200 euro. En volgens mij kost een 5406zl met 2 moduels met 24 poorten ongeveer 6000 euro ex. BTW.

Dan zitten we al aan ruim 8k ex. BTW.

[AK47]

Ik snap dat die optie vrij prijzig is, maar ik gaf een aantal opties voor "stackables" binnen de HP lijn. De andere opties uit de A-lijn zijn ook prijzig trouwens.

Dit zijn dan natuurlijk wel "full managed" switches en geen "web managed" switches (zoals de V1910). De 5406zl heeft een L3 feature-set en hetzelfde geldt ook voor de A5500 serie. Dit is vrij overkill voor als end-user switch eigenlijk.

Als stacking geen noodzaak is dan kun je prima gaan voor een 48p gigabit switch en deze met 2x 1gigabit uplinken (via LACP). Je kunt daarbij ook overwegen om te kijken naar deze modellen uit de E-Series:

- HP ProCurve 2510-24G (geen PoE mogelijk) (layer 2 managed only)
- HP ProCurve 2910al-48G (evt ook PoE+ mogelijk) (layer 3 managed)

In deze modellen heb je ook support voor o.a. spanning-tree (wat niet in de V1910 serie zit zover ik weet), wat o.a. goed is voor loop-protection en evt. redundant links.

[MaanBanaan]

Predator schreef op dinsdag 29 maart 2011 @ 21:43:
[...]
Maar aangezien stackable switches ook wat duurder zijn zou ikzelf gewoon 2x48p nemen en beide 2 uplinks geven. Client verkeer wordt zo vaak overschat. 2x1G zal voldoende zijn voor 48 normale clients zelfs als ze allemaal Gig hebben. Clients gaan geen TB's naar de fileserver pompen.

Hmm, jullie voorstellen zijn stuk voor stuk goed (en goed onderbouwd). Ik denk dat het 2 niet gestackte 48 poorts worden, die ik dan inderdaad met 2x1Gbit met de backbone zal verbinden. De voorgestelde stackables zijn super, maar inderdaad onder de streep te duur en een beetje overkill. Voor dingen als OSPF is ons netwerk (gemeente) niet groot of mission-critical genoeg, dus spelen met de echt interessante switches blijft helaas theorie.

_{Over "niet mission-critical genoeg" gesproken: 2 jaar geleden, voor ik hier was, is hier een complete ESX-Farm opgezet. Dikke UPS eraan, HA aan, alles super. En dan 6 maanden geleden een stroomstoring. Tja... De UPS heeft braaf zn werk gedaan, TOTDAT de batterij op was. Ja, de stroomstoring duurde helaas langer. Ja, alle servers zijn spontaan uit de lucht gevallen in plaats van braaf met een signaal van te voren afgesloten. En ja, die paar honderdtjes voor UPS Powerchute Licenties plus een paar uurtjes werk vond kennelijk niemand belangrijk . Zeg maar dag tegen je high-availability . Voordat het SAN weer consistent was en alles weer up...}

Bl@ckbird schreef op dinsdag 29 maart 2011 @ 23:37:

Deze keuze liet ik vaak afhangen van het PoE budget wat de switch had. IEEE 802.3af PoE standaard ondersteund 15.4W per poort. Veel switches ondersteunen slechts 24x 15.4W = 370W per switch. Een andere mogelijk is 48x 7.7W = 370W per switch, maar het max. budget is 370W per switch.
Bij een 48 poorts switch bestaat dus de mogelijkheid dat men teveel PoE vraagt. (Vooral als men een hoop IP camera's, kleuren IP Phones en N-standaard access points gaat aansluiten.)

Met 2x 24 poorts switches weet je altijd zeker dat men niet teveel PoE vraagt.
Inmiddels zijn er ook switches die Full Power ondersteunen. Dus die 48x 15.4W ondersteunen.

Gelukkig worden dat er slechts weinig, een paar AP's en misschien eens een IP-Camera hier en daar.

Overigens, wat zijn die GBICs een ramp zeg. 300 Euro per stuk voor een JD118B, de JD493A werkt niet meer... HP schijnt alles met firmware geblocked te hebben, net zoals bij de inktpatronen. Heeft er iemand wel eens succesvol "compatible-GBIC's" gebruikt in recente HP producten? En omdat de V1910 eigenlijk een 3COM Baseline 28xx is, of de oude 3CSFP91 er nog in werken?

[Bl@ckbird]

JRTB schreef op woensdag 30 maart 2011 @ 16:35:
[...]

De voorgestelde stackables zijn super, maar inderdaad onder de streep te duur en een beetje overkill. Voor dingen als OSPF is ons netwerk (gemeente) niet groot of mission-critical genoeg, dus spelen met de echt interessante switches blijft helaas theorie.

De 3750X (dus niet de klassieke 3750 switches) zijn er ook met layer 2 image / licentie. Dit scheelt iets in prijs.
En je kan een L2 3750X altijd upgraden naar L3 als daar behoefte voor is.

Lager in het product portfolio zijn er de SMB switches:
http://www.cisco.com/cisc...uters_switches/index.html

Zo is SB300 een layer 3 switch. Je kan hem alleen beheren via een WebGUI en SNMP, maar geen CLI. SMB switches zijn vooral point-managed. Wil je deze switches configureren, dan moet je elke switch apart configureren. Met netwerkmanagement kan je alleen wat monitoring doen (via SNMP) maar geen configuratie veranderingen doorvoeren. Ook advanced zaken als EEM (waarmee je dingen kan scripten. Low-level waarschuwing voor inktcardridges doorsturen via Twitter bijvoorbeeld ) zit niet op deze switches.

Overigens heeft Cisco ook refurb apparatuur. Dit zijn vaak voorraden die distributeurs en de Cisco TAC support organisatie retour mogen sturen. Wettelijk gezien mag dit niet als "nieuw" verkocht worden. Op Cisco Certified Refurb apparatuur (dus niet grijze handel) kan je ook gewoon Smartnet support contracten afsluiten. Prijzen van refurb liggen ongeveer 25% lager t.o.v. nieuw. Het duurt alleen altijd even voordat de nieuwste hardware beschikbaar is als refurb. Maar switches die al enige tijd op de markt zijn geen probleem.

[Predator]

JRTB schreef op woensdag 30 maart 2011 @ 16:35:
Overigens, wat zijn die GBICs een ramp zeg. 300 Euro per stuk voor een JD118B, de JD493A werkt niet meer... HP schijnt alles met firmware geblocked te hebben, net zoals bij de inktpatronen. Heeft er iemand wel eens succesvol "compatible-GBIC's" gebruikt in recente HP producten? En omdat de V1910 eigenlijk een 3COM Baseline 28xx is, of de oude 3CSFP91 er nog in werken?

Ik vind die prijs goed meevallen voor SX-SFP.

Ik heb nog compatible-GBIC's (non-cisco) in cisco apparatuur gehad die vele jaren zonder problemen gewerkt hebben, maar het blijft een risico factor.
Het is vergelijkbaar maar compatible toners voor printers...
Leuk en goedkoop zolang het blijft werken en je geen support nodig hebt.

PS: kleine tip... tegen je leverancier zeuren over de prijs van de SFP's en het grote prijsverschil met compatible SFP's helpt vaak om wat extra korting te krijgen. Ik doe het altijd en met succes

[AK47]

@ JRTB: 3Com/H3C doet zover ik weet geen vendor checking. HP ProCurve modellen (E-Series) doen dat daarin tegen wel.

Let wel dat je geen support hebt als je non-compatible transceivers gebruikt.

[MaanBanaan]

Zo, besteld.

Het zijn HP V1910s geworden (vroeger 3com 2928), 48 poorts. 2Gbit uplink pro switch. Samen met een V1910 24 poorts en een V1910 24 Poorts met PoE (beide voor een andere patchkamer) en alle GBICs/Kabels zit ik alweer over de 5000 Euro (originele GBICs genomen, inderdaad omdat er anders evt. geen support geleverd wordt en ik in het geval van storingen niet de tijd heb/mag nemen om zelf te knutselen als er ook betaalde support bestaat).

[MaanBanaan]

Potverdrieeurodubbeltjes .

Alles binnen. Nu probeer ik de uplinks aan de praat te krijgen, maar daar kwam pas licht uit de GBIC's toen ik aan de kant van de coreswitches de snelheid handmatig op 1000 en de duplexmode op full had gezet. Gewoon, omdat ze het niet voor elkaar kregen om zelf deze basis-verbindingsinfo op elkaar af te stemmen (HP JD118B/X120 GBIC's in de V1910 switches, J4858C in de 3com 5500G-EI coreswitches).

Super, het werkt in ieder geval per poort. Maar ja, misschien kennen jullie de voorwaarden voor LACP op veel switches: handmatige poortinstellingen zijn niet geoorloofd. Misschien dat de coreswitches een FW-Upgrade nodig hebben om de GBIC's beter te herkennen, zodat ze ook automatisch de juiste instellingen met de GBIC's in de andere switch vinden, maar misschien dat het ook helemaal niet gaat werken met LACP omdat de Aggregation-Group uit twee soorten GBIC's bestaat.

Een TFTP opzetten om al onze 8 coreswitches een softwareupdate te geven zie ik niet zo zitten, daarna moet ik beslist de stack weer opbouwen. Hebben jullie ervaringen met LACP en verschillende GBIC's?

[Predator]

JRTB schreef op maandag 25 april 2011 @ 20:17:
Een TFTP opzetten om al onze 8 coreswitches een softwareupdate te geven zie ik niet zo zitten, daarna moet ik beslist de stack weer opbouwen. Hebben jullie ervaringen met LACP en verschillende GBIC's?

Ik ben niet zo bekend met HP/ex-com meuk, maar het lijkt me wel raar dat je de stack config verliest na een FW-upgrade

Voor wat betreft je vraag over LACP icm GBIC. Dat zou niet mogen verschillen.
GBIC's zijn L1 interfaces. LACP draait natuurlijk boven. De onderliggende hardware speelt geen rol (of er zou een vendor beperking moeten zijn).
Zelf vind ik het geen nadeel als je een mix van verschillende GBIC's hebt, integendeel zelfs.
Als je switch na een FW upgrade last heeft met 1 type GBIC, dan is de kans groot dat het beperkt blijft bij dat ene type...

[MaanBanaan]

Waarom ik bang was die dingen te upgraden, ist omdat we een stack van 8 coreswitches hebben, en ik vermoed dat verschillende firmware-versies in 1 stack niet gaat werken. Dit heb ik bevestigd door in de configguide te kijken. Je hebt trouwens theoretisch gelijk met layer 1, maar LACP is wel afhankelijk van o.a. gelijk ingestelde duplexmodes etc.

Maar het ziet er naar uit dat ik LACP toch aan de praat heb. Dus dat deel met de firmwareupgrade is dan gelukkig niet van toepassing. Weet iemand hoe ik kan testen of de ingestelde 2-kabel-aggregation-group ook met load balancing functioneert? Met vier snelle 1000-Mbit PC's (twee per Switch) tegelijkertijd grote stukken data kopieren en dan minimaal op 70 a 80 MB/sec per PC uitkomen? De testprogramma's die ik tot nu toe gebruik (PCATTCP.exe) vind ik namelijk niet betrouwbaar.

[TigerMooD]

Zoals ik het tot nu toe bij 3COM 5500's heb meegemaakt is dat het verkeer zoveel mogelijk over 1 lijn gaat. Threads zullen (en mogen) nooit opgedeeld worden over de verschillende lijnen. Als een kabel aan zijn max doorvoer zit, wordt een tweede bijgeschakeld, als die weer max zit een derde, enz...

Het probleem is alleen dat ik dit nooit in de werkelijkheid heb kunnen testen, ook de engineers van 3COM konden me geen fatsoenlijk antwoord geven wat er precies gebeurde in een LACP opstelling.

Testen heb ik tot nu toe altijd met IPerf gedaan, dat werkt voor mij prima genoeg.

[Predator]

Normaal doet de switch een hash functie op basis van L2 (src/dst mac), L3 (src/dst IP) en/of L4 (src/dst TCP) die dan 1 van de LACP active members geeft.
Dit is dan de 'load-balancing'. Voor zover ik weet wordt er geen rekening gehouden met de load van de LACP links. Maw als de eerste 'flow' over L1 gaat, en de hash van een andere 'flow' dezelfde member L1 geeft dan wordt die 'flow' ook over L1 gestuurd.

Cisco CLI heeft zelf een commando om de gebruikte link te identifieren:

VB met een 4 member LACP:

code:

>test etherchannel load-balance interface port-channel 10 ip 10.10.10.10 10.20.30.40
Would select Gi1/4 of Po10

>test etherchannel load-balance interface port-channel 10 ip 10.10.10.10 10.20.30.41
Would select Gi1/3 of Po10

>test etherchannel load-balance interface port-channel 10 ip 10.10.10.10 10.20.30.42
Would select Gi1/1 of Po10

>test etherchannel load-balance interface port-channel 10 ip 10.10.10.10 10.20.30.43
Would select Gi1/2 of Po10

[MaanBanaan]

Hmm, helaas schijnen zowel TigerMooD als Predator de waarheid te zeggen. De uplink tussen de switches onderling heb ik nog niet getest. Maar omdat ik alles hier zo redundant mogelijk wil maken, heb ik onze admin-nas (QNAP 8xx 19") ook per LACP op 2 verschillende switches in de XRN-Stack geprikt. Ik zie dus nu, dat een van de twee NIC's nooit knippert. Pas als ik de eerste kabel eruit haal, springt de tweede verbinding er na één seconde bij. Geen echte loadbalancing dus, alleen maar een aktive standby. Dat is wel jammer.

Misschien moet ik eens met andere protokollen experimenteren...

[PerfectPC]

JRTB schreef op maandag 02 mei 2011 @ 16:35:
Hmm, helaas schijnen zowel TigerMooD als Predator de waarheid te zeggen. De uplink tussen de switches onderling heb ik nog niet getest. Maar omdat ik alles hier zo redundant mogelijk wil maken, heb ik onze admin-nas (QNAP 8xx 19") ook per LACP op 2 verschillende switches in de XRN-Stack geprikt. Ik zie dus nu, dat een van de twee NIC's nooit knippert. Pas als ik de eerste kabel eruit haal, springt de tweede verbinding er na één seconde bij. Geen echte loadbalancing dus, alleen maar een aktive standby. Dat is wel jammer.

Misschien moet ik eens met andere protokollen experimenteren...

Ben je zeker dat LACP wel active is en dat je geen kale 802.3ad hebt opgezet?

[MaanBanaan]

Even voor het archief, zodat anderen er in de toekomst ook iets aan hebben: het thema LACP op 3com 2928/2952 resp. HP V1910 switches is inmiddels duidelijk. Je leest namelijk meerdere meningen, in dit topic bijvoorbeeld:

mookie schreef op zondag 06 december 2009 @ 14:42:


Je switches zullen dan pakketten om en om over 1 van de links gaan.
En het is ook niet gebonden aan sessies van gebruikers, hij balanced echt om en om per pakket.

Dat klopt dus niet. Bij 1 clients blijft de 1e uplink van elke switch bijna dood, de LED knippert somst 30 seconden überhaupt niet. Zodra ik met 2 i.p.v. 1 client ga testen, wordt duidelijk dat de 2e link gebruikt wordt.
Met 2 Clients, en aan de andere kant 2 servers, wordt uit bijvoorbeeld gelijktijdige iPerf-tests duidelijk, dat ik 1,5-1,7 GB/sec door de vezels kan sturen (dat is iets minder als 2 keer de 950 Mbit die ik door een enkele uplink krijg).

TigerMooD schreef op donderdag 28 april 2011 @ 15:40:
Zoals ik het tot nu toe bij 3COM 5500's heb meegemaakt is dat het verkeer zoveel mogelijk over 1 lijn gaat. Threads zullen (en mogen) nooit opgedeeld worden over de verschillende lijnen. Als een kabel aan zijn max doorvoer zit, wordt een tweede bijgeschakeld, als die weer max zit een derde, enz...

Het probleem is alleen dat ik dit nooit in de werkelijkheid heb kunnen testen, ook de engineers van 3COM konden me geen fatsoenlijk antwoord geven wat er precies gebeurde in een LACP opstelling.

Testen heb ik tot nu toe altijd met IPerf gedaan, dat werkt voor mij prima genoeg.

Dit ist dus wel correct. Verkeer van 1 client zal altijd over 1 kabel gaan. De andere doet dan letterlijk niets. Pas bij meerdere clientsessies, zoals gezegd. Failover functioneert ook prima, kabels eruit trekken wordt niet gemerkt, hoogstens door oude datenbankprogramma's. LACP op de switches in dit topic, ook de 5500, werkt dus zowel qua failover, als ook qua snelheidverdubbeling goed.

[TrailBlazer]

Die loadbalancing ook van een client kan prima over twee poorten gaan dat hangt af hoe intelligent de switch is. Op onze 6500

code:

switch#sh etherchannel load-balance
EtherChannel Load-Balancing Configuration:
        src-dst-port
        mpls label-ip

EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source XOR Destination MAC address
  IPv4: Source XOR Destination TCP/UDP (layer-4) port number
  IPv6: Source XOR Destination IP address
  MPLS: Label or IP
switch#

dus van elk ip pakket wordt gekeken wat het source destination port is en daarop wordt er gehashed. Verkeer van een tcp sessie zal over een touwtje gaan maar als een client meerdere sessies heeft staan dan heb je ene behoorlijke kans dat het over twee poorten gaat.

[MaanBanaan]

Cisco 6500 dus? Cool. Dan weet je, waarvoor je betaalt.

[MagicTempest]

Even terugkomend op het upgradeverhaal, wij hebben stacks van h3c s5500's en die zijn prima te upgraden zonder de config kwijt te raken. Je kan de upgrade van de bootrom en de firmware gemakkelijk op de eerste switch doen en tijdens de reboot zorgt de switch er zelf voor dat het ook op de andere stackmembers wordt geplaatst. Duurt allemaal wel even voordat je switch weer operationeel is, dus dit moet je niet overdag doen

Ik neem momenteel even voor het gemak aan dat de h3c s5500 switches dezelfde zijn als de 3com 5500.

Overigens is het voor een gemeente misschien nog wel een idee om via ebay twee 6500's te kopen. Zo duur zijn ze daar niet meer. Ik ken internetproviders die hun core-apparatuur op die manier kochten.