Configureren trunk setup zonder loop te creeren

[excaliburvii]

Misschien ben ik hier compleet aan het verkeerder adres, if so dan hoor ik dat graag.

Momenteel ben ik bezig het het vernieuwen van de IT bij mijn werkgever (fabriek). men wou graag een zeer betrouwbare netwerkomgeving voor een geringe prijs.

Ik heb gekozen om een setup te bouwen met 2 HPE 1420 core switches en 2 HPE Aruba 2540 POE switches.
De bedoeling is om de 2 Aruba switches dmv glasvezel te verbinden naar de 1420 switches. vanuit elke aruba gaat er een vezel naar een 1420 waardoor er een soort van kruisverbinding ontstaat.
als ik dit zonder config doe ontstaat er een loop (logisch). daarom wil ik met trunk verbinding gaan werken. de bedoeling is om de 2 uplink vanuit de aruba als trunk in te stellen. maar omdat ze allebei naar een andere switch gaan vraag ik mij af of dit gaat werken. de 1420 onderling verbinden met elkaar zou naar mijn weten sowiezo een loop creeren.

zowel de servers, als de nas zitten op beide coreswitches tegelijkertijd aangesloten. mocht er een switch uitvallen zou er zonder problemen doorgewerkt moeten kunnen worden.

voor verduidelijking heb ik een kleine diagram bijgevoegd:
https://lhoornweg.stackstorage.com/s/jZS1yhplzAnWeMa

Is het uberhaupt mogelijk om de gewenste situatie te creëren met 2 unmanaged switches?
indien ja, is de geschetste opzet mogelijk?

Via vmware heb ik een failover gebouwd zodat wanneer 1 van de coreswitches uitvalt alles over gaat naar de andere coreswitch

[SambalBij]

Met een unmanaged switch zul je geen etherchannel/LACP kunnen bouwen.

(Om de verwarring even voor te zijn; HPE gebruikt de term 'trunk' voor wat de rest van de wereld een etherchannel of link aggregation (LACP) noemt, nl. het bundelen van meerdere kabels tot een verbinding. In de rest van de wereld betekend een 'trunk' het versturen van meerdere VLAN's over een link)

Je zou mogelijk wat kunnen bereiken met STP. Ook dat is niet ideaal met unmanaged switches, maar je bereikt waarschijnlijk wel dat de Aruba switches zelf regelen welke poorten er dicht gehouden moeten worden om loops te voorkomen. (Ik zou dan wel die twee Aruba's ook nog onderling linken)

[Voor 6% gewijzigd door SambalBij op 10-10-2018 14:11]

[ralpje]

Zijn de twee coreswitches gestacked, of zijn het gewoon losse switches?
Als ze gestacked zijn, kun je inderdaad een trunk bouwen over beide coreswitches en die verbinden met een access-switch. Voor de tweede access-switch maak je dan een tweede trunk.
Als de coreswitches niet gestacked zijn, zou je met spanning tree (STP) ervoor kunnen zorgen dat loops voorkomen worden. Als je dat juist inricht is er echter steeds maar één uplink naar de access-switch actief en wordt de andere automatisch uitgeschakeld. Je hebt dan dus effectief minder bandbreedte.

[DukeBox]

Daarnaast kan je een trunk niet opsplitsen. Ook al heeft HP zoiets als een virtual trunk.
Je zal je moeten verdiepen in spanning tree, daarmee los je je redundancy issues op.

[chupkes]

Nee, unmanaged switches kun je hier niet voor inzetten. Je kunt geen trunk aanmaken en ze ondersteunen geen spanning tree, dus creëer je inderdaad een loop.

Kijk 1 stapje hoger naar de 18xx-series, die doen in ieder geval spanning tree. Of ze trunk/etherchannel doen weet ik niet zeker, maar dat heb je met wat Google-werk zo gevonden. Afhankelijk van je eisen qua bandbreedte moet je wellicht meer geld uitgeven voor switches die trunk/etherchannel ondersteunen, of settelen voor de bandbreedte van één link.

Spanning-tree is met zo'n kleine omgeving niet spannend/moeilijk. Gewoon inschakelen (RSTP of MST) en je core switches de hoogste prioriteit (=0)geven.

[BazzH]

Wel lekker kort, die opdracht:

"men wou graag een zeer betrouwbare netwerkomgeving voor een geringe prijs"

Die horen we wel vaker.
Zoals hierboven al gezegd, kan dat niet met unmanaged switches en eigenlijk wil je dan die 1420 "core" switches vervangen door een stack van 2 managed switches. De prijs wordt wel iets minder gering.

(Wel lekker betaalbaar trouwens: 190 euro inc. BTW per core switch.)

[Voor 9% gewijzigd door BazzH op 10-10-2018 14:34]

[excaliburvii]

Wow, dank voor jullie supersnelle reacties!

Ik was er helaas al bang voor dit dit niet ging werken.
Brandbreedte speelt geen rol, de switches zijn verbonden met een 10Gbe verbinding. 20Gbe zou leuk zijn, maar compleet overkill in deze omgeving. het gaat mij er meer om dat wanneer een van de coreswitches uitvalt ik niet als een gek kabels moet gaan ompluggen om de boel weer in de lucht te krijgen.
Helaas is alles al aangeschaft en ik heb niet goed opgelet bij goedkeuring van de offerte.

voor mijn eigen beeldvorming, wat zou er gebeuren als ik management tree aanzet op de aruba's, deze onderling met elkaar verbind en deze naar beide 1420's verbind? de onderlingen verbinding tussen de 1420's komt dat te vervallen.

[Equator]

het gaat mij er meer om dat wanneer een van de coreswitches uitvalt ik niet als een gek kabels moet gaan ompluggen om de boel weer in de lucht te krijgen.

Waar je naar toe zou willen is een setup als deze (even quick 'n dirty met Visio 2010 ) Daarmee kan er 1 core switch uitvallen, en een leaf, en dan is je server nog steeds verbonden



Dit vereist echter wat zaken als LACP (EtherChannel), Trunking (multiple VLAN's over 1 logische verbinding) mogelijk een Next Hop Redundancy Protocol (VRRP/HSRP) en of ondersteuning voor Spanning Tree Protocol (STP) (mocht je core geen stacking o.i.d. ondersteunen)

voor mijn eigen beeldvorming, wat zou er gebeuren als ik management tree aanzet op de aruba's, deze onderling met elkaar verbind en deze naar beide 1420's verbind? de onderlingen verbinding tussen de 1420's komt dat te vervallen.

Dan krijg je in wezen deze opstelling: (wederom quick 'n dirty)
of
Op L3 kan je daarmee wel enige redundantie maken (mits de switches een routing protocol als RIPv2, OSPF of BGP ondersteunen), maar op L2 niet (en daarbij laat ik eventuele overlay protocollen even buiten beschouwing). Misschien dat je met wat knutselwerk een werkende oplossing krijgt, maar daar zou ik niet op aansturen.

edit: nog een toevoeging

Daarmee heb je twee nutteloze core switches. Maar kan je wel L2 redundantie bieden.

Probeer gewoon met je manager te overleggen, geef aan dat je een bestelfout hebt gemaakt en probeer de twee HPE switches te retourneren en vervangen met een instap model wat je kan stacken. Dan heb je 1 logische switch i.p.v. 2 losse switches, heb je niet direct noodzaak voor STP, en kan je op L2 een redundant pad bieden.

[Voor 10% gewijzigd door Equator op 11-10-2018 09:56]

[drie van acht]

Even een puntje van orde: "Trunk" is een telecomterm. Computernetwerkers zijn het niet eens wat het moet betekenen. Of je nu link aggregation (vergroten bandbreedte) of VLAN tagging (meerdere VLANs op een lijn) bedoelt, praat maar niet over trunking, want of we nu hpe of cisco gelijk geven, het blijft verwarrend.

In het TS-plaatje gaat het over nog iets anders: Redundancy. Als de ene switch (of poort) uitvalt doet de andere nog wat. Je krijgt namelijk niet twee keer de linksnelheid als je zo'n kruislingse setup neerzet, ethernet trekt dat niet. Meer nog dan dat link aggregation ook al niet een simpele vermenigvuldiging oplevert, dat heeft voeten in de aarde. Je gaat hiervoor STP oid nodig hebben en dat betekent dat de "extra" verbindingen als hot spare dienst doen, maar dus niet normaliter verkeer verschepen.

En voor zulke truuks wil je managed switches. Je kan wel gaan proberen om met half managed en half unmanaged te gaan werken maar waarom jezelf op achterstand zetten? Je wil op z'n minst kunnen zien wat de status van je poortjes is; een 1420 zal gewoon doodleuk een loop maken en het niet doorhebben. Verder zul je wat huiswerk moeten doen, uitzoeken wat wat is en hoe je het inzet. Niet om flauw te doen: Als je als netwerkbouwer dit soort setups wil bouwen --en troubleshooten-- moet je weten hoe dan.

[Equator]

@drie van acht
Trunking in netwerken is in mijn ogen toch echt alleen meerdere VLAN's over 1 verbinding. Een EtherChannel is een combinatie van 2, 4 of 8 lijnen tot een enkele logisch verbinding (middels LACP bijvoorbeeld)

Grappig genoeg is het bundelen van FibreChannel wel weer trunking (maar dat kan ook weer merkafhankelijk zijn)

---

Belangrijk is wel: Als je een redundante setup wilt maken, pak dan managed switches!

[Ascension]

Overigens zijn die 2540 switches prima. Die zijn managed en hebben ondersteuning voor LACP en STP.

Die HPE 1420's kan je beter vergeten, dat zijn geen core switches. Zijn unmanaged, doen geen STP en LACP.

Als core kies je typisch een managed switch uit met voldoende SFP+-poorten zodat je het netwerk eenvoudig uit kan breiden en bijvoorbeeld een switch die je kan stacken zodat je redundantie op device niveau hebt.

Zou je bijna adviseren om er even door een expert naar te laten kijken. Kan best zijn dat je nu bepaalde requirements over het hoofd ziet en straks met oplossing zit die niet doet wat je wil.

[drie van acht]

Equator schreef op donderdag 11 oktober 2018 @ 09:55:
@drie van acht
Trunking in netwerken is in mijn ogen toch echt alleen meerdere VLAN's over 1 verbinding.

In jouw ogen, prima. Maar het punt was dus dat hier geen eenduidige consensus over bestaat, en dat dit gekibbel oplevert. Je kan natuurlijk proberen om het over "vlan trunk" en "etherchannel trunk" te hebben om eea te verduidelijken, maar ook dat is niet echt handig. Dus ik zeg, doe maar niet, laten we deze geleende telecomterm lekker bij de telecomjongens en heb het over vlan tagging danwel link aggregation. Of zoals hier, redundancy.

Want er staat dan wel "trunk" in de titel maar er is weinig trunk aan de schets te bekennen. Wat indirect een aanwijzing is waarom TS hulp nodig heeft te zien waarom wat'ie wil niet gaat lukken met wat'ie heeft.

Belangrijk is wel: Als je een redundante setup wilt maken, pak dan managed switches!

Dat toch zeker.

Ook dat alleen is niet voldoende, trouwens. Ethernet is een beetje een lappendeken van net-iets-te-simpele aanpakken en daar dan weer oplossingen voor. Je moet dus nog steeds heel goed weten welke features je van je switches nodig hebt.

Best kans dat "webmanaged" of "smart managed" budgetspul gewoon niet voldoende gaat zijn, en dan zijn je switches ineens zo goedkoop niet meer. Of je moet voor tweedehands gaan en zelf spares aanhouden.

[kosz]

De 2540 kunnen in een virtual stack gebouwd worden, dit is alleen management en niet te verwarren tussen VSF of backplane-stacking. De 1420 is een unmanaged switch, daar kan je verder niet veel mee, dus daar iets redundants mee bouwen, nee... (PS bestaat jullie netwerk uit 1 plat vlan ?)
De 2540 is meer geschikt als access switch, dus in de plaats van de 1420 in je plaatje. Neem dan als Core de 2930F welke middels VSF is te stacken, zo kan je het bouwen zoals in je plaatje, vanuit elke core een uplink naar je switches middels LACP en klaar. In je plaatje moet je dan wel ff de verbinding tussen de 2 access switches (1420) weghalen, dat heeft geen toegevoegde waarde.....