With 10.0.S1.1 the only headaches we encounter with our loaded configuration on a 2-member 4200 stack (~850+ RVI's total, some on OSPF) is the time it takes for the configuration to be checked or implemented from the CLI. The wait times from "commit" to actually being returned to the command prompt can be up to twenty seconds sometimes. At first this scared me (making large changes in a production environment... then ... wait.) but now I'm accustomed to it.
But the CPU under regular performance (no configuration changes or port mirroring stuff) leaves the CPU at an average of 12% on a very active network (routing internet access traffic along with switching SAN traffic for thousands of virtual servers, so it's doing some heavy lifting). Dan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ross Vandegrift Sent: Monday, June 21, 2010 11:33 AM To: Laurent HENRY Cc: [email protected] Subject: Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? On Mon, Jun 21, 2010 at 12:29:00PM +0200, Laurent HENRY wrote: > 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 ? We make some use of layer 3 services on the EX-4200, and largely, our experience has been good in this department. Be aware that their FIB size is very limited, so you'll need defaults. We have EXes working a customer edge boxes for people that don't want a full table and it's reliable and cost effective if you can live without the missing features. We do OSPF, iBGP, and some MPLS, though the EXes are feature crippled there. If you care, uRPF sucks big time, but I'm used to that from the 6500. Be somewhat cognizant of RE CPU performance. Unfortunately, the EX CPU doesn't cope too well with large VC installations in complicated configuration. In my experience, you'll be fine if you stay away from virtual-chassis. We've only really hit this in our layer 2 deployments, where committing a config can cause STP to miss BPDU timers. However, I don't see any reason why a 10 member layer 3 VC wouldn't exhibit the same issue with (for example) OSPF hellos. Software choice can be annoying - things are still changing. 9.6 is my current target for layer 3 boxes because you finally get capable loopback filters with recent bugfixes. If you want to police LSPs though, you'll need 10.1. I've had good luck so far with 10.1R2 in this application. Of course neither of these are extended EOE... To sum up - if you can live with some missing features and headaches, they aren't bad. The price point is pretty attractive. Ross -- Ross Vandegrift [email protected] "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
