Onderwerp: Advies ToR switchen

We zijn aan het plannen om een tweede datacenter op te starten, naast ons huidige dc.
Tussen de twee DC's krijgen we een dedicated fiber paar.

We hebben momenteel de Summit x670 van Extreme draaien.
Die hebben 1 groot nadeel, namelijk dat je de hele stack moet rebooten bij een software update.
Een distributed stack over de twee DC's is dus niet handig...

We planden over te schakelen naar de VDX reeks van Brocade, maar die ondersteunen dan weer geen Q-in-Q, wat we absoluut nodig hebben.

Niemand bij ons heeft Juniper ervaring, dus daar hangt vermoedelijk een stevige leercurve aan?
Ik vermoed dat Cisco te duur zal zijn voor ons budget.
We hebben heel wat Huawei campus switchen in gebruik, waar we op zich wel tevreden over zijn. Maar geen ervaring met hun datacenter switchen...

Iemand die nog een andere vendor/reeks kan aanraden?

Leercurve van Juniper valt zeer mee, als je bekend bent met de materie is het alleen CLI leren. Dat heb je vrij snel door.

Je zou kunnen overwegen de Juniper oplossing te laten configureren met een kleine training erbij. Maakt de leercurve nog wat kleiner.

Maar waarom distributed stack. Het maakt beheer wel makkelijker misschien maar afhankelijkheden ook groter tussen de DCs.
Je kunt ook voor ethernet ring protection kiezen, en daar heeft jouw Extreme switch een vergelijkbare oplossing voor.

Wij hebben een aantal Huawei CloudEngine CE68xx series switches hangen, een jaartje of 3 nu. Nog nooit issues mee gehad. Ze zijn per twee gestacked (en met elkaar verbonden met 2 DAC kabels).

Ik zweer bij de HP 5xxx serie. 5120 is prima ToR

Gebruik zelf Juniper EX4200 in Virtual Chassis. Dat heeft ons nog nooit in de steek gelaten en de performance is uitstekend.
Leercurve valt erg mee. Of met een paar uurtjes advies moet je de basis wel kunnen begrijpen (zolang je config niet te complex is).

Oorspronkelijk geplaatst door CharlieRoot

Ik zweer bij de HP 5xxx serie. 5120 is prima ToR

Dat spul staat zo'n beetje bovenaan mijn lijst om af te raden. Storm control is niet goed in hardware geimplementeerd en daardoor bij een BUM-storm nauwelijks effectief. Als je teveel VLANs (100+) van een interface af wil halen in 1x wordt het de CPU van het ding ook teveel, waardoor, als je pech hebt, er een proces blijft hangen en je CPU op 100% blijft hangen. Dat laatste is overigens met een aankomende release opgelost.

Gelukkig gaat die klant over naar QFX'en van Juniper. Merk waar pas echt bij te zweren is (50+ QFX switches in dagelijks beheer, totaal ruim 400 Juniper switches). Ik zou het wel weten in elk geval.

Oorspronkelijk geplaatst door T. Verhaeg

Dat spul staat zo'n beetje bovenaan mijn lijst om af te raden. Storm control is niet goed in hardware geimplementeerd en daardoor bij een BUM-storm nauwelijks effectief. Als je teveel VLANs (100+) van een interface af wil halen in 1x wordt het de CPU van het ding ook teveel, waardoor, als je pech hebt, er een proces blijft hangen en je CPU op 100% blijft hangen. Dat laatste is overigens met een aankomende release opgelost.

Gelukkig gaat die klant over naar QFX'en van Juniper. Merk waar pas echt bij te zweren is (50+ QFX switches in dagelijks beheer, totaal ruim 400 Juniper switches). Ik zou het wel weten in elk geval.

Nou misschien dat de inrichting er wat mee te maken heeft, heb toch vrij grote netwerken op deze hardware gedraaid en de problemen die jij noemt nooit gehad.

Oorspronkelijk geplaatst door CharlieRoot

Nou misschien dat de inrichting er wat mee te maken heeft, heb toch vrij grote netwerken op deze hardware gedraaid en de problemen die jij noemt nooit gehad.

De beperking van stormcontrol in software is geen gevolg van inrichting maar een keuze bij het maken van de software. Was in dat geval op een 5900 en dat euvel is ook toegegeven door HP TAC. Een broadcast storm van 3-4 gbit/s kreeg het ding daarmee op zijn knieeen. Voor wat betreft het andere probleem, daar zou het zomaar aan inrichting kunnen liggen (ding doet, of deed, hoop VLANs met SVI's en OSPF / BGP naar de core van het netwerk).

Oorspronkelijk geplaatst door T. Verhaeg

De beperking van stormcontrol in software is geen gevolg van inrichting maar een keuze bij het maken van de software. Was in dat geval op een 5900 en dat euvel is ook toegegeven door HP TAC. Een broadcast storm van 3-4 gbit/s kreeg het ding daarmee op zijn knieeen. Voor wat betreft het andere probleem, daar zou het zomaar aan inrichting kunnen liggen (ding doet, of deed, hoop VLANs met SVI's en OSPF / BGP naar de core van het netwerk).

Als een broadcast storm mogelijk is zit er wel meer fout in de configuratie van het netwerk dus dat alleen al vind ik geen goed argument. Dat is dus wel een kwestie van inrichting. Verder heb ik zelf die 5900 ook draaien, tests met 10gbps gehaald en zonder issues.

En BGP op een switch? een switch moet switchen.... BGP hebben ze routers voor..

Oorspronkelijk geplaatst door CharlieRoot

Als een broadcast storm mogelijk is zit er wel meer fout in de configuratie van het netwerk dus dat alleen al vind ik geen goed argument. Dat is dus wel een kwestie van inrichting. Verder heb ik zelf die 5900 ook draaien, tests met 10gbps gehaald en zonder issues.

En BGP op een switch? een switch moet switchen.... BGP hebben ze routers voor..

Je opmerking over BGP is pas een voorbeeld van een slecht argument. Het is juist schaalbaar om je laag 2 boundary zo klein mogelijk te houden, dus als dat kan op een ToR (leaf) die vervolgens laag 3 naar je spines doet, dan spreek je van een schaalbaar design (CLOS l3 fabric). http://www.networkers-online.com/blo...network-part1/. Maar met een paar servertjes erop kan ik me voorstellen dat dat niet de moeite loont .

Vwb storm-control, in een laag 2 redundant netwerk, waar de klant vandaan kwam kan je maar wat blij zijn met de functie mits die goed werkt. Feit blijft, waar andere (Juniper / Cisco / Arista) die functionaliteit in hardware implementeren staat dat op een 5900 in software. En in dat geval, in dat netwerk, was dat de verkeerde keus.

Zijn je servers aangesloten op 1G of 10G?

Heb je al eens naar Arista gekeken? Deze zitten met hun gamma toch nog een trapje hoger als HP/Extreme/Huawei.
Al mag ik hier als zijnde werkzaam bij een verdeler van Arista geen reclame maken.

Oorspronkelijk geplaatst door T. Verhaeg

Je opmerking over BGP is pas een voorbeeld van een slecht argument. Het is juist schaalbaar om je laag 2 boundary zo klein mogelijk te houden, dus als dat kan op een ToR (leaf) die vervolgens laag 3 naar je spines doet, dan spreek je van een schaalbaar design (CLOS l3 fabric). http://www.networkers-online.com/blo...network-part1/. Maar met een paar servertjes erop kan ik me voorstellen dat dat niet de moeite loont .

Vwb storm-control, in een laag 2 redundant netwerk, waar de klant vandaan kwam kan je maar wat blij zijn met de functie mits die goed werkt. Feit blijft, waar andere (Juniper / Cisco / Arista) die functionaliteit in hardware implementeren staat dat op een 5900 in software. En in dat geval, in dat netwerk, was dat de verkeerde keus.

Geschreven door Ayman AboRabh.. wie kent hem niet.

Even serieus. Je kunt het zo mooi en complex maken als je zelf wilt, maar dan moet je niet gaan klagen dat je CPU load omhoog gaat.. Daarnaast heb ik VM's die over hele netwerk heen verplaatsen (dus niet op één switch zitten, niet in éen kast zitten en soms zelfs niet in het zelfde DC) en dan heb je al niets meer aan jouw prachtige L3 setup. Maar goed, ieder zijn ding.

Maar met een paar servertjes erop kan ik me voorstellen dat dat niet de moeite loont .

Dat laat ik verder voor jouw rekening. Kom eerst maar met echte metingen voordat je een verkeerde voorstelling van de feiten geeft.

Oorspronkelijk geplaatst door CharlieRoot

Even serieus. Je kunt het zo mooi en complex maken als je zelf wilt, maar dan moet je niet gaan klagen dat je CPU load omhoog gaat.. Daarnaast heb ik VM's die over hele netwerk heen verplaatsen (dus niet op één switch zitten, niet in éen kast zitten en soms zelfs niet in het zelfde DC) en dan heb je al niets meer aan jouw prachtige L3 setup. Maar goed, ieder zijn ding.

Voor een laag 2 functionaliteit kun je dan perfect gebruik maken van tunneling technieken zoals VXLAN. Koppel VXLAN aan EVPN en je hebt een setup die een active-active anycast gateway kan bieden, built in loop preventie heeft en ook nog eens kan schalen. Maar dat gaat veel verder dan een simpele ToR, dus ik laat het hier verder bij.

Oorspronkelijk geplaatst door CharlieRoot

Dat laat ik verder voor jouw rekening. Kom eerst maar met echte metingen voordat je een verkeerde voorstelling van de feiten geeft.

Dat was niet specifiek richting jouw bedoeld maar richting het feit dat je een complexere setup kiest die schaalbaarder is.

Oorspronkelijk geplaatst door T. Verhaeg

Voor een laag 2 functionaliteit kun je dan perfect gebruik maken van tunneling technieken zoals VXLAN. Koppel VXLAN aan EVPN en je hebt een setup die een active-active anycast gateway kan bieden, built in loop preventie heeft en ook nog eens kan schalen. Maar dat gaat veel verder dan een simpele ToR, dus ik laat het hier verder bij.



Dat was niet specifiek richting jouw bedoeld maar richting het feit dat je een complexere setup kiest die schaalbaarder is.

We weten nu wel dat je denkt dat je alle kennis in huis hebt. Ik ben meer van de keep-things-simple. Waarom zou ik mijn switch helemaal beladen met alle mogelijke functies omdat het stoer is om hierover op WHT te flamen. Ik ben er om mijn klanten een goede dienst te leveren en dit betaalbaar te houden. Dat betekend een netwerk zo inrichten dat ik het zo efficiënt mogelijk kan beheren in zo min mogelijk tijd en de hardware betaalbaar te houden. Efficiënt beheren betekend ook niet op iedere machine die het kan gaan lopen routeren als het niet hoeft. Ik doe mijn routing liever op één plek en ToR switches zijn hiervoor niet de juiste.