On Mon, Aug 30, 2010 at 08:01:50AM -0700, Derick Winkworth wrote: > In fact, yes! 10.3 is primarily a JUNOS cleanup effort. There should > be close to nothing in the release notes compared to previous > releases. > > I believe they intend to do this with another release in the near > future. Like 10.5?
The story I've heard is that they put the brakes on almost all new feature development for 10.3 and I think 10.4, to give them a chance to get their systest act together. I'm not sure if halting feature development (and switching to a goofy quarterly date-based release system :P) is really the right way to fix things, but at least they're trying to do something to address the very serious issue of the disasterously buggy code they've been churning out lately, so at least that's something. :) > I think they are really, really wanting to have another golden release > similar to 8.5. Perhaps Richard's stalled route issue will be > cleared? Don't get your hopes up, I don't think there has been any significant progress made on the route stall issue. As far as I can tell it appears to be a long-standing issue in rpd that Juniper just doesn't have the ability or will to fix (at least not at the rate they're losing rpd developers). The root of the issue seems to be that exchanging large numbers of routes over BGP will starve something within rpd, to the point that new routes cannot be installed to the FIB, and in some cases the box won't even start advertising any routes outbound, while it is still receiving new BGP routes. For MX's our best solution was to roll out a layer of dedicated route reflector boxes to replace our current IBGP core mesh, thus hiding most of the inactive paths from the real routers (e.g. bringing it down from 3-4 million paths over ~30 sessions to 330k * 2 paths from 2 sessions). EX is still pretty bad though, you can stall it for 20 minutes with less than a million paths, which is a real problem when you have a customer aggregation router which won't advertise customer prefixes for 20 minutes following rpd restart. I'm really wondering how things are coming with SMP-capable JUNOS. I tried booting a jinstall64 olive, and while the image isindeed using an amd64 kernel it STILL doesn't have SMP enabled. Considering they briefly slipped in a line about upcoming Core2 Duo/Quad RE's into some recent release notes, I really hope they're gonna have this working soon. :) -- Richard A Steenbergen <[email protected]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
