[j-nsp] MX-Series JUNOS Version

[Richard A Steenbergen]

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).

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.

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. :)

-- 
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)