Netwerk Migratie naar EX4200 juniper virtual chassis

[sakbari]

Beste Forum gebruikers

ik ben bezig met een netwerk Migratie van de heel netwerk. op dit moment wordt er 2 ex3200 als core switchs gebruikt en er zetten 150 cisco switchs als access switch aangesloten met spanning tree aangesloten. ik wil graag de access switchs in de toekomst met port channel aansluiten op de VC van de juniper. uit de ducumentie van de juniper lees ik dat het max LAG 64 is

hebben jullie ervaring juniper virtual chassis en port channel ( LAG) van de juniper.

graag wil ik jullie advies of ervaring hiermee

MVG
Sakbari

[WhizzCat]

Hoe zit dat dan in elkaar? Ik zie dat de Ex3200 met maximaal 48 poorten uit te rusten is. Ik snap dus even niet hoe je 150 switches met STP d'r op krijgt. Ik neem hierbij even aan dat je iedere access switch apart hebt ontsloten, of is er sprake van doorlussen?

Misschien kan je even een tekening van de opzet maken zoals die nu is en zoals je die wilt hebben want dit is eigenlijk veel te weinig informatie om een zinnig advies te geven. Ook het type netwerk verkeer speelt denk ik wel een rol. Gaat het om simpel office werk of is er b.v. ook sprake van data intensieve applicaties zoals autocad, multicast dingen, voip, etc?

[sakbari]

Het zit zo van de EX4200 kan je een virtual-chassis bouwen je kan deze virtual-chassis uitbrieden met max 10 members. ik kan geen tekening hier plaatsen

ik wil de bestaande access switches via port channel aansluiten op de virtual-chassis

[Equator]

Als je een tekening hebt dan kan ik die wel voor je plaatsen. Stuur hem maar via de mail naar [e-mail]

Je hebt het nu over zowel EX3200 als de EX4200. Wat is het nu, en wat moet het worden?

Ik begrijp dat de Juniper die je als coreswitch in wilt zetten max 64 LAG (port channels) aan kan maken en jij wilt er dus 150 op plaatsen? Dan zal je dus een aanpassing in je netwerkdesign moeten doen door bijvoorbeeld je aantal coreswitches te verhogen.

[Koffie]

Move Netwerken -> PNS

[PerfectPC]

Koffie schreef op woensdag 18 december 2013 @ 23:22:
Move Netwerken -> PNS

you're joking right?

Sakbari, wat jij wil doen gaat gewoon niet. Ofwel moet je de topologie veranderen, ofwel moet je echte core switches gebruiken.
Ik raad je verder aan om hiervoor een professional in te huren.

[pablo_p]

In het algemeen zie je dat de virtual chassis technieken op dit moment als zij-effect hebben dat de aansluitcapaciteit van een set lager wordt, omdat de limieten (max LACP/LAG, max spanning tree ports etc) ook gedeeld worden. Jouw wens kan je dus in dit geval niet direct uitvoeren.

Het is dan wel goed te kijken naar waarom je LACP wilt gebruiken.
- loop je binnenkort tegen performance limieten aan (link utilization van uplinks)
- will je redundantie hebben met minimale afhankelijkheid van spanning-tree?
- wil je snelle convergentie hebben in geval van uitval?
- heb je LACP nodig op alle koppelingen op slecht op een gedeelte (geldt voor alle bovenstaande punten)

En weet dat je ook naar de access-laag kan kijken. Indien meerdere access-switches bij elkaar staan, kan je die dan niet combineren tot één logische eenheid? Waarschijnlijk kan dat nu niet en ga je ze ook niet allemaal vervangen. Maar als je over twee jaar naar meer LACP wilt en over anderhalf jaar staat op de planning om de access-switches te vervangen, dan kan je dat dan meenemen.

Los hiervan vind ik zwaardere core switches niet slecht klinken. Ik ben niet vaak tegengekomen dat er problemen ontstonden door beperkingen in forward-rates van switches, wel in Spanning-Tree capaciteit. Als je relatief lichte switches gebruikt (weinig CPU power, forwarding gaat met ASICs), heb je een grote kans op instabiliteiten als die lichte CPUs LACP, STP, SNMP, IGMP snooping, DHCP snooping en andere control en management protocollen moeten draaien.Ik heb een DC omgeving met 4 Cisco 4500 distributieswitches met 200+ access-switches helemaal zien instorten, de limieten van stabiliteit waren opgezocht tijdens de geleidelijke groei van het netwerk.

[sakbari]

Beste mensen het gaat om volgende


we hebben op dit moment ongeveer 150 access switches die zijn met elkaar verbonden via de gigabitEthernet. Equator zal tekening voor me plaasten.

ik weet dat de juniper EX4200 Virtual Chassis MAX LACP porten heeft dat is namelijk 64. ik heb mijn heel netwerk topologie in 2 gesplits zoals jullie in tekening kunnen zien.

voor mijn distributieswitches wil ik de ex4200 Virtual Chassis gebruiken en als routerdistributie SRX550.
het gaat om een netwerk voor een hosting pakketen. openvz.


wat raden jullie mijn aan

[ijdod]

Qua redundantie en beschikbaarheid is het verstandig je te beseffen dat de virtual chassis technieken nog wel eens last hebben van chassis-itis: dat er zich een errorconditie voordoet die het alsnog noodzakelijk maakt dat *beide* switches in het virtual chassis gelijktijdig geboot moeten worden. Heb dit zien gebeuren met VSS (Cisco), IRF (HP) en met stip op 1: SMLT (Nortel/Avaya). Toegegeven, geen Juniper ervaring. Ook de geclaimde failovertijden kunnen optimistisch zijn.

Verder zijn het doorgaans proprietary protocollen, waardoor je nogal afhankelijk bent van de documentatie (or lack thereof) en beschikbare switch management output van de leverancier. Wel iets op rekening mee te houden.

[Equator]

Hierbij de tekeningen:





@sakbari: Ik heb geen dia geïnstalleerd dus ik kan ze niet groter krijgen. Deze tekeningen hebben we erg weinig aan...

[ Voor 14% gewijzigd door Equator op 19-12-2013 22:23 ]

[PerfectPC]

Ah ok,je wil ze dus niet als core maar als distributie laag gebruiken, da's iets heel anders...
Dan is't heel simpel: gebruik geen stacking (of slechts per 2), dan heb je voldoende LACP bundels per distributie switch. En vanaf elke distributie switch/stack leg je een redundante L3 linknaar je core switches.
Maar zoals ijdod al aangeeft: oppassen met VSS en SMLT varianten, dat kan vuurwerk geven, je bent gewaarschuwd...

[Equator]

grotere versie van de tekening, maar nog altijd erg lastig leesbaar IMO.

[WhizzCat]

Waarom zou je überhaupt iets met virtual chassis-achtige zaken willen gebruiken? Waarom niet gewoon op basis van (R)STP of OSPF o.i.d.? Lijkt mij een stuk handiger en makkelijker te onderhouden

[sakbari]

Beste Tweakers

wat ik op wil zetten is 2 virtual chassis van minimaal 4 members. dat wordt mijn distributie laag. deze distributie laag wil ik via 10-Gigabit op de Router aansluiten. de access switches via EtherChannel aansluiten naar de distributie laag. zoheb ik wanneer er een link down is andere als redundantie.

in de tekening zien jullie een voorbeeld ervan.

[Equator]

Die VC keuze is waarschijnlijk genomen omdat hij een LACP wil maken tussen de Access Switches en de Dsitributie Switches. De keuze hiervoor kan genomen zijn voor Fail-over en of verhoogde bandbreedte.

De verhoogde bandbreedte is afhankelijk van het verwachte gebruik wel of minder interessant. Bij een-op-een verkeer zal je dit niet gaan merken. Bij veel-op-een zal dat wel interssant zijn.

Als het puur een keuze is voor de fail-over dan is (R)STP misschien een veel makkelijkere keuze.

Dan komt het neer op: (Even quick & Dirty )


Waarbij je de link van de Distributielaag naar de core laag nog kan verdubbelen met een LACP port channel indien mer bandbreedte vereist is.

[WhizzCat]

Wat Equator dus zegt. Vandaar dat ik in mijn eerste post hier ook vroeg naar het type verkeer. Dat is wel relevant voor de keuzes die je nu moet gaan maken.

Eventueel kan je nog denken aan OSPF tussen je Core en Disitributie met wat koppelnetwerkjes er tussen. Dan heb je ook nog goeie failover. Van je Distri naar Access zou ik dat STP doen. Dat is ook wat we hier ongeveer doen en dat is eigenlijk een prima oplossing voor jou hoeveelheid switches denk ik.

[sakbari]

het type verkeer is veel-op-een. op de access switchen worden de servers van de klanten aangesloten.
het gaat om webhosting pakket OPENVZ. klanten hebben ook eigen servers met eigen vlan.


je moet zo zien elke kast heeft 2x Cisco Catalyst 2960 die wil ik met LACP aansluiten op de VC. VC wordt mijn distributie laag. en de distributie laag ( VC) wil ik via 10-Gigabit aansluiten op de Routers ( SRX550)
De SRX550 is ook een stacken.

[Equator]

Maar volgens jou kan die VC (wat IMO ook gewoon een stacked oplossing is, althans zo zie ik het) maar maximaal 64 Link Aggregates aan. Dan wordt dat dus lastig.

Veel op 1 zeg je. Hoe loopt de verbinding van de daadwerkelijke client (met de webbrowser) dan naar de servers van de klanten op de access switches? Is dat rechtstreeks of zit daar nog een (NAT) router of reverse proxy voor?

[PerfectPC]

sakbari schreef op vrijdag 20 december 2013 @ 11:06:
De SRX550 is ook een stacken.

wait... what???
De SRX550 is een firewall, die stack je niet maar gebruik je in een active/active of active/stanby HA cluster.
Verder gebruik je zo'n toestel ook NIET als core switch (ik weet zelfs niet of L2 mogelijk is tussen verschillende GPIM of XPIM slots...)
Verder heb je maar 3 10GE aansluitingen op een SRX550.

Waarom ben je zo koppig en blijf je voorthameren op je oorspronkelijke idee? Je komt hier raad vragen maar doet er niets mee...

[sakbari]

de verbinding van de website loopt achter een hardware node. de hardware-node doet niet (NAT) de hardware node doet bridge
deze hardware Node is aangesloten op de access switchs..

na de acces switch komt eerst de core switch en vervolgens de routers.

welke opzet raad jullie me aan.

@PerfectPC ik ben niet koppig ik ben opzoek naar de beste oplossing

[Paul]

Ok, resumé:

Je hebt 2 stuks Juniper SRX550 firewall, deze wil je tussen je uplink en je racks zetten neem ik aan.

Verder heb je 75 racks met in ieder rack twee Cisco 2960's. Je zoekt nu een manier om deze 2960's aan te sluiten op je firewalls?

[sakbari]

klopt Paul en daarbij weet ik niet zeker of de SRX550 de juiste Firewall/routers zijn.

[KoeKk]

Welke JunOS versie gebruik je op je EX series switches? De limiet van 64 LAG's is vanaf JunOS 12.3 verhoogt. Zie de volgende link: http://www.juniper.net/te...erfaces-lag-overview.html

Als je 12.3 draait, of naar 12.3 kan upgraden heb je voldoende LAG's om uit te voeten te kunnen.

[edit]
Wat trouwens GEEN toekomstbestendig pad is, uiteindelijk zal je tegen hetzelfde probleem aan lopen als je groei in je DC hebt. Of het moet acceptabel zijn om meerdere VC's in te richten, dan komt er gewoon een VC bij als je een aantal racks er bij krijgt

[ Voor 29% gewijzigd door KoeKk op 20-12-2013 15:57 ]

[Paul]

Je weet niet of... Ok, stapje terug, wat HEB je (al dan niet al in bevestigde bestelling)? Heb je die SRX'en al maar lepel je het typenummer uit je geheugen op of had je die al gevonden als 'die lijken me wel leuk'?

[sakbari]

de SRXen heb ik nog niet bevestigd omdat ik niet zeker weet of deze wil het verkeer aan kunnen wat we hebben.

@koeKk bedankt voor de info ik kan hiermee uit de voet. heeft LAG's geen invloed op de Performance van de VC.

[KoeKk]

En LAG kan invloed hebben op de perfomance van je VC, er gaat LAG / LACP verkeer over je VC link geduwd worden. Maar dit is niet anders als bij normaal verkeer tussen interfaces van de verschillende node's

Dit zou in geen geval tot management issues in je VC mogen leiden, maar goed, dat heb ik een fabrikant vaker horen zeggen . Overigens heb ik dit nog nooit meegemaakt, en ik heb mijn Junipers al aardig mishandeld.

[ Voor 15% gewijzigd door KoeKk op 20-12-2013 16:32 . Reden: Wat verduidelijkt ]

[Paul]

sakbari schreef op vrijdag 20 december 2013 @ 15:55:
de SRXen heb ik nog niet bevestigd omdat ik niet zeker weet of deze wil het verkeer aan kunnen wat we hebben.

ok, en hoeveel verkeer heb je (PPS en throughput)? Hoeveel VPN's wil je opzetten? Personal of site-to-site? Hoeveel subnetten / VLAN's? Hoeveel regels? NAT? Speciale dingen of alleen een paar honderd keer "iedereen mag naar TCP/80 van server 172.19.12.53"?

Ik weet niet of je een leverancier hebt die je hierbij helpt maar ons geef je in ieder geval wat weinig om mee te werken

[KoeKk]

Dat is onderdaad een goeie Paul, dit is geen materie waarbij je even een gok doet. Dus de beste tip is: zorg dat je een engineer er naar laat kijken.

Als er 8 EX4200's aangeschaft kunnen worden is er hopelijk ook budget om een netwerk nerd er 4 of 8 uurtjes naar te laten kijken .

[knutsel smurf]

Ik weet niet of je keuze voor Juniper al vast staat maar kijk eens naar de Alcatel-Lucent 6900 die kan namelijk wel wat je wilt.

De opzet die je wilt is wel mogelijk wanneer je gebruik zou maken van 2x een ALU OS6900 in virtual chassis(tot max 6 in 1 Virtueel chassis), vervolgens kan je ook MultiChassis-LAG toepassen waardoor je 60x een stack kan aansluiten en 2x 10GB.

Waarschijnlijk is de OS6900 ook nog goedkoper dan de Juniper wat weer ruimte geeft voor een engineer.

[ik222]

Zonder echt inzicht in de gevraagde performance van het hele netwerk blijft het gevaarlijk om hier iets over te zeggen. Als het puur om redundantie gaat is misschien wel de eenvoudigste / beste optie om elke access switch middels één 1G link op de distributie laag aan te sluiten, en daarbij dan een verbinding tussen de twee access switches in een kast te maken. Op die manier heb je ook een prima redundantie als je gebruik maakt van RSTP (zorgen dat in een normale situatie de link tussen de beide access switches blocked is). Alleen moet je dan wel weten of je voldoende performance overhoudt wanneer een van beide uplinks down gaat. Met bovenstaande zou er ook niet direct meer een noodzaak zijn voor VC binnen je distributie laag.

[ Voor 12% gewijzigd door ik222 op 21-12-2013 22:31 ]

[knutsel smurf]

je wilt niet meer gebruik maken van RTSP omdat er dan altijd 1 link op blocked staat, met LAC of MC-LAG krijg je altijd actieve paden en dan heb je nog steeds redundantie.

[Equator]

Maar dan moet de distributielaag wel meerdere Link Aggregates aan kunnen. Als dat niet kan (of je zit tegen de max aan en je hebt geen groeipad) dan moet je daar van afwijken. Als een enkele 1Gbps verbinding niet voldoende is dan zal je moeten upgraden naar 10Gbps van je access switches naar de distributielaag.

Als de topicstarter toch wil vasthouden aan een LAG/LACP van de access switches naar de distributielaag dan zal hij de keuze voor de distributielaag moeten heroverwegen.

[knutsel smurf]

Door te upgraden naar 10GB kan je de distributie laag er tussen uit knippen, in principe is dat ook mogelijk kijkende naar de hoeveelheid poorten die nodig zijn denk ik dat dit geen probleem is.

[sakbari]

@paul (PPS en throughput)
MAX 403.07 kpps uplink in pps
MAX Uplink 495.78 Kpps out pps

er zetten 3 VPN verbindingen.

[Paul]

Hmm, dan zit je met de SRX wel aan je max als ik de datasheet mag geloven. Je hebt een datacentrum met 75 racks maar bent hier in het topic aan het klungelen met branch- of campus-zooi. Waarom?

Laat ik voorop stellen dat ik geen ervaring heb met Junpier, maar zo te zien is de SRX1400 (XGE) beter geschikt en als je denk nog te gaan groeien misschien zelfs de 3400. Ik weet alleen niet hoe ik die datasheets moet beoordelen, het kan zijn dat die 'max'-getalletjes inclusief het maximum aantal extra processing cards is...

Dan je distributielaag. Je hebt al 150 stuks Cisco 2960. Met 48 poorten per switch zou ik 4 stacks (virtual chassis) maken van ieder 2 switches (mits je afstanden binnen de 100m blijft). Je hebt dan 8 uplink poorten naar core-swiches of naar IOC's om de SRX en kunt groeien naar 96 racks.

Je kunt de EX4550's in de volgende opstelling er tussenuit laten door 10GE IOC's in de firewalls te plaatsen maar daar bespaar je niet zo heel veel mee en het is een stuk minder flexibel.

[sakbari]

Beste paul

ga ik problemen krijgen wanneer ik de access switchs met etherchannel aansluit op de VC van EX4200.
en de SRX550 vervang voor de SRX1400 en de SRX1400 in stack aansluit.

met de Junos OS 12.3 kan men 111 Aggregated Ethernet Interfaces maken. als ik mijn netwerk in 2 VC verdeel. moet toch ook goed gaan.

[Paul]

Qua aantallen heb je dan nog evenveel switches nodig, je hebt nu eenmaal 300 poorten nodig op je distributielaag. Omdat je nu (meer dan) 96 + 1 LAG's kunt maken kun je er inderdaad minder stacks van maken.

Mijn oplossing is de mooiste, als dat teveel 10GE SFP's kost kun je die nog met de helft verminderen (distributie -> core niet iedere member naar beide cores, core -> firewall niet iedere core naar beide firewalls).

Met maar 2 stacks kun je mogelijk de core-switches overslaan omdat je voldoende poorten hebt op de firewalls, maar dat hangt wel heel erg van je logische structuur af, ik weet niet of die firewalls kunnen switchen tussen de poorten, en ook niet of dat nodig is.

Ik herhaal het nog maar een keer: Bel je leverancier Die is daar veel beter in dan wij dat zijn, ten eerste kent die zijn product een stuk beter en ten tweede haalt hij uit zijn intake-gesprek en site survey veel meer info dan dat wij via een forum kunnen achterhalen.

[Bastiaan V]

Stacken met srx-en gaat (nog) niet lekker (dat wil zeggen, layer2 verkeer tussen poorten van de twee nodes in een cluster), je moet deze in (iig per interface) als active/standby gebruiken.
dat houd ook in dat je niet 1 lacp tussen je srx cluster, en je EX VC kan maken (Geloof me, been there :-))

Wij hadden dezelfde idee-en, en zijn daar in overleg met JTAC op terug gekomen.
Houd er ook rekening mee dat er SRX features zijn welke niet supported zijn in een cluster (MPLS bijvoorbeeld)

Eerste vraag die bij mij opkomt is hoe het meeste verkeer loopt, horizontaal (tussen je servers) of verticaal (tussen WAN en servers).
Wat wil je precies firewallen (hoe zijn je zones onderverdeeld) enkel tussen servers en internet? of ga je vlans stretchen tussen je racks?

[ Voor 15% gewijzigd door Bastiaan V op 24-12-2013 19:50 ]

[Fabian]

Hier draait een ex4200 stack als distributie en cisco 2950/2960/3560 als access met LAG naar ex4200 al enige jaren erg stabiel.

Hierbij is er voor gekozen om STP zo ver mogelijk naar buiten te duwen. De ex4200 doen dan ook geen STP.

Wanneer je er zeker bent van je Layer1 zou ik geen LACP gaan gebruiken, maar gewoon kale etherchannels. Scheelt weer CPU en scheelt LACP gehaper wanneer de CPU van de ex4200 het wel een keer druk krijgt.

[sakbari]

@Bastiaan V

(Houd er ook rekening mee dat er SRX features zijn welke niet supported zijn in een cluster (MPLS bijvoorbeeld)

waneer de SRX in cluster zijn geconfigueerd ondersteunen geen MPLS wil je zeggen?

de hoofzakelijke verkeer loopt hier verticaal (tussen WAN en servers).

wat we met de firewallen doen is het filteren van inbound-traffic en blokken van bepaalde IP adres als ze aan het spammen zijn of Ddos aan het uitvoeren zijn.

de server worden door vlans gescheiden. we hebben op dit moment 25 vlans

[Harrie666]

25 vlans over 75 racks is een redelijk plat netwerk zoals ik het ff snel zie.

Vergeet eens ff welke firewalls/routers/switches je er in wil hebben en of je STP of LACP wil gebruiken.

Wat wil je gaan bereiken ? redundante internet feed naar je racks en dat verdeeld over een paar Vlans ?
Welke snelheden moeten er op welke plek zijn ? waar zitten de zwakke punten ?

je verhaal zou ik wel kunnen beoordelen en er een gerichte wilde gok op los laten maar echt duidelijk wat je wilt bereiken heb ik nog niet gelezen.

Vergeef me als ik ergens een regel niet gezien heb......

[sakbari]

Beste @Harrie666

als Firewall willen we SRX550 of SRX1400 gaan gebruiken

en het zijn geen werkplekken maar servers die in OPENVZ draaien.

wat we willen is de access switchs op een VC aansluiten met LACP voor redundante en ik heb een verbeterde tekening helaas kan ik deze niet zelf plaasten.

ik vraag @Equator of hij de tekening voor kan plaatsen

[Paul]

Kun je in de Karmastore het fotoalbum 'kopen'? Of anders uploaden naar één van de vele gratis foto-sites?

wat we willen is de access switchs op een VC aansluiten met LACP voor redundante

Dat ziet er uit als een technische requirement, wat zijn de functionele requirements?

Iedere server redundant aansluiten op een firewalled internetconnectie? Want je blijft met apparaten en technieken gooien terwijl je ons nog niet volmondig hebt kunnen beamen (of vertellen) wat je probeert te bereiken

[sakbari]

https://mega.co.nz/#!2NdE...JEvEWKV4tE43a3LbopQ14GB_A

[sakbari]

Beste paul

wat ik wil is de access switches redundant aansluiten op de distributie Laag. De juniper ex4200 virtual chassis wordt dan mijn distributie Laag zie tekening

https://mega.co.nz/#!2NdE...JEvEWKV4tE43a3LbopQ14GB_A

[Equator]

Op verzoek nog een tekening..