Strategie voor verbinden switches

[Qlimaxxx]

Hoi mede-tweakers,

Bij een familielid, die tevens mijn klant is, ben ik bezig met het moderniseren van het bedrijfsnetwerk. Aangezien dit netwerk wat uitgebreider is dan het netwerk van mijn andere klanten kom ik voor nieuwe uitdagingen te staan. Gelukkig krijg ik de tijd en ruimte om te leren. Het leek me daarom ook leuk om dit eens voor te leggen aan andere Tweakers.

De huidige situatie kort uitgelegd:
- KPN FttO 10/10
- Een partij dure en verouderde Cisco routers(waarvan tevens het wachtwoord niet bekend is)
- Een fysiek gescheiden VOIP netwerkje(via DSL)
- Nog wat overbodige zaken
- Vrijwel nergens Gigabit, ook niet tussen switches en zelfs niet tussen switch en servers
- 3 servers(1 voor AD en Exchange, 1 voor het oude softwarepakket, 1 voor het nieuwe softwarepakket)
- 1 NAS voor backup en filesharing

Het zijn 3 verschillende winkels die 1 netwerk delen. Daarvan zijn 2 naast elkaar gelegen en is de 3e 2 panden verderop.

Op dit moment heb ik alles switches vervangen door gigabit apparatuur. De router, servers en een switch bevinden zich in de serverruimte. Vanaf daar gaan er 3 UTP-kabels naar de meterkast. Vanaf deze meterkast zijn er 2 UTP-kabels richting een patchkast in de 3e winkel(minder dan 100 meter). Vanaf serverruimte is er 1 voor VOIP(aparte switch), 1 voor de switch in de 3e winkel(doorgepatcht) en 1 naar de switch in de meterkast(hier zit een patchpaneel). Ook is er een switch voor het fysiek gescheiden VOIP netwerk in de 3e winkel.

Dit is de huidige situatie:


Ik ben van plan om de verbinding tussen de 1e switch en de switch in het 3e pand via de switch in de meterkast te laten verlopen. Vervolgens wil ik een LAG maken tussen de switch in de serverruimte en de switch in de meterkast. Is dit verstandig of niet?

Dit is dan de beoogde situatie:


Mocht het toepassen van een LAG verstandig zijn, is het dan misschien ook een goed idee om een LAG te creëren tussen de meterkast en het 3e pand? En dan vervolgens de VOIP via een VLAN te laten verlopen tussen de meterkast en het 3e pand? Ik kan me voorstellen dat dit met VOIP minder verstandig is om te doen.

Deze situatie bijvoorbeeld:


Ik ben benieuwd naar jullie mening en feedback!

Edit:
Even vergeten te vermelden: binnen nu en 1 maand komt er FttO van een andere provider met een snelheid van 100/100. Op zich niet heel belangrijk voor de vragen die ik gesteld heb. Die zijn meer bedoeld om het LAN te optimaliseren. Zo krijgen sommige servers ook een LAG(o.a. de NAS).

Edit2: De Edgerouter 6P in de schematische weergave is nog niet geplaatst, maar zal in gebruik worden genomen wanneer er van ISP geswitcht wordt.

[ Voor 7% gewijzigd door Qlimaxxx op 16-12-2018 22:40 ]

[Verwijderd]

Zonder al te inhoudelijk te worden, het is nog vroeg, een paar opmerkingen.

Qlimaxxx schreef op zondag 16 december 2018 @ 22:35:
De huidige situatie kort uitgelegd:
- KPN FttO 10/10

Is dit voldoende, en als niet waarom niet en hoeveel heb je wel nodig?

- Een partij dure en verouderde Cisco routers(waarvan tevens het wachtwoord niet bekend is)

Een password reset is zo gebeurd, ben je alleen wel de configuratie kwijt.

"Wachtwoord niet bekend" betekent "site documentatie niet op orde". Dat moet de top van je TO DO lijstje zijn: Niet alleen nieuwe site documentatie opzetten, maar ook zorgen dat er over tien jaar nog steeds recente en relevante documentatie beschikbaar is.

Dat cisco meuk duur is, tsja, maar de investering is gedaan. Kan de hardware fysiek aan wat ervan verwacht wordt? De rest van je ontwerp leest namelijk als een excuus om ubiquiti spul in te kunnen zetten. Niets mis met die hardware maar het excuus is het pijnpunt. Je hebt hier een betere onderbouwing nodig dan "oud" om te overtuigen. Netwerkapparatuur is over het algemeen suffige CPUs aangekleed met ASICs precies omdat het om die ene taak gaat, die met hoge betrouwbaarheid lang vervuld moet kunnen worden.

- Een fysiek gescheiden VOIP netwerkje(via DSL)

Als je dat gaat ont-scheiden is het tijd om je over QoS in te lezen.

- Nog wat overbodige zaken

Hoe zeker weet je dat die overbodige zaken ook overbodig zijn? Trek ze nu los en kijk hoe snel er mensen komen klagen.

- Vrijwel nergens Gigabit, ook niet tussen switches en zelfs niet tussen switch en servers

Heb je enig idee hoeveel verkeer er verstookt wordt en in hoeverre dat problemen oplevert in het netwerk? Heb je bijvoorbeeld traffic graphs van je backbone?

Ik ben van plan om de verbinding tussen de 1e switch en de switch in het 3e pand via de switch in de meterkast te laten verlopen. Vervolgens wil ik een LAG maken tussen de switch in de serverruimte en de switch in de meterkast. Is dit verstandig of niet?

Je hebt dus een verbinding over drie switches. Dat kan. Wat zijn de voors en tegens waar je mee worstelt?

Mocht het toepassen van een LAG verstandig zijn, is het dan misschien ook een goed idee om een LAG te creëren tussen de meterkast en het 3e pand? En dan vervolgens de VOIP via een VLAN te laten verlopen tussen de meterkast en het 3e pand? Ik kan me voorstellen dat dit met VOIP minder verstandig is om te doen.

Link aggregation is geen magische bandbreedteverdubbelaar, dus als je niet weet hoe het wel werkt, lees je in.

Het is meestal een beter idee om met je ene link stapje hoger te gaan. Maar dat heeft alleen maar zin als het noodzakelijk is qua bandbreedte.

Voor LAG geldt hetzelfde plus dat er voldoende "houvast" in de switches moet zijn om de datastromen over de verschillende pijpen te verdelen. Het is dus een lapmiddel met haken en ogen.

Deze situatie bijvoorbeeld:
[Afbeelding]

Waarom denk je dat dit een beter idee is dan de VoIP-ISL direct te leggen?

Als je toch wil integreren, waarom hou je de aparte switches bij, en stop je niet alle VoIP op eigen VLAN-poortjes in de gewone switches?

Hoe bedrijfscritisch is VoIP, kan het er een dag uitvliegen omdat bijvoorbeeld een switch kapot gaat en er een nieuwe managed switch besteld moet worden?

En zo kun je vast nog wel meer "was als...?" vragen bedenken. Wat niet wil zeggen dat je je ook tegen alle eventualiteiten indekt. Je moet ze alleen wel overwogen hebben en een besluit genomen of en zo ja hoe je je in wil dekken, en wat dat mag kosten.

[Frogmen]

Paar opmerkingen ter aanvulling van bovenstaande. In dien mogelijk zou ik kiezen voor een glas verbinding tussen de panden, Dit om een galvanische scheiding tussen beiden te maken. Maar hiervoor moet moet de situatie het belang onderbouwen. En ik zou de NAS die voor backup gebruikt wordt in het andere pand plaatsen zodanig dat er een scheiding van locatie is tussen backup en productie. Anders heb je bij brand nog steeds niets. Ik lees verder niets over wifi dus waarom Unifi? Verder zou ik zeker wel met VLAN's gaan werken.

[Qlimaxxx]

Verwijderd schreef op maandag 17 december 2018 @ 09:05:
Is dit voldoende, en als niet waarom niet en hoeveel heb je wel nodig?

Er komt een nieuwe provider met 100/100. Dit scheelt 90 euro per maand, dat is de voornaamste reden. Ze hebben ook 50/50, maar dat is maar een tientje per maand goedkoper. Ook m.b.t. offsite backup is die upload natuurlijk prettig.

Een password reset is zo gebeurd, ben je alleen wel de configuratie kwijt.

"Wachtwoord niet bekend" betekent "site documentatie niet op orde". Dat moet de top van je TO DO lijstje zijn: Niet alleen nieuwe site documentatie opzetten, maar ook zorgen dat er over tien jaar nog steeds recente en relevante documentatie beschikbaar is.

Dat cisco meuk duur is, tsja, maar de investering is gedaan. Kan de hardware fysiek aan wat ervan verwacht wordt? De rest van je ontwerp leest namelijk als een excuus om ubiquiti spul in te kunnen zetten. Niets mis met die hardware maar het excuus is het pijnpunt. Je hebt hier een betere onderbouwing nodig dan "oud" om te overtuigen. Netwerkapparatuur is over het algemeen suffige CPUs aangekleed met ASICs precies omdat het om die ene taak gaat, die met hoge betrouwbaarheid lang vervuld moet kunnen worden.

De documentatie is deels aanwezig, echter klopt het vermeldde wachtwoord niet. Dit is door KPN achtergelaten, maar KPN heeft nogal wat steken laten vallen. De 2 Cisco routers zijn niet voorzien van Gigabit poorten. Daarnaast zit ik er niet op te wachten om puur voor deze ene klus Cisco te leren. Het is gewoon makkelijker om met EdgeOS te werken, gezien ik hier al bekend mee ben. Ik kan dan ook gewoon de backup vanuit UNMS terugzetten als er een hardware swap moet plaatsvinden.

Als je dat gaat ont-scheiden is het tijd om je over QoS in te lezen.

Daar ben ik ook al mee bezig. Het is me echter nog niet gelukt om goede topics te vinden waar deze specifieke situatie wordt besproken. Daarnaast lees ik veelal dat op switch niveau QoS niet zo ontzettend belangrijk is, maar ik weet natuurlijk niet of dat toepasbaar is op deze situatie.

Hoe zeker weet je dat die overbodige zaken ook overbodig zijn? Trek ze nu los en kijk hoe snel er mensen komen klagen.

Omdat er 2 Cisco routers staan, 1 zou genoeg zijn. Daarnaast is er nog een router die een VPN verbinding heeft met een Duits bedrijf dat het vorige kassasysteem onderhield, deze is obsoleet. Verder is er een Draytek router, enkel en alleen als VPN server. De functies verdwijnen dus, of zijn allemaal in te vullen door 1 fysiek apparaat, in dit geval de Edgerouter.

Heb je enig idee hoeveel verkeer er verstookt wordt en in hoeverre dat problemen oplevert in het netwerk? Heb je bijvoorbeeld traffic graphs van je backbone?

Je hebt dus een verbinding over drie switches. Dat kan. Wat zijn de voors en tegens waar je mee worstelt?

Dat heb ik nog niet precies in kaart gebracht. Ik was van plan LAG's vooral in te zetten waar er baat is bij meerdere clients. Bijvoorbeeld tussen NAS en switch(zodat backup van server en file services beiden op volle snelheid kunnen). Daarnaast tussen grote switches, zodat LAN verkeer op Gigabit kan plaatsvinden en er tegelijkertijd ook de volle internetsnelheid benut kan worden. Misschien overschat ik de voordelen.

Weegt het voordeel van LAG zwaarder of is het beter om een gescheiden VOIP netwerk te houden.

Link aggregation is geen magische bandbreedteverdubbelaar, dus als je niet weet hoe het wel werkt, lees je in.

Dat heb ik ook zeker gedaan. Echter is deze situatie minder recht toe recht aan en heb ik niet de info kunnen vinden die ik zoek.

Het is meestal een beter idee om met je ene link stapje hoger te gaan. Maar dat heeft alleen maar zin als het noodzakelijk is qua bandbreedte.

Voor LAG geldt hetzelfde plus dat er voldoende "houvast" in de switches moet zijn om de datastromen over de verschillende pijpen te verdelen. Het is dus een lapmiddel met haken en ogen.

Waarom denk je dat dit een beter idee is dan de VoIP-ISL direct te leggen?

Als je toch wil integreren, waarom hou je de aparte switches bij, en stop je niet alle VoIP op eigen VLAN-poortjes in de gewone switches?

Hoe bedrijfscritisch is VoIP, kan het er een dag uitvliegen omdat bijvoorbeeld een switch kapot gaat en er een nieuwe managed switch besteld moet worden?

Het is best wel bedrijfskritisch. Als er echter geen internet is, of zelfs geen intern netwerk richting servers, is het bedrijf sowieso al beperkt in de mogelijkheden. Downtime dient zoveel mogelijk voorkomen te worden, echter niet tegen alle kosten. Een switch is binnen 24 uur wel te vervangen. Zeker met een oplossing als UniFi of UNMS.

Door op 2 locaties om te patchen is het natuurlijk simpel om tijdelijk de huidige situatie m.b.t. VOIP te herstellen. Juist vanwege slechte ervaringen met 1 fysiek netwerk is er gekozen voor volledig gescheiden structuur. Ik sluit niet uit dat dit in de toekomst weer gemigreerd wordt.

En zo kun je vast nog wel meer "was als...?" vragen bedenken. Wat niet wil zeggen dat je je ook tegen alle eventualiteiten indekt. Je moet ze alleen wel overwogen hebben en een besluit genomen of en zo ja hoe je je in wil dekken, en wat dat mag kosten.

Dat is inderdaad het geval. Echter is mijn doel niet om alles tot in de puntjes aan te pakken. Bepaalde zaken worden vervangen, vooral op de plekken waar het belangrijk is. 25 computers die over 100Mbit met servers communiceren is natuurlijk niet ideaal.

Paar opmerkingen ter aanvulling van bovenstaande. In dien mogelijk zou ik kiezen voor een glas verbinding tussen de panden, Dit om een galvanische scheiding tussen beiden te maken. Maar hiervoor moet moet de situatie het belang onderbouwen. En ik zou de NAS die voor backup gebruikt wordt in het andere pand plaatsen zodanig dat er een scheiding van locatie is tussen backup en productie. Anders heb je bij brand nog steeds niets. Ik lees verder niets over wifi dus waarom Unifi? Verder zou ik zeker wel met VLAN's gaan werken.

Als er nog geen netwerk lag zou er uiteraard glas komen. Behalve de galvanische scheiding zal het m.b.t. performance geen invloed hebben. Geen van de switches heeft beschikking over 10GbE. De UTP-kabels liggen er al. Ik probeer vooral met de huidige infrastructuur en wat nieuwe apparatuur de performance te optimaliseren.

De NAS doet een offsite backup naar de NAS in de meterkast van de eigenaar.

Wifi is uiteraard ook UniFi, vandaar de keuze van UniFi switches i.p.v. EdgeSwitch. Maar zoals gezegd, waar ik twijfel over de aanpak is de kern van het netwerk. Of aan de rand de clients nou draadloos of bedraad verbinden maakt voor die vraagstelling niet zoveel uit. Dat zal overigens voornamelijk bedraad zijn. Omdat er geen of amper routing zal zijn tussen VLAN's is een L3 switch ook niet noodzakelijk. Gezien de beperkte integratie van EdgeSwitches met UNMS heeft UniFi ook mijn voorkeur, simpelweg betere remote management.