Netwerk Design advies gevraagd

[DutchITMaster]

Goedemiddag Tweakers.

Ik ben bezig met een netwerk design waar ik met vrij basic netwerkapparatuur en beperkte glasvezelparen een groot netwerk moet opzetten.

de grootste site betreft 58 sites op 1 terrein, voor zover nu bekend wordt iedere switch doorgekoppeld middels een unmanaged switch Fiber in > fiber out naar volgende switch

Nu heb ik een design gemaakt waar ik vanuit ga dat ik een gedeelte kan daisychainen en toch nog beperkt aders hoef bij te laten lassen. Ik verwacht in dit design tot 42 switches te kunnen gaan

Zie ik in dit design iets over het hoofd?

[ Voor 4% gewijzigd door DutchITMaster op 22-04-2018 17:32 ]

[Equator]

Aanname, alles is op Laag 2 aangesloten. Je maakt zo wel enorme netwerkloops, dus zal je met STP aan de gang moeten. Of je links van de distributie Switches naar de andere switches zijn laag 3.

Heb je niet de mogelijkheid om al de Switches aan te sluiten op je distributie Switches? Of moet je dan te veel glas trekken wat niet kan of gewoonweg te duur is?

In at geval zou ik die sets met Switches inderdaad op L3 aansluiten op je distributie Switches. Maar ik weet niet of je Switches dat ondersteunen.

Hoe ziet je L2 design er uit?

[ Voor 32% gewijzigd door Equator op 22-04-2018 18:19 ]

[ik222]

Ik zou dit niet doen zo met unmanaged switches. Ja in theorie blijft je wel loop vrij als de BPDU's er gewoon er doorheen gaan (distributie switches zullen een link blocking zetten) of de koppelingen op de distributieswitches L3 zijn. Maar in een productie omgeving moet je dit echt niet willen. Wat gebeurt er bijvoorbeeld als er per ongeluk een extra verbinding tussen 2 unmanaged switches komt denk je?

Nog even los van het feit dat ik spanning tree eigenlijk liever helemaal niet meer zou gebruiken voor redundante paden te kunnen maken in 2018. Er zijn echt betere alternatieven.

Ik zou als je op laag2 wilt blijven zorgen dat je LACP kunt draaien over de 2 distributie switches heen. En dan als access switches netjes managed switches die een LACP hebben over één link naar elke distributie switch.

En anders kijken naar laag3 met eventueel daaroverheen een laag2 overlay.

[ Voor 3% gewijzigd door ik222 op 22-04-2018 18:41 ]

[DutchITMaster]

Ter informatie er zal geen enkele unmanaged switch tussenzitten. En het plan was om RSTP te gebruiken

Het grote probleem is dat alles nu parallel is aangesloten. Daar zijn nu dus netwerk/applicatie problemen. De switches die er nu liggen zijn unmanaged.
Ik wil dit netwerk met de switches van Mikrotik gaan opzetten. De core en distributie switches zijn van het volgende type :
https://mikrotik.com/product/crs317_1g_16s_rm

en de switches die voor monitoring en camera in de kasten zorgt:
https://mikrotik.com/product/crs112_8p_4s_in

Ik ben goed bekend met deze apparatuur.Alle switches zijn managed.

Maar eigenlijk adviseer je MPLS of OSPF voor dit netwerk? Alles is Fiber op deze locaties. Het idee is niet zozeer de redundantie , maar de 58 switches aansluiten die parallel zijn aangesloten.

[ Voor 16% gewijzigd door DutchITMaster op 22-04-2018 18:56 ]

[DutchITMaster]

ik222 schreef op zondag 22 april 2018 @ 18:40:
Ik zou dit niet doen zo met unmanaged switches. Ja in theorie blijft je wel loop vrij als de BPDU's er gewoon er doorheen gaan (distributie switches zullen een link blocking zetten) of de koppelingen op de distributieswitches L3 zijn. Maar in een productie omgeving moet je dit echt niet willen. Wat gebeurt er bijvoorbeeld als er per ongeluk een extra verbinding tussen 2 unmanaged switches komt denk je?

Nog even los van het feit dat ik spanning tree eigenlijk liever helemaal niet meer zou gebruiken voor redundante paden te kunnen maken in 2018. Er zijn echt betere alternatieven.

Ik zou als je op laag2 wilt blijven zorgen dat je LACP kunt draaien over de 2 distributie switches heen. En dan als access switches netjes managed switches die een LACP hebben over één link naar elke distributie switch.

En anders kijken naar laag3 met eventueel daaroverheen een laag2 overlay.

Extra kabel tussen de ( unmanaged switches ) is niet mogelijk ivm beperking aantal fibers. Ik ga alles zelf onderhouden dus dat zie ik ook niet gebeuren. Echter het diameter van het hele netwerk zonder dat het doodgaat door broadcast verkeer.

[DutchITMaster]

Equator schreef op zondag 22 april 2018 @ 18:16:
Aanname, alles is op Laag 2 aangesloten. Je maakt zo wel enorme netwerkloops, dus zal je met STP aan de gang moeten. Of je links van de distributie Switches naar de andere switches zijn laag 3.

Heb je niet de mogelijkheid om al de Switches aan te sluiten op je distributie Switches? Of moet je dan te veel glas trekken wat niet kan of gewoonweg te duur is?

In at geval zou ik die sets met Switches inderdaad op L3 aansluiten op je distributie Switches. Maar ik weet niet of je Switches dat ondersteunen.

Hoe ziet je L2 design er uit?

Dit is het Layer2 Design. De koppelingen zijn fiber connecties. De afstanden tussen de switches kunnen erg varieren. Ik heb hier helaas ook nog niet alle informatie kwa intern fiber. Maar ze gaan van unit naar unit , en waarschijnlijk is er geen ring. Dus ik ga uit van de ergste situatie , en de goedkoopste fiber kabel dus 6 aders.over een afstand van een kilometer of 10.

[Equator]

DutchITMaster schreef op zondag 22 april 2018 @ 18:59:
[...]


Dit is het Layer2 Design.

Nee, dit is het (onvolledige) laag 1 design. Daar horen nog wat poortnummers bij.

Een laag 2 design lijkt er op, maar voorziet ook wat VLAN nummers. Dan kan je tenminste zien welk VLAN waar aanwezig zou moeten zijn. Je kan deze twee designs overigens prima in 1 tekening verwerken

De koppelingen zijn fiber connecties. De afstanden tussen de switches kunnen erg varieren. Ik heb hier helaas ook nog niet alle informatie kwa intern fiber. Maar ze gaan van unit naar unit , en waarschijnlijk is er geen ring. Dus ik ga uit van de ergste situatie , en de goedkoopste fiber kabel dus 6 aders.over een afstand van een kilometer of 10.

Daarom zijn die VLAN ID's belangrijk. Ik zie wel degelijk een ring, 3 zelfs, maar omdat ik niet weet wat je met VLAN's wilt doen, kan ik nog niet weten of je een blocking architectuur gaat krijgen of niet.

Maar eigenlijk adviseer je MPLS of OSPF voor dit netwerk? Alles is Fiber op deze locaties. Het idee is niet zozeer de redundantie , maar de 58 switches aansluiten die parallel zijn aangesloten.

Wat @ik222 bedoeld is dat je - als je laag 3 links aanlegt tussen je distributie switches en de switches daaronder, je een redundant routing protocol moet (wil) hebben om de route automatisch te laten verlopen. Dat kan OSPF zijn, maar ook BGP.

MPLS is iets heel anders. Het overlay stuk waar ik222 het over had is een protocol waarmee je over een underlay netwerk bestaande uit enkel laag 3 koppelingen, toch een plat laag 2 netwerk kunt realiseren. Denk daarbij aan ISIS achtigen (TRILL, of Cisco's FabricPath) of VxLAN.

Alles valt en staat met wat je werkelijk nodig hebt aan VLAN's, redundancy, onderhoudbaarheid.

Ik zou in ieder geval wegblijven van elke vorm van Spanning Tree. Dat wil je echt niet meer anno 2018 (zoals @ik222 ook aangeeft.

[DutchITMaster]

Oke, het is een plat netwerk, geen meerdere vlans aanwezig. Dit zou wel mogelijk zijn , er is niets wat me hiervan weerhoud.

Het probleem , wat ik tenminste als probleem zie is de diepte van het aantal switches. Ik durf het niet hardop te zeggen maar dat kan niet parallel met 10 switches achter elkaar . Er zit nu nog geen ring, alleen maar parallel aangesloten switches via glasvezel. Ik ga eerdaags onsite. maar ik zie daar het probleem.
Als dus de layer 1 geen probleem is weet ik voldoende.

Dus simpel gezegd zit het nu als volgt aangesloten

Switch A <> B <> C <> D <>E <> F <> G <> H enz . geen retour naar A

[ik222]

DutchITMaster schreef op zondag 22 april 2018 @ 18:50:
Ter informatie er zal geen enkele unmanaged switch tussenzitten. En het plan was om RSTP te gebruiken

Het grote probleem is dat alles nu parallel is aangesloten. Daar zijn nu dus netwerk/applicatie problemen. De switches die er nu liggen zijn unmanaged.
Ik wil dit netwerk met de switches van Mikrotik gaan opzetten. De core en distributie switches zijn van het volgende type :
https://mikrotik.com/product/crs317_1g_16s_rm

en de switches die voor monitoring en camera in de kasten zorgt:
https://mikrotik.com/product/crs112_8p_4s_in

Ik ben goed bekend met deze apparatuur.Alle switches zijn managed.

Maar eigenlijk adviseer je MPLS of OSPF voor dit netwerk? Alles is Fiber op deze locaties. Het idee is niet zozeer de redundantie , maar de 58 switches aansluiten die parallel zijn aangesloten.

Oké omdat je het in de TS had over unmanaged switches?

Voor de rest bedenk even goed wat de requirements zijn van het netwerk. Dus hoeveel verkeer, hoeveel MAC adressen, hoeveel VLAN's. Moet alle appatuur elkaar op laag2 kunnen zien? Wat zijn dan wel de redundantie eisen? Je zegt redundantie is niet het doel maar ik neem aan dat niet een hele ketting van switches down mag zijn als de eerste in een ketting uitvalt, in dat geval bouw je dus redundantie door een ring te maken.

Verder je hebt het over hoe groot je broadcast domain is. Maar dat wordt bepaald door het aantal hosts in een L2 segment en niet door het aantal switches achter elkaar. En dat gaat al helemaal niet kleiner worden door een ring terug naar de distributie switches te maken.

[ Voor 3% gewijzigd door ik222 op 22-04-2018 20:18 ]

[DutchITMaster]

ik222 schreef op zondag 22 april 2018 @ 20:15:
[...]

Oké omdat je het in de TS had over unmanaged switches?

Voor de rest bedenk even goed wat de requirements zijn van het netwerk. Dus hoeveel verkeer, hoeveel MAC adressen, hoeveel VLAN's. Moet alle appatuur elkaar op laag2 kunnen zien? Wat zijn dan wel de redundantie eisen? Je zegt redundantie is niet het doel maar ik neem aan dat niet een hele ketting van switches down mag zijn als de eerste in een ketting uitvalt, in dat geval bouw je dus redundantie.

Verder je hebt het over hoe groot je broadcast domain is. Maar dat wordt bepaald door het aantal hosts in een L2 segment en niet door het aantal switches achter elkaar.

Basic switches , niet unmanaged. Momenteel zitten er unmanaged switches, die wil ik weg hebben.
Deze switches zijn layer 3, ik kan hier al het nodige mee doen, ospf, bgp enz


Wanneer er nu iets uitvalt voor in de ketting, ligt alles erachter plat! Dit netwerk wordt alleen gebruikt voor monitoring en camera controle ( toegang alarm ed ) . Er is dus niet veel verkeer. Iedere switch zal op zijn max 4 hosts krijgen. Ideaal is het natuurlijk niet, daardoor zijn ze opzoek naar een nieuw design. Ik heb al veel netwerken gemaakt, echter nog niet met zoveel switches achter elkaar .

Ik weet dus dat STP niet goed werkt met meer dan 7 hops. Dit is bij mij nooit voorgekomen.

[ Voor 6% gewijzigd door DutchITMaster op 22-04-2018 20:21 ]

[Equator]

DutchITMaster schreef op zondag 22 april 2018 @ 20:20:
[...]

Wanneer er nu iets uitvalt voor in de ketting, ligt alles erachter plat! Dit netwerk wordt alleen gebruikt voor monitoring en camera controle ( toegang alarm ed ) .

Even over bovenstaande. Stel, een switch valt uit of een fiber gaat stuk. Alles wat verderop in deze keten aangesloten zit, is dan niet meer benaderbaar. Hoe erg is dit? Wat vind het bedrijf daarvan?

[Predator]

Is dit een uitgestrekte fabrieksite ? Het doet me daaraan denken. Vroeger zag je wel vaker dat de gebouwen/kantoren in een ring verbond. Met FDDI was dat goed, nu is dat een nachtmerrie

Als je echt zeker bent dat je geen normaal design kan doen (alle access switches naar de distri/core uplinken), maar vast zit aan 1 of meerdere grote daisychains/ringen dan zie ik maar 1 echt werkbare optie:
Als je toch de switches gaat vervangen door Mikrotik exemplaren met OSPF support, dan kan je er wel een L3 ring van maken, waar je OSPF in draait.
Je hebt dan redundantie bij 1 breuk in je ring, en geen spanning-tree issues.
Je zal dan wel elke switch moeten isoleren op L2, maw 1 of meerdere vlans per switch, en je verliest L2 adjacency over je access switches heen. Maar dat lijkt me op zich geen probleem, toch niet als je bereid bent van de devices te hernummeren.

Wil je jezelf uitleven in OSPF, dan kan je nog meerdere area's maken. Area 0 met de core & distri, en elke ring steek je in een aparte area (al dan niet stub of nssa). Mits een correct ip plan kan je dat nog netjes verdelen zodat elke area geen failures in de andere area hoeft te zien.

Maar het blijft een grote ring .... bovenstaande is gewoon een manier om het werkbaar te maken.
Het blijft iets wat je bij elke vernieuwing terug meedraagt, en het moet betaalbaar blijven.

[ Voor 24% gewijzigd door Predator op 23-04-2018 10:23 ]

[SpamLame]

Geen idee hoe de fysieke spreiding is en waar de vezelparen lopen.

Maar als je stelt dat je te weinig vezelparen hebt, heb je dan ook naar de mogelijkheid van passive DWDM dmv multiplexers en OADM bekeken om een wat meer traditioneel netwerk te bouwen?

[ Voor 10% gewijzigd door SpamLame op 23-04-2018 12:18 ]

[DutchITMaster]

Equator schreef op maandag 23 april 2018 @ 08:05:
[...]

Even over bovenstaande. Stel, een switch valt uit of een fiber gaat stuk. Alles wat verderop in deze keten aangesloten zit, is dan niet meer benaderbaar. Hoe erg is dit? Wat vind het bedrijf daarvan?

Dat gebeurt nu op regelmatige basis , dit is dus ongewenst. Bovenstaande verhaal is dus echt afhankelijk van de beschikbare aders. Ik zal er niet aan ontkomen meerdere switches te daisychainen.

Predator schreef op maandag 23 april 2018 @ 10:16:
Is dit een uitgestrekte fabrieksite ? Het doet me daaraan denken. Vroeger zag je wel vaker dat de gebouwen/kantoren in een ring verbond. Met FDDI was dat goed, nu is dat een nachtmerrie

Als je echt zeker bent dat je geen normaal design kan doen (alle access switches naar de distri/core uplinken), maar vast zit aan 1 of meerdere grote daisychains/ringen dan zie ik maar 1 echt werkbare optie:
Als je toch de switches gaat vervangen door Mikrotik exemplaren met OSPF support, dan kan je er wel een L3 ring van maken, waar je OSPF in draait.
Je hebt dan redundantie bij 1 breuk in je ring, en geen spanning-tree issues.
Je zal dan wel elke switch moeten isoleren op L2, maw 1 of meerdere vlans per switch, en je verliest L2 adjacency over je access switches heen. Maar dat lijkt me op zich geen probleem, toch niet als je bereid bent van de devices te hernummeren.

Wil je jezelf uitleven in OSPF, dan kan je nog meerdere area's maken. Area 0 met de core & distri, en elke ring steek je in een aparte area (al dan niet stub of nssa). Mits een correct ip plan kan je dat nog netjes verdelen zodat elke area geen failures in de andere area hoeft te zien.

Maar het blijft een grote ring .... bovenstaande is gewoon een manier om het werkbaar te maken.
Het blijft iets wat je bij elke vernieuwing terug meedraagt, en het moet betaalbaar blijven.

Het is een bestaande site die inderdaad als een lang uitgerekt bedrijfssite is opgezet. Jou antwoord spreekt mij het meeste aan, en ik denk ook dat dat de oplossing gaat zijn. Ik ga proberen kleine segmenten te maken en ieder segment aan te sluiten op beide distributie switches. Ik ben vrij met het nummeren van ip adressen en zal meerdere OSPF areas gaan maken. Hoe ik doe boel op layer1/2 ga aansluiten moet ik per site gaan bekijken. Maar de basis is bepaalt. En uiteraard spring ik een gat in de lucht als er toch een glasvezelring ligt met 96 vezels. Dan kan het een fatsoenlijk netwerk worden, en ga ik direct een glasvezellas apparaat huren. Maar ik ga nu even uit van een simpele 6 vezel kabel.

quote]SpamLame schreef op maandag 23 april 2018 @ 12:16:
Geen idee hoe de fysieke spreiding is en waar de vezelparen lopen.

Maar als je stelt dat je te weinig vezelparen hebt, heb je dan ook naar de mogelijkheid van passive DWDM dmv multiplexers en OADM bekeken om een wat meer traditioneel netwerk te bouwen?
[/quote]

Woow , dat bestaat natuurlijk ook nog. Als het daadwerkelijk een issue is kunenn we dit ook nog eens nader bekijken.


Thanks voor jullie meedenken, stel het zeer op prijs

[Bastiaan V]

Dit schreeuwt om een oadm oplossing. op die manier kan je elke switch met zijn eigen kleurtje koppelen aan je "core" waardoor je een mooie (moderne) leaf/spine omgeving kan opbouwen.

[Ascension]

Hou er met meerdere area's wel rekening mee dat elke area aan area 0 moet grenzen, anders moet je weer met virtual-links gaan werken.

[Equator]

Bastiaan V schreef op woensdag 25 april 2018 @ 21:06:
Dit schreeuwt om een oadm oplossing. op die manier kan je elke switch met zijn eigen kleurtje koppelen aan je "core" waardoor je een mooie (moderne) leaf/spine omgeving kan opbouwen.

In dat geval zou je op elke plek waar je een leaf-switch hebt staan, 2 kleurtjes moeten kunnen gebruiken. Want in een leaf-spine constructie staat elke leaf-switch verbonden met beide spine-switches.



En zoals we het tot nu toe van @DutchITMaster hebben begrepen, is het nog onduidelijk of er uberhaupt op elke locatie (waar de leaf-switches dan staan) wel een uplink mogelijkheid is naar de spine-switches.

Wat dat betreft is de oplossing van @Predator mooier. Alle links in de ring op een /31 /30 en dan middels een routing protocol als OSPF redundantie toevoegen. Aangezien er geen laag 2 afhankelijkheid blijkt te zijn op elke switch locatie, is dat een mooie oplossing. Mits elke switch wel de noodzakelijke L3 functionaliteit heeft.

Ascension schreef op woensdag 25 april 2018 @ 22:55:
Hou er met meerdere area's wel rekening mee dat elke area aan area 0 moet grenzen, anders moet je weer met virtual-links gaan werken.

Nu ben ik geen OSPF expert, maar ik zou in deze situatie slechts een area 0 hanteren. Elke extra area maakt het IMHO alleen maar complexer dan noodzakelijk.

[overhyped]

DutchITMaster schreef op maandag 23 april 2018 @ 13:45:
[...]


Dat gebeurt nu op regelmatige basis , dit is dus ongewenst. Bovenstaande verhaal is dus echt afhankelijk van de beschikbare aders. Ik zal er niet aan ontkomen meerdere switches te daisychainen.


[...]


Het is een bestaande site die inderdaad als een lang uitgerekt bedrijfssite is opgezet. Jou antwoord spreekt mij het meeste aan, en ik denk ook dat dat de oplossing gaat zijn. Ik ga proberen kleine segmenten te maken en ieder segment aan te sluiten op beide distributie switches. Ik ben vrij met het nummeren van ip adressen en zal meerdere OSPF areas gaan maken. Hoe ik doe boel op layer1/2 ga aansluiten moet ik per site gaan bekijken. Maar de basis is bepaalt. En uiteraard spring ik een gat in de lucht als er toch een glasvezelring ligt met 96 vezels. Dan kan het een fatsoenlijk netwerk worden, en ga ik direct een glasvezellas apparaat huren. Maar ik ga nu even uit van een simpele 6 vezel kabel.

quote]SpamLame schreef op maandag 23 april 2018 @ 12:16:
Geen idee hoe de fysieke spreiding is en waar de vezelparen lopen.

Maar als je stelt dat je te weinig vezelparen hebt, heb je dan ook naar de mogelijkheid van passive DWDM dmv multiplexers en OADM bekeken om een wat meer traditioneel netwerk te bouwen?
[/quote]

Woow , dat bestaat natuurlijk ook nog. Als het daadwerkelijk een issue is kunenn we dit ook nog eens nader bekijken.


Thanks voor jullie meedenken, stel het zeer op prijs

Waarom de complexiteit van meerdere areas? Nu zal dr CPU van zo’n microtik weinig voorstellen, en ik weet niet hoe stabiel de OSPF implementatie is, mAr dit handje vol routes mag echt geen probleem zijn.

Er zijn maar weinig netwerken in Nederland waar areas echt wat toevoegen, dit is er geen.

[Predator]

Equator schreef op donderdag 26 april 2018 @ 08:02:
[...]
Wat dat betreft is de oplossing van @Predator mooier. Alle links in de ring op een /31 en dan middels een routing protocol als OSPF redundantie toevoegen.

Ik denk dat je /30 bedoelt ;-)

Nu ben ik geen OSPF expert, maar ik zou in deze situatie slechts een area 0 hanteren. Elke extra area maakt het IMHO alleen maar complexer dan noodzakelijk.

Niemand weet echt hoeveel OSPF routers je in 1 area kwijt kan voor je in de probleemzone komt. Dat hangt ook van omgeving tot omgeving af. In best practise info zie je meestal een cijfer tussen 50 en 250.
De realiteit is op moderne hardware zeker hoger, want die cijfers worden nooit aangepast.
Dus kan zeker, en is voor iemand met basic OSPF zeker aan te raden.

Design technisch zijn er wel voordelen aan meerdere area's:

Het grootste nadeel aan OSPF is dat je in OSPF enkel op ABR en ASBR routers kan summarization/filtering doen. (Je kan wel op elke (OSPF) router bepalen wat er uiteindelijk in de RIB komt, maar niet de OSPF DB). Door je ABR routers correct te kiezen heb je meer controller over je OSPF DB, en kan je ook vermijden dat een failure ergens voor een SPF berekening op alle routers leidt.

Enkele vendors (Cisco *kuch*) kiezen er ook voor om in de lagere feature sets enkel een light OSPF (Cisco noemt het "OSPF for routed access") in te bouwen, waarbij je maar 1 OSPFv2 en 1vOSPFv3 proces kan draaien, beperkt tot 1000 routes. Dat kan een reden zijn om bv een stub of nssa area te gebruiken naast de backbone area. In een nssa area kan je zelfs je nssa-external routes nssa-only maken, waardoor de nssa translator die niet zal injecteren in de backbone area. Je hoeft die dan zelf niet te filteren op de ABR. In sommige gevallen kan dat erg handig zijn.

Maar zoals gezegd, je hebt helemaal gelijk, hier zal enkel een backbone area ook wel prima werken, en de routing tables zullen zeker niet groot zijn gezien het kleine aantal subnets.

[ Voor 6% gewijzigd door Predator op 26-04-2018 09:00 ]

[Predator]

overhyped schreef op donderdag 26 april 2018 @ 08:42:
[...]


Waarom de complexiteit van meerdere areas? Nu zal dr CPU van zo’n microtik weinig voorstellen, en ik weet niet hoe stabiel de OSPF implementatie is, mAr dit handje vol routes mag echt geen probleem zijn.

Er zijn maar weinig netwerken in Nederland waar areas echt wat toevoegen, dit is er geen.

Het aantal routes heeft weinig tot geen impact op de OSPF stabiliteit/complexiteit. Het aantal OSPF routers (lees: transit links) wel. 10 L3 switches met 1000 vlans in OSPF is veel simpeler dan 100 OSPF routers met elk slechts 2 subnets. Die 1000 vlans die zijn gewoon stub networks gelinkt aan de OSPF router.
Stub networks hebben geen invloed op OSPF, en dat wordt heel efficient geregeld. Zolang je maar geen "redistribute connected" doet, hoewel dat laatste ook nog wel meevalt.

Maar uiteraard, als de OSPF implementatie buggy is, dan is dat kans wel kleiner dat je in enkel een area 0 die bugs gaat tegenkomen. Maar je mag toch verwachten dat Mikrotik OSPF wel op orde heeft

[overhyped]

Predator schreef op donderdag 26 april 2018 @ 09:12:
[...]

Het aantal routes heeft weinig tot geen impact op de OSPF stabiliteit/complexiteit. Het aantal OSPF routers (lees: transit links) wel. 10 L3 switches met 1000 vlans in OSPF is veel simpeler dan 100 OSPF routers met elk slechts 2 subnets. Die 1000 vlans die zijn gewoon stub networks gelinkt aan de OSPF router.
Stub networks hebben geen invloed op OSPF, en dat wordt heel efficient geregeld. Zolang je maar geen "redistribute connected" doet, hoewel dat laatste ook nog wel meevalt.

Maar uiteraard, als de OSPF implementatie buggy is, dan is dat kans wel kleiner dat je in enkel een area 0 die bugs gaat tegenkomen. Maar je mag toch verwachten dat Mikrotik OSPF wel op orde heeft

Direct toegegeven dat 100 routers met 10 netwerken meer complexiteit qua ospf dan 10 routers met 100 netwerken., maar een grote tabel heeft wel degelijk invloed op de stabiliteit.

Of microtik z’n OSPF op orde heeft: geen idee; te weinig ervaring mee en ben wat biased

Feit blijft dat bij zo’n klein netwerkje simpelheid qua configuratie belangrijker is dan een vermeende optimalisatie met areas.

Mocht L2 toch een eis zijn vanwege Industrial protocollen kan ‘t ook nuttig zijn om eens naar een Media Redundancy Protocol, een geoptimaliseerd protocol voor L2 ringen in Industrial omgevingen. Wat ik las gaat ‘t om camera’s en wat standaard IT spul, dus ‘t zal niet relevant zijn

[Predator]

overhyped schreef op donderdag 26 april 2018 @ 10:35:
[...]


Direct toegegeven dat 100 routers met 10 netwerken meer complexiteit qua ospf dan 10 routers met 100 netwerken., maar een grote tabel heeft wel degelijk invloed op de stabiliteit.

Dan mag je altijd uitleggen waarom mijn standpunt ivm stublinks vs transit links niet klopt.
Tenzij je over de RIB spreekt, en niet de OSPF database, maar dan snap ik je nog minder.
Het aantal routes in de RIB heeft absoluut geen impact op de stabiliteit, zolang je de ingestelde limieten van je platform niet bereikt.

Daarnaast zijn de cpu's in de control-planes dermate sneller geworden dat Cisco besloten heeft met support voor iSPF (incremental SPF, een feature voor grote OSPF databases) gewoon te stoppen in nieuwere versies. Daarnaast zijn de default lsa throttle timers verlaagd. SPF calculatie tijd is geen issue meer op moderne hardware. Optimalisaties zoals iSPF zijn gewoon niet meer nodig.

iSPF Has Been Removed

Reason for the Change

Incremental SPF is a feature which was developed circa 2000 as a means to optimize performance of the IGP, that reduces the execution time of an SPF by only recalculating a sub-tree of the full Shortest Path Tree when topology changes were limited to a portion of the network. Implementation of this feature has been superceded with ever increasing CPU power on routers, which meant that when you use iSPF, it became less and less necessary, because of providing almost no benefit, while adding complexity. For this reason, it is generally recommend to not enable this feature, because with higher CPU power the use of regular SPF is more straightforward. This is also why Cisco chose to deprecate the iSPF feature. The CLI that exists is still accepted but does not enable the feature and the command will not be NVGEN'ed. A warning message is printed that indicates that the feature is no longer supported.

[overhyped]

Predator schreef op donderdag 26 april 2018 @ 11:43:
[...]

Dan mag je altijd uitleggen waarom mijn standpunt ivm stublinks vs transit links niet klopt.
Tenzij je over de RIB spreekt, en niet de OSPF database, maar dan snap ik je nog minder.
Het aantal routes in de RIB heeft absoluut geen impact op de stabiliteit, zolang je de ingestelde limieten van je platform niet bereikt.

Daarnaast zijn de cpu's in de control-planes dermate sneller geworden dat Cisco besloten heeft met support voor iSPF (incremental SPF, een feature voor grote OSPF databases) gewoon te stoppen in nieuwere versies. Daarnaast zijn de default lsa throttle timers verlaagd. SPF calculatie tijd is geen issue meer op moderne hardware. Optimalisaties zoals iSPF zijn gewoon niet meer nodig.

[...]

Mischien was stabiliteit niet direct 't goede woord, point taken.

de tree wordt niet complexer, er is alleen wat meer data. en dat heeft invloed. Op een high end implementatie op een asr1k of hoger is dat inderdaad goed geregeld, maar er zijn nog genoeg ospf implementaties die bij een simpele change de hele database leeggooien en opnieuw beginnen. Met name bij "vreemde" devices zoals firewalls e.d. wil dat nog wel eens gebeuren. (laatst nog een major firewall: Statefull failover voor connecties, neighors werden gesynced, maar de OSPF tabel was leeg. Dan maakt 't uit of je 5 of 50.000 routes hebt. (en een goede case om area's te gebruiken naar zo'n apparaat met alleen een paar summaries.)

Waar microtik zit in z'n implementatie; Geen idee. Ik schat ergens in 't midden

en ja: BFD rocks

[ Voor 0% gewijzigd door overhyped op 26-04-2018 14:42 . Reden: Zinnetje vergeten ]

[Predator]

Firewalls zijn nu inderdaad geen goed voorbeeld, helemaal akkoord.
Ik heb helaas ook verschillende WTF-issues gehad met OSPF icm een firewall cluster.
Er is nog wat meer maturiteit op dat vlak nodig in die producten blijkbaar...

[DutchITMaster]

Mijn ervaring is dat mikrotik zijn ospf prima op orde heeft. Vorige werkgever had private glasvezel in diverse dorpen. Het hele datacenter draait daar op mikrotik de internet routers met meerdere 10gbit uplinks. Enkel de switches waren disco en de accesswitches waren ook Disco. Er is toen ooit gekozen voor OSPF voor de interne routers. Ipv iBGP .

Ik ga bij dit netwerk voor ospf. Aangezien ik de nodige certificering voor mikrotik heb verwacht ik geen problemen. Het gaat om een park waar zaken als camera's keyprocessor en management moet draaien

[Bastiaan V]

Equator schreef op donderdag 26 april 2018 @ 08:02:
[...]

In dat geval zou je op elke plek waar je een leaf-switch hebt staan, 2 kleurtjes moeten kunnen gebruiken. Want in een leaf-spine constructie staat elke leaf-switch verbonden met beide spine-switches.

[afbeelding]

En zoals we het tot nu toe van @DutchITMaster hebben begrepen, is het nog onduidelijk of er uberhaupt op elke locatie (waar de leaf-switches dan staan) wel een uplink mogelijkheid is naar de spine-switches.

Wat dat betreft is de oplossing van @Predator mooier. Alle links in de ring op een /31 /30 en dan middels een routing protocol als OSPF redundantie toevoegen. Aangezien er geen laag 2 afhankelijkheid blijkt te zijn op elke switch locatie, is dat een mooie oplossing. Mits elke switch wel de noodzakelijke L3 functionaliteit heeft.


[...]

Nu ben ik geen OSPF expert, maar ik zou in deze situatie slechts een area 0 hanteren. Elke extra area maakt het IMHO alleen maar complexer dan noodzakelijk.

Ik weet hoe een leaf/spine omgeving wordt opgebouwd

In de OP zie je (vereenvoudigd) twee ringen. je kan er voor kiezen om elke leaf binnen 1 van de ringen 1 kleur te geven, waarbij je linksom naar de ene, en rechtsom naarde andere spine toe gaat. Wanneer je meer spines wilt kan je simpelweg meer kleurtjes gaan gebruiken. (wij hebben recent een omgeving opgeleverd met 192(!) 10G kanalen over een enkele vezel).

Natuurlijk kan je ook gaan routeren op alle locaties, maar dan zal je bandbreedte gaan delen met de locatiet die achter elkaar zitten, waardoor je een veel complexere omgeving gaat krijgen. Ook moeten de routers snel genoeg zijn om niet alleen het eigen verkeer te routeren, maar ook het verkeer wat transit is naar de volgende locatie. (Kostenpost!) Daarnaast voegtiedere hop latency toe aan de verbinding.

[ Voor 11% gewijzigd door Bastiaan V op 29-04-2018 17:28 ]

[Equator]

@Bastiaan V Let even op dat er door de TS is aangegeven dat deze ' leaf' switches over een groot terrein verspreid staan. Beschikbare bekabeling was nog niet bekend.

[Bastiaan V]

Equator schreef op maandag 30 april 2018 @ 07:24:
@Bastiaan V Let even op dat er door de TS is aangegeven dat deze ' leaf' switches over een groot terrein verspreid staan. Beschikbare bekabeling was nog niet bekend.

Wat er totaal niet toe doet.

Wanneer je een layer3 link over glas naar "de core" kan realiseren, kan je ook een lichtpad naar beide spines realiseren.

[Equator]

Bastiaan V schreef op woensdag 2 mei 2018 @ 21:27:
[...]


Wat er totaal niet toe doet.

Wanneer je een layer3 link over glas naar "de core" kan realiseren, kan je ook een lichtpad naar beide spines realiseren.

In het plaatje van de topicstarter staan slechts 2 'leaf-switches' verbonden met de core/spine-switches.

De switches ertussen staan over een groot terrein verdeeld. Als al deze switches (wat er veel meer zijn dan getekend) een link naar de spines moeten hebben, dan moet daar op die locatie wel de noodzakelijke fysieke infrastructuur (lees: bekabeling) liggen. (wat overigens nog onbekend is). Je kan dus niet zomaar verwachten dat er glas ligt op elke locatie. Gezien "groot terrein" laten we UTP ook maar even achterwege.

Maar goed, we kunnen er nog niets van zeggen, aangezien de TS niet weet wat er op locatie aan bekabeling beschikbaar is.

[DutchITMaster]

De infrastructuur is het grote vraagstuk. Binnen een paar weken hebben we toegang tot de site en kan ik het design verder uitwerken. Ik heb al wat informatie ingewonnen bij een bevriende glasvezel installateur die ook al enkele soortgelijke site's heeft verglaast. Hij gaf aan dat er over het algemeen een ring van 12 fibers ligt. Dus ik vermoed dat het hier ook het geval zal zijn. Het is geen bedrijfskritisch systeem, het is een aanvulling op de monitoring, camera's en toegangscontrole ( keyprocessor ) .

[Verwijderd]

Zoek uit waar je de beste kosten/baten mee behaalt. Als je 96 vezels neerlegt is dat misschien goedkoper dan voor een 2e keer een installateur laten komen. En 96 vezels (48x LC pair) past in een 1U high density patch panel.

[DJSmiley]

Als je over korte afstanden praat (lees: <30km) kun je ook met CWDM nog prima af. DWDM is een stukje duurder, maar met CWDM kun je ook wel aardig wat kwijt over 1 vezelpaar (of desnoods over 1 enkele vezel)

In die gevallen moet er natuurlijk wel SM liggen.

DutchITMaster schreef op zondag 22 april 2018 @ 18:50:
Ter informatie er zal geen enkele unmanaged switch tussenzitten. En het plan was om RSTP te gebruiken

Het grote probleem is dat alles nu parallel is aangesloten. Daar zijn nu dus netwerk/applicatie problemen. De switches die er nu liggen zijn unmanaged.
Ik wil dit netwerk met de switches van Mikrotik gaan opzetten. De core en distributie switches zijn van het volgende type :
https://mikrotik.com/product/crs317_1g_16s_rm

De CRS serie is een L2 switch, die toevallig wat L3 dingetjes kan. Als je dingen als MPLS en OSPF enz wilt doen, dan kun je niet af met SwOS, maar zul je met routerOS aan de gang moeten.
En dan is het cputje snel de bottleneck.

[Bastiaan V]

Equator schreef op donderdag 3 mei 2018 @ 07:08:
[...]

In het plaatje van de topicstarter staan slechts 2 'leaf-switches' verbonden met de core/spine-switches.

De switches ertussen staan over een groot terrein verdeeld. Als al deze switches (wat er veel meer zijn dan getekend) een link naar de spines moeten hebben, dan moet daar op die locatie wel de noodzakelijke fysieke infrastructuur (lees: bekabeling) liggen. (wat overigens nog onbekend is). Je kan dus niet zomaar verwachten dat er glas ligt op elke locatie. Gezien "groot terrein" laten we UTP ook maar even achterwege.

Maar goed, we kunnen er nog niets van zeggen, aangezien de TS niet weet wat er op locatie aan bekabeling beschikbaar is.

Simpelweg niet waar.
Wanneer het mogelijk is om een L3 netwerk op te bouwen waarbij enkel gebruik gemaakt wordt van glas verbindingen, kan je ook een lichtpad creëren tussen twee willekeurige locaties.
Enige beperking is dat je maximaal 96 gebouwen kan daisy-chainen (per vezelpaar) wanneer je het betaalbaar wilt houden. (of max 48 gebouwen wanneer je 2 lichtpaden naar de spine switches wilt hebben)

DJSmiley schreef op donderdag 3 mei 2018 @ 20:32:
Als je over korte afstanden praat (lees: <30km) kun je ook met CWDM nog prima af. DWDM is een stukje duurder, maar met CWDM kun je ook wel aardig wat kwijt over 1 vezelpaar (of desnoods over 1 enkele vezel)

In die gevallen moet er natuurlijk wel SM liggen.


[...]


De CRS serie is een L2 switch, die toevallig wat L3 dingetjes kan. Als je dingen als MPLS en OSPF enz wilt doen, dan kun je niet af met SwOS, maar zul je met routerOS aan de gang moeten.
En dan is het cputje snel de bottleneck.

In mijn ervaring is CWDM enkel serieus duurder wanneer je 1G optics wil gebruiken. wanneer je enkel 10G gaat gebruiken is het verschil minimaal.
List kost een 18 channel CWDM mux ongeveer het zelfde als een 18 channel DWDM mux, de DWDM optics zijn ~20% duurder dan de CWDM tegenhangers.

[ Voor 39% gewijzigd door Bastiaan V op 04-05-2018 14:59 ]

[Equator]

Bastiaan V schreef op vrijdag 4 mei 2018 @ 14:51:
[...]


Simpelweg niet waar.
Wanneer het mogelijk is om een L3 netwerk op te bouwen waarbij enkel gebruik gemaakt wordt van glas verbindingen, kan je ook een lichtpad creëren tussen twee willekeurige locaties.
Enige beperking is dat je maximaal 96 gebouwen kan daisy-chainen (per vezelpaar) wanneer je het betaalbaar wilt houden. (of max 48 gebouwen wanneer je 2 lichtpaden naar de spine switches wilt hebben)

Dus jij wilt een spine leaf constructie maken met paden die gedaisychained zijn via alle andere leaf switches. Begrijp ik je nu goed?

Ja, je kan een L3 verbinding maken tussen de spine switche en de laatste leaf switch, maar of dat nu een bruikbaar ontwerp is

[Bastiaan V]

Equator schreef op vrijdag 4 mei 2018 @ 15:24:
[...]

Dus jij wilt een spine leaf constructie maken met paden die gedaisychained zijn via alle andere leaf switches. Begrijp ik je nu goed?

Ja, je kan een L3 verbinding maken tussen de spine switche en de laatste leaf switch, maar of dat nu een bruikbaar ontwerp is

Nee, Ik heb het over een L1 verbinding...
Wikipedia: Optical add-drop multiplexer

[Equator]

Bastiaan V schreef op vrijdag 4 mei 2018 @ 15:36:
[...]


Nee, Ik heb het over een L1 verbinding...
Wikipedia: Optical add-drop multiplexer

Ah, oke, dat apparaat kende ik nog niet.