Trunking over Koper of Fiber?

[Madmama]

Ik ben bezig met een vervangingsplan voor onze huidige switches

Huidige setup:
Core stack: 3x 3750G ( 24x1gbit + 4xSFP per switch)
Stack 1: 6x 3750 (48x 100mbit + 4x SFP per switch)
Stack 2: 5x 3750 (48x 100mbit + 4x SFP per switch) + 1x 3750E (24x 1gbit + 4x SFP)
Stack 3: 5x 3750 (48x 100mbit + 4x SFP per switch) + 1x 3750E (24x 1gbit + 4x SFP)

Alle stacks zijn aangesloten met 4x Fiber naar de core. Op de core heb ik totaal 15 UTP poorten in gebruik (alle SFP's zijn gevuld), de verwachting is niet dat dit zal groeien de komende tijd. Alles bij elkaar opgeteld heb ik dus een hele berg poorten op de core die ik niet gebruik, ik heb 3 core switches omdat ik de SFP's nodig heb voor de trunks.


Het vervangingsplan heeft de volgende setup:
Core stack: 2x 3850 (24x 1gbit + waar ik later eventueel een C3850-NM-2-10G (2x 1gbit + 2x 10gbit) in kan schuiven)
Stack 1: 6x 2960x (48x 1gbit + 2x SFP+ )
Stack 2: 8x 2960x (48x 1gbit + 2x SFP+ )
Stack 3 is niet meer nodig door een uitbreiding van Stack2, eventueel kan Stack 1 ook nog uitgebreid worden.

Op dit moment is er geen behoefte om stacks met 10gbit met elkaar te verbinden.

Omdat de serverruimte ook verbouwd gaat worden moet alle fiber er uit en volledig vervangen worden. Maar wat is eigenlijk de toegevoegde waarde nog van Fiber?

De 2de stack staat op 50 meter afstand, het is goedkoper voor ons om 4x cat6a neer te leggen (zelfs 8x cat6a is de helft van de kosten) van de serverruimte naar de andere patch ruimte.

Ik heb genoeg poorten vrij op de core om beide stacks te verbinden met 8x 1gbit koper. Eventueel zou ik later altijd nog kunnen overstappen op 2x 10gbit (bestaan er eigen 10gbase SFP+ voor ethernet?)

De vraag is dus, als je met 1gbit trunks kunt connecten, is koper dan niet een goedkoper alternatief welke net zo stabiel is?

[CyBeR]

Glasvezel biedt hogere bandbreedte dan koper (10 gig? Leuk. Glas doet 100 gig) en dus meer toekomstvastheid voor de toepassing van inter-switch connectiviteit. Bovendien is het een galvanische scheider zodat een electrisch probleem aan de ene kant van 't gebouw niet ook je switches aan de andere kant fuckt.

Als laatste: 10x 1GbE in een aggregation (een trunk is iets anders), is niet hetzelfde als 10GbE.

[Dafjedavid]

Eens met Cyber.

Los van je galvanische scheiding houd ik van fiber vanwege cablemanagement (beter weg te werken), en je kan inderdaad hogere snelheden halen. Hangt wel van de kwaliteit fiber af. Met Single-mode kan je de meeste snelheden tot 100G wel halen, met Multimode is dat een ander geval. Zorg ervoor dat je minimaal OM3 Multi-mode laat leggen als je 10G wil doen in de toekomst. Houd bij de keuzen van het type fiber rekening met de afstand die je moet overbruggen....

Zie Wikipedia: Multi-mode optical fiber voor de verschillen.

In een Port-channel kun je niet meer dan 8 interfaces kwijt, dus 8 x 1 gbit = 8 gbit en harder zal t niet gaan.

[ Voor 5% gewijzigd door Dafjedavid op 14-07-2016 22:53 ]

[Barreljan]

Dafjedavid schreef op donderdag 14 juli 2016 @ 22:52:
Eens met Cyber.
In een Port-channel kun je niet meer dan 8 interfaces kwijt, dus 8 x 1 gbit = 8 gbit en harder zal t niet gaan.

Ho dat klopt niet. De snelheid blijft max 1 gbit alleen je kan meerdere flows hebben van 1 gbit (dus bandbreedte), zoals Cyber ook aangaf. Naast dat, redundantie.

[Dafjedavid]

klopt.... was niet helemaal wakker gisteren

[knutsel smurf]

Ik ben zowiezo voorstander van glas vanwegen de hierboven al genoemde voordelen. Daarbij wat nu goedkoper is hoeft over een paar jaar niet zo te zijn.

Ik weet niet precies hoe het bij Cisco werkt. Maar in het geval van Alcatel-Lucent zouden we MC-LAG toepassen waardoor je wel beide links tegelijk kan gebruiken zonder beperkingen van verschillende flows.

Overigens bestaan 10GbaseT SFP's niet, je zou wel kunnen werken met switches die 10GB koper poorten standaard hebben.

[CyBeR]

knutsel smurf schreef op maandag 18 juli 2016 @ 15:13:
Overigens bestaan 10GbaseT SFP's niet

Ze zijn er wel maar je moet dan kiezen tussen een lagere maximale afstand (30m) of zo'n situatie:



Aangezien sfp+ niet genoeg power biedt om normaal 10gbase-t te doen heeft dat dus externe power nodig.

[knutsel smurf]

Interessant heb je een link waar ik die dingen kan kopen?

[CyBeR]

HPE part no. 813874-B21 voor die 30m variant.

[knutsel smurf]

Heb er nog geen in het veld gezien maar dat kan natuurlijk nog komen. Zou iig niet mijn bekabeling hierop baseren.

[CyBeR]

Zeker niet. Sowieso zie ik copper sfp's als "kan niet anders"-mogelijkheid.

[Olaf van der Spek]

Barreljan schreef op vrijdag 15 juli 2016 @ 09:10:
[...]


Ho dat klopt niet. De snelheid blijft max 1 gbit alleen je kan meerdere flows hebben van 1 gbit (dus bandbreedte),

Eh, waarom dat? En wat is hier de definitie van een flow?

[Mr_gadget]

Meerdere verbindingen (de flows) van 1 gbit. Maar geen een flow van 10 gbit. Met de meeste protocollen zal je een bestand maar op 1 gbit snelheid kunnen versturen (maar wel 10 keer parallel). Het voordeel van 1 10 gbit verbinding is dat je dan wel 10 gbit snelheid hebt voor een bestand.

[ Voor 5% gewijzigd door Mr_gadget op 24-07-2016 00:13 ]

[knutsel smurf]

De wijze waarop tunking protocol is opgezet/gedefineerd betekent dat elke flow geinitieerd over een bepaalde L2 link ook terug moet over die specifieke L2 link. Als je meerdere services hebt of meerdere flows tegelijk waarbij je geen eisen stelt aan de snelheid dan is dit geen probleem.

Mocht je bijvoorbeeld een groot bestand of een volledige VM willen verplaatsen binnen een zo`n kort mogelijke tijd dan kan het wel een probleem zijn. Je moet er dan gewoon meer bandbreedte tegen aan gooien.

Er zijn tegenwoordig overigens protocollen die dit probleem verhelpen, SPB is 1 van die protocollen. Maar dat support Cisco niet.

[Olaf van der Spek]

Ik begrijp er niks van. Voor beide switches maakt het toch niks uit over welke link in zo'n port groep een frame / packet wordt verzonden?

Of is het probleem dat packets binnen een 'flow' niet herordend mogen worden?

[CyBeR]

Olaf van der Spek schreef op maandag 25 juli 2016 @ 14:09:
Of is het probleem dat packets binnen een 'flow' niet herordend mogen worden?

Ja.

[Olaf van der Spek]

CyBeR schreef op maandag 25 juli 2016 @ 14:11:
[...]


Ja.

TCP en UDP kunnen prima omgaan met herordening en IP garandeert het ook niet.. wat is nog wel afhankelijk van die garantie?

[CyBeR]

Olaf van der Spek schreef op maandag 25 juli 2016 @ 14:19:
[...]

TCP en UDP kunnen prima omgaan met herordening

Dat is de theorie ja. De praktijk is weerbarstiger.

[Olaf van der Spek]

OK, en hoe houdt port aggregation / trunking hier rekening mee? Een tabel met alle flows bijhouden lijkt mij onbegonnen werk.

Sowieso hebben de hosts van Madmama volgens mij 'slechts' 1 gbit links, dus in welk opzicht is een 10x 1 link dan nog minder dan een 1x 10 link?

[ Voor 37% gewijzigd door Olaf van der Spek op 25-07-2016 18:07 ]

[CyBeR]

Olaf van der Spek schreef op maandag 25 juli 2016 @ 18:02:
OK, en hoe houdt port aggregation / trunking hier rekening mee? Een tabel met alle flows bijhouden lijkt mij onbegonnen werk.

Sowieso hebben de hosts van Madmama volgens mij 'slechts' 1 gbit links, dus in welk opzicht is een 10x 1 link dan nog minder dan een 1x 10 link?

Probeer je hier nou een opleiding bij me vandaan te peuteren?

Ze doen dat op basis van src/dest mac of src/dest ip of src/dest port of een combinatie daarvan. En idealiter komen twee verschillende flows dan op een verschillende link maar dat is geen gegeven.