[prev in list] [next in list] [prev in thread] [next in thread] 

List:       juniper-nsp
Subject:    Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
From:       Dan Farrell <danno () appliedi ! net>
Date:       2010-06-22 15:27:08
Message-ID: 06275CB4814DA94AB880409FDD8D779C14DEBD705A () EXMBXCLUS01 ! citservers ! local
[Download RAW message or body]

We experienced phantom routing and arp issues as well in the 9 series, but 10.0s1.1 \
has been very stable.

-----Original Message-----
From: Cyrill Malevanov [mailto:cm@n-home.ru] 
Sent: Tuesday, June 22, 2010 10:18 AM
To: Dan Farrell
Cc: Laurent HENRY; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?

We have a lot of routing problems on EX4200 VC's. Standalone EX works fine, but \
routing on high loads using VC - is a pain. Some routing loss, packets loss etc.

Cyrill

On 22.06.2010 17:59, Dan Farrell wrote:
> Not in -this- version 10.0S1.1 .  I sing the praises of the EX series because it \
> fits our needs like a glove and Cisco wants more money for less product. But just 6 \
> months ago it was a little rough because the platform, IMHO, was 'growing up' in \
> the 9.X series. There were some definite operational problems we had on 9.  With \
> 10, aside from great stability, one noticeable difference is interface groups- in \
> our environment (virtualization hosting) this has made configuring the devices \
> significantly easier.

> 
> At this point I can't fault them, and we are using 4200 VC stacks to slowly expand \
> our core routing/switching, one chassis at a time (getting ready to add our first \
> third chassis to a stacked core). We may eventually convert to the 8208 platform \
> there, but right now the 4200's price point is so attractive it's hard not to \
> continue in this direction. 
> 
> Dan
> 
> -----Original Message-----
> From: Laurent HENRY [mailto:Laurent.Henry@ehess.fr]
> Sent: Tuesday, June 22, 2010 5:23 AM
> To: Dan Farrell
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
> 
> 
> Thank you !
> No weird bugs encountered ?
> 
> 
> Le Monday 21 Ju4ne 2010 23:25:13 Dan Farrell, vous avez écrit :
> 
> > We leverage the EX3200 and 4200's extensively in our network, for 
> > edge, core, and access.
> > 
> > As far as edge (ISP connectivity) we use EX3200's in pairs- each
> > EX3200 has a separate peer session to each upstream provider, 
> > providing redundancy
> > (high-availability) without merging the two units as one logical unit.
> > This makes zero-downtime maintenance easier at your edge, as 
> > upgrading a stacked chassis involves rebooting all the devices at 
> > once. And they're cheaper than their 4200 counterparts.
> > 
> > I'm elated at the 4200's performance in our core- I think what may be 
> > of use to you is a comparison to equivalent Cisco gear- in this light 
> > we just replaced a two-chassis 3750G stack with a two-chassis EX4200 
> > stack (we stack them to take advantage of port densities with 
> > staggered growth in the core), and we are glad we did so.
> > 
> > The EX series allows 1000 RVI's and 4k VLANS per virtual chassis- the 
> > Catalyst 3xxx series only actually supports 8 RVI's, and they don't 
> > publish this (you will find it when configuring the profile of the 
> > device). This created a problem with 10 OSPF interfaces (and 15 other 
> > non-OPSF
> > interfaces) on the Cisco. Upon a link-state change on any of the 
> > Cisco's OSPF-configured interfaces, the CPU would crank up to 100% 
> > and the stacked device throughput was ground to a crawl (80%+ traffic 
> > loss). Changing the configuration in the OSPF subsection, elimination 
> > of the problem interface (flapping or not) from the configuration, or 
> > a complete reboot would solve the problem- none of which are 
> > attractive solutions to a problem we shouldn't have been having in the first \
> > place. 
> > Compare this to a two-chassis EX4200-48T stack we have in another 
> > part of the network- 13 OSPF interfaces and ~845 other non-OSPF RVI's 
> > , and the stacked device hasn't given us any grief.  They cost us 1/3 
> > less than the Cisco solution, and doubled the port density (the 
> > Ciscos had
> > 24 and the Junipers we got have 48 ports).
> > 
> > There are platform limitations, like memory, which may cause you to 
> > be a little more exotic on BGP route selection, but the Catalyst 
> > 3750G's have even less memory as I recall. Overall they have been 
> > extremely good for our network, and have caused me to swear off Cisco completely.
> > 
> > Hope this provides some insight.
> > 
> > Dan
> > 
> > -----Original Message-----
> > From: juniper-nsp-bounces@puck.nether.net
> > [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Laurent 
> > HENRY
> > Sent: Monday, June 21, 2010 6:29 AM
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
> > 
> > Hi all,
> > I am thinking about using two EX 4200 as redondant border 
> > routers of my main Internet link.
> > 
> > In this design, I would then need to use BGP with my ISP and OSPF for 
> > inside route redistribution.
> > 
> > Reading the archive, and on my own experience with the product too, i 
> > am looking for feedbacks about stability of this solution with EX.
> > 
> > In archives i understood there could have been some huge stability 
> > problems, am i right ?
> > 
> > Could things be different with 10.1 JunOS release ?
> > 
> > Does anyone actually use these features actively with this platform ?
> > 
> > 
> > Regards
> > 
> > 
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net 
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic