[j-nsp] MX-Series JUNOS Version

[Eric Van Tol]

> -----Original Message-----
> From: Richard A Steenbergen [mailto:ras at e-gerbil.net]
> Sent: Thursday, February 04, 2010 2:21 PM
> To: Eric Van Tol
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] MX-Series JUNOS Version
> 
> On Thu, Feb 04, 2010 at 12:42:29PM -0500, Eric Van Tol wrote:
> > Hi all,
> > We just took shipment of some MX960s and MX240s for a much needed
> > network upgrade.  They came shipped with 10.0R2.10.  This seems to be
> > the latest and greatest version of JUNOS.  The question is, is anyone
> > currently running it and is it "stable"?  Any serious bugs I should be
> > aware of that might not be listed in the JTAC site?
> 
> We've been over this a lot recently, so check the archives. I personally
> recommend you wait for 9.5R4, which is due out just about any time now.
> 9.6R3 might not be a bad option either, but I can't personally vouch for
> it quite yet. From what I've seen, I don't see any particularly
> interesting features for MX between 9.6 and 10.1 (it seems like a
> healthy majority of the dev work being done lately is for SRX).

Thanks, Richard.  Your input is always valuable and quite helpful.  It looks like I'll just be "playing around" with 10.0 until 9.5R4 comes out.  I swore that this was discussed previously, but couldn't find it in my own archives.  I guess I should have gone to lmgtfy.com.

> As generic advice I would say that if you are a "classic" Juniper user,
> you need to put aside any notions you used to have about Juniper
> routinely putting out solid, well tested, working code. For all intents
> and purposes they are now Cisco 2.0, and should be treated as such if
> you want a working network. You really don't want to rush out and try
> the latest and greatest code without doing some very extensive testing,
> and anything before R3 is probably a bad idea if you have any kind of
> complexity in your network/configuration at all.

I have noticed such complaints on-list and this is one reason why we haven't upgraded most of our routers for some time, except for critical bug fixes.  This, and the increase in memory usage with every new version.
 
> FYI for the bug I previously mentioned which crashes rpd in 9.5R3 when
> an interface flaps, it appears to be related to accept-remote-nexthop,
> and can probably be avoided by not configuring that. We've still working
> on the slow fib issue too, haven't quite found the cause yet, but the
> Juniper guys have done a great job helping document the behavior at
> least.
> 
> http://www.e-gerbil.net/slowfib.jpg
> 
> The red line shows the pending routes. The current working theory is
> that installation of the routes into the pfe is blocked until rpd is
> able to advertise them to IBGP. In the graph above, you can see that the
> pending routes don't start to clear until IBGP fully converges, which
> happens after a local transit interface converges and there are no new
> routes to send into IBGP. This is the closest I've felt to actually
> finding and fixing the cause of the problem in...well... ever, so
> hopefully I'll have more good news soon. :)

So I assume that whatever this fix is, it won't make it into any code fixes any time soon.  Funny how a customer has to do all this work to find a bug that seems easy to reproduce.

> --
> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

-evt